相關文章
解析ClassLoader系列
前言
在Android應用開發中,熱修復技術被越來越多的開發者所使用,也出現了很多熱修復框架,比如:AndFix、Tinker、Dexposed和Nuwa等等。如果只是會這些熱修復框架的使用那意義並不大,我們還需要了解它們的原理,這樣不管熱修復框架如何變化,只要基本原理不變,我們就可以很快的掌握它們。這一個系列不會對某些熱修復框架源碼進行解析,而是講解熱修復框架的通用原理。
1.熱修復的產生概述
在開發中我們會遇到如下的情況:
1. 剛發佈的版本出現了嚴重的bug,這就需要去解決bug、測試並打渠道包在各個應用市場上重新發布,這會耗費大量的人力物力,代價會比較大。
2. 已經改正了此前發佈版本的bug,如果下一個版本是一個大版本,那麼兩個版本的間隔時間會很長,這樣要等到下個大版本發佈再修復bug,這樣此前版本的bug會長期的影響用戶。
3. 版本升級率不高,並且需要很長時間來完成版本覆蓋,此前版本的bug就會一直影響不升級版本的用戶。
4. 有一個小而重要的功能,需要短時間內完成版本覆蓋,比如節日活動。
爲了解決上面的問題,熱修復框架就產生了。對於Bug的處理,開發人員不要過於依賴熱修復框架,在開發的過程中還是要按照標準的流程做好自測、配合測試人員完成測試流程。
2.熱修復框架的對比
熱修復框架的種類繁多,按照公司團隊劃分主要有以下幾種:
類別 | 成員 |
---|---|
阿里系 | AndFix、Dexposed、阿里百川、Sophix |
騰訊系 | 微信的Tinker、QQ空間的超級補丁、手機QQ的QFix |
知名公司 | 美團的Robust、餓了麼的Amigo、美麗說蘑菇街的Aceso |
其他 | RocooFix、Nuwa、AnoleFix |
雖然熱修復框架很多,但熱修復框架的核心技術主要有三類,分別是代碼修復、資源修復和動態鏈接庫修復,其中每個核心技術又有很多不同的技術方案,每個技術方案又有不同的實現,另外這些熱修復框架仍在不斷的更新迭代中,可見熱修復框架的技術實現是繁多可變的。作爲開發需需要了解這些技術方案的基本原理,這樣就可以以不變應萬變。
部分熱修復框架的對比如下表所示。
特性 | AndFix | Tinker/Amigo | QQ空間 | Robust/Aceso |
---|---|---|---|---|
即時生效 | 是 | 否 | 否 | 是 |
方法替換 | 是 | 是 | 是 | 是 |
類替換 | 否 | 是 | 是 | 否 |
類結構修改 | 否 | 是 | 否 | 否 |
資源替換 | 否 | 是 | 是 | 否 |
so替換 | 否 | 是 | 否 | 否 |
支持gradle | 否 | 是 | 否 | 否 |
支持ART | 是 | 是 | 是 | 是 |
支持Android7.0 | 是 | 是 | 是 | 是 |
我們可以根據上表和具體業務來選擇合適的熱修復框架,當然上表的信息很難做到完全準確,因爲部分的熱修復框架還在不斷更新迭代。
從表中也可以發現Tinker和Amigo擁有的特性最多,是不是就選它們呢?也不盡然,擁有的特性多也意味着框架的代碼量龐大,我們需要根據業務來選擇最合適的,假設我們只是要用到方法替換,那麼使用Tinker和Amigo顯然是大材小用了。另外如果項目需要即時生效,那麼使用Tinker和Amigo是無法滿足需求的。對於即時生效,AndFix、Robust和Aceso都滿足這一點,這是因爲AndFix的代碼修復採用了底層替換方案,而Robust和Aceso的代碼修復借鑑了Instant Run原理,現在我們就來學習代碼修復。
3.代碼修復
代碼修復主要有三個方案,分別是底層替換方案、類加載方案和Instant Run方案。
3.1 類加載方案
類加載方案基於Dex分包方案,什麼是Dex分包方案呢?這個得先從65536限制和LinearAlloc限制說起。
65536限制
隨着應用功能越來越複雜,代碼量不斷地增大,引入的庫也越來越多,可能會在編譯時提示如下異常:
com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536
這說明應用中引用的方法數超過了最大數65536個。產生這一問題的原因就是系統的65536限制,65536限制的主要原因是DVM Bytecode的限制,DVM指令集的方法調用指令invoke-kind索引爲16bits,最多能引用 65535個方法。
LinearAlloc限制
在安裝時可能會提示INSTALL_FAILED_DEXOPT。產生的原因就是LinearAlloc限制,DVM中的LinearAlloc是一個固定的緩存區,當方法數過多超出了緩存區的大小時會報錯。
爲了解決65536限制和LinearAlloc限制,從而產生了Dex分包方案。Dex分包方案主要做的是在打包時將應用代碼分成多個Dex,將應用啓動時必須用到的類和這些類的直接引用類放到主Dex中,其他代碼放到次Dex中。當應用啓動時先加載主Dex,等到應用啓動後再動態的加載次Dex,從而緩解了主Dex的65536限制和LinearAlloc限制。
Dex分包方案主要有兩種,分別是Google官方方案、Dex自動拆包和動態加載方案。因爲Dex分包方案不是本章的重點,這裏就不再過多的介紹,我們接着來學習類加載方案。
在Android解析ClassLoader(二)Android中的ClassLoader中講到了ClassLoader的加載過程,其中一個環節就是調用DexPathList的findClass的方法,如下所示。
libcore/dalvik/src/main/java/dalvik/system/DexPathList.java
public Class<?> findClass(String name, List<Throwable> suppressed) {
for (Element element : dexElements) {//1
Class<?> clazz = element.findClass(name, definingContext, suppressed);//2
if (clazz != null) {
return clazz;
}
}
if (dexElementsSuppressedExceptions != null) {
suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
}
return null;
}
Element內部封裝了DexFile,DexFile用於加載dex文件,因此每個dex文件對應一個Element。
多個Element組成了有序的Element數組dexElements。當要查找類時,會在註釋1處遍歷Element數組dexElements(相當於遍歷dex文件數組),註釋2處調用Element的findClass方法,其方法內部會調用DexFile的loadClassBinaryName方法查找類。如果在Element中(dex文件)找到了該類就返回,如果沒有找到就接着在下一個Element中進行查找。
根據上面的查找流程,我們將有bug的類Key.class進行修改,再將Key.class打包成包含dex的補丁包Patch.jar,放在Element數組dexElements的第一個元素,這樣會首先找到Patch.dex中的Key.class去替換之前存在bug的Key.class,排在數組後面的dex文件中的存在bug的Key.class根據ClassLoader的雙親委託模式就不會被加載,這就是類加載方案,如下圖所示。
類加載方案需要重啓App後讓ClassLoader重新加載新的類,爲什麼需要重啓呢?這是因爲類是無法被卸載的,因此要想重新加載新的類就需要重啓App,因此採用類加載方案的熱修復框架是不能即時生效的。
雖然很多熱修復框架採用了類加載方案,但具體的實現細節和步驟還是有一些區別的,比如QQ空間的超級補丁和Nuwa是按照上面說得將補丁包放在Element數組的第一個元素得到優先加載。微信Tinker將新舊apk做了diff,得到patch.dex,然後將patch.dex與手機中apk的classes.dex做合併,生成新的classes.dex,然後在運行時通過反射將classes.dex放在Element數組的第一個元素。餓了麼的Amigo則是將補丁包中每個dex 對應的Element取出來,之後組成新的Element數組,在運行時通過反射用新的Element數組替換掉現有的Element 數組。
採用類加載方案的主要是以騰訊係爲主,包括微信的Tinker、QQ空間的超級補丁、手機QQ的QFix、餓了麼的Amigo和Nuwa等等。
3.2 底層替換方案
與類加載方案不同的是,底層替換方案不會再次加載新類,而是直接在Native層修改原有類,由於是在原有類進行修改限制會比較多,不能夠增減原有類的方法和字段,如果我們增加了方法數,那麼方法索引數也會增加,這樣訪問方法時會無法通過索引找到正確的方法,同樣的字段也是類似的情況。
底層替換方案和反射的原理有些關聯,就拿方法替換來說,方法反射我們可以調用java.lang.Class.getDeclaredMethod,假設我們要反射Key的show方法,會調用如下所示。
Key.class.getDeclaredMethod("show").invoke(Key.class.newInstance());
Android 8.0的invoke方法,如下所示。
libcore/ojluni/src/main/java/java/lang/reflect/Method.java
@FastNative
public native Object invoke(Object obj, Object... args)
throws IllegalAccessException, IllegalArgumentException, InvocationTargetException;
invoke方法是個native方法,對應Jni層的代碼爲:
art/runtime/native/java_lang_reflect_Method.cc
static jobject Method_invoke(JNIEnv* env, jobject javaMethod, jobject javaReceiver,
jobject javaArgs) {
ScopedFastNativeObjectAccess soa(env);
return InvokeMethod(soa, javaMethod, javaReceiver, javaArgs);
Method_invoke函數中又調用了InvokeMethod函數:
art/runtime/reflection.cc
jobject InvokeMethod(const ScopedObjectAccessAlreadyRunnable& soa, jobject javaMethod,
jobject javaReceiver, jobject javaArgs, size_t num_frames) {
...
ObjPtr<mirror::Executable> executable = soa.Decode<mirror::Executable>(javaMethod);
const bool accessible = executable->IsAccessible();
ArtMethod* m = executable->GetArtMethod();//1
...
}
註釋1處獲取傳入的javaMethod(Key的show方法)在ART虛擬機中對應的一個ArtMethod指針,ArtMethod結構體中包含了Java方法的所有信息,包括執行入口、訪問權限、所屬類和代碼執行地址等等,ArtMethod結構如下所示。
art/runtime/art_method.h
class ArtMethod FINAL {
...
protected:
GcRoot<mirror::Class> declaring_class_;
std::atomic<std::uint32_t> access_flags_;
uint32_t dex_code_item_offset_;
uint32_t dex_method_index_;
uint16_t method_index_;
uint16_t hotness_count_;
struct PtrSizedFields {
ArtMethod** dex_cache_resolved_methods_;//1
void* data_;
void* entry_point_from_quick_compiled_code_;//2
} ptr_sized_fields_;
}
ArtMethod結構中比較重要的字段是註釋1處的dex_cache_resolved_methods_和註釋2處的entry_point_from_quick_compiled_code_,它們是方法的執行入口,當我們調用某一個方法時(比如Key的show方法),就會取得show方法的執行入口,通過執行入口就可以跳過去執行show方法。
替換ArtMethod結構體中的字段或者替換整個ArtMethod結構體,這就是底層替換方案。
AndFix採用的是替換ArtMethod結構體中的字段,這樣會有兼容問題,因爲廠商可能會修改ArtMethod結構體,導致方法替換失敗。Sophix採用的是替換整個ArtMethod結構體,這樣不會存在兼容問題。
底層替換方案直接替換了方法,可以立即生效不需要重啓。採用底層替換方案主要是阿里係爲主,包括AndFix、Dexposed、阿里百川、Sophix。
3.3 Instant Run方案
除了資源修復,代碼修復同樣也可以借鑑Instant Run的原理, 可以說Instant Run的出現推動了熱修復框架的發展。
Instant Run在第一次構建apk時,使用ASM在每一個方法中注入了類似如下的代碼:
IncrementalChange localIncrementalChange = $change;//1
if (localIncrementalChange != null) {//2
localIncrementalChange.access$dispatch(
"onCreate.(Landroid/os/Bundle;)V", new Object[] { this,
paramBundle });
return;
}
其中註釋1處是一個成員變量localIncrementalChange ,它的值爲$change
,$change
實現了IncrementalChange這個抽象接口。當我們點擊InstantRun時,如果方法沒有變化則$change
爲null,就調用return,不做任何處理。如果方法有變化,就生成替換類,這裏我們假設MainActivity的onCreate方法做了修改,就會生成替換類MainActivity$override
,這個類實現了IncrementalChange接口,同時也會生成一個AppPatchesLoaderImpl類,這個類的getPatchedClasses方法會返回被修改的類的列表(裏面包含了MainActivity),根據列表會將MainActivity的$change
設置爲MainActivity$override
,因此滿足了註釋2的條件,會執行MainActivity$override
的access$dispatch
方法,access$dispatch方法中會根據參數”onCreate.(Landroid/os/Bundle;)V”執行MainActivity$override
的onCreate方法,從而實現了onCreate方法的修改。
借鑑Instant Run的原理的熱修復框架有Robust和Aceso。
這裏不僅分享Android、Java和移動前端相關技術,還有行業動態、技術資訊、面經和個人感悟。每個月都會爭取送書福利給大家。