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

[[193982]]

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

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

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

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

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

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

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

設(shè)計(jì)理念

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

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

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

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

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

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

詳細(xì)比較

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

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

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

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

技術(shù)分析

Sophix的誕生，起初是對(duì)原先的阿里百川Hotfix 1.X版本進(jìn)行升級(jí)衍進(jìn)。

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

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

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

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

代碼修復(fù)

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

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

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

底層替換方案

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

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

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

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

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

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

變成了這樣的整體替換 :

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

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

類加載方案

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

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

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

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

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

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

手淘插件化框架Atlas下載：

https://github.com/alibaba/atlas

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

雙劍合璧

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

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

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

資源修復(fù)

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

簡(jiǎn)要說來(lái)，Instant Run中的資源熱修復(fù)分為兩步：

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

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

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

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

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

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

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

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

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

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

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

so庫(kù)修復(fù)

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

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

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

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

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

未來(lái)展望

熱修復(fù)的必要性

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

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

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

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

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

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

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

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

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

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

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

1. 谷歌和蘋果在中國(guó)的地位不同

2. Android和iOS的開放性不同

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

未來(lái)，無(wú)限可能

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

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

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

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