插件化之旅2-广播插件的两种实现模式和apk安装原理

写在文章之前，在上一篇插件化之旅2的中忘了强调一件事情，就是插件的xml中不能给View添加onClick标签，这个一定要注意！！！

一、阿里插件框架如何加载插件广播？

步骤1.新建一个接口PayInterfaceBroadCast定义插件广播的实现标准：

image.png

步骤2.在插件的taopiaopiao模块，新建一个MyBroadCast类继承BroadCast并实现广播标准接口PayInterfaceBroadCast，然后我们在插件的MainActivity中新增两个方法，一个是动态注册MyBroadCast,另外一个是发送广播的action，看看能否接收这个Action？

image.png

很显然，这样显然是不能收到广播的action，那么原因是什么呢？

二、为什么第一点中的广播发送和接收会失败？

何为插桩方式实现插件四大组件加载呢？就是说四大组件都必须在宿主中有个代理类，那么此时很明显要创建一个ProxyBroadCast类，这个是一点，另外一点是插件中的BaseActivity的registerBroadCast方法是调用that的register方法，此时我们要知道，that就是ProxyActivity，那么也要再ProxyActivity重写registerBroadCast方法：

image.png

image.png

这里就能实现动态注册插件广播啦，小伙伴们可以试下哦！！！

三、静态注册插件广播

3.1静态注册的广播是什么时候注册的？

静态注册的广播在手机启动的时候，就已经加装到手机内存了（可以联想到自启动广播的业务）
App的四种安装方式：
1.adb指令安装（无安装界面）
2.应用商店安装应用（有安装界面）
3.三方应用安装其他应用（有安装界面，由PackageInstaller.apk处理安装已卸载过程）
4.系统应用安装其他应用（无安装界面）

App安装时候，系统给我们做了什么事情呢？（三件事）
1.安装时，系统把apk文件复制到data/app -------------用户程序安装的目录
2.开辟存放应用文件的数据 /data/data/包名
3.将apk中的dex文件安装到/data/dalvik-cache目录下，dex文件是dalvik虚拟机可执行文件，其大小约为原始apk文件大小的四分之一。

静态广播的加载，是发生在系统启动时，系统启动可以理解成将所有app重新安装一遍，会重复上述三件事

PMS定义:
你可以理解为系统通过apk的存放路径，来为我们生成开发过程中想要的一切（class和res）。下面通过PMS的源码来分析加载apk的流程

3.2PMS的源码核心步骤分析：

步骤一、首先看它的核心入口方法：main方法：

image.png

步骤二、再看PMS构造方法做了什么事？

image.png

步骤三、根据步骤二中有个很关键的file：mAppInstallDir,路径前缀是/data/data/app/com.xxx.xxx，然后接下来看看哪里使用了mAppInstallDir：

image.png

image.png

image.png

步骤四、接下来发现通过apk路径，然后调用的是PackageParser.parsePackage的方法，来解析生成apk唯一的Package

image.png

image.png

image.png

image.png

image.png

四、如何加载插件的静态广播？

根据前面的第三点内容我们可以知道PMS如何解析Apk，同时了解到静态注册的广播已经在apk安装完后，系统已经帮我们注册了，那么如何让系统知道插件apk里面的注册的是静态的广播呢？这里我们就要模拟系统加载apk的方法，来加载插件apk，也相当于解析的过程.

image.png

上图中已列出详细的注释，它的核心思想是：反射拿到插件apk中的Package，再反射拿到receivers集合，最终在宿主中动态注册插件的静态广播。

有了上述的步骤之后，我们可以模拟一下，看看代码是否生效？首先在宿主的MainActivity中动态注册一个广播，给插件发送指定的Action，然后在插件中静态注册广播，接收这个Action，插件接收完成后，再给宿主发送广播，证明流程完毕，具体代码可到github上的demo，这里就不贴图出来了
Demo地址：
https://github.com/cWX411904/AliPayPluginTestOne