一，不修改源码让protobufjs适应多平台
我们上一篇讲解了通过修改源码的方案，让protobufjs能正常运行在JSB环境上。这个方案适合将protobufjs源码直接放到项目中，而我们使用NPM来管理三方库的方式，这种方案就显得不太优雅。
1.解决IS_NODE的检查
之前源码中已经看到Util.IS_NODE是用来区分代码是运行在的NodeJS上还是浏览器上。我们可以模拟茯苓，JSB为环境的NodeJS，我们看protobufjs是怎么来检查环境的。
Util.IS_NODE = !!(
typeof process === 'object' && process+'' === '[object process]' && !process['browser']
);
上面这段代码我们注意两个地方：!!：在一个变量或表达示前面使用“!!”的意思是将其值转换为布尔值即真或假，这是JS中常用的技术，第一次见这种写法的人可会犯晕。
工艺：工艺对象是的NodeJS的内置进程对象，在科科斯-JSB上肯定是没这货，那怎么办呢？
方案一：伪装者
在要求( 'protobufjs')之前我们自己定义一个处理对象
if(cc.sys.isNative) {
global.process = {
toString: () => '[object process]'
}
}
...
require('protobufjs');
这种方案相当于欺骗protobufjs我们是的NodeJS，这段代码也解释两句：global：global对象是js中很特殊的对象，全局的方法，属性都集中在一个对象中。我们这里将处理对象放到全局上相当于定义了全局变量。
的toString方法：JS中所有对象上都具有的toString方法(除空\未定义外)，当你在对象上使用字符串连接“+”操作时，其实是调用的对象的的toString方法。
这种方法可将椰油JSB化身为的NodeJS，但感觉有点文绉绉的，我们再看看更直接的方法。
方案二：霸王硬上弓
在要求( '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.js
module.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”)问题
源码中有对路径模块的使用：
...
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.js
module.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语言的灵活性，以及一种思路一种可能性。如果觉得还是不能接受，下面我再给大家介绍一种方案，预编译原文件。
二，使用预编译方案
在静态语言中使用的protobuf都需要将原始文件编译成目标代码，protobufjs模块也为我们提供了pbjs命令行工具。
1. pbjs工具介绍
上图是pbjs命令工具的帮助，看起来参数不少，但我们这里只需要很简单的使用，生成JSON格式或JS格式。
2.将proto编译为jsonpbjs xxx.proto> xxx.json
无需任何选项，直接输入文件名，将输出JSON格式的原始文件。 我们来看下如何使用：
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格式与使用原格式没什么大的差别读过源码的话知道，protobufjs库加载原始文件的顺序大致如下：加载原文件
将获取的原始字符串，解析为JSON对象
构建操作将JSON对象转换为原始对象
使用预编译JSON加载相当于省略了第二步，直接加载JSON文件转换原对象。 当原文件比较多的时候，使用JSON加载可以提高一些效率。
3.将原版编译为js
pbjs -t commonjs xxx.proto > xxx.js
使用pbjs提供的-t参数将原始文件编译为目标格式，这里我们指定的CommonJS的，后面紧跟原文件名。
//-----------------------------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
},
{
"rule": "optional",
"type": "uint64",
"name": "enterTime",
"id": 3
}
]
}
],
"isNamespace": true
}).build();
大致一看编译后的JS文件，其实与使用原文件，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文件较多时可以提高性能。
三，protobuf爱你不容易
我在使用的protobuf的过程也不是一帆风顺，只能说protobuf的爱你不容易！
1.第一个项目
在最初的项目中，使用的是直接加载原文件，当时也没想过使用预编译的方式。项目中有接近上百个原文件，原文件由服务端程序定义的，粒度非常小，几个消息就是一个原文件。开发期间觉得没什么问题，后来发布时，发现加载比较慢，性能差点的手机会特别明显，因此还为加载原文件的整个过程做了一个进度条。
2.卡牌项目
之后的一个卡牌项目中，我们吸取了之前的经验，与服务端程序讨论定义原文件时将同类数据结构尽量定在一个文件中，不要太过分散，任然使用直接加载原始文件的方式。在这项目中虽然protobuf的的数据结构更多，更复杂，但文件数量较少加载过程中没有太大影响。
3. SLG项目
后来在一个SLG项目里我们任然使用直接加载原文件，但SLG项目的复杂度比之前的卡牌上升了好几个数量级，protobuf的文件个数，数据结构的规模都翻了几倍，加载原的加载过程在低配置手机上显的非常慢，又只好为原型的加载过程制作进度条。
4.小结
至此开始我才开始意识到直接加载大量的原文件的缺陷，在细读protobufjs库的文档之后开始使用在项目中尝试使用预编译的方式。
预编译JS方式解决了文件加载，但增加代码编译时间，在创造者中可以将编译的原文件设置为插件，不参与编译，但文件多了也是很麻烦。
预编译json的方式不会增加编译时间，减少了原到JSON的转换时间，但文件IO操作任然是最大的瓶颈。
4.觉知开发中的痛点
在protobuf的的使用上，除了原加载方案的选择外，还存在不少其它问题。
有项目使用JSON做协议，无需解码，客户端处理服务器响应逻辑时比较方便。但protobuf的必须做解码后才能读取数据结构，原对象的新的解码代码充斥着客户端项目。
在JavaScript的项目使用的protobuf还有一个痛点就是IDE无法很好支持原对象的代码补全，需要在代码与原原文件中来回切换，不时出现单词拼写错误等问题。
下一次我们将继续探索在项目中如何相对高效使用protobuf的。
1340
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
