11 月 4 日，松山湖畔，第四屆華為開(kāi)發(fā)者大會(huì)召開(kāi)。

作為開(kāi)發(fā)者，自然最關(guān)注的是大會(huì)中關(guān)于開(kāi)發(fā)框架/套件以及開(kāi)發(fā)者工具的部分，畢竟這是和開(kāi)發(fā)者直接打交道的領(lǐng)域。無(wú)論是大會(huì)上著重強(qiáng)調(diào)的原子化卡片、分布式服務(wù)、超級(jí)中轉(zhuǎn)站等功能，其底層都是基于 HarmonyOS 3 新的技術(shù)體系架構(gòu)。

在 11 月 5 日上午開(kāi)發(fā)者主題演講里，華為技術(shù)專(zhuān)家用三句話定義了這一代的鴻蒙操作系統(tǒng)：

一次開(kāi)發(fā)，多端部署；

可分可合，自由流轉(zhuǎn)；

統(tǒng)一生態(tài)，原生智能。

愿景很美好，但是要達(dá)成這樣的技術(shù)全景，需要的技術(shù)板塊非常多，不由讓人懷疑完成度究竟如何。其實(shí)道理很簡(jiǎn)單，因?yàn)橐坏┥婕暗姐暯娱_(kāi)發(fā)者，衍生出來(lái)的問(wèn)題就會(huì)像石頭扔進(jìn)平靜的水潭里一般——設(shè)計(jì)系統(tǒng)、運(yùn)行時(shí)管理、UI框架、編程范式、調(diào)試、調(diào)優(yōu)、測(cè)試、日志、上架、分發(fā)……特別是還要面對(duì)當(dāng)前這些已經(jīng)被其他成熟平臺(tái)把開(kāi)發(fā)體驗(yàn)喂養(yǎng)得極其挑剔的開(kāi)發(fā)者，鴻蒙真的做好準(zhǔn)備了么？

順著這個(gè)思路，我嘗試在主題演講和開(kāi)發(fā)者論壇里尋找答案。

好在我的答題本上不是空空如也，近一段時(shí)間里，百度正在使用鴻蒙的新 UI 框架 ArkUI 以及 Stage 應(yīng)用模型制作了 OpenHarmony 版本的百度 APP。除此之外，我還在動(dòng)態(tài)化跨端開(kāi)發(fā)方面嘗試推進(jìn)和 ArkUI 對(duì)接，并取得了初步的成果。

先來(lái)看一下 HarmonyOS 的技術(shù)棧，由下至上分為三層，依次是：

* 由 HarmonyOS Design、ArkTS、ArkUI、ArkCompiler 為基礎(chǔ)的開(kāi)發(fā)基礎(chǔ)框架/套件層；

* 由 DevEco Studio 和 DevEco Testing 組成的開(kāi)發(fā)者工具層；

* 由 AppGallery Connect（AGC）支撐應(yīng)用上架、分發(fā)和運(yùn)營(yíng)層。

展開(kāi)來(lái)講的話，篇幅會(huì)很長(zhǎng)，本文會(huì)抓住其中最重要的部分進(jìn)行分析，這里我給出四個(gè)關(guān)鍵詞：**性能**、**可控**、**體驗(yàn)**、**動(dòng)態(tài)**。

注：本文提到的內(nèi)容大部分面向明年 Q1 鴻蒙將要退出的 3.1 版本的操作系統(tǒng)。

且聽(tīng)我一一道來(lái)。

性能

性能依賴(lài)輕量級(jí)的運(yùn)行時(shí)環(huán)境，鴻蒙 3.1 版本的革新有很多。這里講解其中最重要的 3 點(diǎn)：

* ArkUI 渲染樹(shù)歸一

* Stage 應(yīng)用模型帶來(lái)的資源優(yōu)化

* Runtime 輕量化并發(fā)

我們知道，一般渲染框架的后臺(tái)架構(gòu)由三棵樹(shù)支撐（以 flutter 為例，Widget Tree、Element Tree、Render Tree），它們各司其職。有的是為了銜接組件系統(tǒng)，有的是為了在內(nèi)存中維護(hù)真正的結(jié)構(gòu)信息（承擔(dān) Virtual DOM 的責(zé)任），有的為了橋接底層渲染引擎。

