背景

在WifiManager.java中，随处可见这样的方法调用实现：
代码路径：frameworks/base/wifi/java/android/net/wifi/WifiManager.java

public void connect(int networkId, ActionListener listener) {...getChannel().sendMessage(CONNECT_NETWORK, networkId, putListener(listener));}public void save(WifiConfiguration config, ActionListener listener) {...getChannel().sendMessage(SAVE_NETWORK, 0, putListener(listener), config);}

继续追踪getChannel()的实现不难发现，这个方法返回的是一个AsyncChanel的实例对象：

private synchronized AsyncChannel getChannel() {if (mAsyncChannel == null) {Messenger messenger = getWifiServiceMessenger();...mAsyncChannel = new AsyncChannel();mConnected = new CountDownLatch(1);Handler handler = new ServiceHandler(mLooper);mAsyncChannel.connect(mContext, handler, messenger);try {mConnected.await();} catch (InterruptedException e) {Log.e(TAG, "interrupted wait at init");}}return mAsyncChannel;}

虽然可以进一步快速定位到AsyncChannel.sendMessage()的接收端是getWifiServiceMessenger()返回的Messenger实例对象，并通过Messenger.send()方法实现跨进程调用，从而由WifiServiceImpl.ClientHandler接收并处理消息；

但是由于有如下疑问：

  • Handler本身是不可跨进程的，因此AsyncChannel的跨进程是如何实现的；
  • 为何要使用AsyncChannel，而不是直接使用AIDL调用？

因此决定好好理一理这个Android Framework的Internal工具类；

整体介绍

根据类声明处的注释可知，AsyncChannel可用于实现如下四种通信之一：

  • 进程内两个线程Handler的单向通信；
  • 进程内两个线程Handler的双向通信；
  • 进程间两个线程Handler的单向通信；
  • 进程间两个线程Handler的双向通信；

同时，这4种通信方式还可以以同步与异步两种连接、通信方式实现；
所以严格意义来说，一共是8种通信方式；
但是这里的同步与异步差别不大，因此只会在需要区别的地方提出，其余部分就一概而论了；

进程内和进程间很好理解，事实上，无论是进程内，还是进程间的两个Handler，AsyncChannel的通信都是借助实现了Parcelable接口的Messenger类实现，因此区别仅是走不走Binder，对于上层表征来看是没有区别的。

这里重点解释下单向与双向的含义：

单向指的是客户端可以向服务端发送消息，但是服务端无法知道客户端的任何情况（总共连接上的客户端个数，发送这个消息的客户端是哪一个等）

（注意：这里说的单向并不是指数据流只能从Client到Server。事实上Server端是可以回执消息给Client的，只是Server端无法知晓Client，因此无法主动发送消息给Client；）

双向指的是客户端与服务端可以互发消息，因此彼此是可以了解对方情况的；

由于双向本质上就是两端都连接一次对端，各自持有一个AsyncChannel实例，向对端发送消息，互为Client/Server，并且的场景使用得比较少，因此本文后续若无特别说明，均以单向的连接、通信方式为例；

工作原理

概览

先上一张图：

简单解读下：

  1. Looper1与Looper2表示两个线程，由于在讨论Handler的通信，因此用Looper更直观；
  2. Looper2可以与Looper1在不同进程，也可以在同一进程，甚至可以是同一个Looper（即同一线程）；
  3. 当Looper1下的Handler1x构造AsyncChannel并发起对Looper2下Handler2x的连接请求时，我们认为Handler1x是客户端(Client)，Looper2中的目标Handler则为服务端(Server)；
  4. 在单向连接情况下，只能由Client发送消息到Server，Server端只能在处理完Client发送过来的消息后，通过replyToMessage方法定向回执一个Message给Client，无法主动调用sendMessage/sendMessageSynchronously给Client发送消息；
  5. 而在双向连接的状态下，双方均可调用sendMessage/sendMessageSynchronously方法向对端发送消息，也可通过replyToMessage方法定向回执一个Message给对端；
  6. 消息传递利用了IMessenger这一AIDL接口：如果Looper1与Looper2在同一进程内，甚至为同一线程时，AIDL会直接走本地调用；如果Looper1与Looper2在不同进程时，会利用Binder调用过去（详见AIDL接口文件生成的JAVA类中Stub.asInterface()方法实现）

