阿里巴巴對Android熱修復(fù)技術(shù)已經(jīng)進行了長達多年的探索。

[[193982]]

最開始，是手淘基于Xposed進行了改進，產(chǎn)生了針對Android Dalvik虛擬機運行時的Java Method Hook技術(shù)，Dexposed。但這個方案由于對底層Dalvik結(jié)構(gòu)過于依賴，最終無法繼續(xù)兼容Android5.0以后ART虛擬機，因此作罷。

后來支付寶提出了新的熱修復(fù)方案Andfix。Andfix同樣是一種底層結(jié)構(gòu)替換的方案，也達到了運行時生效即時修復(fù)的效果，并且重要的是，做到了Dalvik和ART環(huán)境的全版本兼容。阿里百川結(jié)合手淘在實際工程中使用Andfix的經(jīng)驗，對相關(guān)業(yè)務(wù)邏輯解耦后，推出了阿里百川Hotfix方案，并得到了良好的反響。

此時的百川Hotfix已經(jīng)是一個很不錯的產(chǎn)品了，對于基本的代碼修復(fù)需求都可以解決，安全性和易用性都做的比較好。然而，它所依賴的基石，Andfix本身，是有局限性的。且不說其底層固定結(jié)構(gòu)的替換方案穩(wěn)定性不好，其使用范圍也存在著諸多限制，雖然可以通過改造代碼繞過限制來達到相同的修復(fù)目的，但這種方式既不優(yōu)雅也不方便。而更大的問題是，Andfix只提供了代碼層面的修復(fù)，對于資源和so的修復(fù)都還未能實現(xiàn)。

再看一下同期的其他熱修復(fù)方案，此時的熱修復(fù)技術(shù)可謂是百花齊放，許多產(chǎn)品都聲稱自己可以做到全方位全功能的熱修復(fù)。不過他們各自有自身的局限性，或者不夠穩(wěn)定，或者補丁過大，或者效率低下，或者使用起來過于繁瑣，大部分技術(shù)上看起來似乎可行，但實際體驗并不好。而在我們看來，有很多技術(shù)細節(jié)能夠做得更加完美。

終于在2017年6月11日，手淘技術(shù)團隊聯(lián)合阿里云正式發(fā)布了史上首個非侵入式移動熱更新解決方案——Sophix。

Sophix入口：https://www.aliyun.com/product/hotfix

Sophix的橫空出世，將會打破各家熱修復(fù)技術(shù)紛爭的局面。我們可以滿懷信心地說，在Android熱修復(fù)的三大領(lǐng)域：代碼修復(fù)、資源修復(fù)、so修復(fù)方面，以及方案的安全性和易用性方面，Sophix都做到了業(yè)界領(lǐng)先。

設(shè)計理念

Sophix的核心設(shè)計理念，就是非侵入性。

我們的打包過程不會侵入到apk的build流程中。我們所需要的，只有已經(jīng)生成完畢的新舊apk，而至于apk是如何生成的——是Android Studio打包出來的、還是Eclipse打包出來的、或者是自定義的打包流程，我們一律不關(guān)心。在生成補丁的過程中間既不會改變?nèi)魏未虬M件，也不插入任何AOP代碼，我們極力做到了——不添加任何超出開發(fā)者預(yù)期的代碼，以避免多余的熱修復(fù)代碼給開發(fā)者帶來困擾。

在Sophix中，唯一需要的就是初始化和請求補丁兩行代碼，甚至連入口Application類我們都不做任何修改，這樣就給了開發(fā)者最大的透明度和自由度。我們甚至重新開發(fā)了打包工具，使得補丁工具操作圖形界面化，這種所見即所得的補丁生成方式也是阿里熱修復(fù)獨家的。因此，Sophix的接入成本也是目前市面上所有方案里最低的。

這種非侵入式熱更新理念，是我們在設(shè)計過程中從用戶使用角度進行了深入思考而提煉出的核心思想。

