HarmonyOS 自研代碼量和 API 增長數據

如果說代碼量衡量的是 HarmonyOS 自身研發實力，開發工具則意味著對開發者的賦能功力。

在日前舉行的 HDC 華為開發者大會 2022 上，HarmonyOS 的多項舉措，讓我們看到了華為的那股子“向上捅破天，向下扎到根”的精神，通過打造自研開發工具和“根技術”能力，描繪出了鴻蒙世界的藍圖。

開發者四大痛點

從 HDC 現場分享的數據里，可以看到，2019-2022 這四年里，HarmonyOS 已累計收集到 10 萬余條開發者問題反饋。這個數字顯示出開發者對 HarmonyOS 的期待與改進。

投我以桃，報之以李。我們欣喜地看到，HarmonyOS 也以極大的表現回報開發者的熱情。

首先，HarmonyOS 將這些千頭萬緒的問題分析歸類，最后歸結為效率、性能、成本、安全四個方面。

• 效率方面：跨端應?開發代碼能否進?步簡化；跨端應?調試能否更?便……

• 性能方面：JS/TS 應?性能容易受硬件資源限制；進程?拉起持續存在，容易引發應?卡頓……

• 成本方面：?型應?多?程管理成本?；多設備應??程開發成本?……

• 安全方面：JS/TS 源碼容易被反編譯，安全度低……

問題擺在這兒了，HarmonyOS 要如何解決呢？

理念+實干，HarmonyOS 開發套件解憂開發者

HarmonyOS 的答案是理念牽引，實干支撐。

HarmonyOS 生態理念

理念只有區區 24 個字：“?次開發，多端部署”“可分可合，?由流轉”“統??態，原?智能”，卻蘊藏著大內涵。

萬物互聯時代，設備終端數以百億計，每個終端都是一個節點，但開發者并沒有必要為每個終端單獨開發應用和服務。“?次開發，多端部署”就意味著通過一套工程、多端部署，同一特性、多端運行，一套界面、多端適配，就以意味著在最大程度地幫助開發者提升效率和獲得回報。

而如今的大型應用，其代碼量動輒上千萬行。把所有要修改的地方都開發完，再去測試和上架，周期之長，可想而知。于是，小步快跑、漸進迭代成為開發者的首選項。在鴻蒙看來，在開發態，“可分”即為應用按照優先級拆分為 HarmonyOS 原子化服務，每個服務都可以獨立開發和上架；“可合”讓 HarmonyOS 原子化服務按需組合成為 HarmonyOS 應用，而且每個原子化服務可以共享生命周期管理，這樣做對開發效率的提升有目共睹。同時，在運營態，可以做到跨端遷移、“自由流轉”，比如手機接聽的電話在上車以后可以無縫流轉到車機上，跑步時手機播放的音樂可以無縫流轉到智能手表上，這才是真正做到應用的自由流轉了。

HarmonyOS 統一了華為的硬件設備底座，同時還兼容 OpenHarmony 生態，做到統一建設一個大的鴻蒙生態。不僅如此，開發者也能選擇原生的開發框架或者第三方框架開發，與第三方生態共建共榮。同時，依托華為在智能方面的積淀，在芯片層，HarmonyOS 幫助應用提升性能、降低功耗；在應用能力開放層，HarmonyOS 將自然語言交互、計算視覺、情景感知等能力以 SDK 的方式開放出來，開箱即用；在服務能力開放層，幫助開發者精準觸達用戶，實現商業閉環。這一切，我們看到的是“統??態，原?智能”。

在這三大理念的牽引下，HarmonyOS 對設計、開發、測試、分發 4 個階段的應用開發全生命周期，進行了徹頭徹尾的改進和提升，一口氣推出了包括設計工具、編程語言、編程框架、編譯器、IDE 等“鴻蒙開發套件”七件套大禮包，誠意滿滿。

華為終端 BG 軟件部總裁龔體發布鴻蒙開發套件

• HarmonyOS Design：為 HarmonyOS 應用開發提供一致的體驗設計規范及高效設計工具；設計資源免費開放，支持開發者快速調用；

• ArkTS：全新聲明式開發語言，兼容 JS/TS 語言生態、擴展了聲明式 UI 語法和輕量化并發機制，簡潔高效，進一步降低跨端應用開發代碼量，開發效率提升 30%；

• ArkCompiler：優化編譯運行機制，縮短動態類型語言應用啟動時間；多種源碼保護技術，保障動態類型語言源碼安全；

• ArkUI：升級渲染機制，簡化界面渲染算法；創新 Stage 開發模型，避免了后臺進程無序侵占系統資源；邏輯和 UI 分離技術，提升流轉開發效率；

• 開發（DevEco Studio）、測試（DevEco Testing）及應用上架（AppGallery Connect）工具：配套聲明式開發體系全面升級，實現高效開發、快速測試、一鍵上架分發。

這其中，最能讓開發者眼前一亮的有三個字“聲明式”，對，就是那個開發者夢寐以求的開發模式。

聲明式開發：HarmonyOS 技術路線轉型之基

HarmonyOS 從“命令式開發”全面轉型“聲明式開發”，意料之中。

對于“命令式”“聲明式”，開發者們并不陌生。

所謂“命令式”，顧名思義，程序按部就班地聽從“命令”去執行，沒有自己的思想，不智能，只會遵循開發的規范，被動去執行。執行得好壞、效率高不高，與開發者本身的技術能力關聯度很大，要寫出讓機器如何去做事情（how to do）的代碼，也就是說基本取決于開發者的代碼“水平”。現在大部分程序開發都是走的這條路。

