乐变黄杲：当前如何选择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和游戏在运营和开发上也能提供很大的帮助。对于没有自研能力的公司来说，在选择热更新技术时，需要多方面考虑，选择适合自己的技术和服务。