adb 禁止app联网_手机车联网——MirrorLink，CarPlay，CarLife介绍
前篇文章小评给大家讲了讲什么是车联网，其中提到了车联网的第二阶段：手机车机互联。现在小评想跟大家专题介绍一下车机手机互联的发展历程和主要方案，由此理解这一技术的主要价值及未来方向。
汽车行业发展至今，一直有一个有趣的现象，很多用户都喜欢在车上装一个手机支架来导航，这也是让众多车联网从业人员无奈的地方。车机始终无法赶上手机的迭代速度，也无法企及手机APP的更新频率，与其用一个基本道路都无法辨别的老套车机，很多驾驶员宁愿选择手机导航。
到2011年的时候，以大众、本田为首的汽车厂商和以诺基亚、HTC、三星为代表的手机厂商想到了一个绝妙的主意，为什么不直接把这些手机上的APP通过投影的方式呈现在车机里呢？ 既省力又能够满足用户的需求，还可以保证一定的驾驶安全。于是，他们组建了一个联盟CCC（Car Connectivity Consortium），一起研究这一方案的可行性，MirrorLink技术由此诞生。
1. MirrorLink
MirrorLink确实是一个绝妙的主意，它依靠一根USB线的连接，可以将手机上的部分APP传递给车机，以实现投影。要实现手机车机互联，无非要解决这几个问题：手机如何与车机建立连接？手机上的界面怎么传递给车机显示？用户在车机上点击界面上的元素如何实现操作？手机上播放的音频怎么在车内扬声器播出？怎么来保证车机上显示的APP不会像手机支架方案那么危险？
如下这些协议就是来保证这一方案的可用性的：
(1). USB : 物理层，连接建立的基础。
(2). UPnP：设备发现协议，保证连接的建立。
(3). VNC： 实现手机界面到车机的传递，并可以实现车机上的操作反向给到手机APP。
(4). RTP : 实现音频的传输，比如用户听导航路线指引的时候，可以直接从车载扬声器听到。
(5). DAP：设备认证协议，确保能够投影到车机的APP，都是满足驾驶安全性要求的，对于手机上那些交互异常复杂的APP，这一协议可以将它们拒之门外，来保证车内使用的安全。
车机和手机连接好之后，能实现什么样的应用也是极为关键的。因此CCC联盟在国外与一些APP开发者（包括Sygic，Parkopedia等）达成了合作，这些APP开发者提供支持MirrorLink技术的应用程序，给到用户导航、媒体等类别的服务。
为了保证各个厂家实现这一方案时的兼容性，CCC联盟订立了MirrorLink的各个协议的标准文档，要求下属会员按照标准文档进行开发，并且在功能实现之后交由CCC指定的实验室进行认证。同时，CCC联盟每年都会在不同的地方举行会议，让手机厂商、车机厂商以及汽车厂商带上自己的设备，互相测试彼此连接的兼容性，来保证新产品上市之前不会存在彼此不兼容的尴尬情况。
CCC这个联盟联合了很多业内大厂，不管是汽车界的老牌霸主大众、丰田和本田，还是手机界当时的大佬三星和HTC，在彼时，很多厂商都在支持这一协议，其全球前景一片看好。
紧接着，苹果在2013年提出了iOS in the car的设想，一度想要在车内打造iOS系统，一年之后，苹果将iOS in the car更名为Apple CarPlay，实现方式也变成了手机车机互联。接下来，小评给大家讲一讲Apple CarPlay技术。
2. Apple CarPlay
苹果想要在Apple CarPlay中实现的是iOS系统上车的体验，整体的交互实现都是通过手机来完成，人机界面的风格与iOS系统完全一致，用户上车之后，有非常亲切的感觉。这一风格从创始之初到如今，一直沿袭了下来。
Apple CarPlay完全是苹果自己制订的技术标准，以实现界面、音频的传递，以及反向操作的实现。 在车机端，苹果会提供一个协议栈（Communication Plug-in），车机厂商将底层的驱动、连接管理器和上层的应用与这个协议栈对接之后，即可以实现与苹果手机的连接，实现控制流、音频流以及视频流的传递。注意，这里的视频流并非是说Apple CarPlay支持视频播放，而是手机界面的传递是通过编码成H.264的视频之后，由手机传递给车机，车机解码视频流之后再把界面实时投影出来。
如下从五个部分描述了Apple CarPlay的要素：
(1). 界面传输，如前所述，通过H.264视频流，手机端编码，车机端解码。
(2). 反向操控，Apple CarPlay除了支持触屏控制，还支持其他硬按键如多功能方向盘、旋钮及其他按键的控制。比如，你在听Apple Music的时候，可以通过多功能方向盘下一曲按键切换到下一曲。
(3). 音频传输，手机端的音频（如音乐，导航和电话）以LPCM高品质音频的格式传递给到车机端进行播放，为了支持Siri和打电话的场景，Apple CarPlay要求接收车载麦克风的音频输入，为了保证音频的质量，苹果要求该音频需要车机端进行降噪处理，并且满足高品质的采样率要求。
(4). 握手鉴权，苹果有严格的认证要求，车机端与苹果手机建立功能连接前，需要完成iAP2协议的鉴权过程，该过程依赖外置的苹果芯片以及苹果提供给车机端的iAP2协议栈。
(5). 车载数据传输，Apple CarPlay希望通过车机端获取一些基本的车辆数据，如GPS数据和车速，以辅助苹果地图进行导航定位。
在苹果手机这端，苹果开发了一个资源管理器，这个资源管理器可以实现界面和音频的调度。 当车机端需要显示Apple CarPlay界面或者隐藏Apple CarPlay界面时，车机端需要向手机端的资源管理器申请界面资源或者释放界面资源。同理，当车机端需要播放Apple CarPlay音频或者停止Apple CarPlay音频时，也需要向资源管理器进行申请。这一机制可以保证车机端和手机端状态的绝对同步。
一开始Apple CarPlay能够实现的功能非常有限，基本就是苹果全家桶：Apple Map，Siri，Apple Music, Phone。 功能上吸引力不足，再加上苹果地图和Siri的水土不服，亮点不多。后来，苹果开始重视中国市场的用户体验，每年都会来中国与开发者、车机厂商以及汽车厂商交流，在交流过程中，他们意识到了应用生态的无力，因此他们邀请了更多的APP开发者加入，一开始是媒体类的应用如QQ音乐、网易云音乐、喜马拉雅，后来又开放了导航类的应用，如高德地图。 由此，其吸引力极大提高。
谈Apple CarPlay，必须要说的就是苹果严苛的认证要求。苹果一直以来都奉行极致的用户体验，在Apple CarPlay也是如此，它不仅对于HMI人机交互设计有自己的要求，而且在性能上要求也非常高。比如，对于无线CarPlay，苹果要求传输带宽需要在25Mbps以上，传输的延时在16ms以内，丢包率小于1%，这是非常难以达到的要求。 苹果有十几个的认证条目，因此， 车机厂商通常都会安排专人负责苹果认证，并随时跟踪各条目的认证进度。但是即便如此，车机厂商们仍然难免遇到苹果认证进度推迟，对整体项目进度造成影响，来来回回与苹果沟通，请求苹果接受部分场景不满足要求，大部分时候还需要汽车厂商与苹果交涉，项目投产之后还没有拿到苹果的认证许可也是常有的事。
紧接着苹果，各大互联网公司和车联网服务商都接连推出了自己的车机手机互联产品，其中最为典型的就是百度CarLife产品。
3. 百度CarLife
百度在2015年推出了其CarLife产品，旨在通过车机手机互联实现百度地图和小度语音助手在车载端的支持，在车机端占据一块自有的市场。百度CarLife是第一个实现同时支持苹果和安卓手机的技术。其刚开始推出时，对于苹果手机的支持使用的WiFi连接方式以绕过苹果认证，对于安卓手机的支持采用ADB方式（Android Debug Bridge）。两个方式都存在局限性，特别是ADB方式， 必须要手机端让用户打开开发者模式，操作复杂，而且还无法实现多音频通道的传输实现较好的体验。
从2016年开始，随着与众多厂商的合作开展，百度也优化了其技术协议，转而使用苹果的外设协议（EAP）来支持苹果手机，使用谷歌的外设协议（AOA）来支持安卓手机，保证了连接的便利性和可靠性，也便于开发视频流和音频流通道。
百度CarLife主要通过如下六个通道实现其技术架构：
(1). 数据流，主要用于传输车辆数据和一些配置数据。
(2). 视频流，类似Apple CarPlay，将CarLife界面通过H.264视频格式编码，然后传输给到车机，车机解码之后呈现CarLife界面。
(3). 音频流，分为媒体音和导航音两个通道，通过两个TCP端口传输给到车机，这样的好处在于，车机可以根据自己的音频管理策略决定哪些音频需要暂停，哪些音频需要混合，播放的音量大小各是多少，比如导航音和媒体音可以一同播放，同时将媒体音降音，以实现用户在听歌的时候不会错过导航信息的收听。
(4). 语音流，传递从车载麦克风录入的语音，以实现百度CarLife的语音识别功能。
(5). 反控流，传递车机的触摸事件或者按键事件给到手机端，来实现反向控制（如触屏控制、方向盘按键控制）。
百度CarLife可以实现的功能有百度地图、小度语音助手、网易云音乐、喜马拉雅、QQ音乐等，基本满足主要的车载场景。百度同样有认证的要求，厂商开发好功能之后，需要将车机样件给到百度公司，他们会进行测试验证，得以通过之后百度会颁发一个证书。
由上可以看到，百度CarLife与Apple CarPlay有很多相似之处，比如它们都依赖于H.264视频流传输界面，来实现较为流畅的体验。两者的最大区别在于，CarLife只是手机系统上运行的一个APP，它并没有系统级的权限，因此CarLife无法在手机端APP处于后台时实现流畅运行，同时CarLife的无线连接操作稍显繁琐，需要每次在手机端打开APP来实现连接，无法像Apple CarPlay那样实现无感连接。 CarPlay仅支持苹果手机，CarLife支持安卓手机，虽然支持的生态更为丰富，但是也会带来更多的兼容性问题，比如小米手机就会比华为的旗舰手机性能差，兼容性问题也会多一些，因此CarLife功能上线之前需要在多个品牌的多款手机上进行兼容性测试。
4. 小结
CarLife之后，还出现了腾讯的Tencent Link，阿里旗下高德的A Link，Tencent Link支持腾讯QQ聊天以及QQ音乐，A Link支持高德地图，他们的出现无一不是试图依靠手机车机互联抢夺一部分车联网市场，并实现更多自有品牌的露出，与Apple CarPlay和百度CarLife的目的如出一辙。但是这些技术大都昙花一现，很快这些互联网公司就因为合作厂商太少、对这个领域前景不乐观而放弃了该技术，转而投向更为高端的嵌入式车联网方案。
这里还要提的一点是，百度CarLife和Apple CarPlay创立之初，很多传统车厂人士大喊狼来了，声称互联网的野蛮人来抢夺市场、企图获取更多的车辆数据。但如今看来这完全是多虑了，CarLife和CarPlay除了基本的定位数据，并不要求什么车辆数据，他们更看重还是车内的交互体验。并且，到现在为止，并没有哪家车厂完全放弃自有的车联网体系而全部仰仗车机手机互联，后者只能是用户场景的部分补充，满足百度和苹果用户的使用需求，是一个互补的作用。
上一篇文章已经说了，目前车联网行业正在步入第三个阶段，很多车厂都已经推出了自己的车联网系统，并且取得了初步的成功。但是，这并不是说车机手机互联已经淡出市场了，它并没有被厂商们遗弃。可以看到的是，大部分车厂仍然在支持CarLife和CarPlay，甚至还在广告宣传语中将这个作为卖点，因为这些技术已经获得了较大的知名度，有大批的用户，而且厂商支持这一技术的成本并不大（百度和苹果都不收取授权费用），性价比很高。有的厂商甚至还试图依靠这一技术获得进一步盈利，如宝马近期被爆出需要用户支付费用以解锁Apple CarPlay功能，当然，小评并不看好这个选择。
小评认为，只有当车联网系统的应用生态足够丰富，并且能够与手机生态实现无缝打通之后，车厂的车联网系统才有可能不需要手车互联产品独立存在，并且还能让用户忘掉它们。这一天的到来，需要各个厂商的努力，也需要互联网公司的通力协作，目前看来，这条路道阻且长，每家公司的策略都会不同，各个公司的车联网应用无法实现在同一平台的相互兼容，生态整合的难度非常大，这条路的前途还不甚明朗。
小评愿与你一起去经历这个变化的时代，一层层拨开迷雾，守得云开。
- END -
如果你喜欢这篇文章，请关注车联网评论公众号，获取一首信息。
