2019 年，華為 HarmonyOS 橫空出世，歷經(jīng)4年千錘百煉，面向智能家居、智慧辦公、智慧出行、運動健康、影音娛樂 5 大場景，自研代碼量從 492 萬行增長到 2396 萬行，API 從 3493 個增長到 16000 個，幾乎同步實現(xiàn)了近 4 倍的增長。

HarmonyOS 自研代碼量和 API 增長數(shù)據(jù)

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

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

開發(fā)者四大痛點

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

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

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

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

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

· 成本方面：?型應?多?程管理成本?；多設備應??程開發(fā)成本?……

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

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

理念+實干，HarmonyOS 開發(fā)套件解憂開發(fā)者

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

HarmonyOS 生態(tài)理念

理念只有區(qū)區(qū) 24 個字：“?次開發(fā)，多端部署”“可分可合，?由流轉”“統(tǒng)??態(tài)，原?智能”，卻蘊藏著大內涵。

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

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

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

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

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

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

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

· ArkCompiler：優(yōu)化編譯運行機制，縮短動態(tài)類型語言應用啟動時間；多種源碼保護技術，保障動態(tài)類型語言源碼安全；

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

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

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

聲明式開發(fā)：HarmonyOS 技術路線轉型之基

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

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

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

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

聲明式 UI 范式

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

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

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

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

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

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

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

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

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

· 動態(tài)組合：可以在運行時進行動態(tài)創(chuàng)建、組合內容，并且可以直接引用到另外的運行時中。

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

Stage：全新的規(guī)范化進程管理開發(fā)模型

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

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

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

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

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

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

Stage 模型

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

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

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

與傳統(tǒng)的編程開發(fā)模式相比，Stage 模型實現(xiàn)了碾壓，預計后續(xù)會逐漸成為鴻蒙的主流模式。

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

鴻蒙開發(fā)套件總覽

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

鴻蒙操作系統(tǒng)+開發(fā)工具雙輪驅動的鴻蒙生態(tài)的未來，值得期待。

生成海報

免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產(chǎn)權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。