|
2019 年，華為 HarmonyOS 橫空出世，歷經4年千錘百煉，面向智能家居、智慧辦公、智慧出行、運動健康、影音娛樂 5 大場景，自研代碼量從 492 萬行增長到 2396 萬行，API 從 3493 個增長到 16000 個，幾乎同步實現了近 4 倍的增長。 HarmonyOS 自研代碼量和 API 增長數據 如果說代碼量衡量的是 HarmonyOS 自身研發實力，開發工具則意味著對開發者的賦能功力。 在日前舉行的 HDC 華為開發者大會 2022 上，HarmonyOS 的多項舉措，讓我們看到了華為的那股子“向上捅破天，向下扎到根”的精神，通過打造自研開發工具和“根技術”能力，描繪出了鴻蒙世界的藍圖。 開發者四大痛點 從 HDC 現場分享的數據里，可以看到，2019-2022 這四年里，HarmonyOS 已累計收集到 10 萬余條開發者問題反饋。這個數字顯示出開發者對 HarmonyOS 的期待與改進。 投我以桃，報之以李。我們欣喜地看到，HarmonyOS 也以極大的表現回報開發者的熱情。 首先，HarmonyOS 將這些千頭萬緒的問題分析歸類，最后歸結為效率、性能、成本、安全四個方面。
問題擺在這兒了，HarmonyOS 要如何解決呢？ 理念+實干，HarmonyOS 開發套件解憂開發者 HarmonyOS 的答案是理念牽引，實干支撐。 HarmonyOS 生態理念 理念只有區區 24 個字：“⼀次開發，多端部署”“可分可合，⾃由流轉”“統⼀⽣態，原⽣智能”，卻蘊藏著大內涵。 萬物互聯時代，設備終端數以百億計，每個終端都是一個節點，但開發者并沒有必要為每個終端單獨開發應用和服務。“⼀次開發，多端部署”就意味著通過一套工程、多端部署，同一特性、多端運行，一套界面、多端適配，就以意味著在最大程度地幫助開發者提升效率和獲得回報。 而如今的大型應用，其代碼量動輒上千萬行。把所有要修改的地方都開發完，再去測試和上架，周期之長，可想而知。于是，小步快跑、漸進迭代成為開發者的首選項。在鴻蒙看來，在開發態，“可分”即為應用按照優先級拆分為 HarmonyOS 原子化服務，每個服務都可以獨立開發和上架；“可合”讓 HarmonyOS 原子化服務按需組合成為 HarmonyOS 應用，而且每個原子化服務可以共享生命周期管理，這樣做對開發效率的提升有目共睹。同時，在運營態，可以做到跨端遷移、“自由流轉”，比如手機接聽的電話在上車以后可以無縫流轉到車機上，跑步時手機播放的音樂可以無縫流轉到智能手表上，這才是真正做到應用的自由流轉了。 HarmonyOS 統一了華為的硬件設備底座，同時還兼容 OpenHarmony 生態，做到統一建設一個大的鴻蒙生態。不僅如此，開發者也能選擇原生的開發框架或者第三方框架開發，與第三方生態共建共榮。同時，依托華為在智能方面的積淀，在芯片層，HarmonyOS 幫助應用提升性能、降低功耗；在應用能力開放層，HarmonyOS 將自然語言交互、計算視覺、情景感知等能力以 SDK 的方式開放出來，開箱即用；在服務能力開放層，幫助開發者精準觸達用戶，實現商業閉環。這一切，我們看到的是“統⼀⽣態，原⽣智能”。 在這三大理念的牽引下，HarmonyOS 對設計、開發、測試、分發 4 個階段的應用開發全生命周期，進行了徹頭徹尾的改進和提升，一口氣推出了包括設計工具、編程語言、編程框架、編譯器、IDE 等“鴻蒙開發套件”七件套大禮包，誠意滿滿。 華為終端 BG 軟件部總裁龔體發布鴻蒙開發套件
這其中，最能讓開發者眼前一亮的有三個字“聲明式”，對，就是那個開發者夢寐以求的開發模式。 聲明式開發：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 主要增強了這幾個方面的能力。
在這里，分享一個數字：相比傳統的 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 模型實現了碾壓，預計后續會逐漸成為鴻蒙的主流模式。 鴻蒙開發套件，還有非常多值得深挖的地方，受限于篇幅，我們這次對鴻蒙開發套件的初步觀察就先到這里。 鴻蒙開發套件總覽 最后，我們想說的是，做開發工具不容易，做覆蓋開發全生命周期的全鏈路開發工具更不容易。更進一步，能同時做操作系統和全鏈路開發工具的，放眼全球，更是屈指可數。 鴻蒙操作系統+開發工具雙輪驅動的鴻蒙生態的未來，值得期待。 |
