本篇內容主要講解“Android熱修復技術原理中的代碼熱修復技術是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Android熱修復技術原理中的代碼熱修復技術是什么”吧!

一、底層熱替換原理

1.1、Andfix 回顧

我們先來看一下，為何唯獨 Andfix 能夠做到即時生效呢？

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

Andfix 采用的方法是，在已經加載了的類中直接在 native層替換掉原有方法, 是在原來類的基礎上進行修改的。對于不同Android版本的art，底層Java對象的數據結構是不同的，因而會進一步區分不同的替換函數。每一個 Java 方法在 art 中都對應著一個 ArtMethod，ArtMethod記錄了這個 Java 方法的所有信息，包括所屬類、訪問權限、代碼執行地址等等。

通過 env->FromReflectedMethod，可以由 Method對象得到這個方法對應的ArtMethod 的真正起始地址。然后就可以把它強轉為 ArtMethod指針，從而對其所有成員進行修改。

這樣全部替換完之后就完成了熱修復邏輯。以后調用這個方法時就會直接走到新 方法的實現中了。

1.2、虛擬機調用方法的原理

為什么這樣替換完就可以實現熱修復呢？這需要從虛擬機調用方法的原理說起。

在 Android 6.0, art 虛擬機中 ArtMethod 的結構是這個樣子的：

classArtMethodFINAL{...
protected:
//Fieldorderrequiredbytest"ValidateFieldOrderOfJavaCppUnionClasses".
//Theclassweareapartof.
GcRoot<mirror::Class>declaring_class_;

//Shortcutstodeclaring_class_->dex_cache_memberforfastcompiledcodeaccess.
GcRoot<mirror::PointerArray>dex_cache_resolved_methods_;

//Shortcutstodeclaring_class_->dex_cache_memberforfastcompiledcodeaccess.
GcRoot<mirror::ObjectArray<mirror::Class>>dex_cache_resolved_types_;

//Accessflags;low16bitsaredefinedbyspec.
uint32_taccess_flags_;

/*Dexfilefields.Thedefiningdexfileisavailableviadeclaring_class_->dex_cache_*/

//OffsettotheCodeItem.
uint32_tdex_code_item_offset_;

//Indexintomethod_idsofthedexfileassociatedwiththismethod.
uint32_tdex_method_index_;

/*Endofdexfilefields.*/

//Entrywithinadispatchtableforthismethod.Forstatic/directmethodstheindexisinto
//thedeclaringClass.directMethods,forvirtualmethodsthevtableandforinterfacemethodsthe
//ifTable.
uint32_tmethod_index_;

//Fakepaddingfieldgetsinsertedhere.

//Mustbethelastfieldsinthemethod.
//PACKED(4)isnecessaryforthecorrectnessof
//RoundUp(OFFSETOF_MEMBER(ArtMethod,ptr_sized_fields_),pointer_size).
structPACKED(4)PtrSizedFields{
//Methoddispatchfromtheinterpreterinvokesthispointerwhichmaycauseabridgeinto
//compiledcode.
void*entry_point_from_interpreter_;

//PointertoJNIfunctionregisteredtothismethod,orafunctiontoresolvetheJNIfunction.
void*entry_point_from_jni_;

//Methoddispatchfromquickcompiledcodeinvokesthispointerwhichmaycausebridginginto
//theinterpreter.
void*entry_point_from_quick_compiled_code_;
}ptr_sized_fields_;...
}

這其中最重要的字段就是 entry_point_from_interprete_ 和 entry_point_ from_quick_compiled_code_了，從名字可以看出來，他們就是方法的執行入口。 我們知道，Java 代碼在 Android 中會被編譯為 Dex Code。

art 中可以采用解釋模式或者 AOT 機器碼模式執行。

• 解釋模式，就是取出 Dex Code，逐條解釋執行就行了。如果方法的調用者是以解釋模式運行的，在調用這個方法時，就會取得這個方法的entry_point_fronn_ interpreter，然后跳轉過去執行。

• AOT方式，就會先預編譯好 Dex Code對應的機器碼，然后運行期直接執行機器碼就行了，不需要一條條地解釋執行Dex Code。如果方法的調用者 是以AOT機器碼方式執行的，在調用這個方法時，就是跳轉到 entry_point_from_ quick_compiled_code_ 執行。

那我們是不是只需要替換這幾個 entry_point_*入口地址就能夠實現方法替換了呢？

并沒有這么簡單。在實際代碼中，有許多更為復雜的調用情況。很多情況下還需要用到dex_code_item_offset_ 等字段。由此可以看出，AOT機器碼的執行過程，還是會有對于虛擬機以及ArtMethod 其他成員字段的依賴。

因此，當把一個舊方法的所有成員字段都換成新方法后，執行時所有數據就可以 保持和新方法的一致。這樣在所有執行到舊方法的地方，會取得新方法的執行入口、 所屬class、方法索引號以及所屬 dex信息，然后像調用舊方法一樣順滑地執行到新 方法的邏輯。

1.3、兼容性問題的根源

然而，目前市面上幾乎所有的 native 替換方案，比如 Andfix和其他安全界的 Hook方案，都是寫死了 ArtMethod 結構體，這會帶來巨大的兼容性問題。

由于Android是開源的，各個手機廠商都可以對代碼進行改造，而 Andfix 里 ArtMethod 的結構是根據公開的 Android源碼中的結構寫死的。如果某個廠商對這個ArtMethod結構體進行了修改，就和原先開源代碼里的結構不一致，那 么在這個修改過了的設備上，替換機制就會出問題。

這也正是 Andfix不支持很多機型的原因，很大的可能，就是因為這些機型修改了底層的虛擬機結構。

1.4、突破底層結構差異

知道了 native替換方式兼容性問題的原因，我們是否有辦法尋求一種新的方式，不依賴于 ROM 底層方法結構的實現而達到替換效果呢？

我們發現，這樣 native 層面替換思路，其實就是替換 ArtMethod的所有成員。 那么，我們并不需要構造出ArtMethod 具體的各個成員字段，只要把 ArtMethod的作為整體進行替換，這樣不就可以了嗎？

