一、熱修復技術(shù)方案概況：
1、技術(shù)概況：
2015年以來，Android開發(fā)領(lǐng)域里對熱修復技術(shù)的討論和分享越來越多，同時也出現(xiàn)了一些不同的解決方案，如QQ空間補丁方案、阿里AndFix以及微信Tinker（Bugly sdk也集成Tikner熱更新）和阿里最新出品Sophix.它們在原理各有不同，適用場景各異，到底采用哪種方案，是開發(fā)者比較頭疼的問題。下面是這幾種技術(shù)方案介紹。
技術(shù)背景
一、正常開發(fā)流程
從流程來看，傳統(tǒng)的開發(fā)流程存在很多弊端：
·重新發(fā)布版本代價太大
·用戶下載安裝成本太高
·
BUG修復不及時，用戶體驗太差
二、熱修復開發(fā)流程
而熱修復的開發(fā)流程顯得更加靈活，優(yōu)勢很多：
·無需重新發(fā)版，實時高效熱修復
·用戶無感知修復，無需下載新的應用，代價小
·修復成功率高，把損失降到最低
2、熱修復對銘師堂的其他意義：
? ? ? 對當虹播放器的支持，從我們協(xié)作的情況來看，當虹播放器出現(xiàn)升級的概率很大，特別是修改臨時的BUG，對他們開放一個綠色的通道，而不走我們正常的發(fā)布流程，對我們的用戶損傷較小。
? ? ? APP小型調(diào)整，類似于一些非產(chǎn)品型迭代的，比如界面微調(diào)，緊急BUG修復，用戶協(xié)議變更或者公司名稱變更等等，熱修復技術(shù)這些對我們的產(chǎn)品體驗非常好。
二、業(yè)界熱門的熱修復技術(shù)
熱修復作為當下熱門的技術(shù)，在業(yè)界內(nèi)比較著名的有阿里巴巴的AndFix、Dexposed，騰訊QQ空間的超級補丁和微信的Tinker。最近阿里百川推出的HotFix熱修復服務就基于AndFix技術(shù)，定位于線上緊急BUG的即時修復，所以AndFix技術(shù)這塊我們重點分析阿里百川HotFix。下面，我們就分別介紹QQ空間超級熱補丁技術(shù)和微信Tinker以及阿里百川的HotFix技術(shù)。
1、QQ空間超級補丁技術(shù)
超級補丁技術(shù)基于DEX分包方案，使用了多DEX加載的原理，大致的過程就是：把BUG方法修復以后，放到一個單獨的DEX里，插入到dexElements數(shù)組的最前面，讓虛擬機去加載修復完后的方法
當patch.dex中包含Test.class時就會優(yōu)先加載，在后續(xù)的DEX中遇到Test.class的話就會直接返回而不去加載，這樣就達到了修復的目的。
但是有一個問題是，當兩個調(diào)用關(guān)系的類不在同一個DEX時，就會產(chǎn)生異常報錯。我們知道，在APK安裝時，虛擬機需要將classes.dex優(yōu)化成odex文件，然后才會執(zhí)行。在這個過程中，會進行類的verify操作，如果調(diào)用關(guān)系的類都在同一個DEX中的話就會被打上`CLASS_ISPREVERIFIED`的標志，然后才會寫入odex文件。
所以，為了可以正常地進行打補丁修復，必須避免類被打上`CLASS_ISPREVERIFIED`標志，具體的做法就是單獨放一個類在另外DEX中，讓其他類調(diào)用。
修復的步驟為：
1.可以看出是通過獲取到當前應用的Classloader，即為BaseDexClassloader
2.通過反射獲取到他的DexPathList屬性對象pathList
3.通過反射調(diào)用pathList的dexElements方法把patch.dex轉(zhuǎn)化為Element[]
4.兩個Element[]進行合并，把patch.dex放到最前面去
5.加載Element[]，達到修復目的
整體的流程圖如下：
從流程圖來看，可以很明顯的找到這種方式的特點：
優(yōu)勢：
1.沒有合成整包(和微信Tinker比起來)，產(chǎn)物比較小，比較靈活
2.可以實現(xiàn)類替換，兼容性高。(某些三星手機不起作用)
不足：
1.不支持即時生效，必須通過重啟才能生效。
2.為了實現(xiàn)修復這個過程，必須在應用中加入兩個dex!dalvikhack.dex中只有一個類，對性能影響不大，但是對于patch.dex來說，修復的類到了一定數(shù)量，就需要花不少的時間加載。對手淘這種航母級應用來說，啟動耗時增加2s以上是不能夠接受的事。
3.在ART模式下，如果類修改了結(jié)構(gòu)，就會出現(xiàn)內(nèi)存錯亂的問題。為了解決這個問題，就必須把所有相關(guān)的調(diào)用類、父類子類等等全部加載到patch.dex中，導致補丁包異常的大，進一步增加應用啟動加載的時候，耗時更加嚴重。
2、微信Tinker
微信針對QQ空間超級補丁技術(shù)的不足提出了一個提供DEX差量包，整體替換DEX的方案。主要的原理是與QQ空間超級補丁技術(shù)基本相同，區(qū)別在于不再將patch.dex增加到elements數(shù)組中，而是差量的方式給出patch.dex，然后將patch.dex與應用的classes.dex合并，然后整體替換掉舊的DEX文件，以達到修復的目的。
整體的流程如下：
從流程圖來看，同樣可以很明顯的找到這種方式的特點：
優(yōu)勢：
1.合成整包，不用在構(gòu)造函數(shù)插入代碼，防止verify，verify和opt在編譯期間就已經(jīng)完成，不會在運行期間進行。
2.性能提高。兼容性和穩(wěn)定性比較高。
3.開發(fā)者透明，不需要對包進行額外處理。
不足：
1.與超級補丁技術(shù)一樣，不支持即時生效，必須通過重啟應用的方式才能生效。
2.需要給應用開啟新的進程才能進行合并，并且很容易因為內(nèi)存消耗等原因合并失敗。
3.合并時占用額外磁盤空間，對于多DEX的應用來說，如果修改了多個DEX文件，就需要下發(fā)多個patch.dex與對應的classes.dex進行合并操作時這種情況會更嚴重，因此合并過程的失敗率也會更高。
3、阿里百川HotFix
阿里百川推出的熱修復HotFix服務，相對于QQ空間超級補丁技術(shù)和微信Tinker來說，定位于緊急BUG修復的場景下，能夠最及時的修復BUG，下拉補丁立即生效無需等待。
1、AndFix實現(xiàn)原理
AndFix不同于QQ空間超級補丁技術(shù)和微信Tinker通過增加或替換整個DEX的方案，提供了一種運行時在Native修改Filed指針的方式，實現(xiàn)方法的替換，達到即時生效無需重啟，對應用無性能消耗的目的。
原理圖如下：
2、AndFix實現(xiàn)過程
對于實現(xiàn)方法的替換，需要在Native層操作，經(jīng)過三個步驟：
AndFix對ART設(shè)備支持，過程與Dalvik相似。
從技術(shù)原理，不難看出阿里百川HotFix的幾個特點：
優(yōu)勢：
1.
BUG修復的即時性
2.補丁包同樣采用差量技術(shù)，生成的PATCH體積小
3.對應用無侵入，幾乎無性能損耗
不足：
1.不支持新增字段，以及修改方法，也不支持對資源的替換。
2.由于廠商的自定義ROM，對少數(shù)機型暫不支持。兼容性差。
（每一個java方法在art種都對應一個ArtMethod, ArtMethod記錄了這個java方法的所有信息，包括所屬類，訪問權(quán)限、代碼執(zhí)行地址。
通過evn->FromReflectedMethod,可以由Method對象得到這個方法對應的ArtMethod的真正其實地址，然后就可以把它強轉(zhuǎn)為ArtMethod指針，從而對其所有的成員進行修改。這樣就全部替換完之后就完成了熱修復邏輯。以后調(diào)用這個方法時就會直接走到新方法的實現(xiàn)中了。
然而由于andfix里面的ArtMethod的結(jié)構(gòu)體遵照android虛擬機art源碼里面的ArtMethod構(gòu)建的，各個手機廠商對這個ArtMethod結(jié)構(gòu)體進行修改就會導致喝原來開源代碼里面的結(jié)構(gòu)不一致，那么在這個修改過的設(shè)備上，替換機制就會出問題，無法正常執(zhí)行熱修復邏輯。）
綜合分析如下：
3、對比總結(jié)：
? ?1）、qq空間超級補丁，微信Tinker類似多DEX帶來的性能影響
我們知道，多DEX方案原來是用于解決應用方法數(shù)65k的問題，現(xiàn)在google也官方支持了MultiDex的實現(xiàn)方案。超級補丁技術(shù)和Tinker卻作為一種熱修復的方案，平生給應用增加了多個DEX，而多DEX技術(shù)最大的問題在于性能上的坑，因此基于這種方案的補丁技術(shù)影響應用的性能是無疑的。
? ? 啟動加載時間過長
我們可以看到，超級補丁技術(shù)和Tinker都選擇在Application的attachBaseContext()進行補丁dex的加載，即時這是加載dex的最佳時機，但是依然會帶來很大的性能問題，首當其沖的就是啟動時間太長。
對于補丁DEX來說，應用啟動時虛擬機會進行dexopt操作，將patch.dex文件轉(zhuǎn)換成odex文件，這個過程本身非常耗時。而這個過程又要求在主線程中，以同步的方式執(zhí)行，否則無法成功進行修復。就DEX的加載時間，大概做了以下的時間測試。
通過上表可以看到，隨著patch.dex的尺寸增加，在不做任何優(yōu)化的情況下，啟動時間也直線增長。對于一個應用來說，這簡直是災難性的。
? ?易造成應用的ANR和Crash
由于多DEX加載導致了啟動時間變長，這樣更容易引發(fā)應用的ANR。我們知道當應用在主線程等待超過5s以后，就會直接導致長時間無響應而退出。超級補丁技術(shù)為保證ART不出現(xiàn)地址錯亂問題，需要將所有關(guān)聯(lián)的類全部加入到補丁中，而微信Tinker采取一種差量包合并加載的方式，都會使要加載的DEX體積變得很大。這也很大程度上容易導致ANR情況的出現(xiàn)。
除了應用ANR以外，多DEX模式也同樣很容易導致Crash情況的出現(xiàn)。在ART設(shè)備中為了保證不出現(xiàn)地址錯亂，需要把修改類的所有相關(guān)類全部加入到補丁中，這里會出現(xiàn)一個問題，為了保證補丁包的體積最小，能否保證引入全部的關(guān)聯(lián)類而不引入無關(guān)的類呢?一旦沒有引入關(guān)聯(lián)的類，就會出現(xiàn)以下的異常：
·NoClassDefFoundError
·Could Not Find Class
·Could Not Find Method
出現(xiàn)這些異常，就會直接導致應用的Crash退出。
所以，不難看出如果我們需要修復一個不是Crash的BUG，但是因為未加入相關(guān)類而導致了更嚴重的Crash，就更加的得不償失。
總的來說，熱修復本質(zhì)的目的是為了保證應用更加穩(wěn)定，而不是為了更強大的功能引入更大的風險和不穩(wěn)定性。
2）、熱修復or插件化?
我們經(jīng)常提到熱修復和插件化，這都是當下熱門的新興技術(shù)。在講述之前，需要對這兩個概念進行一下解釋。
·熱修復：當線上應用出現(xiàn)緊急BUG，為了避免重新發(fā)版，并且保證修復的及時性而進行的一項在線推送補丁的修復方案。
·插件化：一個程序劃分為不同的部分，以插件的形式加載到應用中去，本質(zhì)上它使用的技術(shù)還是熱修復技術(shù)，只是加入了更多工程實踐，讓它支持大規(guī)模的代碼更新以及資源和SO包的更新。
顯然，從概念上我們可以看到，插件化使用場景更多是功能上的，熱修復強調(diào)微小的修復。從這個層面來說，插件化必然功能更加強大，能做的事情也更多。QQ空間超級補丁技術(shù)和微信Tinker從類、資源的替換和更新上來看，與其說是熱修復，不如說是插件化技術(shù)的實踐。
QQ空間超級補丁技術(shù)和微信Tinker提供了更加強大的功能，但是對應用的性能和穩(wěn)定有較大的影響，就BUG修復的這個使用場景上還不夠明確，并且顯得過重。在插件化開發(fā)上，有用武之地。
同樣andfix兼容又有很大的問題。
三、Sophix閃亮等場：
終于進入主題阿里最新推出的熱修復方案技術(shù)sophfix.
1、概述：
1）、Sophix設(shè)計理念：
Sophix的核心設(shè)計理念，就是非侵入性。
我們的打包過程不會侵入到apk的build流程中。我們所需要的，只有已經(jīng)生成完畢的新舊apk，而至于apk是如何生成的——是Android
Studio打包出來的、還是Eclipse打包出來的、或者是自定義的打包流程，我們一律不關(guān)心。在生成補丁的過程中間既不會改變?nèi)魏未虬M件，也不插入任何AOP代碼，我們極力做到了——不添加任何超出開發(fā)者預期的代碼，以避免多余的熱修復代碼給開發(fā)者帶來困擾。
在Sophix中，唯一需要的就是初始化和請求補丁兩行代碼，甚至連入口Application類我們都不做任何修改，這樣就給了開發(fā)者最大的透明度和自由度。我們甚至重新開發(fā)了打包工具，使得補丁工具操作圖形界面化，這種所見即所得的補丁生成方式也是阿里熱修復獨家的。因此，Sophix的接入成本也是目前市面上所有方案里最低的。
這種非侵入式熱更新理念，是我們在設(shè)計過程中從用戶使用角度進行了深入思考而提煉出的核心思想。
這里的用戶，指的自然是廣大的開發(fā)者。對于開發(fā)者而言，熱修復應該是一個與業(yè)務無關(guān)的SDK組件，在整個開發(fā)過程中感知不到它的存在。最理想的情況，就是開發(fā)者拿過來兩個apk，一個是已經(jīng)安裝在手機上的apk，另一個是將要發(fā)布出去的apk。我們直接通過工具，就可以根據(jù)這兩個apk生成補丁，然后把這個補丁下發(fā)給已經(jīng)安裝的舊app上，就可以直接加載，使舊app重生為新的app。而這個加載了補丁包新app，在功能和使用上，將會和直接安裝新apk別無二致。
2）、Sophfix與其他熱修復方案對比：
可以看到，Sophix在各個指標上全面占優(yōu)。而其中唯一不支持的地方就是四大組件的修復，這是因為如果要修復四大組件，必須在AndroidManifest里面預先插入代理組件，并且盡可能聲明所有權(quán)限，而這么做就會給原先的app添加很多臃腫的代碼，對app運行流程的侵入性很強。
Sophix支持代碼修復、資源修復、so庫修復。下面對這三種修復進行介紹。
2、代碼修復
代碼修復有兩大主要方案，一種是阿里系的底層替換方案，另一種是騰訊系的類加載方案。
這兩類方案各有優(yōu)劣：
底層替換方案限制頗多，但時效性最好，加載輕快，立即見效。
類加載方案時效性差，需要重新冷啟動才能見效，但修復范圍廣，限制少。
1）、底層替換方案
底層替換方案是在已經(jīng)加載了的類中直接替換掉原有方法，是在原來類的基礎(chǔ)上進行修改的。因而無法實現(xiàn)對與原有類進行方法和字段的增減，因為這樣將破壞原有類的結(jié)構(gòu)。
一旦補丁類中出現(xiàn)了方法的增加和減少，就會導致這個類以及整個Dex的方法數(shù)的變化。方法數(shù)的變化伴隨著方法索引的變化，這樣在訪問方法時就無法正常地索引到正確的方法了。
如果字段發(fā)生了增加和減少，和方法變化的情況一樣，所有字段的索引都會發(fā)生變化。并且更嚴重的問題是，如果在程序運行中間某個類突然增加了一個字段，那么對于原先已經(jīng)產(chǎn)生的這個類的實例，它們還是原來的結(jié)構(gòu)，這是無法改變的。而新方法使用到這些老的實例對象時，訪問新增字段就會產(chǎn)生不可預期的結(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)了即時生效的代碼熱修復。sophix實現(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ā)者預覽版的系統(tǒng)時，hotfix demo直接就能順利地加載補丁跑起來了，我們并沒有做任何適配工作，穩(wěn)定性極好。
2）、類加載方案
類加載方案的原理是在app重新啟動后讓Classloader去加載新的類。因為在app運行到一半的時候，所有需要發(fā)生變更的類已經(jīng)被加載過了，在Android上是無法對一個類進行卸載的。如果不重啟，原來的類還在虛擬機中，就無法加載新類。因此，只有在下次重啟的時候，在還沒走到業(yè)務邏輯之前搶先加載補丁中的新類，這樣后續(xù)訪問這個類時，就會Resolve為新類。從而達到熱修復的目的。
再來看看騰訊系三大類加載方案的實現(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)較為復雜，性能消耗比較嚴重。實際上，dex的大小占整個apk的比例是比較低的，一個app里面的dex文件大小并不是主要部分，而占空間大的主要還是資源文件。因此，Tinker方案的時空代價轉(zhuǎn)換的性價比不高。
其實，dex比較的最佳粒度，應該是在類的維度。它既不像方法和指令維度那樣的細微，也不像bsbiff比較那般的粗糙。在類的維度，可以達到時間和空間平衡的最佳效果?；谶@個準則，我們另辟蹊徑，實現(xiàn)了一種完全不同的全量dex替換方案。
sophix采用的也是全量合成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)類覆蓋的目的。這將會大大減少合成補丁的開銷。
3）、雙劍合璧
既然底層替換方案和類加載方案各有其優(yōu)點，把他們聯(lián)合起來不是最好的選擇嗎?Sophix的代碼修復體系正是同時涵蓋了這兩種方案。兩種方案的結(jié)合，可以實現(xiàn)優(yōu)勢互補，完全兼顧的作用，可以靈活地根據(jù)實際情況自動切換。
這兩種方案我們都進行了重大的改進，并且從補丁生成到應用的各個環(huán)節(jié)都進行了研究，使得二者能很好地整合在一起。在補丁生成階段，補丁工具會根據(jù)實際代碼變動情況進行自動選擇，針對小修改，在底層替換方案限制范圍內(nèi)的，就直接采用底層替換修復嗎，這樣可以做到代碼修復即時生效。而對于代碼修改超出底層替換限制的，會使用類加載替換，這樣雖然及時性沒那么好，但總歸可以達到熱修復的目的。
另外，運行時階段，Sophix還會再判斷所運行的機型是否支持熱修復，這樣即使補丁支持熱修復，但由于機型底層虛擬機構(gòu)造不支持，還是會走類加載修復，從而達到最好的兼容性。最后也要注意
2、資源修復
android資源熱修復，就是在app不重新安裝的情況下，利用下發(fā)補丁包直接更新本app中的資源。
目前市面上的資源熱修復方案基本上都是參考Instant Run的實現(xiàn)。Instant Run實現(xiàn)過程大概分為兩部：
1、構(gòu)造一個新的AssetManager,并通過反射條用addAssetPath,把這個完整的新資源包加入到AssetManager中。這樣就得到了一個含有所有新資源的AssetManager。
2、找到所有之前引用到原油AssetManager的地方，通過反射，把引用處替換為AssetManager
這種方式下發(fā)完整的包很占用空間。而像有些方案，是先進行對資源包做差量，在運行時合成完整包再加載。這樣確實減少包的體積，但是在運行時多了合成的操作，耗費了運行時間喝內(nèi)存。合成后的包也是完整的包，仍舊會占磁盤空間。
Sophix采用的一種很巧妙的方式，構(gòu)造一個package id為0x66的資源包，這個包里面只包含改變了的資源項，然后直接在原來的AssetManager中addAssetPaht這個包。然后，就可以了。憂郁補丁包的package id為0x66和原來文件的package id為0x7f不沖突，因此直接加入到一有的AssetManager中就直接使用了。補丁包里面的資源，只包含原油包里面沒有而新包里有的資源以及內(nèi)容發(fā)生改變的資源。
資源的改變包含增加、減少、修改，分別處理方法如下：
1、新增資源，直接加入布丁包
2、減少的資源，我們只要不使用就行了，因此不用考慮這種情況，它不影響布丁包
3、對于修改資源，比如替換了一張圖片之類的情況，我們把他視為新增資源，在打入補丁的時候，代碼在引用出也會做相應的修改，也就是直接把原來使用的舊資源id的地方變?yōu)樾耰d。
Sophix優(yōu)勢：
1.不修改AssetManager的引用處，替換更快更完全。(對比Instanat Run以及所有copycat的實現(xiàn))
2.不必下發(fā)完整包，補丁包中只包含有變動的資源。(對比Instanat Run、Amigo等方式的實現(xiàn))
3.不需要在運行時合成完整包。不占用運行時計算和內(nèi)存資源。(對比Tinker的實現(xiàn))
3、so庫修復
so庫的修復本質(zhì)上是對native方法的修復和替換。
我們知道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過。
我們采用的是類似類修復反射注入方式。把補丁so庫的路徑插入到nativeLibraryDirectories數(shù)組的最前面，就能夠達到加載so庫的時候是補丁so庫，而不是原來so庫的目錄，從而達到修復的目的。
采用這種方案，完全由Sophix在啟動期間反射注入patch中的so庫。對開發(fā)者依然是透明的。不用像某些其他方案需要手動替換系統(tǒng)的System.load來實現(xiàn)替換目的。
四、我為sophix背書：
? ? 我們在選擇熱修復的時候，常常選擇tinker或者sophix，那么我這里對tinker和sophix的感知再描述下：
1、TINKER的問題：
1）、如騰訊的X5一樣，外邊人用不好，騰訊內(nèi)部可以用，支持不好是騰訊對外產(chǎn)品的通病。以菜鳥我為例，我花了2個星期，對其DEMO的熱修復的包進行上傳，這個補丁包總是提醒 “未匹配到可以應用的APP補丁包版本“，DEMO都跑不通，最后用其他方式，集成在系統(tǒng)中才勉強上傳。
2）、需要冷啟動2次才生效，有時候包合并不好，甚至熱修復不生效。
3）、某些機型就是不支持，比如不支持部分三星android-19的機型，要命的是，他們不管，沒人服務，沒人服務，沒人服務。我們公司用得魅族魅藍3S也不支持。
2、sophix的好處：
1）、看得見服務，我調(diào)試sohpix解決各種問題，阿里幾乎是全程服務，有固定的群，有固定的人員專門對接。同事可以看到其他用戶的問題，比如4.3以下機型支持不好，阿里的技術(shù)人員說正在發(fā)補丁包，其他客戶催促說能不能快點，用戶等得很急。能夠走下神壇，和開發(fā)人員交流，這是一個產(chǎn)品能夠成功的根源，我欣賞sophix在處理他們的技術(shù)問題的這種態(tài)度，就因為這種態(tài)度，我愿意為他們背書。
2）、技術(shù)上目前看得見的地方：熱修復及時生效，補丁包小，能解決幾乎除四大組件更改之外的其他所有問題，接入簡單。
3、sophix的壞處：
如果是月活5萬以下的用戶數(shù)，是不需要給阿里繳費的，銘師堂開課啦的月活用戶在6萬多，屬于繳費的邊緣地帶，新航線當然不用繳費，E網(wǎng)通需要月繳費1萬元左右。交錢總是一件走流程的事情，一個流程走下來，一個月時間消耗掉了。
4、與阿里的產(chǎn)品聊天記錄：
? ? ? ? Q：熱修復資費
? ? ? ? A：資費標準參考官網(wǎng) https://help.aliyun.com/document_detail/57064.html
? ? ? ? ? ? ? 簡單來說有兩種：后付費，預付費（提前預估消費量，購買資源包，可以享受最低72折折扣）
? ? ? ? ? ? ? 熱修復計費單位主要app月活（MAU）設(shè)備，每月5W免費閾值。
? ? ? ? ? ? ? 價格速算公式：（MAU-50000)*0.0150/月 = 消費額/月
? ? ? ? ? ? ? 100W月活的app如下：
? ? ? ? ? ? ? ? ? ? ?后付費 14250 元/月
? ? ? ? ? ? ? ? ? ? ?預付費 10260 元/月
? ? ? ? ?Q：什么情況適合熱修復，什么情況適合全量發(fā)布？
? ? ? ? ? ? ? A：熱修復支持代碼，資源，so發(fā)布，但使用上也有一定的邊界。線上緊急問題修復和輕量級發(fā)布建議走熱修復，其它建議走全量發(fā)布，?
? ? ? ? ? ? ? 避免碎片化。熱修復接入以官網(wǎng)指導文檔為準。
? ? ? ? ?Q：熱修復是否支持iOS平臺
? ? ? ? ? ? ? ?A：阿里云熱修復支持iOS平臺，請注意保密。因為蘋果的審核和限制，官網(wǎng)只透出Android技術(shù)。
? ? ? ? ? ? ? ? ? ? ?如果使用iOS熱修復技術(shù)提供app-id 和 阿里云uid，后臺加白名單。