ArkUI 在此基礎(chǔ)上進(jìn)行了融合升級(jí)，把多節(jié)點(diǎn)組合模型升級(jí)為“單節(jié)點(diǎn)+屬性”的組合模型，將數(shù)據(jù)依賴(lài)組件級(jí)更新升級(jí)為細(xì)粒度函數(shù)級(jí)更新，從而從而實(shí)現(xiàn)三棵渲染樹(shù)的歸一，提升了組件構(gòu)建速度，降低了內(nèi)存占用。

（上圖來(lái)源于大會(huì)主題演講）

按照鴻蒙官方給出的數(shù)據(jù)，這次技術(shù)升級(jí)帶來(lái)的性能收益包括：渲染速度提升 20%、渲染內(nèi)存降低 30%、渲染指令數(shù)降低 20%。

除了渲染樹(shù)優(yōu)化，鴻蒙應(yīng)用模型進(jìn)行了徹底的迭代，從 API 7 支持的 FA 應(yīng)用模型切換為 API 9 的 Stage 應(yīng)用模型，F(xiàn)A 模型在未來(lái)會(huì)淡出歷史舞臺(tái)。Stage 模型相關(guān)的知識(shí)點(diǎn)有很多，在性能這一 Part，我們著重了解下它帶來(lái)的最為重大的變化——同一個(gè)虛擬機(jī)中可以容納更多個(gè)組件。這使得開(kāi)發(fā)者更為方便地共享狀態(tài)的同時(shí)，還能大幅降低內(nèi)存的占用率：

（上圖來(lái)源于分論壇——鴻蒙開(kāi)發(fā)套件（語(yǔ)言與框架）——利用Stage應(yīng)用模型快速構(gòu)建HarmonyOS應(yīng)用）

除了應(yīng)用模型的更新，在 ArkCompiler 運(yùn)行時(shí)層面，鴻蒙打造了 Lite Actor 輕量化并發(fā)模型。鴻蒙除了輕量化基礎(chǔ)架構(gòu)，還支持了對(duì)象共享機(jī)制（目前支持不可變對(duì)象的共享，未來(lái)還會(huì)支持可變對(duì)象的部分共享）：

（上圖來(lái)源于分論壇——DevEco開(kāi)發(fā)工具新特性——深入淺出ArkCompiler）

在支持傳統(tǒng)的基于 Worker 的多線程之余，鴻蒙還支持新的 Task Pool API。從代碼體驗(yàn)上來(lái)說(shuō)，相比 Worker，Task Pool 的使用更加直觀清晰，開(kāi)發(fā)者無(wú)需關(guān)心并發(fā)實(shí)例的生命周期，業(yè)務(wù)無(wú)需關(guān)心場(chǎng)景下并發(fā)負(fù)載問(wèn)題，因?yàn)樨?fù)載管理在運(yùn)行時(shí)由 OS 層面統(tǒng)一協(xié)同處理，管控線程數(shù)和線程資源開(kāi)銷(xiāo)。

當(dāng)然，除了以上三點(diǎn)之外，ArkUI 的 AOT 編譯管線、XComponent 接入底層的高性能渲染方案以及各種性能調(diào)優(yōu)后的高階組件庫(kù)……都大幅提升了 3.1 版本的鴻蒙的運(yùn)行性能。

可控

先來(lái)問(wèn)大家一句：開(kāi)發(fā)的時(shí)候你最怕什么？

我自己的答案是：不可控。無(wú)法收斂的 bug，時(shí)不時(shí)會(huì)冒出的所謂的“底層”問(wèn)題，以及黑盒的構(gòu)建、編譯、渲染 pipeline……這些都是程序員頭發(fā)的終極殺手。

畢竟大家都習(xí)慣把命運(yùn)掌握在自己手里，新版本的鴻蒙自然也想到了這點(diǎn)，我認(rèn)為主要體現(xiàn)在 3 個(gè)方面：

* 基于 ArkTS 的聲明式開(kāi)發(fā)范式

* Stage 模型對(duì)鴻蒙應(yīng)用運(yùn)行規(guī)則的重構(gòu)

* Hvigor 對(duì)構(gòu)建任務(wù)流的自由擴(kuò)展

