前言

根據中汽協數據顯示，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增加了對汽車特定要求、功能和技術的支持。

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

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