张小龙「跳一跳」都玩到 6000 多分，是时候掌握微信小游戏高级开发了
用微信扫描二维码分享至好友和朋友圈
用微信扫描二维码分享至好友和朋友圈
　　　　作者 | 凌华彬、王哲　　责编 | 徐威龙　　【CSDN 编者按】今天，在 2018 年度微信公开课 PRO 上，张小龙以 967 分和一句“今天没有发挥的很好，我最高纪录有 6000 多分”开启了微信的年度盛事。　　在现场，张小龙分享了前不久上线「跳一跳」的初心及其漂亮的数据。“这个游戏发布以后，其实它的效果有点超出我们的预期，我们自己开玩笑说，这个游戏突然变成了有史以来可能用户规模最大的一个游戏，因为它的 DAU（日活跃用户数）大概到了 1 点几亿”。　　　　为什么我们会说玩一个小游戏才是正经事？对我来说，它是一个很放松的方法，我也很期待这样一个小游戏，因为它简单到让你可以有一个面对自己，一个最个人的时刻。大家在微信上的时间，可能会有很多的消息要处理，朋友圈里有很多信息要你去点赞、评论，可能还有很多工作的信息也夹杂在里面。这个时候玩这样一个小游戏，反而是一个非常正经的事情。　　当然我们也期待有更多的小游戏能像跳一跳这样，跳一跳不是我们刻意做的游戏，它只是我们小游戏平台的一个实验，我们希望有更多的第三方游戏能够像跳一跳这个游戏一样得到用户的喜爱。　　　　基于张小龙对于高质量小游戏的召唤，我们已经分享过由 Cocos 两位专家凌华彬、王哲主笔撰写的「微信小游戏开发上手」和「小游戏文档解读」两篇文章，从框架到 API，从原理到使用都有覆盖，也聊到了市场展望和小游戏渠道特性等话题，相信大家对小游戏环境和开发都有比较深入的了解了。今天，将继续讨论一些相对进阶的话题：小游戏调试、资源管理、第三方库的移植，希望能够帮助所有有志于开发小游戏的开发者们早日“上分”。　　以下为正文：　　一、小游戏调试　　调试是游戏开发的必经阶段，一个好的调试环境和调试工具也会大大提升开发效率。不过在小游戏开发环境中，调试层面的体验还不够完美，下面就给大家介绍一下目前小游戏的调试环境以及如何更好得完成调试工作。　　微信开发者工具　　首先大家接触到最直接的调试工具就是微信开发者工具，这个工具集成了模拟器、代码编辑器、调试器。其中调试器使用的就是 Chrome Devtools，做过 HTML5 开发的一定不会陌生，是非常强大的运行时调试工具。代码编辑器可以帮助你在定位问题时修改代码，模拟器可以直接看到运行结果，所以已经是比较完整的一个调试工具了。　　　　虽然根本上是基于 Chrome 内核及其调试工具，不过微信开发者工具与浏览器调试环境有几大区别：　　开发者工具包含小游戏环境的微信 API，这些 API 在浏览器中不支持；　　开发者工具模拟了小游戏的加载，以 game.js 作为入口，而不是 HTML 文件；　　开发者工具提供了小游戏的各种配置与便捷的编译、预览。　　对于依赖 HTML5 游戏库或基础模块，在开发者工具中直接编写代码的开发者来说，这样的开发体验其实是足够的。不过很多开发者都会使用游戏引擎来开发游戏，可能会遇到问题。以 Cocos Creator 为例，开发者打包过程中引擎会将游戏代码压缩为单一文件，如果选择发布模式，还会进一步混淆并合并代码。这样就会导致调试过程中无法正确使用原始用户脚本进行调试，会加大调试的难度。　　Cocos Creator 引擎中避免此问题的办法就是在打包时生成 source map：　　　　构建面板中勾选 Source Maps 选项　　同时，还要注意，必须将微信开发者工具中的 ES6 转 ES5 选项给去掉，否则开发者工具会在原始脚本内容上多包一层闭包，你之前生成的 source map 也就失效了。　　　　详情页面中取消勾选 ES6 转 ES5 选项　　真机调试　　尽管开发者工具比较好用，但是我们必须面对它的一大问题，它的模拟器运行环境和微信小游戏的真机运行环境并不完全相同。在 API 层面，微信的开发者尽可能将他们做到了一致，但是模拟器依然是由浏览器来驱动的，而微信小游戏的真机环境是原生环境 + 绑定 API构成的，我们再回顾一下第一篇中的框架图。　　　　小游戏基础运行框架　　也就是说，有可能出现真机环境中的 Bug 在模拟器环境中无法重现的问题。　　上面这个消息不算是个好消息，然而还有个更糟糕的消息等着你：小游戏真机运行环境目前无法进行远程调试。　　。。。　　好了好了，别哭，其实也没那么糟糕，微信团队正在非常努力得解决这个问题，他们也希望尽快将远程调试功能带给大家。在此之前，其实还有一个 vConsole 可以用来输出 log 进行调试，所以也算是一点慰藉。好在真机环境中出现问题而模拟器没问题的情况比较少见，一般游戏逻辑不会引起类似的问题。如果大家真的遇到，可以尝试用 log 的方式定位，也可以反馈给你使用的引擎提供方，看看能不能帮助你解决问题。　　　　vConsole https://mp.weixin.qq.com/debug/wxagame/dev/tutorial/usability/debug.html?t=2018110　　　　使用游戏引擎调试　　在使用 HTML5 游戏引擎制作小游戏的过程中还有一个好处，就是可以先发布 HTML5 版本，在浏览器中调试游戏逻辑，然后再发布到小游戏环境中进行兼容性测试。当然，你可能需要在 HTML5 版本中隔离微信小游戏的 SDK 代码，以 Cocos Creator 为例，可以使用下面的判断代码：　　if (cc.sys.platform === cc.sys.WECHAT_GAME) { // wechat exclusive logic} 　　二、小游戏的资源管理　　除了前两篇中提到的 API 级别的差异以外，小游戏环境和浏览器环境的另一大差异就是资源管理了。　　资源加载　　首先是资源加载的差异，我们通过首场景加载的流程来展示这种差异：　　　　在浏览器中始终遵循按需加载的原则，执行到加载的标签或者脚本，才会去作出网络请求加载内容。而在小游戏中，会首先下载你提交的完整游戏包，再运行 game.js 来启动游戏。所谓完整游戏包，也就是开发者在微信开发者工具中所导入的资源，不管你是否需要这些资源，在玩家打开你的小游戏时，都会被完整下载。所以为了首场景加载的体验，我们应该尽可能减小自己的小游戏包体，将可以按需加载的资源，放在远程服务器上，用脚本进行加载。微信团队也考虑到了首场景加载体验，所以将小游戏包体限制在了 4mb。下面是具体的小游戏包体方面的限制：　　小游戏的包内体积不能够超过 4mb，包含所有代码和资源，额外的资源必须通过网络请求下载；　　对于小游戏包内资源，小游戏环境内并不是按需加载的，而是一次性加载所有包内资源，然后再启动页面；　　不可以从远程服务器下载脚本文件。　　基于这些限制，我们给出的建议就是，将所有引擎和游戏脚本，放在小游戏包内，同时可以将首场景资源或者预加载场景资源放在包内。其他资源都应该放在远程服务器上。　　缓存与更新机制　　资源管理上的第二点差异我们在第二篇文章中也提到过，对于从远程服务器下载的文件，小游戏环境没有浏览器的缓存以及过期更新机制。　　众所周知，浏览器对于用户已经访问过的资源，会进行缓存，再次访问时，会优先从缓存获取，而不是发送请求给服务端，这样可以尽可能减少网络使用，优化页面响应速度。微信小游戏环境所提供的接口则是更为基础的文件系统接口：　　wx.downloadFile：下载文件到缓存文件　　FileSystemManager.saveFile：保存缓存文件　　FileSystemManager.access：判断文件/目录是否存在　　FileSystemManager.readFile：读取本地文件内容　　FileSystemManager.unlink：删除文件　　基于以上接口来实现浏览器的缓存方案当然是可行的，但是对于普通开发者来说，太过于繁琐，所以我们为开发者提供了更完整的资源管理方案。　　Cocos Creator 的资源管理方案　　首先，微信内将小游戏的文件存储空间按照用户和游戏来划分。所有文件系统接口，都是在独立的文件沙盒环境中执行，所有的文件目录也是相对于沙盒环境的，所以不用担心不同小游戏或者不同用户之间的文件冲突。　　　　在这个沙盒环境之下，Cocos Creator 为小游戏环境提供了一个 wxDownloader 对象用来加载远程资源。当用户给它设置 REMOTE_SERVER_ROOT 属性后，资源的加载流程就变成了下面这样：　　检查资源是否在小游戏包内；　　不存在则查询本地缓存资源；　　如果没有缓存就从远程服务器下载；　　下载后保存到小游戏应用缓存内供再次访问时使用（按照资源相对路径保存）。　　只要用户保证 wxDownloader.REMOTE_SERVER_ROOT 路径下的资源相对路径与 Cocos Creator 发布的资源相对路径一致，那么再次访问同一个资源时，就会在小游戏的文件沙盒环境中找到对应的文件。这样就足够支撑游戏资源的加载和缓存需求了。　　那么我们如何做到资源的更新呢？假设服务端资源内容更新了，而 URL 没有变化，那么我们还是会优先使用缓存中的资源，岂不是就没有得到更新？的确如此，我们解决问题的思路，并不是从资源文件内容是否变化来判断，而是一旦内容变化就修改文件的 URL。这点就依赖于 Cocos Creator 打包时的 md5Cache 功能，这个功能会在打包时给所有资源文件的文件名附加 md5 后缀，比如 example.png 变成 example.23j8s1.png，一旦文件内容变化，它的 md5 后缀自然会发生变化。而所有资源文件的相对路径，实际上是在运行时由 AssetLibrary 从 settings.js 中解析出来的。　　　　在构建面板中勾选 MD5 Cache 选项　　所以开发者只要更新了新的小游戏包，包含最新版本的 settings.js，那么所有资源的路径就得到了更新，自然会从服务端请求最新版本的资源。由此还可引申出多版本共存的方案，就是不同版本的游戏，指向不同的 wxDownloader.REMOTE_SERVER_ROOT 服务器路径，可以保障不同版本都可以访问，并且不会出现资源的冲突或缺失。　　最后，如果想要在本地或非正式服务器上测试远程加载功能，需要在详情页面中勾选“不检验安全域名、TLS 版本以及 HTTPS 证书”。　　至此，Cocos Creator 对小游戏资源管理中，远程资源加载和更新就解释清楚了，虽然我们不希望用户感知到浏览器和小游戏环境的差异，不可否认的是，资源管理方面，用户仍然需要了解更多的细节，才能够更好保障自己的小游戏所带来的用户体验。　　三、第三方库的使用　　目前部分第三方库已经发现有很多不兼容小游戏环境了，这里可以分享一个判断原则，如果是纯 JS 库，那么是没问题的，但是如果第三方库使用到了 DOM API，多半是无法支持。举几个例子：　　lodash：纯 JS 库，可以放心使用。　　jQuery：此类对 DOM API 有强依赖的第三方库肯定是无法支持的，也无法通过适配来支持。　　SocketIO：支持，但是需要取消勾选 ES6 转 ES5 避免闭包的运行环境被改变，这点适用于很多 node module。　　protobuf.js：protobuf.js 已经被验证是会出现问题的，因为它包含了加载的逻辑，这部分逻辑需要适配到微信小游戏的 API 才可以使用。　　四、总结　　三篇系列文章到这里就正式完结了，感谢所有读者的耐心和关注。在 Cocos Creator 与微信官方团队合作正式支持小游戏之后，我们花费了不少的心血研究微信小游戏框架和环境，只为了对小游戏有兴趣的开发者能尽快上手，加入这个新兴游戏渠道的探索中去。当然，微信小游戏的未来还不明朗；开发者也还无法正式提交游戏；关于盈利方式的问题更是没有定论。不过这些都不影响微信平台的庞大用户量所蕴含的潜力，所以我们相信小游戏的未来还是非常值得期待的。　　从开发者角度来说，庞大的潜在用户和便捷的触达方式当然是极好的，但这并不是又一次洗用户的机会，我认为只有真正理解微信的用户，为微信的用户创作游戏，才有可能获得真正的爆发。　　从微信的角度来说，相信外界的期待让他们即欣喜又倍感压力，从谨慎得控制小游戏的发布步调中就能看出，我们期待未来能够开放更多的能力解放开发者的创造力，孕育出行业瞩目的游戏产品给广大微信用户。　　最后，作为引擎开发商的我们，只有进一步提升易用性、性能，降低开发门槛，努力成为开发者的另一大助力。在这里也预告一下 Cocos Creator 的下一步计划，目前 Cocos Creator 2.0 已经在很紧张的开发过程中了，我们彻底重构了渲染层，精简了引擎的内部框架，并且会在 2.x 阶段开放 Material System 接口。无论是性能还是渲染的能力上，都会再上一个台阶。我们非常期待被赋予新生的引擎能够帮助开发者开发出性能卓越、视效出众的全新游戏体验。　　One more thing —— 补遗：常见问题 Q & A　　小游戏的盈利方式是什么？有没有支付或者广告 SDK？　　目前官方文档中没有提供这两种 API，不过从已发布游戏的体验来看，支付未来肯定是会支持的，广告还没有见到。未来的进展，还需要开发者们持续关注微信官方的消息。　　小游戏中的资源是否安全？　　小游戏的脚本和资源都会保存在微信的文件沙盒环境中，常规的方式并无法获得其中的内容，所以相对来说比浏览器安全许多。此外，Cocos Creator 打包过程中，如果不勾选 debug 模式，会自动将 JS 脚本混淆，但是并不支持资源的加密。当然，并不是说沙盒环境永远不会被破解，这个世界上没有绝对的安全，不过开发者还是可以更多考虑从服务器的角度来加强安全性。　　如果实在需要加密，理论上纯 JS 实现的解密库是可以被用于微信小游戏环境的。Cocos Creator 的开发者也可以通过定制 wxDownloader 实现，完成资源的解密，不过这项功能目前引擎并没有覆盖。　　微信小游戏环境中还需要微信 JS-SDK 吗？　　微信小游戏环境包含完整的微信 API，不需要任何额外的 SDK 支持。　　开发者工具中提示 "未找到入口 app.json" 怎么办？　　目前微信公众平台并没有开放游戏类目的申请权限，所以大家只能通过微信开发者工具中体验小游戏的方式来测试小游戏运行环境（或者使用游客 appid：wx6ac3fc5）。同时，请保障开发者工具详情页面中选择的库版本是 game。　　至于微信何时会开放游戏类目的申请权限，目前官方的答复仍然是："尚未开放，敬请期待"　　开发者工具详情中找不到 "不检验安全域名、TLS 版本以及 HTTPS 证书" 选项怎么办？　　当使用体验小游戏的方式来测试时，在开发者工具详情页面中，会找不到“不检验安全域名、TLS 版本以及 HTTPS 证书”选项，这是开发者工具的 bug，我们已经反馈给微信团队，目前你可以在 project.config.json 中手动设置 urlCheck 为 false。　　　　作者简介：　　凌华彬，Cocos Creator 主程、Game Jamer、玩家，曾负责 Cocos2d-JS、热更新框架、JSB 框架，现在主要在负责小游戏发布流程、Cocos Creator 引擎新渲染器架构。　　王哲，Cocos 引擎创始人、首席客服。　　读完文章，欢迎给作者点赞，如果关于微信小游戏，你还有许多疑问，或者对于文章中有不能理解透彻之处，欢迎留言，作者会不定时溜达到这里进行解答。　　　　　　————— 推荐阅读 —————　　点击图片即可阅读　　　　　　　　
特别声明：本文为网易自媒体平台“网易号”作者上传并发布，仅代表该作者观点。网易仅提供信息发布平台。
阅读下一篇
网易通行证/邮箱用户可以直接登录：想开发微信小游戏，先看看腾讯是如何制定规则的
作者 | 凌华彬、王哲
责编 | 徐威龙
在第一篇文章《微信小游戏开发上手》中，我们给大家介绍了上手微信小游戏开发所需要的知识，以及小游戏的开发环境和工具。学会如何开发小游戏固然重要，但是更重要的是，什么样的游戏更适合小游戏环境和它的用户。
我们都知道小游戏是运行在微信内部的游戏环境中的，那么微信用户也就是小游戏的潜在用户，这些用户在使用微信时，会被什么样的游戏所吸引？会分享什么样的游戏？什么样的游戏能融入用户的社交过程？这些在今天都没有最佳的答案，开发者们都在探索，也正是广大小游戏开发者的机会所在。但毫无疑问的是，制作这样的爆款游戏一定需要完美理解各种微信社交/系统 SDK 接口的能力，并将其发挥到极致。
今天我们会更详细分析小游戏环境给大家开放的各种 SDK 接口，以及这些接口可以承载什么样的游戏体验。当然，微信小游戏官方文档中，对这些接口都有很详细的使用介绍，我们不会重复这些具体的 API 调用细节，会更多侧重在这些接口所提供的功能和潜力上。最后，我们还会给出一个 Cocos Creator 制作小游戏的案例。
注：小游戏官方文档地址：https://mp.weixin.qq.com/debug/wxagame/dev/document/render/canvas/Canvas.html?t=201816
二、小游戏提供的接口能力
微信 SDK 接口通用规则
微信的 SDK 接口大多有非常接近的使用方式和命名规则，下面是我们总结出来的一些经验：
onXXX & offXXX：这类 API 一般都是的事件注册和反注册；
xxxSync：在某个函数名后添加 Sync 就是该函数的同步方法，同时也说明原始函数一定是异步调用；
异步函数：由于微信很多 API 都需要做后台请求，或从微信运行内核中获取信息，所以存在大量的异步接口，有时会提供它们的同步版本，但在大多数情况下我们仍然建议使用异步接口，以便更方便得捕获异常，组织异常处理代码；
异步函数的调用方式：微信 API 内的异步函数绝大多数都接受一个对象作为参数，该对象内应该包含：success：成功回调fail：失败回调complete：完成回调（调用成功、失败都会执行）
wx.getSystemInfo({
success: function(res) {
// res 一般是一个包含调用结果的对象
console.log('This phone is '+ res.brand + ' '+ res.model);
fail: function(res) {
// 通过 res.errMsg 可以获取错误信息
console.warn(res.errMsg);
complete: function() {
console.log('API call completed');
getXXX & setXXX：获取和设置接口，比较反常理的是，很多这样的接口也是异步的，需要仔细阅读 API 文档。
接下来我们来看具体的接口，先看大家最关注的三大接口：用户、转发和支付接口。
用户接口方面，开发者最应该关注的就是用户的登录了，登录接口的使用示例如下：
wx.login({
success: function(res) {
// res.code 为用户的登录凭证
if(res.code) {
// 游戏服务器处理用户登录
// 失败处理
console.log('获取用户登录态失败！'+ res.errMsg);
fail: function(res) {
// 失败处理
console.log('用户登录失败！'+ res.errMsg);
按前文所说，要做到好的用户体验，所有异步接口的 fail 都应该被处理，Login 更是如此，如果 Login 失败，游戏很难进行下去，除非是纯单机游戏。至于失败的处理，我们建议重新尝试，或者引导用户关闭小游戏再次尝试。
回调接口中的res.code是用户的登录凭证，通过它可以在开发者服务器后台换取 openid 和 session_key 等信息，部分 API 可能包含用户的敏感数据，这些敏感数据需要传递 session_key 才可以获取，否则只能获得很有限的基本数据。具体信息请参考用户登录态签名文档，目前需要登录态签名来获取敏感数据的 API 为：
用户登录态签名文档：https://mp.weixin.qq.com/debug/wxagame/dev/tutorial/open-ability/http-signature.html
wx.getUserInfo：获取用户信息，链接：https://mp.weixin.qq.com/debug/wxagame/dev/document/open-api/user-info/wx.getUserInfo.html
wx.getShareInfo：获取转发详细信息，链接：https://mp.weixin.qq.com/debug/wxagame/dev/document/share/wx.getShareInfo.html
wx.getWeRunData：获取微信运动信息，链接：https://mp.weixin.qq.com/debug/wxagame/dev/document/open-api/werun/wx.getWeRunData.html
除此之外，部分 API 调用需要用户的授权方能使用，如果没有申请过授权，第一次调用时会自动申请，流程如下：
也可以在调用 API 之前做预授权：
授权的详细范例和需要授权的 API 列表请参考微信官方文档中的用户授权章节，地址：https://mp.weixin.qq.com/debug/wxagame/dev/tutorial/open-ability/authorize.html。
在第一篇文章中，我们提到小游戏最大的开创性能力，可能就是从转发入口点击直接进入游戏的超快捷体验。从技术角度来说，小游戏中的转发分为被动转发和主动转发（主被动是针对游戏开发者来说）：
使用 wx.showShareMenu 在右上角 ”…” 按钮的弹出菜单中显示转发选项，这样用户游戏中的任何时候，都可以发起转发。可以通过 wx.hideShareMenu 来去掉转发选项。
wx.showShareMenu：https://mp.weixin.qq.com/debug/wxagame/dev/document/share/wx.showShareMenu.html
wx.hideShareMenu：https://mp.weixin.qq.com/debug/wxagame/dev/document/share/wx.hideShareMenu.html
wx.onShareAppMessage：https://mp.weixin.qq.com/debug/wxagame/dev/document/share/wx.onShareAppMessage.html
同时，开发者可以监听 wx.onShareAppMessage 来监听用户转发行为，并准备适宜的转发内容。具体来说开发者可以在回调函数的返回值中定制转发内容：
1. title：标题，不传则默认使用当前小游戏的昵称；
2. imageUrl：转发显示图片的链接；
3. query：游戏参数，遵循 key1=val1&key2=val2 格式的查询字符串，从这条转发消息进入后，可通过 wx.onLaunch 或 wx.onShow 获取这些启动参数。
用户点击右上角菜单按钮发起转发
所谓主动转发是指开发者在游戏交互中主动替用户发起转发请求，一般是玩家在游戏中点击某个分享按钮后，开发者通过调用 wx.shareAppMessage 直接调起转发窗口。
wx.shareAppMessage：https://mp.weixin.qq.com/debug/wxagame/dev/document/share/wx.shareAppMessage.html
用户点击按钮自动调起转发页面
开发者还可以为所有的转发设置 withShareTicket 模式，这种模式下，开发者在转发和用户通过转发链接进入游戏时，都可以获取一个 shareTicket。将 shareTicket 传入 wx.getShareInfo，可在回调中解密数据来获取分享的群 id。关于数据解密请参考加密解密算法文档，地址：https://mp.weixin.qq.com/debug/wxagame/dev/tutorial/open-ability/signature.html。
在小游戏 API 文档中并没有支付相关的 API，不过目前从安卓已上线的小游戏来看，已经有支付的体验了。至于未来何时会开放给所有开发者，还请期待微信官方的消息。
网络接口分为三个部分：网络请求，WebSocket，上传下载。
网络请求网络请求的 API 是 wx.request，这个接口可以理解为浏览器中的 ，实际上 Adapter 中的 XHR 对象也正是用它来封装的。它可以用来发出网络请求，获取远程服务器返回的数据。值得一提的是，这份数据是存储在内存中的，用户可以直接使用，不涉及到任何文件 IO 操作。
WebSocketWebSocket 相关接口的使用方式可以参考 API 文档，虽然接口定义和浏览器中并不相同，不过 Adapter 再次基于微信基础 API 提供了等同于浏览器接口的封装，所以我们建议大家不需要根据微信基础 API 进行适配，直接引入 Adapter 脚本，省去适配的烦恼。当然，如果游戏中的网络请求遇到奇怪的问题，你可能需要通过原始 API 进行调试和定位。
上传下载微信还提供了浏览器中所没有的直接上传（wx.uploadFile）和下载（wx.downloadFile） API。对于游戏开发来说，我们需要重点关注的是下载 API。首先它和 request 的用途不同，request 用来请求多种形式的数据，包括字符串、文件数据、ArrayBuffer、json 对象，所以适合用来做短链接请求，调用服务器 Restful API，而 wx.downloadFile 则是用来直接下载文件到本地的。如果在调用参数对象中指定 filePath，那么下载下来的文件会被存储到小游戏的本地缓存空间，否则下载下来的文件会被存储在临时空间，退出小游戏时就会被删除，这取决于你是否需要长期保留这个文件。不过需要注意的是，如果 filePath 带有相对路径，而本地缓存中不存在这个路径，会下载失败，这个需求就要配合文件系统 API 才能满足了。
wx.request：https://mp.weixin.qq.com/debug/wxagame/dev/document/network/request/wx.request.html
API 文档：https://mp.weixin.qq.com/debug/wxagame/dev/document/network/websocket/wx.connectSocket.html
wx.uploadFile：https://mp.weixin.qq.com/debug/wxagame/dev/document/network/upload/wx.uploadFile.html
wx.downloadFile：https://mp.weixin.qq.com/debug/wxagame/dev/document/network/download/wx.downloadFile.html
小游戏给开发者开放了很完整的文件系统接口，这点和浏览器中不支持文件 IO 的情况完全不同。一方面这给了开发者更大的自由度和发挥空间，但另一方面，这也是目前微信小游戏环境所必要的 API，因为微信小游戏环境不支持类似浏览器的资源缓存和资源过期机制。
具体来说，浏览器对于用户已经访问过的资源，会进行缓存，再次访问时，会优先从缓存获取，而不是发送请求给服务端，这样可以尽可能减少网络使用，优化页面响应速度。当服务端资源更新时，浏览器会发现本地资源已过期，自动清除对应本地资源并从服务端获取最新版本。
而在小游戏环境中，如果想要避免每次都从服务端获取资源，就需要自己实现一套类似的资源缓存和过期方案，这样的方案就不得不依赖于上面的下载接口以及文件系统接口。好消息是，Cocos Creator 提供了一套完整的资源管理方案，我们会在下一篇分享中详细讨论。
要理解小游戏的文件系统，首先要理解小游戏的文件沙盒环境：
所有的文件系统接口，都是在这个文件沙盒环境中执行的，所有的文件目录也是相对于沙盒环境的，所以我们不用担心不同小游戏或者不同用户之间的文件冲突。
从 API 使用的角度来说，所有文件系统接口都是由 FileSystemManager 来提供的，开发者需要首先通过：
FileSystemManager：https://mp.weixin.qq.com/debug/wxagame/dev/document/file/FileSystemManager.html?t=201818
letfs = wx.getFileSystemManager();
来获取 FileSystemManager 对象，然后调用它的 API 来完成需要的功能，下面通过下载、读取、删除文件流程展示 API 的用法：
以上只是最基本的一些接口使用。除此之外，微信小游戏还提供了 renameFile、copyFile、readdir、writeFile 等，大家可以参考 API 文档自行探索。细心的开发者还会注意到这些接口大多包含同步版本，比如 fs.readFileSync，我们建议一律使用异步版本的接口，否则文件 IO 造成的阻塞会影响到游戏运行的流畅度和游玩体验，相比之下，显然编写异步代码这点麻烦还是可以承受的。
除了以上这些接口以外，还有很多接口对于特定游戏类型非常重要，下面列举一些例子：
wx.getSystemInfo：获取系统信息，包含手机品牌、型号、屏幕宽高、语言、版本、电量等信息；
wx.onAccelerometerChange：监听加速计事件，可用于部分游戏的操控输入；
wx.setKeepScreenOn：保持屏幕常亮，挂机游戏可能需要 ? ；
wx.vibrateShort：15ms 短震动，也存在长震动接口，可以用来增强游戏体验，比如辅助模拟吴彦祖给玩家打电话 ? ；
wx.getLocation：获取地理位置、速度等，LBS 功能必备；
键盘接口：包含显示/隐藏键盘，以及各种键盘输入监听器接口，可以用来制作游戏中的输入框，Cocos Creator 中已经封装到 EditBox 组件中，使用方式与浏览器环境无异；
wx.getRecorderManager：获取录音管理器，可以用来录入玩家语音；
图片接口：用来从用户相册中选择图片，或保存图片到用户相册；
wx.createVideo：创建视频，提供视频播放和视频控制接口；
wx.triggerGC：如果游戏中频繁创建和销毁 WebGL 贴图，或内存使用过高，需要在适当时机调用此接口来触发 GC，降低游戏内存使用。
三、从接口能力思考小游戏的机会
虽然接口的分析讲完了，但是从上一篇的反馈来看，恐怕大家还是不能满意的：
微信小游戏开发上手的文末评论
看来大家最关心的是，小游戏该如何为自己赚钱？虽然被吐槽，不过至少大家的胃口被吊起来了，那么究竟这个问题的答案是什么呢？
其实这个问题答案就是没有答案～这也是最好的答案。
为什么这么说呢？试想一个已经有成熟商业模式的游戏平台，普通开发者再入局还有机会吗？今天微信平台的小游戏还没有被大家摸透，意味着开发者的资源水平还没有成为决定性的因素。所以今天入局的开发者仍然在同一条起跑线上，都有机会摸到小游戏玩家的甜区（Sweet Point）。
虽然没有答案，不过我们还是可以尝试回答几个与此相关的问题，希望抛砖引玉。
小游戏和其他游戏渠道的区别是什么？小游戏最大的两大特性，就是依托于微信，以及即点即玩。第一篇文章我列举了小游戏的五大入口：1. 群或好友分享3. 微信聊天列表页面下拉后出现最近玩过的小游戏4. 发现 - 小程序5. 发现 - 游戏 - 我的小游戏可以说，在微信内部小游戏有很多曝光的机会，这种曝光并不是靠推送的方式，而是用户的主动发现、分享。这应该也是微信在做小程序/小游戏的重要思路：不干扰用户，但鼓励用户之间的分享，也让用户在需要的时候很轻松得找到自己需要的内容。这与传统的用户从 App Store 或某些渠道中找到游戏并下载／体验的方式有很大区别。即点即玩是小游戏继承自 HTML5 游戏的体验，我们在已发布的游戏中看到了很多点击分享链接直接进入游戏的无缝体验。这会很大程度上改变小游戏的设计，尤其是对战、挑战、组队等玩法，下面是欢乐坦克大战的组队界面，随时可以从微信中邀请好友：
小游戏的受众人群有什么特点？对于其他渠道来说，玩家在寻找一款游戏时，首先你可以确定他是一个玩家。但在微信小游戏环境下，这个假设不成立。你可以假定，通过分享链接进入你的游戏的可能是完全没有玩过游戏的，比如开发者自己的父母或第一次使用手机的孩子。微信所带来的流量潜能固然是非常可观的，但如果只考虑游戏用户，在很大程度上转化的效率会变得低下。这点对于游戏设计的挑战非常大，如果只是分享游戏的主入口，用户进入之后可以先通过教学还可以接受。但如果你想要设计对战、挑战这种直接进入游戏某一个关卡或功能模块的体验，就需要好好思考新手的上手门槛了。总体来说，你的游戏体验越直观，就越容易将微信用户转化为你的玩家。
小游戏的传播、交互有什么特点？在开发小游戏时，大家应该时刻铭记在心的是，微信是一个私密社交圈，这和 微博 / Facebook / Twitter 是有本质区别的。首先，你无法通过分享 API 分享到朋友圈，所以，广播式的分享不可行。不过，你可以分享给好友或是群，也可以重复分享，这是一种点对点的分享模式。其次，微信中真正的爆发式传播是通过关系网辐射式传播的，所以如果想要最大限度利用关系网，通过游戏乐趣促使玩家之间持续分享是成功的关键。交互上来说，玩家在玩小游戏时，一定是非常碎片化的，这也体现在目前的小游戏中，大多数小游戏都是以关卡或局为单位，方便用户随时跳出和再进入，这种碎片化的程度甚至超过普通 HTML5 游戏。碎片化也不止于时间，还影响到游戏体验，比如玩家有可能在玩某一个关卡，收到了一个好友的挑战分享，打开分享链接后，需要重置玩家的游戏关卡到挑战关卡中。这种非线性的体验，并不是开发者所可以控制的，相反，我们认为这正是小游戏开发者应该在游戏设计中拥抱的。
小游戏适合什么样的品类？相信看了以上这些分析，开发者们都会有自己的想法，虽然目前小游戏中还都是休闲和棋牌类游戏，但是我们相信小游戏的未来还是充满了丰富的可能性。只要顺势而为，这里的势指的是微信作为私密社交圈的产品思路以及微信用户的使用习惯，一定能够充分发挥微信庞大用户基数的潜能。
四、实例：用 Cocos Creator 制作第一个小游戏
长篇大论了这么久，可能大家又要吐槽太抽象了，一点实践都没有。那么我们就来分享一个小游戏案例，前一篇也提到游戏引擎对于微信小游戏开发所能提供的强有力支持，作为 Cocos Creator 的核心开发人员，自然要给大家安利一下如何使用 Cocos Creator 制作一款小游戏（【编者注】@两位大佬，出门右转，交下广告费）。
第一步自然是去 www.cocos.com 官网下载最新版本的 Cocos Creator，从 1.8 版本开始，我们正式支持发布小游戏。
安装完成后，打开 Cocos Creator 会开启 Dashboard 面板，选择新建项目，再选择 Hello World 项目模版，设置好项目路径就可以点击 “新建项目” 创建了。
打开项目后，可以打开 “Scene/helloworld” 场景，感兴趣的话也可以随意进行一些修改。
从菜单栏找到 “Cocos Creator & 偏好设置” 选项并打开，点击 “原生开发环境” 设置，在 WechatGame 程序路径中设置微信开发者工具的安装路径，最后点击 “保存并关闭”。
从菜单栏中找到 “项目 & 构建发布…” 选项并打开，在构建发布面板中，选择发布平台为 Wechat Game，设置设备方向、appid、调试模式等，最后点击构建。（目前微信尚未开放游戏类目，大家无法获取到小游戏 appid，不过暂时可以使用游客 appid：wx6ac3fc5）。
当构建发布面板上方的进度条走完，并显示 sleep，则表示构建完成，此时直接点击运行即可自动调起微信开发者工具，并显示正确的场景效果。（如果没有自动打开微信开发者工具，或者没有自动打开游戏项目，你可以用微信开发者工具在项目路径下的 build/wechatgame 作为项目目录创建小游戏体验项目）。
这样就算是完成了小游戏的发布，当然，使用 Cocos Creator 制作游戏的知识这里无法覆盖，还请移步官网文档：http://docs.cocos.com/creator/manual/zh/。
系列文章的第二篇给各位总结了小游戏提供的微信 API 能力，以及如何利用这些能力。也从我们的理解角度分析了微信小游戏环境的独特性，希望能够抛砖引玉，激发开发者的想象力，找到最适合微信平台的游戏设计。
作者简介：
凌华彬，Cocos Creator 主程、Game Jamer、玩家，曾负责 Cocos2d-JS、热更新框架、JSB 框架，现在主要在负责小游戏发布流程、Cocos Creator 引擎新渲染器架构。
王哲，Cocos 引擎创始人、首席客服。
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
今日搜狐热点}