11 月 4 日，松山湖畔，第四屆華為開發者大會召開。

作為開發者，自然最關注的是大會中關于開發框架/套件以及開發者工具的部分，畢竟這是和開發者直接打交道的領域。無論是大會上著重強調的原子化卡片、分布式服務、超級中轉站等功能，其底層都是基于 HarmonyOS 3 新的技術體系架構。

在 11 月 5 日上午開發者主題演講里，華為技術專家用三句話定義了這一代的鴻蒙操作系統：

一次開發，多端部署；

可分可合，自由流轉；

統一生態，原生智能。

愿景很美好，但是要達成這樣的技術全景，需要的技術板塊非常多，不由讓人懷疑完成度究竟如何。其實道理很簡單，因為一旦涉及到銜接開發者，衍生出來的問題就會像石頭扔進平靜的水潭里一般——設計系統、運行時管理、UI框架、編程范式、調試、調優、測試、日志、上架、分發……特別是還要面對當前這些已經被其他成熟平臺把開發體驗喂養得極其挑剔的開發者，鴻蒙真的做好準備了么？

順著這個思路，我嘗試在主題演講和開發者論壇里尋找答案。

好在我的答題本上不是空空如也，近一段時間里，百度正在使用鴻蒙的新 UI 框架 ArkUI 以及 Stage 應用模型制作了 OpenHarmony 版本的百度 APP。除此之外，我還在動態化跨端開發方面嘗試推進和 ArkUI 對接，并取得了初步的成果。

先來看一下 HarmonyOS 的技術棧，由下至上分為三層，依次是：

* 由 HarmonyOS Design、ArkTS、ArkUI、ArkCompiler 為基礎的開發基礎框架/套件層；

* 由 DevEco Studio 和 DevEco Testing 組成的開發者工具層；

* 由 AppGallery Connect（AGC）支撐應用上架、分發和運營層。

展開來講的話，篇幅會很長，本文會抓住其中最重要的部分進行分析，這里我給出四個關鍵詞：**性能**、**可控**、**體驗**、**動態**。

注：本文提到的內容大部分面向明年 Q1 鴻蒙將要退出的 3.1 版本的操作系統。

且聽我一一道來。

性能

性能依賴輕量級的運行時環境，鴻蒙 3.1 版本的革新有很多。這里講解其中最重要的 3 點：

* ArkUI 渲染樹歸一

* Stage 應用模型帶來的資源優化

* Runtime 輕量化并發

我們知道，一般渲染框架的后臺架構由三棵樹支撐（以 flutter 為例，Widget Tree、Element Tree、Render Tree），它們各司其職。有的是為了銜接組件系統，有的是為了在內存中維護真正的結構信息（承擔 Virtual DOM 的責任），有的為了橋接底層渲染引擎。

ArkUI 在此基礎上進行了融合升級，把多節點組合模型升級為“單節點+屬性”的組合模型，將數據依賴組件級更新升級為細粒度函數級更新，從而從而實現三棵渲染樹的歸一，提升了組件構建速度，降低了內存占用。

（上圖來源于大會主題演講）

按照鴻蒙官方給出的數據，這次技術升級帶來的性能收益包括：渲染速度提升 20%、渲染內存降低 30%、渲染指令數降低 20%。

除了渲染樹優化，鴻蒙應用模型進行了徹底的迭代，從 API 7 支持的 FA 應用模型切換為 API 9 的 Stage 應用模型，FA 模型在未來會淡出歷史舞臺。Stage 模型相關的知識點有很多，在性能這一 Part，我們著重了解下它帶來的最為重大的變化——同一個虛擬機中可以容納更多個組件。這使得開發者更為方便地共享狀態的同時，還能大幅降低內存的占用率：

（上圖來源于分論壇——鴻蒙開發套件（語言與框架）——利用Stage應用模型快速構建HarmonyOS應用）

除了應用模型的更新，在 ArkCompiler 運行時層面，鴻蒙打造了 Lite Actor 輕量化并發模型。鴻蒙除了輕量化基礎架構，還支持了對象共享機制（目前支持不可變對象的共享，未來還會支持可變對象的部分共享）：

（上圖來源于分論壇——DevEco開發工具新特性——深入淺出ArkCompiler）

