插件化问题

Posted gitzzp

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了插件化问题相关的知识,希望对你有一定的参考价值。

插桩式插件化

启动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

以上是关于插件化问题的主要内容,如果未能解决你的问题,请参考以下文章

Android 插件化Hook 插件化框架 ( 加载插件包资源 )

插件化架构设计:插件化从设计到实践该考量的问题汇总

插件化换肤方案

Android 插件化“ 插桩式 “ 插件化框架 ( 获取插件入口 Activity 组件 | 加载插件 Resources 资源 )

Android 插件化“ 插桩式 “ 插件化框架 ( 运行应用 | 代码整理 )

Android 插件化Hook 插件化框架 ( 创建插件应用 | 拷贝插件 APK | 初始化插件包 | 测试插件 DEX 字节码 )