也就是把原先這樣的逐一替換：

變成了這樣的整體替換：

//%%把舊函數的所有成員變量都替換為新函數的。
smeth->declaring_class_=dmeth->declaring_class_；
smeth->dex_cache_resolved_methods_=dmeth->dex_cache_resolved_methods_；
smeth->dex_cache_resolved_types_=dmeth->dex_cache_reso1ved_types_；smeth->access_flags_=dmeth->access_flags_；
smeth->dex_code_item_offset_=dmeth->dex_code_item_offset_；
smeth->dex_method_index_=dmeth->dex_method_index_；
smeth->method_index_=dmeth->method_index_；

其實可以濃縮為：

memcpy(smeth,dmeth,sizeof(ArtMethod));

就是這樣，一句話就能取代上面一堆代碼，這正是我們深入理解替換機制的本質之后研發出的新替換方案。

但這其中最關鍵的地方，在于sizeof(ArtMethod)□如果sizeit算有偏差, 導致部分成員沒有被替換，或者替換區域超出了邊界，都會導致嚴重的問題。

對于ROM開發者而言，是在art源代碼里面，所以一個簡單的sizeof (Art- Method)就行了，因為這是在編譯期就可以決定的。

但我們是上層開發者，app會被下發給各式各樣的Android設備，所以我們是 需要在運行時動態地得到app所運行設備上面的底層ArtMethod大小的，這就沒那 么簡單了。

在art里面，初始化一個類的時候會給這個類的所有方法分配空間，類的方法有direct方法和virtual方法。direct方法包含static方法和所有不可 繼承的對象方法。而virtual方法就是所有可以繼承的對象方法了。需要對兩中類型方法都進行分配空間。

方法是一個接一個緊密地new出來排列在 ArtMethod Array 中的。這時只是分配出空間，還沒填入真正的ArtMethod的各個 成員值：

正是這里給了我們啟示，ArtMethod 們是緊密排列的，所以一個 ArtMethod的大小，不就是相鄰兩個方法所對應的ArtMethod 的起始地址的差值嗎？

正是如此。我們就從這個排列特點入手，自己構造一個類，以一種巧妙的方式獲 取到這個差值。

publicclassNativeStructsModel{
finalpublicstaticvoidfl0{}
finalpublicstaticvoidf2(){}
}

由于 f1 和 f2 都是 static 方法，所以都屬于 direct ArtMethod Array。由于 NativeStructsModel 類中只存在這兩個方法，因此它們肯定是相鄰的。

那么我們就可以在JNI層取得它們地址的差值：