這里的用戶，指的自然是廣大的開發(fā)者。對于開發(fā)者而言，熱修復(fù)應(yīng)該是一個與業(yè)務(wù)無關(guān)的SDK組件，在整個開發(fā)過程中感知不到它的存在。最理想的情況，就是開發(fā)者拿過來兩個apk，一個是已經(jīng)安裝在手機上的apk，另一個是將要發(fā)布出去的apk。我們直接通過工具，就可以根據(jù)這兩個apk生成補丁，然后把這個補丁下發(fā)給已經(jīng)安裝的舊app上，就可以直接加載，使舊app重生為新的app。而這個加載了補丁包新app，在功能和使用上，將會和直接安裝新apk別無二致。

至于Sophix這個名字，是來源于Sophic(明智的)+ FIX，一個更明智的熱修復(fù)方案。

詳細比較

下面的這張表格，從幾個熱修復(fù)最重要的維度，把Sophix和另外兩個主要商業(yè)化熱修復(fù)方案進行了比較。

可以看到，Sophix在各個指標上全面占優(yōu)。而其中唯一不支持的地方就是四大組件的修復(fù)，這是因為如果要修復(fù)四大組件，必須在AndroidManifest里面預(yù)先插入代理組件，并且盡可能聲明所有權(quán)限，而這么做就會給原先的app添加很多臃腫的代碼，對app運行流程的侵入性很強。

所以，本著對開發(fā)者透明與代碼極簡的原則，我們沒有做這種多余的處理。

直接看表格的話，其中有些技術(shù)細節(jié)可能還看不太明朗，那么接下來，我將從各個角度，深度解讀Sophix的技術(shù)優(yōu)勢以及它與同類技術(shù)的差別。

技術(shù)分析

Sophix的誕生，起初是對原先的阿里百川Hotfix 1.X版本進行升級衍進。

原先百川Hotfix服務(wù)端的整套請求控制流程，以及安全檢查這部分，是與熱修復(fù)功能相對分離的，因此我們依舊保留了這部分的邏輯。

而原本的熱修復(fù)方案，主要限制在于Andfix本身，我們最開始也是從突破原先修復(fù)限制入手，希望能夠基于原先的Andfix代碼做一些必要的改進。然而最終發(fā)現(xiàn)，Andfix自身限制幾乎是無法繞過的，在運行時對原有類的結(jié)構(gòu)是已經(jīng)固化在內(nèi)存中的，它的一些動態(tài)屬性和很難進行擴展。并且由于Android系統(tǒng)的碎片化，廠商的虛擬機底層結(jié)構(gòu)都不是確定的，因此直接基于原先機制進行擴展的風險很大。

所以我們繞開了具體的技術(shù)實現(xiàn)細節(jié)，直接從修復(fù)的原理入手，對原先的代碼修復(fù)技術(shù)進行深挖和改良。

回顧為期九個多月的探索與開發(fā)，這其中無處不體現(xiàn)著我們對易用性和優(yōu)雅性的極致追求，在技術(shù)先進性與易用性上我們達到了完美的平衡。所以，當我們再回頭看目前市面上的其他熱修復(fù)技術(shù)，真的有一種“曾經(jīng)滄海難為水”的感覺。

代碼修復(fù)

代碼修復(fù)有兩大主要方案，一種是阿里系的底層替換方案，另一種是騰訊系的類加載方案。

這兩類方案各有優(yōu)劣：

• 底層替換方案限制頗多，但時效性最好，加載輕快，立即見效。
• 類加載方案時效性差，需要重新冷啟動才能見效，但修復(fù)范圍廣，限制少。

底層替換方案

底層替換方案是在已經(jīng)加載了的類中直接替換掉原有方法，是在原來類的基礎(chǔ)上進行修改的。因而無法實現(xiàn)對與原有類進行方法和字段的增減，因為這樣將破壞原有類的結(jié)構(gòu)。

一旦補丁類中出現(xiàn)了方法的增加和減少，就會導(dǎo)致這個類以及整個Dex的方法數(shù)的變化。方法數(shù)的變化伴隨著方法索引的變化，這樣在訪問方法時就無法正常地索引到正確的方法了。