而“聲明式”則大有不同，是對開發模式的一次變革——比 GitHub 的 Cloplite 輔助工具通過函數注釋生成代碼的方式更進一步，只要“聲明”我想要什么樣的結果（what to do），程序就調用相關的 API，自主設計執行路徑，以達到預期的結果。可以看出，“聲明式”讓程序具備一定的智能，開發起來能有效降低門檻，提升效率。

聲明式 UI 范式

可以看出，“聲明式”開發更接近人類語言，具備更高的可讀性、易學習性，并且代碼簡潔可重用、編碼高效好測試。

舉例來說，要炒一道菜，“命令式”要一步步地指揮洗菜、切菜、放油、下鍋、加料、翻炒、盛盤；而“聲明式”要表達的是想炒一道菜，程序便自動調用相關的 API，尋找這道菜的最佳工藝并執行。

隨著 AI 驅動的自動化編程技術的發展，“聲明式”從理想成為現實，并且正在成為趨勢。

正是看到了這樣的趨勢，結合自身的積累，HarmonyOS 向“聲明式”開發，正式開拔。

要進行“聲明式”開發，根在編程語言。在最關鍵的編程語言轉型為“聲明式”后，與之配套的應用開發全生命周期的工具，自然要同步轉型，遵循同樣的語法規則，方能形成合力。

此次發布的聲明式開發語言 ArkTS 是 HarmonyOS 的主力應用開發語言，它基于 TypeScript 語言體系擴展了聲明式 UI 語法和輕量化并發機制，增加了一些語法糖的能力，讓跨端界面開發和并行化任務開發，高效簡潔，使應用開發效率提升 30%。目前，基于 ArkTS 語言的 API 已達 10000+，基本能滿足當前應用開發場景的使用需求。

事實上，ArkTS 語言并非一門全新的語言，而是作為 TypeScript 語言的增強型語言，因此兼容 JS 語言和 TS 語言的生態。總體來說，ArkTS 主要增強了這幾個方面的能力。

• 實現了簡潔自然的描述機制：ArkTS 做了一些自定義能力的增強，比如可以自定義組件，實現了組件化機制。自定義組件，可以被別的自定義組件所引用，形成新的更高級的組合型組件，這樣我們就可以把業務應用中使用頻次高的復雜的幾個組件，直接定義成一個組件去重復利用，這對開發效率的提升顯而易見。

• 響應式多維狀態管理：通過定義一個狀態，實現在組件級、頁面級甚至全局的狀態觸發。這就方便了在應用編程時，根據需要再進行觸發，因為 ArkTS 提供的是響應式 UI（聲明式 UI 本質上也是響應式 UI），而響應式 UI 的界面刷新是根據狀態來進行觸發的。這種模式有利于進行狀態管理和定制。

• 動態組合：可以在運行時進行動態創建、組合內容，并且可以直接引用到另外的運行時中。

在這里，分享一個數字：相比傳統的 HTML+CSS+JS 的類 Web 范式，同樣的任務，ArkTS 代碼量有超過 50% 的減少。

Stage：全新的規范化進程管理開發模型

在聲明式之外，還有一點吸引到我了——Stage 開發模型，可謂是 ArkUI 中的一大創新。

ArkUI 的本意實現“一次開發，多端部署”，提升開發效率和設備性能。具體的實現方式有三。

一是跨設備界面開發能力，這是鴻蒙一直在持續構建的能力，不再贅述。

二是升級了整體渲染框架。傳統的渲染，由三棵樹來完成，經過反復的嘗試后，鴻蒙實現了一棵樹來完成，同時把多節點組合模型變成了單節點+屬性組合模型。這些架構的調整，對應用開發者來說，是不可見、透明的。這頓操作之后，ArkUI 提升了界面加載性能——渲染速度提升 20%，渲染內存降低 30%，渲染指令降低 20%。

三就是 Stage 這個“新生兒”。

之所以推出 Stage 模型，是因為在上一代移動操作系統中，大多數的設備后臺管理比較混亂。Stage 模型提供了系統對進程數量配置、后臺服務定義、后臺服務拉起等的統一納管，從而使應用能夠更好地組織在一起。目前，Stage 模型支持兩種模式，一種是 JS 語言層的實體類 UIAbility，另一種是鴻蒙提供的一組系統類 Extention Ability。應用如果希望調用系統提供類似服務的話，不再需要自己寫一個 Service，而是自己繼承派生出一個基于 Extention 類的自有類，通過這種方式拉起相關的服務。

Stage 模型

這樣管理起來之后，后臺的常駐程序可大幅減少，從使系統資源更加有序。

同時，Stage 模型實現了將邏輯與UI解耦。意思是，使用 Stage 模型時，可以讓邏輯段代碼和 UI 段代碼在分離的物理設備上運行，這無疑強化了鴻蒙程序流轉的能力。

多設備應用模型歸一、Stage 內置的框架可以實現秒級的自動恢復，則進一步強化了 Stage 模型在進程管理方面的優勢。

與傳統的編程開發模式相比，Stage 模型實現了碾壓，預計后續會逐漸成為鴻蒙的主流模式。

鴻蒙開發套件，還有非常多值得深挖的地方，受限于篇幅，我們這次對鴻蒙開發套件的初步觀察就先到這里。

鴻蒙開發套件總覽

最后，我們想說的是，做開發工具不容易，做覆蓋開發全生命周期的全鏈路開發工具更不容易。更進一步，能同時做操作系統和全鏈路開發工具的，放眼全球，更是屈指可數。

鴻蒙操作系統+開發工具雙輪驅動的鴻蒙生態的未來，值得期待。