2024年Android插件化探索与发现，2024年最新面试时手撕代码

最后

其实Android开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。

上面分享的腾讯、头条、阿里、美团、字节跳动等公司2019-2021年的高频面试题，博主还把这些技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，上面只是以图片的形式给大家展示一部分。

【Android思维脑图（技能树）】

知识不体系？这里还有整理出来的Android进阶学习的思维脑图，给大家参考一个方向。

【Android高级架构视频学习资源】

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

if (c == null) {

try {

if (parent != null) {

c = parent.loadClass(name, false);

} else {

c = findBootstrapClassOrNull(name);

}

} catch (ClassNotFoundException e) {

}

if (c == null) {

c = findClass(name);

}

}

return c;

}

}

这明显就是一个双亲委派模型，在类加载的时候，首先去查找这个类之前是否已经被加载过，如果加载过直接返回，否则委托父类加载器去查找，如果父类加载器找不到那么就去系统的BootstrapClass去查找，到最后还是找不到的话，那么就自己亲自上阵查找了。这样就避免了重复加载，实现了更加安全。

好了总结一下DexClassLoader的加载过程：loadClass->findClass->BaseDexClassLoader.findClass->DexPathList.findClass->loadDexFile->DexFile.loadClassBinaryName->DexFile.defineClass，大体上就这样么个过程吧。

资源加载

Android系统加载资源都是通过Resource资源对象来进行加载的，因此只需要添加资源（即apk文件）所在路径到AssetManager中，即可实现对插件资源的访问。

/**

• Create a new AssetManager containing only the basic system assets.

• Applications will not generally use this method, instead retrieving the

• appropriate asset manager with {@link Resources#getAssets}. Not for

• use by applications.

• @hide

*/

public AssetManager() {

final ApkAssets[] assets;

synchronized (sSync) {

createSystemAssetsInZygoteLocked();

assets = sSystemApkAssets;

}

mObject = nativeCreate();

if (DEBUG_REFS) {

mNumRefs = 0;

incRefsLocked(hashCode());

}

// Always set the framework resources.

setApkAssets(assets, false /invalidateCaches/);

}

不难发现AssetManager的构造方法是@hide隐藏的api，所以不能直接使用，这里肯定是需要通过反射啦，不过有人说Android P不是对系统的隐藏Api做出了限制，因此插件化估计要凉凉，但是我想说现在一些主流的插件化技术基本都已经适配了Android9.0了，所以无需担心。下面先简单贴出Android资源的加载流程。关于插件化的资源加载可以参考下滴滴VirtualApk资源的加载思想 （传送门）

class ContextImpl extends Context {

//…

private ContextImpl(ContextImpl container, ActivityThread mainThread,

LoadedApk packageInfo, IBinder activityToken, UserHandle user, boolean restricted,

Display display, Configuration overrideConfiguration) {

//…

Resources resources = packageInfo.getResources(mainThread);

//…

}

//…

}

这里不去关注packageInfo是如何生成的，直接跟踪到下面去.

public final class LoadedApk {

private final String mResDir;

public LoadedApk(ActivityThread activityThread, ApplicationInfo aInfo,

CompatibilityInfo compatInfo, ClassLoader baseLoader,

boolean securityViolation, boolean includeCode, boolean registerPackage) {

final int myUid = Process.myUid();

aInfo = adjustNativeLibraryPaths(aInfo);

mActivityThread = activityThread;

mApplicationInfo = aInfo;

mPackageName = aInfo.packageName;

mAppDir = aInfo.sourceDir;

mResDir = aInfo.uid == myUid ? aInfo.sourceDir : aInfo.publicSourceDir;

// 注意一下这个sourceDir，这个是我们宿主的APK包在手机中的路径，宿主的资源通过此地址加载。

// 该值的生成涉及到PMS,暂时不进行分析。

// Full path to the base APK for this application.

//…

}

//…

public Resources getResources(ActivityThread mainThread) {

if (mResources == null) {

mResources = mainThread.getTopLevelResources(mResDir, mSplitResDirs, mOverlayDirs,

mApplicationInfo.sharedLibraryFiles, Display.DEFAULT_DISPLAY, null, this);

}

return mResources;

}

//…

}

进入到ActivityThread.getTopLevelResources()的逻辑中

public final class ActivityThread {

Resources getTopLevelResources(String resDir, CompatibilityInfo compInfo) {

//我们暂时只关注下面这一段代码

AssetManager assets = new AssetManager();

if (assets.addAssetPath(resDir) == 0) { //此处将上面的mResDir，也就是宿主的APK在手机中的路径当做资源包添加到AssetManager里，则Resources对象可以通过AssetManager查找资源，此处见(老罗博客：Android应用程序资源的查找过程分析)

return null;

}

// 创建Resources对象，此处依赖AssetManager类来实现资源查找功能。

r = new Resources(assets, metrics, getConfiguration(), compInfo);

}

}

