当前，诸多车企普遍使用的近场通信主要是NFC、蓝牙、WiFi这三大类技术，UWB仍属小众。随着蔚来进场，UWB被发扬光大，逐步得到了汽车产业界的认可。
接下来马上加入这个阵营的，还有将会大规模在华为系汽车上搭载的NearLink星闪。
设备间的快速连接，是通过分布式软总线（华为鸿蒙OS提出的概念）或者跨设备互联总线（小米澎湃OS的概念）实现的。面对不同的通信介质和通信协议（上文提到过NFC、蓝牙、WiFi、UWB、星闪五种），软总线可以对开发者屏蔽不同通信介质和通信协议带来的差异，实现异构组网、建立多个通信链路。
所以，异构组网的本质是设备之间同时存在多个可信的通信链路，设备可以根据消息大小、网络状态、设备状态，自主选择最合适的通信链路，将数据传输到对端的设备上，从而在功耗、性能之间达到一种均衡。
在组网的过程中，各个设备会辨别待联网设备的账号信息，从而基于同一个账号体系实现跨设备的可信互联，同时，设备会上报各自支持的硬件资源，形成一个统一的“硬件能力资源池”，以实现硬件资源的共享。
快速连接后，还可以带来高效的数据流转。
连接、组网相当于铺设了设备之间信息通信的高速公路，但是，如果没有“信号灯”、“车道线”和“交通规则”，这条高速路还是无法正常运转。为了让信息和数据跨设备自由流转起来，需要网络内的多个设备共同遵守同一套跨设备通信协议。
鉴于鸿蒙OS问世最早、资料最全，读者朋友们对其技术原理和概念多多少少都有所耳闻，所以，我们还是以鸿蒙OS为例，说明一下数据的跨设备流转是如何实现的。
鸿蒙OS在系统服务层提供了分布式数据管理和分布式任务调度两个子系统，它们都是上述“跨设备互联协议”的一部分。
以手机和车机的导航流转为例，当地图应用发起接力后，在分布式数据管理的支持下，手机端将数据存储到分布式数据库中，然后，通过分布式任务调度激活车机端相应的地图应用。
这一过程中，如果手机端用华为的花瓣地图，车机端就会调用花瓣地图，如果手机端用高德地图，车机端就会调用高德地图。
然后，车机端的地图应用从分布式数据库中恢复数据，继续导航服务。下车后，车机将导航再度流转到手机时，也会遵循同样的逻辑。
最后，车手互联还可以带来硬件协同。
上个月，在智界S7的预售发布会上，余承东提到被大家广泛热议的AEB只是小菜一碟，‘a piece of cake’。在这里借用一下余总的说法，导航、音乐的流转也只是车手互联应用中的小菜一碟。
车手互联更大的目的在于，将手机和车机这两个独立的终端融合成一个超级终端，实现「1+1＞2」的效果，从而解锁更多的应用场景。
超级终端靠的是硬件协同，背后的技术是分布式调度和分布式硬件。如前文所述，在设备组网时，每个设备都上报了自己的硬件资源和服务，形成了一个可被各个设备调用的虚拟化的硬件资源池。
至于本地设备怎么像调用本地硬件那样调用远端的硬件，以鸿蒙操作系统为例，它提供了一个叫做HDF的硬件驱动框架，所有设备的驱动程序都遵循HDF的规范。
这样一来，对于设备来说，无论这个硬件在本地还是远端，调用的都将是同一个驱动程序，只不过在函数的参数里设置一下remote或local的属性就可以了。
通过对车手互联底层技术栈的解析，大家就能明白，车手互联要想大规模上车，需要克服两大难关。
二、车手互联存在两大难关，以及蔚来的解法第一道难关，是跨设备互联协议不统一。
无论是快速互连、基于账号体系的安全通讯，还是应用接力和设备协同，这些跨设备互联功能都是在私有协议上实现的。
掰着手指头捋一捋，华为有HarmonyOS Connect（由之前的HiLink升级而来），小米有HyperConnect，魅族有Flyme Link，蔚来有NIO Link，Vivo有BlueXLink，这些协议就像是不同厂商人为建造的一道篱笆，柏林墙一立，各个生态圈里的终端设备就无法自由地互联起来了。
这种生态圈的割裂，绝非一纸行政命令就可以弥合的。
因为，无论是快速的发现和连接还是跨端服务流转，这些能力都是这些形形色色的操作系统以SDK或者API的形式为上层应用提供的，这意味着，想支持与鸿蒙设备的互联，就要集成华为的SDK，要与小米的设备进行跨设备流转，就需要使用小米提供的API。
最终的结果就是：选择了一家就拒绝了其他家，不能既要又要。
还有一个难题，跨端应用的安装难题。
100多年前，胡适先生曾经说过，「多谈点问题，少谈点主义。」
如果把操作系统的分布式能力比作一种主义的话，那么各个支持跨端迁移和多端协同的应用才是用来解决一个又一个具体问题的。即便手机市场破天荒地出现了一个几乎垄断了所有份额的带头大哥，但怎么保证手机上应用与车机上应用的一致呢？
透过问题看本质，用户想要的不是“应用”这个实体，而是其能够提供的“服务和功能”。用户想要的并不是“应用接力”的能力，而是“服务可跨端迁移”的体验。
还是拿导航的无缝流转举例，如果消费者拿着装载百度地图的手机上了装有高德地图的车机，尽管这两个地图应用都支持导航自动流转，但是，在前面提到的分布式数据库中，不同应用之间的数据是互相隔离的。请问，在无法访问对方应用的数据的前提下，这两个地图应用之间怎么“接力”？导航服务怎么接续？
之所以说蔚来到NIO Phone前途光明，是因为它在解决这两大难题。
正是基于对车手互联技术栈的深度钻研，和实现深度互联所面临难关的专业判断，蔚来才顶着非议，选择了自己做手机。
自研手机的好处是，一来可以做减法，降低开发工作量。
和手机厂商以及兼具“手机厂商+车企”双重身份的友商相比，蔚来的优势在于它可以做减法。它只需要面对汽车和手机的互联这个细分场景就可以达到自己的目的。
相比之下，手机厂商面对的是万物互联的全场景生态，奔向的是星辰大海，所以不得不做加法，单单在设备的连接和组网方面，就得同时支持蓝牙、WiFi、UWB、NFC等各种协议。
蔚来只需要采用UWB做车手互联的“软总线”通信介质，就可以实现抗干扰性比蓝牙强、定位精度比蓝牙和WiFi高、功耗比蓝牙及WiFi更低等效果。