序文
中国自動車協会のデータによると、2022 年 8 月の中国の自動車輸出台数は、前年比 65% 増の 30.8 万台に達し、史上初めて 30 万台を超えました。今年の最初の 8 か月間の全体的な状況から判断すると、私の国の自動車輸出量はドイツを上回り、日本の自動車輸出量に次いで 2 番目です。その中で、1月から8月までの新エネルギー車の輸出台数は前年比90%以上増加し、重要な増加に貢献した。
ご存知のように、今年のインターネット業界の発展は快適ではなく、インターネット業界の雇用状況が不十分であり、「サルを開いて支出を削減する」ことが時々発生しているため、多くの Android 開発者がクルマ系の仕事に転職する考え. 実は以前記事を書いた. この記事はAndroidカーアプリの開発と分析に役立つ(11) - カーAndroidアプリ開発の入門ガイド, この記事の本来の意図は実際にはAndroid開発の学生を説得して、慎重に自動車業界に転職させよう！
ただ、私のようにモバイルアプリから車載アプリに乗り換えた学生もいるので、これを読んで車載Androidの学習について詳しく話せたらいいなと思っています。前回のブログがめんどくさいので、車載アプリケーションエンジニアの視点から車載Androidシステムについてお話しすることにしました。
車載OS
自動車のオペレーティング システムは、従来の自動車用電子機器から絶えず進化しています。従来の自動車用電子機器製品は、次の 2 つのカテゴリに分けることができます。
1 つは自動車の電子制御デバイスで、アクチュエータ (電子バルブ、リレー スイッチ、エグゼクティブ モーターなど) に指示を直接送信して、車両の主要コンポーネント (エンジン、ギアボックス、パワー バッテリーなど) を制御し、このようなシステムは、一般に電子制御ユニット (ECU) と呼ばれます。
もう 1 つのタイプは、計器、エンターテイメント オーディオ、ナビゲーション システム、HUD などの車載電子機器です。これらのシステムは、自動車の運転の制御意思決定に直接関与せず、自動車の運転性能に影響を与えません。および安全性は、通常、車載インフォテインメント システム (IVI) と総称されます。これは、Android プログラマーが主に担当する領域でもあります。
主流の車両オペレーティング システム アーキテクチャ
現在の国内の主流の車両オペレーティング システムのアーキテクチャを上に示します. 左側は自動車の中央制御および副操縦士の画面であり、オペレーティング システムは一般的に Android であり、右側は自動車の計器画面であり、通常は QNX システムです.
車載システムにもセキュリティやSOA、AutoSAR関連のモジュールがいくつかあり、これらのモジュールはAndroidのエンジニアとして知っていても差し込むことができず、入れられない場合はすべて省略されます彼らが描くものを理解します。
最初に、Android プログラマーがなじみのないモジュールをいくつか説明しましょう。
イーサネット
イーサネットは一種のコンピュータ ローカル エリア ネットワーク技術であり、インターネットの専門家が毎日扱っているものでもあります。車のコックピット内の IVI ハードウェアと他のハードウェア間の通信は、MQTT、HTTP などのイーサネットを使用して実現する必要がある場合があります。
できる
コントローラ エリア ネットワーク (略してCANまたはCAN バス) は、機能豊富な車両バス規格です。ホストを必要とせずに、ネットワーク上のマイクロコントローラーと計測器が相互に通信できるように設計されています。これはメッセージ パッシング プロトコルに基づいており、当初は車両で多重化された通信ケーブルを使用して銅線の使用を削減するように設計されており、その後、他の業界でも使用されています。
CAN は自動車分野で非常に重要な通信バスです. 中央制御画面でいつでもドア, エンジン, トランクなどのモジュールを表示および設定できます. 実際, それは CAN バスの助けを借りて実現されています. Android プログラマーは頻繁に Android と通信する必要がありますが、これについては後で詳しく説明します。
MCU
マイクロコントローラ ユニットは、オンボード コントローラを介してさまざまなデータを分析および処理して最適な決定を下すなど、自動車の機能の大部分を担っており、自動車のインフォテインメント インタラクションやモーション コントロールなどを担っています。
一般に、MCU は車両通信、エネルギー、ストレージ、認識、コンピューティングに適用でき、自動車業界で重要な役割を果たします。
SOC
SoC にはさまざまな定義がありますが、含意が豊富で適用範囲が広いため、正確な定義を与えることは困難です。一般的に言えば、SoC はシステム オン チップ (システム オン チップ) としても知られるシステム オン チップと呼ばれます。これは、完全なシステムを含み、すべてを備えた製品、専用のターゲットを備えた集積回路であることを意味します。組み込みソフトウェアの内容。
自動車用 SoC は、一般的な携帯電話用 SoC と非常によく似ており、CPU と GPU が内部に統合されています。現在、最も主流の自動車用Socは、携帯電話のSoc Snapdragon 855に基づいてQualcommが開発したQualcommの8155です。
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的官方文档：source.android.google.cn/docs/device…
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 日、Leapmotor は香港で正式に上場しました。「魏小麗」に続いて意外にも新人になった。しかし、リープ・モーターの業績は資本市場に認められていないようで、上場初日に株価は急落した。データによると、9 月 29 日の取引終了時の Leap Motor の株価は 1 株あたり 31.9 香港ドルで、発行価格から 33.54% 下落しました。次の半月で、Leap Motor の株価は 56% 下落し、その市場価値は 343 億香港ドル蒸発しました。
一方では自動車の輸出量が大幅に増加し、他方では上場時に自動車製造の新勢力の第 2 段階が崩壊し、株価は 2 取引日で半減します。これはまた、資本市場が自動車会社の熱意を大幅に弱めていることを示しており、投資家が豊富な利益を得ることができない場合、自動車会社が将来的に市場から資金を調達することは容易ではない可能性があります。
以上が環境の話ですが、技術者としての主な仕事は自分の技術を磨くことです。
振り返ってみると、このアーキテクチャ図をもう一度見直す必要があります.図の青でマークされた部分は、アプリケーション開発ができる部分です. アプリケーションが実際に車載オペレーティングシステムの小さな割合を占めていることを発見したかどうかはわかりません。技術的なしきい値は高くありません。これは基本的に、車載の分野で純粋な Android の開発見通しアプリケーションは広くありません。
しかし、巨大な車載システムにより、アプリケーション開発者は深く研究し、実践し続けることがFrameworkできNativeますHAL。
最後にまとめると、モバイルアプリ開発と車載アプリ開発は基本的に2組の技術路線なので、慎重に転職する必要があります！決まっている方はお早めにどうぞ！