作者：michalliu，腾讯 WXG 客户端开发工程师

华为鸿蒙OS有什么创新，是否自主研发完全开源，本文带你深入鸿蒙的世界。

一、初识鸿蒙

国内在计算机基础核心领域缺乏建树，一直没有自主知识产权的操作系统。之前又出过多起诸如汉芯，红芯浏览器等造假事件，犹如现实世界的“狼来了”，使国人对任何打着自主知识产权宣传的产品都会戴着放大镜去看，那么鸿蒙到底是不是个例外？

鸿蒙是个很泛的概念，鸿蒙不仅一个操作系统，还是一个生态。鸿蒙这个词在不同的场景下指代不同的东西。根据华为官方IDE DevEco Studio 的应用模板可以看出，目前鸿蒙支持的设备有手机，平板，电视，手表，汽车，以及相机等小家电等等，不同的技术栈开发的应用支持的设备种类也不同。其中Java类型的应用支持的设备类型最为丰富，JS类型的应用其次，C 应用支持的类型最少。

在嵌入式领域， 鸿蒙指是一款嵌入式操作系统，鸿蒙的核心为LiteOS，系统只能在配套的硬件（开发板）上运行，并非通用的操作系统，OpenHarmony是其对外开源的版本，在2020年9月在gitee上开源OpenHarmony 1.0，关于这款系统华为自身的文档比较欠缺，这里有较为详细的开发者文档。

在非嵌入式领域， 鸿蒙指的是一款叫鸿蒙的手机操作系统，最近网上热议的“此应用专为旧版鸿蒙打造”令人疑窦丛生。

（1）设备间的发现和连接：从手动发现，进化成自发现：

（3）多设备多协议间的高效传输技术：

4、通信安全

要实现设备间的互联互通，那么安全无疑是特别重要的环节。这里的问题是如何保证正确的人使用正确的设备，消费正确的数据。即要解决如下三个问题：

（1） 如何保证消费者对设备的鉴权是安全的，保证设备是原厂生产，没有被篡改的？（正确的设备）

（2） 如何保证消费者操作设备数据是安全的？(正确的人)

（3）如何保证消费者数据安全?（正确使用数据）

鸿蒙在系统和数据通信安全方面有较为完善的考虑。

三、系统层分析

基于鸿蒙已经开源的openharmony源码统计，openharmony包含C代码2KW行，C 500W行。

1、内核部分

鸿蒙宣传的微内核，并未说明是哪个鸿蒙，华为目前已经发布的内核包括：

1、Linux 面向手机 (L5级别设备)

2、LiteOS-a 面向有MMU的设备 (>=L1级别)

3、LiteOS-m 面向无MMU的嵌入式设备 (L0级别)

目前行业内对内核进行分类主要是：

1.2 LiteOS-A

LiteOS-A是HW基于LiteOS进行演进的，进行 多进程，多核，虚拟内存，IPC等重新封装，尽量类似于Linux，但是尽量简化内核实现。OpenHarmony LiteOS-A内核架构图：

如上图所示，对于鸿蒙OS，其可以支持各种内核（目前支持Liteos-m,LiteOS-a,Linux）。其通过KAL层对上层提供统一的API接口能力。

我们可以清楚的看到KAL 支持统一是通过支持POSIX和CMSIS（针对arm Cotex-m 的抽象，做到在RTOS层面的尽量统一）对底层内核进行统一封装。做到基于上层API的程序可以在相应的CPU下编译通用，强调只能编译通用。

其中兼容POSIX的库是Musl-libc。该库是一个轻量级的C标准库，设计作为GNU C library (glibc)、 uClibc或Android Bionic的替代用于嵌入式操作系统和移动设备。它遵循POSIX 2008规格和 C99 标准，采用MIT许可证授权，使用Musl的Linux发行版和项目包括sabotage，bootstrap-linux，LightCube OS等等，然后通过HDF来统一驱动模块的编写调试过程。以此来兼容驱动设备。

POSIX表示可移植操作系统接口（Portable Operating System Interface of UNIX，缩写为 POSIX ），POSIX标准定义了操作系统应该为应用程序提供的接口标准。POSIX标准意在期望获得源代码级别的软件可移植性。换句话说，为一个POSIX兼容的操作系统编写的程序，应该可以在任何其它的POSIX操作系统（即使是来自另一个厂商）上编译执行。

CMSIS（Cortex Microcontroller Software Interface Standard）标准，它是ARM同各个微控制器供应商、工具供应商和软件解决方案一起开发的Cortex微控制器软件接口标准。它使得微控制器和软件供应商可以使用一致的软件结构来开发Cortex微控制器的软件。

CMSIS-RTOS是CMSIS的一部分，它本身是一种API规范，各厂商可以基于CMSIS-RTOS构建自己的实时操作系统（RTOS）。由于基于CMSIS-RTOS的API是标准化的，所以基于这些API开发的应用软件，不需要进行额外的移植开发工作，就可跑在任何支持CMSIS-RTOS的OS上。随着基于CMSIS-RTOS的中间件越来越多，支持CMSIS-RTOS后的OS也会因此获得更多的中间件。

4、HDF驱动架构

OpenHarmony驱动主要部署在内核态，当前主要采用静态链接方式，随内核子系统编译和系统镜像打包。

