Android Binder机制中的异步回调
“Binder通信是同步而不是异步的”，但是在实际使用时，是设计成客户端同步而服务端异步。
看看Framwork层的各service类java源码便会知道，在客户端调用服务端的各种方法时，通常会传递一个Binder过来，该Binder对象用于服务端做异步回调，而服务端本身会使用handler或队列的方式做成异步处理。在Android中，系统service是作为"管理者"的身份存在的，像Ams(ActivityManagerService)，它并不创建Activity，创建Activity的是客户端的ActivityThread，但是每当ActivityThread想创建一个Acitivty，就必须告诉Ams，Ams会进行调度该Acitivty的创建。更简单的一个例子，Toast和NotificationManagerService，Toast负责弹出窗口的创建显示和隐藏，而何时显示跟何时隐藏却是由NotificationManagerService决定的。具体可以看看这篇文章Toast窗口的源码分析。
我们可以发现，当队列本来不为空时，客户端的同步在服务端执行完将ToastRecord放入队列之后就可以结束了。服务端会通过连续取出队列项并且回调客户端的show()和hide()方法。而在服务度回调show()和hide()时，客户端就成了”服务端“，这时它通过handler将本次真正的显示和隐藏Toast窗口操作压入Message队列，再一次实现了异步操作。
那为什么要设计成这样呢？以Toast为例，假如服务端不设计成异步调用+使用Binder回调，那当有2个Toast请求同时过来时，为了实现串行化显示(Toast每次只显示一个，本次显示完毕后才接下去显示下一个)，那么第二个Toast进程就必须阻塞着等待第一个Toast显示再隐藏，更糟糕的是，即使是第一个请求也必须在显示之后阻塞着等待服务端发送隐藏指令。
(我在看源码时对于每次IPC调用客户端都会传递一个Binder对象到服务端觉得很奇怪，当时以为是为了"双向通信"：服务端也可能需要客户端的一些处理结果。但看了更多代码后我觉得可能更准确的原因是为了异步回调。以上只是个人理解，如有错误请指出。)
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