你可能會(huì)想：ArkTS 的聲明式開(kāi)發(fā)范式和可控性有什么關(guān)系？畢竟 JS/CSS/Template 的單文件合一在別的框架的 SFC 模式里早就實(shí)踐過(guò)，而且聲明式的開(kāi)發(fā)模式已經(jīng)不是什么新鮮的事情。但深入來(lái)看， ArkTS 在可控性和標(biāo)準(zhǔn)化這里做得更加“極致”了些。

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

再來(lái)說(shuō)下 Stage 模型。前文提到 Stage 模型時(shí)主要說(shuō)了它對(duì)于虛擬機(jī)管控和組件資源占用和內(nèi)存共享的優(yōu)化，這里主要想強(qiáng)調(diào)的是，與 FA 模型（以及 AOSP 生態(tài)為代表的復(fù)雜的應(yīng)用模型）不同，Stage 模型簡(jiǎn)化了鴻蒙應(yīng)用的運(yùn)行規(guī)則。

在 Stage 模型里，Ability 被分位 UI Ability 和 Extension Ability，前者是一個(gè) UI 容器，每一個(gè)對(duì)應(yīng)一個(gè)獨(dú)立的任務(wù)（MIssion），在主進(jìn)程中運(yùn)行；而后者是一個(gè)模板服務(wù)（使用是需要使用 Extension Ability 的派生類(lèi)），銜接系統(tǒng)服務(wù)，場(chǎng)景化地支持特定服務(wù)，雖然在單獨(dú)的進(jìn)程中運(yùn)行，但是和主進(jìn)程有一樣的 uid，共享數(shù)據(jù)目錄。

（上圖來(lái)源于分論壇——鴻蒙開(kāi)發(fā)套件（語(yǔ)言與框架）——利用Stage應(yīng)用模型快速構(gòu)建HarmonyOS應(yīng)用）

Stage 模型體現(xiàn)了鴻蒙“節(jié)制”的設(shè)計(jì)思想，不支持開(kāi)發(fā)者配置多進(jìn)程，不支持開(kāi)發(fā)者自定義服務(wù)，不支持應(yīng)用直接拉起自己的場(chǎng)景服務(wù)；只支持應(yīng)用間 UI 展示界面的相互調(diào)起以及通過(guò)系統(tǒng)服務(wù)調(diào)起場(chǎng)景服務(wù)。

最后聊一下 Hvigor 對(duì)構(gòu)建任務(wù)流的自由擴(kuò)展（Hvigor 是 DevEco 集成的官方構(gòu)建打包工具）。說(shuō)實(shí)話，在來(lái)參加 HDC 之前，我對(duì) Hvigor 構(gòu)建工具的認(rèn)知還處于黑盒狀態(tài)，只是從之前的技術(shù)交流中知道它使用了主流的 Web 向的前端構(gòu)建方案（Webpack），當(dāng)然因?yàn)槠?TS 超級(jí)的語(yǔ)言特性，也包括了相關(guān)的語(yǔ)言編譯方面的 Configuration。但是在聽(tīng)了華為工程師的分享后，我了解到，在 Hvigor 的構(gòu)建 pipeline 中，工具會(huì)為開(kāi)發(fā)者預(yù)留了很多 Task 插槽，可以插入到你想要介入的編譯構(gòu)建環(huán)節(jié)：

（上圖來(lái)源于分論壇——DevEco開(kāi)發(fā)工具新特性——DevEco Hvigor 工具助力靈活高效構(gòu)建打包）

比如構(gòu)建前的集成環(huán)境檢測(cè)、構(gòu)建過(guò)程中插樁修改特定代碼和資源以及構(gòu)建打包的后置任務(wù)。開(kāi)發(fā)者可以復(fù)用 Hvigor 的調(diào)度能力，提升任務(wù)的執(zhí)行效率。

對(duì)開(kāi)發(fā)范式、應(yīng)用模型和構(gòu)建打包的精心設(shè)計(jì)，讓開(kāi)發(fā)者享受到“我命由我不由天”，除此之外，在開(kāi)發(fā)調(diào)試、調(diào)優(yōu)和測(cè)試環(huán)節(jié)，鴻蒙的開(kāi)發(fā)者工具也做了大量的工作，這里且不一一贅述。

體驗(yàn)

