一.概述

通過本篇文章的學習，你將學會：
1.java中類加載機制
2.Android中類加載機制

二.java類加載機制

java類加載流程

JVM類加載機制分為五個部分：加載，驗證，準備，解析，初始化。如下圖所示：

image.png

image.png

類加載器

• 啟動類加載器，Bootstrap ClassLoader，加載JACA_HOME\lib，或者被-Xbootclasspath參數限定的類
• 擴展類加載器，Extension ClassLoader，加載\lib\ext，或者被java.ext.dirs系統變量指定的類
• 應用程序類加載器，Application ClassLoader，加載ClassPath中的類庫

• 自定義類加載器，通過繼承ClassLoader實現，一般是加載我們的自定義類

  
  
  image.png

雙親委派模型

雙親委派是指每次收到類加載請求時，先將請求委派給父類加載器完成（所有加載請求最終會委派到頂層的Bootstrap ClassLoader加載器中），如果父類加載器無法完成這個加載（該加載器的搜索范圍中沒有找到對應的類），子類嘗試自己加載。這樣的好處可以避免一個類被多次加載。
我們看一下loadClass方法：

protected Class<?> loadClass(String name, boolean resolve)
      throws ClassNotFoundException
  {
      synchronized (getClassLoadingLock(name)) {
          // 先從緩存查找該class對象，找到就不用重新加載
          Class<?> c = findLoadedClass(name);
          if (c == null) {
              long t0 = System.nanoTime();
              try {
                  if (parent != null) {
                      //如果找不到，則委托給父類加載器去加載
                      c = parent.loadClass(name, false);
                  } else {
                  //如果沒有父類，則委托給啟動加載器去加載
                      c = findBootstrapClassOrNull(name);
                  }
              } catch (ClassNotFoundException e) {
                  // ClassNotFoundException thrown if class not found
                  // from the non-null parent class loader
              }
              if (c == null) {
                  // 如果都沒有找到，則通過自定義實現的findClass去查找并加載
                  c = findClass(name);
                  // this is the defining class loader; record the stats
                  sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                  sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                  sun.misc.PerfCounter.getFindClasses().increment();
              }
          }
          if (resolve) {//是否需要在加載時進行解析
              resolveClass(c);
          }
          return c;
      }
  }

緩存 -> 父類加載器 -> 沒有父類 -> 啟動類加載器 -> 自己的 findClass() 方法查找和加載

三.Android類加載機制

在Java標準的虛擬機中，類加載可以從class文件中讀取，也可以是其他形式的二進制流。而Dalvik虛擬機如同Java虛擬機一樣，在運行程序時首先需要將對應的類加載到內存中。只不過Android平臺上虛擬機運行的是Dex字節碼,一種對class文件優化的產物,傳統Class文件是一個Java源碼文件會生成一個.class文件，而Android是把所有Class文件進行合并，優化，然后生成一個最終的class.dex,目的是把不同class文件重復的東西只需保留一份,如果我們的Android應用不進行分dex處理,最后一個應用的apk只會有一個dex文件。
Android平臺的類加載器
Android中類加載器有BootClassLoader,URLClassLoader,PathClassLoader,DexClassLoader,BaseDexClassLoader,等都最終繼承自java.lang.ClassLoader。如圖：

image.png

image.png

ClassLoader加載class的過程

// BaseDexClassLoader
//創建
public BaseDexClassLoader(String dexPath, File optimizedDirectory,
            String libraryPath, ClassLoader parent) {
        super(parent);
        this.originalPath = dexPath;
        this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
    }
//加載
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException { 
    Class clazz = pathList.findClass(name);
    if (clazz == null) { 
        throw new ClassNotFoundException(name); 
    } 
    return clazz;
}

