一、Java中的類加載器

首先花點(diǎn)時間回顧一下Java中的三種類加載器：

• BootStrap ClassLoader 啟動類加載器，它是實現(xiàn)自C/C++的類加載器，用于加載JDK的核心類庫，例如java.lang、java.util等系統(tǒng)類。JVM的啟動需要通過BootStrap ClassLoader來創(chuàng)建一個初始類來完成。
• Extensions ClassLoader 擴(kuò)展類加載器，ExtClassLoader，它用于加載一些系統(tǒng)之外的額外功能。
• Application ClassLoader 應(yīng)用類加載器，也稱作系統(tǒng)類加載器，它可以通過getSystemClassLoader拿到，也可以稱為系統(tǒng)類加載器。
• Custom ClassLoader 自定義類加載器，我們可以通過繼承java.lang.ClassLoader類來實現(xiàn)自己的類加載器，注意，ExtClassLoader和AppClassLoader也是繼承自java.lang.ClassLoader類的。

總體的加載關(guān)系是：null->ExtClassloader->AppClassLoader，需要注意的是，BootStrap ClassLoader無法在Java中通過.class.getClassLoader()訪問它的父加載器。

同時，這只代表加載關(guān)系，而不代表繼承關(guān)系，ClassLoader的繼承關(guān)系如下：

其中：

• ClassLoader本身是一個抽象類，定義了主要的一些功能。
• SecureClassLoader擴(kuò)展實現(xiàn)了ClassLoader方面加入權(quán)限方面的功能，加強(qiáng)了ClassLoader的安全性。
• URLClassLoader通過URL路徑，從Jar文件和文件夾下加載類和資源。
• ExtClassLoader和AppClassLoader，本身都是Launcher應(yīng)用的內(nèi)部類，Launcher是Java虛擬機(jī)的入口應(yīng)用，二者都在Launcher中初始化；

雙親委派機(jī)制，大致意思就是當(dāng)一個類加載器去加載某個類時，會優(yōu)先委托給父加載器去進(jìn)行加載，而不是自己加載。這樣能夠有效地保護(hù)加載類的安全性，比如我們希望加載一個java.lang.String類，在雙親委派機(jī)制下，我們就會優(yōu)先由父類進(jìn)行加載，而不是我們自己的類加載器去做加載，父類加載器會從指定的，安全的目錄下查找String類。如果是我們自己的類加載器中加載該類那么可能會出現(xiàn)一些安全方面的問題。換句話說，你自己定義的java.lang.String類是無法被加載的。當(dāng)然，這個前提是，你得遵循雙親委派機(jī)制，如果你重新寫個類加載器，自定義了loadClass并且不遵循雙親委派機(jī)制，那么雙親委派機(jī)制就被打破了。這也是為什么，JVM認(rèn)為兩個類相等不僅僅要類名相等，而且要類加載器相等才是同一個類。

二、Android中的類加載器

區(qū)別于標(biāo)準(zhǔn)JVM以Class文件為輸入的字節(jié)碼文件，Android虛擬機(jī)采用更為緊湊的Dex文件作為輸入文件，無論是Dalvik VM還是ART VM。這樣一來，類加載器自然也會有所改變。

Android中的類加載器類型被分為兩類：

• 系統(tǒng)類加載器：PathClassLoader、DexClassLoader、BootClassLoader
• 自定義類加載器

2.1 BootClassLoader

Android 系統(tǒng)啟動時，會使用BootClassLoader來加載常用的類，與SDK中的BootStrap ClassLoader不同的是，它本身不是由C/C++實現(xiàn)的， 而是采用Java實現(xiàn)的，它是ClassLoader的內(nèi)部類，繼承自ClassLoader，本身是一個單例類。應(yīng)用中無法直接訪問到BootClassLoader。

BootClassLoader是在ZygoteInit的入口方法中，間接調(diào)用了preloadClasses方法中，進(jìn)行創(chuàng)建的，Android在/framework/base/preloaded-classes中封裝了一系列的預(yù)加載類的目錄，一些常用類，例如：ContextImpl、Fragment、Dialog等等都在列。預(yù)加載之后，應(yīng)用程序啟動時，就不用額外去做加載了。

2.2 PathClassLoader

PathClassLoader它通常被系統(tǒng)用來加載Apk中自帶的Dex文件，它的構(gòu)造函數(shù)中少了一個參數(shù)：optimizedDirectory，這是因為PathClassLoader定義了默認(rèn)的optimizedDirectory參數(shù)：/data/dalvik-cache/，因此，我們無法自定義Dex文件的解壓路徑，所以我們加載類時，一般都使用DexClassLoader。

PathClassLoader是Zygote進(jìn)程在fork SystemServer進(jìn)程時創(chuàng)建的，當(dāng)Zygote進(jìn)程在新創(chuàng)建SystemServer時，通過調(diào)用forkSystemServer方法時，會調(diào)用到handleSystemServerProcess()，然后調(diào)用createPathClassLoader()去創(chuàng)建PathClassLoader。

2.3 DexClassLoader

可以在磁盤中加載.dex或者是.apk文件，但是本質(zhì)上都是加載屬于Android 的字節(jié)碼文件：Dex文件。

