Android熱修復

咱們部門有不少Android的能力SDK，被不少App(約1000個)集成。每次SDK有微調發布新版本後，App集成須要花上1－2個月時間，不少時候SDK團隊和App團隊雙方都很痛苦。16年10月份，Boss叫搞一個Android的熱修復功能。神奇的是，竟然讓我一個從未搞過Android的人來負責（看來我在老闆心中 只能充當救火隊員）。我在16年12月完成了第一個版本的實現，後面詳細針對200多種機型的調試，就交給其餘同事去了。 最近看見已在部門幾個產品推廣該功能了，想一想仍是記錄下當時實現的思路。

當時首先調研了幾個公司的App熱更新方案（沒辦法，當時市場上沒有針對SDK的熱修復，僅找到針對App的）

l 阿里百川的Andfix

n 優勢是：能針對方法級別的更新，並且是真正的熱修復－不須要重啓App

n 缺點是：1）使用了Java的newInstance()去構造對象，因此不支持帶參數的構造函數 2）也不支持新增類和類字段 3）由於該方案本持是在native C++層替換函數指針來實現方法的「熱替換」，牛是很牛了，但聽說致使崩機率高。

n 結論：不適合我司的場景，PASS掉

n 備註：在17年1月推出了AndFix的2.0新版本，聽說有本質的提升。但由於沒有開源，只能圍觀一下。

l QQ的HotFix（開源版本叫Nuwa）

也就是你們熟知的Classloader方案。重啓App後更新。

n 優勢是：該方案提穩定性是最好的，補丁生效率是最高的。可是對補丁大小有嚴格限制。

n 缺點是：開源的Nuwa程序，實際使用後程序不是很穩定，在部分機型上總是崩潰。一旦補丁升級過多，會致使App在運行時效率低下。

l 微信的Tinker

整個更新過程和QQ的方案相似，但本質卻徹底不一樣。Tinker在客戶端在收到補丁後，將用原Apk文件+補丁作一次合成，造成新的APK文件，再基於新的APK文件運行程序。

n 優勢是：不受限補丁更新次數，不受限於熱修復自己，一旦程序啓動後，對性能無影響。

n 缺點是：啓動程序（好比微信）時，由於有合成動做，佔用內存較多。

l 美團的熱修復

在全部Class的全部Method中自動插樁一段代碼。這段代碼包含了更新的邏輯。

n 優勢是：是基於Java的原理實現，而非Android自己原理，原理更加通用和簡單。

n 缺點是：增長APK包體大小，直接致使部分DEX文件超過65535 Method總數的限制。儘管後續作了優化，但我的感受太過簡單粗暴。

n 結論：PASS掉

l 攜程的插件化方案

把每一個SDK作成APK格式，由主程序加載全部APK文件。

n 優勢是：很符合我司SDK更新的場景，並且能同時更新SDK的UI、Java代碼、so庫。看起來很完美。

n 缺點是：老闆說，SDK熱修復方案要對App層無感知。但攜程的插件化方案須要對App框架進行改造。1000個App，得改到啥時候啊。

n 結論：最開始原本想採用這套方案來着，後面也只有揮淚PASS掉。

l 我司其它團隊的土方法：

1) 去掉SDK的UI層，直接將SDK的界面經過純Java代碼實現，界面中涉及的圖片，經過網絡在線加載

2) 把Java層切成兩部分：接口和核心邏輯，分別單獨打包。接口層初始化時負責加載核心層的Java包。

最後基於種種考慮，採用了QQ和微信的混合方案， 客戶端熱修復的底層實現，使用Nuwa中代碼（加載dex包部分）；補丁的生成方案使用微信的dexDiff算法。

缺點就是：不能更新SDK的UI層，僅支持更新SDK的Java層和so庫。 主要緣由是SDK自己的限制，畢竟不是App，拿不到相應的系統權限。

大致方案以下圖所示：

本次介紹就到這裏。抽空再介紹一下實際操做中，遇到熱修復不生效和崩機時的回退方案。

我有幾張阿里雲幸運券分享給你，用券購買或者升級阿里雲相應產品會有特惠驚喜哦！把想要買的產品的幸運券都領走吧！快下手，立刻就要搶光。