当creator遇上protobufjs|深入

栏目: 编程语言 · IOS · 发布时间: 5年前

内容简介:我们上一篇##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上肯定是没这货,那怎么办呢?

方案一:伪装者

当creator遇上protobufjs|深入 在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,但感觉有点文绉绉的,我们再看看更直接的方法。

方案二:霸王硬上弓

当creator遇上protobufjs|深入 在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对象,上面封装有不少原生上的文件操作。

当creator遇上protobufjs|深入

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

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工具介绍

当creator遇上protobufjs|深入

上图是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文件的顺序大致如下:

  1. 加载proto文件
  2. 将获取的proto字符串,解析为json对象
  3. 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爱你不容易

当creator遇上protobufjs|深入

我在使用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|深入》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

领域驱动设计

领域驱动设计

埃文斯 / 赵俐、盛海艳、刘霞 / 人民邮电出版社 / 2010-11 / 69.00元

《领域驱动设计:软件核心复杂性应对之道》是领域驱动设计方面的经典之作。全书围绕着设计和开发实践,结合若干真实的项目案例,向读者阐述如何在真实的软件开发中应用领域驱动设计。书中给出了领域驱动设计的系统化方法,并将人们普遍接受的一些最佳实践综合到一起,融入了作者的见解和经验,展现了一些可扩展的设计最佳实践、已验证过的技术以及便于应对复杂领域的软件项目开发的基本原则。《领域驱动设计:软件核心复杂性应对之......一起来看看 《领域驱动设计》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具