从上面的代码中我们知道了我们常用的Resources是如何生成的了，那么理论上插件也就按照如此方式生成一个Resources对象给自己用就可以了。

组件的加载

这个其实不能一概而论，因为Android拥有四大组件，分别为Activity、Service、ContentProvider、BoradCastRecevier，每个组件的属性及生命周期也不一样，所以关于插件中加载的组件就需要分别研究每个组件是如何加载的了。

简单拿Activity组件来说，现在一些主流的方式基本上都是通过“坑位”的思想，这个词最早据说也是来源于360，总的来说，先占坑，因为我们宿主app的Manifest中是不会去申请插件中的Activity的，那我就先占一个坑，欺骗系统，然后替换成插件中的Activity。这里可能需要多个坑位，因为一些资源属性都是可以动态配置的。比如launchMode、process、configChanges、theme等等。

这里还需要了解一下Activity的启动流程，这里我们可以简单看一下。

@Override

public void startActivity(Intent intent, @Nullable Bundle options) {

if (options != null) {

startActivityForResult(intent, -1, options);

} else {

// Note we want to go through this call for compatibility with

// applications that may have overridden the method.

startActivityForResult(intent, -1);

}

}

可以看出，我们平时startActivity其实都是通过调用startActivityForResult（），我们接下来继续看

public void startActivityForResult(@RequiresPermission Intent intent, int requestCode,

@Nullable Bundle options) {

if (mParent == null) {

options = transferSpringboardActivityOptions(options);

Instrumentation.ActivityResult ar =

mInstrumentation.execStartActivity(

this, mMainThread.getApplicationThread(), mToken, this,

intent, requestCode, options);

if (ar != null) {

mMainThread.sendActivityResult(

mToken, mEmbeddedID, requestCode, ar.getResultCode(),

ar.getResultData());

}

if (requestCode >= 0) {

mStartedActivity = true;

}

cancelInputsAndStartExitTransition(options);

// TODO Consider clearing/flushing other event sources and events for child windows.

} else {

if (options != null) {

mParent.startActivityFromChild(this, intent, requestCode, options);

} else {

// Note we want to go through this method for compatibility with

// existing applications that may have overridden it.

mParent.startActivityFromChild(this, intent, requestCode);

}

}

}

我们可以看到是通过系统的Instrumentation这个类execStartActivity（）来执行启动Activity的，我们继续可以看到下面的这个方法：

public ActivityResult execStartActivity(

、、、、、

try {

intent.migrateExtraStreamToClipData();

intent.prepareToLeaveProcess(who);

int result = ActivityManager.getService()

.startActivity(whoThread, who.getBasePackageName(), intent,

intent.resolveTypeIfNeeded(who.getContentResolver()),

token, target != null ? target.mEmbeddedID : null,

requestCode, 0, null, options);

checkStartActivityResult(result, intent);

} catch (RemoteException e) {

throw new RuntimeException(“Failure from system”, e);

}

return null;

}

/**

• @hide

*/

public static IActivityManager getService() {

return IActivityManagerSingleton.get();

}

private static final Singleton IActivityManagerSingleton =

new Singleton() {

@Override

protected IActivityManager create() {

final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);

final IActivityManager am = IActivityManager.Stub.asInterface(b);

return am;

}

};

ActivityManager.getService()拿到IActivityManager对象，然后就去调用startActivity（）了，而IActivityManager只是一个抽象接口，下面看看它的实现类

public abstract class ActivityManagerNative extends Binder implements IActivityManager

public final class ActivityManagerService extends ActivityManagerNative

implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback

class ActivityManagerProxy implements IActivityManager

可以看到它的两个实现类ActivityManagerProxy与ActivityManagerService，简称AMP与AMS，AMP只是AMS的本地代理对象，其startActivity方法会调用到AMS的startActivity方法。而且要注意，这个startActivity方法会把ApplicationThread对象传递到AMS所在进程，当然AMS拿到的实际上是ApplicationThread的代理对象ApplicationThreadProxy，AMS就要通过这个代理对象与我们的App进程进行通信。

既然Activity是否存在的校验是发生在AMS端，那么我们在与AMS交互前，提前将Activity的ComponentName进行替换为占坑的名字，选择hook Instrumentation或者ActivityManagerProxy应该都是可以的，然后Activity经过复杂的启动流程后最终会执行Instrumentation的newActivity（），这里我们可以进行还原成插件的Activity。

public Activity newActivity(Class<?> clazz, Context context,

IBinder token, Application application, Intent intent, ActivityInfo info,

CharSequence title, Activity parent, String id,

Object lastNonConfigurationInstance) throws InstantiationException,

IllegalAccessException {

Activity activity = (Activity)clazz.newInstance();

ActivityThread aThread = null;

// Activity.attach expects a non-null Application Object.

if (application == null) {

application = new Application();

}

activity.attach(context, aThread, this, token, 0 /* ident */, application, intent,

info, title, parent, id,

(Activity.NonConfigurationInstances)lastNonConfigurationInstance,

new Configuration(), null /* referrer /, null / voiceInteractor */,

null /* window /, null / activityConfigCallback */);

return activity;

}

