Android 類加載機制及熱修復原理
Android熱修復
1、簡述
bug通常是一個或多個class出現了問題，在一個理想的狀態下，咱們只需將修復好的這些個class更新到用戶手機上的app中就能夠修復這些bug了。要怎麼才能動態更新這些class呢？其實，不論是哪一種熱修復方案，確定是以下幾個步驟：java
- 下發補丁（內含修復好的class）到用戶手機，即讓app從服務器上下載（網絡傳輸）
- app經過某種方式，使補丁（apk、dex、jar等文件）中的class被app調用（本地更新）
這裏的某種方式，對本篇而言，就是使用Android的類加載器，經過類加載器加載這些修復好的class，覆蓋對應有問題的class，理論上就能修復bug了。android
2、類加載機制
一、雙親委派模型
在加載一個字節碼文件時，會詢問當前的classLoader是否已經加載過此字節碼文件。若是加載過，則直接返回，再也不重複加載。若是沒有加載過，則會詢問它的Parent是否已經加載過此字節碼文件，一樣的，若是已經加載過，就直接返回parent加載過的字節碼文件，而若是整個繼承線路上的classLoader都沒有加載過，才由child類加載器（即，當前的子classLoader）執行類的加載工做。數組
1）特色：
若是一個類被classLoader繼承線路上的任意一個加載過，那麼在之後整個系統的生命週期中，這個類都不會再被加載，大大提升了類的加載效率。緩存
2）做用：
- 類加載的共享功能
一些Framework層級的類一旦被頂層classLoader加載過，會緩存到內存中，之後在任何地方用到，都不會去從新加載。安全
- 類加載的隔離功能
共同繼承線程上的classLoader加載的類，確定不是同一個類，這樣能夠避免某些開發者本身去寫一些代碼冒充核心類庫，來訪問核心類庫中可見的成員變量。如java.lang.String在應用程序啓動前就已經被系統加載好了，若是在一個應用中可以簡單的用自定義的String類把系統中的String類替換掉的話，會有嚴重的安全問題。bash
驗證多個類是同一個類的成立條件：服務器
- 相同的className
- 相同的packageName
- 被相同的classLoader加載
3）loadClass()
經過loadClass()這個方法來驗證雙親委派模型網絡
找到ClassLoader這個類中的loadClass()方法，它調用的是另外一個2個參數的重載loadClass()方法。app
public Class<?> loadClass(String name) throws ClassNotFoundException {
return loadClass(name, false);
}
複製代碼
找到最終這個真正的loadClass()方法，下面即是該方法的源碼：jvm
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;
}
複製代碼
能夠看到，如前面所說，加載一個類時，會有以下3步：
- 檢查當前的classLoader是否已經加載琮這個class，有則直接返回，沒有則進行第2步。
- 調用父classLoader的loadClass()方法，檢查父classLoader是否有加載過這個class，有則直接返回，沒有就繼續檢查上上個父classLoader，直到頂層classLoader。
- 若是全部的父classLoader都沒有加載過這個class，則最終由當前classLoader調用findClass()方法，去dex文件中找出並加載這個class。
2、Android中的ClassLoader
一、類加載器類型
Android跟java有很大的淵源，基於jvm的java應用是經過ClassLoader來加載應用中的class的，Android對jvm優化過，使用的是dalvik虛擬機，且class文件會被打包進一個dex文件中，底層虛擬機有所不一樣，那麼它們的類加載器固然也是會有所區別。
Android中最主要的類加載器有以下4個：
- BootClassLoader：加載Android Framework層中的class字節碼文件（相似java的Bootstrap ClassLoader）
- PathClassLoader：加載已經安裝到系統中的Apk的class字節碼文件（相似java的App ClassLoader）
- DexClassLoader：加載制定目錄的class字節碼文件（相似java中的Custom ClassLoader）
- BaseDexClassLoader：PathClassLoader和DexClassLoader的父類
一個app必定會用到BootClassLoader、PathClassLoader這2個類加載器，可經過以下代碼進行驗證：
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ClassLoader classLoader = getClassLoader();
if (classLoader != null) {
Log.e(TAG, "classLoader = " + classLoader);
while (classLoader.getParent() != null) {
classLoader = classLoader.getParent();
Log.e(TAG, "classLoader = " + classLoader);
}
}
}
複製代碼
上面代碼中能夠經過上下文拿到當前類的類加載器（PathClassLoader）,而後經過getParent()獲得父類加載器（BootClassLoader），這是因爲Android中的類加載器和java類加載器同樣使用的是雙親委派模型。
二、PathClassLoader與DexClassLoader的區別
通常的源碼在Android Studio中能夠查到，但 PathClassLoader 和 DexClassLoader 的源碼是屬於系統級源碼，因此沒法在Android Studio中直接查看。能夠到androidxref.com這個網站上直接查看，下面會列出以後要分析的幾個類的源碼地址。
如下是Android 5.0中的部分源碼：
1）使用場景
先來介紹一下這兩種Classloader在使用場景上的區別
- PathClassLoader：只能加載已經安裝到Android系統中的apk文件（/data/app目錄），是Android默認使用的類加載器。
- DexClassLoader：能夠加載任意目錄下的dex/jar/apk/zip文件，比PathClassLoader更靈活，是實現熱修復的重點。
2）代碼差別
下面來看一下PathClassLoader與DexClassLoader的源碼的差異，都很是簡單
// PathClassLoader
public class PathClassLoader extends BaseDexClassLoader {
public PathClassLoader(String dexPath, ClassLoader parent) {
super(dexPath, null, null, parent);
}
public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
super(dexPath, null, librarySearchPath, parent);
}
}
複製代碼
// DexClassLoader
public class DexClassLoader extends BaseDexClassLoader {
public DexClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {
super(dexPath, new File(optimizedDirectory), librarySearchPath, parent);
}
}
複製代碼
經過比對，能夠得出2個結論：
- PathClassLoader與DexClassLoader都繼承於BaseDexClassLoader。
- PathClassLoader與DexClassLoader在構造函數中都調用了父類的構造函數，但DexClassLoader多傳了一個optimizedDirectory。
三、BaseDexClassLoader
經過觀察PathClassLoader與DexClassLoader的源碼咱們就能夠肯定，真正有意義的處理邏輯確定在BaseDexClassLoader中，因此下面着重分析BaseDexClassLoader源碼。
1）構造函數
先來看看BaseDexClassLoader的構造函數都作了什麼：
public class BaseDexClassLoader extends ClassLoader {
private final DexPathList pathList;
...
public BaseDexClassLoader(String dexPath, File optimizedDirectory, String libraryPath, ClassLoader parent){
super(parent);
this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
}
...
}
複製代碼
- dexPath：要加載的程序文件（通常是dex文件，也能夠是jar/apk/zip文件）所在目錄。
- optimizedDirectory：dex文件的輸出目錄（由於在加載jar/apk/zip等壓縮格式的程序文件時會解壓出其中的dex文件，該目錄就是專門用於存放這些被解壓出來的dex文件的）。
- libraryPath：加載程序文件時須要用到的庫路徑。
- parent：父加載器
tip:從一個完整App的角度來講，程序文件指定的就是apk包中的classes.dex文件；但從熱修復的角度來看，程序文件指的是補丁。
由於PathClassLoader只會加載已安裝包中的dex文件，而DexClassLoader不只僅能夠加載dex文件，還能夠加載jar、apk、zip文件中的dex。jar、apk、zip其實就是一些壓縮格式，要拿到壓縮包裏面的dex文件就須要解壓，因此，DexClassLoader在調用父類構造函數時會指定一個解壓的目錄。
2）findClass()
類加載器確定會提供有一個方法來供外界找到它所加載到的class，該方法就是findClass()，不過在PathClassLoader和DexClassLoader源碼中都沒有重寫父類的findClass()方法，但它們的父類BaseDexClassLoader就有重寫findClass()，因此來看看BaseDexClassLoader的findClass()方法都作了哪些操做，代碼以下：
private final DexPathList pathList;
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
// 實質是經過pathList的對象findClass()方法來獲取class
Class c = pathList.findClass(name, suppressedExceptions);
if (c == null) {
ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);
for (Throwable t : suppressedExceptions) {
cnfe.addSuppressed(t);
}
throw cnfe;
}
return c;
}
複製代碼
能夠看到，BaseDexClassLoader的findClass()方法其實是經過DexPathList對象（pathList）的findClass()方法來獲取class的，而這個DexPathList對象剛好在以前的BaseDexClassLoader構造函數中就已經被建立好了。因此，下面就來看看DexPathList類中都作了什麼。
四、DexPathList
1）構造函數
private final Element[] dexElements;
public DexPathList(ClassLoader definingContext, String dexPath, String libraryPath, File optimizedDirectory) {
...
this.definingContext = definingContext;
this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,suppressedExceptions);
...
}
複製代碼
這個構造函數中，保存了當前的類加載器definingContext，並調用了makeDexElements()獲得Element集合。
經過對splitDexPath(dexPath)的源碼追溯，發現該方法的做用其實就是將dexPath目錄下的全部程序文件轉變成一個File集合。並且還發現，dexPath是一個用冒號（":"）做爲分隔符把多個程序文件目錄拼接起來的字符串(如：/data/dexdir1:/data/dexdir2:...)。
那接下來無疑是分析makeDexElements()方法了，由於這部分代碼比較長，我就貼出關鍵代碼，並以註釋的方式進行分析：
private static Element[] makeDexElements(ArrayList<File> files, File optimizedDirectory, ArrayList<IOException> suppressedExceptions) {
// 1.建立Element集合
ArrayList<Element> elements = new ArrayList<Element>();
// 2.遍歷全部dex文件（也多是jar、apk或zip文件）
for (File file : files) {
ZipFile zip = null;
DexFile dex = null;
String name = file.getName();
...
// 若是是dex文件
if (name.endsWith(DEX_SUFFIX)) {
dex = loadDexFile(file, optimizedDirectory);
// 若是是apk、jar、zip文件（這部分在不一樣的Android版本中，處理方式有細微差異）
} else {
zip = file;
dex = loadDexFile(file, optimizedDirectory);
}
...
// 3.將dex文件或壓縮文件包裝成Element對象，並添加到Element集合中
if ((zip != null) || (dex != null)) {
elements.add(new Element(file, false, zip, dex));
}
}
// 4.將Element集合轉成Element數組返回
return elements.toArray(new Element[elements.size()]);
}
複製代碼
在這個方法中，看到了一些眉目，整體來講，DexPathList的構造函數是將一個個的程序文件（多是dex、apk、jar、zip）封裝成一個個Element對象，最後添加到Element集合中。
其實，Android的類加載器（不論是PathClassLoader，仍是DexClassLoader），它們最後只認dex文件，而loadDexFile()是加載dex文件的核心方法，能夠從jar、apk、zip中提取出dex，但這裏先不分析了，由於第1個目標已經完成，等到後面再來分析吧。
2）findClass()
再來看DexPathList的findClass()方法：
public Class findClass(String name, List<Throwable> suppressed) {
for (Element element : dexElements) {
// 遍歷出一個dex文件
DexFile dex = element.dexFile;
if (dex != null) {
// 在dex文件中查找類名與name相同的類
Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
if (clazz != null) {
return clazz;
}
}
}
if (dexElementsSuppressedExceptions != null) {
suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
}
return null;
}
複製代碼
結合DexPathList的構造函數，其實DexPathList的findClass()方法很簡單，就只是對Element數組進行遍歷，一旦找到類名與name相同的類時，就直接返回這個class，找不到則返回null。
爲何是調用DexFile的loadClassBinaryName()方法來加載class？這是由於一個Element對象對應一個dex文件，而一個dex文件則包含多個class。也就是說Element數組中存放的是一個個的dex文件，而不是class文件。這能夠從Element這個類的源碼和dex文件的內部結構看出。
3、熱修復的實現原理
通過對PathClassLoader、DexClassLoader、BaseDexClassLoader、DexPathList的分析，咱們知道，安卓的類加載器在加載一個類時會先從自身DexPathList對象中的Element數組中獲取（Element[] dexElements）到對應的類，以後再加載。採用的是數組遍歷的方式，不過注意，遍歷出來的是一個個的dex文件。在for循環中，首先遍歷出來的是dex文件，而後再是從dex文件中獲取class，因此，咱們只要讓修復好的class打包成一個dex文件，放於Element數組的第一個元素，這樣就能保證獲取到的class是最新修復好的class了（固然，有bug的class也是存在的，不過是放在了Element數組的最後一個元素中，因此沒有機會被拿到而已。
- 1. Android熱修復技術(三)-----代碼修復之冷啓動類加載原理
- 2. 一篇文章搞懂熱修復類加載方案原理
- 3. Android熱修復原理普及
- 4. Android熱修復原理及實現
- 5. Android熱修復原理
- 6. Android Tinker 熱修復原理
- 7. 熱修復之冷啓動類加載原理與實現
- 8. Android熱修復之dex修復原理
- 9. 熱修復原理
- 10. Android性能優化(6)：淺析類加載機制與熱修復技術
- 更多相關文章...
- • ionic 加載動畫 - ionic 教程
- • Eclipse 快速修復 - Eclipse 教程
- • 漫談MySQL的鎖機制
- • ☆技術問答集錦（13）Java Instrument原理
-
每一个你不满意的现在，都有一个你没有努力的曾经。