它的構(gòu)造方法有四個參數(shù)：

• dexPath：相關(guān)的文件路徑；支持多個路徑，使用「:」分割
• optimizedDirectory：Dex文件解壓后的文件存儲路徑，一般情況下使用當(dāng)前文件的私有路徑。

"this parameter is deprecated and has no effect since API level 26."

注意：optimizedDirectory參數(shù)在API26之后被廢棄了

• librarySearchPath：包含C/C++庫的路徑集合，可以為null
• parent：父加載器

我們通常在App啟動時，我們通常使用DexClassLoader動態(tài)加載Dex的方式來實現(xiàn)應(yīng)用程序Java代碼層面的熱修復(fù)。

2.4 InMemoryDexClassLoader

Android8.0 中新增的用于加載內(nèi)存中的類加載器。和PathClassLoader、DexClassLoader一樣，都是BaseDexClassLoader的實現(xiàn)類。

三、Dex文件

3.1 Android內(nèi)存中的Dex文件

BaseDexClassLoader有三個子類：DexClassLoader、PathClassLoader、InMemoryDexClassLoader，它們?nèi)齻€主要任務(wù)就是：加載外部的Dex文件，獲取其中定義的類信息。同樣，Android的類加載機(jī)制也遵循雙親委派機(jī)制。

BaseDexClassLoader有一個特殊的結(jié)構(gòu)：DexPathList類型的pathList ，它內(nèi)部維護(hù)了一個Element類型的數(shù)組，用來存儲被加載的Dex文件信息：

private Element[] dexElements;

每當(dāng)我們要使用一個類時，類加載器就會先檢索：DexPathList中的所有Dex文件，逐個遍歷，看看其中是否含有所需要的類：

Element內(nèi)部有一個對象：DexFile，在調(diào)用Element#findClass時，會按照如下規(guī)則去查找：

而最終，loadClassBinaryName會調(diào)用Native代碼在本地內(nèi)存上創(chuàng)建一個指向Dex文件的對象，這樣 ，我們知道Dex文件在內(nèi)存中的引用是類加載下的DexPathList中的一個個Element。

這個Element數(shù)組可以作為一個熱修復(fù)的接入點(diǎn)，我們知道，類加載只會被加載一次，如果此時我們有多個Dex文件，那么Dex文件的引用在Element中會按照加載的順序排列，這樣一來，排在前面的Dex類中的Class就會被優(yōu)先加載，由此我們就可以將熱修復(fù)后重新生成的Patch.dex或Patch.apk加載到用戶手機(jī)存儲空間當(dāng)中，然后自行使用DexPathClassLoader進(jìn)行加載，并通過反射，Hook掉PathClassLoader，將Patch.dex對應(yīng)的Element反射插入到其DexPathList當(dāng)中去。這樣一來，加載時就會優(yōu)先從Patch.dex中加載了，原理大致如下圖。修復(fù)后加載原先出錯的類ClassE將會從Patch.dex中優(yōu)先加載，而出錯的Class E由于類加載的特性，將不會被加載出來。

3.2 Dex文件的生成

我們所編寫的Java代碼，使用Java自帶的編譯器編譯完成之后默認(rèn)的輸出一定是.class文件，而在ART或者Dalvik虛擬機(jī)中需要輸入Dex文件，那么在其中必然存在Class -> Dex文件的過程。

該過程是由d8工具完成的，在我們的SDK目錄下：/Library/Android/sdk/build-tools/28.0.3，有非常多和我們Android 構(gòu)建相關(guān)的一些工具，例如aapt2工具會負(fù)責(zé)將res.xml中的文件在R.java中生成對應(yīng)的ID引用、負(fù)責(zé)將二進(jìn)制資源、資源表resources.arsc、classes.dex以及assets集成打包進(jìn)一個未簽名的.apk文件內(nèi)。

d8工具會將需要打包的.class文件、額外依賴的Jar文件一同參與編譯。比如我們需要對appt2下的一個MainActivity.class文件進(jìn)行編譯，那么我們可以在一個新項目中，點(diǎn)擊Android Studio的編譯或者上面的綠色小錘子，然后在：MyApplication2/app/build/intermediates/javac/debug/classes/com/red/myapplication 下我看到MainActicity.class文件，然后在該目錄下執(zhí)行如下的指令，注意，將MainActivity的AppcompatActivity換成Activity，因為前者是屬于AndroidX系列的的AAR包中的依賴，需要額外添加。

d8 aapt/MainActivity.class
 --lib /Library/Android/sdk/platforms/android-29/android.jar
 --output ./

其中，--lib指定了一些額外的依賴，因為MainActivity中會依賴android.jar中的一些文件（比如Activity類），完成后，我們就得到了一個classes.dex文件，結(jié)構(gòu)如下：

如上的步驟都在Android提供的Gradle套件中，幫我們完成了，Gradle插件依賴的本質(zhì)，就是插件文件的下載(Gradle同步)和引用。

到此這篇關(guān)于Android 中的類文件和類加載器詳情的文章就介紹到這了,更多相關(guān)Android 類文件 內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論