HackerMi

一. 前言

2014年Google推出了一种全新的手机和车机互联方案 Android Auto， 同时苹果也推出了自己的车联网方案Car Play，一时间车联网成了大家争相进军的领域。除了这些大厂造势之外，还有一个第三方默默耕耘的车联网解决方案 —— MirrorLink，由于处于中间位置，没能像车厂和手机厂商那样为大家熟知。由于工作的原因，也参与了这次热潮。虽然由于各方面原因，未能拿出比较有竞争力的产品，但这期间还是有一些值得记录的东西。本文主要分析主流的车联网技术方案，以及个人对这个市场的一些理解。

二. 车联网行业理解

车联网本质上是手机厂商与车场的计算平台之争，手机厂商希望将手机的生态圈扩展到车机中，汽车厂商当然也不会就这么简单的坐以待命，也开始兼容手机APP推动各自平台的发展。

车厂的主流操作系统是QNX（黑莓），WindowsEmbeddedAutomotive（微软）， Linux。其中QNX占据50%以上的车载系统，主流车厂的系统（例如：宝马，法拉利，玛莎拉蒂等）都基于QNX构建，福特的SYNC基于WindowsEmbeddedAutomotive构建，少量车厂直接基于Linux搭建自己车机系统。

手机厂商的操作系统相对简单，主要是Android 与 IOS，还包括专门做车联网的应用层软件 —— MirrorLink。

在这个行业里还有一个很特别的角色，国家交通法规，有很多国家法规处于安全的考虑对手机连接汽车比较排斥，这也是车联网中需要考虑的一个问题。

车联网的概念首先由手机厂商提出，更多的是针对手机阵营的开发者，主要解决以下问题：

• 为应用开发法者提供统一的车机平台，开发者开发软件不需要针对不同车机平台进行适配
• 为应用开发者提供统一的软件分发平台，解决应用发布到车机中相对困难的问题
• 统一适配各国的驾驶安全法规，降低应用开发者开发和维护的成本
• 将手机连接性和个性定制化融入车载系统，提升车机的用户体验

车厂的车机系统目前主要停留在GPS导航，语音协助，车内电子系统控制等汽车电器一体化的阶段，缺少信息的融合，比如可以接入互联网的汽车相对较少。手机厂商提出的车联网构想对车机信息互联也是很好的提升，但因为车内电子系统的控制权以及平台利益问题，这其中有着长久的博弈。个人理解未来，手机厂商的技术方案会广泛应用，但考虑到汽车的生产周期，预计2020年后市场开始成熟。

三. 主流技术方案

Android Auto 车联技术方案

发展历史

大家看到Android Auto时都觉的非常惊艳，对老美的创新能力也十分佩服。但事实上Android Auto也是一步一步发展而来，不是一群聪明人拍脑袋火拼一年搞出来的东西。下面是Android Auto发展的路线图

Google Map早在2005已经开始与车厂合作，到2010年发布Android Auto已经是水到渠成的事情。

主要用户

Android Auto 面对的主要面对三类人员：驾驶员，开发人员，乘坐人员。Android Auto首先着重优化的是驾驶员的体验，解决的问题也是帮助驾驶员在行驶的过程中合理的使用手机，提高驾驶安全。其次是统一各个车机的开发平台，降低开发者门槛。最后是乘坐人员的体验，主要依托开发人员开发各种场景的APP来丰富。

设计出发点

1. 车机软件与手机、PC软件最大的不同是更新很慢，车内联网条件比较差，用户更新车机软件的情况大多数时候是用来更新地图，一般不会主动升级车机软件，所以车机部分的Android Auto应当尽量稳定，而且体积相对较小。
2. 汽车内部的电气一体化信息是手机所不具备的，Android Auto设计之初已经考虑到将其与手机的计算能力融合。主要包括：方向盘转向信息，车机控制信息，车内麦克风数据，车内音响，车机GPS信息，轮子转速等。
3. 汽车有自己的发电系统，可以为手机充电，这一点很好的保证了手机的长期工作能力。
   总体上来讲，Android Auto的设计是以手机为出发点，将汽车看作手机的配件，努力将其信息整合入手机的系统。

软件架构

Android Auto 软件架构主要分为三个部分：手机框架，连接协议，车机框架

• 手机框架：主要包括与车机通讯的API接口（媒体API，通知API，语音API，消息API），屏幕投射与控制模块。
• 连接协议：Android Auto的私有协议，主要用于手机和车机相互通讯，以及搭建私有传输通道。其中，包括四个独立的传输通道，按照传输优先级由高到低的顺序：声音，视频，传感器，输入输出。这样设计首先保证了驾驶员开车接电话的场景，其次是驾驶员阅读导航信息以及其他的控制信息。
• 车机框架：主要包括五个模块，输入控制模块，声音模块，显示模块，传感器数据搜集模块，底层通讯模块。其中底层通讯模块主要用来解决平台差异，对其他模块提供统一的接口。

总体工作过程

