作者： Mr.Yu
自从华为正式发布 HarmonyOS 2 已经过去一个多月，眼下最令人期待的就是 7 月 29 日这周四的华为 P50 发布会了。
从日前的官宣中我们得知，这次发布会主题叫做「万象新生」，预示着从 HarmonyOS（下文中称鸿蒙 OS）正式登场开始，一切都将变得不一样。
话归正题，今天咱们聊聊车上的鸿蒙 OS。
视频也好文章也好，相信大家都看得差不多了。
结合已有的公开信息，我们会从功能、交互等方面对鸿蒙 OS 在车上的表现进行分析，并推测可能的发展方向。希望我们的视角，能为大家带来一点不一样的思考。
OS 不再久用必卡
不管是实地体验还是网络视频，我们都能看到，鸿蒙 OS 车机的应用响应速度很快。
我们认为原因有两点：
车载 SoC 麒麟 990A 立功了
作为与高通骁龙 855 的车载规格封装版本 8155 对标的产品，车规级麒麟 990A 主要应用于汽车座舱场景，与华为 Mate 30、P40 系列手机采用的麒麟 990 芯片之间的关系，并不是换个代号这么简单，它们的工艺流程和核心数堆叠等结构方面完全不同，更适合鸿蒙生态应用在车端的运行。
鸿蒙 OS 座舱中存在华为的方舟编译器，或类似的技术和架构
编译技术是一种能够将 C、Java 等高级语言转换为机器能读懂的低级语言，将精妙的代码转化为 0 和 1 的二进制指令。编译器是软件与芯片之间的桥梁，其性能、效率直接影响到机器的运行效率。
2019 年最早在 EMUI 9.1 上登场的方舟编译器，采用了全新的系统及应用的编译和运行机制，对所有的 Java 语义全部做到静态编译，直接将 Java 语言「翻译」成机器语言（静态编译），消除虚拟机动态编译的额外开销，实现开发和运行效率的兼容并举。
在用户端来看，最直观的感受就是：
-
从打开到运行，应用的整体流畅度提升；
-
降低 SoC 的计算资源开销，进而降低功耗提升了手机续航能力；
-
为用户带来更加持久流畅的体验，解决安卓系统久用必卡的「遗传病」。
鸿蒙 OS 不是 Android，但编译技术在产品应用上的逻辑是相通的。
注意，这里仅仅是代入关系。
事实上，手机与汽车之间的结构复杂程度相差太多，也正是因为如此，应用「上车」并非是移植或适配的简单概念，相同应用在不同车机系统上的表现也不一样。
交互习惯的延伸
自鸿蒙 OS 问世后，华为一直将万物互联作为其最核心的卖点进行宣传。
不仅是无缝衔接的跨端流媒体播放，还是车家、车车、人车之间的跨平台通话都堪称惊艳。
我们注意到，华为将智能手机上的隔空操作也搬到了鸿蒙 OS 座舱中。
用户在手机上的翻页、播放、浏览、截图等一系列隔空操作，在车机上变成了通过手势达到翻页、音量调节等效果。
通过多段视频判断，在上海车展期间，手势操作的响应延迟大概在 1 秒（1 s=1000 ms）左右。算上体验者从视觉上确认的反应速度，交互的过程算是基本流畅。
同样的效果，手机上的交互传感器是前置摄像头，而鸿蒙 OS 座舱中的则是车内毫米波雷达。
在最近的视频中，鸿蒙 OS 座舱中手势交互的延迟已经控制在相当低的水平。
如果将视频中呈现的 50ms 左右的延迟进行主观量化的话，大概与低延迟处理比较好的真无线耳机产品的水平相当，或是与我们日常刷门禁卡响应开门的流畅度差不多。
于是，在鸿蒙座舱的车机屏幕上，大家又见到了经典的《水果忍者》游戏。在车里通过隔空手势玩「切水果」，硬件的冗余带来的不仅是交互流畅度的提升，还为开发者们的脑洞提供了释放的空间。
我们认为，华为尝试在做的不仅是将鸿蒙生态下的应用打通，还包括操作习惯也一并延续。
显然，华为不打算在各设备之间保留看上去最适合的传统操作模式。这样做的目的，很大程度上是为了保证用户即便横跨多款设备，也能够在鸿蒙生态下的各端获得一体化或趋近的操控体验。一方面降低新设备上手操作的学习成本，另一方面尽量拉平在设备之间切换时的操控体验。
AI 上车，不只是多了个场景而已
这还要先从 AI 智能助手在国内的崛起说起。
也许是受到苹果 Siri 的启发，也许是荣耀 Magic 智能手机为移动端 AI 能力的场景化应用建立了很好的范式，也许是小米生态链的 AIoT 布局越做越大。总之，AI 智能助手在智能设备中的存在，从前几年开始迅速为人们所熟悉。
AI 智能助手概念最火的一段时间里，小米甚至可以在主流手机机型上单独设置一个用来唤醒 AI 助手小爱同学的物理按键。
后面的 OPPO 的 Breeno（小布）、vivo 的 Jovi 等智能助手在各自的平台上站稳脚跟，随着设计越发成熟，「AI 键」演化成了手机、智能手表的某个按键的长按、快速双击等操作来唤醒，不再突兀地设置单独的物理按键。
华为的 AI 智能助手小艺不如小米家的小爱同学在社交网络上出名，但随着鸿蒙生态在移动、家庭、车载、办公等场景中迅速铺开，华为的 AI 能力应用将会形成完整的生态闭环，并随着各领域合作伙伴的相继加入进而不断扩大。
令人意外的一点，在鸿蒙 OS 座舱中的 AI 语音部分采用了车端侧和云端侧双引擎机制，二者基于华为自研。这么做的好处是即便车辆行驶到网络信号不佳或没有信号的区域，云端侧无法响应的情况下，车端侧的智能语音也能正常工作。
同为 AIoT 大厂，按小米的行为方式和对数据的重视程度，小米很大几率会在车载端采用与自家 MIUI 类似的模式，建立独立的生态，再将小爱同学作为交互入口做 AI 能力应用的统一调用。
除非小米在自家汽车量产下线之前也以 OS 形式全面进军车载场景，再跟汽车领域的老字号新玩家们分个高下 —— 这里并非一捧一踩，但我们也知道，这并不容易。
生态便利性
先从已公布信息来看鸿蒙 OS 的几个信息点：
-
上海车展前后，鸿蒙 OS 下的应用数量在 27、8 个左右，全部支持语音控制，还有一部分支持手势控制；
-
在 2021 年年底之前，鸿蒙 OS 支持的应用数量将会达到 100 个；
-
尚未进入鸿蒙 OS 的第三方应用，也可以通过手机投屏的形式，进入鸿蒙座舱的车载屏幕中；
-
通过投屏进入鸿蒙座舱的第三方应用，支持设备内的反向控制，用户可以通过车机的触摸屏使用手机端的应用，同时支持语音控制；
-
上述操作不受手机品牌限制，只要是安卓手机都可以实现上述操作。
这部分不做过多解读，大家细品。
通过视频中的细节我们注意到，进入鸿蒙 OS 的应用可以获得更好的交互体验。
比如，使用者向鸿蒙 OS 座舱发出「打开咪咕音乐播放《稻香》」这种多段式的语音命令时，座舱可以正确响应指令，语音交互的效率和便利性很大程度上得到了保障。
我们来看一组对比。
经过测试，以家中的空调操作为例，目前米家生态链智能电器 + 小爱同学智能音箱的组合，暂时还没法实现类似的一步到位操作，而是要：
-
Mr.Yu：「小爱同学。」—— 小爱同学：「我在。」——Mr.Yu：「打开客厅空调。」—— 小爱同学：「开啦～」—— 交互结束
-
Mr.Yu：「小爱同学。」—— 小爱同学：「我在。」——Mr.Yu：「客厅空调调整到 26 度。」—— 小爱同学：「好的，空调已经调整到 26 度啦。」—— 交互结束
这两组的命令从唤醒词、响应、发出指令到回复确认执行效果，加在一起需要耗时 10 秒以上。
我们无法苛责 AI，毕竟 AI 不是靠着常识来进行理解和沟通的。
但对使用者来说，绝大多数使用者需要的是在保证安全的前提下少费口舌，准确执行，一步到位。
宏观层面上来看，鸿蒙 OS 生态上未来可以发布华为原生应用、车企应用或第三方应用，对各方来说，统一的平台可以获得更高的市场份额。
基于微内核的鸿蒙 OS 兼具 Android 和 QNX 的优点，对于国内 Android 没有 Google GMS 支持的在应用软件适配成本较高这点上，鸿蒙 OS 借助华为服务实现更快更低成本的适配，在后端生态适配上的优势显而易见。
一个小问题
在上海车展期间，我们见到了 AR-HUD 在鸿蒙座舱中的搭载。
在 Demo 体验中我们发现，鸿蒙座舱的 AR-HUD 对可视角度有一定要求。我 GeekCar 编辑部的 @米其林 小姐姐所在的海拔，似乎并不能看清 AR-HUD 上显示的信息，AR-HUD 设备也无法做出调整。
希望上车量产之前，华为和主机厂的合作伙伴们能够注意到这个问题，并加以解决。毕竟在视频中，有位小哥都把 XBox One 手柄接到车机上，用 AR-HUD 玩起游戏了。
如果这都有门槛，那就有些尴尬了。
写在最后
这些表象的背后，鸿蒙座舱承载了华为太多的野心。
比起国外传统车企偏好基于 QNX 或 Linux 进行开发的老派作风，国内车企为了追求更高的智能化程度，大多会基于 Android 来定制座舱 OS。
但我们前面说过，没有 Google GMS 的支持，从头搭建生态的大量资源投入和等待成本是无法避免的。
目前来看，除非鸿蒙生态新伙伴「入伙」的增速一直不理想。不然，按照现在的势头发展，鸿蒙 OS 是具备对 Android、QNX、Linux 等现有底层 OS 开发模式形成挑战的实力的。
