移动端热更新方案（iOS+Android）

PPT资源包含iOS+Android 各种方案分析：https://github.com/qiyer/Share/blob/master/%E7%83%AD%E6%9B%B4%E6%96%B0%E5%88%86%E4%BA%ABPPT.pptx

一、热更新（热修复）产品背景

这里谈到的热更新都是指APP（不包含网页）。APP按大类别可以粗略分为应用和游戏。
APP的开发周期是极其快速的，在实际开发流程中，我们总会有一些需求迫使我们短时间内快速上线，比如需求流程出错,程序员主观导致的一些bug（闪退、主要功能无法使用），节日活动小版本改动。早期APP Store 的审核速度可以用龟速形容，一旦你app出问题了，想修复重新上一个新版本可能2周或是更长，对于app公司方是无法接受的。（现在App Store审核速度正常情况下大概1-3天）
虽然一些大公司有绿色通道，可以第一时间联系到 App Store 或是其它一些安卓渠道帮忙测试上线。但对于绝大部分公司来说没有这个特权。（即使走绿色通道，也需要一定的时间，另外并不是所有用户都愿意更新整个客户端）热更新技术呼之欲出。
其实热更新早就存在，只是很多方案在一开始并不成熟，一方面没有持续的更新维护，导致很多热更新方案最终夭折。

二、iOS APP 热更新方案出现的机遇

a-1.png

为什么从14年开始一些成熟的热更方案开始爆发？

在2013WWCD上苹果已经正式发布了iOS7 beta版并发布了下载，同年9月18日iOS7正式版发布了下载。
作为本次iOS的升级带来了iOS热更方案的关键，JavaScriptCore。
在iOS7之前，原生应用和Web应用之间很难通信。如果你想在iOS设备上渲染HTML或者运行JavaScript，你不得不使用UIWebView。iOS7引入了JavaScriptCore，功能更强大，使用更简单。然而现在可以利用JavaScriptCore的先进功能了，它可以：
1.运行JavaScript脚本而不需要依赖UIWebView；
2.使用现代Objective-C的语法（例如Blocks和下标）；
3.在Objective-C和JavaScript之间无缝的传递值或者对象；
4.创建混合对象（原生对象可以将JavaScript值或函数作为一个属性）。

iOS7刚出来并不是所有iphone用户都选择升级，意味很多用户还是iOS7 之前的版本，那么他们就没法使用JavaScriptCore。苹果于2014年WWDC（苹果开发者大会）发布的新开发语言Swift，最低支持iOS7(苹果建议)。苹果在强推用户升级这方面一直够霸道（经常不小心就升级了），很快iOS7以及以上用户占据了主流，逐渐的各大厂小厂APP最低版本支持变成了iOS7，现在的话大部分是最低支持iOS8 。

三、各方案优缺点对比

a-2.png

1、 Rollout.io 、 JSpatch、 DynamicCocoa比较

为什么把标题3个方案放一起比较？因为他们都是适合小更新，都是针对iOS平台的非跨平台热更方案, 原理和部署方案比较接近。
其中 Rollout 不仅仅支持OC ，还支持Swift，脚本语言是javascript，已经平台化了，若干个产品使用。（建议大家可以研究一下Swift的热更原理，OC大家基本比较理解了）
JSpatch 跟 Rollout 很像（除了不支持Swift），已经平台化，而且部署发布流程几乎和 rollout一样，国内各大产品都在用。
DynamicCocoa是滴滴搞出来的，我有看到sunnyxx 在 16年8月份博客上在研究这块。目前还没有开源，滴滴自己的产品流在使用，预计17年上半年开源。它也是只支持OC，不过有一个很大的进步是，不用我们再去写蹩脚的js脚本了，因为他们提供了工具可以用OC写，然后自动生成js。另外它还支持xib，storyboard，图片等资源的更新。（青出于蓝胜于蓝）

2、React Native、 Weex比较

React Native 和 Weex 都是跨平台的热更方案，Weex出来的晚，功能相对强大一点，具体表现为不仅支持iOS、Android，还支持H5. RN 在实现原理和 Weex 还是有很多共性的，不过Weex 做得更好点，一次编写可生成三平台代码。RN重视平台独立性，不能做到100%代码共用。

RN是facebook开源的，说实话刚出来时候那性能确实不咋的，加上一开始还不支持Android,还得去学习jsx规范，于是出现了看好、看衰派。不过随着RN的不断优化、安卓的支持、文档的规范、框架的稳定，越来越多公司开始采用了，包括天猫和手机淘宝部分模块，腾讯的QQ、 QQ空间、QQ音乐、全名K歌等。然后一度出现原生iOS 和 Android 开发要GG的段子，同时也出现了滥用RN，很多小公司跟风搞，结果是RN实现的模块出了不少bug，原因我不想分析了。(比如平安某医生)

Weex是阿里推出的，目前阿里系产品都已经开始使用，16年双11，页面99.6%是Weex实现的，说明其已经经得起实战验证。阿里系之前也有试用RN，为什么没有继续试用？RN的JSX写法很别扭这是其一，其二就是没办法实现100%代码共用，其三就是RN某些地方也有性能问题（iOS的UITableview就是个槽点），另外RN自身的bug以及性能优化太被动。然后才有了Weex 横空出世的机会。最近Weex 官网也出了，平台化了，支持中英文，我就想说两个字：“不仅仅是开源，阿里野心不小”！未来一波weex学习潮。。。

