乐变黄杲：当前如何选择 App 热更新服务

在 2017 年 6 月这个时间点，我们有必要谈谈热更新这个技术到底何去何从。

上半年苹果的两次警告，通知 iOS 开发者在 6 月 12 日前移除热更新相关代码，否则将会下架相关 App，一时间风声鹤唳，那么 App 热更新技术到底还能用吗？Android 热更新技术还有必要做吗？

对于这一问题，InfoQ 记者咨询了乐变技术的 CEO 黄杲，他们是做 App 热更新和游戏分包服务的，来看看他们如何解读。以下根据采访内容整理而成。

iOS 热更新：遵守苹果规则为本

iOS 平台的热更新可以分为三类：

第一类是使用 Hybrid 或者 React Native 及类似技术开发的 App，在更新时只更新页面内容和 JS 脚本，这种是苹果允许的。但苹果的规则还规定，在更新时不得改变应用原本的意图，如果完全改头换面，被用户投诉，苹果还是会处罚的。

第二类是使用 Native 动态化技术，替换原生代码。这种是苹果所主要打击的对象，虽然不是不能绕过苹果的检测，但一旦发现肯定会被处理。

第三类是手机游戏，使用热更新技术进行小版本更新。今年 WWDC 上苹果对 App Store 进行重大改版，专门将游戏提到了一级菜单，可见苹果对游戏的重视。在 6 月 12 日至今苹果下架了一批 App，其中游戏占一半，有开发者怀疑是因为热更新，不过很多带热更新的热门游戏并未受影响，所以这方面仍待进一步观察。

黄杲认为，无论是 App 开发者还是服务提供商都需要在各个平台允许的规则范围内开展业务。从热更新的需求上来说，苹果平台是一个封闭系统，App Store 可以在系统层面帮助应用做自动升级，除非用户在设置里关闭了此功能，苹果平台上应用自己实现热更新方面并不是刚需。

iOS 在较新的版本里允许本地库的动态加载 (要求签名一致)，也就是说，技术层面其实 iOS 要比早些年要开放一些；但在商务层面，苹果的审核在今年是偏严厉的，通过观察 iOS 的热更禁止行为，得到的结论是但凡没有动态加载和反射调用系统的函数，苹果仍然是允许的 (也就是说仍然可以动态加载自己的功能)，但从第二次通知来看这方面也在收紧，未来如何变化还尤未可知。

Android 热更新：特殊国情要求热更新功能

虽然 iOS 上热更新遭遇阻碍，但在国内 Android 平台，事情是另一个样子。

Android 系统是个开放生态，国内主流应用商店都是第三方的，它们通常无法第一时间获取 App 更新从而帮助应用自动更新，导致在 Android 平台上升级周期和升级率的问题会凸显出来。因此从平台角度上来说，Android 因为其生态的原因，需要应用自身来补足热更新能力补足的问题。

如何选择 Android 热更新服务

在国内 Android 热更新技术的探索上，可谓是百花齐放，各大互联网公司几乎都研发了自己的热更新技术。据不完全统计，包括微信的 Tinker，阿里巴巴早期的 Dexposed、后来的 Andfix 以及其升级版 Sophix，QQ 推出的 Qzone 方案和 QFix，饿了么的 Amigo，滴滴出行的 VirtualAPK，美团点评最新开源的 Robust 等。

这些热更新技术大部分已经开源，但要想应用这些技术实际并不容易，其中有很多坑。

应用 Android 热更新技术中的那些坑

第一大坑当属 Android 系统版本兼容性。有些热更新技术在开发的技术路线选择时，未完善考虑系统升级带来的问题。当 Android 系统进行大的版本升级时，可能会对底层的代码进行一些修改，如果热更新技术依赖了旧版本的代码，一旦系统升级，热更新技术就会变得完全不可用。早期的热更新技术基本都有这样的特点。

第二大坑是由 Android 系统碎片化带来的兼容问题。由于国内不同 Android 版本和硬件设备的组合高达数千种，不同厂商还会对自家的 ROM 进行魔改，热更新由于涉及系统底层代码，撞上错误的概率并不小，Android 的开放生态使得没有任何人能绝对的说，它的应用或代码可以和所有 Android 机型兼容。由此带来的问题就是，如果你使用的是部分第三方的开源热更新技术，没有人及时跟进 issue 时，遇到问题难以及时修复。

第三大坑是部署和实施，热更新并不是在在客户端嵌个 SDK，然后写几行代码集成就完了，你还需要在服务器部署更新包的分发，管理不同的客户端版本和差分包，更新出现问题时要能回滚，另外灰度发布也是运营大概率会要求支持的，甚至可能还有针对机型和系统版本进行更新的需求。这方面的人力成本并不小。

