一 、熱更新（熱修復）產品背景

這裡談到的熱更新都是指APP（不包含網頁）。APP按大類別可以粗略分為 應用 和 遊戲。
APP的開發週期是極其快速的，在實際開發流程中，我們總會有一些需求迫使我們短時間內快速上線，比如需求流程出錯,程式設計師主觀導致的一些bug（閃退、主要功能無法使用），節日活動小版本改動。早期APP Store 的稽核速度可以用龜速形容，一旦你app出問題了，想修復重新上一個新版本可能2周或是更長，對於app公司方是無法接受的。（現在App Store稽核速度正常情況下大概1-3天）
雖然一些大公司有綠色通道，可以第一時間聯絡到 App Store 或是 其它一些安卓渠道 幫忙測試上線。但對於絕大部分公司來說沒有這個特權。（即使走綠色通道，也需要一定的時間，另外並不是所有使用者都願意更新整個客戶端） 熱更新技術呼之欲出。
其實熱更新早就存在，只是很多方案在一開始並不成熟，一方面沒有持續的更新維護，導致很多熱更新方案最終夭折。

二、iOS APP 熱更新方案出現的機遇

為什麼從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 。

三、各方案優缺點對比

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拓展資源

五、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空間補丁技術相同，同樣需要侵入式打包。

六、更多以及感謝以下連結