把一块平板电脑装进车里，靠谱吗？

之前有人跟我说：智能汽车的座舱，不就是「塞了」一块平板电脑吗？

但事实真的是如此吗？

那为什么 AITO 问界 M5 的车机「像」一块平板电脑？这里其实包含了软件和硬件两部分：

AITO 问界 M5 的座舱里，除了方控、车窗控制以及双闪之外，几乎没有其它的物理按键了。只有一块仪表屏和中控屏，而中控屏的造型和尺寸也像极了一块平板电脑。

虽然包括特斯拉在内，越来越多的品牌车型都开始进行这样的设计，但这并不能说明这种设计方向一定是完全正确的。

拿 AITO 问界 M5 的这套鸿蒙车载 OS 来说，它的 HMI 交互设计与 UI 设计与移动设备的鸿蒙 OS 极其相似，所以软件的可视化效果与交互逻辑也像极了一块平板电脑。

如今用惯了智能手机、平板电脑的我们，对这样的系统界面和交互逻辑已经存有基本认知，所以上手门槛就变得很低了。

这套鸿蒙车载 OS 的主页是多张可切换壁纸，除了 Dock 栏和 Smart Dock 栏之外，绝大部分的空间并不能进行交互。

如今，很多车机系统会采用「导航即主页」的设计，以内容播放、空调等不同的卡片对应呈现常用功能。但 AITO 问界 M5 功能卡片与图标的排列方式，有赖于排布的先后顺序，使用者不得不做出取舍。

不可否认的是，车内交互设计的美观性是在驾驶安全和高效交互的基础上进行拓充的。

对于采用了大屏车机、取消物理按键的车型，这样的交互设计对于静态场景的操作没有问题，但对于动态驾驶场景下的操作影响会比较大。当视线集中在频繁的屏幕交互时，会因为注意力分散而对驾驶安全造成影响。

还有就是行驶于路面颠簸路段的时候，操作的准确性和效率也会大打折扣。

所以，AITO 问界 M5 的这套鸿蒙车载 OS 在 HMI 交互设计上，针对驾驶场景必然要做出足够的「适配」。

目前来看，这套鸿蒙车载 OS 中主要的交互和信息，都布置在适宜驾驶员交互和观察的范围内，这也是鸿蒙车载 OS 与移动设备 OS 有区别的一点。

这样的设计，能够在搭载中控大屏、取消大量实体按键的前提下，尽可能的减少驾驶员对屏幕的交互时长、扫视时长，让驾驶员更快完成交互、信息获取后能够能快地将注意力回到驾驶当中。

除此之外，AITO 问界 M5 还设置了带「P」的应用，主要是视频应用，而这些应用只可以在驻车状态下使用，以避免驾驶员在驾驶场景中的分心。

在体验 AITO 问界 M5 的这几天里，这套车机反应速度快、流畅度高是给我印象最深的点。可以说，在目前以触控屏为核心交互形式的车机系统中它有着极强的实力。

这种体验几乎涵盖了所有交互相关的层面，像应用的开启及运行、触控交互、语音交互等等。

所以，这种「快」的背后是什么？

人们的通常认知中，人机交互界面的「快」，其背后原因基本会分为三种：

实际上，「优化好」是种很玄学的说法，能被用来解释许多无法立刻给出答案的说法。

但在硬件上，AITO 问界 M5 的座舱 SoC 采用了华为的麒麟 990A 芯片，算力约为 3.5TOPS。作为与高通 8155 对标的产品，车规级麒麟 990A 芯片主要应用于汽车座舱，并且更适合鸿蒙生态在车端的运行。

在软件上，我推测鸿蒙车载 OS 中应用了华为的「方舟编译器」或「微内核」的技术和架构。

说到编译技术，这是一种能够将代码转换为机器语言的技术。编译器是软件与芯片之间的桥梁，它的性能将直接影响到整个系统的运行效率。

我们所熟知有一些移动设备「久用必卡」，这一点其实就与编译技术有关。以往最司空见惯的做法就是堆配置，做出大量的硬件冗余，但是这样治标不治本。

方舟编译器采用了全新的系统及应用的编译和运行机制，对所有的 Java 语义全部做到静态编译，直接将 Java 语言「翻译」成机器语言（静态编译），消除了虚拟机动态编译的额外开销，实现了开发和运行效率的兼容并举。

如果把编译器看做一个翻译，就好比我们去到一个语言不通的国家，原本只能通过同声翻译（虚拟机）来进行交流沟通，难免效率低下。而华为的方舟编译器更像是直接让人获得了语言能力，从而可以摆脱同声翻译（虚拟机），可以更畅快地与当地人沟通。

所以，我们认为来自华为的「软硬结合」才是 AITO 问界 M5 上鸿蒙车载 OS「反应快」、「交互流畅」背后的原因。

回归到「智能汽车的座舱就是一块平板电脑」这个问题，其实并不恰当，因为驾驶场景与移动设备的使用场景有着极大的差异。

即便有的车机看起来和用起来像一块平板电脑，如果它没有针对驾驶场景做足够多的适配，它将会给驾驶场景的交互安全带来极大的隐患。