一、底層熱替換原理

1.1、Andfix 回顧

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

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

Andfix 采用的方法是，在已經(jīng)加載了的類中直接在 native層替換掉原有方法, 是在原來類的基礎(chǔ)上進行修改的。對于不同Android版本的art，底層Java對象的數(shù)據(jù)結(jié)構(gòu)是不同的，因而會進一步區(qū)分不同的替換函數(shù)。每一個 Java 方法在 art 中都對應(yīng)著一個 ArtMethod，ArtMethod記錄了這個 Java 方法的所有信息，包括所屬類、訪問權(quán)限、代碼執(zhí)行地址等等。

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

這樣全部替換完之后就完成了熱修復(fù)邏輯。以后調(diào)用這個方法時就會直接走到新 方法的實現(xiàn)中了。

1.2、虛擬機調(diào)用方法的原理

為什么這樣替換完就可以實現(xiàn)熱修復(fù)呢？這需要從虛擬機調(diào)用方法的原理說起。

在 Android 6.0, art 虛擬機中 ArtMethod 的結(jié)構(gòu)是這個樣子的：

class ArtMethod FINAL {...
 protected:
  // Field order required by test "ValidateFieldOrderOfJavaCppUnionClasses".
  // The class we are a part of.
  GcRoot<mirror::Class> declaring_class_;

  // Short cuts to declaring_class_->dex_cache_ member for fast compiled code access.
  GcRoot<mirror::PointerArray> dex_cache_resolved_methods_;

  // Short cuts to declaring_class_->dex_cache_ member for fast compiled code access.
  GcRoot<mirror::ObjectArray<mirror::Class>> dex_cache_resolved_types_;

  // Access flags; low 16 bits are defined by spec.
  uint32_t access_flags_;

  /* Dex file fields. The defining dex file is available via declaring_class_->dex_cache_ */

  // Offset to the CodeItem.
  uint32_t dex_code_item_offset_;

  // Index into method_ids of the dex file associated with this method.
  uint32_t dex_method_index_;

  /* End of dex file fields. */

  // Entry within a dispatch table for this method. For static/direct methods the index is into
  // the declaringClass.directMethods, for virtual methods the vtable and for interface methods the
  // ifTable.
  uint32_t method_index_;

  // Fake padding field gets inserted here.

  // Must be the last fields in the method.
  // PACKED(4) is necessary for the correctness of
  // RoundUp(OFFSETOF_MEMBER(ArtMethod, ptr_sized_fields_), pointer_size).
  struct PACKED(4) PtrSizedFields {
    // Method dispatch from the interpreter invokes this pointer which may cause a bridge into
    // compiled code.
    void* entry_point_from_interpreter_;

    // Pointer to JNI function registered to this method, or a function to resolve the JNI function.
    void* entry_point_from_jni_;

    // Method dispatch from quick compiled code invokes this pointer which may cause bridging into
    // the interpreter.
    void* entry_point_from_quick_compiled_code_;
  } ptr_sized_fields_;...
}

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

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

• 解釋模式，就是取出 Dex Code，逐條解釋執(zhí)行就行了。如果方法的調(diào)用者是以解釋模式運行的，在調(diào)用這個方法時，就會取得這個方法的entry_point_fronn_ interpreter，然后跳轉(zhuǎn)過去執(zhí)行。
• AOT方式，就會先預(yù)編譯好 Dex Code對應(yīng)的機器碼，然后運行期直接執(zhí)行機器碼就行了，不需要一條條地解釋執(zhí)行Dex Code。如果方法的調(diào)用者 是以AOT機器碼方式執(zhí)行的，在調(diào)用這個方法時，就是跳轉(zhuǎn)到 entry_point_from_ quick_compiled_code_ 執(zhí)行。

那我們是不是只需要替換這幾個 entry_point_*入口地址就能夠?qū)崿F(xiàn)方法替換了呢？

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

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

1.3、兼容性問題的根源

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

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

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

1.4、突破底層結(jié)構(gòu)差異

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

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

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

變成了這樣的整體替換：

// %%把舊函數(shù)的所有成員變量都替換為新函數(shù)的。
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));

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

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

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

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

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

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

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

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

public class NativeStructsModel {
    final public static void fl 0 {}
    final public static void f2() {}
} 

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

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

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

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

memcpy(smeth, dmeth, methSize)；

問題就迎刃而解了。

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

1.5、訪問權(quán)限的問題

1.5.1、方法調(diào)用時的權(quán)限檢查

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

在構(gòu)造函數(shù) 調(diào)用同一個類下的私有方法func時，不會做任何權(quán)限檢查。也就是說，這時即使我偷梁換柱，也能直接跳過去正常執(zhí)行而不會報錯。

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

