Android中如何自定義ClassLoader耗時(shí)

今天就跟大家聊聊有關(guān)Android中如何自定義ClassLoader耗時(shí)，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

首先看下西瓜目前使用的插件 ClassLoader 是怎么注入的，大致代碼如下：

代碼大致意思是在 PathClassLoader 和 BootClassLoader 之間插入了一個(gè) DelegateClassLoader，而在 DelegateClassLoader 的 findClass 方法中去執(zhí)行插件 Class 的加載。

為了方便驗(yàn)證，寫一個(gè)簡單的測試Demo，測試加載一個(gè)類的耗時(shí)：

以小米Max2，Android7.1.1機(jī)型為例，測試不注入和注入 DelegateClassLoader 加載一個(gè)類的耗時(shí)：

不注入：60μs

注入后：472μs

差不多慢了8倍，測試了幾款手機(jī)基本數(shù)據(jù)都差不多，但是4.x手機(jī)上這兩種情況下耗時(shí)差別卻很小。

DelegateClassLoader.findClass耗時(shí)？

因?yàn)殡p親委托機(jī)制，所以宿主中所有類的加載都會(huì)走到 DelegateClassLoader.findClass 中，但是 DelegateClassLoader 中因?yàn)椴淮嬖谒拗黝?，所以必然找不到，因此一個(gè)宿主類的加載會(huì)多調(diào)用了一次無用的 findClass 方法，一次findClass的調(diào)用會(huì)帶來如此大的耗時(shí)？于是將 DelegateClassLoader 代碼精簡成下面這樣的：

這樣，DelegateClassLoader 中沒有做任何插件類加載的邏輯，只是做了一個(gè)中轉(zhuǎn)到父 ClassLoader 的 loadClass 的操作。

結(jié)果依然是8倍左右的耗時(shí)差距。

java方法調(diào)用耗時(shí)？

上面方案里只是比不注入自定義 ClassLoader 多了一次 DelegateClassLoader.loadClass 方法的調(diào)用，理論上不可能存在這么大的耗時(shí)。如果說多調(diào)用一次 java 方法 DelegateClassLoader.loadClass 會(huì)有8倍的耗時(shí)差異的話，那么多調(diào)用兩次是不是就是16倍的差異？

于是嘗試注入兩個(gè) DelegateClassLoader，類似這樣：

但是結(jié)果還是8倍左右的耗時(shí)差異，并非16倍，這么說不是方法調(diào)用帶來的性能損耗。

自定義ClassLoader耗時(shí)？

所以猜測可能是系統(tǒng)對 PathClassLoader 有什么優(yōu)化？然后直接構(gòu)造一個(gè)空的 PathClassLoader 注入到 PathClassLoader 和 BootClassLoader 中間，類似這樣：

神奇的8倍耗時(shí)差異沒了！所以真的是系統(tǒng)對 PathClassLoader 有優(yōu)化？

帶著這個(gè)疑問我們來看下 ClassLoader 的源碼，以 Android 7.1.1 源碼為例。

ClassLoader#loadClass

首先來看下源頭，ClassLoader 的 loadClass 源碼，核心代碼如下：

大致流程是先調(diào)用 findLoadedClass 嘗試從已加載的 class 中查找，然后再調(diào)用父 ClassLoader 的 loadClass 查找，如果依然沒有找到的話，最后再調(diào)用自己的 findClass 加載。

在 JVM 中，類第一次加載時(shí)，肯定之前是沒有加載過的，因此 findLoadedClass 應(yīng)該是返回 null 的，而 BootClassLoader 中只有系統(tǒng)類，因此宿主類的加載應(yīng)該是調(diào)用了 PathClassLoader#findClass 加載的。

PathClassLoader#findClass

那么我們再來看看 PathClassLoader#findClass 的源碼，調(diào)用鏈大致如下：

如果說系統(tǒng)對 ClassLoader 有某些優(yōu)化，那么應(yīng)該只要重點(diǎn)關(guān)注在調(diào)用鏈中有用到 ClassLoader 的地方即可。

整個(gè) findClass 流程中使用到 ClassLoader 的地方并不多，只有 ClassLinker::RegisterDexFile 和 ClassLinker::SetupClass 中使用到了。

• ClassLinker::RegisterDexFile 中是對 ClassLoader 取 class_table 的簡單操作；

