一种高效车内设备间通信状态管理器的研究

张艺杰，郑敏，程斌，刘全

(1.上海大学自动化系,上海，200444；2.滨州市国土空间生态修复中心，山东滨州，256600）

0 引言

车联网的概念源于物联网，是以行驶中的车辆为信息感知对象，借助新一代信息通信技术[1-3]，实现车与X（即车与车、人、路、服务平台）之间的网络连接，其中，车与人间的通信是指用户可以通过Wi-Fi、蓝牙、蜂窝等无线通信[4]手段与车辆进行信息沟通，使用户能通过对应的移动终端设备监测并控制车辆[5]。

比较经典的应用场景是车载投屏，即手机应用投射于车机系统。现行的车载投屏软件主要有苹果公司开发的Apple CarPlay[6]、Google开发的 Android Auto[7]、百度开发的Baidu CarLife[8]等。在车载投屏应用场景中，手机通常会做主设备，而车机做从设备，手机通过WiFi或USB通路将音视频数据传递至车机，同时两者间还会交互控制命令以及其他数据。车载投屏应用内含丰富的功能，以至于看上去像一个小型系统，对于这个系统，车载终端需要良好处理本地事件、设备间事件、状态同步等的关系。由此，一个高效的状态管理器应运而生。

本文在介绍设备交互状态管理器设计结构的同时，以Apple CarPlay为例做具体分析。

1 状态管理器概况

现行车载中控的操作系统以安卓[9]居多，本文状态管理器即以安卓为平台，该状态管理器主要针对车机的音频和视频资源。

音视频资源在投屏应用中会处于不同的状态，我们以模式的划分来区别不同的状态。模式可简单分为车机模式（本地模式）和手机模式（投射模式）。参照苹果公司MFi[10]中对于Apple CarPlay的规范，可将车机模式称为ACCESSORY模式，即从机（附件）模式，手机模式称为CONTROLLE模式，即主机（控制器）模式。处于ACCESSOR模式时，车机呈现本地的媒体资源；处于CONTROLLE模式时，车机的音视频资源被手机占用，此时播放手机的音视频媒体。MFi中还对模式的切换方式和切换约束做了细分，以区别对待不同的切换场景。对于切换方式，用TAKE、UNTAKE、BORROW、UNBORROW分别表示不同的占有时长；而切换约束（占用强度）则以ANYTIME、USER INITIAL、NEVER来表示。由此构建了一套简单有效的模式切换规则。

安卓界面的呈现借助于Activity机制，于Activity内配置Surface View，即可在Surface之上实现视频流的投射。由此，视频投射的管理转变为Activity创建与销毁的管理，更准确的说，是对Projection Activity（投屏活动）的管理。

在车联运行中，车载安卓系统会有高优先级的本地事件中断手机媒体的播放，常见的有倒车视频、安吉星（OnStar）电话、本地蓝牙电话等。这些都是临时性事件，不同于切换到本地媒体播放（如FM、USB音乐），临时事件结束后车机需要恢复到此前的手机媒体状态（如果此前是手机模式），以提供良好的用户体验，这就要求车机能够协调好本地事件和手机媒体资源。

由上可知，简单意义上，车载投屏系统主要需处理好模式的切换、Projection Activity的管控以及本地事件与手机资源的竞争关系。本文以视频状态管理器为例分析，音频状态管理器机制类似。

2 状态管理器设计思想

针对本文探讨的移动终端车载投屏这一应用场景，其管理视频资源的状态管理器基本设计理念如下：

（1）将事件分类、集束，对不同类别事件分别制定较为独立的流程，以降低耦合度，无法解开的耦合关系安排在流程的特定位置处理，以减少耦合的影响范围，将高圈复杂度限定在小范围中。

（2）单个处理流程中，将几种需要考虑的因素分阶段单独处理。因素中的关联成分会因此缺失，对此用补偿方式在流程靠后阶段加以弥补。对于流程中需要作判定的环节，制定通用规则作判定依据。

（3）对设备间模式切换记录做存储，用以参考。模式记录需要结合通信协议设计并具备纠错功能，由于是设备间异步通信，记录数据并非越详尽越好。

（4）在事件分类、集束的基础上，分别建立Projection Activity、本地事件、模式切换记录各自的微型状态机，通过减小状态机的规模达到简化逻辑复杂度、降低圈复杂度的目的。

3 状态管理器实现

3.1 迷你状态机

在设计流程之前我们需要先设计好数据结构，即迷你状态机，请参考图1，不再赘述。

图1 迷你状态机的设计

3.2 Projection Activity事件处理

接下来开始分析事件处理流程，首先是Projection Activity，流程分为几个阶段：

（1）依据接收到的Projection Activity状态更新本地记录信息。

（2）依据Projection Activity的当前状态，构建发往手机的模式切换信息，这里不考虑本地事件的状态。

（3）查看本地事件状态机，如果状态机中有处于ON状态的事件，根据Projection Activity的状态发送对应的模式切换消息。以Apple CarPlay为例，如果CarPlay Activity退至后台且有本地事件为ON，则向手机发送BORROW请求。相反，如果CarPlay Activity拉到前台，则要清算BORROW请求，因为此时车机处于CONTROLLER模式。那么此时虽然本地事件有发生，但用户行为将视频资源切换为了手机媒体资源。

（4）按照MFi中对Apple CarPlay的规范要求，BORROW和UNBORROW要一一对应，即多次借调后要在结束时全部清算。本套设计采用单BORROW模式，在发送一次新的BORROW前需要先清除上次的BORROW，这一清算安排在流程最后的冗余查询中。冗余查询要结合当前的模式、模式切换方式和模式切换约束，详见图2。

图2 Projection Activity事件处理流程

3.3 本地事件处理

本地事件的处理流程，整体上与Projection Activity事件处理结构类似。

（1）通过监听各种的本地事件，获取变更通知，以更新记录。

（2）修改记录信息。高优先级事件发生的时候可以中止低优先级事件；部分事件如锁屏事件，被中断后还要求能在中断事件结束后恢复锁屏。依据实际使用场景，事件的优先级可如图3所示。

图3 本地事件处理流程

（3）生成模式切换消息。

（4）清算，避免发送冗余的消息，以提高异步通信的鲁棒性。

（5）这里要介绍一下本流程的模式消息生成规则。本地事件借用视频资源的场景中，收到本地事件通知和CarPlay Activity退至后台都会查询到有本地事件为ON而试图发送BORROW，而两者的先后顺序并不能保证。为了解决这一异步问题，只在本地事件为ON且CarPlay Activity退至后台同时满足的情况下才会发送BORROW请求。而对于本地事件的结束通知，如果CarPlay Activity已经在前台，则当前模式已经是用于显示手机视频资源的CONTROLLER模式，已经清算了BORROW请求，不必再发送，故而本流程的模式消息生成规则只需考虑CarPlay Activity在后台的情况，详见图3。

3.4 模式同步事件处理

最后是模式同步的处理流程，此流程较为简单，重点在于及时准确的更新当前模式。避免因模式的错误而引起混乱，详见图4，不再赘述。

图4 模式同步事件处理流程

至此，状态管理器的核心部分完成设计，除此之外，还要结合项目需求、通信协议特点及其他因素，做出完善化设计，并为特殊用例加打补丁，以提高用例覆盖范围。这样，一种精简低耦合的状态管理器设计完毕。

4 总结

本文针对车载投屏应用场景提出了一种状态管理器的基本设计结构，对于其他车内设备互联的场景亦具有参考价值，其要点简述如下：

（1）几个相关领域尽量降低耦合，分成相对独立的几条分支。

（2）设立事件迷你状态机和设备间模式切换消息记录。

（3）在一条分支中，首先更新状态机，其次完成本分支单独的操作，最后综合其他分支的状态完成补偿操作。

（4）分支间的综合操作，需要设立通用的规则，规则不能覆盖的地方，可以通过补丁的方式完善。

本文所提出的这种状态管理器，对于降低耦合，提高可扩展性很有帮助，但也应当指出，如果遇到压力测试，这种管理器并没有很好的方法克服异步通信的时序问题，由此可能引发状态机错误。对此，如果没有更细化的协议来纠正，则只能通过生成新的状态纠正机制来克服，不过这不在本文的探讨范围内。