内容简介:我们上一篇##1. 解决IS_NODE的检查之前源码中已经看到Util.IS_NODE是用来区分代码是运行在nodejs上还是浏览器上。我们可以模拟cocos-jsb为nodejs环境,我们看protobufjs是怎么来检查环境的。
一、 不修改源码让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.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”)问题
源码中有对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.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语言的灵活性,以及一种思路一种可能性。如果觉得还是不能接受,下面我再给大家介绍一种方案,预编译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 }, { "rule": "optional", "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文件较多时可以提高性能。
三、 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操作任然是最大的瓶颈。
四、 觉知开发中的痛点
在protobuf的使用上,除了proto加载方案的选择外,还存在不少其它问题。
有项目使用json做协议,无需解码,客户端处理服务器响应逻辑时比较方便。但protobuf必须做解码后才能读取数据结构,proto对象的new、decode代码充斥着客户端项目。
在javascript项目使用protobuf还有一个痛点就是IDE无法很好支持proto对象的代码补全,需要在代码与proto原文件中来回切换,不时出现单词拼写错误等问题。
下一次我们将继续探索在项目中如何相对高效使用protobuf。
以上所述就是小编给大家介绍的《当creator遇上protobufjs|深入》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 推荐系统遇上深度学习(二十五)--当知识图谱遇上个性化推荐
- 当算法遇上敏捷开发
- 当漏洞管理遇上威胁情报
- 当 WebAssembly 遇上 Serverless
- 当 Substrate 遇上传统业务应用
- 当Substrate遇上传统业务应用
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Building Websites with Joomla!
H Graf / Packt Publishing / 2006-01-20 / USD 44.99
This book is a fast paced tutorial to creating a website using Joomla!. If you've never used Joomla!, or even any web content management system before, then this book will walk you through each step i......一起来看看 《Building Websites with Joomla!》 这本书的介绍吧!