- 主进程

王哲 - 创始人

本文是微信小游戏开发系列文章的第三篇。前两篇文章涵盖了从框架到API，从原理到使用的方方面面，还讨论了市场前景、小游戏渠道特点等话题。对小游戏环境和开发有比较深入的了解。在上一篇文章中，我们将进入一些高级主题：小游戏调试、资源管理和第三方库的移植。

第一。小游戏调试

调试是游戏开发的必要阶段，一个好的调试环境和调试工具会大大提高开发效率。但是在小游戏开发环境中，调试层面的体验并不完美。介绍一下目前小游戏的调试环境，以及如何更好的完成调试工作。

微信开发者工具

首先大家接触到的最直接的调试工具就是微信开发者工具，它集模拟器、代码编辑器、调试器于一体。其中，调试器使用 ，做过开发的人一定不会陌生。它是一个非常强大的运行时调试工具。代码编辑器可以在定位问题的时候帮你修改代码，模拟器可以直接看到运行结果，已经是比较完善的调试工具了。

虽然基本是基于内核及其调试工具的，但是微信开发者工具和浏览器调试环境还是有几个区别的：

对于依赖游戏库或者基础模块，直接在开发者工具中编写代码的开发者来说，这样的开发经验其实已经足够了。但是，很多开发者使用游戏引擎来开发游戏，可能会遇到问题。例如，在开发者打包过程中，引擎会将游戏代码压缩成单个文件，如果选择发布模式，则会对代码进行进一步的混淆和合并。这样在调试过程中就无法正确使用原用户脚本进行调试，会增加调试难度。

在引擎中避免这个问题的方法是在打包的时候生成地图：

检查构建面板中的地图选项

同时还要注意，微信开发者工具中的ES6 to ES5选项一定要去掉，否则开发者工具会在原脚本内容和之前生成的图上再包一层闭包将无效。 .

在详情页取消选中 ES6 to ES5 选项

真机调试

虽然开发者工具比较好用，但我们还是要面对一个大问题。它的模拟器运行环境与微信小游戏的真机运行环境并不完全相同。在API层面，微信的开发者尽量让它们保持一致，但是模拟器还是浏览器驱动，微信小游戏的真机环境是由原生环境+绑定API组成的，我们来再复习第一篇的框架图。

小游戏的基本运行框架

也就是说，可能存在真机环境中的bug在模拟器环境中无法重现的问题。

以上消息不是好消息，但还有更坏的消息等着你：小游戏的真机运行环境目前无法进行远程调试。

。 . .

好了好了，别哭了，其实没那么糟糕，微信团队正在努力解决这个问题，也希望能尽快把远程调试功能带给大家。在此之前，其实还有一个可以用来输出log进行调试的，所以也算是一点安慰。好在真机环境下很少出现问题但模拟器没问题，一般的游戏逻辑不会出现类似问题。如果你真的遇到了，可以尝试通过日志定位，也可以反馈给你使用的引擎提供商，看看能不能帮你解决问题。

使用游戏引擎进行调试

使用游戏引擎制作小游戏还有一个好处，就是可以先发布版本，在浏览器中调试游戏逻辑，再发布到小游戏环境进行兼容性测试。当然，您可能需要在版本中隔离微信小游戏的SDK代码。例如可以使用如下判断代码：

