private Element[] dexElements;
DexPathList(ClassLoader definingContext, String dexPath,
String librarySearchPath, File optimizedDirectory, boolean isTrusted) {
…
this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
suppressedExceptions, definingContext, isTrusted);
…
}
private static Element[] makeDexElements(List files, File optimizedDirectory,
List suppressedExceptions, ClassLoader loader, boolean isTrusted) {
Element[] elements = new Element[files.size()];
int elementsPos = 0;
for (File file : files) {
if (file.isDirectory()) {
elements[elementsPos++] = new Element(file);
} else if (file.isFile()) {
String name = file.getName();
DexFile dex = null;
if (name.endsWith(DEX_SUFFIX)) {
// Raw dex file (not inside a zip/jar).
try {
dex = loadDexFile(file, optimizedDirectory, loader, elements);
if (dex != null) {
elements[elementsPos++] = new Element(dex, null);
}
} catch (IOException suppressed) {
System.logE("Unable to load dex file: " + file, suppressed);
suppressedExceptions.add(suppressed);
}
} else {
try {
dex = loadDexFile(file, optimizedDirectory, loader, elements);
} catch (IOException suppressed) {
suppressedExceptions.add(suppressed);
}
if (dex == null) {
elements[elementsPos++] = new Element(file);
} else {
elements[elementsPos++] = new Element(dex, file);
}
}
} else {
System.logW("ClassLoader referenced unknown path: " + file);
}
}
return elements;
}
public Class findClass(String name, List suppressed) {
for (Element element : dexElements) {
DexFile dex = element.dexFile;
if (dex != null) {
Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
if (clazz != null) {
return clazz;
}
}
}
if (dexElementsSuppressedExceptions != null) {
suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
}
return null;
}
}
DexPathList构造方法被调用的时候其实就是通过makeDexElements方法把dexPath进行遍历，依次加载每个dex文件，然后通过数组Element[]存放，而在DexPathList类的findClass调用的时候，通过遍历Element[]的dex文件，在通过DexFile类的loadClassBinaryName()来加载类，如果不为空那么代表加载成功，并且返回class，否则返回null。
下面再来看一下基类的ClassLoader是如何实现的吧
public abstract class ClassLoader {
private final ClassLoader parent;
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException{
Class c = findLoadedClass(name);
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();
尾声
最后，我再重复一次，如果你想成为一个优秀的 Android 开发人员，请集中精力，对基础和重要的事情做深度研究。
对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。 整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。
最后想要拿高薪实现技术提升薪水得到质的飞跃。最快捷的方式，就是有人可以带着你一起分析，这样学习起来最为高效，所以为了大家能够顺利进阶中高级、架构师，我特地为大家准备了一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。
当你有了学习线路，学习哪些内容，也知道以后的路怎么走了，理论看多了总要实践的。
以上进阶BATJ大厂学习资料可以免费分享给大家，需要完整版的朋友，点这里可以看到全部内容。
-
自行下载直达领取链接：【GitHub】
进阶学习视频
附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题 （含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）
弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。
最后想要拿高薪实现技术提升薪水得到质的飞跃。最快捷的方式，就是有人可以带着你一起分析，这样学习起来最为高效，所以为了大家能够顺利进阶中高级、架构师，我特地为大家准备了一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。
当你有了学习线路，学习哪些内容，也知道以后的路怎么走了，理论看多了总要实践的。
以上进阶BATJ大厂学习资料可以免费分享给大家，需要完整版的朋友，点这里可以看到全部内容。
-
自行下载直达领取链接：【GitHub】
进阶学习视频
[外链图片转存中…(img-8AUzvKwY-1727085960146)]
附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题 （含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）
扫一扫
488
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
