ClassLoader概念

我們知道，Java源文件（.java）經(jīng)過編譯器編譯之后，會(huì)轉(zhuǎn)換成Java字節(jié)碼(.class)，然而程序是如何加載這些字節(jié)碼文件到內(nèi)存中呢？這就用到了ClassLoader，即類加載器。ClassLoader類加載器負(fù)責(zé)讀取 Java 字節(jié)代碼，并轉(zhuǎn)換成 java.lang.Class類的一個(gè)實(shí)例。從而只有class文件被載入到了內(nèi)存之后，才能被其程序所引用。所以ClassLoader就是用來動(dòng)態(tài)加載class文件到內(nèi)存當(dāng)中用的。

ClassLoader的分類

Android中的常用幾種類加載器類型繼承關(guān)系劃分可以用一組關(guān)系圖來表示

BootClassLoder

通過查看ClassLoader源碼 我們得知，Android中在默認(rèn)父加載器傳入的情況下，默認(rèn)父加載器為PathClassLoder，而PathClassLoader的父加載器正是BootClassLoader。BootClassLoader是ClassLoader的內(nèi)部類，是包內(nèi)可見，我們無法直接使用，也無法直接動(dòng)態(tài)加載。

 /**
   * Encapsulates the set of parallel capable loader types.
   */
  private static ClassLoader createSystemClassLoader() {
    String classPath = System.getProperty("java.class.path", ".");
    String librarySearchPath = System.getProperty("java.library.path", "");

    ...省略部分代碼

    //默認(rèn)父構(gòu)造器為PathClassLoder
    return new PathClassLoader(classPath, librarySearchPath, BootClassLoader.getInstance());
  }

URLClassLoader

URLClassLoader繼承自SecureClassLoader，SecureClassLoader繼承自ClassLoader。URLClassLoader的特點(diǎn)就是只能加載jar文件，但是dalvik不能直接識(shí)別jar。所以在Android中無法直接使用這個(gè)類加載器。

BaseDexClassLoader

BaseDexClassLoader直接繼承自ClassLoader，下面是其構(gòu)造函數(shù)

public BaseDexClassLoader(String dexPath, File optimizedDirectory, String librarySearchPath, ClassLoader parent) {
    super(parent);
    this.pathList = new DexPathList(this, dexPath, librarySearchPath, null);
    ....
  }

下面解析下這四個(gè)參數(shù)

1. dexPath:指目標(biāo)類所在的apk、dex或者jar文件的路徑（包括SD卡），然后加載器將從該路徑中尋找到指定的目標(biāo)類。當(dāng)然了，這個(gè)路徑可以是多個(gè)路徑，這樣可以尋找到多個(gè)目標(biāo)類，多路徑之間需要使用特定的分隔符，分隔符可以使用System.getProperty("path.separtor")獲取。
2. optimizedDirectory:由于dex文件被包含在apk或者jar文件中，需要先解壓出來，而這個(gè)參數(shù) 就代表了被解壓的路徑。而且apk文件其實(shí)也是一個(gè)壓縮包，解壓的過程其實(shí)也是一個(gè)ODEX優(yōu)化的過程，那么何為ODEX優(yōu)化呢？其實(shí)就是把包里面的可執(zhí)行程序提取出來變成ODEX文件，存放到optimizedDirectory目錄下，因?yàn)樘崛〕鰜淼脑?，?yīng)用第一次進(jìn)行啟動(dòng)的時(shí)候，直接使用ODEX文件 啟動(dòng)速度自然是比解壓再啟動(dòng)速度是要快的。為什么是應(yīng)用第一次啟動(dòng)呢？因?yàn)閐ex版本只有第一次啟動(dòng)會(huì)解壓執(zhí)行程序到/data/dalvik-cache（針對(duì)PathClassLoader），或者optimizedDirectory文件目錄下（針對(duì)DexClassLoader），之后就可以直接讀取目錄下的dex文件了。
3. librarySearchPath：指的是目標(biāo)類所使用的c、c++庫存放的路徑
4. parent：是指該加載器的父加載器，一般為當(dāng)前執(zhí)行類的加載器。

PathClassLoader

public PathClassLoader(String dexPath, ClassLoader parent) { 
    super(dexPath, null, null, parent); 
} 

 public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
    super(dexPath, null, librarySearchPath, parent);
   ...
 }

通過源碼我們可以知道，PathClassLoader繼承于BaseDexClassLoader，并且構(gòu)造器將optimizedDirectory置為null，也就是沒有設(shè)置ODEX優(yōu)化后的存儲(chǔ)路徑，前文有提到，如果沒有設(shè)置optimizedDirectory目錄，那么默認(rèn)存儲(chǔ)路徑就是/data/dalvik-cache。因?yàn)檫@個(gè)原因，PathClassLoader被設(shè)定成只能加載Android系統(tǒng)類和已安裝的android應(yīng)用類。

