Shadow源码解析笔记

2019-08-05  本文已影响0人  豆沙包67

Github链接

0 引言

插件化一直以来都被视为Android中一门高深莫测的学问，它需要解决一系列难题：

腾讯最近开源的Tencent Shadow分享了很多设计细节和解决思路。对比之前的插件化框架，其优势在于零反射，无入侵性且零增量。对于有些未接触过或对插件化比较陌生的同学，整个流程可能比较难以一下看懂。下面先分析整体执行流程，再研究其中的代码细节是如何解决上述难题的。

先阅读Github的文档有助于理解。而编译代码的过程已省去，按照Github上的步骤可以顺利完成。

1 由宿主应用开始

本地启动的顺序

因此重点在于1、2步。

从尾到头进行回溯。

最终是调用

DynamicPluginManager.enter(Context context, long fromId, Bundle bundle, EnterCallback callback)

2 Plugin Manager

DynamicPluginManager.enter方法做了三件事

重点看第2步：

3 FastPluginManager.convertActivityIntent

宿主进程 Binder 传递跨进程对象 插件进程 作用
PluginManagerThatUseDynamicLoader PpsBinder << PpsController PluginProcessService
BinderUuidManager UuidManagerBinder >> UuidManagerBinder PluginProcessService 根据uuid和APPID获取对应的插件信息
BinderPluginLoader PpsBinder << PluginLoaderImpl PluginProcessService 转换intent

插件加载是重点，我们从loadPlugin作为起点开始看。

3. 1 PluginLoader.loadPlugin

// 位于宿主进程
FastPluginManager.loadPlugin(partKey); // loadPluginLoaderAndRuntime
// 位于插件进程
LoadPluginBloc.loadPlugin(){
    // 在这里初始化PluginServiceManager
    // 加载插件到ClassLoader中.
    LoadApkBloc.loadPlugin
    // 获取宿主包信息包括activity、meta_data、service、provider和native路径等
    PackageManager.getPackageArchiveInfo
    // 解析插件apk，将插件内的信息放到pluginInfo内
    ParsePluginApkBloc.parse
    // new PluginPackageManager
    PluginPackageManager(hostPackageManager, packageInfo, allPluginPackageInfo)
    // 创建资源resource
    CreateResourceBloc.create
    // 创建shadow Application
    CreateApplicationBloc.createShadowApplication
    // 解析插件apk
    ParsePluginApkBloc.parse
    // 将插件信息放到各个map内，包括类名，Activity，services，provider
    ComponentManager.addPluginApkInfo(pluginInfo);
    // 添加<partKey, PluginParts>键值对
    pluginPartsMap[]
    // 添加<classLoader, pluginPartInfo>键值对
    PluginPartInfoManager.addPluginInfo();
 }
// 调用shadow applciation.oncreate方法
pluginLoader.callApplicationOnCreate(partKey);
DynamicPluginLoader.convertActivityIntent();
// 最后启动插件内的plashActivity

3.1.1 loadPluginLoaderAndRuntime

更具体的原理可以参考作者的文章Shadow的全动态设计原理解析，对应container动态化。

3.1.2 loadPluginLoader

更具体的原理可以参考作者的文章Shadow的全动态设计原理解析，对应关于动态加载接口实现的实践经验。

3.1.3 LoadApkBloc.loadPlugin

所有的插件框架中，Activity的加载都是这样的，new一个DexClassLoader加载插件apk。然后从插件ClassLoader中load指定的插件Activity名字，newInstance之后强转为Activity类型使用。实际上Android系统自身在启动Activity时也是这样做的。所以这就是插件机制能动态更新Activity的基本原理。

...

因此，我们可以通过修改ClassLoader的parent，为ClassLoader新增一个parent。将原本的BootClassLoader <- PathClassLoader结构变为BootClassLoader <- DexClassLoader <- PathClassLoader，插入的DexClassLoader加载了ContainerActivity就可以使得系统在向PathClassLoader查找ContainerActivity时能够正确找到实现。

更具体的原理可以参考作者的文章Shadow的全动态设计原理解析，对应loader动态化。

3.1.4 CreateApplicationBloc.createShadowApplication

集合上述加载的部件

初始化

