為什麼要理解Android中的ClassLoader？

目前來講，Android中的外掛技術以及熱修復技術都跟ClassLoader息息相關，瞭解此技術有助於加深對Android系統的 瞭解。尤其是對於外掛技術來講，對Class的載入基本固定都是一個套路。（熱修復要更復雜一些，涉及到C++層面的方法數等知識）

閱讀本篇文件需要有哪些儲備知識？

最好先閱讀JVM中的ClassLoader，有了這篇基礎然後再看這邊理解會更加深刻。此外還可以谷歌關鍵字搜尋一下相關知識，有個基礎概念再看本篇文章更佳。本文不會過多重複其他BlOG中提到的概念。

相比其他講Android ClassLoader的文章，這篇有什麼優點？

相比其他多數東拼西湊的文章，這篇文章能從頭到腳幫你梳理一下Android中ClassLoader的知識點，以及程式碼層面幫你實戰 加深理解。

JVM和android的虛擬機器在ClassLoader上有何不同？

還記得在我之前的JVM那篇文章的結尾，我自定義了一個ClassLoader，通過讀取了一個本地class檔案，然後傳遞了 一個byte陣列 到defineClass這個方法裡從而成功的載入了一個本地class，但是在android中，這種方法是不被允許的。 我們來看看原始碼：

android的classLoader可以看出來是有defineClass這個方法的，但是這些方法都統一返回了異常，也就是說 android官方不允許我們用JVM那套方法來載入class，為了更清晰，我複製一段原始碼出來。

 protected final Class<?> defineClass(String name, byte[] b, int off, int len,
                                         ProtectionDomain protectionDomain)
        throws ClassFormatError
    {
        throw new UnsupportedOperationException("can't load this type of class file");
    }
複製程式碼

很直觀，能看出來這裡是什麼意思，再接著往下看

 protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
            // First, check if the class has already been loaded
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                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) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    c = findClass(name);
                }
            }
            return c;
    }
複製程式碼

這裡看一下，一樣很直觀，可以看出來這裡的loadClass和JVM中的loadClass的流程一模一樣。也是符合雙親委託機制。

既然Android中不能用defineClass的方法讀取一個class檔案的byte，那麼android如何載入class檔案的？

有一定基礎的人應該知道，android中的類載入器有兩種，DexClassLoader和PathClassLoader。我們下面就來看看這2個 ClassLoader是如何載入class檔案的吧。

package dalvik.system;

import dalvik.system.BaseDexClassLoader;
import java.io.File;

public class DexClassLoader extends BaseDexClassLoader {
    public DexClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {
        super((String)null, (File)null, (String)null, (ClassLoader)null);
        throw new RuntimeException("Stub!");
    }
}
複製程式碼

public class PathClassLoader extends BaseDexClassLoader {
    public PathClassLoader(String dexPath, ClassLoader parent) {
        super((String)null, (File)null, (String)null, (ClassLoader)null);
        throw new RuntimeException("Stub!");
    }

    public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
        super((String)null, (File)null, (String)null, (ClassLoader)null);
        throw new RuntimeException("Stub!");
    }
}

複製程式碼

嗯 能看出來 這2個都是派生自BaseDexClassLoader類，

public class BaseDexClassLoader extends ClassLoader {
    public BaseDexClassLoader(String dexPath, File optimizedDirectory, String librarySearchPath, ClassLoader parent) {
        throw new RuntimeException("Stub!");
    }

    protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new RuntimeException("Stub!");
    }

    protected URL findResource(String name) {
        throw new RuntimeException("Stub!");
    }

    protected Enumeration<URL> findResources(String name) {
        throw new RuntimeException("Stub!");
    }

    public String findLibrary(String name) {
        throw new RuntimeException("Stub!");
    }

    protected synchronized Package getPackage(String name) {
        throw new RuntimeException("Stub!");
    }

    public String toString() {
        throw new RuntimeException("Stub!");
    }
}
複製程式碼

看到這可能很多人就懵逼了，這是啥意思，實際上這裡代表的就是這個類執行的時候，會讓ROM裡的類來實際執行，這裡android studio定位到的原始碼 只是告訴我們，嗯 這裡有一個這樣的類。但是實際的實現是放在Rom中做的。 很多人到這裡可能還是無法理解是什麼意思，其實這個地方在很多開源專案中都有實際用法，比如你要反射呼叫api裡沒有暴露出來給你的類怎麼辦呢？這個類在rom裡是有的 但是api並沒有暴露出來給你。就可以用這種寫法了。我舉個滴滴開源框架VirtualApk的例子：

看到沒有滴滴也是這麼做的，將這些類放在自己的框架內暴露出來（注意包名要和ROM中的一樣）這樣就可以在其他地方反射呼叫了。 我們隨便找個原始碼進去看一看：

package android.app;

import android.content.Intent;
import android.content.pm.ActivityInfo;
import android.os.Handler;
import android.os.IBinder;
import android.os.Looper;

/**
 * @author johnsonlee
 */
public final class ActivityThread {

    public static ActivityThread currentActivityThread() {
        throw new RuntimeException("Stub!");
    }

    public static boolean isSystem() {
        throw new RuntimeException("Stub!");
    }

    public static String currentOpPackageName() {
        throw new RuntimeException("Stub!");
    }