// PathClassLoader.java,optimizedDirectory永遠為null
//創建
public class PathClassLoader extends BaseDexClassLoader {
    public PathClassLoader(String dexPath, ClassLoader parent) {
        super(dexPath, null, null, parent);
    }

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

// DexClassLoader.java
//創建
public class DexClassLoader extends BaseDexClassLoader {
    public DexClassLoader(String dexPath, String optimizedDirectory,
            String libraryPath, ClassLoader parent) {
        super(dexPath, new File(optimizedDirectory), libraryPath, parent);
    }
}

//DexPathList的findClass
public Class findClass(String name) { 
    for (Element element : dexElements) { 
        DexFile dex = element.dexFile;
        if (dex != null) { 
            Class clazz = dex.loadClassBinaryName(name, definingContext); 
          if (clazz != null) { 
              return clazz; 
          } 
        } 
    } 
    return null;
}

//DexFile的loadClassBinaryName
public Class loadClassBinaryName(String name, ClassLoader loader) { 
    return defineClass(name, loader, mCookie);
}
private native static Class defineClass(String name, ClassLoader loader, int cookie);

從上圖可以看到：
在創建類加載器過程
optimizedDirectory是用來緩存我們需要加載的dex文件的，并創建一個DexFile對象，optimizedDirectory必須是一個內部存儲路徑，DexClassLoader可以指定自己的optimizedDirectory，所以它可以加載外部的dex，因為這個dex會被復制到內部路徑的optimizedDirectory；而PathClassLoader沒有optimizedDirectory，所以它只能加載內部的dex，這些大都是存在系統中已經安裝過的apk里面的。
加載類的過程
BaseDexClassLoader中有個DexPathList實例pathList，pathList中包含一個DexFile的數組dexElements，dexElements數組就是這些dex文件的集合，dex文件就是內部存儲路徑optimizedDirectory緩存起來的。如果不分包一般這個數組只有一個Element元素，也就只有一個DexFile文件，而對于類加載呢，就是遍歷這個集合，通過DexFile去尋找。簡單來說就是：
1.在DexClassLoader的findClass 方法中通過一個DexPathList對象findClass()方法來獲取class
2.在DexPathList的findClass 方法中，對之前構造好dexElements數組集合進行遍歷，一旦找到類名與name相同的類時，就直接返回這個class，找不到則返回null。
動態加載技術
基于ClassLoader的動態加載技術的一個特點就是，如果程序不重新啟動，加載過一次的類就無法重新加載。因此，如果使用ClassLoader來動態升級APP或者動態修復BUG，都需要重新啟動APP才能生效。很容易可以想到熱修復實現的一種方式，假設現在代碼中的某一個類或者是某幾個類有bug，那么我們可以在修復完bug之后，將這些個類打包成一個補丁文件，然后通過這個補丁文件封裝出一個Element對象，并且將這個Element對象插到原有dexElements數組的最前端，這樣當DexClassLoader去加載類時，優先會從我們插入的這個Element中找到相應的類，雖然那個有bug的類還存在于數組中后面的Element中，但由于雙親加載機制的特點，這個有bug的類已經沒有機會被加載了，這樣一個bug就在沒有重新安裝應用的情況下修復了。微信的Tinker框架通過修復好的class.dex 和原有的class.dex比較差生差量包補丁文件patch.dex，在手機上這個patch.dex又會和原有的class.dex 合并生成新的文件fix_class.dex，用這個新的fix_class.dex 整體替換原有的dexPathList的中的內容。

除了微信的Tinker，其他的動態加載技術還可以使用jni hook的方式修改程序的執行代碼。前者是在虛擬機上操作的，而后者做的已經是Native層級的工作了，直接修改應用運行時的內存地址，所以使用jni hook的方式時，不用重新應用就能生效，比如阿里的dexposed和AndFix。

四.總結

以上就是關于類加載機制的知識點，如有不足或者錯誤的地方請指正。在技術這塊，我們需要多看更需要多寫，我們只有不斷學習，不斷進步才能不被淘汰。