用戶(hù)體驗(yàn)永遠(yuǎn)是繞不開(kāi)的話題，HarmonyOS 給自己的定位是“面向萬(wàn)物互聯(lián)時(shí)代的全場(chǎng)景分布式操作系統(tǒng)”。對(duì)于一個(gè)分布式系統(tǒng)，最有挑戰(zhàn)也最需要解決的就是體驗(yàn)一致性問(wèn)題。在本次 HDC 開(kāi)發(fā)者大會(huì)里，對(duì)于這個(gè)問(wèn)題，鴻蒙從設(shè)計(jì)和技術(shù)兩個(gè)維度給出了解決方案：

* 設(shè)計(jì)上，深入實(shí)踐響應(yīng)式布局的設(shè)計(jì)方案

* 技術(shù)上，做到一次開(kāi)發(fā)多端部署

用戶(hù)體驗(yàn)在 UI 層面的基礎(chǔ)是設(shè)計(jì)系統(tǒng)。從十幾年前我剛開(kāi)始接觸前端開(kāi)發(fā)，柵格化就植入了我的大腦，今天看鴻蒙的新設(shè)計(jì)語(yǔ)言，基礎(chǔ)依然如是。之前的 HDC 大會(huì)上，設(shè)計(jì)方向就提出了“屏幕斷點(diǎn)”的概念，針對(duì)不同設(shè)備和不同尺寸的屏幕進(jìn)行差異化的布局和顯示，這次迭代，鴻蒙基于柵格系統(tǒng)又強(qiáng)化了這一概念。

柵格系統(tǒng)由 Margin（邊界大小，決定了整體寬度）、Gutter（內(nèi)容 Column 間距）和 Column（內(nèi)容占位元素）三個(gè)屬性構(gòu)成，是響應(yīng)式布局的基礎(chǔ)。

（上圖來(lái)源于分論壇——鴻蒙開(kāi)發(fā)套件（語(yǔ)言與框架）——HarmonyOS動(dòng)態(tài)響應(yīng)式布局介紹）

通過(guò)斷點(diǎn)、Media Query 和柵格化，響應(yīng)式布局可以實(shí)現(xiàn)界面隨外部容器大小有級(jí)不連續(xù)變化。而在系統(tǒng)默認(rèn)推薦的超小、小、中、大四個(gè)屏幕斷點(diǎn)的基礎(chǔ)上重構(gòu)柵格系統(tǒng)，使得局部容器的變化方式可以相互獨(dú)立，共同打造 Harmony（和諧）的交互體驗(yàn)。

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

做過(guò)移動(dòng)端開(kāi)發(fā)的同學(xué)都知道，端能力的紛雜堪比當(dāng)年對(duì) IE 6/7/8 以及各種移動(dòng)版本 Webview 的支持，而因?yàn)槎四芰Φ倪m配問(wèn)題引入的 bug 以及不良開(kāi)發(fā)體驗(yàn)給很多程序員都帶來(lái)了不好的體驗(yàn)。對(duì)于語(yǔ)言層面，可以針對(duì) JS 引擎不同版本進(jìn)行統(tǒng)一的 polyfill 管控，而對(duì)于系統(tǒng)的端能力，如何分而治之，則需要投入更大的精力。這不光影響功能是否正常運(yùn)行，對(duì)于 OpenHarmony 這種分布式的 OS，由于需要支持更重 IoT 設(shè)備，端能力的管控顯得更加重要。

為此，鴻蒙引入了一種叫做 syscap（System Capability）的機(jī)制來(lái)解決端能力的管控問(wèn)題，把系統(tǒng)能力分為支持能力集、要求能力集和聯(lián)想能力集。

（上圖來(lái)源于分論壇——鴻蒙開(kāi)發(fā)套件（語(yǔ)言與框架）——一次開(kāi)發(fā)，多端部署）

支持能力集是針對(duì)設(shè)備的，不同設(shè)備的能力集合不一樣；要求能力集，顧名思義，是針對(duì)應(yīng)用在不同設(shè)備上需求的交集，因?yàn)楸仨毺峁┻@些能力應(yīng)用才可用；聯(lián)想能力集則針對(duì)開(kāi)發(fā)場(chǎng)景，是在 IDE 中針對(duì)能力進(jìn)行的聯(lián)想 API 集合。

你可能會(huì)問(wèn)，既然設(shè)備之間的能力不一樣，那么在使用能力的時(shí)候，如何判斷哪些能力可用，哪些能力不可用？答案是：`CanIUse`。對(duì)，就是大家在 Web 開(kāi)發(fā)中經(jīng)常做兼容性查詢(xún)的那個(gè) CanIUse 網(wǎng)站同名的查詢(xún)接口，開(kāi)發(fā)者可以通過(guò)這個(gè)方法來(lái)判斷設(shè)備是否支持某個(gè)系統(tǒng)能力。

