安卓插件化框架Shadow原理分析
一、前言：
1.介绍：
Shadow是一个腾讯自主研发的Android插件框架，经过线上亿级用户量检验。 Shadow不仅开源分享了插件技术的关键代码，还完整的分享了上线部署所需要的所有设计。
与市面上其他插件框架相比，Shadow主要具有以下特点：
- 复用独立安装App的源码：插件App的源码原本就是可以正常安装运行的。
- 零反射无Hack实现插件技术：从理论上就已经确定无需对任何系统做兼容开发，更无任何隐藏API调用，和Google限制非公开SDK接口访问的策略完全不冲突。
- 全动态插件框架：一次性实现完美的插件框架很难，但Shadow将这些实现全部动态化起来，使插件框架的代码成为了插件的一部分。插件的迭代不再受宿主打包了旧版本插件框架所限制。
- 宿主增量极小：得益于全动态实现，真正合入宿主程序的代码量极小（15KB，160方法数左右）。
- Kotlin实现：core.loader，core.transform核心代码完全用Kotlin实现，代码简洁易维护。
2.项目地址
项目地址：GitHub - Tencent/Shadow: 零反射全动态Android插件框架
二、原理分析：
Shadow号称无Hook点。核心原理是运用代理的方式，把原本的acitivty编译期间改成一个代理类，去代理宿主activity的所有生命周期。
2.1 传统的方案
既然这里提到了Shadow的特点是无hook，那么我们自然先简单的聊一下hook的方法是实现组件化。传统的方式，是通过hook了instrumetation或者classLoader，本来把本来启动HostActivity的任务，转换成了启动TargetActivity的任务，从而实现了插件当中TargetActivity的启动。
具体插件化的文章可以参看我的插件化系列课程：
https://blog.csdn.net/rzleilei/category_11590922.html?spm=1001.2014.3001.5482
hook有什么缺点吗？那自然是有的，否则Shadow也不会着重宣传其无hook的特性。hook最大的问题，就是风险性。随着安卓版本的更新， 之前hook的点很有可能会随着版本的变化而改变。比如下面通过反射Hook了Instrumetation。这样的代码在安卓12以下都是OK的，但是如果安卓14把mInstrumentation设置为了私有变量，那我们的整个插件化方案都会失效。
private fun checkInstrumentation(context: Context) {
if (state.isHookInstrumentation) {
return
}
state.isHookInstrumentation = true
val myInstrumentation =
MyInstrumentation()
//替换Acitivty中的mInstrumentation
val classLoader = javaClass.classLoader
val activityThreadClass = classLoader.loadClass("android.app.ActivityThread")
val activityThreadField =
activityThreadClass.getDeclaredField("sCurrentActivityThread")
activityThreadField.isAccessible = true
val activityThreadGet = activityThreadField.get(null)
val instrumentationField = activityThreadClass.getDeclaredField("mInstrumentation")
instrumentationField.isAccessible = true
instrumentationField.set(activityThreadGet, myInstrumentation)
}2.2 Shadow中activity启动流程：
上面是我画了一下午整理出来的完整的启动流程图，基本上覆盖了所有的流程，下面就是对整个流程做一下解释。
1.首先click作为起点，我们点击按钮启动应用，这时候调用的是startPluginActivity的方法，启动就是启动我们在宿主中埋桩好的PluginDefaultProxyActivity，同时会带入一些必要信息，比如目标类的类名等等。
2.由于在mainfest中我们注册了PluginDefaultProxyActivity，所以AMS的检查会通过，然后通知Instrumetation进行对应的Activity的创建。
3.PluginDefaultProxyActivity创建时，会调用父类的构造函数。其父类是PluginContainerActivity。在PluginContainerActivity的构造方法中，会生成代理类ShadowActivityDelegate对象delegate，由这个代理类维护宿主和实现类的关系。
3.系统的Instrumetation创建后，会调用Activity的onCreate方法，由于PluginDefaultProxyActivity中没有任何实现，所以系统会调用其父类PluginContainerActivity的onCreate方法当中。
4.PluginContainerActivity的onCreate方法中，会通过之前创建的delegate对象，去创建targetActivity（根据传过来的类名等信息生成的），targetActivity就是我们的目标Activity，这里面包含了我们正常的业务逻辑。
5.创建好了对象之后，会调用targetActivity的onCreate方法。我们的目标Activity中，自然会有一些正常的使用逻辑。比如setContentView()等等。
6.这里就以setContentView为例。TargetActivity中调用setContentView方法，其实会调用到其父类ShadowActivity中的setContentView方法。
7.这里自然会有人会问了，我们正常的TargetActivity不是继承自Activity嘛，如果都把父类改成ShadowActivity岂不是很麻烦？这里Shadow用了字节码插桩的技术，就是在APK打包的时候，自动会帮我们做替换的。
8.在ShadowActivity的onCreate方法中，会通过代理类通知真正的宿主Activity的setContentView方法的。
2.3 Shadow是如何加载插件中的dex的
就是正常的使用DexClassLoader进行加载。
new DexClassLoader(apkFile.getAbsolutePath(), oDexDir.getAbsolutePath(), null, ODexBloc.class.getClassLoader());2.4 Shadow是如何加载资源包的
val packageManager = hostAppContext.packageManager
packageArchiveInfo.applicationInfo.publicSourceDir = archiveFilePath
packageArchiveInfo.applicationInfo.sourceDir = archiveFilePath
packageArchiveInfo.applicationInfo.sharedLibraryFiles = hostAppContext.applicationInfo.sharedLibraryFiles
try {
return packageManager.getResourcesForApplication(packageArchiveInfo.applicationInfo)
} catch (e: PackageManager.NameNotFoundException) {
throw RuntimeException(e)
}也是通过正常的packageManager生成的。但是是生成一个新的Resources，区别于宿主中正常使用的Resources。由于插件和宿主中是不通的Resources，所以不会出现资源ID冲突的问题。
三、个人见解
3.1使用体验
用了几个月，没有出什么大的问题，稳定性还是不错的。
3.2优势
1.无Hook点，会是一个长期稳定的状态。
2.资源ID不会有冲突的问题，这一点对三星等特殊机型特别友好。
3.3劣势
1.由于是插桩的模式，所以Activity中的样式属性是不生效的。需要在Activity代码中设置。
2.Shadow应该是属于组件化，所以插件应用必需接入Shadow组件进行一定的改造才能正常接入。
3.接入成本感觉还是偏高。很多功能，需要了解其原理才能正常使用，还做不到一键接入。