5.2.1 HSM和AsyncChannel介绍

HSM(对应的类是StateMachine)和AsyncChannel是Android Java Framework中两个重要的类。不过,它们目前还仅由Framework内部使用,SDK中并没有包含它们。这两个类的作用如下。

·HSM在传统状态机对所有状态都一视同仁的基础上做了一些改变,使得状态和状态之间有了层级关系。HSM中的状态层级关系与Java中父子类的派生和继承关系类似,即在父状态中实现generic的功能,而在子状态中实现一些特定的处理。不过,和Java中类派生不同的是,HSM中父子状态对应的是毫无派生关系的两个类,所以使用时需要创建两个对象。而Java中子类则从其父类派生,实际使用时创建一个子类对象即可,该子类对象就能完成父类的工作。

·AsyncChannel用于两个Handler之间的通信。具体的通信方式为源Handler通过sendMessage向目标Handler发送消息,而目标Handler通过replyToMessage回复源Handler处理结果。注意,这两个Handler可位于同一个进程,也可分属两个不同的进程。

本节先来介绍HSM。

注意 由于HSM和AsyncChannel并非本书的主题,故本章仅介绍它们的用法。对实现原理感兴趣的读者不妨在了解它们用法的基础上,自行研究相关代码。

1.HSM使用

HSM对应的类叫StateMachine,下面通过一个例子来介绍其用法。

