0


腾讯插件化—Shadow源码

简介

Shadow是一个腾讯自主研发的Android插件框架,经过线上亿级用户量检验。 Shadow不仅开源分享了插件技术的关键代码,还完整的分享了上线部署所需要的所有设计。

与市面上其他插件框架相比,Shadow主要具有以下特点:

  • 复用独立安装App的源码:插件App的源码原本就是可以正常安装运行的。
  • 零反射无Hack实现插件技术:从理论上就已经确定无需对任何系统做兼容开发,更无任何隐藏API调用,和Google限制非公开SDK接口访问的策略完全不冲突。
  • 全动态插件框架:一次性实现完美的插件框架很难,但Shadow将这些实现全部动态化起来,使插件框架的代码成为了插件的一部分。插件的迭代不再受宿主打包了旧版本插件框架所限制。
  • 宿主增量极小:得益于全动态实现,真正合入宿主程序的代码量极小(15KB,160方法数左右)。
  • Kotlin实现:core.loader,core.transform核心代码完全用Kotlin实现,代码简洁易维护。

支持特性

  • 四大组件
  • Fragment(代码添加和Xml添加)
  • DataBinding(无需特别支持,但已验证可正常工作)
  • 跨进程使用插件Service
  • 自定义Theme
  • 插件访问宿主类
  • So加载
  • 分段加载插件(多Apk分别加载或多Apk以此依赖加载)
  • 一个Activity中加载多个Apk中的View
  • 等等……

编译与开发环境

环境准备

建议直接用最新的稳定版本Android Studio打开工程。目前项目已适配Android Studio Arctic Fox | 2020.3.1, 低版本的Android Studio可能因为Gradle版本过高而无法正常打开项目。

然后在IDE中选择sample-app或sample-host模块直接运行,分别体验同一份代码在正常安装情况下和插件情况下的运行情况。

Shadow的所有代码都位于projects目录下的3个目录,分别是:

  • sdk包含SDK的所有代码
  • test包含SDK的自动化测试代码
  • sample包含演示代码

其中sample应该是大家体验Shadow的最佳环境。 详见sample目录中的README介绍。

由宿主应用开始

本地启动的顺序

  • HostApplication内进行恢复上次runtime和得到插件目录。其中PluginHelper.init方法指定了pluginManagerFile、pluginZipFile并从assets拷贝到"/data/…/files/"目录下
  • MainAcitiviy -> PluginLoadActivity -> PluginManager.enter 此时还是在host内
  • SplashActivity -> 其他Activity 此时是业务方app的实现

因此重点在于1、2步。

从尾到头进行回溯。

最终是调用

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

Plugin Manager

DynamicPluginManager.enter方法做了三件事

  • updateManagerImpl比对上次更新时间,若不相等,则以最新文件进行更新,创建SamplePluginManager(在manager包内的pluginManagerFile内构造出ManagerFactoryImpl再构造出来dynamic包内的SamplePluginManager),属于动态化的子功能。
  • SamplePluginManager.enter启动activity(前一半在宿主进程内)
  • 根据最新文件更新PluginManager

重点看第2步:

  • 调用callback.showLoading
  • installPlugin从压缩包中解压插件,更新数据库,安装插件的runtime,loader,.so
  • startPluginActivity -> BinderPluginLoader.convertActivityIntent 该过程详细看下一章
  • loadPlugin -> bindPluginProcessService
  • loadRuntime 跨进程load runtime,hack class loader
  • loadPluginLoader 跨进程传uuid,插件进程根据uuid初始化pluginLoader,将其传回客户端
  • PluginLoader.loadPlugin(partKey) 跨进程调用mDynamicPluginLoader.loadPlugin(_arg0)。先初始化PluginServiceManager,再调用LoadPluginBloc.loadPlugin
  • 在HostApplication.loadPlugin加载插件到classloader中,调用createShadowApplication初始化插件application,将所包含的信息注册保存

跨进程调用mDynamicPluginLoader.callApplicationOnCreate

  • 跨进程调用mDynamicPluginLoader.convertActivityIntent 确认启动的类名在插件中存在,将类信息放到intent内,在host进程内启动对应Activity。
  • 调用callback.closeLoading

FastPluginManager.convertActivityIntent

宿主进程Binder传递跨进程对象插件进程作用PluginManagerThatUseDynamicLoaderPpsBinder<< PpsControllerPluginProcessServiceBinderUuidManagerUuidManagerBinder>> UuidManagerBinderPluginProcessService根据uuid和APPID获取对应的插件信息BinderPluginLoaderPpsBinder<< PluginLoaderImplPluginProcessService转换intent
插件加载是重点,我们从loadPlugin作为起点开始看。

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

loadPluginLoaderAndRuntime

  • bind PPS拿到插件进程PluginProcessService的接口PpsController,不赘述
  • 跨进程loadRuntime
  • 在插件进程的PPS内,使用mUuidManager(即从宿主进程传递来的binder)反过来调用宿主进程的PluginManagerThatUseDynamicLoader.getRuntime,构造一个InstalledApk返回到PPS内
  • 使用InstalledApk内的path来调用DynamicRuntime.loadRuntime
  • 关键是DynamicRuntime.hackParentToRuntime,将RuntimeClassLoader(这个就是下面说的DexClassLoader)插入到BootClassLoader与之间。
  • 保存结果,可以用作runtime恢复

loadPluginLoader

  • 跟上一步骤类似取到InstalledApk,调用new LoaderImplLoader().load
  • 使用ApkClassLoader.getInterface获取LoaderFactory,ApkClassLoader主要有两个功能:
  • 实现不正常的双亲委派逻辑,既能和parent隔离类加载,也能通过白名单复用一些类
  • 封装了加载对象强转成接口类型的方法
  • LoaderFactory.build返回PluginLoaderImpl。LoaderFactory不是为了返回多种Loader实现,只是为了让构造参数能在编译期进行检查,而不是通过反射方法构造的,在参数不对应时编译期检查不出来。

