我们之前讲过要在Creator原生环境下使用protobufjs,使用伪装者的方式模拟nodejs的fs和path模块可以完美解决问题。
但随着creator1.7的到来,Shawn也尝了下鲜,但发现在Creator模拟器环境下,原来的伪装方案失效了。
追踪这个问题,不得不称赞下Creator1.7提供的新的底层引擎,在调试上ios/mac平台使用safari,android/windows使用chrome。
在模拟器上调试require函数中找到一些线索
上图中,从已经加载的模块文件中没有找fs模块,心拔凉拔凉的,继续追查原因。
注意fs的值为2
在数组中2号元素的文件名为empty.js,并不是我们的fs文件,找到原因了。
从上面调试看出,Creator模拟器将fs\path模块认为是nodejs模块,没有按普通模块进行加载。
二、一波三折伪装的fs\path模块只是不能在Creator1.7的模拟器上运行,在浏览器、自编译的MacApp、ios、android上都能正常运行。但Creator模拟器是平时开发调试的利器,不能运行protobufjs会影响日常的开发效率,也会影响pbkiller的用户,决对不能马虎了事。
1. 明灯
发现问题的第一时间,火速向Creator引擎组的大大汇报了此问题,Jare建议使用cc.loader.loadRes函数抹平不同平台上的文件加载问题,当时眼前一亮,猛拍一下自己的脑袋,我以前怎么没想到这个办法?
不论是web\ios\android所有平台的文件加载都可以用cc.loader.loadRes搞定,比protobufjs中实现的fetch都简单多了,cc.loader.loadRes为我提供了一盏明灯。
2. 熄灭
马上开始动手,刚一动手时,就想到决对不能修改protobufjs的源码,因为有些人是用npm来管理的protobufjs,不能让pbkiller的用户去修改node_moduls吧,这样太low了!
脑子飞快地运转起来,一束光在一片神经网络的触突上闪耀,电光石火的一瞬间,找到了一个方案:动态修改函数
let protobuf = require('protobufjs');
protobuf.Util.fetch = function myfetch(path, callbcak) {
cc.loader.loadRes(path, (error, data) => {
if (!error) {
callback(data);
}
)
};
正在得意之时,突然之间脑子里翁的一声,有问题?如果这样去实现protobufjs的fetch函数,只能是异步加载,而我之前提供的pbkiller的演示范例全是同步方式,决对不能这样坑了pbkiller的用户呀。
“哎呦!好痛,那个打我”
“你看下好多时间了,还不睡觉,明天要上班哈!”
“谢谢老婆关心,马上去睡觉”
3. 曙光
不好意思,明天继续
欢迎关注「奎特尔星球」微信公众号,有代码、有教程、有视频、有故事,一起玩来玩吧!