从应用工程师的角度再谈车载 Android 系统

20,805

前言

根据中汽协数据显示,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的官方文档: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日,零跑汽车正式赴港上市。成为众人意料之外继“蔚小理”后的又一新秀。但是零跑汽车的成绩似乎并没有得到资本市场的认可,在其上市首日,股价便遭遇大跌。根据数据显示,9月29日当日收盘,零跑汽车的股价为31.9港元/股票,相较发行价暴跌33.54%。而随后的半个月以来,零跑汽车的股价更是下跌56%,市值蒸发343亿港元。

一边是汽车出口量大增,另一边是新势力造车第二梯队的零跑上市即破发,并且两个交易日股价即腰斩,虽然有叠加疫情的影响,但这也说明了资本市场对造车企业的热情正在显著减弱,如果投资人赚不到丰厚的回报,那么以后的车企日后想要再从市场融资,恐怕不会是一件轻松的事。

以上说得都是大环境,但是作为技术人本职工作还是磨炼自己的技术为主。

回过头我们还要再看一下这张架构图,图中标蓝的部分是应用开发可以发挥的地方。不知道你有没有发现,应用实际上在车载操作系统中占据的比例很小,而且技术门槛也不高,这基本决定了在车载这个领域,单纯的Android应用开发前景并不广阔。

但是庞大的车载系统让应用开发者有了继续深入研究与实践的可能,那么是卷Framework还是Native或是HAL就需要你自己决定了!

最后总结一句,移动端的应用开发和车载应用开发,本质上走得两套技术路线,所以要慎重转行!如果已经决定,请务必趁早!