|
2019 年，華為 HarmonyOS 橫空出世，歷經(jīng)4年千錘百煉，面向智能家居、智慧辦公、智慧出行、運動(dòng)健康、影音娛樂(lè ) 5 大場(chǎng)景，自研代碼量從 492 萬(wàn)行增長(cháng)到 2396 萬(wàn)行，API 從 3493 個(gè)增長(cháng)到 16000 個(gè)，幾乎同步實(shí)現了近 4 倍的增長(cháng)。 HarmonyOS 自研代碼量和 API 增長(cháng)數據 如果說(shuō)代碼量衡量的是 HarmonyOS 自身研發(fā)實(shí)力，開(kāi)發(fā)工具則意味著(zhù)對開(kāi)發(fā)者的賦能功力。 在日前舉行的 HDC 華為開(kāi)發(fā)者大會(huì ) 2022 上，HarmonyOS 的多項舉措，讓我們看到了華為的那股子“向上捅破天，向下扎到根”的精神，通過(guò)打造自研開(kāi)發(fā)工具和“根技術(shù)”能力，描繪出了鴻蒙世界的藍圖。 開(kāi)發(fā)者四大痛點(diǎn) 從 HDC 現場(chǎng)分享的數據里，可以看到，2019-2022 這四年里，HarmonyOS 已累計收集到 10 萬(wàn)余條開(kāi)發(fā)者問(wèn)題反饋。這個(gè)數字顯示出開(kāi)發(fā)者對 HarmonyOS 的期待與改進(jìn)。 投我以桃，報之以李。我們欣喜地看到，HarmonyOS 也以極大的表現回報開(kāi)發(fā)者的熱情。 首先，HarmonyOS 將這些千頭萬(wàn)緒的問(wèn)題分析歸類(lèi)，最后歸結為效率、性能、成本、安全四個(gè)方面。
問(wèn)題擺在這兒了，HarmonyOS 要如何解決呢？ 理念+實(shí)干，HarmonyOS 開(kāi)發(fā)套件解憂(yōu)開(kāi)發(fā)者 HarmonyOS 的答案是理念牽引，實(shí)干支撐。 HarmonyOS 生態(tài)理念 理念只有區區 24 個(gè)字：“⼀次開(kāi)發(fā)，多端部署”“可分可合，⾃由流轉”“統⼀⽣態(tài)，原⽣智能”，卻蘊藏著(zhù)大內涵。 萬(wàn)物互聯(lián)時(shí)代，設備終端數以百億計，每個(gè)終端都是一個(gè)節點(diǎn)，但開(kāi)發(fā)者并沒(méi)有必要為每個(gè)終端單獨開(kāi)發(fā)應用和服務(wù)�！�⼀次開(kāi)發(fā)，多端部署”就意味著(zhù)通過(guò)一套工程、多端部署，同一特性、多端運行，一套界面、多端適配，就以意味著(zhù)在最大程度地幫助開(kāi)發(fā)者提升效率和獲得回報。 而如今的大型應用，其代碼量動(dòng)輒上千萬(wàn)行。把所有要修改的地方都開(kāi)發(fā)完，再去測試和上架，周期之長(cháng)，可想而知。于是，小步快跑、漸進(jìn)迭代成為開(kāi)發(fā)者的首選項。在鴻蒙看來(lái)，在開(kāi)發(fā)態(tài)，“可分”即為應用按照優(yōu)先級拆分為 HarmonyOS 原子化服務(wù)，每個(gè)服務(wù)都可以獨立開(kāi)發(fā)和上架；“可合”讓 HarmonyOS 原子化服務(wù)按需組合成為 HarmonyOS 應用，而且每個(gè)原子化服務(wù)可以共享生命周期管理，這樣做對開(kāi)發(fā)效率的提升有目共睹。同時(shí)，在運營(yíng)態(tài)，可以做到跨端遷移、“自由流轉”，比如手機接聽(tīng)的電話(huà)在上車(chē)以后可以無(wú)縫流轉到車(chē)機上，跑步時(shí)手機播放的音樂(lè )可以無(wú)縫流轉到智能手表上，這才是真正做到應用的自由流轉了。 HarmonyOS 統一了華為的硬件設備底座，同時(shí)還兼容 OpenHarmony 生態(tài)，做到統一建設一個(gè)大的鴻蒙生態(tài)。不僅如此，開(kāi)發(fā)者也能選擇原生的開(kāi)發(fā)框架或者第三方框架開(kāi)發(fā)，與第三方生態(tài)共建共榮。同時(shí)，依托華為在智能方面的積淀，在芯片層，HarmonyOS 幫助應用提升性能、降低功耗；在應用能力開(kāi)放層，HarmonyOS 將自然語(yǔ)言交互、計算視覺(jué)、情景感知等能力以 SDK 的方式開(kāi)放出來(lái)，開(kāi)箱即用；在服務(wù)能力開(kāi)放層，幫助開(kāi)發(fā)者精準觸達用戶(hù)，實(shí)現商業(yè)閉環(huán)。這一切，我們看到的是“統⼀⽣態(tài)，原⽣智能”。 在這三大理念的牽引下，HarmonyOS 對設計、開(kāi)發(fā)、測試、分發(fā) 4 個(gè)階段的應用開(kāi)發(fā)全生命周期，進(jìn)行了徹頭徹尾的改進(jìn)和提升，一口氣推出了包括設計工具、編程語(yǔ)言、編程框架、編譯器、IDE 等“鴻蒙開(kāi)發(fā)套件”七件套大禮包，誠意滿(mǎn)滿(mǎn)。 華為終端 BG 軟件部總裁龔體發(fā)布鴻蒙開(kāi)發(fā)套件
這其中，最能讓開(kāi)發(fā)者眼前一亮的有三個(gè)字“聲明式”，對，就是那個(gè)開(kāi)發(fā)者夢(mèng)寐以求的開(kāi)發(fā)模式。 聲明式開(kāi)發(fā)：HarmonyOS 技術(shù)路線(xiàn)轉型之基 HarmonyOS 從“命令式開(kāi)發(fā)”全面轉型“聲明式開(kāi)發(fā)”，意料之中。 對于“命令式”“聲明式”，開(kāi)發(fā)者們并不陌生。 所謂“命令式”，顧名思義，程序按部就班地聽(tīng)從“命令”去執行，沒(méi)有自己的思想，不智能，只會(huì )遵循開(kāi)發(fā)的規范，被動(dòng)去執行。執行得好壞、效率高不高，與開(kāi)發(fā)者本身的技術(shù)能力關(guān)聯(lián)度很大，要寫(xiě)出讓機器如何去做事情（how to do）的代碼，也就是說(shuō)基本取決于開(kāi)發(fā)者的代碼“水平”�，F在大部分程序開(kāi)發(fā)都是走的這條路。 而“聲明式”則大有不同，是對開(kāi)發(fā)模式的一次變革——比 GitHub 的 Cloplite 輔助工具通過(guò)函數注釋生成代碼的方式更進(jìn)一步，只要“聲明”我想要什么樣的結果（what to do），程序就調用相關(guān)的 API，自主設計執行路徑，以達到預期的結果�？梢钥闯�，“聲明式”讓程序具備一定的智能，開(kāi)發(fā)起來(lái)能有效降低門(mén)檻，提升效率。 聲明式 UI 范式 可以看出，“聲明式”開(kāi)發(fā)更接近人類(lèi)語(yǔ)言，具備更高的可讀性、易學(xué)習性，并且代碼簡(jiǎn)潔可重用、編碼高效好測試。 舉例來(lái)說(shuō)，要炒一道菜，“命令式”要一步步地指揮洗菜、切菜、放油、下鍋、加料、翻炒、盛盤(pán)；而“聲明式”要表達的是想炒一道菜，程序便自動(dòng)調用相關(guān)的 API，尋找這道菜的最佳工藝并執行。 隨著(zhù) AI 驅動(dòng)的自動(dòng)化編程技術(shù)的發(fā)展，“聲明式”從理想成為現實(shí)，并且正在成為趨勢。 正是看到了這樣的趨勢，結合自身的積累，HarmonyOS 向“聲明式”開(kāi)發(fā)，正式開(kāi)拔。 要進(jìn)行“聲明式”開(kāi)發(fā)，根在編程語(yǔ)言。在最關(guān)鍵的編程語(yǔ)言轉型為“聲明式”后，與之配套的應用開(kāi)發(fā)全生命周期的工具，自然要同步轉型，遵循同樣的語(yǔ)法規則，方能形成合力。 此次發(fā)布的聲明式開(kāi)發(fā)語(yǔ)言 ArkTS 是 HarmonyOS 的主力應用開(kāi)發(fā)語(yǔ)言，它基于 TypeScript 語(yǔ)言體系擴展了聲明式 UI 語(yǔ)法和輕量化并發(fā)機制，增加了一些語(yǔ)法糖的能力，讓跨端界面開(kāi)發(fā)和并行化任務(wù)開(kāi)發(fā)，高效簡(jiǎn)潔，使應用開(kāi)發(fā)效率提升 30%。目前，基于 ArkTS 語(yǔ)言的 API 已達 10000+，基本能滿(mǎn)足當前應用開(kāi)發(fā)場(chǎng)景的使用需求。 事實(shí)上，ArkTS 語(yǔ)言并非一門(mén)全新的語(yǔ)言，而是作為 TypeScript 語(yǔ)言的增強型語(yǔ)言，因此兼容 JS 語(yǔ)言和 TS 語(yǔ)言的生態(tài)�？傮w來(lái)說(shuō)，ArkTS 主要增強了這幾個(gè)方面的能力。
在這里，分享一個(gè)數字：相比傳統的 HTML+CSS+JS 的類(lèi) Web 范式，同樣的任務(wù)，ArkTS 代碼量有超過(guò) 50% 的減少。 Stage：全新的規范化進(jìn)程管理開(kāi)發(fā)模型 在聲明式之外，還有一點(diǎn)吸引到我了——Stage 開(kāi)發(fā)模型，可謂是 ArkUI 中的一大創(chuàng )新。 ArkUI 的本意實(shí)現“一次開(kāi)發(fā)，多端部署”，提升開(kāi)發(fā)效率和設備性能。具體的實(shí)現方式有三。 一是跨設備界面開(kāi)發(fā)能力，這是鴻蒙一直在持續構建的能力，不再贅述。 二是升級了整體渲染框架。傳統的渲染，由三棵樹(shù)來(lái)完成，經(jīng)過(guò)反復的嘗試后，鴻蒙實(shí)現了一棵樹(shù)來(lái)完成，同時(shí)把多節點(diǎn)組合模型變成了單節點(diǎn)+屬性組合模型。這些架構的調整，對應用開(kāi)發(fā)者來(lái)說(shuō)，是不可見(jiàn)、透明的。這頓操作之后，ArkUI 提升了界面加載性能——渲染速度提升 20%，渲染內存降低 30%，渲染指令降低 20%。 三就是 Stage 這個(gè)“新生兒”。 之所以推出 Stage 模型，是因為在上一代移動(dòng)操作系統中，大多數的設備后臺管理比較混亂。Stage 模型提供了系統對進(jìn)程數量配置、后臺服務(wù)定義、后臺服務(wù)拉起等的統一納管，從而使應用能夠更好地組織在一起。目前，Stage 模型支持兩種模式，一種是 JS 語(yǔ)言層的實(shí)體類(lèi) UIAbility，另一種是鴻蒙提供的一組系統類(lèi) Extention Ability。應用如果希望調用系統提供類(lèi)似服務(wù)的話(huà)，不再需要自己寫(xiě)一個(gè) Service，而是自己繼承派生出一個(gè)基于 Extention 類(lèi)的自有類(lèi)，通過(guò)這種方式拉起相關(guān)的服務(wù)。 Stage 模型 這樣管理起來(lái)之后，后臺的常駐程序可大幅減少，從使系統資源更加有序。 同時(shí)，Stage 模型實(shí)現了將邏輯與UI解耦。意思是，使用 Stage 模型時(shí)，可以讓邏輯段代碼和 UI 段代碼在分離的物理設備上運行，這無(wú)疑強化了鴻蒙程序流轉的能力。 多設備應用模型歸一、Stage 內置的框架可以實(shí)現秒級的自動(dòng)恢復，則進(jìn)一步強化了 Stage 模型在進(jìn)程管理方面的優(yōu)勢。 與傳統的編程開(kāi)發(fā)模式相比，Stage 模型實(shí)現了碾壓，預計后續會(huì )逐漸成為鴻蒙的主流模式。 鴻蒙開(kāi)發(fā)套件，還有非常多值得深挖的地方，受限于篇幅，我們這次對鴻蒙開(kāi)發(fā)套件的初步觀(guān)察就先到這里。 鴻蒙開(kāi)發(fā)套件總覽 最后，我們想說(shuō)的是，做開(kāi)發(fā)工具不容易，做覆蓋開(kāi)發(fā)全生命周期的全鏈路開(kāi)發(fā)工具更不容易。更進(jìn)一步，能同時(shí)做操作系統和全鏈路開(kāi)發(fā)工具的，放眼全球，更是屈指可數。 鴻蒙操作系統+開(kāi)發(fā)工具雙輪驅動(dòng)的鴻蒙生態(tài)的未來(lái)，值得期待。 |
