您的位置:首页 > 移动开发 > Cocos引擎

在cocos creator中使用protobufjs(四)

2017-11-30 22:37 597 查看
我们之前讲过要在Creator原生环境下使用protobufjs,使用伪装者的方式模拟nodejs的fs\path模块可以完美解决问题。但随着Creator1.7的到来,Shawn也尝了下鲜,但发现在creator**模拟器环境**下,原来的伪装方案失效了。

一、疑犯追踪

1. 调试神器

追踪Bug这个问题,不得不大赞一下Creator1.7提供的新的底层JS引擎,它使得在原生jsb环境上的调试手段、效率、体验都有了质的飞跃。在iOS/Mac平台使用Safari浏览器,Android/Windows可使用Chrome及Chrome的衍生调试工具。



上图是在Safari浏览器的调试界面,可以非常方便地在命令控制台上查看jsb上的对象、属性和方法,充分利用命令控制台的交互能力,它是学习js和cocos隐藏API的绝佳手段,特别是jsb函数。

2. 调试require函数

通过Safari的断点追踪,找到有一行protobufjs中的关键代码,require(‘fs’)的返回值为undefined,请看下面代码



进入require函数调试,发现nameMap是一个以文件名为Key,文件路径为Value的一个对象,里面没找到fs,看下图:



通过这个nameMap我明白了为什么在Creator中可以直接require(‘文件名’),而不需要完整路径,同时也明白了为什么js文件不能同名的原因。

继续追踪问题,从下图的代码m.deps[request]中查看到fs与path的值都是等于2。



一步步的逼近问题的真相了,scripts数组的2号元素,是一个对象,指向的文件名为preview-scripts/__node_modules/browser-resolve/empty.js,并不是我们伪装的fs模块,请看下图:



从调试的结果来看,Creator模拟器将fs\path模块认为是nodejs的模块,没有按普通模块进行加载,随后向Creator引擎组最为热心的Jare请教此问题时得到证实。

二、一波三折

模拟的fs\path模块目前不能正常工作在Creator1.7模拟器,但在浏览器、自编译的MacApp、iOS、Android上都能正常运行。可是Creator模拟器是日常开发调试的利器,不能使用protobufjs库未免觉得遗憾。更要命的是,它会影响到我的pbkiller插件用户,面对这个问题绝对不可以马虎了事。

1. 明灯

发现问题的第一时间,我火速向引擎组的大大汇报了此问题,热心的Jare建议使用cc.loader.loadRes函数抹平不同平台上文件的加载问题。

当时眼前一亮,猛拍一下自己的脑袋,我以前怎么没想到这个办法?不论是Web\iOS\Android所有平台的文件加载都可以用cc.loader.loadRes搞定,比protobufjs中实现的fetch都简单多了,cc.loader.loadRes为我提供了一盏明灯。

2. 熄火

马上开始动手,但在准备动手前,我就想到绝对不能修改protobufjs的源码,因为我的pbkiller用户有些是用npm来管理的protobufjs,不可能让他们去修改node_moduls里的代码吧,这样太low了!

一束光在一片神经网络的触突上闪耀,电光石火的一瞬间,找到了一个方案

动态修改函数 + cc.loader.loadRes

请看下面代码,修改的Util.fetch方法

let protobuf = require('protobufjs');
protobuf.Util.fetch = function myfetch(path, callback) {
cc.loader.loadRes(path, (error, data) => {
if (!error) {
callback(data);
}
)}
};


正在得意之时,脑子里翁的一声,有问题?如果这样去实现protobufjs的fetch函数,只能是异步加载,而我之前给pbkiller的范例都是同步加载!眼前一黑,回过神来,绝对不能用这种方法坑了我的插件用户。

3. 曙光

不能修改protobufjs源码

保持同步与异步的加载接口

这两个方向如一座灯塔指引着我,我快速冷静下来,不要一牯脑地胡打乱撞。在安静片刻过后,我开始重新对问题进行分析:

1. 面临的问题是什么?

