從應用工程師的角度再談車載 Android 系統_林栩link

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就需要你自己決定了！

最後總結一句，移動端的應用開發和車載應用開發，本質上走得兩套技術路線，所以要慎重轉行！如果已經決定，請務必趁早！