前言

根據(jù)中汽協(xié)數(shù)據(jù)顯示，2022年8月中國汽車出口量達30.8萬輛，同比增長65%，這也是歷史上首次超過30萬輛。從今年前八個月整體情況來看，我國汽車出口量已經(jīng)超越德國，僅次于日本汽車出口量。其中，新能源汽車1-8月出口量同比增長超九成，貢獻了重要的增量。

眾所周知，今年互聯(lián)網(wǎng)行業(yè)發(fā)展的并不愉快，導致互聯(lián)網(wǎng)行業(yè)就業(yè)形勢不太理想，“開猿節(jié)流”的事情時有發(fā)生，于是不少Android開發(fā)萌生了轉行做車載的想法，之前我其實寫過一篇湊數(shù)用得 Android車載應用開發(fā)與分析（11）- 車載Android應用開發(fā)入門指南，這篇文章的初衷其實是勸Android開發(fā)的同學慎重轉行搞車載！

不過還是有些和我一樣是從手機應用轉行做車載應用的同學讀完后，希望我能再詳細講講車載Android的學習，一些準備做車載的同學，也認為之前的博客寫得太亂，于是決定從一個車載應用工程師的角度，重新來講講車載Android系統(tǒng)。

車載操作系統(tǒng)

汽車操作系統(tǒng)是從傳統(tǒng)汽車電子不斷演變而來的，傳統(tǒng)汽車電子產(chǎn)品可分為兩類：

一類是汽車電子控制裝置，通過直接向執(zhí)行機構（如電子閥門、繼電器開關、執(zhí)行馬達）發(fā)送指令，以控 制車輛關鍵部件（如發(fā)動機、變速箱、動力電池）協(xié)同工作，這類系統(tǒng)一般統(tǒng)稱為電子控制單元（ECU）；

另一類是車載電子設備，如儀表、娛樂音響、導航系統(tǒng)、HUD等，這類系統(tǒng)不直接參與汽車行駛的控制 決策，不會對車輛行駛性能和安全產(chǎn)生影響，通常統(tǒng)稱為車載信息娛樂系統(tǒng)（IVI）。這也是Android程序員主要負責的領域。

主流車載操作系統(tǒng)架構

當前國內主流車載操作系統(tǒng)的架構如上所示，左側是汽車的中控、副駕屏幕，操作系統(tǒng)一般是Android，左側是汽車的儀表屏幕，一般是QNX系統(tǒng)。

車載系統(tǒng)中還有一些Security、SOA、AutoSAR相關的模塊，這些模塊作為Android工程師屬于知道了也插不上手，畫出來也看不懂的東西，就全部省略了。

先來解釋幾個Android程序員可能不太熟悉的模塊：

以太網(wǎng)

以太網(wǎng)（Ethernet），是一種計算機局域網(wǎng)技術，也是互聯(lián)網(wǎng)從業(yè)者，天天打交道的東西。在汽車座艙中IVI硬件與其他硬件間通信有時需要借助以太網(wǎng)來實現(xiàn)，例如：MQTT、HTTP等。

CAN

控制器局域網(wǎng) (Controller Area Network，簡稱CAN或者CAN bus) 是一種功能豐富的車用總線標準。被設計用于在不需要主機（Host）的情況下，允許網(wǎng)絡上的單片機和儀器相互通信。 它基于消息傳遞協(xié)議，設計之初在車輛上采用復用通信線纜，以降低銅線使用量，后來也被其他行業(yè)所使用。

CAN 是車載領域很重要的一種通信總線，我們在中控屏上可以隨時查看、設置車門、發(fā)動機、后備箱這些模塊，其實就是借助CAN bus實現(xiàn)的，即使是Android程序員也經(jīng)常要和它打交道，以后會詳細講講這個東西。

MCU

微控制器單元，它負責著汽車很大一部分的功能，例如通過車載控制器對各項數(shù)據(jù)進行分析處理，以做出最優(yōu)決策；負責對車輛的信息娛樂交互和運動控制等等。