DexClassLoader

public DexClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {
    super(dexPath, new File(optimizedDirectory), librarySearchPath, parent);
   ...
  }

DexClassLoader也是繼承于BaseDexClassLoader，支持加載包含classes.dex文件的apk、jar，前文我們提到dalvik不支持直接加載jar文件，那么為什么到了DexClassLoader這里怎么就可以支持加載了呢？原因在于其父類BaseDexClassLoader對(duì)于“.jar”，“.apk”，".zip"，".dex"后綴的文件都會(huì)進(jìn)行對(duì)應(yīng)的處理，最終提取成可執(zhí)行的dex文件。然而URLClassLoader并未對(duì)此做類似的處理，因此我們一般會(huì)采用DexClassLoader做動(dòng)態(tài)加載。

InMemoryDexClassLoader

 public InMemoryDexClassLoader(ByteBuffer[] dexBuffers, ClassLoader parent) {
    super(dexBuffers, parent);
  }
  
  public InMemoryDexClassLoader(ByteBuffer dexBuffer, ClassLoader parent) {
    this(new ByteBuffer[] { dexBuffer }, parent);
  }

InMemoryDexClassLoader繼承于BaseDexClassLoader，是API26新增的類加載器。dexBuffers數(shù)組構(gòu)造了一個(gè)DexPathList，可用于加載內(nèi)存中的dex。

DelegateLastClassLoader

public DelegateLastClassLoader(String dexPath, ClassLoader parent) {
    super(dexPath, parent);
  }

DelegateLastClassLoader是API27新增的類加載器，繼承自 PathClassLoader。DelegateLastClassLoader實(shí)行最后的查找策略。使用DelegateLastClassLoader來加載每個(gè)類和資源，使用的是以下順序：

1. 判斷是否已經(jīng)加載過該類
2. 搜索此類的類加載器是否已經(jīng)加載過該類
3. 搜索與此類加載器相關(guān)聯(lián)的dexPath文件列表，并委托給父加載器。

雙親委托機(jī)制

Android類加載器通過loadClass加載目標(biāo)類，下面是加載的源碼

 protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
  {
      // 首先檢查當(dāng)前目標(biāo)類是否已經(jīng)被加載過，有則直接返回
      Class<?> c = findLoadedClass(name);
      if (c == null) {
        try {
          if (parent != null) {
            //如果有父類加載器，優(yōu)先使用父類加載器尋找目標(biāo)類
            c = parent.loadClass(name, false);
          } else {
             //其次，如果有輔助類加載器，使用輔助類加載器尋找目標(biāo)類
            c = findBootstrapClassOrNull(name);
          }
        } catch (ClassNotFoundException e) {
          // ClassNotFoundException thrown if class not found
          // from the non-null parent class loader
        }

        if (c == null) {
          //如果仍未找到，則通過尋找子ClassLoader的目標(biāo)類（如果子ClassLoader重寫了findClass）
          c = findClass(name);
        }
      }
      return c;
  }

由上述源碼，我們可以總結(jié)：

1. 當(dāng)前類加載器首先檢查目標(biāo)類是否已經(jīng)被加載過，有則直接返回
2. 當(dāng)前類加載器會(huì)先委托父類加載器加載目標(biāo)類，如果未設(shè)置父加載器，則檢查輔助加載器是否支持查詢加載目標(biāo)類
3. 只有上述加載器找不到目標(biāo)類的時(shí)候，才會(huì)調(diào)用當(dāng)前類加載器（Child） 查詢路徑尋找目標(biāo)類。

以上這么做的好處是：一方面防止目標(biāo)類的重復(fù)加載，另外一方面 主要考慮安全因素，防止有人重寫原生類，比如說java.lang.String這樣的數(shù)據(jù)類型，替換原生的String類，加載到JVM中，造成嚴(yán)重的安全問題。

雙親委托機(jī)制 在Android熱修復(fù)領(lǐng)域中也有著廣泛的應(yīng)用。每個(gè)ClassLoader可以有多個(gè)dex文件，每個(gè)dex文件是一個(gè)Element，多個(gè)dex文件組成一個(gè)dexElements，類加載器尋找類的時(shí)候，會(huì)遍歷dexElements中的dex文件，再通過dex文件遍歷目標(biāo)類。由于雙親委托機(jī)制的存在，尋找到目標(biāo)類后就直接返回，不再尋找其他dex文件下該目標(biāo)類，熱修復(fù)的原理就是hook住ClassLoader，使其先加載修復(fù)后的目標(biāo)類，而存在的BUG的目標(biāo)類不會(huì)被加載。

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論