关于插件化四大组件的加载原理过于复杂，我只简单的描述了一下插件化的思想，如果想看具体的思想流程，也可以查看滴滴VirtualApk的组件加载原理，插件化思想都有共通之处（传送门）

关于插件化方案的选取

如果你在做插件化，或者想去研究插件化，上面看不懂没有关系，反正市场上已经拥有非常多的成熟方案，下面是从万千的方案中挑取较好的几个方案，以免走更多的弯路，毕竟我也是从茫茫的插件化方案中走了一遭。

• VirtualApk 滴滴插件化方案，功能非常强大，而且兼容性强，目前已经适配Android 9.0，如果项目插件和宿主存在依赖的话是个不错的选择。

• DroidPlugin 360的一款插件化方案，最大的特色就是插件独立，不依赖宿主，当然就无耦合啦

• RePlugin 360另外一款插件化方案，它与DroidPlugin代表2个不同方向，各个功能模块能独立升级，又能需要和宿主、插件之间有一定交互和耦合。

• Shadow 腾讯最近刚开源的插件化方案，最大特色零反射，核心库采取Kotlin实现，个人觉得以后是个不错的选择，但是因为刚开源，还未受到大众的检测。

• VirtualApp 罗盒科技的一款运行于Android系统的沙盒产品，可以理解为轻量级的“Android虚拟机”，非常的牛，广泛应用于插件化开发、无感知热更新、云控自动化、多开、手游租号、手游手柄免激活、区块链、移动办公安全、军队政府保密、手机模拟信息、脚本自动化、自动化测试等技术领域，最大的特色app双开及多开，沙盒能力，内外隔离。不过2017已经商业化了。

滴滴插件化尝鲜

VirtualAPK的工作过程

VirtualAPK对插件没有额外的约束，原生的apk即可作为插件。插件工程编译生成apk后，即可通过宿主App加载，每个插件apk被加载后，都会在宿主中创建一个单独的LoadedPlugin对象。如下图所示，通过这些LoadedPlugin对象，VirtualAPK就可以管理插件并赋予插件新的意义，使其可以像手机中安装过的App一样运行。

如何使用

第一步：宿主Project的build.gradle添加

dependencies {

classpath ‘com.didi.virtualapk:gradle:0.9.8.6’

}

第二步：宿主的Moudle的build.gradle添加

apply plugin: ‘com.didi.virtualapk.host’

implementation ‘com.didi.virtualapk:core:0.9.8’

第三步：宿主app的Applicaiton中添加初始化：

@Override

protected void attachBaseContext(Context base) {

super.attachBaseContext(base);

PluginManager.getInstance(base).init();

}

第四步：增加混淆：

-keep class com.didi.virtualapk.internal.VAInstrumentation { *; }

-keep class com.didi.virtualapk.internal.PluginContentResolver { *; }

-dontwarn com.didi.virtualapk.**

-dontwarn android.**

-keep class android.** { *; }

第五步：宿主的使用：

String pluginPath = Environment.getExternalStorageDirectory().getAbsolutePath().concat(“/Test.apk”);

File plugin = new File(pluginPath);

PluginManager.getInstance(base).loadPlugin(plugin);

// Given “com.didi.virtualapk.demo” is the package name of plugin APK,

// and there is an activity called MainActivity.

Intent intent = new Intent();

intent.setClassName(“com.didi.virtualapk.demo”, “com.didi.virtualapk.demo.MainActivity”);

startActivity(intent);

第六步：插件的Project的build.gradle配置：

dependencies {

classpath ‘com.didi.virtualapk:gradle:0.9.8.6’

}

第七步：插件app的build.gradle配置：

最后

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长。而不成体系的学习效果低效漫长且无助。时间久了，付出巨大的时间成本和努力，没有看到应有的效果，会气馁是再正常不过的。

所以学习一定要找到最适合自己的方式，有一个思路方法，不然不止浪费时间，更可能把未来发展都一起耽误了。

如果你是卡在缺少学习资源的瓶颈上，那么刚刚好我能帮到你。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

ity called MainActivity.

Intent intent = new Intent();

intent.setClassName(“com.didi.virtualapk.demo”, “com.didi.virtualapk.demo.MainActivity”);

startActivity(intent);

第六步：插件的Project的build.gradle配置：

dependencies {

classpath ‘com.didi.virtualapk:gradle:0.9.8.6’

}

第七步：插件app的build.gradle配置：

最后

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长。而不成体系的学习效果低效漫长且无助。时间久了，付出巨大的时间成本和努力，没有看到应有的效果，会气馁是再正常不过的。

所以学习一定要找到最适合自己的方式，有一个思路方法，不然不止浪费时间，更可能把未来发展都一起耽误了。

如果你是卡在缺少学习资源的瓶颈上，那么刚刚好我能帮到你。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！