protobufjs库不能通过伪装的方式在creator1.7模拟器上工作,同时要考虑到pbkiller用户的同步加载习惯,不能单纯地使用cc.loader.loadRes的异步加载方案。

分析原因

由于Creator的进化,经过调试分析,伪装者的策略存在了缺陷(就像人小的时候大人连蒙带骗,暂时把孩子给控制住了,但随着一孩子天天长大,他们的学习能力远超过大人的学习能力,原来的小把戏不适用了)。

应对办法

已经实验过在js语言中,为已经存在的函数赋值,可以在运行时修改函数的表现,它是实现继承、多态或勾子常见的做法,这是一个实用的技术。我可以要在运行时修改protobufjs中的关键函数,将其中的具体实现自己重写一次不就行了吗?

这样从物理表面上并没有修改源码,同时又可解决同步异步问题。

4.实施步骤

重写下面两个函数:Util.fetch、Builder.prototype[‘import’]

想办法将其中调用nodejs模块代码摘掉,替换成Cocos jsb等价函数就可以解决问题。

三、逆境成长

经过上面对现状、问题、策略、步骤的自问自答,解决方法跃然纸上。看到这里有人可能会问,这不是四象限法法吗?

1. 四象限法

说实话最早我也不知道四象限法,它是这个周未我刚学到的新知识。当知道这种思考解决问题的方法时,我立刻就想起解决protobufjs在creator1.7模拟器上的问题,当时我不正是用的这种解决问题的吗?

打铁趁热,给大家介绍一下使用四象限法,把任何一个问题拆分成四个象限:

切开上下两部分,一个是现实,一个是理论;切开左右两边,一边是过去,一边是未来;

从而构成思考问题的四个步骤,请看下图:



1. 数据:问题是什么,描述过去的现实

2. 分析:可能原因是什么,思考过去情况的理论原因

3. 方向:应该采取的策略是什么,思考示未来情况的理论策略

4. 下一步:具体的步骤是什么,思考未来情况的实现行动

这个思考过程有点像编写的一个数据转换函数的风格:

输入数据→解析数据→转换数据→生成结果

你还可以将生成的结果做为另一个函数的输入数据,构成一个可以循环使用的流程。

四象限法不仅是个思考工具,它还是一个行动实践指南,更多关于四象限法的知识可以参考《横向领导力》一书,它是我在得到App每天听本书栏目中无意见发现的,也推荐给你。

2. 引导

有了具体的实施步骤,不再废话了,直接上代码

搞定Util.fetch

//导入protobufjs
let protobuf = require('protobufjs');
//保存原Util.fetch函数指针
let fetch = protobuf.Util.fetch;
//编写了一个myfetch函数,覆盖protobuf.Util.fetch变量
protobuf.Util.fetch = function myfetch(path, callbcak) {
//检查是否为原生环境
if (cc.sys.isNative) {
//原生环境直接使用jsb提供的文件操作函数加载proto内容
let str = jsb.fileUtils.getStringFromFile(path);
//如果是异步回调方式,使用callback参数返回数据
if (callbcak) {
callbcak(str);
return null;
}
//同步方式用返回值返回数据
return str;
}
//为web环境使用,protobufjs原来的处理函数
return fetch.call(this, path, callbcak);
};


通过上面的myfetch函数使用jsb.fileUtils.getStringFromFile轻松摘掉Util.fetch中的require(‘fs’)。

拿下protobuf.Builder.prototype[‘import’]

有人可能会纳闷,为什么import函数要这样定义?

protobuf.Builder.prototype[‘import’] = function() { … }

这是因为import是javascript中的关键字,不能定义一个名为import的函数,但可以为一个对象上定义一个import属性,在这里这个属性是一个函数。

由于import函数代码太长,以下修改只给出了关键修改,主要是屏蔽代码。

