Android插件化原理解析 [復制鏈接]

2019-8-30 09:39
BlueManlove 閱讀:923 評論:0 贊:0
Tag:  插件化

概述

Android插件化技術,可以實現功能模塊的按需加載和動態更新,其本質是動態加載未安裝的apk。

本文涉及源碼為API 28

插件化原理

插件化要解決的三個核心問題: 類加載、 資源加載、 組件生命周期管理。

類加載

Android中常用的兩種類加載器: PathClassLoader和 DexClassLoader,它們都繼承于BaseDexClassLoader。

// PathClassLoader.java
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.java
public class DexClassLoader extends BaseDexClassLoader {
public DexClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {
super(dexPath, null, librarySearchPath, parent);
}
}

說明

  • DexClassLoader的構造函數比PathClassLoader多了一個, optimizedDirectory參數,這個是用來指定dex的優化產物odex的路徑,在源碼注釋中,指出這個參數從API 26后就棄用了。
  • PathClassLoader主要用來加載系統類和應用程序的類,在ART虛擬機上可以加載未安裝的apk的dex,在Dalvik則不行。
  • DexClassLoader用來加載未安裝apk的dex。

資源加載

Android系統通過Resource對象加載資源,因此只需要添加資源(即apk文件)所在路徑到 AssetManager中,即可實現對插件資源的訪問。

// 創建AssetManager對象
AssetManager assetManager = new AssetManager();
// 將apk路徑添加到AssetManager中
if (assetManager.addAssetPath(apkPath) == 0) {
return null;
}
// 創建插件Resource對象
Resources pluginResources = new Resources(assetManager, metrics, getConfiguration());

說明:由于AssetManager的構造方法時 hide的,需要通過反射區創建。

組件生命周期管理

對于Android來說,并不是說類加載進來就可以使用了,很多組件都是有“生命”的;因此對于這些有血有肉的類,必須給他們注入活力,也就是所謂的 組件生命周期管理。

在解決插件中組件的生命周期,通常的做法是通過 Hook相應的系統對象,實現欺上瞞下,后面將通過Activity的插件化來進行講解。

Activity插件化

四大組件的插件化是插件化技術的核心知識點,而Activity插件化更是重中之中,Activity插件化的主流實現方式是通過 Hook技術實現。

Activity的啟動過程


上圖列出的是啟動一個Activity的主要過程,具體步驟如下:

  1. Activity1調用startActivity,實際會調用 Instrumentation類的 execStartActivity方法,Instrumentation是系統用來監控Activity運行的一個類,Activity的整個生命周期都有它的影子。
  2. 通過跨進程的binder調用,進入到 ActivityManagerService(AMS)中,其內部會處理Activity棧。之后又通過跨進程調用進入到Activity2所在的進程中。
  3. ApplicationThread是一個binder對象,其運行在binder線程池中,內部包含一個 H類,該類繼承于Handler。ApplicationThread將啟動Activity2的信息通過H對象發送給主線程。
  4. 主線程拿到Activity2的信息后,調用Instrumentation類的 newAcitivity方法,其內部通過ClassLoader創建Activity2實例。

加載插件中的類

public class PluginHelper {
private static final String TAG = "PluginHelper";
private static final String CLASS_DEX_PATH_LIST = "dalvik.system.DexPathList";
private static final String FIELD_PATH_LIST = "pathList";
private static final String FIELD_DEX_ELEMENTS = "dexElements";
private static void loadPluginClass(Context context, ClassLoader hostClassLoader) throws Exception {
// Step1. 獲取到插件apk,通常都是從網絡上下載,這里為了演示,直接將插件apk push到手機
File pluginFile = context.getExternalFilesDir("plugin");
Log.i(TAG, "pluginPath:" + pluginFile.getAbsolutePath());
if (pluginFile == null || !pluginFile.exists() || pluginFile.listFiles().length == 0) {
Toast.makeText(context, "插件文件不存在", Toast.LENGTH_SHORT).show();
return;
}
pluginFile = pluginFile.listFiles()[0];
// Step2. 創建插件的DexClassLoader
DexClassLoader pluginClassLoader = new DexClassLoader(pluginFile.getAbsolutePath(), null, null, hostClassLoader);
// Step3. 通過反射獲取到pluginClassLoader中的pathList字段
Object pluginDexPathList = ReflectUtil.getField(BaseDexClassLoader.class, pluginClassLoader, FIELD_PATH_LIST);
// Step4. 通過反射獲取到DexPathList的dexElements字段
Object pluginElements = ReflectUtil.getField(Class.forName(CLASS_DEX_PATH_LIST), pluginDexPathList, FIELD_DEX_ELEMENTS);
// Step5. 通過反射獲取到宿主工程中ClassLoader的pathList字段
Object hostDexPathList = ReflectUtil.getField(BaseDexClassLoader.class, hostClassLoader, FIELD_PATH_LIST);
// Step6. 通過反射獲取到宿主工程中DexPathList的dexElements字段
Object hostElements = ReflectUtil.getField(Class.forName(CLASS_DEX_PATH_LIST), hostDexPathList, FIELD_DEX_ELEMENTS);
// Step7. 將插件ClassLoader中的dexElements合并到宿主ClassLoader的dexElements
Object array = combineArray(hostElements, pluginElements);
// Step8. 將合并的dexElements設置到宿主ClassLoader
ReflectUtil.setField(Class.forName(CLASS_DEX_PATH_LIST), hostDexPathList, FIELD_DEX_ELEMENTS, array);
}
}

