当前位置: 首页 > Web前端 > JavaScript

HDC2021技术分论坛:HarmonyOS内核技术揭晓!

时间:2023-03-27 01:09:18 JavaScript

作者:jikecheng,miaoxie,HarmonyOS内核技术专家HarmonyOS整体框架分为四层,如图1所示,从上到下依次为:第一层为应用层,应用层主要涵盖系统应用、Launcher、设置、三方应用。第二层为框架层,提供基础的UI框架、用户程序框架和能力模块框架。第三层是系统服务层,让HarmonyOS具备负载分担的能力。你看到的高速多设备协同能力就是这个级别提供的。承载整个操作系统和同时发挥芯片计算能力的基石就沉积在第四层——内核层。宏观上看,内核的主要任务包括芯片资源管理、软件任务调度以及连接用户空间和系统调用的能力。图1鸿蒙OS整体框架本期我们将重点介绍鸿蒙OS的内核层。1.HarmonyOS内核组成为了支持HarmonyOS在多设备、多场景下的性能,内核主要由三部分组成,如下图所示:图2内核组成HarmonyOS内核组件:具有智能资源管理能力的内核组件,包括CPU/GPU资源管理、内存管理、IO调度管理和高效文件系统等。标准Linux内核:兼容LTSLinux主线版本,做好周边生态对接。硬件平台BSP:各种芯片和硬件平台(含1+8+N器件)的BSP(boardsupportpackage,板级支持包)基础能力。本期将介绍HarmonyOS内核组件的三大核心技术:高能效CPU资源调度、Hyperhold内存管理引擎、高效文件系统。下面就为大家一一揭秘~2.高能效的CPU资源调度业界大部分操作系统都是基于标准的Linux内核开发的。早期用于服务器和PC设备的传统Linux内核,与我们现在在手机、平板等设备上使用的交互式内核,其设计理念和资源管理方式不同。以CPU资源为例,传统的Linux内核Linux内核存在以下典型问题:同一优先级的服务过多,每次调度可能不会选择关键进程。传统的Linux内核在多用户场景下倾向于公平分配资源。比较明显的特点是多用户并发访问,并发使用公共资源。由于相同优先级的业务较多,可能不会在每次任务调度时都选择关键流程。例如,当设备后台有多个应用或服务任务时,系统中对用户交互最为敏感的渲染任务无法实时调度,导致设备大概率无法使用顺利或点击反应迟钝。也就是我们通常所说的随机冻结。选择能效最佳的CPU资源耗时过长,CPU资源选择过多。传统的Linux内核选择算力的过程是一个缓慢攀升的过程。任务调度必须经过CPU核心集群选择、负载均衡、频率选择等一系列过程。其长进程很容易导致任务调度错过调度窗口,导致算力供给不足。为了解决上述问题,HarmonyOS内核提供了一个全栈调度框架,如下图所示:图3HarmonyOS调度管理框架HarmonyOS调度管理框架具有以下特点:●任务按照优先级进行调度并且现有的系统任务严格分级,在线标注关键流程和直接关系到用户操作体验的相关任务,并对关键任务进行优先级调度。●根据CPU负载选择最优的任务分配我们会动态检测不同CPU的负载,确保当前CPU有足够的计算能力提供。●选择最优频点,实现高能效我们提供了频点、性能和功耗之间的帕累托最优模型。对于每个任务,我们都可以快速选择系统的最佳频点组合,以达到最佳的能效。经测试,HarmonyOS的全栈调度框架可以帮助用户在多场景(尤其是游戏场景)下获得持续稳定的高帧率体验。3.Hyperhold内存管理引擎内存管理方面,由于开源生态无限,应用开发的内存使用量疯狂增长。设备使用时间长了,可回收内存越来越低。造成这个问题的原因有两个:传统的内存数据冷热管理,无法感知业务特性虽然Linux内核提供了很多内存回收机制,但每次内存回收都会有相应的系统开销。比如回收文件页后,如果系统需要再次加载这部分数据,就需要从底层设备Flash中读回数据,这样就会造成Flash随机IO读取的现象。对于IO操作,Flash设备的速度与当前读取任务是随机读取还是顺序读取有很强的相关性。随机读取很容易导致系统随机卡顿。再比如,回收匿名页面后,如果系统需要重新加载这部分数据,就会触发ZRAM解压,消耗CPU。另外,随着应用程序的内存负载越来越重,当系统的冷热数据没有正确识别时,系统的CPU负载会长期处于高负载状态,最终会影响前台应用程序的基本性能。传统的共享内存分配无法感知数据的重要性从内存分配的角度来看,目前的操作系统基本都是采用统一的接口分配方式,这样手机中的多个进程或者多个服务都会共享一个内存区域。在数据回收过程中,会出现频繁的数据迁移和内存震荡。这种现象会增加内核管理内存的开销。为了解决传统Linux内核的内存问题,HarmonyOS提供了Hyperhold内存管理引擎。Hyperhold内存管理引擎将上层系统的调用栈连接到内核,让内核全面感知应用程序的整个生命周期。结合应用的生命周期和周期内的数据访问特点,对每条内存数据进行合理的内存管理。同时,为了减少内核管理内存的开销,我们提出了自研的压缩系统,包括多线程压缩和自研的压缩算法。为了进一步扩大可用空间,我们在Flash设备上创建了可交换区,结合自主研发的聚合交换和内存标记技术,充分利用Flash设备的性能。图4Hyperhold内存管理引擎经过测试,Hyperhold内存管理引擎可以将应用程序在后台的驻留能力提升50%以上,用户可以明显感觉到后台应用程序的存活率得到了极大的提升。4、高效的文件系统存储是整个缓存系统中最慢的路径,很容易成为系统性能瓶颈。不仅如此,由于存储设备的碎片化,存储也容易出现越用越慢的问题。其次,随着系统的发展,系统占用的存储空间越来越大。在多设备传输场景下,分布式文件系统高效的传输能力显得尤为重要。针对以上问题,HarmonyOS提供了高效的自研文件系统。从第一代的eF2FS到最新的HMDFS,文件系统逐渐解决了碎片化、容量和多设备传输的问题。图5鸿蒙文件系统下面我们介绍鸿蒙文件系统从第一代eF2FS到最新的HMDFS的技术特点。第一代数据盘eF2FS:智能感知空间管理,改善使用慢。面对存储使用速度较慢的行业问题,我们使用数据类型感知的多流算法和空间感知的分配算法来减少碎片。同时,通过高效、业务感知的两层智能垃圾空间回收,实现智能感知空间管理。下面我们通过一个视频来更好的理解HarmonyOS的空间管理机制。https://v.qq.com/x/page/b3309...系统盘EROFS:变长压缩,支持压缩和性能双赢针对系统占用存储越来越多的问题,其他操作系统在业界也采取了改进措施,比如squashfs采用了“定长输入,变长输出”的压缩策略,但是会存在读放大的问题。而我们的EROFS(ExtendableRead-OnlyFileSystem,超级文件系统)采用“变长输入,定长输出”的压缩策略,将不等长的文件块压缩成一个等长的存储块存储可能的。这样我们访问任意一个文件块只需要读取一个存储块,减少了无效读。此外,我们还优化了解压性能和IO流程。图6系统盘EROFS变长压缩通过以上关键技术,系统盘EROFS的性能得到了极大的提升:随机读性能平均提升了20%。与Ext4相比,系统初始空间为2GB,相当于用户可以多存储1000张照片或500首歌曲。升级包体积缩小约5%-10%,升级时间缩短约20%。跨设备HMDFS:HarmonyOS结合“批量流”的分布式文件系统具有同一套系统能力,适应各种终端形态的分布式理念要求我们有一个数据流转的基础——分布式文件系统HMDFS。图7HMDFS支持多设备传输。HMDFS提供多种文件系统能力,包括:文件类型聚合、高效缓存管理、批处理接口、分布式权限控制、高效传输、数据一致性管理。通过以上系列技术的开发与融合,最终实现了现有的跨设备高效文件系统,为用户提供流畅的分布式体验。5、未来的演进方向以上就是我们本期要介绍的HarmonyOS内核的核心技术内容。未来还有很多方向值得我们继续探索。下图列出了HarmonyOS内核未来的演进方向。图8未来演进方向相信通过我们的不断探索,一定能打造出更好的内核,给大家带来更流畅、更好的鸿蒙OS体验!