size_tfirMid=(size_t)env->GetStaticMethodID(nativeStructsModelClazzf
"fl","()V,r)；
size_tsecMid=(size_t)env->GetStaticMethodID(nativeStructsModelClazz,
uf2H,"OV");
size_tmethsize=secMid-firMid；

然后，就以這個methSize作為sizeof (ArtMethod),代入之前的代碼。

memcpy(smeth,dmeth,methSize)；

問題就迎刃而解了。

值得一提的是，由于忽略了底層ArtMethod結構的差異，對于所有的 Android版本都不再需要區分，而統一以memcpy實現即可，代碼量大大減少。即 使以后的Android版本不斷修改ArtMethod的成員，只要保證ArtMethod數組仍是以線性結構排列，就能直接適用于將來的Android 8.0、9.0等新版本，無需再針對新的系統版本進行適配了。

1.5、訪問權限的問題

1.5.1、方法調用時的權限檢查

看到這里，你可能會有疑惑：我們只是替換了 ArtMethod的內容，但新替換的方法的所屬類，和原先方法的所屬類，是不同的類，被替換的方法有權限訪問這個類的其他private 方法嗎？

在構造函數 調用同一個類下的私有方法func時，不會做任何權限檢查。也就是說，這時即使我偷梁換柱，也能直接跳過去正常執行而不會報錯。

可以推測，在 dex2oat 生成 AOT機器碼時是有做一些檢查和優化的，由于在 dex2oat編譯機器碼時確認了兩個方法同屬一個類，所以機器碼中就不存在權限檢查的相關代碼。

1.5.2、同包名下的權限問題

但是，并非所有方法都可以這么順利地進行訪問的。我們發現補丁中的類在訪問同包名下的類時，會報出訪問權限異常：

具體的校驗邏輯是在虛擬機代碼的 Class : : IsInSamePackage 中：

//android-6.0.I_r62/art/runtime/mirror/class.cc
boolClass::IsInSamePackage(Class*that){
Class*klassl=this；
Class*klass2=that;
if(klassl==klass2){
returntrue；
}
//Classloadersmustmatch.
if(klassl->GetClassLoader()!=klass2->GetClassLoader()){
returnfalse；
}
//Arraysareinthesamepackagewhentheirelementclassesare.
while(klassl->IsArrayClass0){
klassl=klassl->GetComponentType()；
}
while(klass2->IsArrayClass()){
klass2=klass2->GetComponentType();
}
//trivialcheckagainforarraytypes
if(klassl==klass2){
returntrue；
}
//Comparethepackagepartofthedescriptorstring.
std：:stringtempi,temp2；
returnIslnSamePackage(klassl->GetDescriptor(&templ),klass2-
>GetDescriptor(&temp2))；
}

關鍵點在于，Class loaders must match 這行注釋。

知道了原因就好解決了，我們只要設置新類的Classloader為原來類就可以了。 而這一步同樣不需要在JNI層構造底層的結構，只需要通過反射進行設置。這樣仍舊能夠保證良好的兼容性。

實現代碼如下:

FieldclassLoaderField=Class.class.getDeclaredField("classLoader");
classLoaderField.setAccessible(true);
classLoaderField.set(newClass,oldClass.getClassLoader());

這樣就解決了同包名下的訪問權限問題。

1.5.3、反射調用非靜態方法產生的問題

當一個非靜態方法被熱替換后，在反射調用這個方法時，會拋出異常。

//BaseBug.test方法已經被熱替換了。
BaseBugbb=newBaseBug();
MethodtestMeth=BaseBug.class.getDeclaredMethod(11test");
testMeth.invoke(bb);

invoke的時候就會報：

Caused by: java.lang.IllegalArgumentException:

Expected receiver of type com.patch.demo.BaseBug, but got com.patch.demo.BaseBug

這里面，expected receiver 的 BaseBug，和 got 到的 BaseBug，雖然都叫 com.patch.demo.BaseBug，但卻是不同的類。

前者是被熱替換的方法所屬的類，由于我們把它的 ArtMethod 的 declaring_class_ 替換了，因此就是新的補丁類。而后者作為被調用的實例對象 bb的所屬類, 是原有的 BaseBug。兩者是不同的。

那為什么方法是非靜態才有這個問題呢？因為如果是靜態方法，是在類的級別直接進行調用的，就不需要接收對象實例作為參數。所以就沒有這方面的檢查了。

對于這種反射調用非靜態方法的問題，我們會采用另一種冷啟動機制對付，本文在最后會說明如何解決。

1.6、即時生效所帶來的限制

除了反射的問題，像本方案以及 Andfix這樣直接在運行期修改底層結構的熱修復，都存在著一個限制，那就是只能支持方法的替換。而對于補丁類里面存在方法增加和減少，以及成員字段的增加和減少的情況，都是不適用的。

原因是這樣的，一旦補丁類中出現了方法的增加和減少，就會導致這個類以及整個Dex的方法數的變化。方法數的變化伴隨著方法索引的變化，這樣在訪問方法時就無法正常地索引到正確的方法了。

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

不過新增一個完整的、原先包里面不存在的新類是可以的，這個不受限制。

總之，只有兩種情況是不適用的：

1.引起原有了類中發生結構變化的修改

2.修復了的非靜態方法會被反射調用

而對于其他情況，這種方式的熱修復都可以任意使用。

雖然有著一些使用限制，但一旦滿足使用條件，這種熱修復方式是十分出眾的， 它補丁小，加載迅速，能夠實時生效無需重新啟動app,并且具有著完美的設備兼容性。對于較小程度的修復再適合不過了。

二、你所不知的Java

和業界很多熱修復方案不同，Sophix 熱修復一直秉承粒度小、注重快捷修復、無侵入適合原生工程。因為堅持這個原則，我們在研發過程中遇到很多編譯期的問題，這些問題對我們最終方案的實施和熱部署也帶來或多或少地影響，令人印象深刻。

本節列舉了我們在項目實戰中遇到的一些挑戰，這些都是 Java語言在編譯實現上的一些特點，雖然這些特點與熱修復沒有直接關系，但深入研究它們對Android及 Java 語言的理解都頗有脾益。

2.1、內部類編譯

有時候我們會發現，修改外部類某個方法邏輯為訪問內部類的某個方法時，最后打出來的補丁包竟然提示新增了一個方法，這真的很匪夷所思。所有我們有必要了解 下內部類在編譯期間是怎么編譯的,首先我們要知道內部類會在編譯期會被編譯為跟 外部類一樣的頂級類。

2.1.1、靜態內部類/非靜態內部類區別

靜態內部類/非靜態內部類的區別大家應該都很熟悉，非靜態內部類持有外部類的引用，靜態內部類不持有外部類的引用。所以在android性能優化中建議handle 的實現盡量使用靜態內部類，防止外部類Activity類不能被回收導致可能 OOM。非靜態內部類，編譯期間會自動合成 this$0 域表示的就是外部類的引用。

內部類和外部類互相訪問

既然內部類實際上跟外部類一樣都是頂級類，既然都是頂級類，那是不是意味著對方private 的 method/field是沒法被訪問得到的，事實上外部類為了訪問內部類私有的域/方法，編譯期間自動會為內部類生成 access&** 相關方法

此時外部類 BaseBug 為了能訪問到內部類 InnerClass 的私有域 s，所以編譯 器自動為InnerClass 這個內部類合成 access&100方法，這個方法的實現簡單返 回私有域s的值。同樣的如果此時匿名內部類需要訪問外部類的 private屬性/方法, 那么外部類也會自動生成 access&** 相關方法提供給內部類訪問使用。

2.1.2、熱部署解決方案

所以有這樣一種場景，patch 前的 test 方法沒訪問 inner.s, patch 后的 test方法訪問了 inner.s，那么補丁工具最后檢測到了新增了 access&ioo方法。那么我們 只要防止生成access&** 相關方法，就能走熱部署，也就是底層替換方式熱修復。

所以只要滿足以下條件，就能避免編譯器自動生成 access&** 相關方法

• 一個外部類如果有內部類，把所有 method/field 的 private訪問權限改成 protected 或者默認訪問權限或 public。

• 同時把內部類的所有 method/field 的 private 訪問權限改成 protected或者默認訪問權限或public。

2.2、匿名內部類編譯

匿名內部類其實也是個內部類，所以自然也有上一小節說明情況的影響，但是我 們發現新增一個匿名類（補丁熱部署模式下是允許新增類），同時規避上一節的情況, 但是匪夷所思的還是提示了 method的新增，所以接下來看下匿名內部類跟非匿名內 部類相比，又有怎么樣的特殊性。

2.2.1、匿名內部類編譯命名規則

匿名內部類顧名思義就是沒名字的。匿名內部類的名稱格式一般是外部類&numble，后面的 numble，編譯期根據該匿名內部類在外部類中出現的先后關系, 依次剛命名。一旦新增或者減少內部類會導致名字與方法含義出現亂套的情況。

2.2.2、熱部署解決方案

新增/減少匿名內部類，實際上對于熱部署來說是無解的，因為補丁工具拿到的 已經是編譯后的 .class 文件，所以根本沒法去區分 DexFixDemo&1/DexFixDemo&2類。所以這種情況下，如果有補丁熱部署的需求，應該極力避免插入一個新的匿名內部類。當然如果是匿名內部類是插入到外部類的末尾，那么是允許的。

2.3、有趣的域編譯

2.3.1、靜態field，非靜態field編譯

實際上在熱部署方案中除了不支持 method/fleld的新增，同時也是不支持 ＜ciinit＞的修復，這個方法會在 Dalvik虛擬機中類加載的時候進行類初始化時候調 用。在java 源碼中本身并沒有 clinit 這個方法,這個方法是 android編譯器自動合成的 方法。通過測試發現，靜態field的初始化和靜態代碼塊實際上就會被編譯器編譯在 ＜ciinit＞這個方法，所以我們有必要去了解一下 field/代碼塊到底是怎么編譯的。

來看個簡單的示例。

publicclassDexFixDemo{
{
i=2;
}
privateinti=1;
privatestaticintj=1;
static{
j=2;
}
}

反編譯為smali看下

2.3.2、靜態field初始化，靜態代碼塊

上面的示例中，能夠很明顯靜態 field初始化和靜態代碼塊被編譯器翻譯在 ＜clinit＞方法中。靜態代碼塊和靜態域初始化在clinit中的先后關系就是兩者出現在源碼中的先后關系，所以上述示例中最后 j==2 。前面說過，類加載然后進行類初始化的時候，會去調用clinit方法，一個類僅加載一次。以下三種情況都會嘗試去 加載一個類:

• new —個類的對象（new-instance 指令）

• 調用類的靜態方法（invoke-static 指令）

• 獲取類的靜態域的值（sget 指令）

首先判斷這個類有沒有被加載過，如果沒有加載過，執行的流程 dvniResolve-Class - ＞dvmLinkClass- ＞dvmInitClass，類的初始化時在 dvmlnitClass。dvmlnitClass 這個函數首先會嘗試會對父類進行初始化，然后調用本類的 clinit方法，所以此時靜態field得到初始化和靜態代碼塊得到執行。

2.3.3、非靜態field初始化，非靜態代碼塊

上面的示例中，能夠很明顯的看到非靜態field初始化和非靜態代碼塊被編譯器翻 譯在＜init＞默認無參構造函數中。非靜態field和非靜態代碼塊在init方法中的先后順 序也跟兩者在源碼中出現的順序一致，所以上述示例中最后i==1。實際上如果存在有參構造函數，那么每個有參構造函數都會執行一個非靜態域的初始化和非靜態代碼塊。

構造函數會被android編譯器自動翻譯成＜init＞方法

前面介紹過clinit方法在類加載初始化的時候被調用，那么＜init＞構造函數方 法肯定是對類對象進行初始化時候被調用的，簡單來說new —個對象就會對這個對象進行初始化，并調用這個對象相應的構造函數，看下這行代碼 String s = new String ("test")；編譯之后的樣子。

首先執行 new-instance指令，主要為對象分配堆內存，同時如果類如果之前沒加載過，嘗試加載類。然后執行invoke-direct 指令調用類的 init構造函數方法執行對象的初始化。

2.3.4、熱部署解決方案

由于我們不支持＜clinit＞方法的熱部署，所以任何靜態field初始化和靜態代碼塊的變更都會被翻譯到clinit方法中，導致最后熱部署失敗，只能冷啟動生效。如上所見，非靜態field 和非靜態代碼塊的變更被翻譯到＜init＞構造函數中，熱部署 模式下只是視為一個普通方法的變更,此時對熱部署是沒有影響的。

2.4、final static 域編譯

final static 域首先是一個靜態域，所以我們自然認為由于會被翻譯到 clinit 方法中，所以自然熱部署下面也是不能變更。但是測試發現，final static修飾的基 本類型/String常量類型，匪夷所思的竟然沒有被翻譯到 clinit 方法中，見以下分析。

2.4.1、final static域編譯規則

final static 靜態常量域。看下 final static 域被編譯后的樣子。

看下反編譯得到的smali文件

我們發現，final static int 12 = 2 和 final static String s2 = "haha"這兩個靜態域竟然沒在中被初始化。其它的非final靜態域均在clinit函數中得到初始化。這里注意下 "haha"和new String ("heihei")的區別，前者是字符串常量，后者是引用類型。那這兩個final static域(i2和s2)究竟在何處得到初始化？

事實上，類加載初始化dvmlnitClass在執行clinit方法之前，首先會先執行 initSFieids，這個方法的作用主要就是給static域賦予默認值。如果是引用類型， 那么默認初始值為NULL。0101Editor工具查看dex文件結構，我們能看到在dex 的類定義區，每個類下面都有這么一段數據，圖中encoded_array_item。

上述代碼示例中，那塊區域有4個默認初始值，分別是t1 = =NULL, t2==NULL, s1==NULL, s2=="haha", i1==0, i2 = =2。其中 t1/t2/s2/i1在 initSFields中首先賦值了默認初始化值，然后在隨后的clinit中賦值了程序設置的值。而i2/s2在initSFields得到的默認值就是程序中設置的值。

現在我們知道了 static 和 final static 修飾 field 的區別了。簡單來說：

• final static 修飾的原始類型和String類型域（非引用類型）,在并不會被翻譯在 clinit方法中，而是在類初始化執行 initSFields 方法時號到了初始化賦值。

• final static 修飾的弓I用類型，初始化仍然在 clinit 方法中；

2.4.2、final static域優化原理

另外一方面，我們經常會看到android性能優化相關文檔中有說過，如果一個 field是常量，那么推薦盡量使用static final作為修飾符。很明顯這句話不大 對，得到優化的僅僅是final static原始類型和String類型域（非引用類型）, 如果是引用類型，實際上不會得到任何優化的。

2.4.3、熱部署解決方案

所有我們可以得到最后的結論：

• 修改 final static 基本類型或者 String類型域(非引用類型)域，由于編譯期 間引用到基本類型的地方被立即數替換，引用到String類型(非引用類型) 的地方被常量池索引id替換，所以在熱部署模式下，最終所有引用到該 finalstatic 域的方法都會被替換。實際上此時仍然可以走熱部署。

• 修改 final static 引用類型域，是不允許的，因為這個 field的初始化會被翻譯到clinit方法中，所以此時沒法走熱部署。

2.5、有趣的方法編譯

2.5.1、應用混淆方法編譯

除了以上的內部類/匿名內部類可能會造成method新增之后，我們發現項目如 果應用了混淆，由于可能導致方法的內聯和裁剪，那么最后也可能導致method的新 增/減少，以下介紹哪些場景會造成方法的內聯和裁剪。

2.5.2、方法內聯

實際上有好幾種情況可能導致方法被內聯掉。

1.方法沒有被其它任何地方引用到，毫無疑問，該方法會被內聯掉

2.方法足夠簡單，比如一個方法的實現就只有一行，該方法會被內聯掉，那么 任何調用該方法的地方都會被該方法的實現替換掉

3.方法只被一個地方引用到，這個地方會被方法的實現替換掉。

舉個簡單的例子進行說明下。

此時假如print方法足夠復雜，同時只在 test 方法中被調用，假設 test方法沒被內聯，print 方法由于只有一個地方調用此時 print方法會被內聯。

如果恰好將要 patch的一方法調用了 print方法，那么print被調用了兩次, 在新的apk中不會被內聯，補丁工具檢測到新增了 print方法。那么該補丁只能走冷 啟動方案。

2.5.3、方法裁剪

查看下生成的mapping.txt文件

com.taobao.hotfix.demo.BaseBug -> com.taobao.hotfix.demo.a:

void test$faab20d() -> a

此時test方法context參數沒被使用，所以test方法的context參數被裁剪， 混淆任務首先生成test$faab20d()裁剪過后的無參方法，然后再混淆。所以如果 將要patch該test方法，同時恰好用到了 context參數，那么test方法的context 參數不會被裁剪，那么補丁工具檢測到新增了 test (context)方法。那么該補丁只 能走冷啟動方案。

怎么讓該參數不被裁剪，當然是有辦法的，參數引用住，不讓編譯器在優化的 時候認為這是一個無用的參數就好了，可以采取的方法很多，這里介紹一種最有效 的方法：

注意這里不能用基本類型false,必須用包裝類Boolean,因為如果寫基本類型 這個if語句也很可能會被優化掉的。

2.5.4、熱部署解期案

實際上只要混淆配置文件加上-dontoptimize這項就不會去做方法的裁剪和內聯。一般情況下項目的混淆配置都會使用到android sdk默認的混淆配置文件 proguard-android-optimize. txt 或者 proguard- android. txt, 兩者的區別就是后者應用了 -dontoptimize 這一項配置而前者沒應用。

2.6、switch case 語句編譯

由于在實現資源修復方案熱部署的過程中要做新舊資源 id 的替換，我們發現竟然存在 switch case 語句中的 id 不會。

所以有必要來探索下switch case語句編譯的特殊性。

看下 testContinue/testNotContinue 方法編譯出來有何不同。

testNotContinue 方法的 switch case 語句被翻譯成 sparse-switch 指令。 比較下差異testContinue的switch 語句的case項是連續的幾個值比較相近的值1,3,5。所以被編譯期翻譯為 packed-switch指令，可以看到對這幾個連續的數中間的差值用:pswitch_0 補齊，:pswitch_0 標簽處直接 retum-void。testNotContinue 的 switch 語句的 case 項分別是1,3,10,很明顯不夠連續，所以 被編譯期翻譯為sparse-switch 指令。怎么才算連續的case值這個是由編譯器來決定的。

2.6.1、熱部署解決方案

—個資源 id 肯定是const final static變量，此時恰好 switch case語句 被翻譯成packed-switch 指令，所以這個時候如果不做任何處理就存在資源id替換 不完全的情況。解決方案其實很簡單暴力，修改smali反編譯流程，碰到packed- switch 指令強轉為sparse-switch指令，:pswitch_N等相關標簽指令也需 要強轉為:sswitch_N 指令。然后做資源id的暴力替換，然后再回編譯 smali 為dex。再做類方法變更的檢測，所以就需要經過反編譯-> 資源id替換-> 回編譯的過程，這也會使得打補丁變得稍慢一些。

2.7、泛型編譯

泛型是 java5 才開始引入的，我們發現泛型的使用，也可能導致 method的新增，所以是時候深入了解一下泛型的編譯過程了。

為什么需要泛型？

• Java語言中的泛型基本上完全在編譯器中實現，由編譯器執行類型檢查和類 型推斷，然后生成普通的非泛型的字節碼，就是虛擬機完全無感知泛型的存在。這種實現技術稱為擦除(erasure)編譯器使用泛型類型信息保證類型安 全，然后在生成字節碼之前將其清除。

• Java5才引入泛型，所以擴展虛擬機指令集來支持泛型被認為是無法接受的， 因為這會為Java 廠商升級其JVM造成難以逾越的障礙。因此采用了可以完 全在編譯器中實現的擦除方法。

2.7.1、類型擦除與多態的沖突和解決

子類中真正重寫基類方法的是編譯器自動合成的bridge方法。而類 B定義的get和set方法上面的 @Override 只不過是假象，bridge方法的內部實 現去調用我們自己重寫的print方法而已。所以，虛擬機巧妙使用了橋方法的方式，來解決了類型擦除和多態的沖突

這里或許也許會有疑問，類B中的字節碼中的方法 get () Ljava/lang/Nuniber ；和 get () Ljava/lang/Object；是同時存在的，這就顛覆了我們的認知，如果是我 們自己編寫Java源代碼，這樣的代碼是無法通過編譯器的檢查的，方法的重載只能 以方法參數而無法以返回類型別作為函數重載的區分標準，但是虛擬機卻是允許這樣做的，因為虛擬機通過參數類型和返回類型共同來確定一個方法，所以編譯器為了實 現泛型的多態允許自己做這個看起來“不合法”的事情，然后交給虛擬器自己去區別 處理了。

2.7.2、泛型類型轉換

同時前面我們還留了一個坑，泛型是可以不需要強制類型轉換。

代碼示例中，第一個不需要強制類型轉換，但是第二個必須強制類型轉換否則編譯期報incovertiable types錯誤。反編譯看下smali：

字節碼文件很意外，兩者其實并沒有什么區別，實際上編譯期間，編譯器發現如 果有一個變量的申明加上了泛型類型的話，編譯器自動加上check-cast類型轉換, 而不需要程序員在源碼文件中進行強制類型轉換，這里不需要并不意味著不會類型轉換，可以發現其實只是類型轉換編譯器自動幫我們完成了而已。

2.7.3、熱部署解決方案

前面類型擦除中說過，如果由 B extends A變成了 B extends A<Number>, 那么就可能會新增對應的橋方法。此時新增方法了，只能走冷部署了。這種情況下, 如果要走熱部署，應該避免類似上面那種的修復。

另外一方面，實際上泛型方法內部會生成一個 dalvik/annotation/Signa- ture 這個系統注解

2.8、Lambda表達式編譯

Lambda 表達式是 java7才引入的一種表達式，類似于匿名內部類實際上又與 匿名內部類有很大的區別，我們發現Lambda表達式的使用也可能導致方法的新增/減少，導致最后走不了熱部署模式。所以是時候深入了解一下 Lambda表達式的編 譯過程了。

2.8.1、Lambda表達式編譯規則

首先簡單介紹下 lambda 表達式，lambda 為 Java添加了缺失的函數式編程 特點，Java現在提供的最接近閉包的概念便是 Lambda 表達式。gradle就是基于 groovy 存在大量閉包。函數式接口具有兩個主要特征，是一個接口，這個接口具有唯一的一個抽象方法，我們將滿足這兩個特性的接口稱為函數式接口。比如 Java標準庫中的java.lang.Runnable 和 java.util.Comparator都是典型的函數式 接口。跟匿名內部類的區別如下：

• 關鍵字 this 匿名類的this關鍵字指向匿名類，而lambda表達式的this關鍵 字指向包圍lambda表達式的類。

• 編譯方式，Java編譯器將lambda表達式編譯成類的私有方法，使用了 Java7 的 invokedynamic 字節碼指令來動態綁定這個方法。Java編譯器將匿名內部類編譯成外部類&numble的新類。

dex字節碼文件和.class字節碼文件對lambda表達式處理的 異同點。

• 共同點：輻譯期間都會為外部類合成一個static輔助方法，該方法內部邏輯 實現lambda表達式。

• 不同點：class字節碼中通過 invokedynamic 指令執行lambda表達式。而.dex字節碼中執行lambda表達式跟普通方法調用沒有任何區別。class字節碼中運行時生成新類。.dex字節碼中編譯期間生成新類。

2.8.2、熱部署解決方案

有了以上知識點做基礎，同時我們知道我們打補丁是通過反編譯為 smali然后新 apk 跟基線 apk 進行差異對比，得到最后的補丁包。所以首先：

新增一個lambda表達式，會導致外部類新增一個輔助方法，所以此時不支 持走熱部署方案，還有另外一方面，可以看下合成類的命名規則Test$$Lamb-da$-void_main_j ava_lang_Stringargs_LambdaImpl0.smali：外部類名+ Lambda + Lambda 表達式所在方法的簽名 + Lambdalmpl +出現的順序號。構成這個合成類。所以此時如果不是在末尾插入了一個新的Lambda表達式，那么就會導 致跟前面說明匿名內部類一樣的問題，會導致類方法比較亂套。減少一個lambda表 達式熱部署情況下也是不允許的,也會導致類方法比較亂套。

那么如果只是修改 lambda表達式內部的邏輯，此時看起來僅僅相當于修改了一 個方法，所以此時是看起來是允許走熱部署的。事實上并非如此。我們忽略了一種情 況，lambda表達式訪問外部類非靜態 field/method 的場景。

前面我們知道 .dex 字節碼中 lambda表達式在編譯期間會自動生成新的輔助類。 注意該輔助類是非靜態的，所以該輔助類如果為了訪問 “外部類”的非靜態field/ method就必須持有"外部類"的引用。如果該輔助類沒有訪問"外部類”的非靜態 field/method,那么就不會持有"外部類"的引用。這里注意這個輔助類和內部類 的區別。我們前面說過如果是非static內部類的話一定會持有外部類的引用的！

2.9、訪問權限檢查對熱替換的影響

訪問權限的問題中有提到權限問題對于底層熱替換的影響，下面我們就來深入剖析虛擬機下權限控制可能給我們的熱修復方案帶來的影響，下面代碼示例僅演 示Dalvik虛擬機。

2.9.1、類加載階段父類/實現接口訪問權限檢查

如果當前類和實現接口 /父類是非 public，同時負責加載兩者的 classLoader 不一樣的情況下，直接 return false。所以如果此時不進行任何處理的 話，那么在類加載階段就報錯。我們當前的代碼熱修復方案是基于新classLoader 加載補丁類，所以在patch的過程中就會報類似如下的錯誤。

2.9.2、類校驗階段訪問權限檢查

如果補丁類中存在非public類的訪問/非 public方法/域的調用，那么都會導致失敗。更為致命的是，在補丁加載階段是檢測不出來的，補丁會被視為正常加載，但是在運行階 段會直接crash異常退出。

2.10、＜clinit＞方法

由于補丁熱部署模式下的特殊性一不允許類結構變更以及不允許變更＜clinit＞ 方法，所以我們的補丁工具如果發現了這幾種限制情況，那么此時只能走冷啟動重啟 生效，冷啟動幾乎是無任何限制的，可以做到任何場景的修復。可能有時候在源碼層 面上來看并沒有新增/減少 method 和 field，但是實際上由于要滿足 Java各種語法 特性的需求，所以編譯器會在編譯期間為我們自動合成一些method 和 field，最后 就有可能觸發了這幾個限制情況。以上列舉的情況可能并不完全詳細，這些分析也只是一個拋磚引玉的作用，具體情況還需要具體分析，同時一些難以理解的java語法 特性或許從編譯的角度去分析可能就無處遁形了。

三、冷啟動類加載原理

前面我們提到熱部署修復方案有諸多特點（有關熱部署修復方案實現。其根本原 理是基于native 層方法的替換，所以當類結構變化時，如新增減少類 method/field 在熱部署模式下會受到限制。但冷部署能突破這種約束，可以更好地達到修復目的，再加上冷部署在穩定性上具有的獨特優勢，因此可以作為熱部署的有力補充而存在。

3.1、冷啟動實現方案概述

冷啟動重啟生效，現在一般有以下兩種實現方案，同時給出他們各自的優缺點：

上面的表格，我們能清晰的看到兩個方案的缺點都很明顯。這里對 tinker 方案

dex merge缺陷進行簡單說明一下:

dex merge 操作是在 java 層面進行，所有對象的分配都是在 java heap上, 如果此時進程申請的java heap對象超過了 vm heap規定的大小，那么進程發生OOM，那么系統 memory killer 可能會殺掉該進程，導致 dex合成失敗。另外一方 面我們知道jni 層面 C++ new/malloc 申請的內存，分配在native heap, nativeheap 的增長并不受 vm heap 大小的限制，只受限于RAM，如果 RAM不足那么進 程也會被殺死導致閃退。所以如果只是從dexmerge 方面思考，在jni層面進行dex merge，從而可以避免 OOM 提高 dex 合并的成功率。理論上當然可以，只是jni層 實現起來比較復雜而已

3.2、類校驗

apk 第一次安裝的時候，會對原 dex 執行 dexopt，此時假如 apk只存在一個 dex，所以 dvmVerifyClass(clazz) 結果為 true。所以 apk中所有的類都會被打上 class_ispreverifIed 標志，接下來執行dvmOptimizeClass，類接著被打上 CLASS_ISOPTIMIZED 標志。

• dvmVerifyClass：類校驗，類校驗的目的簡單來說就是為了防止類被篡改校 驗類的合法性。此時會對類的每個方法進行校驗，這里我們只需要知道如果 類的所有方法中直接引用到的類(第一層級關系，不會進行遞歸搜索)和當前 類都在同一個dex中的話，dvmVerifyClass 就返回 true。

• dvmOptimizeClass：類優化，簡單來說這個過程會把部分指令優化成虛擬機 內咅B指令，比如方法調用指令：invoke-*指令變成了 invoke-*-quick, quick指令會從類的vtable表中直接取，vtable簡單來說就是類的所有方法 的一張大表(包括繼承自父類的方法)o因此加快了方法的執行速率。

3.3、Art下冷啟動實現

前面說過補丁熱部署模式下是一個完整的類，補丁的粒度是類。現在我們的需 求是補丁既能走熱部署模式也能走冷啟動模式，為了減少補丁包的大小，并沒有為 熱部署和冷啟動分別準備一套補丁，而是同一個熱部署模式下的補丁能夠降級直接 走冷啟動，所以我們不需要做dex merge。但是前面我們知道為了解決Art下類地 址寫死的問題，tinker通過dex merge成一^全新完整的新dex整個替換掉舊的 dexElements數組。事實上我們并不需要這樣做，Art虛擬機下面默認已經支持多 dex壓縮文件的加載了。

需要注意一點:

• 補丁dex必須命名為classes.dex

• loadDex得到的DexFile完整替換掉dexElements數組而不是插入

3.4、不得不說的其它點

我們知道DexFile.loadDex嘗試把一個dex文件解析并加載到native內存, 在加載到native內存之前，如果dex不存在對應的odex,那么Dalvik下會執行 dexopt, Art會執行dexoat,最后得到的都是一個優化后的odex。實際上最后虛 擬機執行的是這個odex而不是dex。

現在有這么一個問題，如果dex足夠大那么dexopt/dexoat實際上是很耗時的， 根據上面我們提到的方案，Dalvik下實際上影響比較小，因為loadDex僅僅是補丁包。 但是Art下影響是非常大的，因為loadDex是補丁 dex和apk中原dex合并成的一個 完整補丁壓縮包，所以dexoat非常耗時。所以如果優化后的odex文件沒生成或者沒 生成一個完整的odex文件，那么loadDex便不能在應用啟動的時候進行的，因為會 阻塞loadDex線程，一般是主線程。所以為了解決這個問題，我們把loadDex當做 一個事務來看，如果中途被打斷，那么就刪除。dex文件，重啟的時候如果發現存在 odex文件，loadDex完之后，反射注入/替換dexElements數組，實現patch。 如果不存在。dex文件，那么重啟另一個子線程loadDex,重啟之后再生效。

另外一方面為了 patch補丁的安全性，雖然對補丁包進行簽名校驗，這個時候能 夠防止整個補丁包被篡改，但是實際上因為虛擬機執行的是odex而不是dex,還需 要對odex文件進行md5完整性校驗，如果匹配，則直接加載。不匹配，則重新生成 —遍 odex 文件，防止 odex 文件被篡改。

3.5、完整的方案考慮

代碼修復冷啟動方案由于它的高兼容性，幾乎可以修復任何代碼修復的場景，但 是注入前被加載的類(比如 Application類)肯定是不能被修復的。所以我們把它作 為一個兜底的方案，在沒法走熱部署或者熱部署失敗的情況，最后都會走代碼冷啟動 重啟生效，所以我們的補丁是同一套的。具體實施方案對 Dalvik 下和 Art下分別做了處理：

• Dalvik下采用我們自行研發的全量DEX方案

• Art 下本質上虛擬機已經支持多dex的加載，我們要做的僅僅是把補丁 dex 作為主 dex(classes.dex) 加載而已。

四、多態對冷啟動類加載的影響

前面我們知道冷啟動方案幾乎是可以修復任何場景的，但 Dalvik 下 QFix方案存在很大的限制，下面將深入介紹下目前方案下為什么會有這些限制，同時給出具體的 解決方案。

4.1、重新認識多態

實現多態的技術一般叫做動態綁定，是指在執行期間判斷所引用對象的實際類 型，根據其實際的類型調用其相應的方法。多態一般指的是非靜態非private方法的多態。field 和靜態方法不具有多態性。

子類 vtable 的大小等于子類 virtual方法數+父類vtable的大小。

• 整個復制父類 vtable 到子類的 vtable

• 遍歷子類的 virtual 方法集合，如果方法原型一致，說明是重寫父類方法，那么相同索引位置處，子類重寫方法覆蓋掉 vtable 中父類的方法

• 方法原型不一致，那么把該方法添加到vtable的末尾

4.2、冷啟動方案限制

dex文件第一次加載的時候，會執行dexopt, dexopt 有兩個過程：verify+optimize。

• dvmVerifyClass:類校驗，類校驗的目的簡單來說就是為了防止類被篡改校 驗類的合法性。此時會對類的每個方法進行校驗，這里我們只需要知道如果 類的所有方法中直接引用到的類(第一層級關系，不會進行遞歸搜索)和當前 類都在同一個dex中的話，dvmVerifyClass就返回true。

• dvmOptimizeClass:類優化，簡單來說這個過程會把部分指令優化成虛擬機 內部指令，比如方法調用指令：invoke-virtual-quick, quick指令會從類的 vtable 表中直接取，vtable簡單來說就是類的所有方法的一張大表(包括繼 承自父類的方法)。因此加快了方法的執行速率。

所以，如果在補丁類中新增新的方法有可能會導致方法調用錯亂。

五、Dalvik下完整DEX方案的新探索

5.1、一種新的全量Dex方案

一般來說，合成完整dex，思路就是把原來的 dex 和 patch 里的 dex重新合并 成一個。然而我們的思路是反過來的。

我們可以這樣考慮，既然補丁中已經有變動的類了，那只要在原先基線包里的 dex 里面，去掉補丁中也有的 class。這樣，補丁+去除了補丁類的基線包，不就等于了新app中的所有類了嗎？

參照 Android 原生 multi-dex 的實現再來看這個方案，會很好理解。multi-dex 是把apk 里用到的所有類拆分到 classes.dex、classes2 .dex、classes3.dex、...之中，而每個dex都只包含了部分的類的定義，但單個 dex也是可以加載的，因為只要把所有dex 都 load 進去，本 dex中不存在的類就可以在運行期間 在其他的dex中找到。

因此同理，在基線包 dex 里面在去掉了補丁中 class后，原先需要發生變更的舊的class就被消除了，基線包dex里就只包含不變的class。而這些不變的class 要用到補丁中的新class時會自動地找到補丁dex，補丁包中的新class在需要用到 不變的class 時也會找到基線包dex的class。這樣的話，基線包里面不使用補丁類的class仍舊可以按原來的邏輯做odex,最大地保證了 dexopt的效果。

這么一來，我們不再需要像傳統合成的思路那樣判斷類的增加和修改情況，而且也不需要處理合成時方法數超過的情況，對于dex的結構也不用進行破壞性重構。

現在，合成完整 dex 的問題就簡化為了一如何在基線包dex里面去掉補丁包 中包含的所有類。接下來我們看一下在dex 中去除指定類的具體實現。

需要注意的是，我們并不是要把某個Class的所有信息都從dex移除，因為如 果這么做，可能會導致dex的各個部分都發生變化，從而需要大量調整offset，這樣就變得就費時費力了。我們要做的，僅僅是讓在解析這個dex的時候找不到這個 Class 的定義就行了。因此，只需要移除定義的入口，對于class的具體內容不進 行刪除，這樣可以最大可能地減少offset的修改。

我們只是去除了類的定義，而對于類的方法實體以及其他dex信息不做移除, 雖然這樣會把這個被移除類的無用信息殘留在dex文件中，但這些信息占不了太多空 間，并且對dex的處理速度是提升很大的，這種移除類操作的方式就變得十分輕快。

5.2、對于 Application 的處理

由此，我們實現了完整的dex合成。但仍然有個問題，這個問題所有完整dex 替換方案都會遇到，那就是對于Application的處理。

眾所周知，Application是整個app的入口，因此，在進入到替換的完整dex 之前，一定會通過Application的代碼，因此，Application必然是加載在原來的老 dex里面的。只有在補丁加載后使用的類，會在新的完整dex里面找到。

因此，在加載補丁后，如果Application類使用其他在新dex里的類，由于不在 同一個dex戛 如果Application被打上了 pre-verified標志，這時就會拋出異常

在 Application類初始化的時候。此時補丁還 沒進行加載，所以就會提前加載到原始dex中的類。接下來當補丁加載完畢后，這些 已經加載的類如果用到了新dex 中的類，并且又是 pre-verified 時就會報錯。

這里最大的問題在于，我們無法把補丁加載提前到 dvmOptResolveClass之前，因為在一個app的生命周期里，沒有可能到達比入口 Application初始化更早的 時期了。

而這個問題常見于多dex情形，當存在多dex時，無法保證 Application的用到的類和它處于同個dex 中。如果只有一個 dex，—般就不會有這個問題。

多dex情況下要想解決這個問題，有兩種辦法：

• 第一種辦法，讓Application用到的所有非系統類都和Application位 于同一個dex里，這就可以保證pre-verified標志被打上，避免進入 dvmOptResolveClass，而在補丁加載完之后，我們再清除 pre-verified 標志，使得接下來使用其他類也不會報錯。

• 第二種辦法，把Application里面除了熱修復框架代碼以外的其他代碼都剝離開，單獨提出放到一個其他類里面，這樣使得Application不會直接用到 過多非系統類，這樣，保證這個單獨拿出來的類和Application處于同一個 dex的幾率還是比較大的。如果想要更保險，Application可以采用反射方式 訪問這個單獨類，這樣就徹底扌巴Application和其他類隔絕開了。

第一種方法實現較為簡單，因為 Android 官方 multi-dex機制會自動將 Application 用到的類都打包到主 dex 中，因此只要把熱修復初始化放在 attachBaseContext的最前面，大多都沒問題。而第二種方法稍加繁瑣，是在代碼架構層面進行重新設計，不過可以一勞永逸地解決問題。

總結

以上是生活随笔為你收集整理的Android热修复技术原理中的代码热修复技术是什么的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。