能力的支持程度決定了分發(fā)結(jié)果，而開(kāi)發(fā)者也可以在配置文件中對(duì)聯(lián)想能力和要求能力進(jìn)行配置。

配置，這兩個(gè)字很關(guān)鍵。

鴻蒙力求使用最少的代碼，依賴(lài)聲明式的 UI 編程和豐富的組件庫(kù)，依賴(lài)項(xiàng)目豐富的配置文件，落地“一多開(kāi)發(fā)”模式，為開(kāi)發(fā)者提供良好的編程體驗(yàn)，為用戶(hù)提供優(yōu)秀的跨設(shè)備使用體驗(yàn)。

動(dòng)態(tài)

**城外的人想進(jìn)去，城里的人想出來(lái)。**

動(dòng)態(tài)化也一樣。一方面是 ArkUI 能夠做到跨平臺(tái)，另一方面是其他跨平臺(tái)框架能夠橋接到 ArkUI。

對(duì)于 ArkUI 來(lái)說(shuō)，除了作為 HarmonyOS 原生的應(yīng)用框架，以及原子化服務(wù)的基礎(chǔ)運(yùn)行環(huán)境，它的目標(biāo)還有一個(gè)，就是作為三方應(yīng)用的通用跨平臺(tái)框架：

（上圖來(lái)源于分論壇——鴻蒙開(kāi)發(fā)套件（語(yǔ)言與框架）——如何利用ArkUI開(kāi)發(fā)跨平臺(tái)的應(yīng)用程序）

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

從美的技術(shù)專(zhuān)家的分享中，能夠看到，在“把 ArkUI 變成通用跨平臺(tái)的框架”這條路上，鴻蒙團(tuán)隊(duì)和第三方開(kāi)發(fā)者已經(jīng)做了很多工作。比如 MiniX，這是基于 OpenHarmony ArkUI 二次開(kāi)發(fā)的適配美的 IoT 場(chǎng)景的跨端應(yīng)用開(kāi)發(fā)框架，已經(jīng)對(duì)組件和 API 進(jìn)行了分級(jí)適配，并且還開(kāi)發(fā)了配套的定制化的 VSCode 插件。

（上圖來(lái)源于分論壇——鴻蒙開(kāi)發(fā)套件（語(yǔ)言與框架）——ArkUI跨平臺(tái)能力節(jié)約開(kāi)發(fā)成本實(shí)踐）

對(duì)于三方框架向 ArkUI 橋接這一個(gè)路徑，鴻蒙同京東進(jìn)行了深入的合作。京東輕量級(jí)的跨端渲染框架 MCube 將內(nèi)容通過(guò)動(dòng)態(tài)化模板的方式下發(fā)到端側(cè)，經(jīng)過(guò) DSL 解析來(lái)實(shí)現(xiàn)局部數(shù)據(jù)更新。與此同時(shí)，可以借助 ArkUI 的統(tǒng)一渲染能力，減少渲染節(jié)點(diǎn)，實(shí)現(xiàn)性能和功耗的優(yōu)化。

（上圖來(lái)源于分論壇——鴻蒙開(kāi)發(fā)套件（語(yǔ)言與框架）——HarmonyOS開(kāi)發(fā)語(yǔ)言與框架新進(jìn)展）

對(duì)于三方框架如何同 ArkUI 聲明式開(kāi)發(fā)范式進(jìn)行橋接，我也給出了自己的看法，即“混合跨端開(kāi)發(fā)方式”。百度的動(dòng)態(tài)化開(kāi)發(fā)框架 Talos 以及其包含的輕量級(jí)動(dòng)態(tài)化方案 Talos Lite，未來(lái)會(huì)和 OpenHarmony 技術(shù)棧進(jìn)行深入的整合。

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

因此我認(rèn)為，基于“體驗(yàn)一致性”、“性能”、“復(fù)雜度”和“標(biāo)準(zhǔn)化對(duì)齊”的決策模型，能夠指導(dǎo)開(kāi)發(fā)者進(jìn)行正確的技術(shù)選型：