现在开源出来的openharmony方案总体约束为在同一局域网下进行软总线互通。目前开源出来的还是TCP/IP协议建立的局域网。鸿蒙发布会描述的极简协议统一层，我们并没有看到。

软总线的时序图如下，Module可以看成分布式调度服务等，即其他使用软总线的模块。

对于pubulicService 对服务进行发布，实际同时对 软总线进行初始化。（前提是WiFi已经接入了WiFi的局域网）

传输在上面的publicService过程中创建的会话服务 CreateSessionServer（）就是后续进行基于session会话服务的基础。调用者并不需要关心IP等，只需要使用创建的sessionID 进行通信即可。

g_sessionMgr->serverListenerMap[i] 用于存储session。SessionListenerMap结构中，最重要的是listener成员：onSessionOpened，是在会话创建时被回调的函数。onSessionClosed：是在会话结束时被回调的函数。onBytesReceived：是会话的数据到达的回调函数，注册的模块可以通过这个函数接收会话的报文，按照自己的格式进行解析，并执行会话要求的动作。例如：在分布式调度模块中，接收的数据解析后，可能是START_FA的命令。

相关的代码：

3、应用格式

无论是js应用还是java应用，代码最终编译出来包均为hap后缀，这个hap是未经hack的zip格式，可以使用标准的zip解压工具进行解压。

具体hap包的具体安装使用上，SDK提供命令行工具 hdc：

hdc shell am force-stop com.example.myapplicationhdc shell bm uninstall com.example.myapplicationhdc file send ~/DevEcoStudioProjects/MyApplication/entry/build/outputs/hap/debug/entry-debug-unsigned.hap /sdcard/entry-debug-unsigned.haphdc shell bm install -p /sdcard/hdc shell rm -rf /sdcard/xxxhdc shell am start -n "com.example.myapplication/com.example.myapplication.MainAbilityShellActivity" -Dhdc app install xxx.hap3.1、Java应用

java应用在开发时依赖以下SDK包，只能用来编译代码，SDK反编译看不到源码，也未开源。

根据文件命名，对其功能推测如下：

目前鸿蒙是跟Android深度绑定的，鸿蒙切换操作系统的可能性不是完全没有，但成本相当高，应该说鸿蒙Android的这个设计思路是既然摆脱不了安卓，基于这个前提，那么就充分利用它。

3.2、Js应用

从目前已经开源出来的部分上来看基于js开发的应用是一种类似小程序的开发方式，html,js,css首先会编译成jsbundle（编译工具本身未开源），jsbundle的执行不同的鸿蒙系统上有所区别。

Js应用在鸿蒙嵌入式系统上执行分析

经过对openharmony代码分析，在openharmony里Js应用是以自绘的方式渲染，支持的UI组件看起来还比较完善（从源码里看绘制部分似乎参考了部分flutter代码），使用三星的Jerry Js引擎，猜测是挖的三星的人？因为这个Js引擎实在太小众，Google V8他不香吗？

UI组件框架在 ace_engine_lite 里，从开源的代码我们看出支持的UI组件还比较丰富，除了常规的控件，还包含列表，动画等复杂控件的实现。

这些文件的作用如下：

对于Js应用来说核心逻辑由ohos.aafwk.ace.ability.AceAbility完成jsbundle的加载和运行工作。

（注意：虽然java应用和js应用在解压后目录结构似乎差不多，文件命名也差不多，但其工作原理完全不同。在Java应用里class.dex已经是鸿蒙应用的真正可执行代码。在js应用里class.dex还是一个壳，这个壳用于打造执行Js应用的运行环境，真正的业务逻辑在app.js里。)

js应用布局文件及显示效果:

dump出UI的绘制方式，可以看到Js应用的UI绘制，在鸿蒙Android上是用Android的UI控件来承载，非自绘UI。

             

鸿蒙应用层在设计上，基于自己的DSL和应用运行框架，在嵌入式设备上以自绘的方式渲染，在鸿蒙Android上通过适配层转换为Android原生控件渲染。这样的设计优势是减轻了工作量，组件方面可以复用Android的生态，能力会更丰富，毕竟从零再打造一套完整且庞大的UI体系成本太高，体验还不一定有Android做的好，而劣势则是牺牲了可维护性，两套方案要各自独立维护，维护成本较高，另外还可能带来兼容性的问题。从openharmony源码上看，基于自绘方案并没有预留给Android的扩展接口，targetos仅包含linux和liteos两种，因为渲染层架构不同，未来的改成一致的可能性也较低。

六、总结

鸿蒙OS并不定位于对Windows、Android进行替代，而是剑指万物互联时代全场景、多终端的操作系统，与此相对应，鸿蒙OS（及大华为体系）所有的生态布局也将围绕万物互联展开。鸿蒙OS在完成细分场景的拓展与跑马圈地后，鸿蒙OS将完善华为AIoT生态，进一步在智慧城市、车联网（深化）、工业互联网三方面发力推进。

中长期来看，鸿蒙OS与华为“云 端”芯片形成强大合力，进军产业物联网。华为优质网络设备是IoT的连接基础，连接获得了大量数据，但只有通过智能分析才能够形成杀手级应用。华为已在云侧和端测拥有昇腾、鲲鹏、麒麟等芯片，具备强大算力，叠加鸿蒙OS高效、灵活的执行力，将培育大量高价值应用。基于近景和远景的生态蓝图，当前鸿蒙OS的发力抓手仍是以移动端为核心的HMS产业链。