移动端热更新方案（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 或是 其它一些安卓渠道 帮忙测试上线。但对于绝大部分公司来讲没有这个特权。（即便走绿色通道，也须要必定的时间，另外并非全部用户都愿意更新整个客户端） 热更新技术呼之欲出。
其实热更新早就存在，只是不少方案在一开始并不成熟，一方面没有持续的更新维护，致使不少热更新方案最终夭折。

 

2、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 。

 

3、各方案优缺点对比

 

a-2.png

 

一、 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，图片等资源的更新。（青出于蓝胜于蓝）

二、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。

三、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游戏。

四、补充说明

何为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操蛋脚本。

 

4、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/

 

5、Android APP 热修复方案

 

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

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

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

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

 

a-3.png

 

6、更多以及感谢如下连接

 

https://yq.aliyun.com/articles/67136
http://www.cnblogs.com/alibaichuan/p/5863616.html
http://www.tuicool.com/articles/rQ77J3q
http://blog.csdn.net/u010963246/article/details/51995193