    public static String currentPackageName() {
        throw new RuntimeException("Stub!");
    }

    public static String currentProcessName() {
        throw new RuntimeException("Stub!");
    }

    public static Application currentApplication() {
        throw new RuntimeException("Stub!");
    }

    public ApplicationThread getApplicationThread() {
        throw new RuntimeException("Stub!");
    }

    public Instrumentation getInstrumentation() {
        throw new RuntimeException("Stub!");
    }

    public Looper getLooper() {
        throw new RuntimeException("Stub!");
    }

    public Application getApplication() {
        throw new RuntimeException("Stub!");
    }

    public String getProcessName() {
        throw new RuntimeException("Stub!");
    }

    public final ActivityInfo resolveActivityInfo(final Intent intent) {
        throw new RuntimeException("Stub!");
    }

    public final Activity getActivity(final IBinder token) {
        throw new RuntimeException("Stub!");
    }

    final Handler getHandler() {
        throw new RuntimeException("Stub!");
    }

    private class ApplicationThread extends ApplicationThreadNative {


    }
}

複製程式碼

你看ActivityThread這個類，有過原始碼基礎的同學應該都知道這個類是rom裡我們api裡沒有這個類的。用這種方法暴露出來以後就可以使用它了。

扯遠了，回到正題，既然api 原始碼裡看不到真正的實現 我們只好去rom程式碼裡看看了 這裡推薦一個線上檢視原始碼的網站

點我直接線上查android原始碼

這裡明顯看出來我們的DexClassLoader和pathClassLoader建構函式傳參上面就有不同，DexClassLoader需要提供一個額外的path路徑，這個path路徑我們看下注釋很容易理解：用來存放解壓縮以後的dex檔案。（apk和jar包解壓縮都可以 只要解壓縮以後的是dex檔案），這個path就是解壓縮的目標路徑。但是PathClassLoader就沒有這個建構函式。只能直接操作dex檔案。 總結： DexClassLoader可以載入任何路徑的apk/dex/jar PathClassLoader只能載入/data/app中的apk，也就是已經安裝到手機中的apk。這個也是PathClassLoader作為預設的類載入器的原因，因為一般程式都是安裝了，在開啟，這時候PathClassLoader就去載入指定的apk(解壓成dex，然後在優化成odex)就可以了

繼續跟原始碼 跟到BaseClassLoader

可以看出來BaseClassLoader的建構函式 最終是呼叫的DexPathList函式，注意這裡2個建構函式也是分別對應的dex和path 兩種classLoader的

跟到DexPathList

嗯 發現這裡都是走的makeDex函式

發現了DexFile這個類，繼續跟：

嗯，一直到這裡，我們發現最終的loadclass 在DexFile的 loadClassBinaryname方法完成了（這裡可以和JVM中我們自定義 的那個ClassLoader比對一下）。

有人要問既然DexFile完成的是最終classLoader需要完成的loadClass的操作，為啥不直接用dexFile呢？ 看註釋：

If you are not calling this from a class loader, this is most likely not going to do what you want. Use {@link Class#forName(String)} instead

這裡明確說了，如果你的DexFile的loadClass操作不是在classLoader裡做的，那你很大可能得不到你想要的結果。。。。

所以以後要記住了，DexFile相關的操作一定要在ClassLoader裡完成

程式碼層面驗證一下Android中的類載入器

寫個簡單的demo

package com.example.a16040657.androidclassloader;

import android.content.Context;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.util.Log;
import android.widget.ListView;


public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Log.v("wuyue", "MainActivity的類載入載入器:" + MainActivity.class.getClassLoader());
        Log.v("wuyue", "Context的類載入載入器:" + Context.class.getClassLoader());
        Log.v("wuyue", "ListView的類載入器:" + ListView.class.getClassLoader());
        Log.v("wuyue", "應用程式預設載入器:" + getClassLoader());
        Log.v("wuyue", "系統類載入器:" + ClassLoader.getSystemClassLoader());
        Log.v("wuyue", "系統類載入器和Context的類載入器是否相等:" + (Context.class.getClassLoader() == ClassLoader.getSystemClassLoader()));
        Log.v("wuyue", "系統類載入器和應用程式預設載入器是否相等:" + (getClassLoader() == ClassLoader.getSystemClassLoader()));
        Log.v("wuyue", "列印應用程式預設載入器的委派機制:");
        ClassLoader classLoader = getClassLoader();
        while (classLoader != null) {
            Log.v("wuyue", "類載入器:" + classLoader);
            classLoader = classLoader.getParent();
        }

        Log.v("wuyue", "列印系統載入器的委派機制:");
        classLoader = ClassLoader.getSystemClassLoader();
        while (classLoader != null) {
            Log.v("wuyue", "類載入器:" + classLoader);
            classLoader = classLoader.getParent();
        }
    }
}

複製程式碼

再看看輸出的結果

注意看一下我們的listview和Context的類載入器都是bootClassLoader，很好理解，和JVM中對照一下，其實一些系統類 都是交給bootClssLoader來載入的，只不過jVM中的是叫BootstrapClassLoader罷了。都是一個意思。

注意看一下系統類載入器和應用程式載入器雖然都是pathclassloader，但是這裡注意看一下 這倆的路徑是不同的。 一個是data/app 一個是sytesm/app 所以這倆是不同的類載入器。這裡要注意一下。