前言
有了上篇文章对AIDL、Binder IPC的基本认识以后，接下来将讨论一下应用程序是如何跟Android Framework进行进程间通信的。理解这一点十分重要，有助于我们深入分析源码的实现。
回顾
以AIDL为例子，一个完整Binder IPC上层架构需要包括：
- 一个Proxy，用于向服务端写数据，在Android Framework也存在用“Bp”字样来代替
- 一个Stub，用于读取服务端的数据，不过需要注意的是，在Android Framework中一般用“Native、Bn”字样来代替（后文中用Native来阐述）。
注意：Proxy和Nativede的实现可以是Java，也可以是C/C++。
进程间通信中的客户端（Client）以及服务端（Service）是相对的，取决于当前时间谁在发数据，谁在接收数据。
应用程序与Android Framework的进程间通信
因为服务端和客户端是相对而言的：
- 服务端（Service/Server）：服务端，可以是Android系统服务，例如AMS；也可以是Application Framework中的服务，例如ApplicationThread
- 客户端（Client）：客户端，可以是应用程序，也可以是Android系统服务。
按照进程间通信的基本架构，可以画出下面的类图：
sshot-2.png
根据上图，如果一个XxxService需要对外提供跨进程通信的接口，需要满足：
- 定义接口类：XxxServiceProxy、XxxServiceNative
- XxxService继承XxxServiceNative，并且提供具体实现
举个栗子
下面通过Activity的启动流程，阐述应用程序向Android系统服务发数据、Android系统服务向应用程序发数据的两个过程。
比如说我们要启动一个MyActivity，需要动用的类图如下：
Activity启动过程
本文关心的是进程间通信的过程，而不是Activity的启动流程，因此不作过多讲解，可以参考笔者的其他文章。
如上图所示，这里解释一下这里的进程通信的过程：
- Application（Client端）要使用系统服务AMS中的服务的时候，就通过ActivityManagerProxy向ActivityManagerNative发送数据，而ActivityManagerNative的实现类是AMS，因此就会调AMS中相关的方法了。
- 系统服务AMS要将处理结果返回给Application的时候，AMS就是Client端了，AMS（间接）通过ApplicationThreadProxy向ApplicationThreadNative发送数据，而ApplicationThreadNative的实现类是ApplicationThread，因此就会调ApplicationThread中相关的方法了。然后ApplicationThread向H发消息，H收到消息以后，就（间接）回调给Activity，而我们的MyActivity是继承Activity的，因此也就回调了对应的（生命周期）方法了。
如果觉得我的文字对你有所帮助的话，欢迎关注我的公众号：
公众号：Android开发进阶
我的群欢迎大家进来探讨各种技术与非技术的话题，有兴趣的朋友们加我私人微信huannan88，我拉你进群交（♂）流（♀）。
网友评论