Android IPC机制—Binder的工作机制 _IPC机制

别裁伪体亲风雅，转益多师是汝师。这篇文章主要讲述Android IPC机制—Binder的工作机制相关的知识，希望能为你提供帮助。
进程和线程的关系
IPC机制即为跨进程通信，是inter-Process Communication的缩写。是指两个进程之间进行通信。在说进程通信之前，我们的弄明白什么是线程，什么是进程。进程和线程是两个截然不同的概念。按照操作系统中的描述，线程是CPU调度的最小单位，同时线程也是一种有限的系统资源。而进程一般是指一个执行单元，在pc端或者移动端上是指一个程序或者一个应用。一个进程中可以包含一个或者是多个线程。所以他们的关系应该是包含和被包含的关系。

跨进程的种类
在android中跨进程通信的方式有很多种，Bundle,文件共享，AIDL,Messenger,ContentProvider,Socket,这些都能实现进程间之间的通信，当然，虽然都能够实现进程间通信，但是他们之间的实现原理或者说是底层的实现方式都是不一样的。下面，我们将会一一说明。

注：很多同学觉得创建进程就应该创建一个新的应用。其实不是的。只要我们在AndroidMenifest上加上这一句代码就可以了android:process=“:remote”具体的，同学们可以自己的了解。

在说IPC之前，先说一下一些基础概念，这样对后面的内容能够更好的理解。
1、Serializable，Parcelable接口
Serializable接口是java提供的一个序列化的接口，这是一个空的接口，为对象提供标准的序列化和反序列化操作。Serializable序列化和反序列化，都是采ObjectOutputStream 和ObjectInputStream就可以实现，当然这些系统基本已经为我们实现了。

Parcelable接口，是Android自带的一种序列化方式。序列化和反序列化都是通过writeToParcel方法来完成的。

两者的区别：Serializable是java的序列化接口使用简单，但是由于序列化和反序列化的过程需要大量的I/o操作，所以性能较差。Parcelable接口使用较为麻烦，但是效率很高，但是存在一个很大的缺点，就是被Parcelable将对象序列化以后，要将对象保存到磁盘中的，将会很麻烦。所以建议是使用Serializable。

Binder
直观来说，Binder是Android中的一个类，它实现了IBinder接口，从IPC的角度来说，Binder是Android中的一种跨进程通信的一种方式，同时还可以理解为是一种虚拟的物理设备，它的设备驱动是／dev/binder/。从Framework角度来说，Binder是ServiceManager的桥梁。从应用层来说，Binder是客户端和服务端进行通信的媒介。
在Android开发中，Binder主要用在Service中，包括AIDL和Messenger，由于Messenger的底层其实就是Aidl，所以现在我们以AIDL来分析一下binder的工作机制。
对AIDL还不懂使用的朋友可以看一下我以前写的一篇博客：http://www.cnblogs.com/huangjialin/p/7738104.html，下面就以这个例子来分析一下这个Binder的工作机制。

【Android IPC机制—Binder的工作机制】上代码：

