甜草莓，不是专家 | 人人都有不知道的东西，讨厌嘲讽类评论 阅读原文 我觉得要正确理解鸿蒙做了什么，重点是什么是「物联网」操作系统？而就这个话题本身，可以说目前大多网上的答案都是存在误解，比如大多数报道把在设备上运行的嵌入式操作系统和鸿蒙（当然还有其他一些厂商的系统）统一称为「物联网」操作系统，这是不对的。 至少在这条新闻里，是不对的，它们有比较显著的区别。 如果说大家常用的计算机操作系统在帮助用户怎么通过软件使用计算机，嵌入式操作系统的是解决物联网设备本身的联网和计算问题，而鸿蒙的设计思路是解决物联网联网以后，用户能通过软件做什么 / 怎么做方便的问题。 我会在下文稍微介绍后两种的区别，然后介绍鸿蒙 2.0 在这个设计思路下做了什么事，希望能给大家带来一些思考。 1. 面向物联网设备的嵌入式操作系统不等于鸿蒙 首先，一个大家都应该注意到的事。在物联网时代，电子设备正在海量出现，而且这些终端本身呈现异构化特征。这带来了几个现象， 一个是设备与设备之间连接的增长速度正远大于设备本身的增长速度（以智能手表为例，可以连接 wifi，同时连接多个蓝牙设备）； 另外一个是，设备自身的硬件和连接协议，正在变得越来越多样化，甚至可以说碎片化（比如，物联网设备的存储空间可能从低功耗终端的数十 K 到车联网终端的数百 M 不等，物联网终端的计算单元可能从性能不高的 MCU 到强大的服务器芯片）。 众所周知，操作系统的意义在于，对设备硬件的基本功能抽象，为各类应用软件提供统一接口，从而隔离屏蔽复杂的硬件调度操作，让各种应用软件无需和硬件打交道就可以直接操纵硬件。 物联网时代，硬件本身出现了新问题，这自然是操作系统的新机遇和新挑战。为了解决这些设备自身的连接，碎片化，安全性，自然也诞生了相当多的嵌入式操作系统，比如，华为从前的 LiteOS[1]，ARM 的 Mbed OS[2]，FreeRTOS（以及扩展的 SafeRTOS，Amazon RTOS 等）。 这些源自于嵌入式操作的物联网设备系统的显著特点是： 硬件驱动和操作系统内核可分离。因为物联网设备的异构和碎片化特点，所以不同设备会有不同的固件和驱动程序，需要分离驱动和操作系统内核，让操作系统内核可以成为更容易扩展和可重用的资源。 操作系统可配置裁剪。正如之前所说，物联网终端的硬件配置从几十 k 到几百兆存储空间都存在，因此同一个操作系统需要可以通过裁剪或者动态配置来同时适应低端或者高端复杂的要求。 保证设备间的协同互用。物联网环境下各个设备相互系统工作的任务会越来越多，操作系统需要保证物联网设备之间的通信功能。 保证物联网设备的安全可信。物联网设备本身的会存储更多敏感数据，所以对设备的接入鉴权要求更加高。 在这种想法下，这类操作系统虽然解决了物联网设备的硬件操作，互相调用和联网问题，它并没有考虑当物联网设备联网以后，用户能通过这些系统做什么 / 怎么做方便。 从用户角度，这类物联网设备系统的调用流程一般是这样的： 用户需要通过自身的 APP/ 或者物联网设备管理后台（比如云端管理程序），调用设备上的物联网操作系统对外接口，再通过物联网设备上的系统接入硬件设备。这里往往涉及移动操作系统与物联网设备系统之间的相互调用，而此时的 APP 往往只是一个物联网设备管理后台，任何物联网设备之间的联动都会非常复杂，需要设备厂商从最基础的应用功能到设备连接都逐步开发调试，才能在 iOS 或者 Android 上线相应的 APP，或者从云端完成控制。从某种程度上说，这也是目前物联网应用程序稀少的根本原因。 这是目前的物联网设备系统能做到的事。 2. 鸿蒙在设计思路上改进了什么？ 设备间连接不再是应用层功能，而是通过中间件对用户封装隔离。 从表象上看，鸿蒙通过「分布式软总线」（华为的造词能力真的非常出众）隔离了物联网设备的连接，进而避开了手机系统上的连接管理，所以大家可以在发布会上看到了鸿蒙手机与物联网设备之间的相互调用非常便捷。 但是从操作系统角度，连接的封装隔离，带来的并不只是连接管理的便利。它意味着「连接」从应用层下沉到硬件层面，成为碎片化操作系统的基本能力； 一方面，它代表着跨平台的操作系统资源调用不需要跨层，也就是说跨系统的数据交互不需要经过用户连接和确认，所以在保证连接质量的情况下，操作系统有能力跨设备寻址。这时候，两个设备之间的硬件设备 / 计算系统 / 储存系统（文件系统）是互通的，所以两个或者多个共享硬件 / 存储的设备可以实现「超级终端」（当然，需要保证连接质量和时钟同步），比如跨设备的摄像头同步，文件同步（可以找到发布会例子），甚至未来有可能的 CPU/GPU 跨平台调用。 另一方面，它也代表着开发者本身不需要再过度关注物联网连接所带来的复杂调试，只需要关注功能逻辑和界面逻辑。这会大大降低物联网应用的开发成本，因为此前每个应用系统都需要从最基础的应用功能到设备连接进行开发和调试，导致应用系统的可适应性差，开发和适配的成本高、周期长。开发者只需要依靠鸿蒙提供的 API，就可以避开繁杂的调试连接，完成对多个设备的适配和开发。 可以想象到的是，未来的鸿蒙平台会出现很多多个物联网设备联合起来实现的应用案例，这些案例发挥的作用会大大超过简单叠加的效果，而这些效果原本需要比较高的开发成本以至于难以实现。 比如一组智能灯和人体传感器的协同，通过人类行为控制智能灯的开关；比如路灯和光线传感器的协同，通过户外光照自适应调整屋内亮度；比如在灯光秀里，通过摄像头或者无线传感器，伴随舞蹈演员的动作实时控制灯光效果。 在这种情况下，才能 完全避免跨系统调用，以至于物联网软件和大量的物联网设备硬件可以通过操作系统实现真正的解耦 面对截然不同的场景，通过一个操作系统向所有物联网设备提供基础服务（原子服务卡片） 应用开发只需要关注功能逻辑，极大的提升多物联网设备应用的开发效率。 如果我们再深入思考，当所有的设备都可以连接，那么设备上的应用服务会不会有主次？当然应该有，目前的鸿蒙系统以人为核心提供服务，人的注意力设备即为主设备。 正如我最开始所说，相比于现有的物联网系统仅仅解决物联网设备海量连接，设备碎片化这些基础问题，让物联网设备可以相互链外，而鸿蒙更多的是在考虑当物联网之后，用户和开发者可以怎样便捷的使用 / 调用这些设备完成 1+1 大于 2 的效果。 显然后者更加重要，对于目前物联网系统的发展，也更有意义。 完。 阅读原文
