写在前面
binder是android给我们提供的一种跨进程通信方式。理解binder能帮助我们更好的理解android的系统设计，比如说四大组件，ams，wms等系统服务的底层通信机制就都是基于binder机制的。当然了，binder机制的底层驱动实现很复杂，本文的目的只是为了理清binder的使用和在应用层的结构和流程，对于binder在底层是如何实现的，目前能力还没到这一步去分析，不会涉及到。对于这部分，不妨将它看成是一个黑盒子，我们输入什么，然后底层会给我们提供什么。
代理模式
我们知道，a进程如果想要执行b进程的b方法，是没办法直接办得到的，但是通过binder机制，b进程可以返回给a进程一个代理对象proxy，然后a进程通过调用proxy的方法，由proxy帮我们将信息传递给b进程，从而间接调用b方法。没错，binder实现过程中用到了代理模式。所以在继续前行之前，有必要简单了解下代理模式先。
代理模式相对来说好理解一些，因为在生活中，到处都有代理的影子，比如说我们想去香港买个mac，但是自己不方便去，于是我们找了代购；比如说现在年底了要抢火车票，但是在12306手动抢票根本抢不到啊，所以我们找了第三方抢票软件，它会每隔几十ms就帮我们查询一次，有票的话就帮我们下单。这里就以抢火车票为例来说明代理模式的结构。
proxy
模式比较简单，就直接上代码了。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
// 声明买票接口public interface iticket { boolean buyticket();}// 官方的12306public class real12306 implements iticket { @override public boolean buyticket() { if (抢票成功) return true; return false; }}// 第三方抢票软件public class thirdparty12306 implements iticket { private real12306 real12306; public thirdparty12306(real12306 real12306) { this.real12306 = real12306; } @override public boolean buyticket() { while (true) { if (real12306.buyticket()) { return true; } // 10ms查询一次结果 try { thread.sleep(10); } catch (interruptedexception e) { e.printstacktrace(); } } }}public class main { public static void main(string[] args) { // 初始化我们的购票信息 real12306 real12306 = new real12306(); thirdparty12306 thirdparty12306 = new thirdparty12306(real12306); // 开始不断抢票，释放我们的劳动力 thirdparty12306.buyticket(); }} |
使用了代理模式之后，我们就不用时时刻刻盯着12306刷票了，只需要把这些重复无聊的工作交给代理去帮我们干就好了。
aidl
一般来说，我们使用binder都是通过aidl来完成的。我们新建一个aidl文件，然后定义一个接口，这样android studio就会帮我们生成一个java接口文件。以一个最简单的接口来说吧。
|
1
2
3
4
|
package example.com.aidl;interface imath { int add(int a, int b);} |
生成的imath.java文件中，代码有点乱，整理一下之后，结构大致是这样子的：
aidl
简单来说，生成了一个imath接口，接口内定义了一个抽象类imath.stub，继承了binder，imath.stub又有一个内部类imath.stub.proxy。imath.stub和imath.stub.proxy都实现了imath这个接口。结合上面的代理模式，从这里我们就可以猜出，在跨进程通信中，由于各个进程都是独立的，我们的客户端拿不到服务端的imath.stub类，只能获得它的代理imath.stub.proxy，再通过它来间接帮我们访问imath.stub类，从而完成跨进程通信。
binder流程
看了上面的结构图之后，估计大家还是看不懂的。不急，我们再结合上面这个例子来说明。binder机制是基于c/s模型的，也就是说，需要一个client进程和一个server进程。client和server是相对的，谁发消息，谁就是client，谁接收消息，谁就是server。在实际开发中，server进程通常是四大组件中的service（service必须在manifest文件中指定进程名字）。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
class remoteservice : service() { val math = math() override fun oncreate() { super.oncreate() log.d(tag, "oncreate") } override fun onbind(intent: intent): ibinder { return math } inner class math : imath.stub() { override fun add(a: int, b: int): int { return a + b } }} |
在remoteservice中，我们先定义一个math类，继承自imath.stub，在这里实现我们具体的服务端逻辑。因为imath.stub继承自binder，binder又实现了ibinder接口，所以在onbind()方法中直接返回math对象。接着再来看客户端的业务逻辑。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
// 定义serviceconnection类inner class myserviceconnection : serviceconnection { override fun onservicedisconnected(name: componentname?) { log.d(tag, "onservicedisconnected") } override fun onserviceconnected(name: componentname?, service: ibinder?) { if (service == null) return // 将ibinder转换成imath math = imath.stub.asinterface(service) log.d(tag, "result is ${math.add(1, 2)}") }}// 在oncreate中绑定remoteserviceval intent = intent(this, remoteservice::class.java)bindservice(intent, serviceconnection, context.bind_auto_create) |
当连接上service后，就会回调客户端的onserviceconnected()方法，这里传进来的service是一个binderproxy对象。
binderproxy是binder的代理类，同样也实现了ibinder接口。我们在server端返回的明明是一个math对象，到这里就变成了binderproxy对象了，是不是有点神奇？别忘了，math本身就是一个binder对象。由于是跨进程通信，我们无法直接拿到这个binder对象，只能由binderproxy对象来帮助我们完成任务。至于binder是怎么变成binderproxy的，这就是binder机制的底层原理了，将它当成一个黑盒子就好了。
拿到binderproxy对象后，再将它转换成我们定义的imath接口。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
// imath.javaprivate static final java.lang.string descriptor = "example.com.aidl.imath";public static example.com.aidl.imath asinterface(android.os.ibinder obj) { if ((obj == null)) { return null; } android.os.iinterface iin = obj.querylocalinterface(descriptor); if (((iin != null) && (iin instanceof example.com.aidl.imath))) { return ((example.com.aidl.imath) iin); } return new example.com.aidl.imath.stub.proxy (obj);}// binder.javapublic @nullable iinterface querylocalinterface(@nonnull string descriptor) { if (mdescriptor != null && mdescriptor.equals(descriptor)) { return mowner; } return null;} |
从asinterface()方法中可以看到，根据key值descriptor在binder中匹配mowner，它是一个iinterface对象。但既然是去取值，就应该有地方将他们存进来的，我们好像错过了什么。这里还得回到math的初始化过程，math继承自imath.stub，看一下它的构造方法就能明白了。
|
1
2
3
4
5
6
7
8
9
10
|
// imath.javapublic stub() { this.attachinterface(this, descriptor);}// binder.javapublic void attachinterface(@nullable iinterface owner, @nullable string descriptor) { mowner = owner; mdescriptor = descriptor;} |
到了这里，iinterface的获取已经很明显了吧。但其实，这里取出来的是null。what？为什么？别忘了，remoteservice是运行在一个单独的进程中的，attachinterface()方法是binder调用的。而我们的客户端拿到的只是binderproxy，查询到的iinterface当然是null了，所以我们还得接着看asinterface()方法。（当然了，如果remoteservice和客户端运行在同一个进程的话，这里就能直接拿到iinterface了，但这与跨进程通信就没有半毛钱关系了。）
|
1
|
return new example.com.aidl.imath.stub.proxy(obj); |
直接返回了一个代理对象。后续我们要跟server端做交互就得靠它了。比如我们调用了proxy.add()方法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
@overridepublic int add(int a, int b) throws android.os.remoteexception { android.os.parcel _data = android.os.parcel.obtain(); android.os.parcel _reply = android.os.parcel.obtain (); int _result; try { // 使用parcel来写入数据以便于跨进程传输 _data.writeinterfacetoken(descriptor); _data.writeint(a); _data.writeint(b); // mremote是在asinterface中获得的binderproxy对象 mremote.transact(stub.transaction_add, _data, _reply, 0); // 使用parcel来接收返回值 _reply.readexception(); _result = _reply.readint(); } finally { _reply.recycle(); _data.recycle(); } return _result;} |
核心方法是mremote.transact(stub.transaction_add, _data, _reply, 0);。这里的mremote是客户端拿到的binderproxy对象，然后就要开始跨进程传输了。又到了黑盒子出现的时候了，客户端发起跨进程通信后，服务端就会在自己进程的ontranscat()方法中收到通知：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
@overridepublic 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_add : { data.enforceinterface(descriptor); int _arg0; _arg0 = data.readint(); int _arg1; _arg1 = data.readint(); int _result = this.add(_arg0, _arg1); reply.writenoexception(); reply.writeint(_result); return true; } default: { return super.ontransact(code, data, reply, flags); } }} |
在server端收到信息后，会先通过parcel将信息解析出来，然后执行我们调用的add()方法，也就是我们在remoteservice中重写imath.stub的add()方法。最后将结果写回parcel中再跨进程传回给客户端，从而完成了一次跨进程通信。
如果看到这里，对于binder的流程还有疑惑的话，那就再来一张时序图好了。
binder
看图说话，当我们在客户端中去bindservice()的时候，server端在onbind()中返回了一个binder对象，经过binder驱动的转换，这个binder到了客户端中变成了binderproxy，客户端接着再把binderproxy转换成stub.proxy，后面我们与server的跨进程通信就都是通过stub.proxy发起的，然后binder驱动会帮我们将数据跨进程传输给真正的binder，binder执行完操作后再将结果写入由binder驱动传回来。由此完成了一次跨进程通信。
从图中我们也可以看出通信过程是同步的。当客户端发起请求的同时，当前的线程会被挂起，直到结果返回。所以要注意的是如果请求太耗时的话，不应该在主线程中去请求，否则容易出现anr。给个systrace直观感受一下。
systrace
相应的cpu信息是处于休眠状态的。
cpu
最后
掌握了binder的上层原理之后，后面再来深入framework层学习就会简单一些，这篇文章也是为了后面的学习打下基础。
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对服务器之家的支持。
原文链接：https://www.jianshu.com/p/36264dd97545