[HSM示例]

  1. // 此例来源于StateMachine.java文件中的注释
  2. // StateMachineTest是StateMachine的子类
  3. class StateMachineTest extends StateMachine {
  4. StateMachineTest(String name) {
  5. super(name);
  6. // 为状态机添加一个状态。代码中一般用缩进的方式表达层级关系
  7. addState(mP0);
  8. // 添加一个状态mS0,其父状态为mP0
  9. addState(mS0, mP0);
  10. addState(mP1, mP0);
  11. addState(mS1,mP1); // 添加一个状态mS1,其父状态为mP1
  12. addState(mS5,mS1)
  13. addState(mS2, mP1);
  14. addState(mS3, mS2);
  15. addState(mS4, mS2);
  16.  
  17. // setInitialState函数用于设置状态机的初始状态,本例中该状态是mS5
  18. setInitialState(mS5);
  19. }// StateMachineTest构造函数结束

上述代码中StateMachineTest所涉及的状态及层级关系如图5-2所示。

5.2.1 HSM和AsyncChannel介绍 - 图1

图5-2 HSM示例中状态关系

图5-2中,mS5是初始状态,由代码中的setInitialState函数设置。接着来看StateMachineTest的代码。

[HSM示例]

  1. // 接上面的代码。P0从State类派生。在HSM中,状态由类State来表达
  2. class P0 extends State {
  3. /*
  4. enter代表一个状态的Entry Action,SM进入此状态时将调用其EA。
  5. exit代表一个状态的Exit Action,SM退出某状态时将调用其EXA。
  6. */
  7. public void enter() {......// do sth here}
  8. public void exit() {......// do sth here}
  9. /*
  10. 除了EA和EXA外,每个State中最重要的函数就是processMessage了。
  11. 在HSM中,外界和HSM交互的方式就是向其sendMessage。Message由当前State的processMessage
  12. 函数来处理。如果当前State成功处理此message,则返回HANDLED。否则返回NOT_HANDLED。
  13. 在Message处理中,如果子状态返回NOT_HANDLED,则其父状态的processMessage将被调用。
  14. 如果当前状态及祖先状态都不能处理,则HSM的unhandledMessage将被调用。而HSM的派生类
  15. 可重载unhandledMessage函数以处理这个不能被当前状态及祖先状态处理的消息。
  16. */
  17. public boolean processMessage(Message message) {
  18. return HANDLED; // P0能处理任何Message
  19. }
  20. }
  21. class P1 extends State {......// 实现P1的enter,exit和processMessage函数}
  22. class S0 extends State {......// 实现S0的enter,exit和processMessage函数}
  23. ......// S1到S4的定义
  24. class S5 extends State {
  25. public void enter() {......// 实现S5的enter函数}
  26. public void exit() { ......// 实现S5的exit函数}
  27. public boolean processMessage(Message message) {
  28. switch(message.what){
  29. case: TRANSITION_CMD:
  30. transitionTo(mS4);// 切换状态时,需要调用此函数
  31. break;
  32. case: TRANSITON_CMD_DEFER_MSG:
  33. // deferMessage用于保留某个消息。而被保留的消息将留待到下一个状态中去处理
  34. deferMessage(message);
  35. transitionTo(mS1);
  36. break;
  37. default:
  38. break;
  39. }
  40. return HANDLED;
  41. }
  42. }
  43. ......// StateMachine其他一些可重载函数。以后碰到它们时再介绍
  44.  
  45. // 定义各个状态对应的对象
  46. private P0 mP0 = new P0(); private P1 mP1 = new P1();
  47. private S0 mS0 = new S0(); private S1 mS1 = new S1();
  48. private S2 mS2 = new S2(); private S3 mS3 = new S3();
  49. private S4 mS4 = new S4(); private S5 mS5 = new S5();
  50.  
  51. // 定义消息
  52. final static int TRANSITION_CMD = 0;
  53. final static int TRANSITON_CMD_DEFER_MSG = 1;
  54. }
  55. // 主函数
  56. public void main() throws Exception {
  57. StateMachineTest smTest = new StateMachineTest("StateMachineTest");
  58. smTest.start(); // 启动状态机
  59. synchronized (sm5) {
  60. // 外界只能通过obtainMessage以及sendMessage发送消息给SM去执行
  61. smTest.sendMessage(obtainMessage(TRANSITION_CMD));
  62. smTest.sendMessage(obtainMessage(TRANSITON_CMD_DEFER_MSG));
  63. ......
  64. }
  65. ......
  66. }
  67. }

上面代码介绍了HSM中一些重要的API。

·addState:添加一个状态。同时还可指定父状态。

·transitionTo:将状态机切换到某个状态。

·obtainMessage:由于HSM内部是围绕一个Handler来工作的,所以外界只能调用HSM的obtainMessage以获取一个Message

·sendMessage:发送消息给HSM。HSM中的Handler会处理它。

·deferMessage:保留某个消息。该消息将留待下一个新状态中去处理。其内部实现就是把这些被deferred的message保存到一个队列中。当HSM切换到新状态后,这些deferred消息将被移到HSM内部Handler所对应消息队列的头部,从而新状态能首先处理这些deferred消息。

·start:启动状态机。

·停止状态机可使用quit或quitNow函数。这两个函数均会发送SM_QUIT_CMD消息给HSM内部的Handler,不过效果略有区别。当使用quit时,SM_QUIT_CMD添加在消息队列尾;而使用quitNow时,SM_QUIT_CMD被添加到消息队列头。

HSM中状态和状态之间的层级关系体现在哪些方面呢?以上述代码为例:

·SM启动后,初始状态的EA将按派生顺序执行。即其祖先状态的EA先执行,子状态的EA后执行。以示例代码中的初始状态mS5为例。当HSM的start调用完毕后,EA调用顺序为mP0、mP1、mS1、mS5。

·当State发生切换时,旧State的exit先执行,新State的enter后执行,并且新旧State派生树上对应的State也需要执行exit或enter函数。以mS5切换到mS4为例,在此切换过程中,首先执行的是EXA,其顺序是mS5,mS1。注意,EXA执行的终点是离mS4和mS5最近的一个公共(即同时是mS4和mS5的祖先)祖先State(此处是mP1),但公共祖先状态的EXA不会执行。然后执行的是EA,其顺序是mS2、mS4。同理,公共祖先的EA也不会执行。细心的读者可以发现,HSM中EA和EXA执行顺序和C++类构造/析构函数执行顺序类似。EA执行顺序由祖先类开始直至子孙类,而析构函数的执行先从子孙类开始,直到祖先类。

·State处理Message时,如果子状态不能处理(返回NOT_HANDLED),则交给父状态去处理。这一点也和C++中类的派生函数类似。

HSM的介绍就到此为止,感兴趣的读者可自行研究HSM的实现。

2.AsyncChannel使用

AsyncChannel用于两个Handler之间的通信,其用法包含两种不同的应用模式(usage model)。

·简单的request/response模式下,Server端无须维护Client的信息,它只要处理来自Client的请求即可。连接时,Client调用connectSync(同步连接)或connect(异步连接,连接成功后Client会收到CMD_CHANNEL_HALF_CONNECTED消息)即可连接到Server。

·与request/response模式相反,AsyncChannel中另外一种应用模式就是Server端维护Client的信息。这样,Server可以向Client发送自己的状态或者其他一些有意义的信息。与这种模式类似的应用场景就是第4章介绍的wpa_cli和wpa_supplicant。wpa_cli可以发送命令给WPAS去执行。同时,WPAS也会将自己的状态及其他一些消息通知给wpa_cli。

在WifiService相关模块中,第二种应用模式使用得较多。另外,AsyncChannel中Client和Server端在最开始建立连接关系时,可以采用同步或异步的方式。以异步方式为例介绍第二种应用模式中AsyncChannel的使用步骤。

1)Client调用AsyncChannel的connect函数。Client的Handler会收到一个名为CMD_CHANNEL_HALF_CONNECTED消息。

2)Client在处理CMD_CHANNEL_HALF_CONNECTED消息时,需通过sendMessage函数向Server端发送一个名为CMD_CHANNEL_FULL_CONNECTION的消息。

3)Server端的Handler将收到此CMD_CHANNEL_FULL_CONNECTION消息。成功处理它后,Server端先调用AsyncChannel的connected函数,然后通过sendMessage函数向Client端发送CMD_CHANNEL_FULLY_CONNECTED消息(特别注意,详情见下文)。

4)Client端收到CMD_CHANNEL_FULLY_CONNECTED消息。至此,Client和server端成功建立连接。

5)Client和Server端的两个Handler可借助sendMessage和replyToMessge来完成请求消息及回复消息的传递。注意,只有针对那些需要回复的情况,Server端才需调用replyToMessage。

