在cocos creator中使用protobufjs(二)

概述一、 不修改源码让protobufjs适应多平台 我们上一篇《在cocos creator中使用protobufjs（一）》讲解了通过修改源码的方案，让protobufjs能正常运行在jsb环境上。这个方案适合将protobufjs源码直接放到项目中，而我们使用npm来管理三方库的方式，这种方案就显得不太优雅。 1. 解决IS_NODE的检查 之前源码中已经看到Util.IS_NODE是用来区分代 一、 不修改源码让protobufJs适应多平台

我们上一篇《在cocos creator中使用protobufjs（一）》讲解了通过修改源码的方案，让protobufJs能正常运行在Jsb环境上。这个方案适合将protobufJs源码直接放到项目中，而我们使用npm来管理三方库的方式，这种方案就显得不太优雅。

1. 解决IS_NODE的检查

之前源码中已经看到Util.IS_NODE是用来区分代码是运行在nodeJs上还是浏览器上。我们可以模拟cocos-Jsb为nodeJs环境，我们看protobufJs是怎么来检查环境的。

Util.IS_NODE = !!(    typeof process === 'object' && process+'' === '[object process]' && !process['browser']);

上面这段代码我们注意两个地方：

!!：在一个变量或表达示前面使用“!!”的意思是将其值转换为boolean值即true或false，这是Js中常用的技术，第一次见这种写法的人可会犯晕。 process：process对象是nodeJs的内置进程对象，在cocos-Jsb上肯定是没这货，那怎么办呢？

方案一：伪装者

在require(‘protobufJs’)之前我们自己定义一个process对象

if(cc.sys.isNative) {    global.process = {         toString: () => '[object process]'    }}...require('protobufJs');

这种方案相当于欺骗protobufJs我们是nodeJs，这段代码也解释两句：

global: global对象是Js中很特殊的对象，全局的方法、属性都集中在一个对象中。我们这里将process对象放到global上相当于定义了全局变量。 toString方法：Js中所有对象上都具有toString方法(除null\undefined外)，当你在对象上使用字符串连接“+” *** 作时，其实是调用的对象的toString方法。

这种方法可将coco-Jsb化身为nodeJs，但感觉有点文绉绉的，我们再看看更直接的方法。

方案二：霸王硬上弓

在require(‘protobufJs’)之后强制修改Util.IS_NODE的值

protobufJs.Util.IS_NODE = cc.sys.isNative;

这个方法简单直接，而且不怕他修改检查方案，我觉得这个方法更好。

2. 解决fs.readfile/fs.readfileSync