如果字段發(fā)生了增加和減少，和方法變化的情況一樣，所有字段的索引都會發(fā)生變化。并且更嚴重的問題是，如果在程序運行中間某個類突然增加了一個字段，那么對于原先已經(jīng)產(chǎn)生的這個類的實例，它們還是原來的結(jié)構(gòu)，這是無法改變的。而新方法使用到這些老的實例對象時，訪問新增字段就會產(chǎn)生不可預(yù)期的結(jié)果。

這是這類方案的固有限制，而底層替換方案最為人詬病的地方，在于底層替換的不穩(wěn)定性。

傳統(tǒng)的底層替換方式，不論是Dexposed、Andfix或者其他安全界的Hook方案，都是直接依賴修改虛擬機方法實體的具體字段。例如，改Dalvik方法的jni函數(shù)指針、改類或方法的訪問權(quán)限等等。這樣就帶來一個很嚴重的問題，由于Android是開源的，各個手機廠商都可以對代碼進行改造，而Andfix里ArtMethod的結(jié)構(gòu)是根據(jù)公開的Android源碼中的結(jié)構(gòu)寫死的。如果某個廠商對這個ArtMethod結(jié)構(gòu)體進行了修改，就和原先開源代碼里的結(jié)構(gòu)不一致，那么在這個修改過了的設(shè)備上，通用性的替換機制就會出問題。這便是不穩(wěn)定的根源。

而我們也對代碼的底層替換原理重新進行了深入思考，從克服其限制和兼容性入手，以一種更加優(yōu)雅的替換思路，實現(xiàn)了即時生效的代碼熱修復(fù)。我們實現(xiàn)的是一種無視底層具體結(jié)構(gòu)的替換方式，也就是把原先這樣的逐一替換 ：

變成了這樣的整體替換 :

這么一來，我們不僅解決了兼容性問題，并且由于忽略了底層ArtMethod結(jié)構(gòu)的差異，對于所有的Android版本都不再需要區(qū)分，代碼量大大減少。即使以后的Android版本不斷修改ArtMethod的成員，只要保證ArtMethod數(shù)組仍是以線性結(jié)構(gòu)排列，就能直接適用于將來的Android 8.0、9.0等新版本，無需再針對新的系統(tǒng)版本進行適配了。

事實也證明確實如此，當我們拿到Google剛發(fā)不久的Android O(8.0)開發(fā)者預(yù)覽版的系統(tǒng)時，hotfix demo直接就能順利地加載補丁跑起來了，我們并沒有做任何適配工作，穩(wěn)定性極好。

類加載方案

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

再來看看騰訊系三大類加載方案的實現(xiàn)原理。QQ空間方案會侵入打包流程，并且為了hack添加一些無用的信息，實現(xiàn)起來很不優(yōu)雅。而QFix的方案，需要獲取底層虛擬機的函數(shù)，不夠穩(wěn)定可靠，并且有個比較大的問題是無法新增public函數(shù)。

微信的Tinker方案是完整的全量dex加載，并且可謂是將補丁合成做到了極致，然而我們發(fā)現(xiàn)，精密的武器并非適用于所有戰(zhàn)場。Tinker的合成方案，是從dex的方法和指令維度進行全量合成，整個過程都是自己研發(fā)的。

雖然可以很大地節(jié)省空間，但由于對dex內(nèi)容的比較粒度過細，實現(xiàn)較為復(fù)雜，性能消耗比較嚴重。實際上，dex的大小占整個apk的比例是比較低的，一個app里面的dex文件大小并不是主要部分，而占空間大的主要還是資源文件。因此，Tinker方案的時空代價轉(zhuǎn)換的性價比不高。

其實，dex比較的最佳粒度，應(yīng)該是在類的維度。它既不像方法和指令維度那樣的細微，也不像bsbiff比較那般的粗糙。在類的維度，可以達到時間和空間平衡的最佳效果。基于這個準則，我們另辟蹊徑，實現(xiàn)了一種完全不同的全量dex替換方案。

