【安卓筆記】,熱修復實現2x

　【安卓筆記】

　熱修復實現 2 熱修復實現( 一) 之前也分析過 InstantRun 的源碼，前面也寫了一篇熱修復實現原理的文章。

　But，最近遇到困難了，所在項目要做插件化，同事在開發過程中遇到了一個在5.0 以下手機崩潰的問題，想著一起找找原因修復下。

　但是這個 bug 已經折騰了我兩天了，只找到原因，并沒有找出任何解決方案。

　深深的感覺到之前的那些都是皮毛，沒有真正的去做，真正的去處理一些細節，那些都是沒任何意義的。

　所以這里系統學習一下，既然學習，就找一個做的最好的來學。

　前面的文章也介紹了，目前存在的幾個開源框架: • 手機淘寶基于 Xposed 進行了改進，產生了針對 Android Dalvik 虛擬機運行時的 Java Method Hook 技術-Dexposed。

　但這個方案猶豫底層 Dalvik 結構過于依賴，最終無法兼容 Android 5.0 以后的ART 虛擬機。

　• 支付寶提出了新的方案 Andfix，它同樣是一種底層結構替換的方案，也達到了運行時生效即時修復的效果，而且做到了 Dalvik 和 ART 全版本的兼容。然而它也 是由局限性的，且不說其底層固定結構的替換方案穩定性不好，其使用范文也存在著諸多限制，雖然可以通過代碼改造來繞過限制達到同樣的 修復目的，但是這種方式即不優雅也不方便。而且更大的問題是 Andfix 只提供了代碼層面的修復，對于資源和 so 的修復都還未實現。

　• 其他的就是微信 Tinker、餓了么的 Amigo、美團的 Robust，不過他們都各自有各自的局限性，或者不夠穩定、或者補丁過大、或者效率低下 ，或者使用起來太繁瑣，大部分技術上看起來似乎可行，但是實際體驗并不好。

　我們學習的就是阿里巴巴的新一代非侵入式 Android 熱修復方案-Sophix。

　它各個方面都比較優秀，使用也比較方便，唯一不支持的就是四大組件的修復。這是因為如果修復四大組件，必須在 AndroidManifest 里面預先插入代碼組件，并且盡可能聲明所有權限，這樣就會給 原先的 app 添加很多臃腫的代碼，對 app 運行流程的侵入性很強。

　在 Sophix 中，唯一需要的就是初始化和請求補丁兩行代碼，甚至連入口Application 類我們都不需要做任何修改。

　這樣就給了開發者最大的透明度和自由度。我們甚至重新開發了打包工具，使的補丁工具操作圖形界面化，這種所見即所得的補丁生成 方式也是阿里熱修復獨家的，因此，Sophix 的接入成本也是目前市面上所有方案里最低的。

　代碼修復 代碼修復有兩大主要方案: • 阿里系的底層替換方案:底層替換方案限制頗多，但是時效性最好，加載輕快，立即見效。

　 底層替換方案是在已經加載了的類中直接替換掉原有的方法，是在原來類的基礎上進行修改的。因而無法實現對原有類進行方法和字段的增減，因為這樣將破壞原有類的結構。

　一旦補丁類中出現了方法的增加和減少，就會導致這個類以及整個 dex 的方法數的變化，方法數的變化伴隨著方法索引的變化，這樣在 訪問方法時就無法正常的索引到正確的方法了。如果字段發生了增加或減少，和方法變化的情況一樣，所有字段的索引都會發生變化。

　而新方法中使用到這些老的示例對象時，訪問新增字段就會會產生不可預期的結果。

　 這是該類方案的固有限制，而底層替換方案最為人逅病的地方，在于底層替換的不穩定性。因為 Hook 方案，都是直接依賴修改虛擬機方法實體的具體字段。因為 Art 虛擬機和 Dalvik 虛擬機的不同，每個版本的虛擬機都要適配，而且Android 系統是開源的，各個廠商都可以對代碼進行改造，如果某個廠商進行了修改，那么這種通用性的替換機制就會出問題。這便是不穩定的根源。

　• 騰訊系的類加載方案:類加載方案時效性差，需要重新冷啟動才能見效，但修復范圍廣、限制少。

　類加載方案的原理是在 app 重新啟動后讓 classloader 去加載新的類。因為在 app運行到一半的時候，所有需要發生變更的類已經被加載過了，在 Android 上是無法對一個類進行卸載的。如果不重啟，原來的類還在虛擬機中，就無法加載新類，因此只有在下次重啟的時候， 在還沒走到業務邏輯之前搶先加載補丁中的新類，這樣后續訪問這個類的時候，就會用新類，從而達到熱修復的目的。

　為什么 sophix 更好? 既然底層替換方案和類加載方案各有優點，把他們聯合起來就是最好的選擇。Sophix 就是同時涵蓋了這兩種方案，可以實現優勢互補、完全兼顧的作用，可以靈活的根據實際情況自動切換。

　但是 Sophix 有一個缺點就是，他不是開源的，而且是收費的。但是確實強大。