Android熱修復及外掛化原理
1.前言
熱修復一直是這幾年來很熱門的話題，主流方案大致有兩種，一種是微信Tinker的dex檔案替換，另一種是阿里的Native層的方法替換。這裡重點介紹Tinker的大致原理。
2.類載入機制
介紹Tinker原理之前，我們先來回顧一下類載入機制。
我們編譯好的class檔案，需要先載入到虛擬機器然後才會執行，這個過程是通過ClassLoader來完成的。
雙親委派模型：
- 1.載入某個類的時候，這個類載入器不會自己立刻去載入，它會委託給父類去載入
- 2.如果這個父類還存在父類載入器，則進一步委託，直到最頂層的類載入器
- 3.如果父類載入器可以完成載入任務，就成功返回，否則就再委派給子類載入器
- 4.如果都未載入成功就丟擲ClassNotFoundException
作用：
1.避免類的重複載入。
比如有兩個類載入器，他們都要載入同一個類，這時候如果不是委託而是自己載入自己的，則會將類重複載入到方法區。
2.避免核心類被修改。
比如我們在自定義一個 java.lang.String 類，執行的時候會報錯，因為 String 是 java.lang 包下的類，應該由啟動類載入器載入。
JVM並不會一開始就載入所有的類，它是當你使用到的時候才會去通知類載入器去載入。
3.Android類載入
當我們new一個類時，首先是Android的虛擬機器（Dalvik/ART虛擬機器）通過ClassLoader去載入dex檔案到記憶體。
Android中的ClassLoader主要是PathClassLoader和DexClassLoader,這兩者都繼承自BaseDexClassLoader。它們都可以理解成應用類載入器。
PathClassLoader和DexClassLoader的區別：
-
PathClassLoader只能指定載入apk包路徑，不能指定dex檔案解壓路徑。該路徑是寫死的在/data/dalvik-cache/路徑下。所以只能用於載入已安裝的apk。
-
DexClassLoader可以指定apk包路徑和dex檔案解壓路徑（載入jar、apk、dex檔案）
當ClassLoader載入類時，會呼叫它的findclass方法去查詢該類。
下方是BaseDexClassLoader的findClass方法實現：
public class BaseDexClassLoader extends ClassLoader {
...
@UnsupportedAppUsage
private final DexPathList pathList;
...
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
// 首先檢查該類是否存在shared libraries中.
if (sharedLibraryLoaders != null) {
for (ClassLoader loader : sharedLibraryLoaders) {
try {
return loader.loadClass(name);
} catch (ClassNotFoundException ignored) {
}
}
}
//再呼叫pathList.findClass去查詢該類，結果為null則丟擲錯誤。
List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
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;
}
}
接下來我們再來看看DexPathList的findClass實現：
public DexPathList(ClassLoader definingContext, String librarySearchPath) {
...
/**
* List of dex/resource (class path) elements.
* 存放dex檔案的一個數組
*/
@UnsupportedAppUsage
private Element[] dexElements;
...
public Class<?> findClass(String name, List<Throwable> suppressed) {
//遍歷Element陣列，去查尋對應的類，找到後就立刻返回了
for (Element element : dexElements) {
Class<?> clazz = element.findClass(name, definingContext, suppressed);
if (clazz != null) {
return clazz;
}
}
if (dexElementsSuppressedExceptions != null) {
suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
}
return null;
}
...
}
4.Tinker原理
- 1.使用DexClassLoader載入補丁包的dex檔案
- 2.通過反射獲取DexClassLoader類的pathList，再次通過反射獲得dexElements陣列。
- 3.獲取載入應用類的PathClassLoader，同樣通過反射獲取它的dexElements陣列。
- 4.合併兩個dexElements陣列，且將補丁包的dex檔案放在前面。
根據類載入機制，一個類只會被載入一次，DexPathList.findClass方法中是順序遍歷陣列，所以將補丁的dex檔案放在前面，這樣bug修復類會被優先載入，而原來的bug類不會被載入，達到了替換bug類的功能（補丁包中的修復類名、包名要和bug類相同） - 5.再次通過反射將合併後的dexElements陣列賦值給PathClassLoader.dexElements屬性。
載入類時，Dalvik/ART虛擬機器會通過PathClassLoader去查詢已安裝的apk檔案中的類。
Ok，這樣就替換成功了，重啟App，再呼叫原來的bug類，將會優先使用補丁包中的修復類。
為什麼要重啟：因為雙親委派模型，一個類只會被ClassLoader載入一次，且載入過後的類不能解除安裝。
程式碼實現
接下來我們動手擼一個乞丐版的Tinker。
首先我們寫一個bug類。
package com.baima.plugin;
class BugClass {
public String getTitle(){
return "這是個Bug";
}
}
接著我們新建一個module來生成補丁包apk。
建立bug修復類，注意包名類名要一樣。
package com.baima.plugin;
class BugClass {
public String getTitle(){
return "修復成功";
}
}
生成補丁apk，讓使用者下載這個補丁包。接下來就是載入這個apk檔案並替換了。
public void loadDexAndInject(Context appContext, String dexPath, String dexOptPath) {
try {
// 載入應用程式dex的Loader
PathClassLoader pathLoader = (PathClassLoader) appContext.getClassLoader();
//dexPath 補丁dex檔案所在的路徑
//dexOptPath 補丁dex檔案被寫入後存放的路徑
DexClassLoader dexClassLoader = new DexClassLoader(dexPath, dexOptPath, null, pathLoader);
//利用反射獲取DexClassLoader和PathClassLoader的pathList屬性
Object dexPathList = getPathList(dexClassLoader);
Object pathPathList = getPathList(pathLoader);
//同樣用反射獲取DexClassLoader和PathClassLoader的dexElements屬性
Object leftDexElements = getDexElements(dexPathList);
Object rightDexElements = getDexElements(pathPathList);
//合併兩個陣列，且補丁包的dex檔案在陣列的前面
Object dexElements = combineArray(leftDexElements, rightDexElements);
//反射將合併後的陣列賦值給PathClassLoader的pathList.dexElements
Object pathList = getPathList(pathLoader);
Class<?> pathClazz = pathList.getClass();
Field declaredField = pathClazz.getDeclaredField("dexElements");
declaredField.set看，ccessible(true);
declaredField.set(pathList, dexElements);
} catch (Exception e) {
e.printStackTrace();
}
}
private static Object getPathList(Object classLoader) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {
Class<?> cl = Class.forName("dalvik.system.BaseDexClassLoader");
Field field = cl.getDeclaredField("pathList");
field.setAccessible(true);
return field.get(classLoader);
}
private static Object getDexElements(Object pathList) throws NoSuchFieldException, IllegalAccessException {
Class<?> cl = pathList.getClass();
Field field = cl.getDeclaredField("dexElements");
field.setAccessible(true);
return field.get(pathList);
}
private static Object combineArray(Object arrayLeft, Object arrayRight) {
Class<?> clazz = arrayLeft.getClass().getComponentType();
int i = Array.getLength(arrayLeft);
int j = Array.getLength(arrayRight);
int k = i + j;
Object result = Array.newInstance(clazz, k);// 建立一個型別為clazz，長度為k的新陣列
System.arraycopy(arrayLeft, 0, result, 0, i);
System.arraycopy(arrayRight, 0, result, i, j);
return result;
}
ok,乞丐版Tinker完成了，使用時先在Splash介面檢查是否有外掛補丁，有的話執行替換，這時你再使用bug類會發現它已經被替換成補丁中的修復類了。
5.外掛化
外掛化開發模式，打包時是一個宿主apk+多個外掛apk。
元件化開發模式，打包時是一個apk，裡面分多個module。
優點:
- 安裝的主apk包會小好多
- 給開發者提供了業務功能擴充套件，並且不需要使用者進行更新
- 在非主apk包中的功能出現BUG時，可以及時修復
- 使用者不需要的功能，完全就不會出現在系統裡面，減輕裝置的負擔
需要掌握的知識：
- 1.類載入機制
- 2.四大元件啟動流程
- 3.AIDL、Binder機制
- 4.Hook、反射、代理
5.1 Activity啟動流程簡單介紹
上圖是普通的Activity啟動流程，和根Activity啟動流程的區別是不用建立應用程式程序（Application Thread）。
啟動過程：
- 應用程式程序中的Activity向AMS請求建立普通Activity
- AMS會對這個Activty的生命週期管和棧進行管理，校驗Activity等等
- 如果Activity滿足AMS的校驗，AMS就會請求應用程式程序中的ActivityThread去建立並啟動普通Activity
他們之間的跨程序通訊是通過Binder實現的。
5.2 外掛化原理
通過上面介紹的熱修復，我們有辦法去載入外掛apk裡面的類，但是還沒有辦法去啟動外掛中的Activity，因為如果要啟動一個Activity，那麼這個Activity必須在AndroidManifest.xml中註冊。
這裡介紹外掛化的一種主流實現方式–Hook技術。
- 1.宿主App預留佔坑Activity
- 2.使用classLoader載入dex檔案到記憶體
- 3.先使用佔坑Activity繞過AMS驗證，接著用外掛Activity替換佔坑的Activity。
步驟1、2這裡就不在贅述了，2就是上面講到的熱修復技術。
5.2.1 繞開驗證
AMS是在SystemServer程序中，我們無法直接進行修改，只能在應用程式程序中做文章。介紹一個類–IActivityManager，IActivityManager它通過AIDL（內部使用的是Binder機制）和SystemServer程序的AMS通訊。所以IActivityManager很適合作為一個hook點。
Activity啟動時會呼叫IActivityManager.startActivity方法向AMS發出啟動請求，該方法引數包含一個Intent物件，它是原本要啟動的Activity的Intent。我們可以動態代理IActivityManager的startActivity方法，將該Intent換為佔坑Activity的Intent，並將原來的Intent作為引數傳遞過去，以此達到欺騙AMS繞開驗證。
public class IActivityManagerProxy implements InvocationHandler {
private Object mActivityManager;
private static final String TAG = "IActivityManagerProxy";
public IActivityManagerProxy(Object activityManager) {
this.mActivityManager = activityManager;
}
@Override
public Object invoke(Object o, Method method, Object[] args) throws Throwable {
if ("startActivity".equals(method.getName())) {
Intent intent = null;
int index = 0;
for (int i = 0; i < args.length; i++) {
if (args[i] instanceof Intent) {
index = i;
break;
}
}
intent = (Intent) args[index];
Intent subIntent = new Intent();
String packageName = "com.example.pluginactivity";
subIntent.setClassName(packageName,packageName+".StubActivity");
subIntent.putExtra(HookHelper.TARGET_INTENT, intent);
args[index] = subIntent;
}
return method.invoke(mActivityManager, args);
}
}
接下來就通過反射的方式，將ActivityManager中的IActivityManager替換成我們的代理物件。
public void hookAMS() {
try {
Object defaultSingleton = null;
if (Build.VERSION.SDK_INT >= 26) {
Class<?> activityManagerClazz = Class.forName("android.app.ActivityManager");
defaultSingleton = FieldUtil.getObjectField(activityManagerClazz, null, "IActivityManagerSingleton");
} else {
Class<?> activityManagerNativeClazz = Class.forName("android.app.ActivityManagerNative");
defaultSingleton = FieldUtil.getObjectField(activityManagerNativeClazz, null, "gDefault");
}
Class<?> singletonClazz = Class.forName("android.util.Singleton");
Field mInstanceField = FieldUtil.getField(singletonClazz, "mInstance");
Object iActivityManager = mInstanceField.get(defaultSingleton);
Class<?> iActivityManagerClazz = Class.forName("android.app.IActivityManager");
Object proxy = Proxy.newProxyInstance(Thread.currentThread().getContextClassLoader(), new Class<?>[]{
iActivityManagerClazz}, new IActivityManagerProxy(iActivityManager));
mInstanceField.set(defaultSingleton, proxy);
} catch (Exception e) {
e.printStackTrace();
}
}
Note: 這裡獲取IActivityManager例項會因為Android版本不同而不同，具體獲取方法就需要去看原始碼瞭解了。這裡的程式碼Android 8.0是可以執行的。
5.2.2還原外掛Activity
ActivityThread啟動Activity的過程如下所示：
ActivityThread會通過H在主執行緒中去啟動Activity,H類是ActivityThread的內部類並繼承自Handler。
private class H extends Handler {
public static final int LAUNCH_ACTIVITY = 100;
public static final int PAUSE_ACTIVITY = 101;
...
public void handleMessage(Message msg) {
if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
switch (msg.what) {
case LAUNCH_ACTIVITY: {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
final ActivityClientRecord r = (ActivityClientRecord) msg.obj;
r.packageInfo = getPackageInfoNoCheck(
r.activityInfo.applicationInfo, r.compatInfo);
handleLaunchActivity(r, null, "LAUNCH_ACTIVITY");
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
} break;
...
}
...
}
H中重寫的handleMessage方法會對LAUNCH_ACTIVITY型別的訊息進行處理，最終會呼叫Activity的onCreate方法。那麼在哪進行替換呢？接著來看Handler的dispatchMessage方法：
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
Handler的dispatchMessage用於處理訊息，可以看到如果Handler的Callback型別的mCallback不為null，就會執行mCallback的handleMessage方法。因此，mCallback可以作為Hook點，我們可以用自定義的Callback來替換mCallback，自定義的Callback如下所示。
public class HCallback implements Handler.Callback{
public static final int LAUNCH_ACTIVITY = 100;
Handler mHandler;
public HCallback(Handler handler) {
mHandler = handler;
}
@Override
public boolean handleMessage(Message msg) {
if (msg.what == LAUNCH_ACTIVITY) {
Object r = msg.obj;
try {
//得到訊息中的Intent(啟動佔坑Activity的Intent)
Intent intent = (Intent) FieldUtil.getField(r.getClass(), r, "intent");
//得到此前儲存起來的Intent(啟動外掛Activity的Intent)
Intent target = intent.getParcelableExtra(HookHelper.TARGET_INTENT);
//將佔坑Activity的Intent替換為外掛Activity的Intent
intent.setComponent(target.getComponent());
} catch (Exception e) {
e.printStackTrace();
}
}
mHandler.handleMessage(msg);
return true;
}
}
最後一步就是用反射將我們自定義的callBack設定給ActivityThread.sCurrentActivityThread.mH.mCallback。
public void hookHandler() {
try {
Class<?> activityThreadClass = Class.forName("android.app.ActivityThread");
Object currentActivityThread = FieldUtil.getObjectField(activityThreadClass, null, "sCurrentActivityThread");
Field mHField = FieldUtil.getField(activityThreadClass, "mH");
Handler mH = (Handler) mHField.get(currentActivityThread);
FieldUtil.setObjectField(Handler.class, mH, "mCallback", new HCallback(mH));
} catch (Exception e) {
e.printStackTrace();
}
}
其實要想啟動一個Activity到這步還沒有完，一個完整的Activity應該還需要佈局檔案，而我們的宿主APP並不會包含外掛的資源。
2.3 載入外掛資源
2.3.1 Resources&AssetManager
android中的資源大致分為兩類：一類是res目錄下存在的可編譯的資原始檔，比如anim，string之類的，第二類是assets目錄下存放的原始資原始檔。因為Apk編譯的時候不會編譯這些檔案，所以不能通過id來訪問，當然也不能通過絕對路徑來訪問。於是Android系統讓我們通過Resources的getAssets方法來獲取AssetManager，利用AssetManager來訪問這些檔案。
其實Resource的getString, getText等各種方法都是通過呼叫AssetManager的私有方法來完成的。
過程就是Resource通過resource.arsc(AAPT工具打包過程中生成的檔案)把ID轉換成資原始檔的名稱，然後交由AssetManager來載入檔案。
AssetManager裡有個很重要的方法addAssetPath(String path)方法，App啟動的時候會把當前apk的路徑傳進去，然後AssetManager就能訪問這個路徑下的所有資源也就是宿主apk的資源了。我們可以通過hook這個方法將外掛的path傳進去，得到的AssetManager就能同時訪問宿主和外掛的所有資源了。
public void hookAssets(Activity activity,String dexPath){
try {
AssetManager assetManager = activity.getResources().getAssets();
Method addAssetPath = assetManager.getClass().getMethod("addAssetPath",String.class);
addAssetPath.invoke(assetManager,dexPath);
Resources mResources = new Resources(assetManager, activity.getResources().getDisplayMetrics(), activity.getResources().getConfiguration());
//接下來我們要將宿主原有Resources替換成我們上面生成的Resources。
FieldUtil.setObjectField(ContextWrapper.class,activity.getResources(),"mResources",mResources);
} catch (NoSuchMethodException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
}
}
2.3.2 id衝突
新的問題又出現了，宿主apk和外掛apk是兩個不同的apk，他們在編譯時都會產生自己的resources.arsc。即他們是兩個獨立的編譯過程。那麼它們的resources.arsc中的資源id必定是有相同的情況。這樣我們上面生成的新Resources中就出現了資源id重複的情況，這樣在執行的時候使用資源id來獲取資源就會報錯。
怎麼解決資源Id衝突的問題？這裡介紹一下VirtualApk採用的方案。
修改aapt的產物。即編譯後期重新整理外掛Apk的資源，編排ID，更新R檔案
VirtualApkhook了ProcessAndroidResourcestask。這個task是用來編譯Android資源的。VirtualApk拿到這個task的輸出結果，做了以下處理:
- 1.根據編譯產生的R.txt檔案收集外掛中所有的資源
- 2.根據編譯產生的R.txt檔案收集宿主apk中的所有資源
- 3.過濾外掛資源:過濾掉在宿主中已經存在的資源
- 4.重新設定外掛資源的資源ID
- 5.刪除掉外掛資源目錄下前面已經被過濾掉的資源
- 6.重新編排外掛resources.arsc檔案中外掛資源ID為新設定的資源ID
- 7.重新產生R.java檔案
大致原理是這樣的，但如何保證新的Id不會重複了，這裡在介紹一下資源Id的組成。
packageId: 前兩位是packageId，相當於一個名稱空間，主要用來區分不同的包空間(不是不同的module)。目前來看，在編譯app的時候，至少會遇到兩個包空間：android系統資源包和咱們自己的App資源包。大家可以觀察R.java檔案，可以看到部分是以0x01開頭的，部分是以0x7f開頭的。以0x01開頭的就是系統已經內建的資源id，以0x7f開頭的是咱們自己新增的app資源id。
typeId：typeId是指資源的型別id，我們知道android資源有animator、anim、color、drawable、layout，string等等，typeId就是拿來區分不同的資源型別。
entryId：entryId是指每一個資源在其所屬的資源型別中所出現的次序。注意，不同型別的資源的Entry ID有可能是相同的，但是由於它們的型別不同，我們仍然可以通過其資源ID來區別開來。
所以為了避免衝突，外掛的資源id通常會採用0x02 - 0x7e之間的數值。
- 編譯安裝Mysql8.0.22
- 由Hadoop驅動的原始大資料時代已於2019年6月結束…….858
- Apache Jmeter 教程
- 中國科學院正式回覆饒毅：不再進行調查
- Android熱修復及外掛化原理
- 【資料庫MySQL】練習---備份及恢復
- 一組強大的CSS3 Material 按鈕
- No.8 bin和sbin的區別
- nginx配置ssl證書訪問不了https網站
- 大根堆與小根堆的理解，如何手寫一個堆，以及什麼時候用自己手寫的堆，什麼時候用語言提供堆的api，（二者的區別）
- FreeRTOS的License許可說明~
- 穩定流暢、高清晰， 華為HMS Core帶來一站式視訊服務
- “模板方法 職責鏈設計模式”解決業務場景重複以及場景之間依賴
- vi視窗切分命令（split命令）
- Linux學習筆記
- MySQL事務隔離級別以及髒讀、幻讀、不可重複讀示例
- 基於live555的rtsp播放器：資料接收（拉流）
- APACHE 2.2.15 TOMCAT6.0.26配置負載均衡
- 資料恢復基礎和進階教程（一）
- 2011年11月51CTO桌布點評活動獲獎名單【已結束】