乐变的热更新解决方案

黄杲介绍，乐变的 Android 热更新服务通过以下手段避免以上的几个坑。

对于 Android 新版本的适配，乐变作为 Google Partners Lab 的成员，可以做到在每年的年初，甚至是 Google I/O 之前，就完成了下半年才会正式发布的 Android 新版本的兼容和测试。

乐变热更作为已经研发和成熟商业化运营已有五年的方案，支持从 Android 2.2 到最新的 Android O pre-release 的所有版本，支持 x86 等小众架构，支持 Dalvik 和 ART 引擎，并适配过数千款机型，所以成熟度非常高。

此外，乐变热更新提供的是一整套的解决方案，包括客户端、服务端、管理后台和统计系统、Crash 分析系统等等，所有这些部分都无需开发者自己来构建和实现。

同时，乐变还能够进一步帮助 App 开发者降低 Crash 率，一方面通过崩溃日志手机和分析系统，帮助应用开发者收集每个版本的 Crash Log，在后台的分析能够自动将这些崩溃日志归因到具体的机型和 Android 版本，还有一个智能分析的后台帮助开发者初步定位是什么原因导致的；另一方面，乐变热更新有分机型和分 Android 版本的更新，在应用的不兼容的问题解决后，可以通过乐变的热更新能力帮助应用仅更新指定机型或安卓版本即可动态解决不兼容和 Crash 的问题。

乐变不是一个简单的热更参考方案，而是围绕版本管理的一整套的精细化运营系统，支持灰度发布、AB 测试、分区域更新、分机型更新、自定义标签更新、沉默用户激活、定时上线和预下载等等的能力支撑，客户只需关注如何围绕产品使用好这些功能就能够完成精细化的产品运营。

最后，在服务的灵活性方面，乐变不仅支持公有云的标准化服务，也支持私有云的部署方案，结合客户的诉求，实施方式灵活多变。

游戏热更新技术

在移动平台，游戏的热更新使用的技术通常与 App 不同，有些热更新功能由游戏引擎自行提供，不过要做将热更新做到极致，还是有些地方需要注意。

比如游戏包体通常比较大，所以在差分包计算上难度会更大；同时，游戏的强制更新比较多，针对强制更新将用户体验设计好就很重要；再有，游戏渠道的二次打包的现象比较普遍，这又会进一步对于差分包的计算提出新的挑战；最后，应用和游戏要更新对象的侧重点也会有些差异，比如应用在渠道包之间一般只有渠道标识的差异，但游戏则需集成不同渠道 SDK.

游戏分包技术

热更新在游戏中的一个特殊地方就是游戏分包技术，当前手机游戏的安装包越做越大，但实际上可以通过一些技术实现边下边玩，相对的安装包可以做到很小。

黄杲介绍道，乐变的游戏分包服务包括三级压缩：

第一级是针对 iOS 平台的显示包体变大的问题：可能一个 300M 的游戏包体在 App Store 里显示会超过 800M，他们通过在文件系统层的能力增强等方式能基本解决这个问题；

第二级是边玩边下，原理是通过将用户早期访问到的资源提取出来形成一个小包，在用户玩游戏的同时自动下午后续内容 (非 WiFi 状态需要用户确实和选择)，通过这种方式，通常能够将包体压缩至原包体的三分之一以下的大小；

第三级就是刚才提到的二次加载或者说叫微端，部分游戏即使通过边玩边下做出来的小包仍然比较大，为了满足一些平台的上线要求，比如 Google Play 上 100MB 以下的包体才允许上传，再比如 iOS 在 100MB 以下的包体才允许流量用户下载，那此时就需要对包体仍然过大的游戏通过二次加载的技术来进一步将包体做小。相之于边玩变下的小包对于用户体验是没有影响的，即和完整包完全一致，微端的游戏包体在启动后是不能玩的，用户需要等待加载资源到边玩边下的临界点才能进入游戏。

当前乐变的游戏分包技术支持支持 iOS 和 Android，支持的游戏引擎包括 Unity 和 Cocos2d-X，其它的游戏引擎或平台的对接还在开发和测试当中，比如针对虚幻引擎的支持，还有针对 Windows 系统的支持等。

小结

App 热更新技术是目前热门的移动开发方向，同时对于移动 App 和游戏在运营和开发上也能提供很大的帮助。对于没有自研能力的公司来说，在选择热更新技术时，需要多方面考虑，选择适合自己的技术和服务。