Android 熱補丁實踐之路

大約在15年下半年開始，熱補丁方案開始大量湧現，一時間熱補丁修復技術在 Android 圈非常火爆，比較有代表性的開源實現有 Dexposed、AndFix、Nuwa 以及前段時間微信開源的 Tinker

我一直認為對於客戶端開發來說熱補丁修復技術不是必須的，但是卻很有必要的，我們身為開發者雖然都不想自己的程序出 bug，但是沒有一個開發人員能保證自己的程序一定不出 bug 的，之前出了問題只能重新發布版本，然後用戶下載更新，這個代價還是蠻大的，但是有了熱更新技術，這個就變得很簡單了。

所以在半年前我們也評估了以上幾種熱修復框架，准備用在項目中。

首先考慮的就是阿裡開源的 Dexposed 和 AndFix 兩個框架，前者是手淘開源的，後者是支付寶團隊開源的，都是 native hook 的方案，但是 Dexposed 不支持 art，在未來這是個很大的隱患，所以直接拋棄我們選擇了 AndFix。

評估下來，我們覺得 AndFix 雖說有一些限制，比如並不支持類替換、資源文件替換和 so 替換等，但是畢竟支持全平台，唯一擔心的是 AndFix 基於 native hook 的方案，不是屬於 java 層，屬於 jni 層，在國內這麼復雜的大環境下，穩定性與兼容性是個很大的考驗，不過想到畢竟是支付寶團隊出品，應該不用過渡擔心。

於是我們開始著手在項目中集成 AndFix，過程還算順利，實際測試下來效果也蠻好的，直到真的一次線上版本出現了 bug，考驗 AndFix 的時候到了，像集成的時候一樣，QA發布補丁，測試ok然後發布到正式環境。但是接下來並沒有像我們想象的一樣，錯誤率並沒有下降，而且從後台錯誤統計看到反而產生了新的莫名其妙的bug，所以我們就覺得兼容性有問題了，趕緊修復緊急發布了新的版本。

這次經驗證明了，native hook 的方案兼容性確實有很大問題，而且 AndFix 框架本身也有坑，從 GitHub 上該項目的 Issues 數量也可以看到，目前仍有近 200 個 issue 沒有解決。

我們中途考慮采用 Nuwa，畢竟 multidex 方案是屬於 java 層面的，兼容性肯定沒有問題，但是評估之後覺得 Nuwa 會帶來性能問題，而且這個時候微信的熱補丁方案 Tinker 已經放出來，並且表示即將開源，所以我們考慮等 Tinker 開源了再說。

今年的9月24號，MDCC 大會上騰訊的 Tinker 終於開源了，我們在第一時間進行了評估。

總體看下來，雖說 Tinker 也有一些限制，但是綜合下來優勢很明顯，下圖是微信官方曝出的一張各大熱修復方案對比圖，看下來很直觀：

除了技術上有優勢之外，還有就是微信覆蓋的人群太廣了，全國幾億人，各種設備都有，在兼容性方面微信肯定是首選考慮的，所以兼容性方面評估下來應該不是問題。

於是安排團隊成員果斷把 AndFix 替換成 Tinker，主要是我們項目依賴了 resGuard 來進行資源混淆，所以集成過程中稍微有點小麻煩，但總體來說還算比較順利，畢竟 Tinker 官方文檔很齊全，而且我認識 Tinker 作者，有問題甚至都可以直接進行請教。

就在前幾天我們發布了新版，其中出了一個 bug，又到了檢驗 Tinker 效果的時候了，這一次 Tinker 沒有讓我們失望，補丁發布之後出錯率降的很明顯，實踐證明 Tinker 在兼容性方面完全沒問題。為了更有說服力，上一張真實的友盟出錯率：

現在的技術與資料越來越多，只看網上的理論永遠沒有任何說服力，只有親自實踐才能是最好的說服力。之前很多人都問過我，說熱補丁修復框架到底哪一個好，我都沒有回答，那是因為我們還沒有親自實踐，不能只單純的從理論來進行分析，結果很重要。而如今，如果你想把熱補丁框架應用到你們項目中的話，那麼我推薦把 Tinker 作為最優選擇，起碼現階段來說是最優選擇。