在支持傳統的基于 Worker 的多線程之余，鴻蒙還支持新的 Task Pool API。從代碼體驗上來說，相比 Worker，Task Pool 的使用更加直觀清晰，開發者無需關心并發實例的生命周期，業務無需關心場景下并發負載問題，因為負載管理在運行時由 OS 層面統一協同處理，管控線程數和線程資源開銷。

當然，除了以上三點之外，ArkUI 的 AOT 編譯管線、XComponent 接入底層的高性能渲染方案以及各種性能調優后的高階組件庫……都大幅提升了 3.1 版本的鴻蒙的運行性能。

可控

先來問大家一句：開發的時候你最怕什么？

我自己的答案是：不可控。無法收斂的 bug，時不時會冒出的所謂的“底層”問題，以及黑盒的構建、編譯、渲染 pipeline……這些都是程序員頭發的終極殺手。

畢竟大家都習慣把命運掌握在自己手里，新版本的鴻蒙自然也想到了這點，我認為主要體現在 3 個方面：

* 基于 ArkTS 的聲明式開發范式

* Stage 模型對鴻蒙應用運行規則的重構

* Hvigor 對構建任務流的自由擴展

你可能會想：ArkTS 的聲明式開發范式和可控性有什么關系？畢竟 JS/CSS/Template 的單文件合一在別的框架的 SFC 模式里早就實踐過，而且聲明式的開發模式已經不是什么新鮮的事情。但深入來看， ArkTS 在可控性和標準化這里做得更加“極致”了些。

通過裝飾器，ArkUI 把一切組件 UI 相關的開發徹底“樂高化”，包括組件定義、入口定義、狀態定義、UI Builder 定義、組件擴展定義。并且，ArkUI 提供的豐富的內置組件、屬性方法和事件方法，都讓 UI 開發變得更加可控。

再來說下 Stage 模型。前文提到 Stage 模型時主要說了它對于虛擬機管控和組件資源占用和內存共享的優化，這里主要想強調的是，與 FA 模型（以及 AOSP 生態為代表的復雜的應用模型）不同，Stage 模型簡化了鴻蒙應用的運行規則。

在 Stage 模型里，Ability 被分位 UI Ability 和 Extension Ability，前者是一個 UI 容器，每一個對應一個獨立的任務（MIssion），在主進程中運行；而后者是一個模板服務（使用是需要使用 Extension Ability 的派生類），銜接系統服務，場景化地支持特定服務，雖然在單獨的進程中運行，但是和主進程有一樣的 uid，共享數據目錄。

（上圖來源于分論壇——鴻蒙開發套件（語言與框架）——利用Stage應用模型快速構建HarmonyOS應用）

Stage 模型體現了鴻蒙“節制”的設計思想，不支持開發者配置多進程，不支持開發者自定義服務，不支持應用直接拉起自己的場景服務；只支持應用間 UI 展示界面的相互調起以及通過系統服務調起場景服務。

最后聊一下 Hvigor 對構建任務流的自由擴展（Hvigor 是 DevEco 集成的官方構建打包工具）。說實話，在來參加 HDC 之前，我對 Hvigor 構建工具的認知還處于黑盒狀態，只是從之前的技術交流中知道它使用了主流的 Web 向的前端構建方案（Webpack），當然因為其 TS 超級的語言特性，也包括了相關的語言編譯方面的 Configuration。但是在聽了華為工程師的分享后，我了解到，在 Hvigor 的構建 pipeline 中，工具會為開發者預留了很多 Task 插槽，可以插入到你想要介入的編譯構建環節：

（上圖來源于分論壇——DevEco開發工具新特性——DevEco Hvigor 工具助力靈活高效構建打包）

比如構建前的集成環境檢測、構建過程中插樁修改特定代碼和資源以及構建打包的后置任務。開發者可以復用 Hvigor 的調度能力，提升任務的執行效率。

對開發范式、應用模型和構建打包的精心設計，讓開發者享受到“我命由我不由天”，除此之外，在開發調試、調優和測試環節，鴻蒙的開發者工具也做了大量的工作，這里且不一一贅述。

體驗

用戶體驗永遠是繞不開的話題，HarmonyOS 給自己的定位是“面向萬物互聯時代的全場景分布式操作系統”。對于一個分布式系統，最有挑戰也最需要解決的就是體驗一致性問題。在本次 HDC 開發者大會里，對于這個問題，鴻蒙從設計和技術兩個維度給出了解決方案：

* 設計上，深入實踐響應式布局的設計方案

* 技術上，做到一次開發多端部署

