原始链接：https://lyldalek.notion.site/Shadow-d400c1584e8541779ca6ebf6ffe35192 欢迎评论！
其一
项目编译问题
首先这个工程是可以直接在命令行
build的，但是我的台式机（windows）sync/rebuild等可能会有一些奇葩问题后来又发现我的笔记上
clone一个新的项目没有以下问题，神奇！！！
-
GBK 编码问题，
gradle build可以通过，然后再次sync就没问题了… -
projects - sdk下找不到android.jar中的代码问题，咨询了作者暂时不知道问题在哪里，其核心代码逻辑在CommonJarSettingsPlugin里面的project.dependencies.add("compileOnly", androidJar)**，但是没生效，试了下，直接在 dependence 里面使用也不行，但是将android.jar拷贝到工程目录下就可以了，所以临时解决方案就是拷贝改文件，然后将这个路径写死，再 attach 一下 source 即可。 -
DocumentBuilderFactory.newDefaultInstance()报错问题，有的设置了 jdk 为 11 就行，可以看项目里面的 issue。但是我这不行，改成DocumentBuilderFactory.newInstance()即可。
项目结构概览
红框部分：
sample-constant是一些字符串常量（host 与 plugin 通用）。
sample-host是宿主应用。
sample-manager是插件管理器的动态实现。
绿框部分：
sample-plugin/sample-loader是loader的动态实现，业务主要在这里定义插件组件和壳子代理组件的配对关系等。
sample-plugin/sample-runtime是runtime的动态实现，业务主要在这里定义壳子代理组件的实际类。
sample-plugin/sample-base-lib是插件App的一部分基础代码，是一个aar库。
sample-plugin/sample-base是一个apk模块壳子，将sample-base-lib打包在其中。既用于正常安装运行开发sample-base-lib 。sample-plugin/sample-app是依赖sample-base-lib开发的更多业务代码。它编译出的插件apk没有打包sample-base-lib ，会在插件运行时依赖sample-base插件。
黄框部分：
coding 处理模板代码生成，android.jar 等问题（因为 module 使用的是 java-library）。
core 核心代码。
dynamic 动态相关实现（manager，loader，runtime）都是动态的。
这一块是通过 includeBuild 来进行编译的。
插件内容说明
宿主发布出去后，可以动态更新两部分内容。
可以看到宿主有两个插件包，一个是 pluginmanager.apk，这个是属于宿主的，也可以动态更新。一个是 plugin.zip，这个就是纯插件内容，里面包含 loader/runtime，还有业务相关的 app 与 base 内容。
其二
全动态框架
插件部分自然不用说，当然是动态的。全动态的意思是插件框架本身设计的也是动态的。
这里我们介绍一个前置知识：
Java编译的字节码中保存的就是其他类的名称，其他类的实现是在运行时才去查找的。所以Java是一个“动态”语言。Java有两个和动态化相关的特性，一个是接口，另一个是向上转型：
Class<?> implClass = classLoader.loadClass("com.xxx.AImpl");
Object implObject = implClass.newInstance();
A a = (A) implObject;
使用上面的方式，我们就可以先定义出接口，精心设计接口，让接口足够通用和稳定。只要接口不变，它的实现总是可以修改的。我们将接口打包在宿主中，接口就轻易不能更新了。但是它的实现总是可以更新的。
所有的插件框架在解决的问题都不是如何动态加载类，而是解决动态加载的Activity没有在AndroidManifest中注册，该如何能正常运行的问题。如果Android系统没有AndroidManifest的限制，那么所有插件框架都没有存在的必要了。因为Java语言本身就支持动态更新实现的能力。
这也就是为什么几乎所有的插件化框架，都在到处找 hook 点来欺骗系统。这种插件化框架即使是开源的，看起来也很令人蛋疼，因为它的知识点很偏。一般人的知识范围是一个圆，这些知识点就完全在圆外面，而且还是散开的，就算你看了一遍，当时想通了，过不了多久也会忘记，因为这些知识点与你现有的知识链接的很弱，跟一条蛛丝一样，想要完全搞懂，你需要一条高速公路的链接，所以，通常写这个框架的人才能真正搞懂里面的东西，而看这个框架的人学不到什么东西。
但是 shadow 相对而言就好得多，它没有 hook 点，不需要你去翻源码搞清楚每个点为啥要 hook，甚至是翻每个版本的源码差异来搞清楚里面的每个 if-elseif 的作用。在这里我们可以专心的深入架构设计，顺便看一下插件加载与运行的流程。本篇虽然是深入理解，但是并不会每个细节都讲到，正如前面所说的，有些逻辑如果自己没有遇到过，基本是搞不明白为啥要这样写的，写插件化框架的人也是一个一个坑踩出来的。
有了前置知识，我们来看看如何实现插件框架的动态化。首先，插件框架分为3大部分：
-
manager
-
runtime
-
loader
核心有3大部分，但是能动态化的只有两部分，一个是 manager，一个是 loader。除此之外，还有一个 container 也是动态的。
Manager
Manager 负责管理插件，包括插件的下载逻辑、入口逻辑，预加载逻辑等。由于Manager就是一个普通类，不是Android系统规定要在Manifest中注册才能使用的类，所以Manager的动态化就是一般性的动态加载实现。
上面这个工程就是我们开发一个插件的时候，Manager 具体的实现，逻辑很简单，继承 PluginManagerThatUseDynamicLoader ，实现一个自己的 Manager就行。实际上 FastPluginManager 里面基本上也是模板代码，所以最终我们只需要实现一下 SamplePluginManager 。其核心方法是：
/**
* @return 宿主中注册的PluginProcessService实现的类名
*/
@Override
protected String getPluginProcessServiceName(String partKey) {
if (PART_KEY_PLUGIN_MAIN_APP.equals(partKey)) {
return "com.tencent.shadow.sample.host.PluginProcessPPS";
} else if (PART_KEY_PLUGIN_BASE.equals(partKey)) {
return "com.tencent.shadow.sample.host.PluginProcessPPS";
} else if (PART_KEY_PLUGIN_ANOTHER_APP.equals(partKey)) {
return "com.tencent.shadow.sample.host.Plugin2ProcessPPS";//在这里支持多个插件
} else {
//如果有默认PPS，可用return代替throw
throw new IllegalArgumentException("unexpected plugin load request: " + partKey);
}
}
这个方法的作用就是要声明 插件 与 宿主里面的Service 的对应关系。
宿主声明的 service 如下：
<service
android:name="com.tencent.shadow.sample.host.PluginProcessPPS"
android:process=":plugin" />
插件一般是运行在一个单独的进程，也可以多个插件运行在一个进程。比如 sample 里面的，将一个业务插件拆成了两部分，一个是 base，一个 main-app，这虽然是两个插件包，但是实际上是一个业务整体，这两个插件运行在同一个进程。
回到 manager 部分，我们实现了 SamplePluginManager 后，打包成一个插件apk，发布出去。那么宿主需要将这个 manager 插件加载进来，其流程相当简单：
// 这里的 apk 参数就是 manager 插件 apk 的路径
Shadow.getPluginManager(apk);
这里的调用链如下：
com.tencent.shadow.test.dynamic.host.manager.Shadow#getPluginManager
com.tencent.shadow.dynamic.host.DynamicPluginManager#DynamicPluginManager
会实例化一个 DynamicPluginManager 出来，这个类主要处理pluginManager的动态升级问题。由两部分构成，一个是PluginManagerUpdater，一个是PluginManagerImpl。PluginManagerUpdater就是去查询是否有更新插件apk的存在，有就去加载这个对应的文件。PluginManagerImpl 就是我们写的 SamplePluginManager，是通过 ManagerImplLoader 来获取的。细节就是使用工厂模式去实例化一个com.tencent.shadow.dynamic.impl.ManagerFactoryImpl对象出来。这个类名是固定的，我们的 Manager 插件包里面必须包含这个类，然后里面返回我们的 SamplePluginManage。
/**
* 此类包名及类名固定
*/
public final class ManagerFactoryImpl implements ManagerFactory {
@Override
public PluginManagerImpl buildManager(Context context) {
return new SamplePluginManager(context);
}
}
这样流程就清楚了，我们看一下 ManagerImplLoader 的核心实现：
PluginManagerImpl load() {
// 创建 manager 插件的 classLoader，就是一个普通的 classLoder，只不过支持访问在白名单里面的宿主类
ApkClassLoader apkClassLoader = new ApkClassLoader(...);
// 这个 context 传递给了 SamplePluginManager，里面做了资源等的替换
Context pluginManagerContext = new ChangeApkContextWrapper(...);
try {
ManagerFactory managerFactory = apkClassLoader.getInterface(...);
return managerFactory.buildManager(pluginManagerContext);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
Loader
Loader就是负责加载插件Activity，然后实现插件Activity的生命周期等功能的那部分核心逻辑了。Loader 的动态化稍微蛋疼一些，虽然核心流程与Manager类似，但是由于loader与插件的依赖关系较为强烈，比如代理壳子PluginContainerActivity需要和PluginActivity通过Loader相互调用。所以Shadow应用前面提到的动态化原理时，做了双向的接口，可以看到代码中的HostActivityDelegate和HostActivityDelegator。通过定义出这两个接口，可以避免PluginContainerActivity和Loader相互加载对方时还需要加载对方所依赖的其他类。定义成接口，就只需要加载这个接口就行了。
我们举个例子说明一下，看一下 PluginContainerActivity 的代码，它是插件的一部分：
public PluginContainerActivity() {
HostActivityDelegate delegate;
DelegateProvider delegateProvider = DelegateProviderHolder.getDelegateProvider(getDelegateProviderKey());
if (delegateProvider != null) {
delegate = delegateProvider.getHostActivityDelegate(this.getClass());
delegate.setDelegator(this);
} else {
Log.e(TAG, "PluginContainerActivity: DelegateProviderHolder没有初始化");
delegate = null;
}
super.hostActivityDelegate = delegate;
hostActivityDelegate = delegate;
}
如果没有HostActivityDelegate 这个接口，那么这里必然要先一个具体的实现类，也就是 ShadowActivityDelegate ，而这个类是在 loader 中的，所以插件就与 loader 强关联了。我们需要尽可能的让 loader 单独加载。
通过定义接口进行解耦，是很常见的一种方式，正所谓，计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。后面我们还会遇到同样的设计方式。
loader 插件工程的结构几乎与manager 插件工程一样，不做过多介绍。
Runtime
runtime 实际上不能动态化，因为它必须和插件绑定在一起。从 sample 工程可以看出，动态化的是 container：
里面实际上就是那些注册在宿主AndroidManifest中的代理壳子。由于Activity的创建是系统根据Activity的名字直接通过宿主的PathClassLoader构造的，所以这些Activity必须打包在宿主中才能处于PathClassLoader，才能被系统找到。
之所以要做这个设计，是因为tencent业务的宿主对合入代码的增量要求极其严格，是要求0增量合入的。而 代理壳子Activity上需要提前Override非常多的方法。同时由于定义了Delegate和Delegator接口，还在Delegator接口上又添加了superOnCreate等方法，导致Activity上每有一个需要Override的方法，就要增加4个方法数，而Activity上大概有350个方法。
所以就迫于无奈做了Container的动态化，通过修改ClassLoader的parent，为ClassLoader新增一个parent。将原本的BootClassLoader <- PathClassLoader结构变为BootClassLoader <- DexClassLoader <- PathClassLoader，插入的DexClassLoader加载了ContainerActivity就可以使得系统在向PathClassLoader查找ContainerActivity时能够正确找到实现。这里在这个动态化中使用了唯一一次反射修改私有变量。
需要注意的是，工程的清单文件里面是没有Activity的声明的，是在宿主里面声明的。
其三
一直到这里，都比较简单，因为没设计到生命周期等问题，我们只需要把类加载进来就好了。下面我们就开始分析Shadow 是如何处理Activity 的生命周期问题的。
其实实现原理属于一层窗户纸，一捅就破了。重要的在于思路上的转变。以前的插件框架总是想用一些Hack手段去修改系统行为，找到系统的漏洞达到目的。Shadow的原则是不去跟系统对抗。
如果一个组件需要安装才能使用，那么就别在没安装的情况下把它交给系统。只要我们不说谎，不去欺骗系统，那就不用去到处堵漏洞，做一些Hack的事情。
所以套一个壳子的方案就非常好。这种思路其他框架很早就有了，但是它们一直想把一个插件Activity套在一个宿主Activity之中，然后想办法实现一个转调关系。如果插件Activity是一个真的Activity，那这个插件就可以正常编译安装运行，对开发插件或者直接上架插件App非常有利。
但是由于它是个系统的Activity子类，它就有很多方法不能直接调用，甚至还可能需要避免它的super方法被调用。如果插件Activity不是一个真的Activity，只是一个跟Activity有差不多方法的普通类，这件事就简单多了，只需要让壳子Activity持有它，转调它就行了。但这种插件的代码正常编译成独立App安装运行会比较麻烦，代码中可能会出现很多插件相关的if-else，也不好。
Shadow做了一个非常简单事，通过运用AOP思想，利用字节码编辑工具，在编译期把插件中的所有Activity的父类都改成一个普通类，然后让壳子持有这个普通类型的父类去转调它就不用Hack任何系统实现了。虽然说是非常简单的事，实际上这样修改后还带来一些额外的问题需要解决，比如getActivity()方法返回的也不是Activity了。不过Shadow的实现中都解决了这些问题。
Activity
插件Activity的onCreate方法的代码就相当于是壳子Activity的onCreate方法的代码的一部分了。比如：
class ShadowActivity {
public void onCreate(Bundle savedInstanceState) {
}
}
class PluginActivity extends ShadowActivity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
System.out.println("Hello World!");
}
}
class ContainerActivity extends Activity {
ShadowActivity pluginActivity;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
pluginActivity.onCreate(savedInstanceState);
}
}
但是有一个问题，如果插件里面的代码在 Activity 的 super.onCreate(savedInstanceState); 之前有逻辑的话，就会出问题：
class PluginActivity extends ShadowActivity {
@Override
public void onCreate(Bundle savedInstanceState) {
savedInstanceState.clear();
super.onCreate(savedInstanceState);
}
}
显然这种代码在正常安装运行时和插件环境运行时就不一样了。因为变成了：
class ContainerActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
savedInstanceState.clear();
}
}
我刚开始想的是给 ShadowActivity 加几个方法，比如 ：beforeOnCreate 等等，但是 Shadow 的做法更好些。
我们要的不是插件Activity的super.onCreate()调用不执行，我们是希望插件Activity的super.onCreate()能够直接指挥壳子Activity什么时候调用super.onCreate()。
假如PluginActivity是继承自ContainerActivity的，运行时系统调用的是PluginActivity的实例，那么PluginActivity的super.onCreate()就会直接指导ContainerActivity什么时候调用super.onCreate()了。
所以我们在这里的真正需求是如何把原本的继承关系用持有关系实现了。所以Shadow是这样实现的：
class ShadowActivity {
ContainerActivity containerActivity;
public void onCreate(Bundle savedInstanceState) {
containerActivity.superOnCreate(savedInstanceState);
}
}
class PluginActivity extends ShadowActivity {
@Override
public void onCreate(Bundle savedInstanceState) {
savedInstanceState.clear();
super.onCreate(savedInstanceState);
}
}
class ContainerActivity extends Activity {
ShadowActivity pluginActivity;
@Override
protected void onCreate(Bundle savedInstanceState) {
pluginActivity.onCreate(savedInstanceState);
}
public void superOnCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
}
}
这里我们就又用到中间层，计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。
Shadow实际的选择不是一个单纯的类而已，而是一个继承至 ContextThemeWrapper 的类，因为这样可以很轻松的处理文件相关的问题，比如在插件里面使用了 sp，那么sp应该储存到插件目录下，而不是宿主目录下，具体可看 SubDirContextThemeWrapper。还有就是 Activity 本身就是一个 context，它不过是通过AMS有了生命周期，那么我们继承 context，将生命周期委托给宿主壳子也非常的合适，覆写一些方法，处理插件的资源加载/so加载/classLoader等问题。
发现一个问题，就是 Shadow 的设计里面非常频繁的使用了继承，将一个抽象类的职责尽可能的单一化，但是继承关系长了之后，带来的阅读性下降很多。而且有些抽象类就只是为了单一职责，没有第二个继承它的。会不会使用组合会更好点呢。
Fragment
里面的 getActivity 等方法，通过 FragmentSupportTransform 的变换后，都变成了 com.tencent.shadow.core.runtime.ShadowFragmentSupport#fragmentGetActivity 这个方法。
里面的 onAttach(Activity) 等方法：
@Override
public void onAttach(Activity activity) {
super.onAttach(activity);
}
运行时，这里的 activity 显然是 PluginContainerActivity，而逻辑上我们是把它当作 PluginActivity 的，编译时还让他继承了 ShadowActivity。所以需要做一个转换，简单来说，编译后变成了这样：
private void superOnAttach(ShadowActivity shadowActivity) {
super.onAttach((Activity) ShadowFragmentSupport.toOriginalContext(shadowActivity));
}
@Override // android.app.Fragment
public void onAttach(Activity activity) {
onAttachShadowActivity((ShadowActivity) ShadowFragmentSupport.toPluginContext(activity));
}
private void onAttachShadowActivity(ShadowActivity activity) {
superOnAttach(activity);
}
Service
service 的处理很简单，由于插件的 service 都是走到了 ShadowContext 的对应方法：
@Override
public boolean bindService(Intent service, ServiceConnection conn, int flags) {
..
Pair<Boolean, Boolean> ret = mPluginComponentLauncher.bindService(this, service, conn, flags);
...
}
最终会走到 PluginServiceManager 的方法里面：
fun bindPluginService(intent: Intent, conn: ServiceConnection, flags: Int): Boolean {
...
val service = createServiceAndCallOnCreate(intent)
...
mServiceBinderMap[componentName] = service.onBind(intent)
...
// 回调onServiceConnected
conn.onServiceConnected(componentName, it)
...
}
所以这里是将 service 当成了一个普通类。当然 Transform 阶段也做了一些事情，具体看 ShadowService。可以想到，插件里面的Service不支持多进程，因为插件本来就是一个进程了。
ContentProvider
ContentProvider 的处理采用的是转发的方式，就是宿主声明了一个 Provider：
<provider
android:authorities="${applicationId}.contentprovider.authority.dynamic"
android:name="com.tencent.shadow.core.runtime.container.PluginContainerContentProvider"
android:grantUriPermissions="true"
android:process=":plugin" />
对于插件中的 ContentProvider 的 url，将涉及到 url 解析的方法都重定向了一下，让他们都走到 PluginContentProviderManager 里面的方法去：
override fun parse(uriString: String): Uri {
if (uriString.startsWith(CONTENT_PREFIX)) {
val uriContent = uriString.substring(CONTENT_PREFIX.length)
val index = uriContent.indexOf("/")
val originalAuthority = if (index != -1) uriContent.substring(0, index) else uriContent
val containerAuthority = getContainerProviderAuthority(originalAuthority)
if (containerAuthority != null) {
return Uri.parse("$CONTENT_PREFIX$containerAuthority/$uriContent")
}
}
return Uri.parse(uriString)
}
这里就相当于将插件 ContentProvider 的 Authority 改成了宿主的 Authority，就会走到宿主的 ContentProvider 的逻辑，由他来负责分发。
ShadowContentProviderDelegate 又会将 Authority 替换为插件的，最终走到 PluginContentProviderManager 里面的方法，然后和Service的处理一样。
BroadcastReceiver
广播的实现也比较常规，在插件中动态注册和发送广播，直接调用系统的方法即可，因为广播不涉及生命周期等复杂的内容。需要处理的就是在 Manifest 中静态注册的广播。
因为插件是我们自己编译的，所以在编译的时候，我们可以获取到四大组件的所有信息，然后将这写信息写入一个类（com.tencent.shadow.core.manifest_parser.PluginManifest）里面，放入到插件包一起编译。这样加载插件的时候。我们直接 load 这个类，就知道有哪些 Receiver 了，我们直接全部动态注册一下就ok了。
for (Map.Entry<String, String[]> entry : mBroadcasts.entrySet()) {
try {
String receiverClassname = entry.getKey();
BroadcastReceiver receiver = mAppComponentFactory.instantiateReceiver(
mPluginClassLoader,
receiverClassname,
null);
IntentFilter intentFilter = new IntentFilter();
String[] receiverActions = entry.getValue();
if (receiverActions != null) {
for (String action : receiverActions) {
intentFilter.addAction(action);
}
}
registerReceiver(receiver, intentFilter);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
系统回调BroadcastReceiver的onReceive(Context context, Intent intent)方法时，还有需要处理的地方，具体逻辑见 ReceiverSupportTransform：
-
传回的context是宿主的，需要修改为插件的。
-
intent的ExtrasClassLoader是宿主的，需要改为插件的。
其四
插件的启动流程。
首先，点击宿主的一个按钮：
Intent intent = new Intent(MainActivity.this, PluginLoadActivity.class);
intent.putExtra(Constant.KEY_PLUGIN_PART_KEY, PART_KEY_PLUGIN_BASE);
intent.putExtra(Constant.KEY_ACTIVITY_CLASSNAME, "com.tencent.shadow.sample.plugin.app.lib.gallery.splash.SplashActivity");
可以看到，是通过 PluginLoadActivity 做了二次处理。指定了要启动哪个插件，以及插件的哪个页面。
PluginLoadActivity 里面开了一个单线程线程池去处理：
// 获取到 Manager，因为我们的 Manager 是动态的，需要加载
HostApplication.getApp().loadPluginManager(PluginHelper.getInstance().pluginManagerFile);
// 指定插件包的位置，插件包里面的哪个插件，插件里面的页面
Bundle bundle = new Bundle();
bundle.putString(Constant.KEY_PLUGIN_ZIP_PATH, PluginHelper.getInstance().pluginZipFile.getAbsolutePath());
bundle.putString(Constant.KEY_PLUGIN_PART_KEY, getIntent().getStringExtra(Constant.KEY_PLUGIN_PART_KEY));
bundle.putString(Constant.KEY_ACTIVITY_CLASSNAME, getIntent().getStringExtra(Constant.KEY_ACTIVITY_CLASSNAME));
// 调用了 Manager 的 enter 方法，这里有一个回调，主要用来展示一个 loading 页面
// loading 页面是 Manager 插件包里面的资源，因为 Manager 管理插件的入口
HostApplication.getApp().getPluginManager()
.enter(PluginLoadActivity.this, Constant.FROM_ID_START_ACTIVITY, bundle, new EnterCallback() {
}
然后会进入到 SamplePluginManager 里面的 onStartActivity 方法：
// mCurrentContext 是 Manager 插件的 context
final View view = LayoutInflater.from(mCurrentContext).inflate(R.layout.activity_load_plugin, null);
// 触发回调
callback.onShowLoadingView(view);
// 下面的逻辑运行在一个单线程线程池里面
// 安装插件
InstalledPlugin installedPlugin = installPlugin(pluginZipPath, null, true);
// 可以看到，如果多个插件有依赖关系，需要手动处理加载顺序，
// 这里就先加载了 base 插件，然后加载 main-app 插件。
// 加载完插件之后，调用插件 application 的 onCreate 方法，这样插件就跑起来了。
loadPlugin(installedPlugin.UUID, PART_KEY_PLUGIN_BASE);
loadPlugin(installedPlugin.UUID, PART_KEY_PLUGIN_MAIN_APP);
callApplicationOnCreate(PART_KEY_PLUGIN_BASE);
callApplicationOnCreate(PART_KEY_PLUGIN_MAIN_APP);
// application 处理完毕后，还需要启动目标插件 activity
Intent intent = mPluginLoader.convertActivityIntent(pluginIntent);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
mPluginLoader.startActivityInPluginProcess(intent);
上面的逻辑中，installPlugin 与 loadPlugin 与 callApplicationOnCreate 与 startActivityInPluginProcess 都要细说，我们一个一个道来。
installPlugin
首先将插件包里面的 loader 与 runtime 两个插件包进行 odex 处理：
// ODexBloc 的命名是仿的 dart ？？？
ODexBloc.oDexPlugin(apkFile, oDexDir, AppCacheFolderManager.getODexCopiedFile(oDexDir, key));
里面的处理很简单，而且只对 27 一下才有效，就是用一个 DexClassLoader 加载一下这个插件包就好了，指定一下 odex 的路径，里面会自动触发 odex 优化。
然后将其他业务插件的 so 解压出来，注意这里将所有的业务插件的 so 都放入到了同一个目录：
// so 解压路径 ShadowPluginManager/UnpackedPlugin/test-dynamic-manager/lib/${uuid}/xxx.so
CopySoBloc.copySo(apkFile, soDir, AppCacheFolderManager.getLibCopiedFile(soDir, partKey), filter);
copy so 的时候，是先查询宿主支持哪个，具体可看 getPluginSupportedAbis ，然后只解压插件对应的 so。最后对每个业务插件也做一下 odex。这样插件就安装好了。
loadPlugin
首先启动插件进程，就是 bind 一个宿主的 service，也就是 PluginProcessPPS。想要指定哪个插件对应哪个进程，可以覆写 FastPluginManager的 getPluginProcessServiceName 方法。
把这个 service 返回的 IBinder，经过包装后变为 ：
mPpsController = PluginProcessService.wrapBinder(service);
所以，mPpsController 就是一个 IBinder，用来与 PluginProcessPPS 通信的。
那么为啥要包一下呢？是因为，PpsController 是手写了AIDL 相关的代码，那么为啥要手写呢？因为在此基础上做了一些异常的处理，比如：
public void loadRuntime(String uuid) throws RemoteException, FailedException {
Parcel _data = Parcel.obtain();
Parcel _reply = Parcel.obtain();
try {
_data.writeInterfaceToken(PpsBinder.DESCRIPTOR);
_data.writeString(uuid);
mRemote.transact(PpsBinder.TRANSACTION_loadRuntime, _data, _reply, 0);
int i = _reply.readInt();
if (i == TRANSACTION_CODE_FAILED_EXCEPTION) {
throw new FailedException(_reply);
} else if (i != TRANSACTION_CODE_NO_EXCEPTION) {
throw new RuntimeException("不认识的Code==" + i);
}
} finally {
_reply.recycle();
_data.recycle();
}
}
可以看到都是 AIDL 的模板代码，只不过是多了一些异常的处理。
拿到了 Service 的 Binder 之后，又通过这个 Binder 获取了另外一个 Binder：
IBinder iBinder = mPpsController.getPluginLoader();
mPluginLoader = new BinderPluginLoader(iBinder);
所以，mPluginLoader 也是一个Binder的包装，它最终会调用到 Service 进程的 DynamicPluginLoader 类里面去。
插件的加载核心流程都在 DynamicPluginLoader 里面，所以通过传递 Binder 的方式，提供一些接口方法给宿主调用，触发插件的加载。
mPpsController 提供负责加载 loader 与 runtime 的接口。
mPpsController.loadRuntime(uuid);
mPpsController.loadPluginLoader(uuid);
mPpsController.loadRuntime(uuid);说的是加载，实际只是处理了一下 ClassLoader，核心逻辑在 DynamicRuntime.loadRuntime(installedRuntimeApk); 里面，插入了一层ClassLoader ：
BootClassLoader
|—RuntimeClassLoader
|——PathClassLoader
这样是为了让宿主能访问到 runtime 插件包中的类，比如 PluginContainerActivity等，前面也说过原因了。
mPpsController.loadPluginLoader(uuid); 这个会去加载 loader 插件包，它也创建了一个 ClassLoader：
BootClassLoader
|—RuntimeClassLoader
|——PathClassLoader
|———ApkClassLoader
mPluginLoader 负责提供加载插件的接口。
mPluginLoader.loadPlugin(partKey);
它也创建了一个 ClassLoader：
BootClassLoader
|—RuntimeClassLoader
|——PathClassLoader
|———PluginClassLoader
我们可以看到，loader 插件包与 plugin 插件包都有自己的 ClassLoader，这样会有问题，因为 plugin 插件里面的类，比如 Activity，它是继承 ShadowActivity 的，这个类在 loader 插件包里面。肯定是访问不到的，所以 Shadow 做了这样一个特殊处理：
// 插件依赖跟loader一起打包的runtime类，如ShadowActivity，从loader的ClassLoader加载
// loaderClassLoader 实际上是 ApkClassLoader
if (className.subStringBeforeDot() == "com.tencent.shadow.core.runtime") {
return loaderClassLoader.loadClass(className)
}
通过这种方式，强行让 PluginClassLoader 访问 ApkClassLoader 加载的类。
类加载器说完了，我们继续看mPluginLoader.loadPlugin(partKey); 里面的其他逻辑。
// 加载 com.tencent.shadow.core.manifest_parser.PluginManifest 这个类，
// 做一个检查，保证插件和宿主包名一致
CheckPackageNameBloc.check(pluginManifest, hostAppContext)
为啥要保证插件与宿主包名一致呢？
ApplicationId一般是在build.gradle中设置的，在编译时这个字符串会被记录在2个位置。第1是记录在应用的AndroidManifest.xml中，第2是记录在应用的resources.arsc文件中。
记录在AndroidManifest.xml中的包名主要用来构造应用的Context对象。在我们开发中一般通过context.getPackageName()方法获得到当前应用设置的ApplicationId。但是重要的是，系统也会通过context获取包名来识别context来自于哪个安装的应用。我们知道系统不允许安装多个相同ApplicationId的应用，这也是因为系统就是根据这个包名来区分安装的应用的。通过这个ApplicationId，系统也可以反向查找到应用安装在系统中的apk文件路径。
问题在于系统不是非常简单的和我们一样只会调用context.getPackageName()方法获得应用的ApplicationId。还会调用一些私有API获取，例如getOpPackageName()方法。
所以以Hook方式实现的插件框架中，只能不停的兼容各种OEM系统、各种Android版本。
Shadow始终坚持一个原则来避免使用私有API，就是通过一层中间件将插件代码变成宿主代码的一部分。实际上这个过程是可以通过手工将中间件和插件代码都写在宿主中达到相同效果的。所以在这个设计中，插件代码实际上就是宿主代码的一部分。既然是一部分，ApplicationId怎么会不一样呢？所以要求插件和宿主的ApplicationId保持一致，就永远不会将插件代码没有安装这件事暴露给系统。Shadow代码中并没有什么对包名的特殊处理逻辑，只有一处检查包名是否一致的逻辑com.tencent.shadow.core.loader.blocs.ParsePluginApkBloc#parse。
// 创建一个 ApplicationInfo
CreatePluginApplicationInfoBloc.create()
// 创建插件的 PackageManager
PluginPackageManagerImpl()
// 创建插件的 Resource
CreateResourceBloc.create()
// 处理 AppComponentFactory
ShadowAppComponentFactory::class.java.cast(clazz.newInstance())
// 创建 Application
CreateApplicationBloc.createShadowApplication()
到了这里，插件包就处理完了。
callApplicationOnCreate
由于mPluginLoader 负责插件接口，所以这个方法由 mPluginLoader.callApplicationOnCreate(partKey); 触发，最终调用到 ShadowPluginLoader 里面：
fun callApplicationOnCreate(partKey: String) {
...
val application = pluginParts.application
application.attachBaseContext(mHostAppContext)
mPluginContentProviderManager.createContentProviderAndCallOnCreate(
application, partKey, pluginParts
)
application.onCreate()
...
}
前面已经创建了 application，这里处理很简单，调用 attachBaseContext 与 onCreate 这两个生命周期方法，注意，还处理了 ContentProvider。
startActivityInPluginProcess
这个方法也是通过 mPluginLoader 来触发，最终调用到 DynamicPluginLoader 的 startActivityInPluginProcess 方法里面：
@Synchronized
fun startActivityInPluginProcess(intent: Intent) {
mUiHandler.post {
// 这个 mContext 是由宿主的 applicationContext
mContext.startActivity(intent)
}
}
由于我们已将将 pluginIntent 转换为了 containerIntent，所以直接交给宿主来启动宿主的壳子 Activity。壳子Activity 启动后，就要处理 delegate 等信息，然后同步触发插件 Activity 的生命周期，具体可看 ShadowActivityDelegate。
壳子 Activity 与插件 Activity 的对应关系实现，由 Manager 的 onBindContainerActivity 方法实现，Sample 里面只实现了标准模式的 Activity 对应关系，标准模式可以多对一，其余的模式不行：
public ComponentName onBindContainerActivity(ComponentName pluginActivity) {
switch (pluginActivity.getClassName()) {
/**
* 这里配置对应的对应关系
*/
}
return new ComponentName(context, DEFAULT_ACTIVITY);
}
其五
资源的处理其实比较简单，因为每个插件包都有自己的 Context，而且也没有访问宿主的需求，所以只需要处理一下资源冲突就好了。资源冲突通过资源分包解决，但是引发了其他问题，具体可看 CreateResourceBloc 逻辑。因为我没遇到过，所以也不懂里面为啥会有这样的问题，不深究。
其六
WebView 的处理，WebView 本身也是动态加载的，但是在插件里面实例化一个 WebView 的时候，它的资源路径会被添加到壳子的Resource里面，而不是 ShadowContext 的 Resource 里面，会有问题，处理方式就是，使用宿主 Context 主动实例化一个 WebView，将里面的路径拷贝出来：
WebView(hostAppContext)
val hostApplicationInfo = hostAppContext.applicationInfo
val hostSharedLibraryFiles = hostApplicationInfo.sharedLibraryFiles
还有一个问题，就是 WebView 加载本地资源的问题。
在正常的App开发中，我们可以用这样的代码加载App的Assets中打包的Web页面。
webview.loadUrl("file:///android_asset/index.html");
Android系统实现这个功能时，并没有像我们想象的使用webview对象的Context去查找Assets资源。而是通过当前应用的ApplicationId，反查了当前安装的应用的apk路径。所以查到的自然是安装的宿主应用。在宿主的apk中自然是找不到插件的Assets。
我们可以模仿“Web离线包”方案。对WebView loadUrl中file:///android_asset/协议进行修改。先通过 LayoutInflater 将插件中用到的WebView都换成ShadowWebView。再Override ShadowWebView的loadUrl方法。将请求来的file:///android_asset/协议都修改成http://android.asset/协议。
关于这部分代码，请查看com.tencent.shadow.core.runtime.ShadowWebView类的实现。
其七
还有一个多插件自定义控件重名问题。
在Android 7 及以下，LayoutInflater 创建View的时候，会缓存其构造函数，提升效率，但是它没有校验ClassLoader。也就是说，如果有不同的 ClassLoader 来创建同一个 View，那么就会出现提示信息类似于“RecycleView cannot cast to RecycleView”的Crash异常。
Shadow的处理是如果ClassLoder校验没通过，那就将缓存移除，重新创建一个，其实这里可以参考高版本的逻辑。
if (constructor != null && !verifyClassLoader(context, constructor)) {
constructor = null;
sConstructorMap.remove(cacheKey);
}
其八
画了一些画了一些不伦不类的类图…
参考文档
-
https://juejin.cn/post/6844903929562529800#heading-12
-
https://juejin.cn/user/536217405890903
2390
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