//由于import函数代码太长,以下修改只给出了关键修改,主要是屏蔽代码。
protobuf.Builder.prototype['import'] = function(json, filename) {
var delim = '/';
// Make sure to skip duplicate imports
if (typeof filename === 'string') {
//--------------毙了-----------
// if (ProtoBuf.Util.IS_NODE)
//     filename = require("path")['resolve'](filename);
//-----------------------------
if (this.files[filename] === true)
return this.reset();
this.files[filename] = true;
} else if (typeof filename === 'object') {
// Object with root, file.
var root = filename.root;
//--------------毙了-----------
// if (ProtoBuf.Util.IS_NODE)
//     root = require("path")['resolve'](root);
//--------------------------------------------
if (root.indexOf("\\") >= 0 || filename.file.indexOf("\\") >= 0)
delim = '\\';
//--------------毙了-----------
//var fname;
// if (ProtoBuf.Util.IS_NODE)
//     fname = require("path")['join'](root, filename.file);
// else
//----------------------------
var fname = root + delim + filename.file;
if (this.files[fname] === true)
return this.reset();
this.files[fname] = true;
}    // Import imports

if (json['imports'] && json['imports'].length > 0) {
...
for (var i=0; i<json['imports'].length; i++) {
if (typeof json['imports'][i] === 'string') { // Import file
if (!importRoot)
throw Error("cannot determine import root");
var importFilename = json['imports'][i];
if (importFilename === "google/protobuf/descriptor.proto")
continue; // Not needed and therefore not used
//--------------毙了-----------
// if (ProtoBuf.Util.IS_NODE)
//     importFilename = require("path")['join'](importRoot, importFilename);
// else
//-----------------------------
importFilename = importRoot + delim + importFilename;
if (this.files[importFilename] === true)
continue; // Already imported
...
} else // Import structure
...
}
if (resetRoot) // Reset import root override when all imports are done
this.importRoot = null;
}

// Import structures
if (json['package'])
this.define(json['package']);
if (json['syntax'])
propagateSyntax(json);
...
};


import函数又长又难看,耐着性子满以为把问题解决了,可运行起来时会发现新的错误:propagateSyntax函数没有定义。更气人的是它是protobufjs中的一个内部函数,没有放在任何对象之上,引不出来,没办法只能将propagateSyntax函数在当前上下文中再写一遍。

function propagateSyntax(parent) {
if (parent['messages']) {
parent['messages'].forEach(function(child) {
child["syntax"] = parent["syntax"];
propagateSyntax(child);
});
}

if (parent['enums']) {
parent['enums'].forEach(function(child) {
child["syntax"] = parent["syntax"];
});
}
}


还好,没再出现别的内部函数调用了,这下问题算是全部搞定了,终于我的程序可以运行起来了!

这段时间在学习如何带孩子,通过对protobufjs的几种解决方案对比看,我突然得出一些启发:

1. 修改源码好比是直接揍孩子,简单粗暴,但适应性差

2. 伪装是欺骗孩子,但随着孩子的成长,可能会失效

3. 动态修改函数,它是随时间或环境的变化,做出最正确的引导

耐心引导是最好的选择。

四、小结

简单小结一下,上面两个函数的修改操作还是有点小小差别

静态函数与原型函数

//修改静态函数
protobuf.Util.fetch = function myfetch(path, callbcak) {...}
//修改原型函数
protobuf.Builder.prototype['import'] = function(json, filename) {...}


需要注意protobuf.Util.fetch是静态函数,而import是Builder原型函数,相当于是修改的成员函数。

缓存函数指针

//保存原Util.fetch函数指针
let fetch = protobuf.Util.fetch;
//编写了一个myfetch函数,覆盖protobuf.Util.fetch变量
protobuf.Util.fetch = function myfetch(path, callbcak) {
...
//调用原始操作
fetch.call(this, path, callback);
}


有时候修改函数指针是为了做勾子监听或实现子类扩展,同时还要依赖原函数执行核心操作,这时就需要将原函数指针先保存起来。在适当的时机去调用,同时还要还原函数的this指针,所以要用函数的call方法,不能简单直接调用。

好了,以上就是今天的分享,希望能与Creator和大家一起叛逆成长。

欢迎关注「奎特尔星球」微信公众号,有代码、有教程、有视频、有故事,一起玩来玩吧!

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息