我們采用的也是全量合成dex的技術(shù)，這個技術(shù)是從手淘插件化框架Atlas汲取的。我們會直接利用Android原先的類查找和合成機制，快速合成新的全量dex。這么一來，我們既不需要處理合成時方法數(shù)超過的情況，對于dex的結(jié)構(gòu)也不用進行破壞性重構(gòu)。

手淘插件化框架Atlas下載：

https://github.com/alibaba/atlas

從圖中可以看到，我們重新編排了包中dex的順序。這樣，在虛擬機查找類的時候，會優(yōu)先找到classes.dex中的類，然后才是classes2.dex、classes3.dex，也可以看做是dex文件級別的類插樁方案。這個方式十分巧妙，它對舊包與補丁包中classes.dex的順序進行了打破與重組，最終使得系統(tǒng)可以自然地識別到這個順序，以實現(xiàn)類覆蓋的目的。這將會大大減少合成補丁的開銷。

雙劍合璧

既然底層替換方案和類加載方案各有其優(yōu)點，把他們聯(lián)合起來不是最好的選擇嗎?Sophix的代碼修復(fù)體系正是同時涵蓋了這兩種方案。兩種方案的結(jié)合，可以實現(xiàn)優(yōu)勢互補，完全兼顧的作用，可以靈活地根據(jù)實際情況自動切換。

這兩種方案我們都進行了重大的改進，并且從補丁生成到應(yīng)用的各個環(huán)節(jié)都進行了研究，使得二者能很好地整合在一起。在補丁生成階段，補丁工具會根據(jù)實際代碼變動情況進行自動選擇，針對小修改，在底層替換方案限制范圍內(nèi)的，就直接采用底層替換修復(fù)嗎，這樣可以做到代碼修復(fù)即時生效。而對于代碼修改超出底層替換限制的，會使用類加載替換，這樣雖然及時性沒那么好，但總歸可以達到熱修復(fù)的目的。

另外，運行時階段，Sophix還會再判斷所運行的機型是否支持熱修復(fù)，這樣即使補丁支持熱修復(fù)，但由于機型底層虛擬機構(gòu)造不支持，還是會走類加載修復(fù)，從而達到最好的兼容性。

資源修復(fù)

目前市面上的很多資源熱修復(fù)方案基本上都是參考了Instant Run的實現(xiàn)。實際上，Instant Run的推出正是推動這次熱修復(fù)浪潮的主因，各家熱修復(fù)方案，在代碼、資源等方面的實現(xiàn)，很大程度上地參考了Instant Run的代碼，而資源修復(fù)方案正是被拿來用到最多的地方。

簡要說來，Instant Run中的資源熱修復(fù)分為兩步：

1. 構(gòu)造一個新的AssetManager，并通過反射調(diào)用addAssetPath，把這個完整的新資源包加入到AssetManager中。這樣就得到了一個含有所有新資源的AssetManager。

2. 找到所有之前引用到原有AssetManager的地方，通過反射，把引用處替換為AssetManager。

我們發(fā)現(xiàn)，其實大量代碼都是在處理兼容性問題和找到所有AssetManager的引用處，真正的替換的邏輯其實很簡單。

我們的方案沒有直接使用Instant Run的技術(shù)，而是另辟蹊徑，構(gòu)造了一個package id為0x66的資源包，這個包里只包含改變了的資源項，然后直接在原有AssetManager中addAssetPath這個包就可以了。

由于補丁包的package id為0x66，不與目前已經(jīng)加載的0x7f沖突，因此直接加入到已有的AssetManager中就可以直接使用了。補丁包里面的資源，只包含原有包里面沒有而新的包里面有的新增資源，以及原有內(nèi)容發(fā)生了改變的資源。并且，我們采用了更加優(yōu)雅的替換方式，直接在原有的AssetManager對象上進行析構(gòu)和重構(gòu)，這樣所有原先對AssetManager對象的引用是沒有發(fā)生改變的，所以就不需要像Instant Run那樣進行繁瑣的修改了。

