Android中binder是同步还是异步？

1、三个结构体：

struct binder_proc proc, struct binder_node node, struct binder_thread thread.

1).proc 通过threads 保存当前进程中的请求线程thread信息，通过node保存当前进程中实体节点信息。
2).当前的请求是要交给进程proc中的node所表示的服务进行处理，处理该请求任务的线程为thread。
3).注意有三个队列：proc->todo，node->async_todo，thread->todo.
其中 node->async_todo 存放异步任务的队列。

2、同步及异步任务流程

1).服务收到同步请求后，会将该同步任务添加至proc->todo队列
2).服务收到异步请求后，会根据has_async_transaction的状态来决定是否加入倒 node->async_todo队列
3).服务处理完请求后，会释放buffer数据空间即发送BC_FREE_BUFFER至内核，内核收到后会根据node->async_todo是否为空，若不为空，则取出一个任务添加至thread->todo队列。

3、同步请求和异步请求高并发

1).同步请求全都添加在proc->todo中，异步请求则最多只有一个任务在proc->todo中，其余全部放在node->async_todo中，然后proc依次取出任务进行处理。
2).假设proc的线程thread分配倒的任务首先处理结束，在任务处理结束后需要释放buffer数据空间，由于是高并发请求，则node->async_todo队列不为空，这时候会将该队列中的任务依次取出添加倒thread->todo中。
3).任务执行优先从thread->todo中取出，取出后thread->todo即为空，这时候才从proc->todo中取任务，这样做的目的是为了防止过多的同步任务导致异步任务饿死。

如果客户端通过多个线程T1、T2、T3依次发送binder同步请求，由于服务器可能分配不同线程来分别执行这些任务，也就无法保证这些任务的执行顺序。如果发送异步请求，则会按照T1、T2、T3的顺序依次执行。

因此，在Android中，有些时候是用的异步通信，有些时候是用的同步通信，这里以startActivity为例：

同步：
ActivityManagerProxy 类中startActivity方法使用binder与AMS进行通信:
Parcel data = Parcel.obtain();
………….
mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0);

异步：
假设此时是热启动状态，后面AMS 又会通过binder与ApplicationThread进行通信：
ApplicationThreadProxy类中的scheduleLaunchActivity 方法
mRemote.transact(SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION, data, null, IBinder.FLAG_ONEWAY);

在activity启动期间，一开始app端是作为客户端与 服务端AMS进行通信，后面 AMS 又会作为客户端与 服务端app进行通信。非必须的情况下，一般都是使用同步，那么后面为什么会使用异步？
这个是为了保证activity的生命周期不会走乱，保证AMS 能正确调度activity。如果有两个请求，第一个是launch，第二个是pause因为某种耗时原因在同时发送过来，如果AMS 还是使用同步的话，会有极大可能出现调度紊乱的情况，所以需要被设置成异步调用。

这部分和Toast的设计类似。

综上，在Android实际开发过程中，一般针对于app客户端是使用binder同步，一般对于类似AMS 的系统服务，则是使用binder异步。