其实打算做游戏内热更新也是几个月之前的事情了，在方案经历了数次变迁之后，最近才终于应用到了外网的bugfix中。
但是就目前数据来看，热更新由于要下载资源，会使新用户的进入门槛变高，所以留存收到了一定影响，基本降低了10个点。
当然，也可能是热更新的功能存在bug。

好了，我们还是进入正题吧!

方案一

最早的时候，我们想用一种类似打patch的方式来更新。
即将lua代码和资源打成一个zip包，而每个zip包只要代码或者资源发生变化，都会有一个自增的小版本号（大版本号为打在apk或者ipa里的版本号）。
不同的zip包之间diff就可以生成一个patch文件，而为了开发的简单，这个patch列表只会将文件路径列出来，之后客户端要去完整的下载新的文件覆盖。

然而这个方案有很多的问题。

1. 小版本号不好维护 因为代码和资源会不停的修改，而如果人工来维护小版本号，会极其复杂。如果通过机器来维护也是个很麻烦的工程

2. patch包太多 如果我们将小版本号的patch包先生成好放到服务器上，那么如果我们有100个小版本，就会有非常多 1->100, 2->100, 3->100 ... 这种格式的patch包。 并且如果小版本号继续增长，patch包的增长基本会失控。

3. 消耗大量流量，速度缓慢 也许有同学会说，不如只有 1->2, 2->3, 3->4 这样的单个小版本之间的升级patch，客户端自己挨个下载就好。

   但是这样客户端如果是个很小的版本号，就不会不停的重复下载，导致迟迟进入不了游戏，并且流量也大量消耗。

综上所述，方案一有太多的弊端。
这也是为什么我们做完了之后迟迟不敢上线的原因 ...

一. 发现问题

最近新版本上线，公司内部的几台iphone测试机测试都一切正常，但是外网用户却频频反馈崩溃。

在友盟上看了错误率统计，曲线如下:

可以看出，错误率确实有了很大的上浮。基本可以确认一定是出问题了。

二. 还原崩溃现场

我们游戏用得cocos2dx-lua，既然是崩溃，那就一定是到了c++端了，我们点击友盟上数量最多的那个看一下：

到了这里，遇到了第一个难点，因为按照友盟文档，使用他的错误dump工具是无效的，一旦看不到具体的错误内容，基本就无法继续了。

(而因为这个问题，发现有人推荐bugly，打算在下一个版本里面试用一下，再给大家反馈)

既然友盟提供的工具不行，我们就得像别的办法，起码现在错误的原始内容是有了，只是要想办法还原出来而已。

仔细研究了一下，友盟其实也是使用了mac原本就提供的工具来做了二次封装，那不如直接用原生的工具了。

具体方法如下：

1. 找到当时出包得那个archive文件，显示包文件，在其中找到如下两个文件放到同一目录:

   xxx.app
   xxx.app.dSYM

   其中 xxx.app.dSYM 即为符号表文件。

2. 查看其对应的UUID，一定要与crash log的UUID一致

   $ dwarfdump --uuid xxx.app ...