一、底層熱替換原理

1.1、Andfix 回顧

我們先來(lái)看一下，為何唯獨(dú) Andfix 能夠做到即時(shí)生效呢？

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

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

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

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

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

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

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

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_了，從名字可以看出來(lái)，他們就是方法的執(zhí)行入口。 我們知道，Java 代碼在 Android 中會(huì)被編譯為 Dex Code。

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

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

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

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

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

1.3、兼容性問(wèn)題的根源

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

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

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

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

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

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

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

變成了這樣的整體替換：

// %%把舊函數(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_；

其實(shí)可以濃縮為：

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

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

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

對(duì)于ROM開(kāi)發(fā)者而言，是在art源代碼里面，所以一個(gè)簡(jiǎn)單的sizeof (Art- Method)就行了，因?yàn)檫@是在編譯期就可以決定的。

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

在art里面，初始化一個(gè)類(lèi)的時(shí)候會(huì)給這個(gè)類(lèi)的所有方法分配空間，類(lèi)的方法有direct方法和virtual方法。direct方法包含static方法和所有不可 繼承的對(duì)象方法。而virtual方法就是所有可以繼承的對(duì)象方法了。需要對(duì)兩中類(lèi)型方法都進(jìn)行分配空間。

方法是一個(gè)接一個(gè)緊密地new出來(lái)排列在 ArtMethod Array 中的。這時(shí)只是分配出空間，還沒(méi)填入真正的ArtMethod的各個(gè) 成員值：

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

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

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

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

那么我們就可以在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；

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

memcpy(smeth, dmeth, methSize)；

問(wèn)題就迎刃而解了。

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

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

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

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

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

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

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

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

具體的校驗(yàn)邏輯是在虛擬機(jī)代碼的 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)鍵點(diǎn)在于，Class loaders must match 這行注釋。

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

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

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

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

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

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

// BaseBug. test方法已經(jīng)被熱替換了。
BaseBug bb = new BaseBug();
Method testMeth = BaseBug.class.getDeclaredMethod (11 test");
testMeth.invoke(bb);

invoke的時(shí)候就會(huì)報(bào)：

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，但卻是不同的類(lèi)。

前者是被熱替換的方法所屬的類(lèi)，由于我們把它的 ArtMethod 的 declaring_class_ 替換了，因此就是新的補(bǔ)丁類(lèi)。而后者作為被調(diào)用的實(shí)例對(duì)象 bb的所屬類(lèi), 是原有的 BaseBug。兩者是不同的。

那為什么方法是非靜態(tài)才有這個(gè)問(wèn)題呢？因?yàn)槿绻庆o態(tài)方法，是在類(lèi)的級(jí)別直接進(jìn)行調(diào)用的，就不需要接收對(duì)象實(shí)例作為參數(shù)。所以就沒(méi)有這方面的檢查了。

對(duì)于這種反射調(diào)用非靜態(tài)方法的問(wèn)題，我們會(huì)采用另一種冷啟動(dòng)機(jī)制對(duì)付，本文在最后會(huì)說(shuō)明如何解決。

1.6、即時(shí)生效所帶來(lái)的限制

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

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

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

不過(guò)新增一個(gè)完整的、原先包里面不存在的新類(lèi)是可以的，這個(gè)不受限制。

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

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

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

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

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

二、你所不知的Java

和業(yè)界很多熱修復(fù)方案不同，Sophix 熱修復(fù)一直秉承粒度小、注重快捷修復(fù)、無(wú)侵入適合原生工程。因?yàn)閳?jiān)持這個(gè)原則，我們?cè)谘邪l(fā)過(guò)程中遇到很多編譯期的問(wèn)題，這些問(wèn)題對(duì)我們最終方案的實(shí)施和熱部署也帶來(lái)或多或少地影響，令人印象深刻。

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

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

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

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

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

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

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

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

2.1.2、熱部署解決方案

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

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

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

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

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

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

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

2.2.2、熱部署解決方案

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

2.3、有趣的域編譯

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

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

來(lái)看個(gè)簡(jiǎn)單的示例。

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 。前面說(shuō)過(guò)，類(lèi)加載然后進(jìn)行類(lèi)初始化的時(shí)候，會(huì)去調(diào)用clinit方法，一個(gè)類(lèi)僅加載一次。以下三種情況都會(huì)嘗試去 加載一個(gè)類(lèi):

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

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

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

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

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

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

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

2.3.4、熱部署解決方案

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

2.4、final static 域編譯

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

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"這兩個(gè)靜態(tài)域竟然沒(méi)在中被初始化。其它的非final靜態(tài)域均在clinit函數(shù)中得到初始化。這里注意下 "haha"和new String ("heihei")的區(qū)別，前者是字符串常量，后者是引用類(lèi)型。那這兩個(gè)final static域(i2和s2)究竟在何處得到初始化？

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

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

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

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

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

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

2.4.3、熱部署解決方案

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

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

2.5、有趣的方法編譯

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

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

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

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

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

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

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

舉個(gè)簡(jiǎn)單的例子進(jìn)行說(shuō)明下。

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

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

2.5.3、方法裁剪