1. 手机通过USB线缆连接车机后，车机端进行USB协议初始化并触发车机的AOA协议协商
2. 车机通过AOA协议协商将手机切换到配件模式
3. 系统识别配件为车机后启动Google Play Service
4. Google Play Service与车机的协议栈协商Android Auto协议
5. 手机进入车载模式，从内容APP中提取数据，将音频视频流投射到车机上

媒体API

媒体API主要由两部分组成：媒体数据提取和媒体控制。

Android Auto将媒体数据抽象为树形结构，主要由MediaBrowserService实现基本框架，通过MediaBrowserService.onGetRoot()获取根节点信息，主要包括APP的版本信息，访问权限校验，APP信息等。通过MediaBrowserService.onLoadChildren()获取子节点信息，主要包括媒体层级，以及播放列表 媒体控制通过MediaSession类实现，APP需要实现onPlay()、 onPause()、 onStop()等控制接口完成媒体流的相关控制。

下面是用户播放音乐场景的工作流：

1. 用户对车机屏幕的触控操作通过Input通道发送到手机端
2. 手机端Google Play Service 映射车机触控信息，并做出相应的UI响应
3. 通过媒体API接口从媒体APP拉取数据，主要包括：媒体库，播放列表，曲目信息等
4. 如果用户触控的是音乐控制，则调用媒体API中的音乐控制接口，控制媒体APP做相应的操作
5. 音频数据通过Audio通道发送给车机，具体实现在底层处理，媒体APP不可见

消息API

消息API基本保持Android系统的通知的实现方法，通过在原有系统的基础上扩展功能来实现与车机的交互。

发送时通过NotificationCompat.Builder.extend()方法添加CarExtender对象增加车载相关的处理，CarExtender对象封装了UnreadConversation，Icon，Color信息。 UnreadConversation封装了消息主体，响应Intention，时间戳等会话信息。

接收车机消息，主要通过接收UnreadConversation中的getReadPendingIntent()和getReplyPendingIntent()广播事件来实现，其中ReadPendingIntent表明用户已经阅读通知，ReplyPendingIntent表明用户发送了响应信息，APP需要处理。 Android Auto增加了RemoteInput类，它会将用户的语音输入翻译为文本信息提供给APP处理，从而帮助开发者处理用户语音回复的信息。

下面是消息发送的工作流：

1. 消息APP根据Auto API构造发送消息
2. 通过NotificationCompat.notify()接口发送消息，消息通过framework中转给Google Play Service。
3. Google Play Service 提取消息，显示在Dashboard上，并通过Display通道输送给车机
4. 调用语音信息将消息翻译为音频流，通过Audio通道发送给车机
5. 车机接收音频数据，通过音响播放相应的声音
6. 驾驶员使用语音应答信息，车机接收语音信息，通过Audio通道发送给手机端的Google Play Service
7. Google Play Service调用语音助手将音频翻译为对应的文字信息发送给消息APP处理

Google Play Service

目前Android Auto的主要实现封装在Google Play Service中，这样做的目的是为了方便Android Auto的核心部件独立升级。

Google Play Service更像是一个信息中转站，它从APP中拉取数据（如媒体信息，通知信息等），显示在Android Auto显示框架上，而后将显示和音频信息通过USB发送到车机端。同时获取车机上的触控出入，车轮转速，GPS等信息，传给手机APP，辅助APP进行工作

Android Auto为车机图像显示提供了一个统一的UI框架 —— UX framework，这样手机APP中的内容在车机显示屏上就有了统一的基础界面风格，当然APP App 可以定制一部分显示界面（如音乐背景），但是大的样式不能修改。这样做的目的一方面是为了防止驾驶员注意力分散，另一方面是为了统一适配各国法律法规，保证应用的通用性。

下面是UX framework的主要界面

Google Play Service 显示模型

整个显示区域分为Content区域和System UI区域，Content区域由APP定制，并且在APP进程进行绘制;System UI区域统一在Google Play Service绘制。这样分开绘制可以防止APP出现问题后，导致系统不稳定。 整个布局使用XML定制，方便后续变更和扩展。

Google Play Service 视频流处理

1. 视频渲染分两个部分，UX框架一部分，APP内容显示一部分
2. Google Play Service现将APP内容显示封装为Surface Object通过binder通讯发给APP
3. APP在其上构建virtual display 绘制自己的显示内容
4. Google Play Service 再创建一个virtual display绘制UX 框架
5. 将两者会之后的结果交给硬件统一编码，打包发送给车机端
6. 车机获取视频流后，解码，并调用车机显示接口显示内容

FLP API

FLP API是Google 退出的提高APP定位精度和速度的新API。 APP使用该API后可以获得更多渠道汇聚来的数据，在Android Auto中，可以获取车机的GPS，轮胎转速，指南针等定位数据；一般应用可以获取WIFI 等附加定位信息。 FLP API 设计非常简洁，主要三类接口getLastLocation(), removeLocationUpdates(), requestLocationUpdates()。核心实现在Google Play Service中，并不对外开源。

连接协议

