一、前言：
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方法的。
|
