Android(安卓)Framework 源码之旅 —— 正识Binder
前言
- Android Framework 源码之旅 —— Activity启动流程
- Android Framework 源码之旅 —— 进程的启动
- Android Framework 源码之旅 —— WindowManagerService初窥
我第一次接触Binder是在写Service的时候,应用层开发时不时会用到Service,而Service里面有一个onBind接口,而其返回值需要一个IBinder对象,而这个返回对象,我们通常是需要继承自Binder
后面慢慢知道了,Binder是用来跨进程通信的,而跨进程通信,应用层开发通常使用aidl来完成,所以对Binder的认知也就只停于此了
然而,在研究源码的时候,跨进程通信非常频繁,虽然研究了一段时间的源码了,但对Binder一直是一知半解,于是准备系统学习下安卓的跨进程通信
1. Binder概述
首先，什么是Binder？Binder是一种进程间通信机制,基于开源的 OpenBinder 实现；OpenBinder 起初由 Be Inc. 开发，后由 Plam Inc. 接手。从字面上来解释 Binder 有胶水、粘合剂的意思，顾名思义就是粘和不同的进程，使之实现通信。
1.1 为什么是Binder
Android 系统是基于 Linux 内核的，Linux 已经提供了管道、消息队列、共享内存和 Socket 等 IPC 机制。那为什么 Android 还要提供 Binder 来实现 IPC 呢？主要是基于性能、稳定性和安全性几方面的原因。
1.1.1 性能
首先说说性能上的优势。Socket 作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，至少有两次拷贝过程。共享内存虽然无需拷贝，但控制复杂，难以使用。Binder 只需要一次数据拷贝，性能上仅次于共享内存。
| IPC方式 | 数据拷贝次数 |
|---|---|
| 共享内存 | 0 |
| Binder | 1 |
| Socket/管道/消息队列 | 2 |
1.1.2 稳定性
再说说稳定性，Binder 基于 C/S 架构，客户端（Client）有什么需求就丢给服务端（Server）去完成，架构清晰、职责明确又相互独立，自然稳定性更好。共享内存虽然无需拷贝，但是控制负责，难以使用。从稳定性的角度讲，Binder 机制是优于内存共享的。
1.1.3 安全性
另一方面就是安全性。Android 作为一个开放性的平台，市场上有各类海量的应用供用户选择安装，因此安全性对于 Android 平台而言极其重要。作为用户当然不希望我们下载的 APP 偷偷读取我的通信录，上传我的隐私数据，后台偷跑流量、消耗手机电量。传统的 IPC 没有任何安全措施，完全依赖上层协议来确保。首先传统的 IPC 接收方无法获得对方可靠的进程用户ID/进程ID（UID/PID），从而无法鉴别对方身份。Android 为每个安装好的 APP 分配了自己的 UID，故而进程的 UID 是鉴别进程身份的重要标志。传统的 IPC 只能由用户在数据包中填入 UID/PID，但这样不可靠，容易被恶意程序利用。可靠的身份标识只有由 IPC 机制在内核中添加。其次传统的 IPC 访问接入点是开放的，只要知道这些接入点的程序都可以和对端建立连接，不管怎样都无法阻止恶意程序通过猜测接收方地址获得连接。同时 Binder 既支持实名 Binder，又支持匿名 Binder，安全性高。
1.2 综述
基于上述原因，Android 需要建立一套新的 IPC 机制来满足系统对稳定性、传输性能和安全性方面的要求，这就是 Binder。
最后用一张表格来总结下 Binder 的优势：
| 优势 | 描述 |
|---|---|
| 性能 | 只需要一次数据拷贝，性能上仅次于共享内存 |
| 安全性 | 为每个 APP 分配 UID，进程的 UID 是鉴别进程身份的重要标志 |
| 稳定性 | 基于 C/S 架构，职责明确、架构清晰，因此稳定性好 |
2. Linux下传统的进程间通信原理
了解 Linux IPC 相关的概念和原理有助于我们理解 Binder 通信原理。因此，在介绍 Binder 跨进程通信原理之前，我们先聊聊 Linux 系统下传统的进程间通信是如何实现。
2.1 基本概念介绍
这里我们先从 Linux 中进程间通信涉及的一些基本概念开始介绍，然后逐步展开，向大家说明传统的进程间通信的原理。
上图展示了 Liunx 中跨进程通信涉及到的一些基本概念：
- 进程隔离
- 进程空间划分：用户空间(User Space)/内核空间(Kernel Space)
- 系统调用：用户态/内核态
2.1.1 进程隔离
简单的说就是操作系统中，进程与进程间内存是不共享的。两个进程就像两个平行的世界，A 进程没法直接访问 B 进程的数据，这就是进程隔离的通俗解释。A 进程和 B 进程之间要进行数据交互就得采用特殊的通信机制：进程间通信（IPC）。
2.1.2 进程空间划分：用户空间(User Space)/内核空间(Kernel Space)
现在操作系统都是采用的虚拟存储器，对于 32 位系统而言，它的寻址空间（虚拟存储空间）就是 2 的 32 次方，也就是 4GB。操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也可以访问底层硬件设备的权限。为了保护用户进程不能直接操作内核，保证内核的安全，操作系统从逻辑上将虚拟空间划分为用户空间（User Space）和内核空间（Kernel Space）。针对 Linux 操作系统而言，将最高的 1GB 字节供内核使用，称为内核空间；较低的 3GB 字节供各进程使用，称为用户空间。
简单的说就是，内核空间（Kernel）是系统内核运行的空间，用户空间（User Space）是用户程序运行的空间。为了保证安全性，它们之间是隔离的。
2.1.3 系统调用：用户态与内核态
虽然从逻辑上进行了用户空间和内核空间的划分，但不可避免的用户空间需要访问内核资源，比如文件操作、访问网络等等。为了突破隔离限制，就需要借助系统调用来实现。系统调用是用户空间访问内核空间的唯一方式，保证了所有的资源访问都是在内核的控制下进行的，避免了用户程序对系统资源的越权访问，提升了系统安全性和稳定性。
Linux 使用两级保护机制：0 级供系统内核使用，3 级供用户程序使用。
当一个任务（进程）执行系统调用而陷入内核代码中执行时，称进程处于内核运行态（内核态）。此时处理器处于特权级最高的（0级）内核代码中执行。当进程处于内核态时，执行的内核代码会使用当前进程的内核栈。每个进程都有自己的内核栈。
当进程在执行用户自己的代码的时候，我们称其处于用户运行态（用户态）。此时处理器在特权级最低的（3级）用户代码中运行。
系统调用主要通过如下两个函数来实现：
copy_from_user() //将数据从用户空间拷贝到内核空间copy_to_user() //将数据从内核空间拷贝到用户空间2.2 Linux下的传统 IPC 通信原理
理解了上面的几个概念，我们再来看看传统的 IPC 方式中，进程之间是如何实现通信的。
通常的做法是消息发送方将要发送的数据存放在内存缓存区中，通过系统调用进入内核态。然后内核程序在内核空间分配内存，开辟一块内核缓存区，调用 copy_from_user() 函数将数据从用户空间的内存缓存区拷贝到内核空间的内核缓存区中。同样的，接收方进程在接收数据时在自己的用户空间开辟一块内存缓存区，然后内核程序调用 copy_to_user() 函数将数据从内核缓存区拷贝到接收进程的内存缓存区。这样数据发送方进程和数据接收方进程就完成了一次数据传输，我们称完成了一次进程间通信。如下图：
这种传统的 IPC 通信方式有两个问题：
- 性能低下，一次数据传递需要经历：内存缓存区 --> 内核缓存区 --> 内存缓存区，需要 2 次数据拷贝；
- 接收数据的缓存区由数据接收进程提供，但是接收进程并不知道需要多大的空间来存放将要传递过来的数据，因此只能开辟尽可能大的内存空间或者先调用 API 接收消息头来获取消息体的大小，这两种做法不是浪费空间就是浪费时间。
3. Binder 跨进程通信原理
理解了 Linux IPC 相关概念和通信原理，接下来我们正式介绍下 Binder IPC 的原理。
3.1 动态内核可加载模块 && 内存映射
正如前面所说，跨进程通信是需要内核空间做支持的。传统的 IPC 机制如管道、Socket 都是内核的一部分，因此通过内核支持来实现进程间通信自然是没问题的。但是 Binder 并不是 Linux 系统内核的一部分，那怎么办呢？这就得益于 Linux 的动态内核可加载模块（Loadable Kernel Module，LKM）的机制；模块是具有独立功能的程序，它可以被单独编译，但是不能独立运行。它在运行时被链接到内核作为内核的一部分运行。这样，Android 系统就可以通过动态添加一个内核模块运行在内核空间，用户进程之间通过这个内核模块作为桥梁来实现通信。
在 Android 系统中，这个运行在内核空间，负责各个用户进程通过 Binder 实现通信的内核模块就叫 Binder 驱动（Binder Dirver）。
那么在 Android 系统中用户进程之间是如何通过这个内核模块（Binder 驱动）来实现通信的呢？难道是和前面说的传统 IPC 机制一样，先将数据从发送方进程拷贝到内核缓存区，然后再将数据从内核缓存区拷贝到接收方进程，通过两次拷贝来实现吗？显然不是，否则也不会有开篇所说的 Binder 在性能方面的优势了。
这就不得不通道 Linux 下的另一个概念：内存映射。
Binder IPC 机制中涉及到的内存映射通过 mmap() 来实现，mmap() 是操作系统中一种内存映射的方法。内存映射简单的讲就是将用户空间的一块内存区域映射到内核空间。映射关系建立后，用户对这块内存区域的修改可以直接反应到内核空间；反之内核空间对这段区域的修改也能直接反应到用户空间。
内存映射能减少数据拷贝次数，实现用户空间和内核空间的高效互动。两个空间各自的修改能直接反映在映射的内存区域，从而被对方空间及时感知。也正因为如此，内存映射能够提供对进程间通信的支持。
3.2 Binder IPC 实现原理
Binder IPC 正是基于内存映射（mmap）来实现的，但是 mmap() 通常是用在有物理介质的文件系统上的。
比如进程中的用户区域是不能直接和物理设备打交道的，如果想要把磁盘上的数据读取到进程的用户区域，需要两次拷贝（磁盘–>内核空间–>用户空间）；通常在这种场景下 mmap() 就能发挥作用，通过在物理介质和用户空间之间建立映射，减少数据的拷贝次数，用内存读写取代I/O读写，提高文件读取效率。
而 Binder 并不存在物理介质，因此 Binder 驱动使用 mmap() 并不是为了在物理介质和用户空间之间建立映射，而是用来在内核空间创建数据接收的缓存空间。
一次完整的 Binder IPC 通信过程通常是这样：
- 首先 Binder 驱动在内核空间创建一个数据接收缓存区；
- 接着在内核空间开辟一块内核缓存区，建立内核缓存区和内核中数据接收缓存区之间的映射关系，以及内核中数据接收缓存区和接收进程用户空间地址的映射关系；
- 发送方进程通过系统调用 copy_from_user() 将数据 copy 到内核中的内核缓存区，由于内核缓存区和接收进程的用户空间存在内存映射，因此也就相当于把数据发送到了接收进程的用户空间，这样便完成了一次进程间的通信。
如下图：
4. Binder 通信模型
介绍完 Binder IPC 的底层通信原理，接下来我们看看实现层面是如何设计的。
一次完整的进程间通信必然至少包含两个进程，通常我们称通信的双方分别为客户端进程（Client）和服务端进程（Server），由于进程隔离机制的存在，通信双方必然需要借助 Binder 来实现。
4.1 Client/Server/ServiceManager/驱动
前面我们介绍过，Binder 是基于 C/S 架构的。由一系列的组件组成，包括 Client、Server、ServiceManager、Binder 驱动。其中 Client、Server、Service Manager 运行在用户空间，Binder 驱动运行在内核空间。其中 Service Manager 和 Binder 驱动由系统提供，而 Client、Server 由应用程序来实现。Client、Server 和 ServiceManager 均是通过系统调用 open、mmap 和 ioctl 来访问设备文件 /dev/binder，从而实现与 Binder 驱动的交互来间接的实现跨进程通信。
Client、Server、ServiceManager、Binder 驱动这几个组件在通信过程中扮演的角色就如同互联网中服务器（Server）、客户端（Client）、DNS域名服务器（ServiceManager）以及路由器（Binder 驱动）之前的关系。
通常我们访问一个网页的步骤是这样的：首先在浏览器输入一个地址，如 www.google.com 然后按下回车键。但是并没有办法通过域名地址直接找到我们要访问的服务器，因此需要首先访问 DNS 域名服务器，域名服务器中保存了 www.google.com 对应的 ip 地址 10.249.23.13，然后通过这个 ip 地址才能放到到 www.google.com 对应的服务器。
4.2 Binder 通信过程
至此，我们大致能总结出 Binder 通信过程：
- 首先，一个进程使用 BINDER_SET_CONTEXT_MGR 命令通过 Binder 驱动将自己注册成为 ServiceManager；
- Server 通过驱动向 ServiceManager 中注册 Binder（Server 中的 Binder 实体），表明可以对外提供服务。驱动为这个 Binder 创建位于内核中的实体节点以及 ServiceManager 对实体的引用，将名字以及新建的引用打包传给 ServiceManager，ServiceManger 将其填入查找表。
- Client 通过名字，在 Binder 驱动的帮助下从 ServiceManager 中获取到对 Binder 实体的引用，通过这个引用就能实现和 Server 进程的通信。
我们看到整个通信过程都需要 Binder 驱动的接入。下图能更加直观的展现整个通信过程(为了进一步抽象通信过程以及呈现上的方便，下图我们忽略了 Binder 实体及其引用的概念)：
4.3 Binder 通信中的代理模式
我们已经解释清楚 Client、Server 借助 Binder 驱动完成跨进程通信的实现机制了，但是还有个问题会让我们困惑。A 进程想要 B 进程中某个对象（object）是如何实现的呢？毕竟它们分属不同的进程，A 进程 没法直接使用 B 进程中的 object。
前面我们介绍过跨进程通信的过程都有 Binder 驱动的参与，因此在数据流经 Binder 驱动的时候驱动会对数据做一层转换。当 A 进程想要获取 B 进程中的 object 时，驱动并不会真的把 object 返回给 A，而是返回了一个跟 object 看起来一模一样的代理对象 objectProxy，这个 objectProxy 具有和 object 一摸一样的方法，但是这些方法并没有 B 进程中 object 对象那些方法的能力，这些方法只需要把把请求参数交给驱动即可。对于 A 进程来说和直接调用 object 中的方法是一样的。
当 Binder 驱动接收到 A 进程的消息后，发现这是个 objectProxy 就去查询自己维护的表单，一查发现这是 B 进程 object 的代理对象。于是就会去通知 B 进程调用 object 的方法，并要求 B 进程把返回结果发给自己。当驱动拿到 B 进程的返回结果后就会转发给 A 进程，一次通信就完成了。
4.4 Binder 的完整定义
现在我们可以对 Binder 做个更加全面的定义了：
- 从进程间通信的角度看，Binder 是一种进程间通信的机制；
- 从 Server 进程的角度看，Binder 指的是 Server 中的 Binder 实体对象；
- 从 Client 进程的角度看，Binder 指的是对 Binder 代理对象，是 Binder 实体对象的一个远程代理
- 从传输过程的角度看，Binder 是一个可以跨进程传输的对象；Binder 驱动会对这个跨越进程边界的对象对一点点特殊处理，自动完成代理对象和本地对象之间的转换。
5. 手动编码实现跨进程调用
通常我们在做开发时，实现进程间通信用的最多的就是 AIDL。当我们定义好 AIDL 文件，在编译时编译器会帮我们生成代码实现 IPC 通信。借助 AIDL 编译以后的代码能帮助我们进一步理解 Binder IPC 的通信原理。
但是无论是从可读性还是可理解性上来看，编译器生成的代码对开发者并不友好。比如一个 BookManager.aidl 文件对应会生成一个 BookManager.java 文件，这个 java 文件包含了一个 BookManager 接口、一个 Stub 静态的抽象类和一个 Proxy 静态类。Proxy 是 Stub 的静态内部类，Stub 又是 BookManager 的静态内部类，这就造成了可读性和可理解性的问题。
Android 之所以这样设计其实是有道理的，因为当有多个 AIDL 文件的时候把 BookManager、Stub、Proxy 放在同一个文件里能有效避免 Stub 和 Proxy 重名的问题。
因此便于大家理解，下面我们来手动编写代码来实现跨进程调用。
5.1 各 Java 类职责描述
在正式编码实现跨进程调用之前，先介绍下实现过程中用到的一些类。了解了这些类的职责，有助于我们更好的理解和实现跨进程通信。
- IBinder : IBinder 是一个接口，代表了一种跨进程通信的能力。只要实现了这个借口，这个对象就能跨进程传输。
- IInterface : IInterface 代表的就是 Server 进程对象具备什么样的能力（能提供哪些方法，其实对应的就是 AIDL 文件中定义的接口）
- Binder : Java 层的 Binder 类，代表的其实就是 Binder 本地对象。BinderProxy 类是 Binder 类的一个内部类，它代表远程进程的 Binder 对象的本地代理；这两个类都继承自 IBinder, 因而都具有跨进程传输的能力；实际上，在跨越进程的时候，Binder 驱动会自动完成这两个对象的转换。
- Stub : AIDL 的时候，编译工具会给我们生成一个名为 Stub 的静态内部类；这个类继承了 Binder, 说明它是一个 Binder 本地对象，它实现了 IInterface 接口，表明它具有 Server 承诺给 Client 的能力；Stub 是一个抽象类，具体的 IInterface 的相关实现需要开发者自己实现。
5.2 AIDL实例
应用层中涉及到跨进程通信的，一般在Service组件中，这里就简单定义一个用来远程通信的Service
public class RemoteService extends Service { @Nullable @Override public IBinder onBind(Intent intent) { return new ProcComm.Stub() { @Override public void clientComm(CommBean bean) throws RemoteException { System.out.println("clientComm -> process name : " + getCurProcessName()); System.out.println("bean message -> " + bean.message); } @Override public void serviceComm(CommBean bean) throws RemoteException { System.out.println("serviceComm -> process name : " + getCurProcessName()); System.out.println("bean message -> " + bean.message); } @Override public void communication(CommBean bean) throws RemoteException { System.out.println("communication -> process name : " + getCurProcessName()); System.out.println("bean message -> " + bean.message); } }; } ......}当然，这里的CommBean是一个实现了Parcelable的JavaBean
public class CommBean implements Parcelable { String message; CommBean() { } protected CommBean(Parcel in) { message = in.readString(); } public static final Creator<CommBean> CREATOR = new Creator<CommBean>() { @Override public CommBean createFromParcel(Parcel in) { return new CommBean(in); } @Override public CommBean[] newArray(int size) { return new CommBean[size]; } }; @Override public int describeContents() { return 0; } @Override public void writeToParcel(Parcel dest, int flags) { dest.writeString(message); } public void readFromParcel(Parcel dest) { message = dest.readString(); }}值得注意的是，这里需要定义一个无参构造函数，否则 aidl 自动生成的 java 类会编译报错；另外，这里定义了一个readFromParcel(Parcel)方法，这样一来，就可以在 aidl 的接口中使用out和inout修饰符了，接下来创建两个 aidl 文件
CommBean.aidl
parcelable CommBean;ProcComm.aidl
interface ProcComm { void clientComm(in CommBean bean); void serviceComm(out CommBean bean); void communication(inout CommBean bean);}最后，只需要绑定Service就可以实现跨进程通信了
private ServiceConnection sc = new ServiceConnection() { @Override public void onServiceConnected(ComponentName name, IBinder service) { System.out.println("onServiceConnected -> process name : " + getCurProcessName()); ProcComm pc = ProcComm.Stub.asInterface(service); CommBean cb = new CommBean(); cb.message = "from client message"; try { pc.clientComm(cb); } catch (RemoteException e) { System.out.println(e.getMessage()); } } @Override public void onServiceDisconnected(ComponentName name) { System.out.println("onServiceDisconnected -> process name : " + getCurProcessName()); } };最后，要在程序清单中注册Service组件
<service android:name=".RemoteService" android:process=":pcProcessName" />注意这里要定义android:process，否则就不是跨进程而是同进程通信了，最终输出打印
System.out: onCreate -> process name : com.andova.systemSystem.out: onServiceConnected -> process name : com.andova.systemSystem.out: clientComm -> process name : com.andova.system:pcProcessNameSystem.out: bean message -> from client message5.3 AIDL文件
使用 aidl 最终会自动生成一个 java 类，这里就来看看它长成什么模样
public interface ProcComm extends android.os.IInterface { public static abstract class Stub extends android.os.Binder implements ProcComm { private static final java.lang.String DESCRIPTOR = "com.andova.system.ProcComm"; public Stub() { this.attachInterface(this, DESCRIPTOR); } public static ProcComm asInterface(android.os.IBinder obj) { if ((obj == null)) { return null; } android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); if (((iin != null) && (iin instanceof ProcComm))) { return ((ProcComm) iin); } return new ProcComm.Stub.Proxy(obj); } @Override public android.os.IBinder asBinder() { return this; } @Override public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException { java.lang.String descriptor = DESCRIPTOR; switch (code) { case INTERFACE_TRANSACTION: { reply.writeString(descriptor); return true; } case TRANSACTION_clientComm: { data.enforceInterface(descriptor); CommBean _arg0; if ((0 != data.readInt())) { _arg0 = CommBean.CREATOR.createFromParcel(data); } else { _arg0 = null; } this.clientComm(_arg0); reply.writeNoException(); return true; } case TRANSACTION_serviceComm: { data.enforceInterface(descriptor); CommBean _arg0; _arg0 = CommBean(); this.serviceComm(_arg0); reply.writeNoException(); if ((_arg0 != null)) { reply.writeInt(1); _arg0.writeToParcel(reply, android.os.Parcelable.PARCELABLE_WRITE_RETURN_VALUE); } else { reply.writeInt(0); } return true; } case TRANSACTION_communication: { data.enforceInterface(descriptor); CommBean _arg0; if ((0 != data.readInt())) { _arg0 = CommBean.CREATOR.createFromParcel(data); } else { _arg0 = null; } this.communication(_arg0); reply.writeNoException(); if ((_arg0 != null)) { reply.writeInt(1); _arg0.writeToParcel(reply, android.os.Parcelable.PARCELABLE_WRITE_RETURN_VALUE); } else { reply.writeInt(0); } return true; } default: { return super.onTransact(code, data, reply, flags); } } } private static class Proxy implements ProcComm { private android.os.IBinder mRemote; Proxy(android.os.IBinder remote) { mRemote = remote; } @Override public android.os.IBinder asBinder() { return mRemote; } public java.lang.String getInterfaceDescriptor() { return DESCRIPTOR; } @Override public void clientComm(CommBean bean) throws android.os.RemoteException { android.os.Parcel _data = android.os.Parcel.obtain(); android.os.Parcel _reply = android.os.Parcel.obtain(); try { _data.writeInterfaceToken(DESCRIPTOR); if ((bean != null)) { _data.writeInt(1); bean.writeToParcel(_data, 0); } else { _data.writeInt(0); } mRemote.transact(Stub.TRANSACTION_clientComm, _data, _reply, 0); _reply.readException(); } finally { _reply.recycle(); _data.recycle(); } } @Override public void serviceComm(CommBean bean) throws android.os.RemoteException { android.os.Parcel _data = android.os.Parcel.obtain(); android.os.Parcel _reply = android.os.Parcel.obtain(); try { _data.writeInterfaceToken(DESCRIPTOR); mRemote.transact(Stub.TRANSACTION_serviceComm, _data, _reply, 0); _reply.readException(); if ((0 != _reply.readInt())) { bean.readFromParcel(_reply); } } finally { _reply.recycle(); _data.recycle(); } } @Override public void communication(CommBean bean) throws android.os.RemoteException { android.os.Parcel _data = android.os.Parcel.obtain(); android.os.Parcel _reply = android.os.Parcel.obtain(); try { _data.writeInterfaceToken(DESCRIPTOR); if ((bean != null)) { _data.writeInt(1); bean.writeToParcel(_data, 0); } else { _data.writeInt(0); } mRemote.transact(Stub.TRANSACTION_communication, _data, _reply, 0); _reply.readException(); if ((0 != _reply.readInt())) { bean.readFromParcel(_reply); } } finally { _reply.recycle(); _data.recycle(); } } } static final int TRANSACTION_clientComm = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0); static final int TRANSACTION_serviceComm = (android.os.IBinder.FIRST_CALL_TRANSACTION + 1); static final int TRANSACTION_communication = (android.os.IBinder.FIRST_CALL_TRANSACTION + 2); } public void clientComm(CommBean bean) throws android.os.RemoteException; public void serviceComm(CommBean bean) throws android.os.RemoteException; public void communication(CommBean bean) throws android.os.RemoteException;}这样一看，其实还是很模式化的
5.4 手写实现AIDL
从上面可以很容易发现，生成的 java 文件无非就是定义接口和实现接口
5.4.1 自定义业务接口
public interface ProcCommInterface extends IInterface { void clientComm(CommBean bean) throws RemoteException; void serviceComm(CommBean bean) throws RemoteException; void communication(CommBean bean) throws RemoteException;}这一步需要继承android.os.IInterface
5.4.2 定义Binder对象
public abstract class Stub extends Binder implements ProcCommInterface { static final String DESCRIPTOR = "com.andova.system.aidl.ProcCommInterface"; static final int TRANSACTION_clientComm = FIRST_CALL_TRANSACTION; static final int TRANSACTION_serviceComm = FIRST_CALL_TRANSACTION + 1; static final int TRANSACTION_communication = FIRST_CALL_TRANSACTION + 2; public Stub() { attachInterface(this, DESCRIPTOR); } public static ProcCommInterface asInterface(IBinder obj) { if ((obj == null)) return null; IInterface inter = obj.queryLocalInterface(DESCRIPTOR); if (inter instanceof ProcCommInterface) { return ((ProcCommInterface) inter); } return new Proxy(obj); } @Override public IBinder asBinder() { return this; } @Override protected boolean onTransact(int code, @NonNull Parcel data, @Nullable Parcel reply, int flags) throws RemoteException { switch (code) { case INTERFACE_TRANSACTION: { if (reply != null) reply.writeString(DESCRIPTOR); return true; } case TRANSACTION_clientComm: { data.enforceInterface(DESCRIPTOR); CommBean bean = null; if (data.readInt() != 0) bean = CommBean.CREATOR.createFromParcel(data); clientComm(bean); if (reply != null) reply.writeNoException(); return true; } case TRANSACTION_serviceComm: { data.enforceInterface(DESCRIPTOR); CommBean bean = new CommBean(); serviceComm(bean); if (reply != null) reply.writeNoException(); if (reply != null) reply.writeInt(1); bean.writeToParcel(reply, Parcelable.PARCELABLE_WRITE_RETURN_VALUE); return true; } case TRANSACTION_communication: { data.enforceInterface(DESCRIPTOR); CommBean bean = null; if (data.readInt() != 0) bean = CommBean.CREATOR.createFromParcel(data); communication(bean); if (reply != null) reply.writeNoException(); if (bean != null) { if (reply != null) reply.writeInt(1); bean.writeToParcel(reply, Parcelable.PARCELABLE_WRITE_RETURN_VALUE); } else { if (reply != null) reply.writeInt(0); } return true; } default: return super.onTransact(code, data, reply, flags); } }}5.4.3 Binder对象本地代理
public class Proxy implements ProcCommInterface { private IBinder mRemote; public Proxy(IBinder remote) { mRemote = remote; } @Override public IBinder asBinder() { return mRemote; } @Override public void clientComm(CommBean bean) throws RemoteException { Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); try { data.writeInterfaceToken(DESCRIPTOR); if (bean != null) { data.writeInt(1); bean.writeToParcel(data, 0); } else { data.writeInt(0); } mRemote.transact(TRANSACTION_clientComm, data, reply, 0); reply.readException(); } finally { data.recycle(); reply.recycle(); } } @Override public void serviceComm(CommBean bean) throws RemoteException { Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); try { data.writeInterfaceToken(DESCRIPTOR); mRemote.transact(Stub.TRANSACTION_serviceComm, data, reply, 0); reply.readException(); if (reply.readInt() != 0) bean.readFromParcel(reply); } finally { reply.recycle(); data.recycle(); } } @Override public void communication(CommBean bean) throws RemoteException { Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); try { data.writeInterfaceToken(DESCRIPTOR); if (bean != null) { data.writeInt(1); bean.writeToParcel(data, 0); } else { data.writeInt(0); } mRemote.transact(Stub.TRANSACTION_communication, data, reply, 0); reply.readException(); if (reply.readInt() != 0 && bean != null) bean.readFromParcel(reply); } finally { reply.recycle(); data.recycle(); } }}尾声
- 三步掌握Android中的AIDL
- 写给 Android 应用工程师的 Binder 原理剖析
更多相关文章
- Android一些知识点汇总
- Android(安卓)Fragment与Fragment、Activity通信的方式的总结
- Android(安卓)系统启动流程总结
- Android获取内存的不同方法总结
- 图解Android(安卓)- Zygote, System Server 启动分析
- framework telephony
- Android孤儿进程防止清理
- Root Android(安卓)and Install Recovery linux shell script &
- Android(安卓)Parcel实现反向Binder通信