HarmonyOS 内核技术大揭秘｜HDC2021 技术分论坛

作者：jikecheng，miaoxie，HarmonyOS 内核技术专家

HarmonyOS 整体框架分为四个层级，如图 1 所示。从上到下，依次为：第一层是应用层，主要涵盖系统应用、Launcher、设置，以及三方应用。第二层是框架层，提供基础 UI 框架、用户程序框架以及能力模块框架。第三层是系统服务层，让 HarmonyOS 具有分布式流转负载的能力。大家看到的高速多设备协同能力就是由该层级提供。而承载整个操作系统，同时发挥芯片算力的基石就沉淀在第四层——内核层。宏观来说，内核的主要工作包含芯片资源管理、软件任务调度，以及衔接用户空间与系统调用能力。

图 1 HarmonyOS 整体框架

本期，我们要重点给大家讲一讲 HarmonyOS 的内核层。

一、HarmonyOS 内核构成

为了支撑 HarmonyOS 在多设备、多场景下的性能表现，内核主要由三部分组成，如下图所示：

​​​

图 2 内核的组成

• HarmonyOS 内核组件：具有智慧化资源管理能力的内核组件，包括 CPU/GPU 资源管理，内存管理，IO 调度管理以及高效的文件系统等。

• 标准的 Linux 内核：兼容了 LTS Linux 主线版本，做好外围生态的对接。

• 硬件平台 BSP：面向各种不同芯片与硬件平台（包含 1+8+N 的多种设备）的 BSP（board support package，板级支撑包）基础能力。

本期要为大家介绍的就是 HarmonyOS 内核组件的三项核心技术：高能效 CPU 资源调度、Hyperhold 内存管理引擎和高效的文件系统。下面为大家一一揭晓~

二、高能效 CPU 资源调度

业界多数的操作系统都是基于标准的 Linux 内核开发的。传统的 Linux 内核，早期用于服务器和 PC 设备，与我们现在用于手机、平板等的交互式内核相比，它们的设计理念和资源管理方式有所不同。以 CPU 资源为例，传统的 Linux 内核存在以下典型问题：

1. 同优先级的业务过多，每次调度都不一定选择到关键进程。

传统的 Linux 内核偏向于在多用户的场景下公平地分配资源。比较明显的特征是，多个用户并发访问，并发使用公共资源。由于同优先级的业务比较多，每次任务调度不一定能够选择到关键进程。举个例子，当设备后台存在多个应用或者服务任务时，系统中和用户交互最敏感的渲染任务没法即时得到调度资源，导致设备会高概率出现使用不流畅或者点击无响应的现象，也就是咱们平时常说的随机卡顿。

2. 选择最优能效的 CPU 资源时间过长，CPU 资源选择过度。

传统的 Linux 内核选择算力的流程，是一个慢速爬坡的过程。任务调度必须经过选择 CPU 核簇、负载均衡、选择频点等一系列流程。其漫长的过程，极易导致任务调度错过调度窗口，出现算力供给不足的现象。

为了解决以上问题，HarmonyOS 内核提供了全栈式的调度框架，如下图所示：

图 3 HarmonyOS 调度管理框架

HarmonyOS 调度管理框架有以下特点：

● 任务按优先级调度

对现有系统任务进行严格级别划分，在线标记与用户的操作体验直接相关的关键进程和关联任务，优先调度关键任务。

● 依据 CPU 负载情况选择最优任务分配

我们会动态检测不同 CPU 的负载，保证当前 CPU 有足够的算力提供。

● 选择最优频点实现高能效

我们提供了频点与性能、功耗之间的帕累托最优模型。每次任务，我们都能够快速选择系统最优的频点组合方式，实现最优能效。

经过试验，HarmonyOS 的全栈式调度框架可以帮助用户获得在多场景（尤其是游戏场景）下持续且稳定的高帧率体验。

三、Hyperhold 内存管理引擎

对于内存管理，由于开源生态的不限制，导致应用开发的内存使用野蛮生长。设备长时间使用后，可回收内存越来越低。产生这个问题的原因有两个：

1. 传统内存数据冷热管理，无法感知业务特性

尽管 Linux 内核提供了很多的内存回收机制，然而每种内存回收都会有相应的系统代价。比如，回收文件页面后，如果系统需要二次加载这部分数据，需要从底层器件 Flash 里面把数据读回来，这会引起 Flash 随机 IO 读的现象。对 IO 操作来说，Flash 器件速度和当前读取任务是随机读还是顺序读有着很强的相关性，随机读容易导致系统随机卡顿。再比如，回收匿名页面后，如果系统需要二次加载这部分数据，会触发 ZRAM 解压，消耗 CPU。

