作者：peitaiyi，華為終端OS產品交付專家HarmonyOS是一款面向萬物互聯時代的、全新的分布式操作系統。在傳統的單設備系統能力基礎上，HarmonyOS提出了基于同一套系統能力、適配多種終端形態的分布式理念，能夠支持手機、平板、智能穿戴、智慧屏、車機等多種終端設備，實現更好的萬物互聯。那么，HarmonyOS是如何用一套OS源碼部署到多種終端的呢？本文將為你揭秘。

一、面臨的挑戰

首先，我們先簡單介紹一套OS部署到多種終端面臨的兩大挑戰。

傳統OS能力比較單一：一套OS系統部署到多種終端，不僅要支持百KB到GB級的內存，還需支持主流CPU架構、板級的器件、各種SoC及外設模組。而傳統OS大都是單設備操作系統，一套OS僅適配于一套設備，無法滿足碎片化的硬件需求。

傳統OS裁剪拼裝能力差：產品形態分布于千行百業，大到汽車、電視、手機，小到手表、門鈴、烤箱，不同功能的產品對OS的能力訴求不同，這要求OS可以靈活地剪和拼裝。而傳統OS裁剪拼裝能力差，無法滿足千行百業的產品。

圖1 硬件和產品形態的碎片

二、HarmonyOS應對策略

基于上述的挑戰，HarmonyOS應對策略是“OS可大可小，部件一次開發可在多種終端上部署” 。

1. 部件介紹部件是HarmonyOS系統能力的基本單元，具有可復用、可裁剪、可配置、可獨立編譯和測試的特點。以源碼、配置和資源文件為劃分依據，擁有獨立的文件和目錄，可在不同的設備上實例化為不同的庫或二進制文件，圖2所示。從系統角度看，部件可視為任何能運行在HarmonyOS上的軟件。從外部設備看，部件則可視為一個個按設備所需組裝成OS的系統能力。

圖2 HarmonyOS部件化示意圖2. 部件拼裝

HarmonyOS源碼由“必選部件集”和“可選部件集”組成，必選部件集具有HarmonyOS特征的必選系統能力，可選部件集則具有產品可裁剪的系統能力。被裁剪的部件只會引起對應系統能力的缺失，不會引起系統的異常。

必選部件和可選部件像“積木”一樣，根據設備硬件模塊（攝像頭、揚聲器、屏幕、網絡）與內存大小靈活拼裝成不同的OS軟件包，并部署到不同設備。“大設備裝大系統，小設備裝小系統。”無論智能設備的運存大小如何，總能找到匹配TA的那一塊系統積木。

圖3 積木拼裝HarmonyOS部件拼裝流程如圖4所示。HarmonyOS發布歸一化的SDK，應用開發者使用SDK和IDE進行跨設備的應用開發，再按不同的設備類型分發應用。同時，三方的部件也可以與OS軟件包一起部署到設備中。

圖4 HarmonyOS部件拼裝流程至此，相信大家對部件拼裝有了一定的認識。隨著萬物互聯時代的不斷發展，HarmonyOS將適配越來越多的硬件設備，這就使得部件開發將馬不停蹄，以適應千行百業的硬件產品。開發者如何開發部件呢？下文將為你解答。

三、如何開發部件

我們都知道，HarmonyOS是基于開源項目OpenHarmony開發的面向多種全場景智能設備的商用版本，HarmonyOS的部件大都來自OpenHarmony，所以下文對部件開發的解答，將圍繞OpenHarmony部件的開發展開。

在OpenHarmony生態中有三大類開發者：OS開發者、芯片解決方案廠商和產品解決方案廠商，如圖5所示。

圖5 OpenHarmony開發者

OS開發者提供OpenHarmony所需的部件，包括內核、驅動框架、圖形、媒體等基礎的系統能力。

芯片解決方案廠商對OS的驅動和接口進行適配，形成基于開發板的完整芯片解決方案。

產品解決方案廠商基于OS和成熟的芯片解決方案組裝產品。

1. 部件標準化

部件開發前需完備部件詳細設計，在此過程中部件標準化尤為重要。

部件標準化確定了部件的名稱、功能、可配置的特性、詳細的規格和依賴。一個典型的部件的定義，圖6所示。它包含了部件的名稱、功能描述、是否系統必選、ROM/RAM、可配置特性和依賴等等。部件的依賴應盡量簡單合理，杜絕循環和冗余的依賴。禁止部件直接依賴特定硬件和產品。

圖6 部件定義文件只有OS的系統能力都按部件進行標準化后，對外的系統能力才能靈活按需拼裝。2. 部件、開發板和產品嚴格解耦

為了保持OS可裁剪可拼裝的能力，部件開發過程中，部件與開發板和產品之間應嚴格解耦且可獨立編譯。至此，我們將開發視圖分為OS部件、芯片解決方案和產品解決方案，如圖7所示。“OS部件”目錄主要存放OS的能力集，比如內核、媒體、圖形、電話、分布式軟總線、安全等等。“芯片解決方案”目錄主要存放芯片廠商基于某個開發板或者SoC對OS的適配。“產品解決方案”目錄主要存放產品相關的配置以及廠商對OS接口的實現。

圖7 OpenHarmony開發視圖目錄樹示意圖基于OpenHarmony開發視圖目錄樹，實現了部件、開發板和產品各自獨立的開發，保障了三者良好的解耦性。3. 全流程管控

部件在設計、開發和測試過程中，需嚴格管控整個流程。如圖8所示，設計文檔在對應PMC審核通過后方可啟動部件的開發，在SIG組開發功能成熟后，再經OpenHarmony對應子系統的committer審核合入。合入后，測試團隊將按部件獨立測試驗收，驗收的范圍不僅包括部件的功能和穩定性，還包括部件是否可獨立編譯、獨立測試、依賴是否合入等等。HPM（HarmonyOS Package Manager）審核人員審核通過后，便可以申請HPM上架。

圖8 HarmonyOS部件管控流程

說明：

PMC（Projects Management Centre）是指項目管理委員會，負責OpenHarmony 社區的管理工作，擁有代碼庫寫權限、OpenHarmony 新版本發布、Roadmap發布、新PMC/Committer等社區事務的投票權、以及新的 PMC 成員和 Committer 提名權。

SIG（Special Interest Group）是指特別興趣小組，SIG在PMC項目管理委員會指導下，負責OpenHarmony社區特定子領域及創新項目的架構設計、開源開發及項目維護等工作。以上就是本期全部內容！相信大家對部件有了一定的認識，歡迎廣大開發者參與到部件開發中。

原文標題：“積木拼裝”，HarmonyOS彈性部署大揭秘！

文章出處：【微信公眾號：HarmonyOS開發者】歡迎添加關注！文章轉載請注明出處。