连接

最常用的连接方法是如下几个：

//异步public void connect(Context srcContext, Handler srcHandler, Handler dstHandler);public void connect(Context srcContext, Handler srcHandler, Messenger dstMessenger);//同步public int connectSync(Context srcContext, Handler srcHandler, Handler dstHandler);public int connectSync(Context srcContext, Handler srcHandler, Messenger dstMessenger);public int fullyConnectSync(Context srcContext, Handler srcHandler, Handler dstHandler);

方法1、3都是简单地将最后一个类型为Handler参数封装成Messenger并调用重载方法，因此我们以方法2、4为例分析：

public void connect(Context srcContext, Handler srcHandler, Messenger dstMessenger) {// We are connectedconnected(srcContext, srcHandler, dstMessenger);// Tell source we are half connectedreplyHalfConnected(STATUS_SUCCESSFUL);}public int connectSync(Context srcContext, Handler srcHandler, Messenger dstMessenger) {// We are connectedconnected(srcContext, srcHandler, dstMessenger);return STATUS_SUCCESSFUL;}public void connected(Context srcContext, Handler srcHandler, Messenger dstMessenger) {// Initialize source fieldsmSrcContext = srcContext;mSrcHandler = srcHandler;mSrcMessenger = new Messenger(mSrcHandler);// Initialize destination fieldsmDstMessenger = dstMessenger;}

前面说过，AsyncChannel利用的是IMessenger实现的通信，那么所谓的“连接”实际上也就是把mSrcMessenger与mDstMessenger等相关成员变量初始化、赋值即可；这部分无论是connect还是connectSync方法，都是同步执行的；

那么所谓的异步是什么？

其实就是返回值是否同步返回：如果是connectSync方法，则在完成连接后直接return STATUS_SUCCESSFUL，而如果是connect方法，则没有返回值，连接成功的状态通过replyHalfConnected传递给mSrcMessenger，需要mSrcHandler在handleMessage中处理：

private void replyHalfConnected(int status) {Message msg = mSrcHandler.obtainMessage(CMD_CHANNEL_HALF_CONNECTED);msg.arg1 = status;msg.obj = this;msg.replyTo = mDstMessenger;if (!linkToDeathMonitor()) {// Override status to indicate failuremsg.arg1 = STATUS_BINDING_UNSUCCESSFUL;}mSrcHandler.sendMessage(msg);}

关于异步连接，考虑到跨进程的AsyncChannel需要传递Binder以建立连接，而这一操作普遍通过bindService后从ServiceConnection.onServiceConnected()回调方法处获取，因此针对这一使用场景，AsyncChannel提供了两个个封装方法：

public void connect(Context srcContext, Handler srcHandler, Class<" />> klass);public void connect(Context srcContext, Handler srcHandler, String dstPackageName, String dstClassName);

当然，由于需要等待ServiceConnection.onServiceConnected()回调方法，因此这两个方法没有同步的响应实现；

断开

断开方法很单一，只有一个：

public void disconnect() {/* * 如果mConnection不为null，表明使用了上方所述的两种封装方法进行bindService建立连接： *- connect(Context srcContext, Handler srcHandler, Class klass); *- connect(Context srcContext, Handler srcHandler, String dstPackageName, String dstClassName)； * 这种情况下需要调用unbindService断开与远端Service的连接； * 注意，unbindService不会调用到ServiceConnection.onServiceDisconnected() */if ((mConnection != null) && (mSrcContext != null)) {/** 注意，unbindService不会调用到ServiceConnection.onServiceDisconnected()，因此 * ServiceConnection.onServiceDisconnected()中的replyDisconnected(STATUS_SUCCESSFUL)不会执行， * 需要下方显式调用一次 */mSrcContext.unbindService(mConnection);mConnection = null;}try {/* * 尝试给服务端发送CMD_CHANNEL_DISCONNECTED信息，尽管可能收不到 */Message msg = Message.obtain();msg.what = CMD_CHANNEL_DISCONNECTED;msg.replyTo = mSrcMessenger;mDstMessenger.send(msg);} catch(Exception e) {}/* * 给客户端的Handler发送CMD_CHANNEL_DISCONNECTED消息； * 如果上面mConnection不为null，这里会重复发送 */replyDisconnected(STATUS_SUCCESSFUL);mSrcHandler = null;// Unlink only when bindService isn't usedif (mConnection == null && mDstMessenger != null && mDeathMonitor!= null) {mDstMessenger.getBinder().unlinkToDeath(mDeathMonitor, 0);mDeathMonitor = null;}}

有几个点需要澄清一下：

  • 无论是通过自己实现bindService，或是通过AsyncChannel提供的内部封装bindService实现的connect方法，其本质只是通过ServiceConnection.onServiceConnected()回调方法获取到服务端的Messenger（以IMessenger实例对象传递）；此后无论Service是否断开，均与AsyncChannel的连接没有必然联系；
  • disconnect()方法内之所以当mConnection不为null时要调用unbindService(mConnection)，并不是为了彻底断开AsyncChannel的连接，而是由于mConnection仅在内部封装了bindService逻辑的connect方法调用时创建，因此在断开连接后，mConnection维系的与服务端Service的绑定关系也就没有必要了，因此需要断开；
  • 由上可得，unbindService后，只要服务端的Handler还在，AsyncChannel连接没有断开，则依旧可以通过AsyncChannel发送消息到服务端；
  • 同理，当AsyncChannel断开后，如果是自行建立的绑定Service并不需要立即解绑（unbindService）；

通信

发送消息

最常用的发送消息方法是如下几个：

//异步public void sendMessage(Message msg);public void sendMessage(int what);public void sendMessage(int what, int arg1);public void sendMessage(int what, int arg1, int arg2);public void sendMessage(int what, int arg1, int arg2, Object obj);public void sendMessage(int what, Object obj);//同步public Message sendMessageSynchronously(Message msg);public Message sendMessageSynchronously(int what);public Message sendMessageSynchronously(int what, int arg1);public Message sendMessageSynchronously(int what, int arg1, int arg2);public Message sendMessageSynchronously(int what, int arg1, int arg2, Object obj);public Message sendMessageSynchronously(int what, Object obj);

无论是同步还是异步，大部分方法都是重载方法，用于适用于各种场景的Message对象封装，只是同步与异步在发送消息后，是否等待对端返回结果：

//frameworks/base/core/java/com/android/internal/util/AsyncChannel.javapublic void sendMessage(Message msg) {//重要：这个字段决定了回执消息发送给谁，此处主要回执给自己，所以必然是mSrcMessengermsg.replyTo = mSrcMessenger;try {mDstMessenger.send(msg);} catch (RemoteException e) {replyDisconnected(STATUS_SEND_UNSUCCESSFUL);}}...public Message sendMessageSynchronously(Message msg) {Message resultMsg = SyncMessenger.sendMessageSynchronously(mDstMessenger, msg);return resultMsg;}...//专门用于同步等待返回消息的工具类private static class SyncMessenger {//用一个栈来管理已经构造出来的SyncMessenger对象，用于复用private static Stack<SyncMessenger> sStack = new Stack<SyncMessenger>();private static int sCount = 0;//每个SyncMessenger运行在一个独立的线程，该线程有一个Handler用于获取返回的Messageprivate HandlerThread mHandlerThread;private SyncHandler mHandler;//用于接收返回消息的Messenger，即利用上方mHandler构造的Messengerprivate Messenger mMessenger;.../** Synchronous Handler class */private class SyncHandler extends Handler {/** The object used to wait/notify */private Object mLockObject = new Object();/** The resulting message */private Message mResultMsg;/** Constructor */private SyncHandler(Looper looper) {super(looper);}/** Handle of the reply message */@Overridepublic void handleMessage(Message msg) {//将收到的消息生拷贝一份，并唤醒等待线程Message msgCopy = Message.obtain();msgCopy.copyFrom(msg);synchronized(mLockObject) {mResultMsg = msgCopy;mLockObject.notify();}}}//尝试复用栈内已经构造，且可用的SyncMessenger对象//如果栈是空的，说明没有可用的SyncMessenger对象，需要构造一个private static SyncMessenger obtain() {SyncMessenger sm;synchronized (sStack) {if (sStack.isEmpty()) {sm = new SyncMessenger();sm.mHandlerThread = new HandlerThread("SyncHandler-" + sCount++);sm.mHandlerThread.start();sm.mHandler = sm.new SyncHandler(sm.mHandlerThread.getLooper());sm.mMessenger = new Messenger(sm.mHandler);} else {sm = sStack.pop();}}return sm;}//使用完毕的SyncMessenger对象压入栈内，供下次obtain方法获取private void recycle() {synchronized (sStack) {sStack.push(this);}} //发送同步消息private static Message sendMessageSynchronously(Messenger dstMessenger, Message msg) {//尝试从栈内获取SyncMessenger对象，如果栈内没有，构造一个返回SyncMessenger sm = SyncMessenger.obtain();Message resultMsg = null;try {if (dstMessenger != null && msg != null) {//替换监听回执消息的Messenger为本地临时构造的mMessenger//这样mHandler就可以收到返回消息，并唤醒下方的wait，将回执消息同步返回给调用方msg.replyTo = sm.mMessenger;synchronized (sm.mHandler.mLockObject) {if (sm.mHandler.mResultMsg != null) {Slog.wtf(TAG, "mResultMsg should be null here");sm.mHandler.mResultMsg = null;}//发送消息依然是异步的dstMessenger.send(msg);//然后调用线程等待mHandler收到回执消息并notifysm.mHandler.mLockObject.wait();//走到这里即表示回执消息已经收到，并且mHandler内部已经调用notify唤醒了该线程//此时获取到mResultMsg返回给调用方即可；resultMsg = sm.mHandler.mResultMsg;sm.mHandler.mResultMsg = null;}}} catch (InterruptedException e) {Slog.e(TAG, "error in sendMessageSynchronously", e);} catch (RemoteException e) {Slog.e(TAG, "error in sendMessageSynchronously", e);}//回收SyncMessenger对象，将其压栈，方便后续复用sm.recycle();return resultMsg;}}

从上面代码片段以及注释讲解可以知道，异步发送消息，srcHandler这边要么不关心该消息的回执情况；要么需要在内部的handleMessage中监听回执结果；
而同步发送消息，则会在调用线程等待，并临时构造了一个SyncMessenger，通过其内部的SyncMessenger来接受回执消息，并通知调用线程唤醒，获取回执消息并返回；

回执消息

回执消息也有大量重载方法，且全为异步操作：

public void replyToMessage(Message srcMsg, Message dstMsg);public void replyToMessage(Message srcMsg, int what);public void replyToMessage(Message srcMsg, int what, int arg1);public void replyToMessage(Message srcMsg, int what, int arg1, int arg2);public void replyToMessage(Message srcMsg, int what, int arg1, int arg2, Object obj);public void replyToMessage(Message srcMsg, int what, Object obj);

本质上都是调用的第一个：

/** * Reply to srcMsg sending dstMsg * * @param srcMsg * @param dstMsg */public void replyToMessage(Message srcMsg, Message dstMsg) {try {dstMsg.replyTo = mSrcMessenger;srcMsg.replyTo.send(dstMsg);} catch (RemoteException e) {log("TODO: handle replyToMessage RemoteException" + e);e.printStackTrace();}}

这里可以看到，回执消息本质上是调用的srcMsg.replyTo.send()方法发送了一个Message；
srcMsg即为Server端handleMessage方法传入的参数；
srcMsg.replyTo是一个IMessenger，即为发送这个srcMsg的Handler对应的Messenger
也就是说，通过这句调用srcMsg.replyTo.send()，即可向Client端发送一个Message，而在Client端会将其认为是刚才发送的那条消息的回执；

这里也反向印证了，上面sendMessage的时候，为何需要将mSrcMessenger赋值给msg.replyTo，而sendMessageSynchronously则需要将临时的SyncMessenger对象中mMessenger赋值给msg.replyTo，这样才能让Client端的对应Handler收到回执消息；

此外，细心的同学其实可以发现，单向通信模型下的AsyncChannel，replyToMessage调用会发送给哪个Handler，取决于接收到的这个Message对象（即srcMsg中封装的replyTo成员变量指向哪个Messenger），与AsyncChannel是不是同一个实例对象没有关系（这也是必然的，跨进程的场景下，两端不可能持有同一个AsyncChannel实例对象）

以至于我们可以在WifiStateMachine.java中看到，回执消息用的AsyncChannel只是随便new的一个：

//frameworks/opt/net/wifi/service/java/com/android/server/wifi/WifiStateMachine.java...// Channel for sending replies.private AsyncChannel mReplyChannel = new AsyncChannel();...private void replyToMessage(Message msg, int what) {if (msg.replyTo == null) return;Message dstMsg = obtainMessageWithWhatAndArg2(msg, what);mReplyChannel.replyToMessage(msg, dstMsg);}private void replyToMessage(Message msg, int what, int arg1) {if (msg.replyTo == null) return;Message dstMsg = obtainMessageWithWhatAndArg2(msg, what);dstMsg.arg1 = arg1;mReplyChannel.replyToMessage(msg, dstMsg);}private void replyToMessage(Message msg, int what, Object obj) {if (msg.replyTo == null) return;Message dstMsg = obtainMessageWithWhatAndArg2(msg, what);dstMsg.obj = obj;mReplyChannel.replyToMessage(msg, dstMsg);}

总结

整个AsyncChannel对于第一次接触的开发人员来说，还是比较难以理解的，这里我列几条总结性的描述，方便理解：

  1. AsyncChannel通常使用的是单向连接模式；
  2. AsyncChannel的单向连接模式，仅需要Client构造AsyncChannel实例对象，并调用connect/connectSync即可，前者在其收到CMD_CHANNEL_HALF_CONNECTED消息后表示连接成功，后者在方法返回值中即可确定连接是否成功；
  3. AsyncChannel的单向连接模式下，Client与Server端身份固定，不会变换：Client通过sendMessage/sendMessageSynchronously方法向Server端发送Message，Server端只能在接收到Message后处理并通过replyToMessage方法回执给Client端，无法主动发送其他Message给Client；
  4. 进程内通信使用AsyncChannel比较冗余，可直接使用两个Handler即可，除非对发送消息的回执有一定要求；
  5. 因此AsyncChannel更多还是用于跨进程的通信上；

最后，解答一下一开始的两个疑问：

  • Handler本身是不可跨进程的，因此AsyncChannel的跨进程是如何实现的；

    答：进程间通信使用AsyncChannel，本质上是利用了IMessenger这个Parcelable接口的跨进程特性，本质上还是Binder调用；

  • 为何要使用AsyncChannel，而不是直接使用AIDL调用？
    答：Android Framework中定义AIDL接口如果需要增加、更改、删减，需要update API，同时通知APP适配。这通常是不被建议、甚至不被允许的。而使用AsyncChannel实现进程间通信，只需要定义一个获取对端Messenger的AIDL接口，后续扩展只需要两端协商好Message的what取值即可，可扩展性方面较好；