Shadow的跨进程设计与插件Service原理

Android系统中的“四大组件（Activity，Service，Receiver，Provider）”全都是可以跨进程通信的组件（下文中的组件指的都是这些组件）。每个组件都可以在AndroidManifest中配置到一个指定的进程。Android系统其实不允许应用自己管理自己进程的生命周期。但是由于我们只要Start一个Intent启动属于那个进程的组件，就能启动那个进程。再用Java一般的进程操作API，比如System.exit()方法就能杀死一个进程。由于这些很容易做到的特点，让很多Android开发以为自己可以管理进程。实际上这样理解Android进程是不对的。Android系统对进程的设计是这样的，系统收到需要用到某个组件的请求时（比如start Activity或bind Service），就会检查这个组件在AndroidManifest中注册的进程是否已经启动了。如果这个进程还没有启动，系统就会首先启动这个进程，然后构造一个应用注册的Application对象，调用Application对象的attachBaseContext()方法。然后构造所有注册了应该在这个进程的ContentProvider，初始化它们，调用它们的onCreate()方法。确保后面所有组件，包括还没有被调用的Application对象的onCreate()方法都能正常使用这个进程的所有ContentProvider。然后再调用Application对象的onCreate()方法。最后才开始初始化本来需要用到这个进程的组件。所以，进程的启动是根据组件的需求启动的。进一步的，这种设计下理应让进程的结束也根据组件的需求。实际上也是这样的，当这个进程中的所有组件都不再被需要时，比如Activity finish了，或者Service stop了，或者没有任何bind了，都会让系统认为这个进程没有存在的必要了。这时系统就会决定回收进程、杀死进程了。当然系统还会在一些“必要”的时刻直接回收进程，比如内存不足等，或者内存不足首先回收了不在前台的Activity、Service等，进而导致进程符合了前面说的条件，不再被需要了。因此，当我们用System.exit()等方法关闭进程时，或者遭遇了Crash，系统是不会认为进程不再需要了的。大概是为了避免死循环Crash，Crash的组件会被系统认为不再需要。不过如果这个进程还有其他组件处于活跃状态，或者Activity栈中有多个Activity，最上面的Activity Crash了，它下面压着的Activity就应该露出了成为活跃的了。这种情况下，由于系统认为其他组件还是需要这个进程的，就会将进程的创建流程重新走一遍，启动应该活跃的组件。所以，这里要理解好，组件对于系统来说不是我们常见的“对象”的概念，它不在自己运行的进程内存中表示和记录，而是在系统管理进程中以记录的形式记录的。这些组件中以Activity最为特殊，在编写Activity的时候，不能将Activity简单思考为一个对象。要进一步理解，Activity是有持久化状态的，这些状态就是通过savedInstanceState来表达的。所以，Activity和Service最大的区别不是Activity有界面而Service没有界面，Activity和Service最大的区别是Activity是有状态的，Service是无状态的。

将组件放置在单独的进程中有很多优点，基本上都是围绕进程具有单独的内存资源的。对于插件框架来说，有两点十分必要。一是插件一般都是热更新的，质量上要求可能会降低一些，一旦出现Crash不会影响其他进程的组件。比如说在宿主的主进程显示一个大厅界面，其中某个按钮跳转到插件。插件在单独进程启动后如果出现Crash，宿主的大厅界面不会受到任何影响。如果插件也在宿主的主进程，就会导致大厅界面也会因进程重启而重新创建。二是Android的JVM虚拟机不支持Native动态库反加载，所以在同一个进程中相同so库的不同版本即不能同时加载，也不能换着加载，会造成插件和宿主存在so库冲突。

多进程也带来更多复杂性，就是它的缺点了。比如，跨进程调用的所有参数都必须是可序列化对象；跨进程通信时对面的进程可能没有启动，也可能已经死了；跨进程通信出现异常，整个跨进程调用的堆栈不会是连着的，而且异常对象通常是不能序列化跨进程传输的。如何控制插件进程退出或重启供另一业务使用。另外，进程的启动速度也比较慢。

Shadow的跨进程设计

主要基于以上两点，Shadow设计的插件框架基本模型是：Manager、LoadParameters、Loader三个部分。其中Manager工作在宿主进入插件的入口界面所在进程，负责下载插件、安装插件，然后将插件信息封装在LoadParameters中控制Loader启动插件。LoadParameters是一个可序列化的结构体，可以跨进程传输。Loader工作在插件进程，负责将插件免安装的运行起来，解决插件框架的核心问题。

Shadow中有一个叫做PluginProcessService的Service是跨进程设计的关键部分，我们简称它PPS。

PPS有多个作用：

1. 代表插件进程的生命周期。插件进程由它触发创建，由它负责自毁。
2. 接收反向注册进来的插件文件路径管理器（UuidManager，后续文章介绍插件包管理时再细讲），供Loader查找Manager安装好的插件文件路径。
3. 加载动态实现的Runtime和Loader。
4. 获取Loader的Binder接口。
5. 使插件中的Service能够跨进程工作。

