橫空出世

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

最開始热某，是手淘基于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ù)可謂是百花齊放，微信的Tinker蒜鸡、QQ空間的Nuwa胯努、餓了么的Amigo、美團的Robust等等逢防，各個熱修復(fù)方案爭相發(fā)布叶沛，都聲稱自己可以做到全方位全功能的熱修復(fù)。不過他們各自有自身的局限性忘朝，或者不夠穩(wěn)定灰署，或者補丁過大，或者效率低下局嘁，或者使用起來過于繁瑣溉箕，大部分技術(shù)上看起來似乎可行，但實際體驗并不好悦昵。而在我們看來肴茄，有很多技術(shù)細節(jié)能夠做得更加完美。

終于在2017年6月11日但指，手淘技術(shù)團隊聯(lián)合阿里云正式發(fā)布了新一代Android移動熱修復(fù)方案——Sophix寡痰。

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ù)方案進行了比較宰睡。

方案對比SophixTinkerAmigo

DEX修復(fù)同時支持即時生效和冷啟動修復(fù)冷啟動修復(fù)冷啟動修復(fù)

資源更新差量包蒲凶，不用合成差量包，需要合成全量包拆内，不用合成

SO庫更新插樁實現(xiàn)旋圆，開發(fā)透明替換接口，開發(fā)不透明插樁實現(xiàn)矛纹，開發(fā)透明

性能損耗低臂聋，僅冷啟動情況下有些損耗高光稼，有合成操作低或南，全量替換

四大組件不能修復(fù)不能修復(fù)能修復(fù)

生成補丁直接選擇已經(jīng)編好的新舊包在本地生成編譯新包時設(shè)置基線包上傳完整新包到服務(wù)端

補丁大小小小大

接入成本傻瓜式接入復(fù)雜一般

Android版本全部支持全部支持全部支持

安全機制加密傳輸及簽名校驗加密傳輸及簽名校驗加密傳輸及簽名校驗

服務(wù)端支持支持服務(wù)端控制支持服務(wù)端控制支持服務(wù)端控制

可以看到，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)了方法的增加和減少卓箫，就會導致這個類以及整個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直接就能順利地加載補丁跑起來了号坡，我們并沒有做任何適配工作螃壤，魯棒性極好。

具體技術(shù)細節(jié)筋帖，可以看這篇文章：Android熱修復(fù)升級探索——追尋極致的代碼熱替換

類加載方案

類加載方案的原理是在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)惹骂。

從圖中可以看到苏携，我們重新編排了包中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ù)分為兩步：

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

找到所有之前引用到原有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)勢在于：

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

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

不需要在運行時合成完整包。不占用運行時計算和內(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ù)功能幸冻，很多人就因此不看好熱修復(fù)技術(shù)了粹庞。這里我想說的是，蘋果的政策并不能證明他有多先進洽损，相反庞溜，作為獨裁者，蘋果做過很多不得人心的事碑定，就比如前段時間封殺微信的文章打賞功能流码。熱修復(fù)功能被禁止，會使得很多app不得不靠直接發(fā)版進行更新延刘，這樣一旦新版本出了問題漫试，整個更新迭代過程變得十分漫長。并且一些試驗性功能無法進行灰度碘赖，這就使得一個重要功能的更新將直接全量發(fā)版驾荣，如果功能不夠穩(wěn)定，波及范圍就變得非常廣普泡。而且播掷，用戶需要重新下載整個app，不僅流程漫長撼班，原本不到1MB的補丁就能解決的事歧匈，現(xiàn)在不得不下載幾十MB的完整包才能更新。

再看回Android的情況权烧，Android熱修復(fù)和iOS是有極大不同的眯亦。主要有兩個方面：

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

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)更加完善携兵。

微信公眾號文章對應(yīng)鏈接：https://mp.weixin.qq.com/s/5KjSPvUflbg0pVRIjtLiRA