一次移植 GBA 模拟器到微信小游戏的血泪史

前言

• 近期任天堂直面会发布了要重制塞尔达梦见岛的消息，勾起了我想在 GBA 上玩通关梦见岛的兴趣。于是在手机上下载了几款 GBA 模拟器，发现都不太好用（主要是摇杆很反人类）
• 既然 GBA 模拟器这么难用，于是就在 GitHub 上搜有没有开源的，倒是找到了一个名为 gba4ios 的项目，但一看时间已经几年没维护了，估计对 iPhoneX 的分辨率支持也不够好，遂放弃（自我猜测）。
• 在搜的过程中，发现了一款 js 实现的 GBA 模拟器（ gbajs ），遂在线试用了一下，发现电脑手机上都没有性能问题，很流畅，于是就萌生了把 GBA 模拟器移植到微信小游戏上的想法。

开始动手

• 由于之前有过小游戏开发经验，也做过 js 游戏引擎相关的开发，还是蛮相信自己能搞定的。下载了代码，作者也没写注释，只能硬着头皮猜，核心部分就是用 js 模拟了 GBA 的 32 位 CPU，GBA 解包等等这些无关语言和环境的东西，只有最后拿到 ImageData 才涉及到渲染层，看上去还挺简单，要改的东西不多。

• 于是自己花了一两个小时，把涉及到 DOM 和 BOM 都改了，渲染全部由小游戏 canvas 接管，解决了一系列 BUG 后，终于能在模拟器上看到画面了。内心很激动，感觉要成了！

噩梦开始

• 在模拟器出画面后，用真机调试，发现真机啥画面都没有，于是开始了 debug 之路，非常漫长，由于不知道是平台原因还是小游戏 API 不完善的原因，完全一行一行的 debug，一两个小时后，终于找到原因所在，一个 callback 导致的画面黑屏（为什么 Web 和模拟器都行，就是真机不行，小游戏&小程序的模拟器不靠谱啊）

• 搞定了上一个问题，更是兴奋，感觉离成功不远了，真机上跑了一下，怎么感觉 fps 有点低呢？ drawcall 只有 2，但 fps 一直上不了 20，稳定在 12-15 左右，变成了幻灯片。用模拟器看了一下，模拟器能跑满 60fps，于是我就在想，会不会是渲染效率的原因，于是又开始了漫长的 debug。这次先找渲染层，也是一行行代码的测，因为不确定小游戏的引擎有哪些未知 BUG，所以这样来测比较细，也不会遗漏什么。这一测，就是 3 个多小时，还是完全没有头绪，各种方式都试遍了，依然保持 12fps。

• 本着不改好 bug 不睡觉的原则，继续刚，终于让我发现了问题所在。在 pc 端和手机浏览器上，能跑满 60fps，但小游戏不行，问题出在模拟 cpu 的核心代码上，用虚拟的 cpu 去运行 GBA 的 rom，pc 和手机浏览器只需要几 ms 的时间就能解析出一帧的画面，而到了小游戏里，则需要 80 多 ms，1000ms/80ms 约等于 12 左右，刚好解释了为什么 fps 在 12 左右波动。完全占据了 90%的性能开销。很奇怪为什么会开销这么大，这部分代码也没用到 polyfill，于是脑瓜更疼了。思来想去，于是想到，会不会是 ios 上小程序的 js 引擎并非系统的 js 引擎，而是自己实现了一套（突然想到了腾讯有自己的 x5 内核，会不会也有自己的"x5js"）？带着疑问搜索了一圈，果真搜到了一篇文章，介绍了小程序的 js 引擎，是苹果的 JSC 引擎？ WTF ？ JSC 不是 Safari 的引擎吗？我明明用 Safari 试过没问题才准备移植的，带着疑问又上路搜关于 JSC 的资料，可算找到一个稍微靠谱的解释。

• 原来在 Safari 里，JSC 是带有 JIT 的，UIWebview 不带 JIT，也没有 Safari 那么好的优化，但具体是哪部分没有优化好，我继续在代码里找。由于小程序开发工具运行流畅，不好 debug，于是只有用真机打 log 看运行时间，又是花费一两个小时时间，终于找到了，原来是 ARM 的 STM 指令耗时，90%的时间都消耗在 STM 上了，由于鄙人能力有限，对计算机底层不太熟悉，到这一步就放弃了

结语

• 白折腾了一个通宵，顿感失落，不知道是自己能力有限，还是平台所限，虽然不是什么正经的大项目，但是自己已经很久没有出于个人兴趣搞一些工作之外的开发了。发出此文的目的除了吐槽自己在开发小游戏过程中的种种不愉快，顺便还想看看有没有大佬能够优化这些问题。