總的來說，MCU可以應用于車輛的通訊、能源、存儲、感知以及計算，對汽車行業(yè)有著重要的作用。

SOC

SoC的定義多種多樣，由于其內涵豐富、應用范圍廣，很難給出準確定義。一般說來， SoC稱為系統(tǒng)級芯片，也有稱片上系統(tǒng)（System on Chip），意指它是一個產(chǎn)品，是一個有專用目標的集成電路，其中包含完整系統(tǒng)并有嵌入軟件的全部內容。

車載Soc和常見的手機Soc非常類似，內部集成了CPU和GPU。目前最主流的車載Soc是高通的8155，它就是高通在手機Soc驍龍855的基礎上發(fā)展而來的。

QNX

QNX是商業(yè)類Unix實時操作系統(tǒng)，主要針對嵌入式系統(tǒng)市場。QNX采取微核心架構，操作系統(tǒng)中的多數(shù)功能是以許多小型的task來執(zhí)行，它們被稱為server。這樣的架構使得用戶和開發(fā)者可以關閉不需要的功能，而不需要改變操作系統(tǒng)本身。

QNX的應用十分廣泛，被廣泛應用于汽車、軌道交通、航空航天等對安全性、實時性要求較高的領域，在汽車領域的市場占有率極高。

該產(chǎn)品開發(fā)于20世紀80年代初，后來改名為QNX軟件系統(tǒng)公司，公司已被黑莓公司并購。

Hypervisor

一種運行在基礎物理服務器和操作系統(tǒng)之間的中間軟件層，可允許多個操作系統(tǒng)和應用共享硬件。也可叫做VMM（ virtual machine monitor ），即虛擬機監(jiān)視器。

目前國內主流的汽車座艙，都是在一個SOC上同時運行著兩個不同特性的操作系統(tǒng)。對娛樂、應用生態(tài)有需求的中控、副駕一般由Android系統(tǒng)控制，而對穩(wěn)定性、安全性要求較高的儀表盤，則由QNX系統(tǒng)直接控制，Android可以看做是一個運行在QNX上的虛擬系統(tǒng)，其底層技術原理就是Hypervisor。

其實以上說得這些都是從Android工程師角度看到的車載操作系統(tǒng)，實際上這只是車載操作系統(tǒng)的冰山一角，最底層的Other Hardware更能代表智能汽車操作系統(tǒng)的核心，它包含高級駕駛輔助系統(tǒng)、泊車輔助系統(tǒng)、自動駕駛系統(tǒng)、TCU、4G/5G網(wǎng)關、中央控制器等等。這些復雜的硬件與軟件共同組成了一個智能汽車操作系統(tǒng)。

現(xiàn)代汽車的操作系統(tǒng)是如此的復雜，一些汽車的TCU、中央控制器甚至還額外運行著一套操作系統(tǒng)（例如linux），所以現(xiàn)在還沒有哪一個汽車/主機廠商能夠獨立完成整套系統(tǒng)的開發(fā)，基本都需要依賴大量的第三方軟、硬件供應商（筆者之前就是就職于一家汽車軟件供應商，不過現(xiàn)在已經(jīng)處于提桶狀態(tài)了）。

好在作為Android程序員我們只需要關心Android系統(tǒng)的那部分。

車載 Android 系統(tǒng)

車載Android系統(tǒng)，又稱Android Automotive，是對原始Android系統(tǒng)的一個功能擴充版本，在編譯AOSP源碼時可以看到相應的編譯選項。

Android Automotive 編譯后的原始界面如下所示，相信有過車載開發(fā)經(jīng)驗的同學對這個界面一定不陌生，我們正是在這個界面上把車載Android系統(tǒng)一點點搭建起來的。

Android Automotive

Android Automotive 是一個基于 Android 平臺擴展后，適用于現(xiàn)代汽車的智能操作系統(tǒng)，可以直接運行為Android系統(tǒng)開發(fā)的應用。Android Automotive并非Android的分支或并行開發(fā)版本。它與手機和平板電腦等設備上搭載的Android使用相同的代碼庫，位于同一個存儲區(qū)中。