...if (Util.IS_NODE) {    //cocos中那来的fs模块呀？    var fs = require("fs");    if (callback) {        fs.readfile(path,function(err,data) {            if (err)                callback(null);            else                callback(""+data);        });    } else        try {            return fs.readfileSync(path);        } catch (e) {            return null;        }}...

这里不能硬来了，硬来只能改源码，使用伪装的方法，我们去编写一个fs模块

//fs.Jsmodule.exports = {    //同步读取文件    readfileSync(path) {        //cocos-Jsb提供有相同功能的函数，就借用下它        return Jsb.fileUtils.getStringFromfile(path);    }    //异步读取文件    readfile(path,cb) {        //cocos-Jsb没提供异步读取文件的函数，这里只能简单执行下回调传回读取内容        let str = Jsb.fileUtils.getStringFromfile(path);        cb(null,str);     },}

我们这里是偷梁换柱，实现了一个fs模块，这关算是过了。这里需要注意的是Jsb.fileUtils对象，上面封装有不少原生上的文件 *** 作。

大多数方法一看名字就知道用法了，这里就不再一一说明。

3. 解决require(“path”)问题

源码中有对path模块的使用：

...filename = require("path")['resolve'](filename);...fname = require("path")['join'](root,filename.file);...

乍眼一看感觉这种写法有点乱，其实它等同如下代码：

let path = require("path");filename = path.resolve(filename);filename = path.join(root,filename.file);

这样看就明白了，有个path模块，调用了他的resolve和join方法，path伪装再次登录场：

//path.Jsmodule.exports = {    //获取全路径    resolve: (subPath) => {        //使用cc.url.raw实现获取全路径        return cc.url.raw(`resources/${subPath}`);    },// 方法使用平台特定的分隔符把全部给定的path片段连接到一起    join: () => {        //使用cocos提供的cc.path.join实现        return cc.path.join.apply(null,arguments);     }}

问题终于被被解决了，估计好多人会觉得好麻烦！我的demo中已经实现了这些伪装者文件。 写这么多其实主要是想让大家了解的是JavaScript语言的灵活性，以及一种思路一种可能性。如果觉得还是不能接受，下面我再给大家介绍一种方案，预编译proto文件。

二、 使用预编译方案

在静态语言中使用protobuf都需要将proto文件编译成目标代码，protobufJs模块也为我们提供了pbJs命令行工具。

1. pbJs工具介绍

上图是pbJs命令工具的帮助，看起来参数不少，但我们这里只需要很简单的使用，生成Json格式或Js格式。

2. 将proto编译为Json

pbJs xxx.proto > xxx.Json

无需任何选项，直接输入文件名，将输出Json格式的proto文件。
我们来看下如何使用：

let protobuf = require('protobufJs')let builder = new protobuf.Builder();protobuf.loadJsonfile('xxx.Json',builder);protobuf.loadJsonfile('yyy.Json',builder);let PB = builder.build('xxx.yyy.zzz');

其实使用Json格式与使用proto格式没什么大的差别。读过源码的话知道，protobufJs库加载proto文件的顺序大致如下：

加载proto文件 将获取的proto字符串，解析为Json对象 build *** 作将Json对象转换为proto对象

使用预编译Json加载相当于省略了第二步，直接加载Json文件转换proto对象。
当proto文件比较多的时候，使用Json加载可以提高一些效率。

3. 将proto编译为Js

pbJs -t commonjs xxx.proto > xxx.Js

使用pbJs提供的-t参数将proto文件编译为目标格式，这里我们指定的commonjs，后面紧跟proto文件名。

//-----------------------------proto文件内容-----------------------------------Syntax = "proto3";package grace.proto.msg;message Player {    uint32  ID = 1;         //唯一ID 首次登录时设置为0，由服务器分配    string  name = 2;       //显示名字    uint64  enterTime = 3;  //登录时间}//-----------------------------编译后的Js文件内容-------------------------------module.exports = require("protobufJs").newBuilder({})['import']({    "package": "grace.proto.msg","Syntax": "proto2","messages": [        {            "name": "Player","Syntax": "proto3","fIElds": [                {                    "rule": "optional","type": "uint32","name": "ID","ID": 1                },{                    "rule": "optional","type": "string","name": "name","ID": 2                },"type": "uint64","name": "enterTime","ID": 3                }            ]        }    ],"isnamespace": true}).build();

大致一看编译后的Js文件，其实与使用proto文件、Json文件加载没什么本质的区别，简单分析下面代码：

module.exports = require("protobufJs").newBuilder({})['import']({  //proto内容的Json格式  ...}).build();

1.require(“protobufJs”)导入protobufJs模块，
2.newBuilder({}) 实例化一个builder对象
3.‘import’ 调用builder实例上的import方法导入一段Json
4.build() 调用builder实例build方法，生成proto对象
5.module.exports 导出build()后的对象
使用预编译Js的方式不需要加载文件，proto直接编写在Js文件中，当proto文件较多时可以提高性能。

@H_194_419@三、 protobuf爱你不容易

我在使用protobuf的过程也不是一帆风顺，只能说protobuf爱你不容易！

1. 第一个项目

在最初的项目中，使用的是直接加载proto文件，当时也没想过使用预编译的方式。项目中有接近上百个proto文件，proto文件由服务端程序定义的，粒度非常小，几个message就是一个proto文件。开发期间觉得没什么问题，后来发布时，发现加载比较慢，性能差点的手机会特别明显，因此还为加载proto文件的整个过程做了一个进度条。

2. 卡牌项目

之后的一个卡牌项目中，我们吸取了之前的经验，与服务端程序讨论定义proto文件时将同类数据结构尽量定在一个文件中，不要太过分散，任然使用直接加载proto文件的方式。在这项目中虽然protobuf的数据结构更多，更复杂，但文件数量较少加载过程中没有太大影响。

3. SLG项目

后来在一个SLG项目里我们任然使用直接加载proto文件，但SLG项目的复杂度比之前的卡牌上升了好几个数量级，protobuf文件个数、数据结构的规模都翻了几倍，加载proto的加载过程在低配置手机上显的非常慢，又只好为proto的加载过程制作进度条。

4. 小结

至此开始我才开始意识到直接加载大量proto文件的缺陷，在细读protobufJs库的文档之后开始使用在项目中尝试使用预编译的方式。

预编译Js方式解决了文件加载，但增加代码编译时间，在creator中可以将编译的proto文件设置为插件，不参与编译，但文件多了也是很麻烦。

预编译Json方式不会增加编译时间，减少了proto到Json的转换时间，但文件io *** 作任然是最大的瓶颈。

4. 觉知开发中的痛点

在protobuf的使用上，除了proto加载方案的选择外，还存在不少其它问题。

有项目使用Json做协议，无需解码，客户端处理服务器响应逻辑时比较方便。但protobuf必须做解码后才能读取数据结构，proto对象的new、decode代码充斥着客户端项目。

在JavaScript项目使用protobuf还有一个痛点就是IDE无法很好支持proto对象的代码补全，需要在代码与proto原文件中来回切换，不时出现单词拼写错误等问题。

下一次我们将继续探索在项目中如何相对高效使用protobuf。

总结

以上是内存溢出为你收集整理的在cocos creator中使用protobufjs(二)全部内容，希望文章能够帮你解决在cocos creator中使用protobufjs(二)所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。