if (cc.sys.platform === cc.sys.WECHAT_GAME) { // wechat exclusive logic }

第二。小游戏的资源管理

除了前两篇文章提到的API级别差异，小游戏环境和浏览器环境的另一个主要区别是资源管理。

资源加载

首先是资源加载的不同。我们通过第一个场景加载过程来展示这种差异：

在浏览器中始终遵循按需加载的原则，只有在加载的标签或脚本被执行后，才会发出网络请求来加载内容。在小游戏中，会先下载你提交的完整游戏包，然后运行game.js启动游戏。所谓完整的游戏包，是指开发者在微信开发者工具中导入的资源。不管你是否需要这些资源，当玩家打开你的小游戏时，它都会被完全下载。所以，为了体验第一个场景的加载，我们应该尽量减少自己的小游戏包，把可以按需加载的资源放在远程服务器上，用脚本来加载。微信团队也考虑到了第一场景的加载体验，所以小游戏包被限制在4mb以内。以下是具体的小游戏包限制：

基于这些限制，我们的建议是把所有的引擎和游戏脚本放在小游戏包里，把第一个场景资源或者预加载的场景资源放在包里。所有其他资源都应该放在远程服务器上。

缓存和更新机制

第二篇文章中也提到了资源管理的第二个区别。对于从远程服务器下载的文件，小游戏环境中没有浏览器缓存和过期更新机制。

众所周知，浏览器会缓存用户已经访问过的资源。再次访问时，会优先从缓存中获取，而不是向服务器发送请求，这样可以尽可能减少网络使用量微信小程序开发工具下载官网，优化页面响应速度。微信小游戏环境提供的接口是比较基础的文件系统接口：

基于以上接口实现浏览器缓存方案当然是可行的，但是对于普通开发者来说过于繁琐，所以我们为开发者提供了更完善的资源管理方案。

资源管理解决方案

首先，微信根据用户和游戏划分小游戏的文件存储空间。所有文件系统接口都在独立的文件沙盒环境中执行，所有文件目录也都是相对于沙盒环境的，不用担心不同小游戏或不同用户之间的文件冲突。

在这个沙盒环境中，为小游戏环境提供了一个对象来加载远程资源。当用户给它设置属性时，资源加载过程如下：

检查该资源是否在小游戏包中不存在，然后查询本地缓存资源。如果没有缓存，则从远程服务器下载并保存到小游戏应用缓存中，以备再次访问时使用（根据资源的相对路径保存）

只要用户确保 . path 与发布资源的相对路径相同，那么当再次访问相同的资源时，会在小游戏的文件沙盒环境中找到对应的文件。这足以支持游戏资源的加载和缓存需求。

那么我们如何更新资源呢？假设服务器上资源的内容更新了，但是url没有改变，那么我们还是会先使用缓存中的资源，这样就不会获取到更新了？确实，我们解决问题的思路不是判断资源文件的内容是否发生变化，而是一旦内容发生变化就修改文件的url。这取决于包装的功能。该函数会在打包时给所有资源文件的文件名附加md5后缀。例如，.png 变为 ..png。一旦文件内容发生变化，其md5后缀自然会发生变化。所有资源文件的相对路径实际上都是在运行时从.js中解析出来的。

检查构建面板中的 MD5 选项

所以只要开发者更新新的小游戏包，包括最新版本的.js，所有资源的路径都会更新，自然会向服务器请求最新版本的资源。由此，也可以推广到多版本共存的方案，即不同版本的游戏指向不同的.路径，这样可以保证不同版本都可以访问，不会出现冲突或缺失资源。

最后，如果你想在本地或非正式服务器上测试远程加载功能，你需要在详情页中勾选“不验证安全域名、TLS版本和证书”。

至此，在小游戏的资源管理中，远程资源加载和更新已经解释清楚了。虽然我们不希望用户感知浏览器和小游戏环境的区别，但不可否认的是，在资源管理方面，用户还是需要了解更多的细节，才能更好的保证自己的小游戏带来的用户体验.

第三。使用第三方库

目前一些第三方库发现存在很多不兼容的小游戏环境。这里可以分享一个判断原则。如果是纯 JS 库，那是没有问题的，但是如果第三方库使用 DOM API，大部分是不支持的。几个例子：

：纯JS库，可以放心使用。 : 这种对DOM API依赖强的第三方库肯定是不支持的，也不能通过适配来支持。 : 支持，但需要取消选中 ES6 到 ES5 以避免更改闭包的运行时环境，这适用于许多节点。 .js：如果.js已经过验证，会有问题，因为它包含加载逻辑，需要适配微信小游戏的API才能使用。

第四。总结

本系列三篇文章到此正式结束，感谢各位读者的耐心和关注。在与官方微信团队合作正式支持小游戏后，我们花了很多精力研究微信小游戏的框架和环境，让对小游戏感兴趣的开发者能够尽快上手，加入小游戏。探索这个新兴的游戏渠道。 当然，微信小游戏的未来还不明朗；开发者无法正式提交游戏；而如何赚钱的问题仍然没有定论。不过这些并不影响微信平台庞大的用户群所蕴含的潜力，所以我们相信小游戏的未来还是非常值得期待的。

从开发者的角度来看，巨大的潜在用户和便捷的接入方式当然是极好的，但这不是又一次洗用户的机会。我想只有真正懂微信的用户才是微信用户。只有创造游戏，才有可能得到真正的爆发。

站在微信的角度，相信外界的期待让他们既开心又压力。从对小游戏发布节奏的精心把控中可以看出，我们期待在未来开放更多的能力来解放开发者。行业的创造力孕育了游戏产品，吸引了广大微信用户的行业关注。

最后，作为引擎开发者，我们只能进一步提升易用性和性能，降低开发门槛，力争成为开发者的又一大助力。这里也是下一步的预览。目前，2.0 已经处于非常紧张的开发过程中。我们已经彻底重构了渲染层，简化了引擎的内部框架，并将在 2. x- 开放接口。无论是性能还是渲染能力，都会更上一层楼。我们非常期待新引擎能够帮助开发者开发具有出色性能和出色视觉效果的新游戏体验。

附录：常见问题问答