1 /* 2 3* This file is auto-generated.DO NOT MODIFY. 4 5* Original file: /Users/huangjialin/MyApplication/service/src/main/aidl/aidl/MyAIDLService.aidl 6 7*/ 8 9 package aidl; 10 11 // Declare any non-default types here with import statements 12 13 14 public interface MyAIDLService extends android.os.IInterface { 15 16 17 18/** 19 20* Local-side IPC implementation stub class. 21 22*/ 23 24public static abstract class Stub extends android.os.Binder implements aidl.MyAIDLService { 25 26private static final java.lang.String DESCRIPTOR = "aidl.MyAIDLService"; 27 28 29 30/** 31 32* Construct the stub at attach it to the interface. 33 34*/ 35 36public Stub() { 37 38this.attachInterface(this, DESCRIPTOR); 39 40} 41 42 43 44/** 45 46* Cast an IBinder object into an aidl.MyAIDLService interface, 47 48* generating a proxy if needed. 49 50*/ 51 52public static aidl.MyAIDLService asInterface(android.os.IBinder obj) { 53 54if ((obj == null)) { 55 56return null; 57 58} 59 60android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); 61 62if (((iin != null) & & (iin instanceof aidl.MyAIDLService))) { 63 64return ((aidl.MyAIDLService) iin); 65 66} 67 68return new aidl.MyAIDLService.Stub.Proxy(obj); 69 70} 71 72 73 74@Override 75 76public android.os.IBinder asBinder() { 77 78return this; 79 80} 81 82 83@Override 84 85public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException { 86 87switch (code) { 88 89case INTERFACE_TRANSACTION: { 90 91reply.writeString(DESCRIPTOR); 92 93return true; 94 95} 96 97case TRANSACTION_getString: { 98 99data.enforceInterface(DESCRIPTOR); 100 101java.lang.String _result = this.getString(); 102 103reply.writeNoException(); 104 105reply.writeString(_result); 106 107return true; 108 109} 110 111} 112 113return super.onTransact(code, data, reply, flags); 114 115} 116 117 118 119private static class Proxy implements aidl.MyAIDLService { 120 121private android.os.IBinder mRemote; 122 123 124 125Proxy(android.os.IBinder remote) { 126 127mRemote = remote; 128 129} 130 131 132 133@Override 134 135public android.os.IBinder asBinder() { 136 137return mRemote; 138 139} 140 141 142 143public java.lang.String getInterfaceDescriptor() { 144 145return DESCRIPTOR; 146 147} 148 149 150 151 152@Override 153 154public java.lang.String getString() throws android.os.RemoteException { 155 156android.os.Parcel _data = https://www.songbingjia.com/android/android.os.Parcel.obtain(); 157 158android.os.Parcel _reply = android.os.Parcel.obtain(); 159 160java.lang.String _result; 161 162try { 163 164_data.writeInterfaceToken(DESCRIPTOR); 165 166mRemote.transact(Stub.TRANSACTION_getString, _data, _reply, 0); 167 168_reply.readException(); 169 170_result = _reply.readString(); 171 172} finally { 173 174_reply.recycle(); 175 176_data.recycle(); 177 178} 179 180return _result; 181 182} 183 184} 185 186 187 188static final int TRANSACTION_getString = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0); 189 190} 191 192 193 194public java.lang.String getString() throws android.os.RemoteException; 195 196 } 197 198

上面这段代码是系统生成的，在gen目录下可以看到根据MyAIDLService.aidl系统为我们生成了MyAIDLService.java这个类。我们先来了解一下这个类中每个方法的含义：
DESCRIPTOR：Binder的唯一标识，一般用于当前Binder的类名表示。

asInterface(android.os.IBinder obj)：用于将服务端的Binder对象转换成客户端所需的AIDL接口类型的对象，这种转化过程是区分进程的，如果客户端和服务端位于同一个进程，那么这个方法返回的是服务端的stub对象本身，否则返回的是系统封装后的Stub.proxy对象。

asBinder()：用于返回当前Binder对象。

onTransact：该方法运行在服务端的Binder线程池中，当客户端发起跨进程通信请求的时候，远程请求通过系统底层封装后交给该方法处理。注意这个方法public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags)，服务端通过code可以确定客户端所请求的目标方法是什么，接着从data中取出目标方法所需的参数，然后执行目标方法。当目标方法执行完毕后，就像reply中写入返回值。这个方法的执行过程就是这样的。如果这个方法返回false，客户端是会请求失败的，所以我们可以在这个方法中做一些安全验证。

public java.lang.String getString() throws android.os.RemoteException：
这个方法运行在客户端中，当客户端调用此方法的时候，它的内部实现是这样的：首先创建该方法所需要的输入类型Parcel对象_data，然后调用transact方法发起远程调用请求，同时当前线程挂起，然后服务端的OnTransact方法会被调用，直到RPC过程返回后，当前线程继续执行，并从_reply中读取返回的数据。

如图：Binder的工作机制

文章图片

从上面分析，我们明白了Binder的工作机制但是要注意一些问题：1、当客户端发起请求时，由于当前线程会被挂起，直到服务端返回数据，如果这个远程方法很耗时的话，那么是不能够在UI线程，也就是主线程中发起这个远程请求的。
2、由于Service的Binder方法运行在线程池中，所以Binder方法不管是耗时还是不耗时都应该采用同步的方式，因为它已经运行在一个线程中了。