用戶體驗在 UI 層面的基礎是設計系統。從十幾年前我剛開始接觸前端開發，柵格化就植入了我的大腦，今天看鴻蒙的新設計語言，基礎依然如是。之前的 HDC 大會上，設計方向就提出了“屏幕斷點”的概念，針對不同設備和不同尺寸的屏幕進行差異化的布局和顯示，這次迭代，鴻蒙基于柵格系統又強化了這一概念。

柵格系統由 Margin（邊界大小，決定了整體寬度）、Gutter（內容 Column 間距）和 Column（內容占位元素）三個屬性構成，是響應式布局的基礎。

（上圖來源于分論壇——鴻蒙開發套件（語言與框架）——HarmonyOS動態響應式布局介紹）

通過斷點、Media Query 和柵格化，響應式布局可以實現界面隨外部容器大小有級不連續變化。而在系統默認推薦的超小、小、中、大四個屏幕斷點的基礎上重構柵格系統，使得局部容器的變化方式可以相互獨立，共同打造 Harmony（和諧）的交互體驗。

技術上，鴻蒙對交互事件手勢進行了歸一化處理，提供了大量的具備自適應布局能力的組件，但是，比較吸引我的是鴻蒙對于端（系統）能力的處理和封裝。

做過移動端開發的同學都知道，端能力的紛雜堪比當年對 IE 6/7/8 以及各種移動版本 Webview 的支持，而因為端能力的適配問題引入的 bug 以及不良開發體驗給很多程序員都帶來了不好的體驗。對于語言層面，可以針對 JS 引擎不同版本進行統一的 polyfill 管控，而對于系統的端能力，如何分而治之，則需要投入更大的精力。這不光影響功能是否正常運行，對于 OpenHarmony 這種分布式的 OS，由于需要支持更重 IoT 設備，端能力的管控顯得更加重要。

為此，鴻蒙引入了一種叫做 syscap（System Capability）的機制來解決端能力的管控問題，把系統能力分為支持能力集、要求能力集和聯想能力集。

（上圖來源于分論壇——鴻蒙開發套件（語言與框架）——一次開發，多端部署）

支持能力集是針對設備的，不同設備的能力集合不一樣；要求能力集，顧名思義，是針對應用在不同設備上需求的交集，因為必須提供這些能力應用才可用；聯想能力集則針對開發場景，是在 IDE 中針對能力進行的聯想 API 集合。

你可能會問，既然設備之間的能力不一樣，那么在使用能力的時候，如何判斷哪些能力可用，哪些能力不可用？答案是：`CanIUse`。對，就是大家在 Web 開發中經常做兼容性查詢的那個 CanIUse 網站同名的查詢接口，開發者可以通過這個方法來判斷設備是否支持某個系統能力。

能力的支持程度決定了分發結果，而開發者也可以在配置文件中對聯想能力和要求能力進行配置。

配置，這兩個字很關鍵。

鴻蒙力求使用最少的代碼，依賴聲明式的 UI 編程和豐富的組件庫，依賴項目豐富的配置文件，落地“一多開發”模式，為開發者提供良好的編程體驗，為用戶提供優秀的跨設備使用體驗。

動態

**城外的人想進去，城里的人想出來。**

動態化也一樣。一方面是 ArkUI 能夠做到跨平臺，另一方面是其他跨平臺框架能夠橋接到 ArkUI。

對于 ArkUI 來說，除了作為 HarmonyOS 原生的應用框架，以及原子化服務的基礎運行環境，它的目標還有一個，就是作為三方應用的通用跨平臺框架：

（上圖來源于分論壇——鴻蒙開發套件（語言與框架）——如何利用ArkUI開發跨平臺的應用程序）

這里背后要解決的問題很多，比如組件和 API 的適配，系統能力的適配，資源適配，工作流的適配等等。

從美的技術專家的分享中，能夠看到，在“把 ArkUI 變成通用跨平臺的框架”這條路上，鴻蒙團隊和第三方開發者已經做了很多工作。比如 MiniX，這是基于 OpenHarmony ArkUI 二次開發的適配美的 IoT 場景的跨端應用開發框架，已經對組件和 API 進行了分級適配，并且還開發了配套的定制化的 VSCode 插件。

（上圖來源于分論壇——鴻蒙開發套件（語言與框架）——ArkUI跨平臺能力節約開發成本實踐）

