游戏 App 热更新功能实作分享：8个步骤，及时清扫Bug

写游戏这么久，第一次在游戏 App 上实作「热更新」功能。

所谓热更新，我想大致上可分成两个层次：

1.仅下载图片、音源等素材档案，藉由设定档等方式，无需更新程序码即可使用新素材档。目的在于大幅缩减初始 app bundle 的档案尺寸，使玩家更快更容易下载游戏。

2.除了下载素材档案以外，亦须下载程序逻辑档案，目的在于绕过 App Store 审查。正所谓「有 Bug 堪修直须修，莫待 Apple 审核过」，以前的经验是，经常修好了要命臭虫后，等待审核过却是等到「花儿也谢了」，玩家也跑光了。修臭虫的时效性是关键所在。

以工程师的观点来看，可将「热更新」功能分解为下列几个步骤：

1.实现 HTTP 下载档案功能

2.检查本地端与服务器端的档案版号

3.依下载进度呈现进度条与数字

4.程序码档案须能区分 32/64 bits

5.程序码与素材档，支援多重读档路径

6.下载完毕后，重新载入图片等素材档案

7.下载完毕后，重新载入程序码（Lua 限定）

8.检查档案正确性，并更新本地端版号

以下详述各步骤的做法。

1. 实现 HTTP 下载档案功能

在 iOS 平台上，可用第三方函式库?AFNetworking?实现下载功能。至于?Android 平台，则可使用官方 SDK 提供的?DownloadManager?实作。

小提示：我原先试着使用?luasocket?来做 http 档案下载，结果尝试许久后，才发现 luasocket 并不支援 HTTPS 协定下的档案下载。若把档案放在 dropbox 或其他使用 HTTPS 的网络空间上，就会无法正确取得档案。

2. 检查本地端与服务器端的档案版号

首先下载 patch header 档案，内容记载此 patch 的版号，以及必须更新的程序码与素材档案列表。在下载 patch header 完成后，先检查 App 版号是否小于 patch header 版号。若否则进入游戏，若是就进入下载档案的程序。

3. 依下载进度呈现进度条与数字

简易版：依「档案数量」做概略显示，例如：下载进度 33%（33/100 ）

进阶版：依「档案尺寸」做精确显示。例如：下载进度 33.1415926%（33,100 / 100,000 KB）

4. 程序码档案须能区分 32/64 bits

目前 Android 无此需求。而在 iOS 上可用 preprocessor macro 来确认是否为 arm64 装置，然后再依此下载正确的程序码版本：



5. 程序码与素材档，支援多重读档路径

在载入程序脚本、图片、声音或其他资源档之前，先检查此档案是否存在于 app 的文件下载目录中，若有则使用之，若无则使用 app bundle 中原本包进去的资源档。

6. 下载完毕后，重新载入图片等素材档案

在这个步骤中，一般需要先卸载所有的 texture 资源，并且毁灭在游戏初始化时建立的相关资源物件，确认不会造成 memory leak。

7. 下载完毕后，重新载入程序码

热更新功能的所有步骤中，实作上最困难的应该就是这一步了。

所幸「有 Lua，没懦夫」，如果你的游戏 App 和我一样，大部分是由 Lua 所撰写而成的，那么只要充分利用 Lua 的特性，依照原先顺序重新载入 lua scripts，便可实时覆写正在运作中的程序码。轻松搞定，打完收工。

8.检查档案正确性，并更新本地端版号

使用 CRC 或其他的档案验证做法，检查下载档案的正确性。将新版号储存于 app 的本地端信息中。

相关进阶功能

在完成基础的热更新功能后，便可更进一步完成以下进阶功能：

1.区分「第一包」和「后续更新包」的内容。

2.利用此机制做简易的停机公告。

3.可限制最小 app bundle 版本。在下载更新前先做检查，若玩家小于此版本，则强制前往商店更新 App。

4.若在下载过程中网络中断，重新尝试连线后可恢复上次的下载进度，而不需要从头开始。

5.下载档案时，让玩家可以做别的事，例如：观看游戏提示、进行小游戏。

热更新功能完成后，便可将游戏素材档案切分开，使 App 于合适时机点下载对应素材。不要再做那种「第一次开游戏就先载个几百 MB 资料」 的事了，连教学都没完成的玩家，无须浪费珍贵的网络频宽在他身上，玩家也不会落入「才刚下载游戏，一开又得等下载」的窘境，或是像我一样：「要先下载档案啊，我还是回家有空再开好了。」让本来想玩游戏的兴致都没了。

以上，「热更新」功能已实现在新游戏 App 上。未来若有订正或进阶的做法，会持续更新在这篇文章里。

相关阅读：Unity热更新方案探索与讨论