当creator遇上protobufjs—叛逆

我们之前讲过要在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. 曙光

不好意思，明天继续