移動端熱更新方案（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