1.5.2、同包名下的權(quán)限問題

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

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

// android-6.0.I_r62/art/runtime/mirror/class.cc
bool Class::IsInSamePackage(Class* that) {
    Class* klassl = this；
    Class* klass2 = that;
    if (klassl == klass2) {
        return true；
    }
    // Class loaders must match.
    if (klassl->GetClassLoader() != klass2->GetClassLoader()) {
        return false；
    }
    // Arrays are in the same package when their element classes are.
    while (klassl->IsArrayClass0) {
        klassl = klassl->GetComponentType()；
    }
    while (klass2->IsArrayClass()) {
        klass2 = klass2->GetComponentType();
    }
    // trivial check again for array types
    if (klassl == klass2) {
        return true；
    }
    // Compare the package part of the descriptor string.
    std：:string tempi, temp2；
    return IslnSamePackage(klassl->GetDescriptor(&templ), klass2-
    >GetDescriptor(&temp2))；
}

關(guān)鍵點在于，Class loaders must match 這行注釋。

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

實現(xiàn)代碼如下:

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

這樣就解決了同包名下的訪問權(quán)限問題。

1.5.3、反射調(diào)用非靜態(tài)方法產(chǎn)生的問題

當(dāng)一個非靜態(tài)方法被熱替換后，在反射調(diào)用這個方法時，會拋出異常。

