安卓插件化框架Shadow原理分析

Posted 2022-02-27 失落夏天

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了安卓插件化框架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冲突的问题。