2019年8月，在华为开发者大会上，万众瞩目的HarmonyOS正式对外发布，并宣布2020年HarmonyOS 2.0版本将支持车机。彼时，我们车机OS团队已经成立数月，正在争分夺秒地为目标努力着。2020年10月，在华为Mate 40系列上海发布会上，华为全栈汽车解决方案首次亮相，三大操作系统之一的“HOS”（鸿蒙智能座舱）引起广泛关注。当时，正在西安远程观看发布会的我难抑激动，立刻将直播画面截图发到团队群，顿时消息“炸锅”，“就像看到自己孩子一样，老泪纵横。”“这才刚刚起航，接下来会更精彩！”“今儿是个好日子，晚上约起来！” ……有人感慨，有人畅想未来，回首HarmonyOS “上车”的这一年，我和伙伴们作为第一批拓荒者，经历的一切就像做梦一样。

要想知道山那边是什么，就翻过去看看2019年初，“上车”计划伊始。怀着对华为鸿蒙的憧憬，入职5年，一直在无线的我转岗加入了终端OS（操作系统）部，机缘巧合下被安排加入HarmonyOS车机项目，负责打造汽车智能座舱控制服务。车机是汽车中控屏幕里的操作系统。汽车智能座舱控制，简单来说，就是将整车电子硬件进行统一的管理，让车上的电子硬件更智能化、更安全地“动”起来，从而给消费者带来更极致的体验。比如当驾驶员靠近车时，车会自动做出迎宾动作（如伸出隐藏式门把手）。每次只要一想到电影《速度与激情》中关于汽车驾驶的炫酷智能场景，在不久的将来会被我们实现，我就忍不住心潮澎湃，热血沸腾。但兴奋过后，现实问题也随之而来：项目组除了PL和两个SE，其余都是新手，无论对鸿蒙操作系统还是对车机的了解，几乎都是零基础。我是需求迭代交付的负责人，在对新业务雄心勃勃的同时，也感到了深深的压力。尤其是随着项目的推进，越来越多的难题摆在了面前。其中最头疼的是，车机OS适配车厂的问题。市面上汽车品牌众多，不同车厂/车型的电子硬件各不相同，加上四座小汽车与七座SUV、传统汽油车与新能源车等，也各有差异，那么同一个车机OS该如何适配种类如此繁多的智能座舱，并且最大程度降低车厂对不同车型的定制化成本？问题像一座大山一样困扰着我们，但如果想知道山那边是什么，办法只有一个，那就是用尽一切努力翻过去看看。不能闭门造车是第一步。项目组启动了“开天窗、看周边”策略。PL涛哥和SE磊哥负责联动 EMUI飞马架构专家，尝试把华为手机EMUI适配不同机型的思路应用到车机产品上；我和其他伙伴则负责行业开源社区源码和业界竞品分析。通过一行行的源码分析和提炼总结，我们最终输出了10多篇详细分析文档，算是深入了解了业界顶尖的汽车电子电气控制架构。但光有理论分析还不够，项目组积极组织大家对各大热门车型进行租赁体验和试驾。试驾时由于问得太仔细，我们一度还被认为是某个车厂的销售员来打探对方的消息。而当我们摸清楚行业标准，对真实的汽车也有所了解后，架构设计的蓝图逐渐清晰起来。合理抽象和实例化设计是关键。简单来说，如果我们能把不同车厂/车型的电子硬件抽象出统一的模型，那么就可以用统一的机制来实现对不同电子硬件的访问和控制，从而实现座舱控制服务。这个想法达成共识后，我们紧接着启动了第二步：让架构可解耦和可扩展。我们对汽车电子硬件做软件建模，为区域信息、硬件类型、数据属性统一了描述语言，如同“车同轨，书同文”一样，可以极大提升硬件的扩展性；同时，我们标准化了对汽车电子硬件的控制访问接口，这样一来，无论不同的汽车厂商如何实现具体功能，车机OS都能对接上。同时，为了使能车厂以最短的开发周期、最低的开发成本完成对HarmonyOS车机的适配，我们还提供了汽车电子硬件扩展工具，通过可视化界面以更直接简单的方式指导车厂操作，以降低车厂适配门槛。2019年底我们完成了架构的设计和编码实现，很快这样的思路在和车企的合作中得到了充分的验证。在B车厂项目交付中，基于我们的HarmonyOS版本，座舱产品化团队开发了一款新能源车的车机。之后，在C车厂项目交付中，基于原有的HarmonyOS版本，利用我们构建的可扩展机制，产品化团队可以直接实现与B车厂有差异的电子硬件管理，而不需要重新再出版本，实现了车机OS版本与车型/车厂的完全解耦。而且，用可视化工具定制电子硬件信号，也大大降低了配置出错的概率。最终B车厂项目成功路测，C车厂项目如期进行。交付的兄弟给我们点赞：“整体架构设计很合理。”这个反馈无疑更加坚定了我们的设计思路。HarmonyOS “上车”计划的第一座山就这样被我们跨过去了，但翻山越岭之旅才刚刚开始。没有整车环境，那就创造一个如果说2019年，是迈出了HarmonyOS车机“拓荒”的第一步，降低了厂商使用车机OS的成本，那么 2020年，则是HarmonyOS车机面临交付，迎接大考的一年。这一年，首款搭载HarmonyOS车机系统的汽车进行道路测试，而我们交付的智能座舱控制作为核心子系统，需要尽可能地提前进行场景测试，保障路测能顺利进行。但是，一个大难题随之而来：我们主要是进行汽车电子硬件控制，但除了手上的几块车机单板，没有汽车的任何电子硬件，也就没有整车环境，该如何端到端验证功能，并进行场景覆盖呢？路途密布荆棘，但这并不能阻挡我们。没有整车环境，创造环境也要上。涛哥、我拉着SE和关键开发人员在会议室热烈探讨：“没有硬件设备的话，那我们开发个模拟器怎么样？”SE磊哥率先说道。听到这个想法，我忍不住叫好：“对呀，这个想法好，如果模拟器能模拟车灯、空调、座椅等电子硬件，对其进行语音或者中控屏幕控制，还能模拟汽车行驶状态、白天/黑夜等外界环境，那我们就能进行充足的场景验证了。”眼见问题似乎迎刃而解，但很快就被质疑。“不行不行，模拟器要逼近真实环境行为的话，这个工作量会很庞大。“正在为下周需求准出忙得不可开交的李工说道，”我们的迭代交付节奏已经非常紧张了，哪有这么多时间投入模拟器开发？”“而且做汽车硬件模拟器，业界没有参考，中间到底有多少瓶颈和困难都不清楚，风险太难把控了！”不断的PK中，大家陷入了进退两难的境地。“站在未来看模拟器是必备能力，交付紧张的话可以分步骤实现，咱应该考虑的是价值，要做就做最好的。”涛哥一句话把大家从争论中拉了回来。“有了模拟器，即使没有整车环境，我们依然能进行端到端功能验证，而且结合鸿蒙自测试框架，我们可以实现用例100%自动化，这个收益是很大的。”我补充道。“对，现在只是我们内部使用，但如果以后我们再集成到IDE（集成开发环境）车机镜像中，还可以提供给车机应用开发者使用，这相当于IDE自带了一套整车环境，可以大大提升车机应用验证效率……”磊哥开始展望未来。在不停的头脑风暴中，大家逐渐达成一致：建模拟器即使困难重重，但价值大于一切，构建能力是长远之计。大方向确定后，说干就干。我们调整了已有的需求人力，将开发需求分阶段实现，先交付模拟器最需要的部分——汽车电子硬件的激励模拟功能。为了达到模拟器环境与真实环境零差异的效果，我们一行行仔细阅读B车厂的技术规范书，不放过任何一个细节，深入了解智能座舱各个设备节点之间的工作机制，以便于我们开发模拟器时，可以使它与OS的交互行为能最大程度逼近真实环境。一辆汽车的电子控制信号千余个，不同的信号很多特征都不一样，加上B车厂特有的电子控制信号，需要进行充分的统一抽象、覆盖各种场景的模拟。我们开始争分夺秒向前奔跑，力争模拟器能做到全面覆盖。时间一天天过去，终于，在经历了无数次的白板和会议对齐、加班加点的编码和调试后，模拟器成功覆盖了几乎所有的电子控制信号，能够模拟种类繁多的汽车电子硬件和外界环境。以模拟器为底座，同时依托于HarmonyOS的开发自测试框架能力，我们进行了充分的自动化用例测试覆盖，系统对外API（应用软件编程接口）覆盖率100%，代码覆盖率近80%，几乎覆盖了所有的正常和异常场景。团队的努力也得到了回报：智能座舱控制服务用在了车辆设置、语音助手等几乎所有的车机Top APP上。在B车厂项目的整车路测和吐鲁番夏季测试中，我们交付的系统服务没有出现一个问题，为2020年10月HarmonyOS车机如期亮相奠定了基础。键下有好码，“车机”行更远要高质量地保障车机规模商用，HarmonyOS车机在上市前还需完成一道大关——华为ICSL（内部网络安全实验室）验证。换句话说，华为的产品首先要经过内部相当严格的ICSL送测，必须确保万无一失。打铁还需自身硬，提升开发质量是团队的头等大事。尽管团队80%的人没有送测经验，但我们依旧定下“0问题通过ICSL测试”的挑战目标。因为，不管经验与否，代码的质量才是最重要的。部门也专门设置了HarmonyOS特战队来抽查代码问题。一开始大家写代码都如履薄冰，生怕被特战队抽查出问题而给车机项目带来不好的影响。记得有一天，我正像往常一样写着代码，突然屏幕右下角弹出一封特战队检视问题确认的邮件，心里咯噔一下，打开一看：子系统（车机系统）单例写法存在线程安全问题，且问题级别严重。“严重”两个字看着特别扎眼。我自己也很不解，“单例是最简单的设计模式了，怎么会在这里翻船呢？”带着疑惑，我和同事一番资料搜索后，才恍然大悟：原来是指令重排序惹的祸。找到了根源，问题迎刃而解，但也由此给团队敲响了警钟，写好一个看似简单的单例并不容易，在代码质量上万不可掉以轻心。从那以后，大家对代码的要求更加严格了。我们苦练内功，3人组成一个阳光小组进行代码Review，并且对每一次特战队检测出的问题进行研讨。而且涛哥还发起了“人人做讲师”的软件小课堂，让大家互相切磋。随着代码能力的不断提升，慢慢地，我们再也不怕被特战队检视出问题，反而是为问题找答案：编码和安全规范、常用的设计思路应该都考虑到了，难道是有什么新的技术点自己不知道吗？接着，我们会仔细查找原因，如果确实是没考虑到的隐藏缺陷，就去详细了解相关内容，恶补一番；如果有不同意见，就勇敢和特战队专家一起探讨交流。车机系统主干缺陷密度就在一次次的优化和切磋中越来越低，每个人的编码能力也在无形中飞升。有了这样层层的质量和安全保障，2020年5月，HarmonyOS车机首次ICSL送测中，我们负责的汽车座舱控制服务子系统成功达成了零DI（缺陷）的送测目标。我们一次成功了！而在2020年消费者BG 软件部的鸿蒙金码奖评选中，我开发的汽车电子服务连接保持功能有幸被评为了第一名，车机项目的质量积分也在HarmonyOS子系统中名列前茅。大家在开心之余，也更加坚信：键下有好码，车机行更远。这也更加坚定了我对代码的“纠结”之道。如同我从特战队和其他子系统那里汲取营养一样，我也将吸收后的营养积极传递给组里的新员工。作为子系统Committer，当检视出代码问题时，我会和他们当面交流，告诉他们这样写违反了具体哪条规范，它背后的隐藏缺陷是什么，以及应该怎么设计。随着实战的不断积累，当我看到新同事对编码也开始纠结时，我倍感欣慰，因为，纠结，意味着在编码前充分思考了，而充分思考后写下的代码一定更有生命力。梦想一旦启程，就不再遥远“日月流转无数，顽童嘻闹如故。凭镜独观眉目，已然少年熟。少年志，意踌躇，敢踏崎岖征途。恰逢时，展鸿图。”不知不觉间，我在华为工作已六年，从稚嫩到成熟，从无线到终端，从想做手机到和伙伴们一起代码“上车”，唯一不变的是用代码改变世界的初心。鸿蒙初辟，畅想未来，我又多了一份雄心。期待自己上能看清业界，规划得了竞争力；下能在需要的时候扑上去，解决得了团队里最难的Bug。而我们团队也众志成城，希望以智能座舱为底座，再结合HarmonyOS的1+8分布式能力，打造出极致体验的鸿蒙车机。从拓荒者到领跑者，还有很长的路要走，作为其中的一份子，我坚信梦想一旦启程，就不再遥远。