處理插件Activity的啟動

在Android中,Activity的啟動需要在 AndroidManifest.xml中配置,如果沒有配置的話,就會報 ActivityNotFoundException異常,而插件的Activity無法再宿主AndroidManifest中注冊。在上面的Activity的啟動流程圖,Activity的啟動是要經過AMS的校驗的,所以就需要對AMS下功夫。

Step1. 在宿主工程的AndroidManifest.xml中預先注冊Activity進行占坑。

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
package="com.github.xch168.plugindemo">
<application>
<!--占坑Activity,不需要創建類-->
<activity android:name=".StubActivity" />
</application>
</manifest>

Step2. 使用占坑Activity繞過AMS驗證。

Activity的啟動,實際會調用 Instrumentation類的 execStartActvity方法,所以可以對其進行hook,將啟動插件Activity的Intent替換成宿主預注冊的插樁Activity,從而繞過ASM的驗證。

Instrumentation代理類:

public class InstrumentationProxy extends Instrumentation {
private Instrumentation mInstrumentation;
private PackageManager mPackageManager;
public InstrumentationProxy(Instrumentation instrumentation, PackageManager packageManager) {
mInstrumentation = instrumentation;
mPackageManager = packageManager;
}
public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options) {
List<ResolveInfo> infos = mPackageManager.queryIntentActivities(intent, PackageManager.MATCH_ALL);
if (infos == null || infos.size() == 0) {
// 保存要啟動的插件Activity的類名
intent.putExtra(HookHelper.TARGET_INTENT, intent.getComponent().getClassName());
// 構建插樁Activity的Intent
intent.setClassName(who, "com.github.xch168.plugindemo.StubActivity");
}
try {
Method execMethod = Instrumentation.class.getDeclaredMethod("execStartActivity", Context.class, IBinder.class, IBinder.class, Activity.class, Intent.class, int.class, Bundle.class);
// 將插樁Activity的Intent傳給ASM驗證
return (ActivityResult) execMethod.invoke(mInstrumentation, who, contextThread, token, target, intent, requestCode, options);
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
}

Hook:

public class HookHelper {
public static final String TARGET_INTENT = "target_intent";
public static void hookInstrumentation(Context context) throws Exception {
Class<?> contextImplClass = Class.forName("android.app.ContextImpl");
Object activityThread = ReflectUtil.getField(contextImplClass, context, "mMainThread");
Class<?> activityThreadClass = Class.forName("android.app.ActivityThread");
Object mInstrumentation = ReflectUtil.getField(activityThreadClass, activityThread, "mInstrumentation");
// 用代理Instrumentation來替換mMainThread中的mInstrumentation,從而接管Instrumentation的任務
ReflectUtil.setField(activityThreadClass, activityThread, "mInstrumentation", new InstrumentationProxy((Instrumentation) mInstrumentation, context.getPackageManager()));
}
}

Step3. 還原插件Activity

上面我們使用插樁Activity來繞過ASM的驗證,接下來的步驟會創建 StubActivity實例,會找不到類,并且我們要啟動的是插件Activity而不是插樁Activity,所以就需要對Intent進行還原。 在Activity啟動流程第10步,通過插件的ClassLoader反射創建插件Activity,所以可以在這hook進行還原。

public class InstrumentationProxy extends Instrumentation {
// ...
public Activity newActivity(ClassLoader cl, String className, Intent intent) throws IllegalAccessException, InstantiationException, ClassNotFoundException {
// 獲取插件Activity的類名
String intentName = intent.getStringExtra(HookHelper.TARGET_INTENT);
if (!TextUtils.isEmpty(intentName)) {
// 創建插件Activity實例
return super.newActivity(cl, intentName, intent);
}
return super.newActivity(cl, className, intent);
}
}

Step4. 在Application中hook Instrumentation。

public class App extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
try {
HookHelper.hookInstrumentation(base);
} catch (Exception e) {
e.printStackTrace();
}
}
}

