一種高效車內設備間通信狀態管理器的研究

張藝杰，鄭敏，程斌，劉全

(1.上海大學自動化系,上海，200444；2.濱州市國土空間生態修復中心，山東濱州，256600）

0 引言

車聯網的概念源于物聯網，是以行駛中的車輛為信息感知對象，借助新一代信息通信技術[1-3]，實現車與X（即車與車、人、路、服務平臺）之間的網絡連接，其中，車與人間的通信是指用戶可以通過Wi-Fi、藍牙、蜂窩等無線通信[4]手段與車輛進行信息溝通，使用戶能通過對應的移動終端設備監測并控制車輛[5]。

比較經典的應用場景是車載投屏，即手機應用投射于車機系統?，F行的車載投屏軟件主要有蘋果公司開發的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）分支間的綜合操作，需要設立通用的規則，規則不能覆蓋的地方，可以通過補丁的方式完善。

本文所提出的這種狀態管理器，對于降低耦合，提高可擴展性很有幫助，但也應當指出，如果遇到壓力測試，這種管理器并沒有很好的方法克服異步通信的時序問題，由此可能引發狀態機錯誤。對此，如果沒有更細化的協議來糾正，則只能通過生成新的狀態糾正機制來克服，不過這不在本文的探討范圍內。