我们前面复习过，进程的启动必须由一个组件触发。那么一个没有界面的Service就是一个不错的选择，因为我们通常要对插件进行“预加载”，可能会静默启动插件的Application对象，或启动插件的Service等。还有要想让系统知道这个插件进程是有用的，就必须有活跃的组件在这个进程。我们的插件中的组件全都是没有安装的组件，系统都不知道他们存在，肯定不能靠它们了。靠插件的壳子代理组件也不行，因为我们是一个全动态插件框架，那些壳子代理组件也是插件的一部分，还没有加载呢，所以也不能靠它们。这就需要有一个专门负责启动插件进程的Service，所以它就叫PluginProcessService了。Service的Bind语义在这里也很正常，Manager就以Bind的方式启动这个PPS，直到宿主认为不再需要这个插件了，再通过Manager unbind这个PPS。Manager通过Bind拿到的Binder就是PPSController，通过这个PPSController操作PPS，让宿主得以使用“插件服务”。所以PPS是一个货真价实的Service。

插件Service的实现原理

选择Service来触发启动插件进程还有一个原因是，我们如果想让插件进程的插件Service能像正常Service一样跨进程通信，就必须在插件进程至少有一个真的注册在宿主中的Service。这涉及一个Binder的基本知识，就是Binder是一个中心化的跨进程通信框架。每一个Binder都分本地端和远程端，本地端实现功能，远程端供其他进程调用功能。直接实现的Binder自然就是本地端了，而远程端怎么实现呢？实际上把一个本地Binder通过另一个已经存在远程端的Binder跨进程传输一下，就自动把这个本地Binder送到Binder的中心管理器中注册并生成远程端了，新生成的远程端就通过那个已经存在的Binder的远程端输出出来了。这里可能自然会想到第一个Binder哪里来的的问题，简单说就是第一个Binder在设计中特殊处理了，详细的设计可以自行Google一下。所以，要想插件Service能正常跨进程工作，就要把插件Service的Binder通过一个已经存在的Binder传输一次。因此，最简单的办法就是通过PPS的Binder传输一次。

所以，我们将Loader本身也设计成了一个插件Service（即dynamic-loader）。因为全动态的设计中，宿主中的代码不会直接操作Loader，真正操作Loader的是动态实现的Manager。因此Loader和Manager都是动态实现，Loader上的接口就没必要在PPS上固定写死了。PPS上只保留了加载Runtime和Loader的必要方法。Loader本身的Binder先通过PPS跨进程通信到Manager进程，从而使Loader的Binder成了跨进程的Binder。然后Loader上再暴露的bindPluginService方法再将插件Service的Binder通过Loader的Binder跨进程传输其他进程，就是的插件Service真正可以面向其他进程工作起来了。我们的插件Service实现就是这么简单。可以看出来Shadow的插件Service是没有单独的代理壳子Service的，只依赖一个PPS就实现了不限数量的插件Service支持。

为什么Shadow里的Service都没有用aidl实现？

这是因为这些Binder跨进程调用都是有可能会失败的，失败了不能粗暴的Crash。所以，PPS和dynamic-loader的Binder都是半手工写的Binder。半手工就是用aidl先生成代码，再复制出来添加自定义可序列化Exception的能力。实现Manager跨进程操作Loader可以Catch异常。

PPS可以有多个

由于全动态的设计，在一个宿主中可以有多个Manager实现。一个Manager实现也可以同时操作多个PPS，只需要继承PPS注册在不同的进程中就可以了。由于Loader、Runtime也是动态的，所以不同的插件进程可以使用不同版本的Loader实现。
待改进的

Shadow的Sample中还有我们自己的业务中，都对壳子代理组件指定了进程名。对我们业务来说，这些壳子实际上是旧框架遗留在宿主中被Shadow复用的。实际上开发完Shadow的PPS，我们就意识到，这些壳子组件应该是可以应用android:multiprocess特性的。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）

结语

网上高级工程师面试相关文章鱼龙混杂，要么一堆内容，要么内容质量太浅， 鉴于此我整理了上述安卓开发高级工程师面试题以及答案。希望帮助大家顺利进阶为高级工程师。
目前我就职于某大厂安卓高级工程师职位，在当下大环境下也想为安卓工程师出一份力，通过我的技术经验整理了面试经常问的题，答案部分是一篇文章或者几篇文章，都是我认真看过并且觉得不错才整理出来。

大家知道高级工程师不会像刚入门那样被问的问题一句话两句话就能表述清楚，所以我通过过滤好文章来帮助大家理解。

现在都说互联网寒冬，其实只要自身技术能力够强，咱们就不怕！我这边专门针对Android开发工程师整理了一套【Android进阶学习视频】、【全套Android面试秘籍】、【Android知识点PDF】。

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
[外链图片转存中…(img-6bkYoSMX-1712867438063)]