處理插件Activity的生命周期

經過上面的處理后,插件Activity可以啟動了,但是是否具有生命周期呢?接下來通過源碼來探索一下。

Activity的 finish方法可以觸發Activity生命周期的變化。

public void finish() {
finish(DONT_FINISH_TASK_WITH_ACTIVITY);
}
private void finish(int finishTask) {
// ...
// mToken是該Activity的標識
if (ActivityManager.getService().finishActivity(mToken, resultCode, resultData, finishTask)) {
mFinished = true;
}
}

說明

  • 調用ASM的finishActivity方法,接著ASM通過ApplicationThread調用ActivityThread。
  • ActivityThread最終會調用performDestroyActivity方法。
public final class ActivityThread extends ClientTransactionHandler {
// ...
ActivityClientRecord performDestroyActivity(IBinder token, boolean finishing, int configChanges, boolean getNonConfigInstance, String reason) {
// 獲取保存到token的Activity
mInstrumentation.callActivityOnDestroy(r.activity);
}
}

token中的Activity是從何而來呢?解析來我們來看看ActivityThread的performLaunchActivity方法。

public final class ActivityThread extends ClientTransactionHandler {
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
// ...
activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);
r.activity = activity;
mActivities.put(r.token, r);
}
}

說明:在performLaunchActivity方法中,會將當前啟動的Activity放在token中的activity屬性,并將其置于mActivities中,而mInstrumentation的newActivity方法已經被我們hook了,所以該activity即為插件Activity,后續各個生命周期的調用都會通知給插件Activity。

加載插件中的資源

當插件Activity創建的時候會調用 setContentView通過id去操作布局,因為凡是通過id去獲取資源的方式都是通過 Resources去獲取的。但是宿主apk不知道到插件apk的存在,所以宿主Resources也無法加載插件apk的資源。因此需要為插件apk構建一個 Resources,然后插件apk中都通過這個Resource區獲取資源。

public class PluginHelper {
private static Resources sPluginResources;
public static void initPluginResource(Context context) throws Exception {
Class<AssetManager> clazz = AssetManager.class;
AssetManager assetManager = clazz.newInstance();
Method method = clazz.getMethod("addAssetPath", String.class);
method.invoke(assetManager, context.getExternalFilesDir("plugin").listFiles()[0].getAbsolutePath());
sPluginResources = new Resources(assetManager, context.getResources().getDisplayMetrics(), context.getResources().getConfiguration());
}
public static Resources getPluginResources() {
return sPluginResources;
}
}
public class App extends Application {
@Override
public Resources getResources() {
return PluginHelper.getPluginResources() == null ? super.getResources() : PluginHelper.getPluginResources();
}
}

說明:在Application中重寫 getResources,并返回插件的Resources,因為插件apk中的四大組件實際都是在宿主apk創建的,那么他們拿到的Application實際上都是宿主的,所以它們只需要通過 getApplication().getResources()就可以非常方便的拿到插件的Resource。

插件工程

插件工程比較簡單,就一個Activity。

public class PluginActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_plugin);
}
@Override
public Resources getResources() {
return getApplication() != null && getApplication().getResources() != null ? getApplication().getResources() : super.getResources();
}
}

說明:重寫 getResources方法,并返回插件Resources,因為需要通過插件Resources才能用id去操作資源文件。

測試

Step1. 將插件項目打包成apk;

Step2. 通過adb命令 adb push<local><remote>將apk推送到手機;

Step3. 宿主應用加載插件apk。

總結

插件化要處理的細節非常多,不僅要適配不同版本的Android系統,還要適配國產的各種ROM。要深入學習插件化的各種解決方案,可以去探索開源的插件化框架。

Android 9.0上Android開始對私有API的使用進行限制,所以后面插件化可能退出歷史主流,但是了解插件化涉及到的知識和技術,可以更好的理解Android系統。


我來說兩句
您需要登錄后才可以評論 登錄 | 立即注冊
facelist
所有評論(0)
領先的中文移動開發者社區
18620764416
7*24全天服務
意見反饋:[email protected]

掃一掃關注我們

Powered by Discuz! X3.2© 2001-2019 Comsenz Inc.( 粵ICP備15117877號 )

阿拉斯加垂钓APP下载
富豪配资 北京快乐8 刮刮乐 股票配资 福建36选7 000247股票行情 全部股票价格查询 意胜配资 老虎配资 鑫福网 吉林快三 易投配资 半全场 外盘股票配资 翻翻配资 圣农发展股票分析