插件化问题

插桩式插件化

启动Activity简单流程

同理，Service和动态注册广播也是类似的流程

插桩式静态广播

几个问题

在插件中，为什么不能使用this

因为插件APK没有安装，没有context环境，所以不能使用this，所有由this调用的方法，都需要被重写，调用宿主代理Activity中的方法

为什么需要代理的Activity

为插件提供Context环境、Activity出入栈处理等等

Hook式插件化

Hook 跳过Manifest验证 启动Activity

Hook 启动插件Apk中的Activity

尝试启动插件Apk中的Activity，分析startActivity流程

根据异常信息，分析源码，寻找解决办法

分析Android中ClassLoader

重写LoadedApk类及ClassLoader式

startActivity流程简单描述：
startActivity --> instrumentation.execStartActivity --> AMS检查(是否在manifest中注册) --> ActivityThread --> mH(Handler)中的LAUNCH_ACTIVITY标记 --> mPackages(存储了包名和LoadedApk的对应关系)中获取到LoadedApk对象 --> LoadedApk中的ClassLoader加载Activity，并最终实例化 -->实例化Activity对象后，会调用LoadedApk对象的makeApplication方法(最终会调用到LoadApk的initializeJavaContextClassLoader方法)，调用PMS根据包名检测安装包是否已经安装 -->通过检查后，会开始处理Activity的生命周期(真正启动完成)

所以我们需要处理的就是生成一个LoadedApk对象，将其添加到mPackages中去，当我们加载插件中Activity的时候，交给我们生成的LoadedApk对象中的ClassLoader来加载

同时我们还需要绕过PMS的检查，Hook PMS的getPackageInfo方法，当传入的包名是我们的插件包名时，返回一个空的packageInfo对象

插桩式和Hook式 对比分析

插桩式：需要定义一整套标准协议，重写插件Activity中的很多方法，将插件中所有用到this的地方替换掉，使用宿主的context
Hook式：通过Hook的方式，将插件Apk与宿主dex进行融合，生成Resource对象，插件Activity可以正常使用this，不必借助宿主传入的context