6)最后,Client和Server的任意一端都可以调用disconnect函数以结束连接。该函数将导致Client和Server端都会收到CMD_CHANNEL_DISCONNECTED消息。

特别说明 上述步骤的描述来自AsyncChannel.java文件中的注释。但实际上Server端代码在处理CMD_CHANNEL_FULL_CONNECTION消息时并不能按照上面的描述开展工作。因为AsyncChannel对象一般由客户端创建,而CMD_CHANNEL_FULL_CONNECTION消息无法携带AsyncChannel对象(AsyncChannel对象无法通过Binder进行跨进程传递)。所以,Server端并不能获取客户端创建的这个AsyncChannel对象,它也就没办法调用AsyncChannel的connected函数。

那么,Server端的正确处理应该是什么样子呢?接下来将通过代码向读者展示正确的做法。

下面结合WifiManager中的相关代码来介绍AsyncChannel中第二种模式涉及的一些重要函数。

WifiManager的init函数中会创建一个AsyncChannel以和WifiService中的某个Handler建立连接关系,代码如下所示。

[—>WifiManager.java::init]

  1. private void init() {
  2. /*
  3. 该函数内部通过Binder机制调用WifiService的getWifiServiceMessgener函数,返回值
  4. 是一个类型为Messagener的对象。Messgener从Parcelable派生,其内部有一个IMessenger
  5. 对象用于支持跨进程的Binder通信
  6. WifiService中,getWifiServiceMessgener的代码如下。
  7. public Messenger getWifiServiceMessenger() {
  8. ......// 权限检查
  9. return new Messenger(mAsyncServiceHandler);// 通过Messenger封装了目标Handler
  10. }
  11. */
  12.  
  13. mWifiServiceMessenger = getWifiServiceMessenger();
  14. ......
  15. // 创建一个HandlerThread。对HandlerThread不熟悉的读者请参考脚注
  16. sHandlerThread = new HandlerThread("WifiManager");
  17. sHandlerThread.start();
  18.  
  19. // Client中的Handler,它将运行在sHandlerThread线程中
  20. // AsyncChannel对Client Handler运行在什么线程没有要求
  21. mHandler = new ServiceHandler(sHandlerThread.getLooper());
  22. /*
  23. connect是AsyncChannel的重要函数。此处使用的connect函数原型如下:
  24. connect(Context srcContext, Handler srcHandler, Messenger dstMessenger)
  25. srcContext:为Client端的Context对象,AsyncChannel内部将使用它。
  26. srcHandler:为Client端的Handler。
  27. dstMessgener:是Server端Handler在Client端的代表。
  28. */
  29. mAsyncChannel.connect(mContext, mHandler, mWifiServiceMessenger);
  30. ......
  31. }

