Android 源码分析之旅2 2 应用程序与Android System Service的进程间通信

###前言

有了上篇文章对AIDL、Binder IPC的基本认识以后，接下来将讨论一下应用程序是如何跟Android Framework进行进程间通信的。理解这一点十分重要，有助于我们深入分析源码的实现。

###回顾

以AIDL为例子，一个完整Binder IPC上层架构需要包括：

1. 一个Proxy，用于向服务端写数据，在Android Framework也存在用“Bp”字样来代替
2. 一个Stub，用于读取服务端的数据，不过需要注意的是，在Android Framework中一般用“Native、Bn”字样来代替（后文中用Native来阐述）。

######注意：Proxy和Nativede的实现可以是Java，也可以是C/C++。

进程间通信中的客户端（Client）以及服务端（Service）是相对的，取决于当前时间谁在发数据，谁在接收数据。

###应用程序与Android Framework的进程间通信

因为服务端和客户端是相对而言的：

1. 服务端（Service/Server）：服务端，可以是Android系统服务，例如AMS；也可以是Application Framework中的服务，例如ApplicationThread
2. 客户端（Client）：客户端，可以是应用程序，也可以是Android系统服务。

按照进程间通信的基本架构，可以画出下面的类图：

根据上图，如果一个XxxService需要对外提供跨进程通信的接口，需要满足：

1. 定义接口类：XxxServiceProxy、XxxServiceNative
2. XxxService继承XxxServiceNative，并且提供具体实现

###举个栗子

下面通过Activity的启动流程，阐述应用程序向Android系统服务发数据、Android系统服务向应用程序发数据的两个过程。

比如说我们要启动一个MyActivity，需要动用的类图如下：

######本文关心的是进程间通信的过程，而不是Activity的启动流程，因此不作过多讲解，可以参考笔者的其他文章。

如上图所示，这里解释一下这里的进程通信的过程：

1. Application（Client端）要使用系统服务AMS中的服务的时候，就通过ActivityManagerProxy向ActivityManagerNative发送数据，而ActivityManagerNative的实现类是AMS，因此就会调AMS中相关的方法了。
2. 系统服务AMS要将处理结果返回给Application的时候，AMS就是Client端了，AMS（间接）通过ApplicationThreadProxy向ApplicationThreadNative发送数据，而ApplicationThreadNative的实现类是ApplicationThread，因此就会调ApplicationThread中相关的方法了。然后ApplicationThread向H发消息，H收到消息以后，就（间接）回调给Activity，而我们的MyActivity是继承Activity的，因此也就回调了对应的（生命周期）方法了。

如果觉得我的文字对你有所帮助的话，欢迎关注我的公众号：

我的群欢迎大家进来探讨各种技术与非技术的话题，有兴趣的朋友们加我私人微信huannan88，我拉你进群交（♂）流（♀）。