導讀
調(diào)試是軟件開發(fā)中必不可少的環(huán)節(jié)。 調(diào)試集成操作系統(tǒng)與調(diào)試桌面操作系統(tǒng)非常不同。 內(nèi)置系統(tǒng)的視覺調(diào)試功能比桌面操作系統(tǒng)的視覺調(diào)試功能稍低。 對于具有復雜業(yè)務場景(例如導航)的程序的開發(fā)，我們可以使用可視化調(diào)試環(huán)境以較少的精力開發(fā)業(yè)務場景，快速定位在業(yè)務之間的交互中出現(xiàn)的問題。 導航和其他車輛模塊，以及開發(fā)過程中的調(diào)試效率。 提高。
遠程調(diào)試是真機調(diào)試中最便捷的一種，開發(fā)者只需借用在PC端強大的調(diào)試器就能完成業(yè)務場景的調(diào)試。
背景
Thrift是一種接口描述語言和二進制通訊協(xié)議，它被用來定義和創(chuàng)建跨語言的服務，是一種RPC(遠程過程調(diào)用)通信框架，由Facebook為“大規(guī)?？缯Z言服務開發(fā)”。在車機系統(tǒng)中，各模塊之間也可以使用Thrift通信框架進行通信。導航作為一個單獨的為進程提供服務的模塊，只提供導航相關(guān)的業(yè)務以及地圖渲染的能力，導航的HMI界面是車機系統(tǒng)中統(tǒng)一的操作界面，系統(tǒng)HMI界面與導航之間的交互接口則是通過已經(jīng)定義好的接口描述語言(IDL)，使用自動化工具生成本地可調(diào)用的接口，然后使用Thrift框架傳輸完成系統(tǒng)HMI與導航之間的通信。
調(diào)試手段
為了開發(fā)過程中調(diào)試方便，我們在PC上做了一套模擬器，能在PC上進行地圖渲染。還實現(xiàn)了一套在PC上使用的系統(tǒng)HMI模擬命令發(fā)送工具，模擬工具是作為客戶端連接導航提供的服務，這樣能在PC端模擬發(fā)送命令，幫助導航簡單業(yè)務的開發(fā)，但這種方式存在著以下弊端：
模擬命令工具，只能模擬簡單的業(yè)務場景，有多個交互的場景無法模擬。
無法操作地圖HMI，也看不到HMI界面顯示以及過程中的反饋。
無法滾動地圖，后面接了Win32上面的鼠標事件，能用鼠標實現(xiàn)滾動，但這種方式與車機中滾動流程不一致。
PC端無法使用車機中的設(shè)備，如導航過程中沒有導航音，無法使用USB等。
PC端拿不到車機中的數(shù)據(jù)，比如車身數(shù)據(jù)、GPS信號等。
調(diào)試方案優(yōu)化
針對當前調(diào)試手段存在的以上問題。我們對調(diào)試方案進行了優(yōu)化，我們可以借助車機中系統(tǒng)HMI來與導航進行交互。實現(xiàn)了使用車機環(huán)境中的信號對PC端導航業(yè)務場景進行調(diào)試。主要有以下幾點功能：
1.PC端模擬器接收車機發(fā)來的信號
在該項目中，導航的相關(guān)業(yè)務都是作為服務端向車機中其他模塊提供服務，在車機系統(tǒng)中，系統(tǒng)HMI連接導航服務的地址是固定的，我們在車機中開發(fā)了一個代理--Sandwich，主要作用是啟動導航服務，這個導航服務并不實現(xiàn)真正的導航業(yè)務，而是啟動了一個空服務，讓車機中其他模塊能成功建立連接，同時Sandwich作為客戶端連接PC端模擬器提供的導航服務，PC端的導航服務真正實現(xiàn)導航業(yè)務，Sandwich負責接收車機發(fā)送過來的業(yè)務請求，并將請求轉(zhuǎn)發(fā)給PC端模擬器，這樣PC端模擬器就能接收到車機中的信號，收到的業(yè)務請求并做處理再將處理結(jié)果通過Thrift反饋到車機端。
這個流程我們打通了車機中信號發(fā)送到PC端模擬器，并可以將處理完的數(shù)據(jù)反饋給車機端。
2.PC端模擬器向車機發(fā)送信號
導航也需要連接車機中其他模塊提供的服務，如，獲取車身數(shù)據(jù)、獲取GPS定位信號，將導航語音數(shù)據(jù)發(fā)送到車機語音播放模塊等。
PC端模擬器需要作為客戶端來連接車機中的服務，真正連接的是車機中Sandwich提供的服務，Sandwich作為客戶端連接車機中其他模塊的服務，比如Sandwich連接Sound模塊，GPS模塊，CarData模塊等。PC端模擬器需要使用車機設(shè)備播放導航音，需要將播放內(nèi)容發(fā)送給Sandwich，Sandwich收到播放內(nèi)容后，再發(fā)送給車機中的Sound模塊，導航音就能播放了。PC端連接車機中其他模塊的工作原理也是一樣。
3. 將PC端模擬器中顯示的地圖投射到車機端顯示
實現(xiàn)了以上兩步，一個使用車機信號調(diào)試PC端導航程序的環(huán)境基本完成了。已經(jīng)能實現(xiàn)車機信號與PC進行雙向接收，但是此時導航的渲染能力還是停留在PC端，車機中還只是顯示了一個系統(tǒng)HMI界面，無法看到導航地圖展現(xiàn)的效果，這樣就會帶來一個問題，一些需要強依賴地圖的操作可能就無法精準操作，比如點擊地圖上某個POI等。此時需要將PC端的展現(xiàn)同步到車機側(cè)。
要實現(xiàn)這一目的，一般我們有兩種方法：
車機與PC同步渲染
車機中的導航正常運行，當導航接收到系統(tǒng)模塊業(yè)務請求時，先是車機導航進行處理，處理完畢后將信號轉(zhuǎn)發(fā)到PC端處理，這種方案兩端導航業(yè)務邏輯并行運行，復雜的業(yè)務場景下，兩端會同時跟車機進行交互，此時可能會產(chǎn)生互斥，會有兩端邏輯不同步的場景，達不到預期效果。
將車機中渲染的數(shù)據(jù)投射到車機端
在這里我們可以將PC上程序每渲染一幀地圖則將結(jié)果傳到車機端，由車機端Sandwich負責接收，當Sandwich接收到一幀地圖像素數(shù)據(jù)后，負責將此幀數(shù)據(jù)渲染到車機屏幕上，此時車機中呈現(xiàn)的效果跟PC端一致。在該項目中我們采用了這一方案，這種方案中，真正的導航業(yè)務邏輯是來自PC端，車機中只是一個轉(zhuǎn)發(fā)過程，所以不會存在第一種方案中的問題。
但在某些特定的環(huán)境下，導航描畫會很頻繁，發(fā)送給車機的數(shù)據(jù)也會很多，頻繁的數(shù)據(jù)發(fā)送可能會帶來一定的性能開銷，表現(xiàn)上可能會出現(xiàn)延遲。這里可以使用降低圖像質(zhì)量來減少圖像數(shù)據(jù)，例如，可以使用16位或者8位BMP來傳輸，還可以壓縮傳輸，這樣1920*720分辨率圖像傳輸大小能控制在30-50k左右。
小結(jié)
基于車機系統(tǒng)中Thrift通信框架，實現(xiàn)的這套遠程調(diào)試方案，實質(zhì)是在車機中使用Sandwich程序接管車機系統(tǒng)中與導航有交互的全部接口處理，通過RPC通信轉(zhuǎn)發(fā)，實現(xiàn)了使用真實車機信號調(diào)試導航的目的。有了這套調(diào)試環(huán)境，我們甚至可以直接在真車上邊路測邊調(diào)試，跟以前的路測拿Log回來分析、重現(xiàn)相比，整個調(diào)試過程，簡單，便捷，直觀。大大提高了開發(fā)效率。
基于RPC通信的特性，我們還可以對調(diào)試方案再進一步優(yōu)化，可以加入多客戶端調(diào)試功能，使用同一臺車機環(huán)境，不同的模塊負責人可以同時進行復雜業(yè)務場景的聯(lián)合調(diào)試。
下載文檔