可以說，我們的資源修復(fù)方案，優(yōu)越性超過了Google官方的Instant Run方案。整個資源替換的方案優(yōu)勢在于：

1. 不修改AssetManager的引用處，替換更快更完全。(對比Instanat Run以及所有copycat的實現(xiàn))

2. 不必下發(fā)完整包，補丁包中只包含有變動的資源。(對比Instanat Run、Amigo等方式的實現(xiàn))

3. 不需要在運行時合成完整包。不占用運行時計算和內(nèi)存資源。(對比Tinker的實現(xiàn))

所以，我們不要被所謂的“官方實現(xiàn)”束縛住手腳，其實Instant Run的開發(fā)團隊和Android framework的開發(fā)團隊并不是同一個團隊，他們對于Android系統(tǒng)機制的理解未必十分深入。只要你認真研讀系統(tǒng)代碼，實現(xiàn)一個比官方更好的方案絕非難事。所以我想說的是，要想實現(xiàn)技術(shù)方案的突破，首先就需要破除所謂“權(quán)威”的觀念。

資源修復(fù)的更多技術(shù)細節(jié)，可通過這篇文章一探究竟：Android熱修復(fù)升級探索——資源更新之新思路

so庫修復(fù)

so庫的修復(fù)本質(zhì)上是對native方法的修復(fù)和替換。

我們知道JNI編程中，native方法可以通過動態(tài)注冊和靜態(tài)注冊兩種方式進行。動態(tài)注冊的native方法必須實現(xiàn)`JNI_OnLoad`方法，同時實現(xiàn)一個`JNINativeMethod[]`數(shù)組，靜態(tài)注冊的native方法必須是`Java+類完整路徑+方法名`的格式。

動態(tài)注冊的native方法映射通過加載so庫過程中調(diào)用JNI_OnLoad方法調(diào)用完成，靜態(tài)注冊的native方法映射是在該native方法第一次執(zhí)行的時候才完成映射，當然前提是該so庫已經(jīng)load過。

我們采用的是類似類修復(fù)反射注入方式。把補丁so庫的路徑插入到nativeLibraryDirectories數(shù)組的最前面，就能夠達到加載so庫的時候是補丁so庫，而不是原來so庫的目錄，從而達到修復(fù)的目的。

采用這種方案，完全由Sophix在啟動期間反射注入patch中的so庫。對開發(fā)者依然是透明的。不用像某些其他方案需要手動替換系統(tǒng)的System.load來實現(xiàn)替換目的。

未來展望

熱修復(fù)的必要性

熱修復(fù)是一個與業(yè)務(wù)完全無關(guān)的模塊，開發(fā)者如果要自己實現(xiàn)一套可靠的熱修復(fù)框架，將花費大量時間和精力。雖然市面上已經(jīng)有很多開源的熱修復(fù)實現(xiàn)，然而其中的很多坑，往往要踩過才知道，等你把這些坑一一踩過之后，可能大量的用戶已經(jīng)對你失去信心。所以，依靠一個穩(wěn)定可靠、而且簡單實用的商業(yè)版本，反而能使各方面的成本降到最低。并且，熱修復(fù)并不是簡單的客戶端SDK，它還包含了安全機制和服務(wù)端的控制邏輯，這整條鏈路也不是短時間內(nèi)可以快速完成的。

還是那句老話，專業(yè)是事交給專業(yè)的人去做。開發(fā)者應(yīng)該把更多時間精力放到自己的核心業(yè)務(wù)之中。

Sophix提供了一套更加完美的客戶端服務(wù)端一體的熱更新方案。做到了圖形界面一鍵打包、加密傳輸、簽名校驗和服務(wù)端控制發(fā)布與灰度功能，讓你用最少的時間實現(xiàn)最強大可靠的全方位熱更新。并且在代碼修復(fù)、資源修復(fù)、SO庫修復(fù)方面，都做到了業(yè)界最佳。

