前言
寫完了《工具篇》,我們再來看看 HarmonyOS 的系統結構,為什麼不先說編碼而選擇系統先進行介紹?俗話說,程式語言只是一個工具,工具多種多樣,而工具作用的物件才是最需要先了解的,這樣可以做到有的放矢(先找釘子,再用趁手錘子),在編碼學習的時候也可以相互映照,起得事半功倍的效果。所以思路上,是先介紹《系統篇》,再展開《編碼篇》。
HarmonyOS 從剛開始推出的時候,就伴隨各種不同的聲音,可以說是褒貶不一,有說是 「Android 套殼,華而不實」,也有說是「突破封鎖,國產之光」,而有趣的是,消費者市場上的華為手機也經歷了極其相似的各種討論。我們從結果上看,今年(2023年)華為推出的 Mate60 系列打破了各種質疑,造就了眾所周知的「遙遙領先」。很難說,搭載在「遙遙領先」手機上的 HarmonyOS 也再一次走到了「聚光燈」下,但這次和之前不一樣的是,再少了很多質疑聲的同時,也引起了各大軟體廠商的注意,各家都在緊鑼密鼓地開發自家 APP 的鴻蒙版本,甚至招聘鴻蒙開發崗位需求也在網際網路寒冬之下顯得獨樹一幟。
說了這麼多技術不強相關的話,也只是想感嘆句,「輕舟已過萬重山」。那我們接下來就具體看一下這個充滿戲劇性色彩的「國產」開發系統到底有什麼秘密。
歷史
2019年8月9日,華為在中國東莞召開開發者大會,正式釋出了鴻蒙系統。鴻蒙系統最初被設計為一個面向物聯網(IoT)裝置的作業系統,但華為表示鴻蒙系統也可以用於智慧手機、平板電腦和其他型別的裝置。
2020年9月,華為釋出了鴻蒙系統 2.0 版本,並宣佈將在未來的智慧手機上使用鴻蒙系統。
2021年6月,華為推出了首批搭載鴻蒙系統的智慧手機。
2022年7月,HarmonyOS 3 正式釋出。
2023年8月,HarmonyOS 4 正式釋出,同時公開 HarmonyOS NEXT 開發預覽版,並宣稱在 NEXT 版本上將作為完全獨立於 Android 的作業系統。
架構
在介紹一個系統之前,首先祭出的肯定是系統架構圖,這裡也不例外,從面到點去理解整個系統的設計思想和意圖是最快速準確瞭解系統的一個重要方法。
我們知道,鴻蒙系統不僅僅針對的是移動端手機平臺的系統,而是基於「萬物互聯」概念,能執行在 PC、平板、車機、IoT 各類裝置上的系統。所以該系統的設計,首先保證的就是系統的相容性和模組的靈活可擴充套件性。
](/img/bVdbwvT)
如上圖所示,HarmonyOS 分為四層,從下向上依次是:核心層、系統服務層、框架層和應用層。系統功能按照「系統>子系統>功能/模組」逐級展開,在多端部署場景下,支援根據實際需求裁剪某些非必要的子系統或功能/模組,符合高內聚、低耦合的特點。
而鴻蒙系統是如何實現「萬物互聯」的“超級終端”系統呢?
我們可以看到,軟匯流排實現了軟硬協同,優先順序排程的功能,資料上透過分散式技術實現了檔案、資料庫和沙箱的資料共享,作為可原子化的應用,實現了可流轉/遷移的特點,一次開發多端部署。
分散式軟匯流排:實現近場裝置間統一的分散式通訊能力,提供不區分鏈路的裝置發現和傳輸介面,具備快速發現並連線裝置,高效分發任務和傳輸資料。
核心層
HarmonyOS 的核心子系統採用多核心設計,支援針對不同資源受限裝置,選用適合的 OS 核心。而驅動子系統(HDF,硬體驅動框架)是 HarmonyOS 硬體生態開放的基礎,提供統一外設訪問能力和驅動開發管理框架。鴻蒙支援三類系統:
- 迷你係統:執行在一些諸如連線模組、感測器、可穿戴裝置,運存介於 128KB 左右的處理器上
- 小型系統:執行在路由器、網路攝像頭等運存介於 1MB 左右的處理器上
- 標準系統:執行在增強型互動、3D GPU、豐富動畫和多樣化元件等 128M 及以上的處理器上
系統服務層
是 HarmonyOS 的核心能力集合,包括適用於各類裝置的基礎能力以及面向特定裝置的專有能力,涵蓋四個子系統集,根據不同裝置形態的部署環境,基礎軟體/增強軟體/硬體服務子系統集內部可以按子系統粒度裁剪,子系統內部還可按功能粒度裁剪。不同維度的裁剪,保證了鴻蒙架構上的裝置靈活性,而分散式的引入,則讓整體系統服務有了互通的可能。這裡對一些理解上可能會有陌生的概念做些解釋:
DFX 子系統(Design for X)
DFX 是為了提升軟體質量設計的工具集,包含 DFR(Design for Reliability,可靠性)、 DFT(Design for Testability,可測試性)、可製造性(Design for Manufacturability)、可服務性(Design for Serviceability)、生命週期設計(Design for LifeCycle)等。X表示產品的某個特性或者產品生命週期的某個階段,目前實現的功能有:
- HiLog:日誌系統,提供給系統框架、服務以及應用列印日誌,記錄使用者操作、系統執行狀態的功能
- HiSysEvent:系統事件記錄介面,定義了 HiSysEvent 埋點介面供應用框架、系統服務使用,用於向 HiView 上報系統時間資訊
- HiView:由框架和外掛平臺組成,包括外掛配置,外掛管理
- FaultLoggered:應用故障訂閱和收集,C/C++ 執行時 Crash 臨時日誌的生成和管理模組
- HiAppEvent:JS 應用事件記錄介面,即打點介面,用於幫助應用記錄在執行過程中發生的故障資訊、統計資訊、安全資訊、使用者行為資訊,以支撐開發者分析應用的執行情況。
DFX 對於開發者而言,更像是一個複雜的事件和日誌系統,該系統貫穿了整個鴻蒙系統的週期和模組,不管是裝置商還是開發者都可以透過 DFX 準確快速地定位到問題,同時 DFX 還提供了分析和診斷服務。
對於日誌分類,日誌可以按型別(Type)、領域(Domain)、標籤(Tag)等進行分類;對於流量管控,有具備流控機制有效地識別濫打日誌的領域;對於隱私管控,採集的日誌是最小化,僅為提供必須服務時收集裝置型號、作業系統、唯一裝置識別符號、登入 IP 地址、軟體版本號、接入網路方式和型別、操作日誌等資訊。DFX 有效保障了在裝置出現應用崩潰、應用卡死、分散式故障、當機、自動重啟、不開機等問題上能分析定位到具體原因並解決問題。
MSDP & DV 子系統
MSDP & DV(Mobile Sensing Development Platform,移動感知平臺;Device Virtualization,裝置虛擬化),可以簡單理解為感測器和虛擬化能力,MSDP 提供分散式融合感知能力,彙總融合來自多個裝置的多種感知源,從而精確感知使用者的空間、移動、手勢、運動健康等多種狀態,實現不同裝置的能力和資源融合。
框架層
包含 UI 框架(包括適用於 Java 的 UI 框架和適用於 JS 的 UI 框架)、Ability 框架、使用者程式框架以及各種軟硬體服務對外開放的多語言框架 API,為 HarmonyOS 應用開發提供了 Java/C/C++/JS/TS 等多語言的使用者程式框架和 Ability 框架。根據系統的元件化裁剪程度,HarmonyOS 裝置支援的 API 也會有所不同。
ArkCompiler 方舟編譯器
這裡再對核心編碼工具 ArkCompiler 做下介紹,ArkCompiler 是華為自研的統一程式設計平臺,包含編譯器、工具鏈、執行時等關鍵部件,支援高階語言在多種晶片平臺編譯和執行,並支撐應用和服務執行在手機、個人電腦、平板、電視、汽車和智慧穿戴等多種裝置上的需求。ArkCompiler 利用 ArkTS 的靜態型別資訊,進行型別推導並生成物件描述和內斂快取,加速執行時對位元組碼的解釋執行,AOT(Ahead-of-Time)Compiler 利用靜態型別資訊直接將位元組碼編譯生成最佳化機器碼,讓應用啟動即可執行高效能程式碼。
相對於動態型別語言的傳統編譯模式,在編譯時期只進行打包原始碼,並且是在安裝之後的執行時執行原始碼解析、編譯執行位元組碼、獲取 Profile 資訊、編譯最佳化執行機器碼,而「號稱」首個動態 AOT 型別語言編譯模式的方舟編譯器,則是將解析原始碼、編譯位元組碼、獲取 Profile 資訊、編譯最佳化機器碼並且打包成位元組碼和最佳化機器碼放在了編譯階段,在應用安裝後,本地直接執行最佳化後的機器碼和位元組碼,這樣做的好處就是減少裝置上的編譯時間,直接做到「執行即可用」。
LiteActor 輕量化併發,提供了 Worker API 支援併發程式設計,在執行時例項記憶體隔離的基礎上,ArkCompiler 透過共享執行例項中的不可變或者不易變物件、內建程式碼塊、方法位元組碼等技術手段,最佳化了併發執行例項的啟動效能和記憶體開銷。
Actor 模型,一個 actor 定義為一個計算單元,每個 actor 包含了儲存、通訊、計算等能力,在分散式系統中,通常包含了非常多的伺服器叢集,每一臺伺服器又包含了大量 actor 例項,他們共同構成了強大的平行計算能力。Actor 的核心思想是獨立維護隔離狀態,並基於訊息傳遞實現非同步通訊。
我們知道 JS 是一門單執行緒語言,在設計之初沒有考慮多執行緒執行的支援和最佳化,所以對於 Actor 模型而言,每一個併發例項都會建立一個完整的引擎例項來支援執行,這樣做的優勢在於讓開發者可以不關注共享狀態和鎖,容易維護和測試,並且非常容易將併發例項遷移成分散式服務,但也造成了啟動慢、記憶體開銷大的問題。而 ArkCompiler 雖然實質上還是 Actor 模型,但透過共享程式內各個併發例項間的不可變物件,將一些基礎設施分層和輕量化,並且重用來減輕併發啟動時間和記憶體負擔。
在原始碼安全方面,區別於 Android Java/Kotlin 程式碼的混淆,方舟編譯器會把 ArkTS/TS/JS 編譯為方舟位元組碼,並且使用多種混淆技術提供更高強度的混淆和保護,使 HarmonyOS 應用包中裝在的是多重混淆後的位元組碼,有效提測應用程式碼安全的強度。
應用層
支援基於框架層實現業務邏輯的原子化開發,構建以 FA/PA 為基礎組成單元的應用(包括系統和三方應用),FA/PA 可以按需下載、載入和執行,基於 FA/PA 實現的應用生態,可以實現三方服務跨裝置智慧分發,提供一致、高效的使用者體驗。在《工具篇》的時候,我們提到 FA 和 PA 的區別在於有沒有 UI 介面,後面 FA 又被 Stage 模型所取代,但在設計結構上不會有太多變化。
從下圖我們可以看到,應用是怎麼靈活動態部署到各個不同裝置中的。華為在除了傳統應用市場之外,還提供給開發者和企業一個分發平臺,在該分發平臺上,使用者可以獨立配置開發的應用可以透過二維碼、碰一碰(NFC)、搜尋、語音、感知等將一些原子化的服務應用部署到不同裝置當中。
以下是對鴻蒙系統對原子化開發的一個例子,簡單而言,透過分發平臺,開發者可以將一個應用中的完整功能(PA1、PA2、PA3)「有選擇地」分發到不同鴻蒙裝置上。這裡的有選擇,代表根據裝置特性選擇特定的原子能力,比如圖中智慧屏只用到了 PA1 的能力,而手機用到了 PA1、PA2、PA3 的完整能力,甚至可以想象下如果有一個搭載了鴻蒙系統的攝像頭 IoT 裝置,只需要用到 PA1 的影片採集能力,而用不到 FA 的介面能力。
總結
從整個鴻蒙系統的設計而言,已經不單單是一個手機系統那麼簡單,而是一個「生態」,透過分散式技術實現多端部署和資料互聯的特性。同時可移植核心能力給鴻蒙覆蓋諸如車機、穿戴裝置、手機、電視、智慧家居等提供了保證,相信鴻蒙後面也會不斷去拓寬它的邊界,達到所謂的「萬物互聯」。
作者:ES2049 / 拂曉
文章可隨意轉載,但請保留此 原文連結。
非常歡迎有激情的你加入 ES2049 Studio,簡歷請傳送至 caijun.hcj@alibaba-inc.com 。