阅读 2114

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

这篇文章介绍一下Shadow的跨进程设计和插件Service的原理。一同讲这两部分是因为它们是相关的。这篇文章假设读者对于Android的Service、Binder通信没有那么了解,因此会提及一些可能对你来说有些简单的内容。

跨进程设计对插件框架的必要性

在Android系统中,应用可以是多进程的。这在移动端操作系统中应该是非常高级的设计了,很多移动端操作系统、嵌入式系统都是不支持的。多进程程序给程序设计带来了很有优点,也带来更多的复杂性。

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特性的。

根据文档: developer.android.com/guide/topic…

android:multiprocess为true时,Activity和Provider的行为是启动Intent时处于哪个进程,就将被启动的Activity或Provider启动在哪个进程。

既然PPS已经决定了插件进程,由PPS启动插件Activity就可以使壳子工作在PPS所在进程了。这样可以在同一个宿主中应用多个插件进程时少注册一些壳子组件。

欢迎大家实验一下然后提一个PR来改进这个问题。

github.com/Tencent/Sha…

PS: 新注册的掘金账号,发文章曝光量很低。选择来掘金分享也是希望吸引更多开发者关注到Shadow。所以请大家支持一下,点个赞提高点我的掘力值,以便更好的继续分享。

关注下面的标签,发现更多相似文章
评论