另外，由于应用的内存负载越来越重，当系统冷热数据识别不恰当，会导致系统的 CPU 负载长期处于高负载状态，最终影响前台应用的基础性能。

2. 传统共享式内存分配，无法感知数据重要性

从内存分配角度看，现在的操作系统基本采用统一接口的分配方式，使得手机里面多个进程或多个业务会共用一块内存区域。数据回收时，会频繁出现数据搬移，以及内存震荡的现象。这个现象会加重内核管理内存的开销。

为了解决传统 Linux 内核的内存问题，HarmonyOS 提供了 Hyperhold 内存管理引擎。Hyperhold 内存管理引擎打通了上层系统到内核的调用栈，让内核完整感知到应用的整个生命周期，并结合应用生命周期以及周期内的数据访问特征，对每一块内存数据做合理的内存管理。同时，为了降低内核管理内存的开销，我们提出了自研的压缩体系，包括多线程压缩、自研的压缩算法。为了进一步扩大可用空间，我们在 Flash 器件上开出了一块可交换区，结合自研的聚合换出和内存标记技术，充分利用 Flash 器件的性能。

图 4 Hyperhold 内存管理引擎

经过试验， Hyperhold 内存管理引擎可以让应用在后台的驻留能力提升 50%以上，用户可以明显感知到后台应用的保活率有大幅提升。

四、高效的文件系统

存储处于整个缓存体系下的最慢路径，容易成为系统性能瓶颈。不仅如此，由于存储器件碎片化的问题，存储还容易出现越用越慢的难题。其次，随着系统的发展，系统占用存储越来越多。而在多设备流转的场景下，分布式文件系统的高效转存能力显得尤为重要。为应对上述问题，HarmonyOS 提供了高效的自研文件系统体系。从第一代的 eF2FS 到最新的 HMDFS，文件系统逐步解决了碎片化问题、容量问题与多设备流转问题。

图 5 HarmonyOS 文件系统

下面我们从第一代的 eF2FS 到最新的 HMDFS，依次介绍 HarmonyOS 文件系统的技术特点。

1. 第 1 代数据盘 eF2FS：智能感知空间管理，改善越用越慢

面对存储越用越慢的业界难题，我们通过数据类型感知的多流算法和空间感知的分配算法，减少碎片产生。同时，通过高效、业务感知的两层智能垃圾空间回收，实现智能感知空间管理。

下面我们通过一个视频，更好地了解 HarmonyOS 的空间管理机制。

2. 系统盘 EROFS：变长压缩，支持压缩与性能双赢

针对系统占用存储越来越多的问题，业界其他操作系统也采取过改进措施，比如 squashfs 采用“定长输入，变长输出”的压缩策略，但会存在读放大的问题。而我们的 EROFS（Extendable Read-Only File System，超级文件系统）采用“变长输入，定长输出”的压缩策略，尽可能地将不等长的文件块压缩成一个等长的存储块进行存储。这样，我们访问任何文件块，只需读取一个存储块，减少了无效读取。除此之外，我们在解压性能和 IO 流程上也做了优化。

图 6 系统盘 EROFS 的变长压缩

通过以上关键技术，系统盘 EROFS 的性能得到大幅提升：

• 随机读性能平均提升 20%。

• 系统初始空间相比 Ext4 节省 2GB，相当于用户可以多存 1000 张照片或 500 首歌曲。

• 升级包大小下降约 5%-10%，升级时间缩短约 20%。

3. 跨设备 HMDFS：“批流”结合的分布式文件系统

HarmonyOS 同一套系统能力、适配多种终端形态的分布式理念，就要求我们有一套数据流转的底座——分布式文件系统 HMDFS。

图 7 HMDFS

应对多设备流转，HMDFS 提供了多种文件系统能力，包括：

• 文件类型聚合

• 高效的缓存管理

• 批处理接口

• 分布式的权限管控

• 高效传输

• 数据一致性管理

通过上述一系列技术的研发与集成，最终实现了现有的跨设备高效文件系统，为用户提供流畅的分布式体验。

五、未来演进方向

上面就是我们本期要介绍的 HarmonyOS 内核核心技术内容了。未来还有很多方向值得我们继续探索，下图列出了 HarmonyOS 内核的未来演进方向。

图 8 未来演进方向

相信经过我们不断的探索，我们能打造出更好的内核，为大家提供更流畅、体验更好的 HarmonyOS！