主要观点总结
本文介绍了支付宝小游戏的技术优化过程，包括小游戏运行时、文件系统优化、文本渲染优化、独立渲染线程和iOS高性能模式等方面的优化。通过优化，提高了小游戏的运行效率和用户体验，解决了游戏卡顿、掉帧等问题。
关键观点总结
关键观点1: 小游戏的技术优化包括哪些方面？
小游戏的技术优化包括多线程、独立音频线程、文件系统优化、文本渲染优化、独立渲染线程和iOS高性能模式等方面的优化。
关键观点2: 什么是多线程在小游戏中的优化作用？
在小游戏中，通过采用多线程技术，可以将耗时的计算任务放到子worker线程并行执行，以满足JS执行不阻塞渲染，从而提高游戏的流畅度。
关键观点3: 什么是独立音频线程在优化中的作用？
独立音频线程可以将音效与游戏主线程解耦，避免游戏卡顿和丢帧问题，提高游戏帧率。
关键观点4: 文件系统优化对小游戏有何影响？
文件系统优化可以提高小游戏中文件操作的吞吐性能上限，减少耗时动作无锁并行化，保障文件操作的稳定性，提高游戏对文件系统的访问效率。
关键观点5: 文本渲染优化的重点是什么？
文本渲染优化的重点是提高文本的渲染效率，通过优化字符排版和测量效率，以及高频API的调用效率，改善游戏的渲染效率。
关键观点6: 独立渲染线程是如何解决游戏卡顿问题的？
独立渲染线程可以将Render任务提交到独立的线程异步执行，避免某一帧Render阶段耗时过长导致的卡顿问题，从而提高游戏的帧率。
关键观点7: iOS高性能模式是如何提高小游戏运行效率的？
在iOS端，通过采用高性能模式，使用WKWebView替代JavaScriptCore作为小游戏的运行环境，解决了JavaScript代码执行效率的问题。同时，通过优化指令通信和调用的效率，提高了游戏的运行效率。
正文
我们使用 Cannon.js 物理引擎模拟 200 个不同形状的物体下落（iPhone 12 上测试），可以看到当把耗时的物理计算挪到子 worker 后，帧率显著改善（5fps->55fps），对比结果如下：
游戏中的音效播放场景与普通应用场景有显著差异：普通场景通常只涉及 1～2 个稳定的音频播放器，而在游戏中，音效播放数量可能在 1～20+ 之间剧烈波动，尤其在发生如多次碰撞等事件时，常会瞬间触发大量音效同时播放。
如上图场景，如果“音效”与“Game Main Thread” 不完全解耦，几乎不可规避游戏音效带来的卡顿丢帧问题，丢帧如下
（FrameTime 1）：
-
Update: 游戏逻辑计算，粒子效果计算，物理引擎计算，碰转计算等；
-
-
-
-
当大量查询播放器当前播放状态、同步构建批量/销毁播放器，导致播放器任务被挤压播放单元的耗时会造成严重的音效同步卡顿。
为了解决这个情况，我们采用，音效与渲染解耦做到完全隔离。
通过在抽象播放器协议中引入完整的“代理播放器”机制，第三方引擎可通过适配层接入该代理，实现音效播放的
0 阻塞
。
由于平台自带的 AudioPlayer 对多音源的支持能力不足，我们改用底层的 OpenAL 实现，并结合资源共享、流式加载等优化手段，加快音频任务处理效率。为应对高负载场景，还引入了任务动态丢弃策略，以避免播放队列堆积造成的延迟与卡顿。
通过独立音效处理优化后，我们的音效延迟基本控制在 30ms 以内，用户无感且很大幅度提高了中重度游戏的帧率，以某肉鸽类游戏为例，优化前后 FPS 对比数据明显提升（蓝色为优化前，红色为优化后）。