Android Automotive與Android最大的區(qū)別在于，Android Automotive增加了對汽車特定要求、功能和技術的支持。

Android Auto

除了Android Automotive，Google還推出了一個Android Auto。兩者的命名方式可能有點讓人迷惑不解。下面介紹了它們之間的區(qū)別：

• Android Auto 是一個基于用戶手機運行的平臺，可通過 USB 連接將 Android Auto 用戶體驗投射到兼容的車載信息娛樂系統(tǒng)。Android Auto本質上就是一個運行在Android系統(tǒng)上的車載應用，與蘋果的CarPlay，百度的CarLife類似。

• Android Automotive 是一個可定制程度非常高的開源Android平臺，它是一個完整的操作系統(tǒng)。

需要說明的是，使用Android Auto需要用戶的手機支持Google服務框架，所以一般只在國內銷售的汽車基本都不支持Android Auto，一些沿用了國外車機系統(tǒng)的合資車型可能會支持Android Auto。

車載 Android 應用

常見的車載應用

SystemUI

系統(tǒng)的UI。SystemUI是一個標準的android應用程序，它提供了系統(tǒng)UI的統(tǒng)一管理方案。
常見的狀態(tài)欄、導航欄、消息中心、音量調節(jié)彈窗、藍牙連接彈窗等一系列后臺彈窗都是由SystemUI模塊負責管理。

開發(fā)難度：SystemUI作為Android系統(tǒng)啟動的第一個帶有UI的應用程序，對啟動性能和穩(wěn)定性都有很高的要求。SystemUI需要管理的模塊非常多，導致開發(fā)任務比較繁重，有的車載項目會要求SystemUI兼容原有的應用層API，那么開發(fā)難度還會上升。開發(fā)人員需要對Android原生的SystemUI源碼有一定的了解。

Launcher

Android系統(tǒng)的桌面。

開發(fā)難度：Launcher是與用戶交互最多的應用程序之一，同樣對啟動性能和穩(wěn)定性都有很高的要求。Launcher開發(fā)難度主要集中在與3D車模的互動（如果有3D模型），可能需要支持Widget的顯示（WidgetHost），各種應用的拖動和編輯等。開發(fā)人員最好對Android原生的Launcher源碼有一定的了解。

Settings

系統(tǒng)設置，是車載Android系統(tǒng)中非常重要的一個系統(tǒng)級應用，是整個車載IVI系統(tǒng)的控制中心，整車的音效、無線通信、狀態(tài)信息、安全信息等等都是需要通過系統(tǒng)設置來查看和控制。

開發(fā)難度：系統(tǒng)設置主要難度都集中在對Android Framework層API的理解上，例如藍牙、Wi-Fi設置就需要開發(fā)人員對系統(tǒng)級API有一定的了解，這些內容往往都需要閱讀Android原生應用的源碼才能了解，所以系統(tǒng)設置也是一個開發(fā)難度比較大的車載應用。

CarService

車載Android系統(tǒng)的核心服務之一，所有應用都需要通過CarService來查詢、控制整車的狀態(tài)。例如：車輛的速度、檔位、點火狀態(tài)等等。

VehicleSettings

車輛設置，更常用的叫法是『車控車設』。負責管理整個車輛內外設置項的應用，主要與CarService進行數(shù)據(jù)交互?？稍O置項非常多。駕駛模式、方向盤助力、后視鏡折疊、氛圍燈、座艙監(jiān)測、無線充電等等。

開發(fā)難度：主要難度集中在復雜多變的UI，有的主機廠商會在HMI中引入3D化的交互模型，就還需要考慮與3D模型間的通信，同時還需要熟練運用CAN工具來模擬汽車的CAN信號用于調試和開發(fā)。

HVAC

空調。負責管理整個車輛空調的應用，主要與CarService進行數(shù)據(jù)交互。

開發(fā)難度：和『車控車設』類似。

