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
注意：文中的JSpatch 和Rollout 方案已經(jīng)受到蘋(píng)果爸爸的抵制，慎用。
更新：Rollout公司推出了第二代產(chǎn)品ROX，一樣的功能，不一樣的罐裝。（還可支持安卓）
JSPatch 提供一個(gè)換了很多函數(shù)名稱的版本，只提供給老用戶使用。
一 、熱更新（熱修復(fù)）產(chǎn)品背景
這里談到的熱更新都是指APP（不包含網(wǎng)頁(yè)）。APP按大類別可以粗略分為 應(yīng)用 和 游戲。
APP的開(kāi)發(fā)周期是極其快速的，在實(shí)際開(kāi)發(fā)流程中，我們總會(huì)有一些需求迫使我們短時(shí)間內(nèi)快速上線，比如需求流程出錯(cuò),程序員主觀導(dǎo)致的一些bug（閃退、主要功能無(wú)法使用），節(jié)日活動(dòng)小版本改動(dòng)。早期APP Store 的審核速度可以用龜速形容，一旦你app出問(wèn)題了，想修復(fù)重新上一個(gè)新版本可能2周或是更長(zhǎng)，對(duì)于app公司方是無(wú)法接受的。（現(xiàn)在App Store審核速度正常情況下大概1-3天）
雖然一些大公司有綠色通道，可以第一時(shí)間聯(lián)系到 App Store 或是 其它一些安卓渠道 幫忙測(cè)試上線。但對(duì)于絕大部分公司來(lái)說(shuō)沒(méi)有這個(gè)特權(quán)。（即使走綠色通道，也需要一定的時(shí)間，另外并不是所有用戶都愿意更新整個(gè)客戶端） 熱更新技術(shù)呼之欲出。
其實(shí)熱更新早就存在，只是很多方案在一開(kāi)始并不成熟，一方面沒(méi)有持續(xù)的更新維護(hù)，導(dǎo)致很多熱更新方案最終夭折。
二、iOS APP 熱更新方案出現(xiàn)的機(jī)遇
為什么從14年開(kāi)始一些成熟的熱更方案開(kāi)始爆發(fā)？
在2013WWCD上蘋(píng)果已經(jīng)正式發(fā)布了iOS7 beta版并發(fā)布了下載，同年9月18日iOS7正式版發(fā)布了下載。
作為本次iOS的升級(jí)帶來(lái)了iOS熱更方案的關(guān)鍵，JavaScriptCore。
在iOS7之前，原生應(yīng)用和Web應(yīng)用之間很難通信。如果你想在iOS設(shè)備上渲染HTML或者運(yùn)行JavaScript，你不得不使用UIWebView。iOS7引入了JavaScriptCore，功能更強(qiáng)大，使用更簡(jiǎn)單。然而現(xiàn)在可以利用JavaScriptCore的先進(jìn)功能了，它可以：
1.運(yùn)行JavaScript腳本而不需要依賴UIWebView；
2.使用現(xiàn)代Objective-C的語(yǔ)法（例如Blocks和下標(biāo)）；
3.在Objective-C和JavaScript之間無(wú)縫的傳遞值或者對(duì)象；
4.創(chuàng)建混合對(duì)象（原生對(duì)象可以將JavaScript值或函數(shù)作為一個(gè)屬性）。
iOS7剛出來(lái)并不是所有iphone用戶都選擇升級(jí)，意味很多用戶還是iOS7 之前的版本，那么他們就沒(méi)法使用JavaScriptCore。蘋(píng)果于2014年WWDC（蘋(píng)果開(kāi)發(fā)者大會(huì)）發(fā)布的新開(kāi)發(fā)語(yǔ)言Swift，最低支持iOS7(蘋(píng)果建議)。蘋(píng)果在強(qiáng)推用戶升級(jí)這方面一直夠霸道（經(jīng)常不小心就升級(jí)了），很快iOS7以及以上用戶占據(jù)了主流，逐漸的各大廠小廠APP最低版本支持變成了iOS7，現(xiàn)在的話大部分是最低支持iOS8 。
三、各方案優(yōu)缺點(diǎn)對(duì)比
1、 Rollout.io 、 JSpatch、 DynamicCocoa比較
為什么把標(biāo)題3個(gè)方案放一起比較？因?yàn)樗麄兌际沁m合小更新，都是針對(duì)iOS平臺(tái)的非跨平臺(tái)熱更方案, 原理和部署方案比較接近。
其中 Rollout 不僅僅支持OC ，還支持Swift，腳本語(yǔ)言是javascript，已經(jīng)平臺(tái)化了，若干個(gè)產(chǎn)品使用。（建議大家可以研究一下Swift的熱更原理，OC大家基本比較理解了）
JSpatch 跟 Rollout 很像（除了不支持Swift），已經(jīng)平臺(tái)化，而且部署 發(fā)布流程 幾乎和 rollout一樣，國(guó)內(nèi)各大產(chǎn)品都在用。
DynamicCocoa是滴滴搞出來(lái)的，我有看到sunnyxx 在 16年8月份 博客上在研究這塊。目前還沒(méi)有開(kāi)源，滴滴自己的產(chǎn)品流 在使用，預(yù)計(jì)17年上半年開(kāi)源。它也是只支持OC，不過(guò)有一個(gè)很大的進(jìn)步是，不用我們?cè)偃?xiě)蹩腳的js腳本了，因?yàn)樗麄兲峁┝斯ぞ呖梢杂肙C寫(xiě)，然后自動(dòng)生成js。另外它還支持xib，storyboard，圖片等資源的更新。（青出于藍(lán)勝于藍(lán)）
2、React Native、 Weex比較
React Native 和 Weex 都是跨平臺(tái)的熱更方案，Weex出來(lái)的晚，功能相對(duì)強(qiáng)大一點(diǎn)，具體表現(xiàn)為不僅支持iOS、Android，還支持H5. RN 在實(shí)現(xiàn)原理 和 Weex 還是 有很多共性的，不過(guò)Weex 做得更好點(diǎn)，一次編寫(xiě)可生成三平臺(tái)代碼。RN重視平臺(tái)獨(dú)立性，不能做到100%代碼共用。
RN是facebook開(kāi)源的，說(shuō)實(shí)話剛出來(lái)時(shí)候那性能確實(shí)不咋的，加上一開(kāi)始還不支持Android,還得去學(xué)習(xí)jsx規(guī)范，于是出現(xiàn)了看好、看衰派。不過(guò)隨著RN的不斷優(yōu)化、安卓的支持、文檔的規(guī)范、框架的穩(wěn)定，越來(lái)越多公司開(kāi)始采用了，包括天貓和手機(jī)淘寶部分模塊，騰訊的QQ、 QQ空間、QQ音樂(lè)、全名K歌 等。然后一度出現(xiàn)原生iOS 和 Android 開(kāi)發(fā)要GG的段子，同時(shí)也出現(xiàn)了濫用RN，很多小公司跟風(fēng)搞，結(jié)果是RN實(shí)現(xiàn)的模塊出了不少bug，原因我不想分析了。(比如平安某醫(yī)生)
Weex是阿里推出的，目前阿里系產(chǎn)品都已經(jīng)開(kāi)始使用，16年雙11，頁(yè)面99.6%是Weex實(shí)現(xiàn)的，說(shuō)明其已經(jīng)經(jīng)得起實(shí)戰(zhàn)驗(yàn)證。阿里系之前也有試用RN，為什么沒(méi)有繼續(xù)試用？RN的JSX寫(xiě)法很別扭這是其一，其二就是沒(méi)辦法實(shí)現(xiàn)100%代碼共用，其三就是RN某些地方也有性能問(wèn)題（iOS的UITableview就是個(gè)槽點(diǎn)），另外RN自身的bug以及性能優(yōu)化 太被動(dòng)。然后才有了Weex 橫空出世的機(jī)會(huì)。最近Weex 官網(wǎng)也出了，平臺(tái)化了，支持中英文，我就想說(shuō)兩個(gè)字：“不僅僅是開(kāi)源，阿里野心不小”！未來(lái)一波weex學(xué)習(xí)潮。。。
由于使用RN的成功產(chǎn)品太多，我就懶得截圖了，臉書(shū)系、騰訊系、京東系、手機(jī)百度、若干國(guó)外app。
3、Wax 、Hybrid介紹
先談?wù)凥ybrid App開(kāi)發(fā)，現(xiàn)階段主流的平臺(tái)包括PhoneGap，AppCan，appMobi，Titanium等，它們基于webkit開(kāi)源內(nèi)核，使用HTML5 標(biāo)準(zhǔn)開(kāi)發(fā)，適配機(jī)型簡(jiǎn)單，支持開(kāi)發(fā)者自定義插件，并能很好的應(yīng)用于商業(yè)，教育，娛樂(lè)等行業(yè)，成為移動(dòng)開(kāi)發(fā)者的首選開(kāi)發(fā)平臺(tái)。但是么，性能確實(shí)有點(diǎn)差，基本上產(chǎn)品前期會(huì)采用這種方式，公司稍有起色，基本上招兵買(mǎi)馬原生重構(gòu)之。加上現(xiàn)階段RN 和 Weex 的成熟穩(wěn)定， Hybrid App已經(jīng)不適合那種強(qiáng)頻次、高性能需求的APP 開(kāi)發(fā)方案了。（這里補(bǔ)充個(gè)案例，facebook當(dāng)年信心滿滿的宣布要用h5作為移動(dòng)端產(chǎn)品方案，并且號(hào)稱不會(huì)使用原生，但經(jīng)過(guò)一階段時(shí)間，改成原生開(kāi)發(fā)了，直接打臉了，不過(guò)還好后來(lái)推出了React Native，挽回了一點(diǎn)面子）
Wax需要特別說(shuō)一下，因?yàn)樗哪_本語(yǔ)言不是javascript，而是lua，在應(yīng)用開(kāi)發(fā)里面算是異類。（PS：不過(guò)lua在游戲開(kāi)發(fā)熱更中可是男一號(hào)）
還記得大明湖畔的游戲《憤怒的小鳥(niǎo)》嗎？它就是基于Wax框架編寫(xiě)的。但是，后來(lái)作者13年開(kāi)始不維護(hù)了，這下急壞了阿里系，因?yàn)樗麄兗耶a(chǎn)品有使用wax，后來(lái)阿里接手了wax的更新維護(hù)，雖然支付寶后來(lái)使用了JSpatch(壞笑)。
這里簡(jiǎn)單說(shuō)下為什么腳本語(yǔ)言有的是js,有的是lua，為什么應(yīng)用開(kāi)發(fā)大部分都是用js作為腳本語(yǔ)言？
答：個(gè)人觀點(diǎn)，從腳本的性能來(lái)講 lua是優(yōu)于js，但lua是小眾語(yǔ)言，相關(guān)類庫(kù)不完善，文檔論壇也不是非常成熟。js本就是web起家的，各種類庫(kù)、文檔、論壇成熟齊全。應(yīng)用開(kāi)發(fā)相比于游戲開(kāi)發(fā)沒(méi)有那么高的性能追求，js作為應(yīng)用開(kāi)發(fā)的腳本語(yǔ)言性能基本上沒(méi)有多大問(wèn)題。Cocos2d-X 和 Unity3d 熱更大部分采用 lua，當(dāng)然 cocos2d-X也有js版本，不過(guò)性能確實(shí)不如lua版本，不過(guò)js版本好處就是可以成h5游戲。
4、補(bǔ)充說(shuō)明
何為GCC？
什么是GCC？GCC是由GNU之父Stallman所開(kāi)發(fā)的linux下的編譯器，全稱為GNU Compiler Collection， 目前可以編譯的語(yǔ)言包括：C, C++, Objective-C, Fortran, Java, and Ada 等。
GCC包括前端和 后端：
GCC目錄下除去gcc/config目錄外的其他文件是各個(gè)語(yǔ)言的編譯器前端源文件，一般放在各自語(yǔ)言命名的目錄下，例如cp（C++）、Java、fortran等。唯一例外的是C語(yǔ)言，它的前端源文件同GCC的通用文件（包括中間表示、中間優(yōu)化等）一起，散放在gcc目錄下。 gcc/config目錄是gcc在各種硬件或操作系統(tǒng)平臺(tái)下的后端源文件，負(fù)責(zé)把GCC生成的中間表示轉(zhuǎn)換為各平臺(tái)相關(guān)的機(jī)器碼、字節(jié)碼或其他目標(biāo)語(yǔ)言。
何為L(zhǎng)LVM 、Clang ？
LLVM是apple贊助支持的，勵(lì)志取代GCC。OC早期是利用GCC，但由于和Apple合作出了問(wèn)題，然后Apple支持了LLVM，取代GCC，目前Xcode編譯都是利用LLVM。目前只支持C、C++、OC。
Clang是LLVM的前端，負(fù)責(zé)將OC編譯成語(yǔ)法樹(shù)（AST）。
說(shuō)了這么多，就是滴滴這次逼格有點(diǎn)高，直接利用Clang生成的語(yǔ)法樹(shù)進(jìn)行解析，然后轉(zhuǎn)譯成js。
這樣就避免了iOS程序員去寫(xiě)ios風(fēng)格的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 熱修復(fù)方案
1、百川Hotfix
不僅僅只基于AndFix，而是靈活切換熱部署和冷部署的方案；實(shí)現(xiàn)了資源、SO文件、類修復(fù)的實(shí)時(shí)生效，同時(shí)采用了傻瓜式接入方案，完全不侵入打包過(guò)程，對(duì)用戶提供了可視化的UI界面打補(bǔ)丁。(阿里)
2、美團(tuán)Robust
在整個(gè)打Patch過(guò)程中，該方案正常的使用DexClassLoader，兼容性高；未反射注入，能夠?qū)崟r(shí)生效。該方案的缺點(diǎn)在于：因?yàn)樵诿慷撕瘮?shù)前插入代碼，需要侵入打包過(guò)程；原來(lái)能被ProGuard內(nèi)聯(lián)的函數(shù)不能被內(nèi)聯(lián)了，所以可能導(dǎo)致方法數(shù)的增加，可能會(huì)超過(guò)65536限制，同時(shí)也會(huì)導(dǎo)致APK體積增大；該方案不支持SO文件和資源文件的修復(fù)。
3、手機(jī)QQ空間
該方案類似谷歌的Multidex ，在保障穩(wěn)定性的前提下兼容性很高。缺點(diǎn)是:不支持實(shí)時(shí)生效；在Davilk下，類加載存在性能問(wèn)題；Art下，補(bǔ)丁包涵有類、父類以及引用該類的所有類，因此補(bǔ)丁包較大；由于原DEX中的類需要引用額外的DEX類，需要侵入式打包。
4、微信Tinker
該方案中通過(guò)自研DexDiff算法，深度利用Dex的格式來(lái)減少差異的大小，從而做到補(bǔ)丁包足夠小。其缺點(diǎn)在于：不支持實(shí)時(shí)生效；由于補(bǔ)丁DEX需要和原DEX合并，需要占用額外內(nèi)存和磁盤(pán)空間，并且很容易因?yàn)閮?nèi)存消耗等原因合并失敗；與QQ空間補(bǔ)丁技術(shù)相同，同樣需要侵入式打包。
六、更多以及感謝以下鏈接
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
