自造手机是车手互联的最佳解决方案
在一年一度的媒体沟通会里，斌哥和力洪总在两个多小时的时间里回答了来自媒体朋友和观众的140多个问题，其中提到了换电、第二品牌、旗舰车型、自动驾驶、NIO Phone、出海策略、品牌定位、销售能力建设、管理效率等一系列问题，也坦诚地提到了人员方面的调整和裁员。
本文引用地址：http://www.eepw.com.cn/article/202401/454380.htm当某位媒体朋友问起蔚来手机的销量时，斌哥的回答是这样的：“我觉得得 3 年才能看这件事对不对，我觉得得等到第三代，等到华为、小米、苹果这些手机巨头的车越卖越多的时候，就知道这件事对不对了，咱们看看我们只做车的同行，要不要做手机。手机和车天然的信息流转，是很有需求的。”
为什么要三年后再看？怎么对这段话做阅读理解，本文试着谈上一谈。
至于车手互联的意义，我们可以借用星际魅族掌门人沈子瑜在FlymeAuto发布会上的说法开章明义。在《魅族∞领克无界生态发布会》上，身兼数职的子瑜总创造性地发明了一个汽车第六域-手机域的概念，即在传统的智能驾驶域、智能座舱域、动力域、底盘域、车身域之外，多了一个由中国人自己定义的第六域-手机域。
图片来源：魅族
也许是因为子瑜总相较于汽车五大域的提出者博世而言过于人微言轻，又或者是让人觉得有语不惊人死不休的哗众取宠之嫌，总之，这个说法成了一个仅限于业内人士调侃式聊天时才会提起的营销概念，既没有得到多少人的认可，也没有得到大规模的传播。
但是，这并不妨碍在未来的一两年内，车手互联将成为智能电动车企之间一个非常重要的竞争战线。站在当下这个时间节点，对车手互联有了比较深体验的消费者，并不会觉得车手互联会成为一个多么重要的银子弹。但回望鸿蒙座舱刚刚问世的那个时候，大家当时确实对它的应用接力、超级桌面能力惊叹连连。
要深刻地理解这一点，需要回望一下汽车变革的历史。
要知道，在这波智能电动汽车爆发之前，汽车一向是与先进、尖端的电子信息技术绝缘的。从鸿蒙座舱问世的2022年再往回倒个三四年，手机、平板、PC、手表、和各类智能家居设备早已经通过近场互联技术（主要是基于蓝牙和WiFi）和专属的跨端互联协议连接成了超级大终端。站在万物互联、超级终端的大背景之下，在汽车的智能属性越来越强、越来越像人们生活和工作的第三空间的情景下，车手互联当然会成为用户全场景中越来越重要的一环。
图片来源：华为
所以，车手互联的终极意义在于以人（手机）为中心，将手机这个超级大终端作为智能座舱域的延伸，大大扩展智能座舱的功能边界，让手机与汽车之间形成生态化反，解锁更多意想不到的场景体验。反过来，如果汽车无法和手机实现深度互联，那么，汽车便只是一个孤岛式的智能终端，它的功能边界就好像孙悟空出去化斋时用金箍棒给玄奘大师牢牢划定好了的那一个圈！
在很多友商车企的眼里，车手互联的主导权应该在手机厂商手里。毕竟，现在车手互联需要基于账号体系，而每一个头部手机厂商的用户数量都高达几亿。
其实事情并没有那么简单，今天把车手互联的技术栈稍微展开一下，大家就会意识到其中的难关到底在哪。
车手互联主要涉及三大技术-异构组网、数据流转和多设备协同，篇幅有限，本文只谈前两点。
2.1 异构组网
异构组网是一个通过近场通信技术将设备连接起来的过程。在实际的连接过程中，就像把大象放进冰箱需要分成三步那样，设备间的连接同样也要走三步：广播、发现、连接。
图片来源：小米
其中，广播的过程并不像那个著名的电影《手机》里-“牛三斤，牛三斤，你的媳妇叫吕桂花。。”式地定向广播找人，而是类似于冯小刚在星爷的电影《功夫》里的那个名场面-“还有谁？”，要求周围的设备主动报告自己的硬件资源和所支持的服务。
广播发现之后的过程是异构组网，所谓异构，指的是可以支持多项近场通信技术。今时不同往日，现在的智能终端大多都能支持两三项近场通信技术，比如蓝牙、WiFi、Zigbee、UWB、星闪、NFC、PLC。。。
这个步骤的难点在于，组网连接是通过分布式软总线或者跨端互联总线实现的，这是一套由手机或汽车厂商自己定义的专属私有协议。这就意味着”不是一家人，不进一家门”，同时意味着，进了“任家”的门，就和“雷家”不是一家人了。
连接组网相当于完成了始皇帝奋六世之余烈、统一六国的第一步，接下来，要通过应用接力实现数据在设备之间的自由流转，要做的第二步工作就是“书同文、车同轨”了。
说到“车同轨”，最近刚刚上映的电影《93国际列车大劫案：莫斯科行动》里，因为中俄两方的铁轨宽度不同，需要在边境处停车更换列车的底盘，给犯罪分子提供了两个小时的时间，从而引发了激烈的枪战。显然，只要双方铁轨宽度一致，不用更换底盘，列车（设备）和乘客（设备上的数据）就可以自由流转了。
应用接力背后的技术是分布式数据和分布式文件，我们可以将这个过程理解为函数调用中的压栈和出栈。应用接力的发起端像本地函数一样将导航数据压栈，相当于存储函数调用之前的上下文，接收端像本地函数那样将数据出栈，相当于恢复上下文数据。
这里的难点在于，面对同一种服务，很难保证手机和车机端装载的是同一个应用。我们可以想象一下导航流转这个服务，如果你手机端用的是腾讯地图或百度地图，车机上用的是高德地图，请问阁下应该怎么办？如果说4×100接力，前后棒还可以跑的不是同一个人，但是在车手互联的应用接力里，两端设备上的应用不一致怎么进行接力呢？虽然用户真正想要的是“服务接力”，但是其背后的技术却是“应用接力”。
其实到这里可以做一个总结了。面对诸多手机厂商提供的各种互相割裂的跨端互联协议，面临同一种服务会有几种应用提供商的局面，与其让蔚来车主们面临选择性困难，享受不到完整的车手互联体验，不如自己做一套NIO Link协议，并在蔚来手机和车机两边为同一个服务部署相同的应用。
当然，理论上，我们可以怀着一个美好的祈愿，鸿蒙OS、澎湃OS、潘达纳尔、蓝河OS、Flyme能够统一起来，可是在互相竞争的商业世界里，是不是要等到“山无棱，天地和，才敢与君绝”的那一天？
正是认识到了这一点，并结合上述提到的技术难关来看，蔚来亲自下场做手机才是做车手互联的最佳答案，所以斌哥才说到三年后再来看！
评论