由于使用RN的成功产品太多，我就懒得截图了，脸书系、腾讯系、京东系、手机百度、若干国外app。

3、Wax 、Hybrid介绍

先谈谈Hybrid App开发，现阶段主流的平台包括PhoneGap，AppCan，appMobi，Titanium等，它们基于webkit开源内核，使用HTML5 标准开发，适配机型简单，支持开发者自定义插件，并能很好的应用于商业，教育，娱乐等行业，成为移动开发者的首选开发平台。但是么，性能确实有点差，基本上产品前期会采用这种方式，公司稍有起色，基本上招兵买马原生重构之。加上现阶段RN 和 Weex 的成熟稳定， Hybrid App已经不适合那种强频次、高性能需求的APP 开发方案了。（这里补充个案例，facebook当年信心满满的宣布要用h5作为移动端产品方案，并且号称不会使用原生，但经过一阶段时间，改成原生开发了，直接打脸了，不过还好后来推出了React Native，挽回了一点面子）

Wax需要特别说一下，因为它的脚本语言不是javascript，而是lua，在应用开发里面算是异类。（PS：不过lua在游戏开发热更中可是男一号）
还记得大明湖畔的游戏《愤怒的小鸟》吗？它就是基于Wax框架编写的。但是，后来作者13年开始不维护了，这下急坏了阿里系，因为他们家产品有使用wax，后来阿里接手了wax的更新维护，虽然支付宝后来使用了JSpatch(坏笑)。

这里简单说下为什么脚本语言有的是js,有的是lua，为什么应用开发大部分都是用js作为脚本语言？
答：个人观点，从脚本的性能来讲 lua是优于js，但lua是小众语言，相关类库不完善，文档论坛也不是非常成熟。js本就是web起家的，各种类库、文档、论坛成熟齐全。应用开发相比于游戏开发没有那么高的性能追求，js作为应用开发的脚本语言性能基本上没有多大问题。Cocos2d-X 和 Unity3d 热更大部分采用 lua，当然 cocos2d-X也有js版本，不过性能确实不如lua版本，不过js版本好处就是可以成h5游戏。

4、补充说明

何为GCC？

什么是GCC？GCC是由GNU之父Stallman所开发的linux下的编译器，全称为GNU Compiler Collection，目前可以编译的语言包括：C, C++, Objective-C, Fortran, Java, and Ada 等。
GCC包括前端和后端：
GCC目录下除去gcc/config目录外的其他文件是各个语言的编译器前端源文件，一般放在各自语言命名的目录下，例如cp（C++）、Java、fortran等。唯一例外的是C语言，它的前端源文件同GCC的通用文件（包括中间表示、中间优化等）一起，散放在gcc目录下。　　gcc/config目录是gcc在各种硬件或操作系统平台下的后端源文件，负责把GCC生成的中间表示转换为各平台相关的机器码、字节码或其他目标语言。

何为LLVM 、Clang ？

LLVM是apple赞助支持的，励志取代GCC。OC早期是利用GCC，但由于和Apple合作出了问题，然后Apple支持了LLVM，取代GCC，目前Xcode编译都是利用LLVM。目前只支持C、C++、OC。
Clang是LLVM的前端，负责将OC编译成语法树（AST）。

说了这么多，就是滴滴这次逼格有点高，直接利用Clang生成的语法树进行解析，然后转译成js。
这样就避免了iOS程序员去写ios风格的js操蛋脚本。

四、iOS拓展资源

http://mp.weixin.qq.com/s/qRW_akbU3TSd0SxpF3iQmQ
http://blog.csdn.net/Tencent_Bugly/article/details/51878361
http://www.open-open.com/lib/view/1481701561391
http://www.cnblogs.com/alibaichuan/p/5475143.html
https://github.com/bang590/JSPatch/wiki/JSPatch-%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86%E8%AF%A6%E8%A7%A3
http://www.tuicool.com/articles/rQ77J3q
http://blog.cnbang.net/tech/2698/

五、Android APP 热修复方案

1、百川Hotfix
不仅仅只基于AndFix，而是灵活切换热部署和冷部署的方案；实现了资源、SO文件、类修复的实时生效，同时采用了傻瓜式接入方案，完全不侵入打包过程，对用户提供了可视化的UI界面打补丁。(阿里)

2、美团Robust
在整个打Patch过程中，该方案正常的使用DexClassLoader，兼容性高；未反射注入，能够实时生效。该方案的缺点在于：因为在每端函数前插入代码，需要侵入打包过程；原来能被ProGuard内联的函数不能被内联了，所以可能导致方法数的增加，可能会超过65536限制，同时也会导致APK体积增大；该方案不支持SO文件和资源文件的修复。

3、手机QQ空间
该方案类似谷歌的Multidex ，在保障稳定性的前提下兼容性很高。缺点是:不支持实时生效；在Davilk下，类加载存在性能问题；Art下，补丁包涵有类、父类以及引用该类的所有类，因此补丁包较大；由于原DEX中的类需要引用额外的DEX类，需要侵入式打包。

4、微信Tinker
该方案中通过自研DexDiff算法，深度利用Dex的格式来减少差异的大小，从而做到补丁包足够小。其缺点在于：不支持实时生效；由于补丁DEX需要和原DEX合并，需要占用额外内存和磁盘空间，并且很容易因为内存消耗等原因合并失败；与QQ空间补丁技术相同，同样需要侵入式打包。

a-3.png

巴特西

移动端热更新方案（iOS+Android）

最新文章

热门文章