（上圖來(lái)源于分論壇——鴻蒙開(kāi)發(fā)套件（語(yǔ)言與框架）——Talos應(yīng)用框架與ArkUI對(duì)接實(shí)踐）

無(wú)論是讓三方框架接入鴻蒙生態(tài)，還是讓 ArkUI 自身成為跨端開(kāi)發(fā)框架，鴻蒙都在對(duì)外展示其極大的包容度。相信在不久的將來(lái)，OpenHarmony 會(huì)以開(kāi)源開(kāi)放的姿態(tài)，成為主流跨端開(kāi)發(fā)框架的選型之一，同時(shí)也成為更多三方框架的堅(jiān)實(shí)基座。

說(shuō)些其他的話

性能、可控、體驗(yàn)、動(dòng)態(tài)——這是我凝練出的，本次 HDC 大會(huì)給軟件開(kāi)發(fā)者傳達(dá)出的最重要的四個(gè)詞。

當(dāng)然，除了開(kāi)發(fā)語(yǔ)言、框架、套件和開(kāi)發(fā)者工具，本次 HDC 大會(huì)的內(nèi)容豐富程度遠(yuǎn)超出這片文章所涵蓋的范疇。特別是大會(huì)開(kāi)設(shè)的創(chuàng)新體驗(yàn)專(zhuān)區(qū)，讓我在自己感興趣的領(lǐng)域也收獲不少。舉幾個(gè)例子：

* WebXR 和游戲。我們知道，雖然 OpenHarmony 在底層能力上為 APP 開(kāi)發(fā)者提供了強(qiáng)有力的渲染能力加持，但帶給我驚喜的是，在華為瀏覽器里，同 Web 標(biāo)準(zhǔn)的對(duì)接也走得十分深入。我在現(xiàn)場(chǎng)體驗(yàn)了鴻蒙結(jié)合 cocos 引擎制作的 WebXR 互動(dòng)游戲，雖然沒(méi)有縱深效果，但是穩(wěn)定性和性能還是不錯(cuò)的。

* 音視頻智能制作，也就是 AIGC。從內(nèi)部的 DEMO 應(yīng)用來(lái)看，華為的音視頻智能制作主要還是圍繞多媒體模板以及配套的圖形圖像算法和模型來(lái)智能生成視頻和處理后的圖像。有一些調(diào)參的選項(xiàng)可供配置，但是更深層的聯(lián)動(dòng)還在開(kāi)發(fā)中，期待后續(xù)的正式版。

* AR。根據(jù)現(xiàn)場(chǎng)體驗(yàn)，基于單攝像頭視覺(jué)算法的效果，跟 iOS 的 LiDAR 技術(shù)加持的掃描效果，雖然速度上有一定的差距，但是效果還好（可能跟場(chǎng)地場(chǎng)景有關(guān)），比較超預(yù)期。

當(dāng)然，這場(chǎng)技術(shù)盛宴給我的收獲，除了對(duì)鴻蒙操作系統(tǒng)和其軟件體系的深入了解，還有松山湖景區(qū)——華為的歐洲小鎮(zhèn)帶給每一位到訪者的愜意——雖然立冬前幾天經(jīng)常細(xì)雨蒙蒙，卻給人一種滋養(yǎng)萬(wàn)物的感覺(jué)。

總結(jié)

如果用一個(gè)詞來(lái)總結(jié)這次的 HDC 的技術(shù)峰會(huì)，我會(huì)選擇：成熟。

2019年，鴻蒙初現(xiàn)；

2020年，面向智能硬件生態(tài)伙伴發(fā)布全新品牌鴻蒙智聯(lián)；

2021年，鴻蒙 2 推出，全面應(yīng)用于智能手機(jī)等多種終端設(shè)備；

2022年，鴻蒙 3 如約而至。

一個(gè) OS 的打造是要經(jīng)歷時(shí)間的歷練，從 0 到 1 時(shí)，展現(xiàn)的是氣魄，而從 1 到 100，需要的是定力。

我十分期待明年 Q1，鴻蒙 3.1 的發(fā)布會(huì)如約展示其日臻成熟的一面；我更期待，明年 HDC 的大會(huì)上，OpenHarmony 能更加夯實(shí)其基礎(chǔ)能力，在不久的將來(lái)，成為移動(dòng) OS 的一枚堅(jiān)實(shí)的鼎足，為移動(dòng)應(yīng)用提供一個(gè)出色的基座。