1. Android Auto定义了自己的协议来传输数据，该协议的底层协议是USB配件模式的AOA协议。但Android Auto协议本身是通用协议，USB线缆传输时依赖AOA协议，未来也可以基于WIFI-DIRECT。
2. Android Auto Protocol使用Protocol Buffers构建，分为四个通道：Audio, Display, Sensors, Input。每个通道使用单独的线程传输数据，并区分优先级。
3. Android Auto Protocol使用SSL加密传输，保证了信息传输的安全。

车机框架

1. Android Auto为车机提供了一个很小的C++ Library，可以运行于Linux、Android、QNX，集成方便
2. 它主要包括车机需要实现的硬件接口，接收手机数据的协议栈（Input，Audio，Sensors，Display)

Apple CarPlay 车联技术方案

由于苹果系统比较封闭，这里之列出一些简单的实验总结和技术分析。

CarPlay本质上是AirPlay的延伸，只不过是传输媒介变成了USB线缆，接收媒体多了车机，增加了反向控制，但总体的框架还是基于AirPlay的架构。这一点可以从手机端操作入口得到证实，当IPhone连接车机时，AirPlay的菜单中会多出一个CarPlay选项，这与手机投射到电视的操作体验一致。另一方面，手机端多媒体APP（比如音乐）的行为与AirPlay并无差异，车机端统一做了适配。

CarPlay采用USB线缆传输主要有两个原因：

• 屏幕投射需要编解码，运算量比较大，需要USB供电
• 为了保证传输数据延迟较小并且稳定

CarPlay所有的运算均在手机端完成，比如车机触发Siri，播报的语音信息以及语音识别都是在手机上处理完，而后在车机中展示。

CarPlay的车机架构与Android Auto并没有太大区别，亦是C++实现Lib库，只是实现的协议与接口不同。

MirrorLink 车联技术方案

MirrorLink 作为第三方商业化的车辆网解决方案，这里只是做一些简单的说明，感兴趣的同学访问 MirrorLink官网 联系进一步的商业合作

• MirrorLink通过独立SDK和APP来车联网基础服务 —— 屏幕投射，设备控制，设备信息交换。
• MirrorLink屏幕投射与设备控制基于Real VNC开发，Real VNC 是开源软件 VNC的商业化版本，它通过截屏的方式将图像传到远程计算机或车机中，并且通过私有协议实现远程控制。官方宣称可以达到30帧每秒，从有限的实验来看确实可以满足日常的需求，导航的体验可以接受。
• MirrorLink封装了独立的模块采集车机中的GPS等重要传感器数据，通过私有协议发送到手机APP中，实现车机数据的采集。手机数据通过蓝牙或者私有协议发送车机中，实现数据的双向传输。

MirroLink的技术方案推广存在一个很大的技术门槛 —— 截屏与远程控制需要获取系统签名。Android 平台将决定权交给了手机厂商自己决定，但是APPLE则明确禁止远程控制。这也是可以理解的，在手机已经变为计算中心的今天，手机隐私和安全性也越来越重要，如果被随意破解进而控制，后果是不可想想的。

三种主流方案优劣势分析

Android Auto

优势：

• 技术实现半开放，手机厂商可以做一些系统定制，有自己的特色
• 针对车机定指了统一的UI界面，保证驾驶安全
• 屏幕投射基于H264编解码，流畅性较好

劣势：

• Android Auto 内置Google 地图，中国本地化做的不好，目前不支持第三方地图
• 中国政府限制Google Play Service回归中国，Android Auto暂时不能在中国使用，不过未来可能解决

Apple CarPlay

优势：

• 技术方案的整合性很好，比如Siri语音助手已经集成到系统级别，并且汽车中会有专门的触发按钮。另外从实际测试效果来看Siri的语音操作成功率和体验均高于Android Auto方案
• 屏幕投射基于视频流，流畅性较好

劣势：

• 系统比较封闭，手机厂商基本不能做自己的定制化
• UI没有针对车机进行优化，采用简单大按钮风格

MirrorLink

优势：

• 独立实现了手机和车机连接的功能，手机厂商与车机厂商集成方便
• 最早实现的车联网技术方案，现存车机中支持的比较好
• 对各国安全法规比较了解，并建立的相关验证平台，保证APP良好支持各国安全法规

劣势：

• 屏幕内容基于截屏工作，流畅性不如传输视频流流畅
• 需要获取系统签名，对系统安全有一定的风险
• 没有整合语音控制，用户体验不是很理想

关于自研车联网的一些建议

• 对于互联网厂商来说，Android Auto已经是足够好的方案，存在的主要问题是Google Play Service回归中国的时间，至于本地化地图问题等回归中国后相信一定会有相关的解决方案出台。个人建议是等待Google的回归，不需要进行大规模的开发。
• 当然2015年百度和乐视出于自身利益的考虑，推出了自己的车联网解决方案，也联合了国内大的车厂，但最终是否可以产生经济效益，只能用时间来检验了。
• 未来车机肯定会智能化，也会联网，另一个比较容易忽略的方向是车机也有可能作为一个独立的计算中心登场。现在市面上已经有很多基于Android 系统的独立车机，相信未来车厂也会考虑进一步的整合，到那时可能真正缺少的是一个统一的物联网协议，目前个人比较看好Upnp。