3.1.5 ComponentManager.addPluginApkInfo(pluginInfo）

Activity和Service需要更新packageNameMap，pluginInfoMap，pluginComponentInfoMap，其中packageNameMap是<类名，包名>，pluginInfoMap<ComponentName, PluginInfo>，pluginComponentInfoMap<ComponentName， PluginComponentInfo>。

另外

3.1.6 callApplicationOnCreate

3.1.7 convertActivityIntent(pluginIntent)

如果请求的是插件内的组件，则写入下列信息

最后启动Activity。

3.2 FastPluginManager.installPlugin

回过头来看loadPlugin之前的installPlugin。

// 解压插件
installPluginFromZip
// odex优化
oDexPluginLoaderOrRunTime
//插件apk的so解压
extractSo
// odex优化
 oDexPlugin

3.2.1 installPluginFromZip

0.png

3.2.2 oDexPluginLoaderOrRunTime

在低于API 26时，使用DexClassLoader时需要指定生成odex的optimizedDirectory，odex是经过优化后的dex文件。

odex文件有两个优点：

指定odex目录后创建DexclassLoader，其构造方法会最终调用DexPathList.makeDexElements加载dex文件，最终将odex路径赋值给RuntimeClassLoader，ApkClassLoader。

3.2.3 extractSo

将插件依赖的so文件复制到 "lib/" 目录下，更新数据库关于so的path。

3.2.4 oDexPlugin

最后插件下的目录为:

至此，启动插件内Activity的整体流程结束。回头看一下作者文章Shadow解决Activity等组件生命周期的方法解析 里讲的：

我们的选择是在宿主PathClassLoader上给它加一个parent ClassLoader。因为PathClassLoader也是一个有正常“双亲委派”逻辑的ClassLoader，它加载什么类都会先问自己parent ClassLoader先加载。

也就对应了3.1.5节内的类加载器的实现。

再看一下壳子Activity复用的实现，作者对比了RePlugin框架需要在宿主中注册大量Activity，而Shadow用代理Activity通过Intent的参数确定构造哪个Activity，令壳子能被复用。这也是runtime包的动态实现功能之一。

打开宿主AndroidManifest文件，注册了三个launchMode分别为standard/singleInstance/singleTask的Activity，都继承于PluginContainerActivity。

主要实现的是这两点

因此整个sample里的Activity启动流程为

MainActivity(Host) -> (上面一大堆加载) -> PluginDefaultProxyActivity(Host) -> PluginContainerActivity(host) -> ShadowActivityDelegate(Host) -> SplashActivity(:plugin)

4 同名View的方法解析

Android系统中存在一个错误的设计，导致LayoutInflater在inflate的时候使用的View类并不是简单的从ClassLoader中读取的，而是自行做了一层缓存，以View的类名作为Key保存了Class对象。这个缓存存储在一个静态域上，因此在同一个进程中，不能存在两个同名的View都使用LayoutInflater构造。这个问题常见于插件框架对于support包中的RecycleView支持上。

具体查看作者原文Shadow解决插件和宿主有同名View的方法解析。

对应LayerInflater.createViewFromtag方法：

而上述问题出在第二步。翻查Android源码，最新版本已经修复了这个问题，通过verifyClassLoader来判断是否需要移除并置空缓存。但我们仍旧需要兼容旧版本，所以可以通过设置factory来进行自定义加载。

在Shadow内的实现，在壳子Activity内重写getLayerInflater方法，返回设置了factory2的自定义LayerInflater，具体请查看ShadowLayoutInflater，其中ShadowFactory2.onCreateView也是类似官方的修复一样来解决这个问题。

再看一下同名资源的处理，插件与宿主的是资源隔离的。因此插件只能访问到自己的资源，而宿主无从更新自身代码，也无需访问插件资源。

5 PackageManager

最终调用的方法顺序是

CodeConverterExtension.redirectMethodCallToStaticMethodCall

->PackageManagerTransform. setupPackageManagerTransform

->PackageManagerInvokeRedirect.getPluginPackageManager

前两部是查找getPackageManager，生成静态的方法调用PackageManagerInvokeRedirect，内部的实现是通过classloader找到对应的PluginPartInfo，再取到相应的资源。

具体查看作者原文Shadow对PackageManager的处理方法。

6 三大组件的调用

其他三大组件并没有Activity复杂的生命周期，比较简单。

6.1 Service

启动流程为ShadowContext.startService -> ComponentManager.startService -> PluginServiceManager.stopPluginService，由3.1.5可知，插件Service已经在ComponentManager中注册了，先调用newServiceInstance通过pluginclassloader新建出Service，设置例如宿主Context、插件资源和loader之类，调用其onCreate方法。

其他方法类似。

6.2 ContentProvider

通过宿主PluginContainerContentProvider来转发方法。

6.3 BroadcastReveiver

对于动态广播直接注册使用就可以了。

对于静态广播，手动将静态广播放到ShadowAcpplication内，在onCreate被调用时进行注册，具体看3.1.4小节。

7 总结

本文分析了插件化框架Shadow如何解决一系列难题，特别是从插件加载到启动Activity的整个流程。宿主仅在AndroidManifest注册了壳子Activity，真正位于dynamic包内。壳子Activity双向持有插件Activity的引用，来实现插件Activity伪生命周期的调用（插件Activity并不真正继承Activity类），仅通过插入一层classloader而不需要过分地hack系统API实现。其中，修改LayerInflater实现同名View和通过AOP修改PackageManager的设计思路十分巧妙，值得学习。

8 Reference

9 转载或引用

转载或引用请注明出处。

上一篇 下一篇

猜你喜欢

热点阅读