查看下生成的mapping.txt文件

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

void test$faab20d() -> a

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

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

注意這里不能用基本類(lèi)型false,必須用包裝類(lèi)Boolean,因?yàn)槿绻麑?xiě)基本類(lèi)型 這個(gè)if語(yǔ)句也很可能會(huì)被優(yōu)化掉的。

2.5.4、熱部署解期案

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

2.6、switch case 語(yǔ)句編譯

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

所以有必要來(lái)探索下switch case語(yǔ)句編譯的特殊性。

看下 testContinue/testNotContinue 方法編譯出來(lái)有何不同。

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

2.6.1、熱部署解決方案

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

2.7、泛型編譯

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

為什么需要泛型？

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

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

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

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

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

同時(shí)前面我們還留了一個(gè)坑，泛型是可以不需要強(qiáng)制類(lèi)型轉(zhuǎn)換。

代碼示例中，第一個(gè)不需要強(qiáng)制類(lèi)型轉(zhuǎn)換，但是第二個(gè)必須強(qiáng)制類(lèi)型轉(zhuǎn)換否則編譯期報(bào)incovertiable types錯(cuò)誤。反編譯看下smali：

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

2.7.3、熱部署解決方案

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

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

2.8、Lambda表達(dá)式編譯

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

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

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

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

dex字節(jié)碼文件和.class字節(jié)碼文件對(duì)lambda表達(dá)式處理的 異同點(diǎn)。

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

2.8.2、熱部署解決方案

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

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

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

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

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

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

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

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

2.9.2、類(lèi)校驗(yàn)階段訪問(wèn)權(quán)限檢查

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

2.10、＜clinit＞方法

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

三、冷啟動(dòng)類(lèi)加載原理

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

3.1、冷啟動(dòng)實(shí)現(xiàn)方案概述

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

上面的表格，我們能清晰的看到兩個(gè)方案的缺點(diǎn)都很明顯。這里對(duì) tinker 方案

dex merge缺陷進(jìn)行簡(jiǎn)單說(shuō)明一下:

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

3.2、類(lèi)校驗(yàn)

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

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

3.3、Art下冷啟動(dòng)實(shí)現(xiàn)

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

需要注意一點(diǎn):

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

3.4、不得不說(shuō)的其它點(diǎn)

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

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

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

3.5、完整的方案考慮

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

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

四、多態(tài)對(duì)冷啟動(dòng)類(lèi)加載的影響

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

4.1、重新認(rèn)識(shí)多態(tài)

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

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

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

4.2、冷啟動(dòng)方案限制

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

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

所以，如果在補(bǔ)丁類(lèi)中新增新的方法有可能會(huì)導(dǎo)致方法調(diào)用錯(cuò)亂。

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

5.1、一種新的全量Dex方案

一般來(lái)說(shuō)，合成完整dex，思路就是把原來(lái)的 dex 和 patch 里的 dex重新合并 成一個(gè)。然而我們的思路是反過(guò)來(lái)的。

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

參照 Android 原生 multi-dex 的實(shí)現(xiàn)再來(lái)看這個(gè)方案，會(huì)很好理解。multi-dex 是把a(bǔ)pk 里用到的所有類(lèi)拆分到 classes.dex、classes2 .dex、classes3.dex、...之中，而每個(gè)dex都只包含了部分的類(lèi)的定義，但單個(gè) dex也是可以加載的，因?yàn)橹灰阉衐ex 都 load 進(jìn)去，本 dex中不存在的類(lèi)就可以在運(yùn)行期間 在其他的dex中找到。

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

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

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

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

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

5.2、對(duì)于 Application 的處理

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

眾所周知，Application是整個(gè)app的入口，因此，在進(jìn)入到替換的完整dex 之前，一定會(huì)通過(guò)Application的代碼，因此，Application必然是加載在原來(lái)的老 dex里面的。只有在補(bǔ)丁加載后使用的類(lèi)，會(huì)在新的完整dex里面找到。

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

在 Application類(lèi)初始化的時(shí)候。此時(shí)補(bǔ)丁還 沒(méi)進(jìn)行加載，所以就會(huì)提前加載到原始dex中的類(lèi)。接下來(lái)當(dāng)補(bǔ)丁加載完畢后，這些 已經(jīng)加載的類(lèi)如果用到了新dex 中的類(lèi)，并且又是 pre-verified 時(shí)就會(huì)報(bào)錯(cuò)。

這里最大的問(wèn)題在于，我們無(wú)法把補(bǔ)丁加載提前到 dvmOptResolveClass之前，因?yàn)樵谝粋€(gè)app的生命周期里，沒(méi)有可能到達(dá)比入口 Application初始化更早的 時(shí)期了。

而這個(gè)問(wèn)題常見(jiàn)于多dex情形，當(dāng)存在多dex時(shí)，無(wú)法保證 Application的用到的類(lèi)和它處于同個(gè)dex 中。如果只有一個(gè) dex，—般就不會(huì)有這個(gè)問(wèn)題。

多dex情況下要想解決這個(gè)問(wèn)題，有兩種辦法：

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

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

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

最新評(píng)論