從應用工程師的角度再談車載 Android 系統
theme: scrolls-light
前言
根據中汽協資料顯示,2022年8月中國汽車出口量達30.8萬輛,同比增長65%,這也是歷史上首次超過30萬輛。從今年前八個月整體情況來看,我國汽車出口量已經超越德國,僅次於日本汽車出口量。其中,新能源汽車1-8月出口量同比增長超九成,貢獻了重要的增量。
眾所周知,今年網際網路行業發展的並不愉快,導致網際網路行業就業形勢不太理想,“開猿節流”的事情時有發生,於是不少Android開發萌生了轉行做車載的想法,之前我其實寫過一篇湊數用得 Android車載應用開發與分析(11)- 車載Android應用開發入門指南,這篇文章的初衷其實是勸Android開發的同學慎重轉行搞車載!
不過還是有些和我一樣是從手機應用轉行做車載應用的同學讀完後,希望我能再詳細講講車載Android的學習,一些準備做車載的同學,也認為之前的部落格寫得太亂,於是決定從一個車載應用工程師的角度,重新來講講車載Android系統。
車載作業系統
汽車作業系統是從傳統汽車電子不斷演變而來的,傳統汽車電子產品可分為兩類:
一類是汽車電子控制裝置,通過直接向執行機構(如電子閥門、繼電器開關、執行馬達)傳送指令,以控 制車輛關鍵部件(如發動機、變速箱、動力電池)協同工作,這類系統一般統稱為電子控制單元(ECU);
另一類是車載電子裝置,如儀表、娛樂音響、導航系統、HUD等,這類系統不直接參與汽車行駛的控制 決策,不會對車輛行駛效能和安全產生影響,通常統稱為車載資訊娛樂系統(IVI)。這也是Android程式設計師主要負責的領域。
主流車載作業系統架構
當前國內主流車載作業系統的架構如上所示,左側是汽車的中控、副駕螢幕,作業系統一般是Android,右側是汽車的儀表螢幕,一般是QNX系統。
車載系統中還有一些Security、SOA、AutoSAR相關的模組,這些模組作為Android工程師屬於知道了也插不上手,畫出來也看不懂的東西,就全部省略了。
先來解釋幾個Android程式設計師可能不太熟悉的模組:
乙太網
乙太網(Ethernet),是一種計算機區域網技術,也是網際網路從業者,天天打交道的東西。在汽車座艙中IVI硬體與其他硬體間通訊有時需要藉助乙太網來實現,例如:MQTT、HTTP等。
CAN
控制器區域網 (Controller Area Network,簡稱CAN或者CAN bus) 是一種功能豐富的車用匯流排標準。被設計用於在不需要主機(Host)的情況下,允許網路上的微控制器和儀器相互通訊。 它基於訊息傳遞協議,設計之初在車輛上採用複用通訊線纜,以降低銅線使用量,後來也被其他行業所使用。
CAN 是車載領域很重要的一種通訊匯流排,我們在中控屏上可以隨時檢視、設定車門、發動機、後備箱這些模組,其實就是藉助CAN bus實現的,即使是Android程式設計師也經常要和它打交道,以後會詳細講講這個東西。
MCU
微控制器單元,它負責著汽車很大一部分的功能,例如通過車載控制器對各項資料進行分析處理,以做出最優決策;負責對車輛的資訊娛樂互動和運動控制等等。
總的來說,MCU可以應用於車輛的通訊、能源、儲存、感知以及計算,對汽車行業有著重要的作用。
SOC
SoC的定義多種多樣,由於其內涵豐富、應用範圍廣,很難給出準確定義。一般說來, SoC稱為系統級晶片,也有稱片上系統(System on Chip),意指它是一個產品,是一個有專用目標的積體電路,其中包含完整系統並有嵌入軟體的全部內容。
車載Soc和常見的手機Soc非常類似,內部集成了CPU和GPU。目前最主流的車載Soc是高通的8155,它就是高通在手機Soc驍龍855的基礎上發展而來的。
QNX
QNX是商業類Unix實時作業系統,主要針對嵌入式系統市場。QNX採取微核心架構,作業系統中的多數功能是以許多小型的task來執行,它們被稱為server。這樣的架構使得使用者和開發者可以關閉不需要的功能,而不需要改變作業系統本身。
QNX的應用十分廣泛,被廣泛應用於汽車、軌道交通、航空航天等對安全性、實時性要求較高的領域,在汽車領域的市場佔有率極高。
該產品開發於20世紀80年代初,後來改名為QNX軟體系統公司,公司已被黑莓公司併購。
Hypervisor
一種執行在基礎物理伺服器和作業系統之間的中間軟體層,可允許多個作業系統和應用共享硬體。也可叫做VMM( virtual machine monitor ),即虛擬機器監視器。
目前國內主流的汽車座艙,都是在一個SOC上同時執行著兩個不同特性的作業系統。對娛樂、應用生態有需求的中控、副駕一般由Android系統控制,而對穩定性、安全性要求較高的儀表盤,則由QNX系統直接控制,Android可以看做是一個執行在QNX上的虛擬系統,其底層技術原理就是Hypervisor。
其實以上說得這些都是從Android工程師角度看到的車載作業系統,實際上這只是車載作業系統的冰山一角,最底層的Other Hardware更能代表智慧汽車作業系統的核心,它包含高階駕駛輔助系統、泊車輔助系統、自動駕駛系統、TCU、4G/5G閘道器、中央控制器等等。這些複雜的硬體與軟體共同組成了一個智慧汽車作業系統。
現代汽車的作業系統是如此的複雜,一些汽車的TCU、中央控制器甚至還額外執行著一套作業系統(例如linux),所以現在還沒有哪一個汽車/主機廠商能夠獨立完成整套系統的開發,基本都需要依賴大量的第三方軟、硬體供應商(筆者之前就是就職於一家汽車軟體供應商,不過現在已經處於提桶狀態了)。
好在作為Android程式設計師我們只需要關心Android系統的那部分。
車載 Android 系統
車載Android系統,又稱Android Automotive,是對原始Android系統的一個功能擴充版本,在編譯AOSP原始碼時可以看到相應的編譯選項。
Android Automotive 編譯後的原始介面如下所示,相信有過車載開發經驗的同學對這個介面一定不陌生,我們正是在這個介面上把車載Android系統一點點搭建起來的。
Android Automotive
Android Automotive 是一個基於 Android 平臺擴充套件後,適用於現代汽車的智慧作業系統,可以直接執行為Android系統開發的應用。Android Automotive並非Android的分支或並行開發版本。它與手機和平板電腦等裝置上搭載的Android使用相同的程式碼庫,位於同一個儲存區中。
Android Automotive與Android最大的區別在於,Android Automotive增加了對汽車特定要求、功能和技術的支援。
Google的官方文件:http://source.android.google.cn/docs/devices/automotive
Android Auto
除了Android Automotive,Google還推出了一個Android Auto。兩者的命名方式可能有點讓人迷惑不解。下面介紹了它們之間的區別:
- Android Auto 是一個基於使用者手機執行的平臺,可通過 USB 連線將 Android Auto 使用者體驗投射到相容的車載資訊娛樂系統。Android Auto本質上就是一個執行在Android系統上的車載應用,與蘋果的CarPlay,百度的CarLife類似。
- Android Automotive 是一個可定製程度非常高的開源Android平臺,它是一個完整的作業系統。
需要說明的是,使用Android Auto需要使用者的手機支援Google服務框架,所以一般只在國內銷售的汽車基本都不支援Android Auto,一些沿用了國外車機系統的合資車型可能會支援Android Auto。
車載 Android 應用
常見的車載應用
SystemUI
系統的UI。SystemUI
是一個標準的android應用程式,它提供了系統UI的統一管理方案。
常見的狀態列、導航欄、訊息中心、音量調節彈窗、藍芽連線彈窗等一系列後臺彈窗都是由SystemUI模組負責管理。
開發難度:SystemUI
作為Android系統啟動的第一個帶有UI的應用程式,對啟動效能和穩定性都有很高的要求。SystemUI
需要管理的模組非常多,導致開發任務比較繁重,有的車載專案會要求SystemUI
相容原有的應用層API,那麼開發難度還會上升。開發人員需要對Android原生的SystemUI
原始碼有一定的瞭解。
Launcher
Android系統的桌面。
開發難度:Launcher是與使用者互動最多的應用程式之一,同樣對啟動效能和穩定性都有很高的要求。Launcher開發難度主要集中在與3D車模的互動(如果有3D模型),可能需要支援Widget的顯示(WidgetHost),各種應用的拖動和編輯等。開發人員最好對Android原生的Launcher原始碼有一定的瞭解。
Settings
系統設定,是車載Android系統中非常重要的一個系統級應用,是整個車載IVI系統的控制中心,整車的音效、無線通訊、狀態資訊、安全資訊等等都是需要通過系統設定來檢視和控制。
開發難度:系統設定主要難度都集中在對Android Framework層API的理解上,例如藍芽、Wi-Fi設定就需要開發人員對系統級API有一定的瞭解,這些內容往往都需要閱讀Android原生應用的原始碼才能瞭解,所以系統設定也是一個開發難度比較大的車載應用。
CarService
車載Android系統的核心服務之一,所有應用都需要通過CarService來查詢、控制整車的狀態。例如:車輛的速度、檔位、點火狀態等等。
VehicleSettings
車輛設定,更常用的叫法是『車控車設』。負責管理整個車輛內外設定項的應用,主要與CarService進行資料互動。可設定項非常多。駕駛模式、方向盤助力、後視鏡摺疊、氛圍燈、座艙監測、無線充電等等。
開發難度:主要難度集中在複雜多變的UI,有的主機廠商會在HMI中引入3D化的互動模型,就還需要考慮與3D模型間的通訊,同時還需要熟練運用CAN工具來模擬汽車的CAN訊號用於除錯和開發。
HVAC
空調。負責管理整個車輛空調的應用,主要與CarService進行資料互動。
開發難度:和『車控車設』類似。
Map
地圖,車載系統的核心功能之一,負責導航和語音提示等功能。不同的主機廠商有不同的開發方式。不外乎有三種:
1)選擇使用百度、高德的地圖SDK自行開發導航應用;
2)將導航模組外包給百度、高德,由地圖供應商進行定製化開發;
3)直接整合地圖供應商已有的車載版本的應用;
開發難度:主要集中在對地圖SDK的運用和理解上,而且地圖應用屬於對效能要求較高的模組。
Multi-Media
多媒體應用。一般包含圖片瀏覽、線上音視訊播放器、USB音視訊播放器、收音機等。
車載的應用遠不止以上說得這些,根據不同的需求,還有非常多的Service需要做定製化開發,這裡只列舉了最常見的應用型別。
汽車上還會有一些第三方的應用,常見的有QQ音樂、微信、QQ、抖音、訊飛輸入法等等,這些應用主機廠商不會獲得原始碼,一般只會拿到一個apk,直接整合到Android系統中即可。
車載應用與移動應用的區別
誇張一點說,移動端的應用開發和車載應用開發,完全就不是一個技術思路。總結一下大致有以下幾個區別:
1)應用級別不同
多數車載應用屬於系統級應用,可以呼叫Android SDK內部隱藏的API,也不需要動態地向用戶申請許可權。移動應用是普通應用,系統對其限制很多,需要遵守Android應用的開發規範。
由於車載應用是系統級應用,所以移動端很多常用的技術比如熱修復、外掛化基本都不會採用,但是相對的程序保活、開機自啟就變得非常簡單了。
2)迭代方式不同
移動應用只要使用者的手機接入了WiFi就可以進行線上升級,所以移動應用多采用小步快跑的形式,進行快速迭代。
車載系統級應用的更新只能以整車OTA的形式進行,而OTA可能會消耗寶貴的車機流量,所以車載應用在SOP(量產)前,就必須完成全部需求的開發,而且不能出現嚴重的bug。在正式交付使用者前,車廠內部或4S店還會進行幾次OTA升級用做最後的bug修復。(如果在交付使用者後還有嚴重的bug或需求未完成,那麼大概率專案經理、程式設計師都要祭天了)
3)技術路線不同
正是因為車載應用對穩定性的要求極高,所以車載應用在開發時,對待新型技術會非常的慎重,比如,目前只有少數主機廠商在使用Kotlin開發車載應用,畢竟Android Framework都還沒有改成Kotlin,大部分廠商對Kotlin的積極性不高。而且車載應用也不允許隨意使用開源框架,如果必須使用,務必注意框架的開源協議,以免給汽車廠商帶來不必要的麻煩。
4)執行環境不同
車載應用的執行環境是經過高度定製化的Android系統,定製化也就意味著bug。移動端的應用出現bug時,我們的第一反應是應用的程式碼有缺陷。車載應用發現bug也要考慮到是不是系統本身出現了bug,這是一件非常有挑戰性的事,應用開發與系統開發相互扯皮、潑髒水也屬於家常便飯。
車載應用需要掌握的技能
除了一般Android開發需要學習的基礎內容外,一名優秀的車載應用工程師還需要掌握以下的技能
1)MVVM架構
雖然如今一些移動端應用已經開始嘗試MVI架構,但是就像前面說得,車載應用對待新技術都會持觀望態度,目前主流的車載應用還是採用基於Jetpack元件的MVVM架構。
2)構建系統級應用
由於多數車載應用都屬於系統級應用,所以必須瞭解如何構建一個系統級應用,這方面的內容可以看我之前寫得Android車載應用開發與分析(11)- 車載Android應用開發入門指南,雖然寫得比較亂湊活看吧。
還有一本比較老的書《Android深度探索:系統應用原始碼分析與ROM定製》也可以看一看。
3)效能優化
應用的效能優化是個亙古不變的話題,掌握應用的各種效能優化方式,也是一個Android程式設計師必備的生存手段,汽車座艙的SOC效能比旗艦手機要差不少,如果優化好車載應用將是一個非常有挑戰性的任務。
4)IPC通訊
Android中最常用的跨程序通訊手段是Binder,因為有大量的Service需要與應用進行互動,所以基於Binder的AIDL在車載應用開發中使用得非常廣泛,學會使用AIDL也同樣屬於必備技能之一。
5)CAN模擬測試工具
CAN模擬測試工具包含了軟體和硬體,在車載應用開發時我們需要藉助這些工具來模擬傳送CAN效能給到IVI來除錯我們的應用,在實車除錯階段,也需要藉助這些工具來捕獲車輛的CAN訊號來分析一些bug。常用的有CAN alyzer、CANoe、TS-Master等等,這些工具價格都極其昂貴,獨自購買不現實,在車載應用開發務必把握學習和使用的機會。
6)系統應用原始碼
這一項是我認為最重要的,不少車載應用層專案都是反覆定製各種SystemUI、Launcher、Settings等等,讀懂Android系統應用原始碼對我們定製化開發這些應用有非常大的好處。
以上是一些我認為車載應用開發時需要掌握的技能,其他的一些諸如:adb除錯指令、Linux作業系統的運用、AOSP原始碼編譯也都需要額外學習,根據不同的需求,JNI、NDK等技術也有可能會用上。
車載應用開發者的未來
這篇文章的開頭提到了一則新聞,中國今年的汽車出口量已經超越德國僅次於日本,這似乎是一個振奮人心的訊息。汽車工業的高速發展,對我們這些車載程式設計師當然屬於利好,但是最近的一則訊息又讓我改變了看法。
9月29日,零跑汽車正式赴港上市。成為眾人意料之外繼“蔚小理”後的又一新秀。但是零跑汽車的成績似乎並沒有得到資本市場的認可,在其上市首日,股價便遭遇大跌。根據資料顯示,9月29日當日收盤,零跑汽車的股價為31.9港元/股票,相較發行價暴跌33.54%。而隨後的半個月以來,零跑汽車的股價更是下跌56%,市值蒸發343億港元。
一邊是汽車出口量大增,另一邊是新勢力造車第二梯隊的零跑上市即破發,並且兩個交易日股價即腰斬,雖然有疊加疫情的影響,但這也說明了資本市場對造車企業的熱情正在顯著減弱,如果投資人賺不到豐厚的回報,那麼以後的車企日後想要再從市場融資,恐怕不會是一件輕鬆的事。
以上說得都是大環境,但是作為技術人本職工作還是磨鍊自己的技術為主。
回過頭我們還要再看一下這張架構圖,圖中標藍的部分是應用開發可以發揮的地方。不知道你有沒有發現,應用實際上在車載作業系統中佔據的比例很小,而且技術門檻也不高,這基本決定了在車載這個領域,單純的Android應用開發前景並不廣闊。
但是龐大的車載系統讓應用開發者有了繼續深入研究與實踐的可能,那麼是卷Framework
還是Native
或是HAL
就需要你自己決定了!
最後總結一句,移動端的應用開發和車載應用開發,本質上走得兩套技術路線,所以要慎重轉行!如果已經決定,請務必趁早!
- Android車載應用開發與分析(1) - Android Automotive概述與編譯
- 【Android R】車載 Android 核心服務 - CarService 解析
- 【Android R】車載 Android 核心服務 - CarPropertyService
- 車載Android程式設計師的2022年終總結與轉行建議
- 從應用工程師的角度再談車載 Android 系統
- Android 車載應用開發與分析(12) - SystemUI (一)
- RE: 從零開始的車載Android HMI(三) - SurfaceView
- RE: 從零開始的車載Android HMI(二) - Widget
- RE: 從零開始的車載Android HMI(一) - Lottie
- Android 車載應用開發與分析 (3)- 構建 MVVM 架構(Java版)
- Android 車載應用開發與分析 (4)- 編寫基於AIDL 的 SDK