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 模型實現了碾壓，預計後續會逐漸成為鴻蒙的主流模式。
鴻蒙開發套件，還有非常多值得深挖的地方，受限于篇幅，我們這次對鴻蒙開發套件的初步觀察就先到這裡。
鴻蒙開發套件總覽
最後，我們想說的是，做開發工具不容易，做覆蓋開發全生命周期的全鍊路開發工具更不容易。更進一步，能同時做操作系統和全鍊路開發工具的，放眼全球，更是屈指可數。
鴻蒙操作系統 開發工具雙輪驅動的鴻蒙生态的未來，值得期待。
,更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
