极客汽车

极客汽车

2021-07-28

Subscription

透过鸿蒙座舱,看华为的如意算盘

  1. 华为
  2. 智能座舱
1,476

作者: 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 语言「翻译」成机器语言(静态编译),消除虚拟机动态编译的额外开销,实现开发和运行效率的兼容并举。

对比示意图

在用户端来看,最直观的感受就是:

  1. 从打开到运行,应用的整体流畅度提升;

  2. 降低 SoC 的计算资源开销,进而降低功耗提升了手机续航能力;

  3. 为用户带来更加持久流畅的体验,解决安卓系统久用必卡的「遗传病」。

鸿蒙 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 开发模式形成挑战的实力的。

本文著作权归作者所有,并授权 42 号车库独家使用,未经 42 号车库许可,不得转载使用。
Comment · 0
Owner: 0
Sort by like

Upload
大胆发表你的想法~
8
Comment