HarmonyOS整體架構分為四個層級，如圖1所示。從上到下，依次為：第一層是應用層，主要涵蓋系統應用、Launcher、設定，以及三方應用。第二層是架構層，提供基礎UI架構、使用者程式架構以及能力子產品架構。第三層是系統服務層，讓HarmonyOS具有分布式流轉負載的能力。大家看到的高速多裝置協同能力就是由該層級提供。而承載整個作業系統，同時發揮晶片算力的基石就沉澱在第四層——核心層。宏觀來說，核心的主要工作包含晶片資源管理、軟體任務排程，以及銜接使用者空間與系統調用能力。
::: hljs-center
圖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的空間管理機制。
視訊連結:https://harmonyos.51cto.com/show/9121
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！
作者：jikecheng，miaoxie，HarmonyOS核心技術專家
想了解更多關于鴻蒙的内容，請通路：
51CTO和華為官方合作共建的鴻蒙技術社群
https://harmonyos.51cto.com/#bkwz