Map

地圖，車載系統(tǒng)的核心功能之一，負責導航和語音提示等功能。不同的主機廠商有不同的開發(fā)方式。不外乎有三種：

1）選擇使用百度、高德的地圖SDK自行開發(fā)導航應用；

2）將導航模塊外包給百度、高德，由地圖供應商進行定制化開發(fā)；

3）直接集成地圖供應商已有的車載版本的應用；

開發(fā)難度：主要集中在對地圖SDK的運用和理解上，而且地圖應用屬于對性能要求較高的模塊。

Multi-Media

多媒體應用。一般包含圖片瀏覽、在線音視頻播放器、USB音視頻播放器、收音機等。

車載的應用遠不止以上說得這些，根據(jù)不同的需求，還有非常多的Service需要做定制化開發(fā)，這里只列舉了最常見的應用類型。

汽車上還會有一些第三方的應用，常見的有QQ音樂、微信、QQ、抖音、訊飛輸入法等等，這些應用主機廠商不會獲得源碼，一般只會拿到一個apk，直接集成到Android系統(tǒng)中即可。

車載應用與移動應用的區(qū)別

夸張一點說，移動端的應用開發(fā)和車載應用開發(fā)，完全就不是一個技術思路。總結一下大致有以下幾個區(qū)別：

1）應用級別不同

多數(shù)車載應用屬于系統(tǒng)級應用，可以調用Android SDK內部隱藏的API，也不需要動態(tài)地向用戶申請權限。移動應用是普通應用，系統(tǒng)對其限制很多，需要遵守Android應用的開發(fā)規(guī)范。

由于車載應用是系統(tǒng)級應用，所以移動端很多常用的技術比如熱修復、插件化基本都不會采用，但是相對的進程保活、開機自啟就變得非常簡單了。

2）迭代方式不同

移動應用只要用戶的手機接入了WiFi就可以進行在線升級，所以移動應用多采用小步快跑的形式，進行快速迭代。

車載系統(tǒng)級應用的更新只能以整車OTA的形式進行，而OTA可能會消耗寶貴的車機流量，所以車載應用在SOP（量產(chǎn)）前，就必須完成全部需求的開發(fā)，而且不能出現(xiàn)嚴重的bug。在正式交付用戶前，車廠內部或4S店還會進行幾次OTA升級用做最后的bug修復。（如果在交付用戶后還有嚴重的bug或需求未完成，那么大概率項目經(jīng)理、程序員都要祭天了)

3）技術路線不同

正是因為車載應用對穩(wěn)定性的要求極高，所以車載應用在開發(fā)時，對待新型技術會非常的慎重，比如，目前只有少數(shù)主機廠商在使用Kotlin開發(fā)車載應用，畢竟Android Framework都還沒有改成Kotlin，大部分廠商對Kotlin的積極性不高。而且車載應用也不允許隨意使用開源框架，如果必須使用，務必注意框架的開源協(xié)議，以免給汽車廠商帶來不必要的麻煩。

4）運行環(huán)境不同

車載應用的運行環(huán)境是經(jīng)過高度定制化的Android系統(tǒng)，定制化也就意味著bug。移動端的應用出現(xiàn)bug時，我們的第一反應是應用的代碼有缺陷。車載應用發(fā)現(xiàn)bug也要考慮到是不是系統(tǒng)本身出現(xiàn)了bug，這是一件非常有挑戰(zhàn)性的事，應用開發(fā)與系統(tǒng)開發(fā)相互扯皮、潑臟水也屬于家常便飯。

車載應用需要掌握的技能

除了一般Android開發(fā)需要學習的基礎內容外，一名優(yōu)秀的車載應用工程師還需要掌握以下的技能

1）MVVM架構

雖然如今一些移動端應用已經(jīng)開始嘗試MVI架構，但是就像前面說得，車載應用對待新技術都會持觀望態(tài)度，目前主流的車載應用還是采用基于Jetpack組件的MVVM架構。

2）構建系統(tǒng)級應用