LoadApkBloc.loadPlugin

  • 先通过Logger.classLoader.parent取到宿主的hostParentClassLoader。
  • 如果dependson为null,则new PluginClassLoader,这个就是下面说的DexClassLoader
  • loadClass方法判断如果hostParentClassLoader!=null || 是白名单 || other 走双亲委派模型,否则先尝试自己加载,再走双亲委派模型。

所有的插件框架中,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时能够正确找到实现。

CreateApplicationBloc.createShadowApplication

集合上述加载的部件

  • 使用工厂模式生产的ShadowPluginLoader
  • 宿主的资源Resource
  • 插件的包信息
  • 宿主的包信息
  • 添加ComponentManager,主要功能是管理组件和宿主中注册的壳子之间的配对关系,这个在第一步生成ShadowPluginLoader会new ComponentManager

初始化

  • 注册静态自定义广播接收器的类名,该类名是loader包里的广播类
  • 设置业务名pluginInfo.businessName和partKey
  • 设置ShadowRemoteViewCreatorImp

ComponentManager.addPluginApkInfo(pluginInfo)

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

另外

  • 插件内的Activity,更新componentMap<componentName, new ComponentName(context, DEFAULT_ACTIVITY)>
  • 插件内的Providers,通过mPluginContentProviderManager.addContentProviderInfo更新providerAuthorityMap<plugin.authority, host.authority>

callApplicationOnCreate

  • 手动调用ShadowApplication.attachBaseContext(mHostAppContext)
  • 调用mPluginContentProviderManager.createContentProviderAndCallOnCreate,调用contentProvider.attachInfo
  • 手动调用ShadowApplication.onCreate

convertActivityIntent(pluginIntent)

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

  • 类名、包名
  • 参数,业务名
  • partkey,pluginloader,版本号,进程ID

最后启动Activity。

FastPluginManager.installPlugin

回过头来看loadPlugin之前的installPlugin。

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

installPluginFromZip

将插件zip解压到名为zip的MD5的文件夹内,例如/data/user/0/包名/files/ShadowPluginManager/UnpackedPlugin/test-dynamic-manager/c35f2f6aa2c138b28e59e9a0d947cea0/plugin-debug.zip/“压缩包内容名”,其中从ShadowPluginManager开始为shadow新增的文件夹名,从UnpackedPlugin后为某个特定插件的名字,例如这里是test-dynamic-manager。

  • 读取配置文件config.json,里面包括版本信息,pluginLoader信息,plugins信息 {“compact_version”:[1,2,3],“pluginLoader”:{“apkName”:“sample-loader-debug.apk”,“hash”:“D1CBB814545373A66537465BAD8F37B5”},“plugins”:[{“partKey”:“sample-plugin-app”,“apkName”:“sample-plugin-app-debug.apk”,“businessName”:“sample-plugin-app”,“hostWhiteList”:[“com.tencent.shadow.sample.host.lib”],“hash”:“504495C8C3016B51B6E65EA9816C7955”}],“runtime”:{“apkName”:“sample-runtime-debug.apk”,“hash”:“AE00182BE7F8D3D459B1BD4F0AE06E47”},“UUID”:“684E32CC-4F8C-4FA2-A60F-66EAB532EDC1”,“version”:4,“UUID_NickName”:“1.1.5”}
  • 将config插入数据库,包括loader.apk, runtime.apk, plugin-app.apk

oDexPluginLoaderOrRunTime

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

odex文件有两个优点:

  • 体积比dex更小,它是应用启动前已优化的部分程序。
  • 更安全,令攻击者更难读取应用内容

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

extractSo

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

oDexPlugin

最后插件下的目录为:

  • md5: 存zip和解压文件
  • lib:存.so
  • oDex:存从apk解压出来的dex和odex文件

至此,启动插件内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。

主要实现的是这两点

  • 插件Activity不继承Activity,通过AOP替换父类为ShadowActivity,继承了PluginActivity
  • 插件Activity控制壳子Activity生命周期的调用
  • 在壳子PluginContainerActivity构造时,持有了被委托的接口delegate,可以调用插件的伪生命周期方法。接着调用了delegate.setDelegator(this),为ShadowActivityDelegate赋值了壳子Activity的引用
  • 在ShadowActivityDelegate.onCreate方法内,通过PluginClassLoader.loadClass创建插件PluginActivity,再为插件PluginActivity赋值了壳子Activity的引用。ShadowActivityDelegate作为一个转调或者信使的功能。
  • 由插件Activity直接指挥壳子Activity什么时候调用super.onCreate()

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

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

同名View的方法解析

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

对应LayerInflater.createViewFromtag方法:

  • 先用factory创建View
  • 若没有,则走自己的createView方法

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

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

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

PackageManager

最终调用的方法顺序是

CodeConverterExtension.redirectMethodCallToStaticMethodCall

->PackageManagerTransform. setupPackageManagerTransform

->PackageManagerInvokeRedirect.getPluginPackageManager

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

三大组件的调用

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

Service

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

其他方法类似。

ContentProvider

通过宿主PluginContainerContentProvider来转发方法。

BroadcastReveiver

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

对于静态广播,手动将静态广播放到ShadowAcpplication内,在onCreate被调用时进行注册

总结

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


本文转载自: https://blog.csdn.net/m0_62167422/article/details/129541316
版权归原作者 Android每日一讲 所有, 如有侵权,请联系我们删除。

“腾讯插件化—Shadow源码”的评论:

还没有评论