前文： 【Java】ClassLoader與雙親委派機制
創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站設(shè)計、做網(wǎng)站、西湖網(wǎng)絡(luò)推廣、小程序設(shè)計、西湖網(wǎng)絡(luò)營銷、西湖企業(yè)策劃、西湖品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供西湖建站搭建服務(wù)，24小時服務(wù)熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com
Android中的類加載器有三種， DexClassLoader 、 PathClassLoader 、 BootClassLoader 。
其中 BootClassLoader 是系統(tǒng)啟動時預(yù)加載常用類的，一般使用不到。 DexClassLoader 、 PathClassLoader 都是繼承自 BaseDexClassLoader 。
但 DexClassLoader 和 PathClassLoader 并沒有重寫 BaseDexClassLoader 中的任何方法，所以源碼只需要看 BaseDexClassLoader 即可。
由于Android SDK并沒有包含 BaseDexClassLoader ，所以需要到源碼查詢網(wǎng)站查詢源碼，如下：
復(fù)制這個java文件到對應(yīng)源碼文件夾下就可以在Android Studio中查看了。
通過調(diào)試可以看到，Android中普通類的加載器其實是 PathClassLoader 。追蹤 PathClassLoader.findClass 方法，即可獲取Android的類加載過程：
PathClassLoader.findClass -- 繼承自 -- BaseDexClassLoader.findClass()
- BaseDexClassLoader.pathList.findClass()
- DexPathList.dexElements.foreach { element.findClass() }
- Element.findClass()
- Element.dexFile.loadClassBinaryName()
- DexFile.defineClass()
即類加載過程通過 BaseDexClassLoader.findClass 、 DexPathList.findClass 、 Element.findClass 、 DexFile.loadClassBinaryName ，最終會落到 DexFile.defineClass 方法中，然后就交給native層了。
其中需要注意的是，在 BaseDexClassLoader.findClass 的開頭有這么一段：
這段是在Android 10新加入的，據(jù)稱是為了實現(xiàn) shared library 功能的，在之前的版本中沒有這一段。
在上一節(jié)中知道了，類加載的流程如下：
BaseDexClassLoader.findClass() -
BaseDexClassLoader.pathList.findClass() -
DexPathList.dexElements.foreach { element.findClass() } -
Element.findClass() - ...
看 DexPathList.findClass 方法：
可以發(fā)現(xiàn)， DexPathList 加載類的方法是遍歷 dexElements 數(shù)組依次加載，知道獲取到值為止。所以可以通過修改這個數(shù)組，把新的dex文件放在數(shù)組的前面，使其加載修改后的類，從而實現(xiàn)熱修復(fù)。
根據(jù)以上原理，寫下這個工具類，有效性待驗證：
1、Applications
Android裝配一個核心應(yīng)用程序集合，包括電子郵件客戶端、SMS程序、日歷、地圖、瀏覽器、聯(lián)系人和其他設(shè)置。所有應(yīng)用程序都是用Java編 程語言寫的。更加豐富的應(yīng)用程序有待我們?nèi)ラ_發(fā)! 從上面我們知道Android的架構(gòu)是分層的，非常清晰，分工很明確。Android本身是一套軟件堆迭(Software Stack)，或稱為「軟件迭層架構(gòu)」，迭層主要分成三層：操作系統(tǒng)、中間件、應(yīng)用程序。從上面我們也看到了開源的力量，一個個熟悉的開源軟件在這里貢獻(xiàn) 了自己的一份力量。
2、Linux Kernel
Android基于Linux 2.6提供核心系統(tǒng)服務(wù)，例如：安全、內(nèi)存管理、進(jìn)程管理、網(wǎng)絡(luò)堆棧、驅(qū)動模型。Linux Kernel也作為硬件和軟件之間的抽象層，它隱藏具體硬件細(xì)節(jié)而為上層提供統(tǒng)一的服務(wù)。 如果你學(xué)過計算機網(wǎng)絡(luò)知道OSI/RM，就會知道分層的好處就是使用下層提供的服務(wù)而為上層提供統(tǒng)一的服務(wù)，屏蔽本層及以下層的差異，當(dāng)本層及以下層發(fā)生 了變化不會影響到上層。也就是說各層各盡其職，各層提供固定的SAP(Service Access Point)，專業(yè)點可以說是高內(nèi)聚、低耦合。 如果你只是做Android應(yīng)用開發(fā)，就不需要深入了解Linux Kernel層。
3、Application Framework
通過提供開放的開發(fā)平臺，Android使開發(fā)者能夠編制極其豐富和新穎的應(yīng)用程序。開發(fā)者可以自由地利用設(shè)備硬件優(yōu)勢、訪問位置信息、運行后臺服 務(wù)、設(shè)置鬧鐘、向狀態(tài)欄添加通知等等，很多很多。 開發(fā)者可以完全使用核心應(yīng)用程序所使用的框架APIs。應(yīng)用程序的體系結(jié)構(gòu)旨在簡化組件的重用，任何應(yīng)用程序都能發(fā)布他的功能且任何其他應(yīng)用程序可以使用 這些功能(需要服從框架執(zhí)行的安全限制)。這一機制允許用戶替換組件。 所有的應(yīng)用程序其實是一組服務(wù)和系統(tǒng)，包括： 視圖(View)--豐富的、可擴(kuò)展的視圖集合，可用于構(gòu)建一個應(yīng)用程序。包括包括列表、網(wǎng)格、文本框、按鈕，甚至是內(nèi)嵌的網(wǎng)頁瀏覽器 內(nèi)容提供者(Content Providers)--使應(yīng)用程序能訪問其他應(yīng)用程序(如通訊錄)的數(shù)據(jù)，或共享自己的數(shù)據(jù) 資源管理器(Resource Manager)--提供訪問非代碼資源，如本地化字符串、圖形和布局文件 通知管理器(Notification Manager)--使所有的應(yīng)用程序能夠在狀態(tài)欄顯示自定義警告 活動管理器(Activity Manager)--管理應(yīng)用程序生命周期,提供通用的導(dǎo)航回退功能。
4、Libraries
Android包含一個C/C++庫的集合，供Android系統(tǒng)的各個組件使用。這些功能通過Android的應(yīng)用程序框架 (application framework)暴露給開發(fā)者。下面列出一些核心庫： 系統(tǒng)C庫--標(biāo)準(zhǔn)C系統(tǒng)庫(libc)的BSD衍生，調(diào)整為基于嵌入式Linux設(shè)備 媒體庫--基于PacketVideo的OpenCORE。這些庫支持播放和錄制許多流行的音頻和視頻格式，以及靜態(tài)圖像文件，包括MPEG4、 H.264、 MP3、 AAC、 AMR、JPG、 PNG 界面管理--管理訪問顯示子系統(tǒng)和無縫組合多個應(yīng)用程序的二維和三維圖形層 LibWebCore--新式的Web瀏覽器引擎,驅(qū)動Android 瀏覽器和內(nèi)嵌的web視圖 SGL--基本的2D圖形引擎 3D庫--基于OpenGL ES 1.0 APIs的實現(xiàn)。庫使用硬件3D加速或包含高度優(yōu)化的3D軟件光柵 FreeType --位圖和矢量字體渲染 SQLite --所有應(yīng)用程序都可以使用的強大而輕量級的關(guān)系數(shù)據(jù)庫引擎。
雙親委托機制
類在進(jìn)行類加載的時候，把加載任務(wù)托管給父類加載器，如能加載成功，則返回，否則依次向子類加載器遞歸嘗試類加載。
意義：
①避免類的重復(fù)加載，父類加載已加載該類時,子ClassLoader就沒有必要加載一次了。
②安全性，防止核心API被隨意篡改。
ClassLoader
ClassLoader本身是一個抽象方法。它的主要實現(xiàn)類有BootClassLoader、PathClassLoader、DexClassLoader.
BootClassLoader：用于加載Android Framwork層（SDK）的class文件
PathClassLoader：用于Android應(yīng)用程序加載器,可以加載指定的dex和jar、zip、apk中的classes.dex（系統(tǒng)使用）
DexClassLoader：用于加載指定的dex和jar、zip、apk中的classes.dex。(供開發(fā)者使用)
拓展：
在API26之前。
optimizedDirectory 參數(shù)就是dexopt的產(chǎn)出目錄(odex)。那 PathClassLoader 創(chuàng)建時，這個目錄為null，就
意味著不進(jìn)行dexopt？并不是， optimizedDirectory 為null時的默認(rèn)路徑為：/data/dalvik-cache。
在API26之后DexClassLoader也取消了optimizedDirectory
熱修復(fù)相關(guān)
LoadClass：
findClass：PathClassLoader和DexClassLoader的父類BaseDexClassLoader中實現(xiàn)findClass。
BaseDexClassLoader中
PathClassLoader加載過后，pathlist 中存在一個Element數(shù)組，Element類中存在一個dexFile成員表示dex文件，即：APK中有X個dex，則Element數(shù)組就有X個元素。
總結(jié):
可能看到這里我們比較亂了，理一下。一個類的加載經(jīng)歷了哪些。我們以PathClassLoader為例。
①加載一個類的時候，首先通過Class緩存尋找是否已經(jīng)加載過該類。參考抽象類的loadClass方法。
②若在緩存中未找到該類，則交由父加載器加載該類。參考抽象類的loadClass方法。
③調(diào)用父加載器PathClassLoader的父類BaseDexClassLoader實現(xiàn)的findClass方法加載該類。
④PathClassLoader在初始化的時候調(diào)用父構(gòu)造方法實例化DexPathList屬性，DexPathList屬性初始化時構(gòu)造方法內(nèi)通過makePathElements（或makeDexElements?不同API可能不同）加載APK內(nèi)的dex文件生成Element數(shù)組。
⑤BaseDexClassLoader實現(xiàn)的findClass方法中順序循環(huán)已存在的Element數(shù)組，通過Element中的DexFile加載類。。
⑥未找到，拋出類未找到異常。
熱修復(fù)（multide?形式（thinker、qfix））
熱修復(fù)的原理。我們只需在應(yīng)用啟動的時候，一般是在application方法中（因為class加載首先從緩存中加載），在應(yīng)用啟動后，經(jīng)過PathClassLoader加載過后所有的類都在 pathList的Element 數(shù)組，把生成的Elment數(shù)組插入到PathList的Element數(shù)組的最前方。在加載類的時候就只會加載到我們需要更新的類了，因為是順序?qū)ふ?，找到就返回?先從我們補丁的dex文件生成的element尋找，找不到再從APK的dex生成的element種尋找)。
熱修復(fù)基本思路總結(jié):
①獲取到當(dāng)前引用的PathClassLoader
②反射獲取其中DexPathList屬性:DexPathList pathList.
③獲取到補丁包path.dex文件的Element[]數(shù)組 pElements。參考PathClassLoader怎么把dex文件轉(zhuǎn)換為Element數(shù)組的。于是我們反射執(zhí)行DexPathList?中的makePathElements方法（視API而定）傳入dex路徑得到補丁包的element數(shù)組。
④獲取pathList的dexElements數(shù)組。
⑤把補丁包的pElements數(shù)組合并到pathList的dexElements數(shù)組的前方，即newElements=pElements+dexElements
⑥反射賦值把newElements替換掉pathList的dexElements
熱修復(fù)沒這么簡單，還需考慮混淆，API版本不同導(dǎo)致的使用makePathElements方法或makeDexElements方法等因素。
熱修復(fù)（InstantRun?形式(Robust)）待了解。
1、Android客戶端應(yīng)用程序
如新浪微博、網(wǎng)銀客戶端、凡客、淘寶客戶端，快盤客戶端。Android在這里的應(yīng)用還是界面層的東西為主。核心還在WEB。客戶端界面很重要，用戶體驗度很重要。從應(yīng)用需求上來講，幾乎大一點的網(wǎng)站，都需要有手機客戶端程序。
2、Android通用類程序
如基于LBS（基于位置的服務(wù)）的應(yīng)用（這類一般會嵌入到客戶端應(yīng)用程序中），流媒體播放應(yīng)用。由于移動設(shè)備的方便便捷、3G、4G網(wǎng)絡(luò)的發(fā)展，這類應(yīng)用有不錯的前景。
3、Android游戲開發(fā)
需要掌握的游戲引擎LGame，游戲框架等。手機上的游戲會是一大塊內(nèi)容，有前途。
4、Android底層開發(fā)
需要掌握C、Linux等較底層的東西，發(fā)展方向應(yīng)該是驅(qū)動、協(xié)議開發(fā)，嵌入式開發(fā)。
Collection是最基本的集合接口，一個Collection代表一組Object，即Collection的元素（Elements）。一些Collection允許相同的元素而另一些不行。一些能排序而另一些不行。Java SDK不提供直接繼承自Collection的類，Java SDK提供的類都是繼承自Collection的“子接口”如List和Set。（這段話是抄來的）
咳咳，大體的意思的就是Collection是所有List的國際標(biāo)準(zhǔn)了，那我們可以看一下Collection接口需要記一下的方法。
這個方法是用來遍歷Collection中所有的元素的，用法如下：
這個可以遍歷出一個Collection中所有的元素。
List接口是有序的Collection接口的實現(xiàn)。此接口能夠精確的控制每個元素插入的位置。用戶能夠使用索引（元素在List中的位置，類似于數(shù)組下標(biāo)）來訪問List中的元素，類似于Java的數(shù)組。
順序是 List 重要的特性；它可保證元素按照規(guī)定的順序排列。
List 為 Collection 添加了大量方法，以便我們在 List 中部插入和刪除元素（只推薦對 LinkedList 這樣做）。List 也會生成一個 ListIterator（列表反復(fù)器），利用它可在一個列表里朝兩個方向遍歷，同時插入和刪除位于列表中部的元素（同樣地，只建議對 LinkedList 這樣做）
ArrayList 由一個數(shù)組后推得到的 List。作為一個常規(guī)用途的對象容器使用，用于替換原先的 Vector。允許我們快速訪問元素，但在從列表中部插入和刪除元素時，速度卻嫌稍慢。一般只應(yīng)該用 ListIterator 對一個 ArrayList 進(jìn)行向前和向后遍歷，不要用它刪除和插入元素；與 LinkedList 相比，它的效率要低許多
LinkedList 提供優(yōu)化的順序訪問性能，同時可以高效率地在列表中部進(jìn)行插入和刪除操作。但在進(jìn)行隨機訪問時，速度卻相當(dāng)慢，此時應(yīng)換用 ArrayList。也提供了 addFirst()，addLast()，getFirst()，getLast()，removeFirst()以及 removeLast() （未在任何接口或基礎(chǔ)類中定義），以便將其作為一個規(guī)格、隊列以及一個雙向隊列使用
Vector和ArrayList
Android手寫熱修復(fù)（一）--ClassLoader
我們平時編寫的 .java 文件不是可執(zhí)行文件，需要先編譯成 .class 文件才可以被虛擬機執(zhí)行。所謂類加載是指通過 類加載器 把class文件加載到虛擬機的內(nèi)存空間，具體來說是方法區(qū)。類通常是按需加載，即第一次使用該類時才加載。
首先，Java與Android都是把類加載到虛擬機內(nèi)存中，然后由虛擬機轉(zhuǎn)換成設(shè)備識別的機器碼。但是由于二者使用的虛擬機不同，所以在類加載方面也是有所區(qū)別的。Java的虛擬機是JVM，Android的虛擬機是dalvik／art(5.0以后虛擬機是art，是對dalvik的一種升級)。 Java虛擬機運行的是class文件，而Android 虛擬機運行的是dex文件。 dex其實是class文件的集合，是對class文件優(yōu)化的產(chǎn)物，是為了避免出現(xiàn)重復(fù)的class。
從上面的講解中，我們已經(jīng)知道我們平時寫的類是被 類加載器 加載盡虛擬機內(nèi)存才能運行。下面就通過Framework源碼來為大家講解Android中最主要的5個類加載器。
在Activity做個簡單驗證：
結(jié)果：
可以看出系統(tǒng)類由BootClassLoader加載，apk中的類由PathClassLoader加載，PathClassLoader的父類加載器是BootClassLoader。如果暫時不能理解父類加載器是什么，沒關(guān)系，后面講雙親委托機制的時候會理解的。
下面的源碼解析基于 Android SDK API28 ，這幾個類加載器（除了ClassLoader）沒辦法直接在AS上查看源碼，AS搜索到的是反編譯的class的內(nèi)容，是不可信的，為大家推薦一個在線工具查看， 在線查看Android Framework源碼 。
用來加載本地文件系統(tǒng)上的文件或目錄，通常是用來加載apk中我們自己寫的類，而像 Activity.class 這種系統(tǒng)的類不是由它加載。注意：這里，并不像很多網(wǎng)上文章說的那樣只能加載apk，本地的其他目錄的文件也是可以的，這一點我會在后面驗證說明。
也是被用來加載 jar 、apk、dex，通常用來加載未安裝到應(yīng)用中的文件。注意，它需要一個應(yīng)用私有的可寫的目錄來存放優(yōu)化后的dex文件。千萬不要選擇外部存儲路徑，因為這樣可能會導(dǎo)致你的應(yīng)用遭到注入攻擊。
關(guān)于dex文件優(yōu)化，可能很多人還是不理解，水平有限，我簡單解釋一下，
構(gòu)造器參數(shù)解釋：
關(guān)于optimizedDirectory：
1、這是dex優(yōu)化后的路徑，它必須是一個應(yīng)用私有的可寫的目錄否則會存在注入攻擊的風(fēng)險；
2、這個參數(shù)在API 26（8.0）之前是有值的，之后的話，這個參數(shù)已經(jīng)沒有影響了，因為在調(diào)用父構(gòu)造器的時候這個參數(shù)始終為null，也就是說Android 8.0 以后DexClassLoader和PathClassLoader基本一樣的來；
3、在加載app的時候，apk內(nèi)部的dex已經(jīng)執(zhí)行過優(yōu)化了，優(yōu)化之后放在系統(tǒng)目錄/data/dalvik-cache下。
這個構(gòu)造器的關(guān)鍵是初始化了一個DexPathList對象，這個是后面加載class的關(guān)鍵類。
這個構(gòu)造方法等關(guān)鍵是通過 makeDexElements() 方法來獲取Element數(shù)組，這個Element數(shù)組非常關(guān)鍵，后面查找class就會用到它，也是熱修復(fù)的關(guān)鍵點之一。
splitDexPath(dexPath) 方法是把dexPath目錄下的所有文件轉(zhuǎn)換成一個File集合，如果是多個文件的話，會用 : 作為分隔符。
makeDexElements()
小結(jié)一下，這個方法就是把指定目錄下的文件apk／jar／zip／dex按不同的方式封裝成Element對象，然后按順序添加到Element[]數(shù)組中。
DexPathList#loadDexFile()
可以看到 DexFile 最終是調(diào)用了openDexFile、native方法openDexFileNative去打開Dex文件的，如果outputName為空，則自動生成一個緩存目錄，具體來說是 /data/dalvik-cache/xxx@classes.dex 。openDexFileNative這個native方法就不具體分析了，主要是對dex文件進(jìn)行了優(yōu)化操作，將優(yōu)化后得odex文件通過mmap映射到內(nèi)存中。感興趣的同學(xué)可以參考：
《DexClassLoader和PathClassLoader加載Dex流程》
現(xiàn)在在回頭看看DexClassLoader與PathClassLoader的區(qū)別。DexClassLoader可以指定odex的路徑，而PathClassLoader則采用系統(tǒng)默認(rèn)的緩存路徑，在8.0以后沒有區(qū)別。
ClassLoader是一個抽象類，有3個構(gòu)造方法，最終調(diào)用的還是第一個構(gòu)造方法，主要功能是保存實現(xiàn)類傳入的parent參數(shù)，也就是父類加載器。ClassLoader的實現(xiàn)類主要有2個，一個是前面講過的BaseDexClassLoader，另一個是BootClassLoader。
BootClassLoader是ClassLoader的內(nèi)部類，而且繼承了ClassLoader。
這是加載一個類的入口，流程如下：
1、 先檢查這個類是否已經(jīng)被加載，有的話直接返回Class對象；
2、如果沒有加載過，通過父類加載器去加載，可以看出parent是通過遞歸的方式去加載class的；
3、如果所有的父類加載器都沒有加載過，就由當(dāng)前的類加載器去加載。
通常我們自己寫的類是通過當(dāng)前類加載器調(diào)用 findClass 方法去加載的，但是在 ClassLoader 中這是個空方法，具體的實現(xiàn)在它的子類 BaseDexClassLoader 中。
BaseDexClassLoader # findClass
可以看到是通過pathList去查找class的，這個對象其實之前講過，它是在BaseDexClassLoader 的構(gòu)造方法中初始化的，它實際上是一個 DexPathList 對象。
DexPathList # findClass()
對Element數(shù)組遍歷，再通過Element對象的 findClass 方法去查找class，有的話就直接返回這個class，找不到則返回null。 這里可以看出獲取Class是通過DexFile來實現(xiàn)的，而各種類加載器操作的是Dex。Android虛擬機加載的dex文件，而不是class文件。
1、加載一個類是通過雙親委托機制來實現(xiàn)的。
2、如果是第一次加載class，那是通過 BaseDexClassLoader 中的findClass方法實現(xiàn)的；接著進(jìn)入 DexPathList 中的findClass方法，內(nèi)部通過遍歷Element數(shù)組，從Element對象中去查找類；Element實際上是對Dex文件的包裝，最終還是從dexfile去查找的class。
3、一般app運行主要用到2個類加載器，一個是PathClassLoader：主要用于加載自己寫的類；另一個是BootClassLoader：用于加載Framework中的類；
4、熱修復(fù)和插件化一般是利用DexClassLoader來實現(xiàn)。
5、PathClassLoader和DexClassLoader其實都可以加載apk／jar／dex，區(qū)別是 DexClassLoader 可以指定 optimizedDirectory ，也就是 dex2oat 的產(chǎn)物 .odex 存放的位置，而 PathClassLoader 只能使用系統(tǒng)默認(rèn)位置。但是在8.0 以后二者是沒有區(qū)別的，只能使用系統(tǒng)默認(rèn)的位置了。
這張圖來源于：
Android虛擬機框架：類加載機制
在類加載流程分析中，我們已經(jīng)知道，查找class是通過DexPathList來完成的，實際上DexPathList最終還是遍歷其Element數(shù)組，獲取DexFile對象來加載Class文件。 由于數(shù)組是有序的，如果2個dex文件中存在相同類名的class，那么類加載器就只會加載數(shù)組前面的dex中的class。如果apk中出現(xiàn)了有bug的class，那只要把修復(fù)的class打包成dex文件并且放在 DexPathList 中Element數(shù)組`的前面，就可以實現(xiàn)bug修復(fù)了 。下一篇為大家?guī)淼氖謱憻嵝迯?fù)。
Android類加載機制的細(xì)枝末節(jié)
從JVM到Dalivk再到ART（class,dex,odex,vdex,ELF）
類加載機制系列2——深入理解Android中的類加載器
Android 熱修復(fù)核心原理，ClassLoader類加載
重慶分公司
重慶分公司