對Android的生態(tài)的影響

很多人會把熱修復(fù)技術(shù)跟其他國內(nèi)廠商的“黑科技”混為一談。有人說，你們國內(nèi)開發(fā)者就是瞎搞，就不能給我們Android用戶一個更加純凈的環(huán)境嗎?

這里我需要澄清一下。熱修復(fù)技術(shù)不同于其他國內(nèi)的Android“黑科技”。就比如，國內(nèi)Android進程保活，是讓app持續(xù)駐留在后臺避免被系統(tǒng)殺死，這既耗費手機電量又占內(nèi)存，浪費了很多手機資源。再比如，app自行定制的推送服務(wù)，無節(jié)操地對用戶進行信息轟炸。還有更過分的全家桶，一個app同時拉起一票app，并且長期占著內(nèi)存，使得手機卡頓不堪。總歸，這些技術(shù)都是為了app廠商的利益而損害手機使用者的實際體驗。

而熱修復(fù)技術(shù)是完全不同的，它達到的是一個手機用戶和開發(fā)者雙贏的目的。不僅廠商可以快速迭代更新app，使得功能能最快上線。并且由于熱更新過程是毫無感知的，手機用戶也減少了繁瑣的更新步驟，節(jié)省了大量等待更新的時間。這實際上是改善了Android的生態(tài)環(huán)境。只是這其中最重要的，是要保證熱修復(fù)功能的穩(wěn)定性。而Sophix的穩(wěn)定性，是經(jīng)過了無數(shù)開發(fā)者檢驗的，并且還有手淘多年深厚的技術(shù)沉淀作為保障。

Android與iOS熱修復(fù)的不同

前段時間，蘋果封殺了iOS的熱修復(fù)功能，這給iOS的開發(fā)者帶來了很大困擾。

熱修復(fù)功能被禁止，會使得很多app不得不靠直接發(fā)版進行更新，這樣一旦新版本出了問題，整個更新迭代過程變得十分漫長。并且一些試驗性功能無法進行灰度，這就使得一個重要功能的更新將直接全量發(fā)版，如果功能不夠穩(wěn)定，波及范圍就變得非常廣。而且，用戶需要重新下載整個app，不僅流程漫長，原本不到1MB的補丁就能解決的事，現(xiàn)在不得不下載幾十甚至上百MB的完整包才能更新。

蘋果這一政策的推出，使得很多人也因此不看好Android的熱修復(fù)技術(shù)了。在這里，我們可以打消這種錯誤的觀念。因為Android的情況和iOS是有極大不同的。主要有兩個方面：

1. 谷歌和蘋果在中國的地位不同

2. Android和iOS的開放性不同

谷歌在中國沒有像蘋果那樣的控制力，即使它想要封殺也不可能，國內(nèi)是有各個安卓應(yīng)用市場的，沒有統(tǒng)一的app安裝渠道。另外，Android是開源的，各個廠商都可以做定制，想統(tǒng)一各家的安裝渠道幾乎是不可能的。

未來，無限可能

我們對于未來是很樂觀的，Android的熱修復(fù)領(lǐng)域不僅不會受到封殺，反而還有很大的發(fā)展空間。我們正在嘗試支持各大加固廠商，目前阿里聚安全修復(fù)已經(jīng)支持了Sophix，熱修復(fù)結(jié)合安全加固，將會使得app的穩(wěn)定性和安全性大大提高，更加堅不可摧。甚至后續(xù)還可以與系統(tǒng)廠商合作，對系統(tǒng)app乃至系統(tǒng)組件進行修復(fù)，這樣就可以避免頻繁O(jiān)TA升級。

因此，熱修復(fù)所能發(fā)揮是價值將是十分巨大的。熱修復(fù)還可以與其他領(lǐng)域進行碰撞，引發(fā)無限的可能性。在這里，我們非常期待攜手廣大應(yīng)用廠商以及ROM廠商，共同推動Android的生態(tài)更加完善。

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文