// BaseBug. test方法已經(jīng)被熱替換了。
BaseBug bb = new BaseBug();
Method testMeth = BaseBug.class.getDeclaredMethod (11 test");
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_ 替換了，因此就是新的補丁類。而后者作為被調(diào)用的實例對象 bb的所屬類, 是原有的 BaseBug。兩者是不同的。

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

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

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

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

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

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

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

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

1.引起原有了類中發(fā)生結(jié)構(gòu)變化的修改

2.修復(fù)了的非靜態(tài)方法會被反射調(diào)用

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

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

二、你所不知的Java

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

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

2.1、內(nèi)部類編譯

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

2.1.1、靜態(tài)內(nèi)部類/非靜態(tài)內(nèi)部類區(qū)別

靜態(tài)內(nèi)部類/非靜態(tài)內(nèi)部類的區(qū)別大家應(yīng)該都很熟悉，非靜態(tài)內(nèi)部類持有外部類的引用，靜態(tài)內(nèi)部類不持有外部類的引用。所以在android性能優(yōu)化中建議handle 的實現(xiàn)盡量使用靜態(tài)內(nèi)部類，防止外部類Activity類不能被回收導(dǎo)致可能 OOM。非靜態(tài)內(nèi)部類，編譯期間會自動合成 this$0 域表示的就是外部類的引用。

內(nèi)部類和外部類互相訪問

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

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

2.1.2、熱部署解決方案

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

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

• 一個外部類如果有內(nèi)部類，把所有 method/field 的 private訪問權(quán)限改成 protected 或者默認訪問權(quán)限或 public。
• 同時把內(nèi)部類的所有 method/field 的 private 訪問權(quán)限改成 protected或者默認訪問權(quán)限或public。

2.2、匿名內(nèi)部類編譯

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

2.2.1、匿名內(nèi)部類編譯命名規(guī)則

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

2.2.2、熱部署解決方案

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

2.3、有趣的域編譯

2.3.1、靜態(tài)field，非靜態(tài)field編譯

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

來看個簡單的示例。

public class DexFixDemo {
        {
            i = 2;
        }
        private int i = 1;
        private static int j = 1;
        static {
            j = 2;
        }
    }

反編譯為smali看下

2.3.2、靜態(tài)field初始化，靜態(tài)代碼塊

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

• new —個類的對象（new-instance 指令）
• 調(diào)用類的靜態(tài)方法（invoke-static 指令）
• 獲取類的靜態(tài)域的值（sget 指令）

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

2.3.3、非靜態(tài)field初始化，非靜態(tài)代碼塊

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

構(gòu)造函數(shù)會被android編譯器自動翻譯成＜init＞方法

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

首先執(zhí)行 new-instance指令，主要為對象分配堆內(nèi)存，同時如果類如果之前沒加載過，嘗試加載類。然后執(zhí)行invoke-direct 指令調(diào)用類的 init構(gòu)造函數(shù)方法執(zhí)行對象的初始化。

2.3.4、熱部署解決方案

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

2.4、final static 域編譯

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

2.4.1、final static域編譯規(guī)則

final static 靜態(tài)常量域。看下 final static 域被編譯后的樣子。

看下反編譯得到的smali文件

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

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

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

現(xiàn)在我們知道了 static 和 final static 修飾 field 的區(qū)別了。簡單來說：

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

2.4.2、final static域優(yōu)化原理

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

2.4.3、熱部署解決方案

所有我們可以得到最后的結(jié)論：

• 修改 final static 基本類型或者 String類型域(非引用類型)域，由于編譯期 間引用到基本類型的地方被立即數(shù)替換，引用到String類型(非引用類型) 的地方被常量池索引id替換，所以在熱部署模式下，最終所有引用到該 finalstatic 域的方法都會被替換。實際上此時仍然可以走熱部署。
• 修改 final static 引用類型域，是不允許的，因為這個 field的初始化會被翻譯到clinit方法中，所以此時沒法走熱部署。

2.5、有趣的方法編譯

2.5.1、應(yīng)用混淆方法編譯

除了以上的內(nèi)部類/匿名內(nèi)部類可能會造成method新增之后，我們發(fā)現(xiàn)項目如 果應(yīng)用了混淆，由于可能導(dǎo)致方法的內(nèi)聯(lián)和裁剪，那么最后也可能導(dǎo)致method的新 增/減少，以下介紹哪些場景會造成方法的內(nèi)聯(lián)和裁剪。

2.5.2、方法內(nèi)聯(lián)

實際上有好幾種情況可能導(dǎo)致方法被內(nèi)聯(lián)掉。

1.方法沒有被其它任何地方引用到，毫無疑問，該方法會被內(nèi)聯(lián)掉

2.方法足夠簡單，比如一個方法的實現(xiàn)就只有一行，該方法會被內(nèi)聯(lián)掉，那么 任何調(diào)用該方法的地方都會被該方法的實現(xiàn)替換掉

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

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

此時假如print方法足夠復(fù)雜，同時只在 test 方法中被調(diào)用，假設(shè) test方法沒被內(nèi)聯(lián)，print 方法由于只有一個地方調(diào)用此時 print方法會被內(nèi)聯(lián)。

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

2.5.3、方法裁剪

查看下生成的mapping.txt文件

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

void test$faab20d() -> a

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

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

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

2.5.4、熱部署解期案

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

2.6、switch case 語句編譯

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

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

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

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

2.6.1、熱部署解決方案

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

2.7、泛型編譯

泛型是 java5 才開始引入的，我們發(fā)現(xiàn)泛型的使用，也可能導(dǎo)致 method的新增，所以是時候深入了解一下泛型的編譯過程了。

為什么需要泛型？

• Java語言中的泛型基本上完全在編譯器中實現(xiàn)，由編譯器執(zhí)行類型檢查和類 型推斷，然后生成普通的非泛型的字節(jié)碼，就是虛擬機完全無感知泛型的存在。這種實現(xiàn)技術(shù)稱為擦除(erasure)編譯器使用泛型類型信息保證類型安 全，然后在生成字節(jié)碼之前將其清除。
• Java5才引入泛型，所以擴展虛擬機指令集來支持泛型被認為是無法接受的， 因為這會為Java 廠商升級其JVM造成難以逾越的障礙。因此采用了可以完 全在編譯器中實現(xiàn)的擦除方法。

2.7.1、類型擦除與多態(tài)的沖突和解決

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

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

2.7.2、泛型類型轉(zhuǎn)換

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

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

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

2.7.3、熱部署解決方案

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

另外一方面，實際上泛型方法內(nèi)部會生成一個 dalvik/annotation/Signa- ture 這個系統(tǒng)注解

2.8、Lambda表達式編譯

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

2.8.1、Lambda表達式編譯規(guī)則

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

• 關(guān)鍵字 this 匿名類的this關(guān)鍵字指向匿名類，而lambda表達式的this關(guān)鍵 字指向包圍lambda表達式的類。
• 編譯方式，Java編譯器將lambda表達式編譯成類的私有方法，使用了 Java7 的 invokedynamic 字節(jié)碼指令來動態(tài)綁定這個方法。Java編譯器將匿名內(nèi)部類編譯成外部類&numble的新類。

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

• 共同點：輻譯期間都會為外部類合成一個static輔助方法，該方法內(nèi)部邏輯 實現(xiàn)lambda表達式。
• 不同點：class字節(jié)碼中通過 invokedynamic 指令執(zhí)行l(wèi)ambda表達式。而.dex字節(jié)碼中執(zhí)行l(wèi)ambda表達式跟普通方法調(diào)用沒有任何區(qū)別。class字節(jié)碼中運行時生成新類。.dex字節(jié)碼中編譯期間生成新類。

2.8.2、熱部署解決方案

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

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

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

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

2.9、訪問權(quán)限檢查對熱替換的影響

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

2.9.1、類加載階段父類/實現(xiàn)接口訪問權(quán)限檢查

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

2.9.2、類校驗階段訪問權(quán)限檢查

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

2.10、＜clinit＞方法

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

三、冷啟動類加載原理

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

3.1、冷啟動實現(xiàn)方案概述

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

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

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

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

3.2、類校驗

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

• dvmVerifyClass：類校驗，類校驗的目的簡單來說就是為了防止類被篡改校 驗類的合法性。此時會對類的每個方法進行校驗，這里我們只需要知道如果 類的所有方法中直接引用到的類(第一層級關(guān)系，不會進行遞歸搜索)和當(dāng)前 類都在同一個dex中的話，dvmVerifyClass 就返回 true。
• dvmOptimizeClass：類優(yōu)化，簡單來說這個過程會把部分指令優(yōu)化成虛擬機 內(nèi)咅B(yǎng)指令，比如方法調(diào)用指令：invoke-*指令變成了 invoke-*-quick, quick指令會從類的vtable表中直接取，vtable簡單來說就是類的所有方法 的一張大表(包括繼承自父類的方法)o因此加快了方法的執(zhí)行速率。

3.3、Art下冷啟動實現(xiàn)

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

需要注意一點:

• 補丁dex必須命名為classes.dex
• loadDex得到的DexFile完整替換掉dexElements數(shù)組而不是插入

3.4、不得不說的其它點

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

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

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

3.5、完整的方案考慮

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

• Dalvik下采用我們自行研發(fā)的全量DEX方案
• Art 下本質(zhì)上虛擬機已經(jīng)支持多dex的加載，我們要做的僅僅是把補丁 dex 作為主 dex(classes.dex) 加載而已。

四、多態(tài)對冷啟動類加載的影響

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

4.1、重新認識多態(tài)

實現(xiàn)多態(tài)的技術(shù)一般叫做動態(tài)綁定，是指在執(zhí)行期間判斷所引用對象的實際類 型，根據(jù)其實際的類型調(diào)用其相應(yīng)的方法。多態(tài)一般指的是非靜態(tài)非private方法的多態(tài)。field 和靜態(tài)方法不具有多態(tài)性。

子類 vtable 的大小等于子類 virtual方法數(shù)+父類vtable的大小。

• 整個復(fù)制父類 vtable 到子類的 vtable
• 遍歷子類的 virtual 方法集合，如果方法原型一致，說明是重寫父類方法，那么相同索引位置處，子類重寫方法覆蓋掉 vtable 中父類的方法
• 方法原型不一致，那么把該方法添加到vtable的末尾

4.2、冷啟動方案限制

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

• dvmVerifyClass:類校驗，類校驗的目的簡單來說就是為了防止類被篡改校 驗類的合法性。此時會對類的每個方法進行校驗，這里我們只需要知道如果 類的所有方法中直接引用到的類(第一層級關(guān)系，不會進行遞歸搜索)和當(dāng)前 類都在同一個dex中的話，dvmVerifyClass就返回true。
• dvmOptimizeClass:類優(yōu)化，簡單來說這個過程會把部分指令優(yōu)化成虛擬機 內(nèi)部指令，比如方法調(diào)用指令：invoke-virtual-quick, quick指令會從類的 vtable 表中直接取，vtable簡單來說就是類的所有方法的一張大表(包括繼 承自父類的方法)。因此加快了方法的執(zhí)行速率。

所以，如果在補丁類中新增新的方法有可能會導(dǎo)致方法調(diào)用錯亂。

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

5.1、一種新的全量Dex方案

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

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

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

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

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

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

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

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

5.2、對于 Application 的處理

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

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

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

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

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

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

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

• 第一種辦法，讓Application用到的所有非系統(tǒng)類都和Application位 于同一個dex里，這就可以保證pre-verified標(biāo)志被打上，避免進入 dvmOptResolveClass，而在補丁加載完之后，我們再清除 pre-verified 標(biāo)志，使得接下來使用其他類也不會報錯。
• 第二種辦法，把Application里面除了熱修復(fù)框架代碼以外的其他代碼都剝離開，單獨提出放到一個其他類里面，這樣使得Application不會直接用到 過多非系統(tǒng)類，這樣，保證這個單獨拿出來的類和Application處于同一個 dex的幾率還是比較大的。如果想要更保險，Application可以采用反射方式 訪問這個單獨類，這樣就徹底扌巴Application和其他類隔絕開了。

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

以上就是深入理解Android熱修復(fù)技術(shù)原理之代碼熱修復(fù)技術(shù)的詳細內(nèi)容，更多關(guān)于Android代碼熱修復(fù)的資料請關(guān)注腳本之家其它相關(guān)文章！