connect函数将触发Client端Handler收到一个CMD_CHANNEL_HALF_CONNECTED消息。马上来看WIfiManager中ServiceHandler。

[—>WifiManager.java::ServiceHandler]

  1. private class ServiceHandler extends Handler {
  2. ......// 此处只关注和AsyncChannel相关的内容
  3. public void handleMessage(Message message) {
  4. ......
  5. switch (message.what) {
  6. case AsyncChannel.CMD_CHANNEL_HALF_CONNECTED:// 半连接成功
  7. if (message.arg1 == AsyncChannel.STATUS_SUCCESSFUL) {
  8. // 向Server端发送CMD_CHANNEL_FULL_CONNECTION消息
  9. mAsyncChannel.sendMessage(AsyncChannel
  10. .CMD_CHANNEL_FULL_CONNECTION);
  11. }......
  12. break;
  13. case AsyncChannel.CMD_CHANNEL_FULLY_CONNECTED: // 连接成功
  14. break;
  15. case AsyncChannel.CMD_CHANNEL_DISCONNECTED:// 连接关闭
  16. mAsyncChannel = null;
  17. getLooper().quit();// 连接关闭,退出线程
  18. break;
  19. ......
  20. }
  21. ......
  22. }

WifiService中的目标Handler是AsyncServiceHandler,其代码如下所示。

[—>WifiService::AsyncServiceHandler]

  1. private class AsyncServiceHandler extends Handler {
  2. ......
  3. // 请读者先看它是如何处理CMD_CHANNEL_FULL_CONNECTION消息的
  4. public void handleMessage(Message msg) {
  5. switch (msg.what) {
  6. case AsyncChannel.CMD_CHANNEL_HALF_CONNECTED: {
  7. // 处理因ac.connect调用而收到的CMD_CHANNEL_HALF_CONNECTED消息
  8. // 该消息携带了一个AsyncChannel对象,即ac
  9. if (msg.arg1 == AsyncChannel.STATUS_SUCCESSFUL) {
  10. // 保存这个AsyncChannel对象,用于向Client发送消息
  11. mClients.add((AsyncChannel) msg.obj);
  12. /*
  13. 注意,Server端可在此处向Client端发送CMD_CHANNEL_FULLY_CONNECTED消息。
  14. 例如:
  15. AsyncChannel sample = (AsyncChannel) msg.obj;
  16. sample.sendMessage(AsyncChannel.CMD_CHANNEL_FULLY_CONNECTED);
  17. */
  18. }
  19. break;
  20. }
  21. case AsyncChannel.CMD_CHANNEL_DISCONNECTED: {
  22. mClients.remove((AsyncChannel) msg.obj);
  23. break;
  24. }
  25. case AsyncChannel.CMD_CHANNEL_FULL_CONNECTION: {// Server端先收到此消息
  26. /*
  27. 新创建一个AsyncChannel对象ac,然后调用它的connect函数。其中:
  28. msg.replyTo代表Client端的Handler,也就是WifiManager中ServiceHandler。
  29. connect函数将触发CMD_CHANNEL_HALF_CONNECTED消息被发送,而且该消息
  30. 会携带对应的AsyncChannel对象,即此处的ac。
  31. 请读者回到handleMessage的前面去看CMD_CHANNEL_HALF_CONNECTED的处理。
  32. */
  33. AsyncChannel ac = new AsyncChannel();// 创建一个新的AsyncChannel对象
  34. ac.connect(mContext, this, msg.replyTo);
  35. break;
  36. }
  37. ......
  38. }
  39. }

根据WifiService的代码并结合上文“特别说明”,由于Server端无法得到Client端的AsyncChannel对象,所以它干脆自己又新创建了一个AsyncChannel,并connect到客户端。这样,Server和Client端实际上有两个不同的AsyncChannel对象,并且都需要调用connect函数。

提示 如果AsyncChannel支持跨进程传递,那么Server端只要获取Client端传递过来的AsyncChannel对象,并调用其connected(注意,不是connect)函数即可。

介绍完HSM和AsyncChannel后,马上来看WifiService的创建和相关的初始化工作。

 关于Android中Handler的实现原理,读者可阅读《深入理解Android:卷Ⅰ》5.4节。

 关于Java Binder的实现机制,读者可参考《深入理解Android:卷Ⅱ》第2章。