對于三方框架向 ArkUI 橋接這一個路徑，鴻蒙同京東進行了深入的合作。京東輕量級的跨端渲染框架 MCube 將內容通過動態化模板的方式下發到端側，經過 DSL 解析來實現局部數據更新。與此同時，可以借助 ArkUI 的統一渲染能力，減少渲染節點，實現性能和功耗的優化。

（上圖來源于分論壇——鴻蒙開發套件（語言與框架）——HarmonyOS開發語言與框架新進展）

對于三方框架如何同 ArkUI 聲明式開發范式進行橋接，我也給出了自己的看法，即“混合跨端開發方式”。百度的動態化開發框架 Talos 以及其包含的輕量級動態化方案 Talos Lite，未來會和 OpenHarmony 技術棧進行深入的整合。

動態化命令式的三方框架想要橋接到 ArkUI 聲明式的開發范式上，需要整合三方庫自己的 Element Tree 和鴻蒙的節點樹，實現 widget 層的組件級別的渲染驅動，而 ArkUI 暴露的 XComponent 組件以及自定義組件的開發模式，能讓這一橋接過程變得更加深入，性能更加高效（Talos-OH 2.0）。與此同時，像 MCube、Talos Lite 這樣的“描述協議型”的輕量級跨端渲染方案，則能充分發揮出 ArkUI 高性能的渲染特性。

因此我認為，基于“體驗一致性”、“性能”、“復雜度”和“標準化對齊”的決策模型，能夠指導開發者進行正確的技術選型：

（上圖來源于分論壇——鴻蒙開發套件（語言與框架）——Talos應用框架與ArkUI對接實踐）

無論是讓三方框架接入鴻蒙生態，還是讓 ArkUI 自身成為跨端開發框架，鴻蒙都在對外展示其極大的包容度。相信在不久的將來，OpenHarmony 會以開源開放的姿態，成為主流跨端開發框架的選型之一，同時也成為更多三方框架的堅實基座。

說些其他的話

性能、可控、體驗、動態——這是我凝練出的，本次 HDC 大會給軟件開發者傳達出的最重要的四個詞。

當然，除了開發語言、框架、套件和開發者工具，本次 HDC 大會的內容豐富程度遠超出這片文章所涵蓋的范疇。特別是大會開設的創新體驗專區，讓我在自己感興趣的領域也收獲不少。舉幾個例子：

* WebXR 和游戲。我們知道，雖然 OpenHarmony 在底層能力上為 APP 開發者提供了強有力的渲染能力加持，但帶給我驚喜的是，在華為瀏覽器里，同 Web 標準的對接也走得十分深入。我在現場體驗了鴻蒙結合 cocos 引擎制作的 WebXR 互動游戲，雖然沒有縱深效果，但是穩定性和性能還是不錯的。

* 音視頻智能制作，也就是 AIGC。從內部的 DEMO 應用來看，華為的音視頻智能制作主要還是圍繞多媒體模板以及配套的圖形圖像算法和模型來智能生成視頻和處理后的圖像。有一些調參的選項可供配置，但是更深層的聯動還在開發中，期待后續的正式版。

* AR。根據現場體驗，基于單攝像頭視覺算法的效果，跟 iOS 的 LiDAR 技術加持的掃描效果，雖然速度上有一定的差距，但是效果還好（可能跟場地場景有關），比較超預期。

當然，這場技術盛宴給我的收獲，除了對鴻蒙操作系統和其軟件體系的深入了解，還有松山湖景區——華為的歐洲小鎮帶給每一位到訪者的愜意——雖然立冬前幾天經常細雨蒙蒙，卻給人一種滋養萬物的感覺。

總結

如果用一個詞來總結這次的 HDC 的技術峰會，我會選擇：成熟。

2019年，鴻蒙初現；

2020年，面向智能硬件生態伙伴發布全新品牌鴻蒙智聯；

2021年，鴻蒙 2 推出，全面應用于智能手機等多種終端設備；

2022年，鴻蒙 3 如約而至。

一個 OS 的打造是要經歷時間的歷練，從 0 到 1 時，展現的是氣魄，而從 1 到 100，需要的是定力。

我十分期待明年 Q1，鴻蒙 3.1 的發布會如約展示其日臻成熟的一面；我更期待，明年 HDC 的大會上，OpenHarmony 能更加夯實其基礎能力，在不久的將來，成為移動 OS 的一枚堅實的鼎足，為移動應用提供一個出色的基座。