由于多數(shù)車載應用都屬于系統(tǒng)級應用，所以必須了解如何構建一個系統(tǒng)級應用，這方面的內容可以看我之前寫得Android車載應用開發(fā)與分析（11）- 車載Android應用開發(fā)入門指南，雖然寫得比較亂湊活看吧。

還有一本比較老的書《Android深度探索：系統(tǒng)應用源代碼分析與ROM定制》也可以看一看。

3）性能優(yōu)化

應用的性能優(yōu)化是個亙古不變的話題，掌握應用的各種性能優(yōu)化方式，也是一個Android程序員必備的生存手段，汽車座艙的SOC性能比旗艦手機要差不少，如果優(yōu)化好車載應用將是一個非常有挑戰(zhàn)性的任務。

4）IPC通信

Android中最常用的跨進程通信手段是Binder，因為有大量的Service需要與應用進行交互，所以基于Binder的AIDL在車載應用開發(fā)中使用得非常廣泛，學會使用AIDL也同樣屬于必備技能之一。

5）CAN仿真測試工具

CAN仿真測試工具包含了軟件和硬件，在車載應用開發(fā)時我們需要借助這些工具來模擬發(fā)送CAN性能給到IVI來調試我們的應用，在實車調試階段，也需要借助這些工具來捕獲車輛的CAN信號來分析一些bug。常用的有CAN alyzer、CANoe、TS-Master等等，這些工具價格都極其昂貴，獨自購買不現(xiàn)實，在車載應用開發(fā)務必把握學習和使用的機會。

6）系統(tǒng)應用源碼

這一項是我認為最重要的，不少車載應用層項目都是反復定制各種SystemUI、Launcher、Settings等等，讀懂Android系統(tǒng)應用源碼對我們定制化開發(fā)這些應用有非常大的好處。

以上是一些我認為車載應用開發(fā)時需要掌握的技能，其他的一些諸如：adb調試指令、Linux操作系統(tǒng)的運用、AOSP源碼編譯也都需要額外學習，根據(jù)不同的需求，JNI、NDK等技術也有可能會用上。

車載應用開發(fā)者的未來

這篇文章的開頭提到了一則新聞，中國今年的汽車出口量已經(jīng)超越德國僅次于日本，這似乎是一個振奮人心的消息。汽車工業(yè)的高速發(fā)展，對我們這些車載程序員當然屬于利好，但是最近的一則消息又讓我改變了看法。

9月29日，零跑汽車正式赴港上市。成為眾人意料之外繼“蔚小理”后的又一新秀。但是零跑汽車的成績似乎并沒有得到資本市場的認可，在其上市首日，股價便遭遇大跌。根據(jù)數(shù)據(jù)顯示，9月29日當日收盤，零跑汽車的股價為31.9港元/股票，相較發(fā)行價暴跌33.54%。而隨后的半個月以來，零跑汽車的股價更是下跌56%，市值蒸發(fā)343億港元。

一邊是汽車出口量大增，另一邊是新勢力造車第二梯隊的零跑上市即破發(fā)，并且兩個交易日股價即腰斬，雖然有疊加疫情的影響，但這也說明了資本市場對造車企業(yè)的熱情正在顯著減弱，如果投資人賺不到豐厚的回報，那么以后的車企日后想要再從市場融資，恐怕不會是一件輕松的事。

以上說得都是大環(huán)境，但是作為技術人本職工作還是磨煉自己的技術為主。

回過頭我們還要再看一下這張架構圖，圖中標藍的部分是應用開發(fā)可以發(fā)揮的地方。不知道你有沒有發(fā)現(xiàn)，應用實際上在車載操作系統(tǒng)中占據(jù)的比例很小，而且技術門檻也不高，這基本決定了在車載這個領域，單純的Android應用開發(fā)前景并不廣闊。

但是龐大的車載系統(tǒng)讓應用開發(fā)者有了繼續(xù)深入研究與實踐的可能，那么是卷Framework還是Native或是HAL就需要你自己決定了！

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