• ClassLinker::SetupClass 中是給加載好的 class 設(shè)置 ClassLoader，兩個(gè)方法對 ClassLoader 的操作看上去是不存在任何優(yōu)化的，理論上不會(huì)導(dǎo)致性能損耗，這里不再貼代碼。

如果不是 findClass 里有優(yōu)化，難道在 ClassLoader#findLoadedClass 里？

ClassLoader#findLoadedClass

再來看看 ClassLoader#findLoadedClass 的源碼，調(diào)用鏈大致如下：

首先來看下c層調(diào)用的第一個(gè)方法 VMClassLoader_findLoadedClass :

這里主要有兩個(gè)分支，第一個(gè)分支，第12行調(diào)用 ClassLinker#LookupClass :

這里大致意思是從 ClassLoader 中找到 ClassTable ，然后調(diào)用 ClassTable#Lookup 而這個(gè) ClassTable 里面就保存了已經(jīng)加載過的類以及啟動(dòng)時(shí)從 app image 中加載的類（app image的作用是記錄已經(jīng)編譯好的“熱代碼”，并且在啟動(dòng)時(shí)一次性把它們加載到緩存，參考Tinker博客）。如果一個(gè)類是首次加載且不在 app image 中，那么這里會(huì)返回 null。

這樣就會(huì)走到第二個(gè)分支（第25行） ClassLinker::FindClassInPathClassLoader 中

這里主要分為兩個(gè)部分：

• 第一部分：從37行開始，反射從 Java 層的 PathClassLoader 取得 DexPathList，然后再反射從 DexPathList 中取得 dexElements，然后再遍歷 dexElements，從每個(gè) Element 中取得 dexFile，然后再從 DexFile 中取得 mCookie，然后通過 mCookie 得到 c 層的 DexFile，最后調(diào)用 c 層 DexFile#FindClassDef 來真正的執(zhí)行類的加載，整個(gè)流程其實(shí)就是在 c 層把 Java 層的 PathClassLoader#findClass 邏輯走了一遍；

• 第二部分：采用遞歸的方式，從 BootClassLoader 開始依次到 PathClassLoader 逐個(gè)調(diào)用 FindClassInPathClassLoader，直到找到 class 為止，相當(dāng)于把 Java 層 ClassLoader 的雙親委托加載 class 的機(jī)制在 c 層做了一遍，這個(gè)其實(shí)是 ART 上對 class 加載做的一個(gè)優(yōu)化，但是在 Dalvik 中是沒有這段邏輯的，可以參考/dalvik/native/javalangVMClassLoader.cpp。

重點(diǎn)來了！因?yàn)樯厦媸褂玫搅朔瓷錂C(jī)制取 PathClassLoader 中的字段，為了保證這套機(jī)制不出問題，這里面加了個(gè)校驗(yàn)：

如果 ClassLoader 鏈中存在不認(rèn)識的 ClassLoader，也就是說 ClassLoader 的類不是 BootClassLoader 和 PathClassLoader，那么就認(rèn)為加載類失敗。當(dāng)然這里加載失敗的話，并不會(huì)影響最終類加載結(jié)果，因?yàn)樵?Java 層 findLoadedClass 失敗后，會(huì)走到 findClass 中的。

結(jié)論

在 Android ART 中默認(rèn)的 ClassLoader 機(jī)制，在 ClassLoader#findLoadedClass 時(shí)就把 JVM 中的 findLoadedClass 和 findClass 兩件事情都做了。但是如果在 class loader 鏈中存在自定義 ClassLoader，那么這個(gè)機(jī)制就會(huì)失效，會(huì)回退到 JVM 默認(rèn)的 ClassLoader 機(jī)制。

回到上面的問題，由于我們自定義了 ClassLoader，導(dǎo)致 Art 的 ClassLoader 機(jī)制回退到了 JVM 的默認(rèn)類加載機(jī)制，而 JVM 默認(rèn)的類加載機(jī)制存在多次 JNI 調(diào)用，JNI 調(diào)用本身性能是比直接方法調(diào)用耗時(shí)高幾倍的，這里不再詳細(xì)展開，因此也就能解釋前面所說的幾倍的耗時(shí)差異了。

看完上述內(nèi)容，你們對Android中如何自定義ClassLoader耗時(shí)有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。