作者：yuzhiqiang

應(yīng)用框架，是操作系統(tǒng)連接開發(fā)者生態(tài)，實(shí)現(xiàn)用戶體驗(yàn)的關(guān)鍵基礎(chǔ)設(shè)施。其中，開發(fā)效率和運(yùn)行體驗(yàn)是永恒的訴求，業(yè)界也在持續(xù)不斷的發(fā)展和演進(jìn)。

本文重點(diǎn)圍繞移動(dòng)應(yīng)用框架，梳理其關(guān)鍵發(fā)展脈絡(luò)，并分析其背后的技術(shù)演進(jìn)思路以及目前的局限；同時(shí)，進(jìn)一步結(jié)合萬物智聯(lián)的新場景和新生態(tài)，圍繞相應(yīng)的應(yīng)用框架的設(shè)計(jì)和演進(jìn)，分享個(gè)人在這個(gè)領(lǐng)域的思考，實(shí)踐，以及下一步探索。

“萬物皆有裂縫，那是光照進(jìn)來的地方”–萊昂納德 · 科恩

1、具體案例分析：ArkUI開發(fā)框架的實(shí)踐，探索和演進(jìn)

2019年，我們開始思考如何構(gòu)建新一代應(yīng)用框架，重點(diǎn)圍繞極簡開發(fā)，高能效比，跨設(shè)備以及跨平臺(tái)這幾個(gè)關(guān)鍵的設(shè)計(jì)目標(biāo)，逐步演進(jìn)出ArkUI以及相配套的語言，API等能力，并形成了鴻蒙生態(tài)主推的開發(fā)框架。接下來的內(nèi)容將以ArkUI作為一個(gè)具體案例，來說明這塊相關(guān)的實(shí)踐，探索和演進(jìn)。

1.1整體概覽

ArkUI是一套聲明式開發(fā)框架，它具備簡潔自然的UI信息語法、豐富的UI組件、多維狀態(tài)管理，以及實(shí)時(shí)多維度預(yù)覽等能力，幫助開發(fā)者提升應(yīng)用開發(fā)效率，并能在多種設(shè)備實(shí)現(xiàn)生動(dòng)而流暢的用戶體驗(yàn)。同時(shí)可進(jìn)一步擴(kuò)展到多個(gè)OS平臺(tái)。下圖描述了ArkUI開發(fā)框架的整體視圖：

Figure 1ArkUI開發(fā)框架整體視圖

ArkUI的關(guān)鍵特征如下所示：

a.簡潔自然的聲明式語法；

b.高效的渲染管線以及平臺(tái)一致性的渲染機(jī)制；

c.高效的方舟編譯器以及運(yùn)行時(shí)；

d.統(tǒng)一的跨平臺(tái)API能力集以及擴(kuò)展機(jī)制。

1.2關(guān)鍵組成

ArkUI的關(guān)鍵組成包括以下幾個(gè)方面：ArkTS語言以及相應(yīng)的聲明式范式；UI關(guān)鍵能力（布局、組件、動(dòng)效以及自適應(yīng)、自定義能力）；渲染管線；ArkTS編譯器&運(yùn)行時(shí)；可部署到輕量級(jí)設(shè)備的輕量化運(yùn)行時(shí)；以及推動(dòng)應(yīng)用開發(fā)的生態(tài)融合設(shè)計(jì)。接下來分別展開說明。

1.2.1 ArkTS語言&聲明式范式

ArkTS在TS(TypeScript)的基礎(chǔ)上，擴(kuò)展了聲明式UI、狀態(tài)管理等相應(yīng)的能力，讓開發(fā)者通過更簡潔、更自然的方式開發(fā)高性能應(yīng)用。

下面結(jié)合一個(gè)具體的示例，從應(yīng)用開發(fā)的角度簡要描述下基于ArkTS的聲明式范式。

Figure 2基于ArkTS的聲明式范式的簡要示例

上圖所示的代碼示例，UI界面會(huì)顯示一個(gè)“Hello World”的文本以及一個(gè)“Click me”按鈕。當(dāng)用戶點(diǎn)擊“Click me”按鈕時(shí)，字符串變量 myText 的值會(huì)從“World”變?yōu)椤?a target="_blank">ACE ”，文本最終顯示為“Hello ACE”。

這個(gè)示例中所包含的ArkUI聲明式開發(fā)范式的基本組成說明如下：

裝飾器：用來裝飾類、結(jié)構(gòu)體、方法以及變量，賦予其特殊的含義，如上述示例中@Entry、@Component、@State都是裝飾器。具體而言，@Component表示這是個(gè)自定義組件；@Entry則表示這是個(gè)入口組件；@State表示組件中的狀態(tài)變量，這個(gè)狀態(tài)變化會(huì)引起相應(yīng)的 UI的自動(dòng)刷新。

自定義組件：可復(fù)用的 UI 單元，可組合其它組件，如上述被@Component 裝飾的Struct Hello。

UI 描述：聲明式的方式來描述 UI 的結(jié)構(gòu)，如上述 build()方法內(nèi)部的代碼塊。

內(nèi)置組件：框架中默認(rèn)內(nèi)置的基礎(chǔ)和布局組件，可直接被開發(fā)者調(diào)用，比如示例中的 Column、Text、Divider、Button。

事件方法：用于添加組件對事件的響應(yīng)邏輯，統(tǒng)一通過事件方法進(jìn)行設(shè)置，如跟隨在Button后面的onClick()。

屬性方法：用于組件屬性的配置，統(tǒng)一通過屬性方法進(jìn)行設(shè)置，如fontSize()、width()、height()、color()等，可通過鏈?zhǔn)秸{(diào)用的方式設(shè)置多項(xiàng)屬性。

具體而言，ArkTS在TS的基礎(chǔ)上，做了以下幾個(gè)方面的增強(qiáng)：

3.2.1.1簡潔自然的組件化描述機(jī)制

這里主要包括通過Struct定義的自定義組件名字；通過build()方法提供的自定義組件的內(nèi)容（可基于系統(tǒng)的內(nèi)置組件，或其他自定義組件來自由組合）；以及通用的裝飾器機(jī)制（以@開始的描述符）。具體到自定義組件而言，則是通過@Component裝飾器來裝飾的自定義組件類型，以便其他組件來使用。同時(shí)，還定義了組件的生命周期相關(guān)的回調(diào)函數(shù)。這些共同定義了自定義組件的基礎(chǔ)設(shè)施。

3.2.1.2多維狀態(tài)管理機(jī)制

狀態(tài)管理主要是實(shí)現(xiàn)數(shù)據(jù)到UI的自動(dòng)映射，以實(shí)現(xiàn)數(shù)據(jù)驅(qū)動(dòng)UI的自動(dòng)變更。上面例子中的通過@State裝飾的myText即是狀態(tài)管理的最簡單的一種情況。實(shí)際應(yīng)用開發(fā)中，則是需要多維度的狀態(tài)管理。下圖顯示了ArkTS所涉及的狀態(tài)管理的整體視圖，主要也是通過相關(guān)的裝飾器來完成。

Figure 3多維狀態(tài)管理

一個(gè)應(yīng)用可以有多個(gè)頁面，每個(gè)頁面可以有多個(gè)組件，不同組件之間可以有相互關(guān)聯(lián)。另外，數(shù)據(jù)的來源以及影響范圍也可以有所不同。為此我們定義了不同維度的狀態(tài)管理，來處理不同的場景。

狀態(tài)管理的范圍可以是組件內(nèi)，組件間，頁面級(jí)(LocalStorage)，應(yīng)用級(jí)(AppStorage)；組件間可以是父子組件間的逐層傳遞，也可以是爺孫組件間跨層傳遞；傳遞方式可以單向傳遞（@Prop）或是雙向傳遞（@Link）;數(shù)據(jù)的類型可以是簡單類型，也可以是復(fù)雜類型；數(shù)據(jù)的來源/存儲(chǔ)可以來自內(nèi)存，持久化存儲(chǔ)，環(huán)境參數(shù)，還可以是跨設(shè)備的分布式數(shù)據(jù)。這些構(gòu)建了應(yīng)用開發(fā)中所需的狀態(tài)管理的基礎(chǔ)設(shè)施，并簡化了跨設(shè)備場景下的應(yīng)用開發(fā)。

3.2.1.3動(dòng)態(tài)擴(kuò)展組合機(jī)制

前面的組件化描述，狀態(tài)管理機(jī)制，再配合內(nèi)置組件構(gòu)建了UI的基礎(chǔ)設(shè)施。某些場景下，還需要UI描述能夠動(dòng)態(tài)擴(kuò)展以及組合，比如基于自定義DSL（Domain Specific Language）動(dòng)態(tài)的內(nèi)容構(gòu)建以及刷新場景，典型的案例是京東的MCube, 阿里巴巴的手淘的DynamicX等。為此，我們進(jìn)一步擴(kuò)展了ArkTS的語義，通過@Extend裝飾器根據(jù)具體場景來動(dòng)態(tài)添加/擴(kuò)展組件的屬性，通過@Builder裝飾器來動(dòng)態(tài)組合不同的組件，從而實(shí)現(xiàn)運(yùn)行時(shí)動(dòng)態(tài)構(gòu)建UI視圖的目標(biāo)。

具體案例分析細(xì)節(jié)，可看參考資料:京東APP Open-Harmony 化的跨端開發(fā)探索

另外，有關(guān)ArkTS的起源和演進(jìn)，可以看參考資料:淺析eTS的起源和演進(jìn)(注：eTS是ArkTS的前稱)

1.2.2內(nèi)置組件、自定義機(jī)制、動(dòng)效、多設(shè)備適配

上述的ArkTS以及聲明式范式的基礎(chǔ)介紹只是描述了聲明式UI的基礎(chǔ)語法以及基礎(chǔ)框架，如果要完成完整的UI能力則還需要其他關(guān)鍵組成，包括各種內(nèi)置組件（容器組件、基礎(chǔ)組件等），動(dòng)效，以及自適應(yīng)，自定義能力等。ArkUI在基礎(chǔ)的圖形Surface之上，構(gòu)建了一整套的UI體系。

1.2.2.1內(nèi)置組件（容器組件，基礎(chǔ)組件等）

ArkUI內(nèi)置組件大致分為以下幾種類型：

容器組件類：包括橫向布局，縱向布局，堆疊布局，相對布局容器，二維的網(wǎng)格類型布局等；以及常用的滾動(dòng)列表（橫向，縱向），側(cè)邊欄容器等；

基礎(chǔ)組件類：包括按鈕，文本，檢查框，選擇框，進(jìn)度條，導(dǎo)航等；

畫布組件類：包含基礎(chǔ)畫布，各類線條形狀路徑等；

媒體&高級(jí)組件類：包含圖片，視頻等；富文本，Web組件，xComponent自繪制組件等；

通過這些內(nèi)置組件以及相應(yīng)的屬性、事件處理能力的不同設(shè)置和組合，來覆蓋應(yīng)用開發(fā)中UI的典型場景。

3.2.2.2自定義機(jī)制

ArkTS的組件化描述機(jī)制，動(dòng)態(tài)擴(kuò)展組合機(jī)制，加上各種內(nèi)置組件，構(gòu)成了自定義組件的基礎(chǔ)，再配合基礎(chǔ)畫布/xComponent等自繪制能力，可以構(gòu)建出常用場景的組件。不過，某些場景下，開發(fā)者還需要更細(xì)粒度的定制化能力，比如自定義測量/布局以實(shí)現(xiàn)任意形狀的布局，以及在現(xiàn)有組件進(jìn)一步定制化和擴(kuò)展等。下圖描述了ArkUI的自定義布局的基本流程：

Figure 4ArkUI自定義布局流程

如圖所示，其中的onMeasure以及onLayout是框架層提供給應(yīng)用開發(fā)者的接口，供開發(fā)者自定義具體的組件測量方法以及基于測量結(jié)果的布局機(jī)制，以實(shí)現(xiàn)任何的布局，比如瀑布流布局，環(huán)狀布局等等。整體運(yùn)行時(shí)流程大致如下：渲染管線觸發(fā)渲染流程->觸發(fā)動(dòng)效->觸發(fā)布局->調(diào)用開發(fā)者實(shí)現(xiàn)OnMeasure函數(shù)，由開發(fā)者實(shí)現(xiàn)測量邏輯，由ArkTS側(cè)調(diào)用框架層相應(yīng)子組件measure接口->調(diào)用開發(fā)者實(shí)現(xiàn)OnLayout函數(shù)，開發(fā)者實(shí)現(xiàn)布局邏輯，設(shè)置所有子組件位置，由ArkTS側(cè)調(diào)用框架層相應(yīng)子組件layout接口->觸發(fā)渲染。

不過，更靈活的自定義能力，比如在現(xiàn)有組件實(shí)現(xiàn)方法/屬性級(jí)的定制化和擴(kuò)展，更便捷的自繪制能力等方面還需進(jìn)一步完善。

3.2.2.3動(dòng)效

動(dòng)效，即動(dòng)畫效果，本質(zhì)上它也是一種狀態(tài)驅(qū)動(dòng)的UI變更。具體而言，動(dòng)效是在起始狀態(tài)和終止?fàn)顟B(tài)之間，加入了基于時(shí)間的顯示效果的平滑過渡。

從作用的對象角度，動(dòng)效一般包括組件本身的動(dòng)效（比如各種屬性變化引起的動(dòng)效），轉(zhuǎn)場動(dòng)效（組件增減/移動(dòng)，頁面之間轉(zhuǎn)場，共享元素在頁面間轉(zhuǎn)場）；從開發(fā)的方式角度，包括隱式動(dòng)效（通過設(shè)置相應(yīng)的參數(shù)自動(dòng)觸發(fā)），顯式動(dòng)效（通過顯示調(diào)用動(dòng)畫接口來指定由于閉包代碼導(dǎo)致的狀態(tài)變化插入過渡動(dòng)效）。

ArkUI提供了上述場景所需的動(dòng)效能力，通過結(jié)合相應(yīng)的狀態(tài)變量，相關(guān)聯(lián)的UI組件/頁面，以及相應(yīng)的時(shí)序曲線算法函數(shù)來共同完成。

應(yīng)用通過提供的聲明式動(dòng)畫接口，進(jìn)行動(dòng)畫業(yè)務(wù)邏輯組織；通過狀態(tài)更新監(jiān)聽器，監(jiān)聽綁定動(dòng)畫的屬性；動(dòng)畫對象提供動(dòng)畫參數(shù)存儲(chǔ)能力的數(shù)據(jù)結(jié)構(gòu)，包括動(dòng)畫持續(xù)時(shí)間、動(dòng)畫曲線、延遲時(shí)間等。組件樹提供真實(shí)組件渲染節(jié)點(diǎn)，包含平移、旋轉(zhuǎn)、縮放等效果渲染節(jié)點(diǎn)。動(dòng)畫引擎提供動(dòng)畫驅(qū)動(dòng)能力。最終觸發(fā)節(jié)點(diǎn)的重新繪制，通過渲染引擎進(jìn)行界面更新。

ArkUI動(dòng)效相關(guān)能力目前還比較基礎(chǔ)，相關(guān)時(shí)序/效果算法的豐富度，以及動(dòng)效的細(xì)粒度控制/自定義能力等都在持續(xù)增強(qiáng)演進(jìn)中。

3.2.2.4多設(shè)備適配（界面自適應(yīng)，交互自適應(yīng)等）

ArkUI圍繞多設(shè)備適配提供了系統(tǒng)化的多層次的解決方案。下圖顯示了其中的關(guān)鍵內(nèi)容。

Figure 5ArkUI多設(shè)備適配

如圖所示，UI維度的多設(shè)備適配從上到下分為三個(gè)層次：場景樣例，布局能力，視覺交互：

場景樣例：聯(lián)合用戶體驗(yàn)設(shè)計(jì)對常用組件的組合場景作出定義和輸出樣例代碼，包含：頂部、入口、分欄、瀑布流、Banner、視頻列表、視頻宮格、圖文、圖片詳情等；

布局能力：包含響應(yīng)式能力：響應(yīng)式組件（List 、Navigation、Grid、Swiper、Tabs、柵格布局組件），響應(yīng)式能力（柵格系統(tǒng)、自定義斷點(diǎn)系統(tǒng)、媒體查詢）；以及自適應(yīng)能力：常用自適應(yīng)組件+自適應(yīng)能力（隱藏、延伸、縮放、均分、占比、拉伸、折行）等；

視覺交互：包含分層參數(shù)/主題風(fēng)格：支持多設(shè)備上采用不同的主題風(fēng)格，深淺主題，自定義主題樣式等，滿足應(yīng)用的個(gè)性化皮膚;多態(tài)組件：支持統(tǒng)一的組件描述，不同的設(shè)備呈現(xiàn)效果；交互歸一：屏蔽設(shè)備差異統(tǒng)一交互邏輯，把不同的設(shè)備的交互輸入集合進(jìn)行統(tǒng)一的事件歸類定義，然后控件完成對應(yīng)的統(tǒng)一響應(yīng)。

在配套開發(fā)工具方面，通過DevEco IDE（Integrated Development Environment）的實(shí)時(shí)多設(shè)備預(yù)覽等相關(guān)能力，進(jìn)一步降低多設(shè)備開發(fā)成本。

當(dāng)然，完整的應(yīng)用的多設(shè)備適配還需結(jié)合相應(yīng)系統(tǒng)的能力，比如系統(tǒng)能力的運(yùn)行期識(shí)別判斷，應(yīng)用的模塊化打包分發(fā)，以及面向不同設(shè)備的彈性部署等。

完整內(nèi)容，可看參考資料：鴻蒙生態(tài)應(yīng)用開發(fā)白皮書

https://developer.huawei.com/consumer/cn/doc/harmonyos-bps?ha_source=wd&ha_sourceId=89000070

1.2.3渲染管線

ArkUI整體渲染管線流程主要包括ArkTS源代碼通過相應(yīng)的編譯工具鏈編譯成中間代碼（其間會(huì)使用到ArkUI的框架API），方舟運(yùn)行時(shí)運(yùn)行相應(yīng)的字節(jié)碼（也可以是AOT后的代碼），最終通過ArkUI框架運(yùn)行時(shí)完成完整的渲染流程。

Figure 6ArkUI渲染管線流程

上圖顯示了主要的渲染流程，其中有幾個(gè)關(guān)鍵特征：

1）扁平化的按需組合的渲染管線。通過聲明式UI前后端的融合設(shè)計(jì)，開發(fā)范式中的UI描述基本可以直接映射到后端組件。同時(shí)，后端組件的相關(guān)屬性基于組合式按需構(gòu)建，進(jìn)一步提升構(gòu)建速度并降低內(nèi)存開銷；

2）數(shù)據(jù)依賴的自動(dòng)收集。開發(fā)者只需通過相關(guān)的裝飾器修飾好狀態(tài)變量， ArkUI框架則會(huì)結(jié)合語言的相關(guān)特性（屬性代理等機(jī)制）來自動(dòng)識(shí)別并構(gòu)建相應(yīng)的依賴，實(shí)現(xiàn)相應(yīng)的渲染刷新；

3）通過方舟編譯器以及運(yùn)行時(shí)基于類型的編譯優(yōu)化以及AOT機(jī)制，實(shí)現(xiàn)語言執(zhí)行性能的進(jìn)一步提升。

在上述基礎(chǔ)上，2022年，ArkUI渲染架構(gòu)又做了進(jìn)一步升級(jí)：

Figure 7ArkUI渲染架構(gòu)進(jìn)一步升級(jí)

如上圖所示，渲染架構(gòu)主要進(jìn)行了以下三個(gè)方面的升級(jí)：

1）多節(jié)點(diǎn)按需組合模型→單節(jié)點(diǎn)+屬性按需組合模型

原先架構(gòu)下組件樹構(gòu)建時(shí)，同一組件的不同屬性是通過基礎(chǔ)節(jié)點(diǎn)疊加相應(yīng)的格外屬性的節(jié)點(diǎn)來按需構(gòu)建，復(fù)雜場景下這容易造成節(jié)點(diǎn)過多從而引起性能以及內(nèi)存負(fù)擔(dān)。新的架構(gòu)下實(shí)現(xiàn)了單節(jié)點(diǎn)模型，附加按需的屬性集合以及相應(yīng)任務(wù)處理器，從而大幅降低節(jié)點(diǎn)樹的層級(jí)。另外，通過對相關(guān)任務(wù)處理器的分離，也為后續(xù)進(jìn)一步的細(xì)粒度并行化改造打下了相應(yīng)的基礎(chǔ)。

2）數(shù)據(jù)依賴組件級(jí)更新→細(xì)粒度函數(shù)級(jí)更新

原先架構(gòu)下數(shù)據(jù)依賴只是跟蹤到了自定義組件層級(jí)。新的架構(gòu)下引入了最小化更新機(jī)制，對自定義組件中的build函數(shù)進(jìn)一步分解為細(xì)粒度的函數(shù)的組合，并實(shí)現(xiàn)了將數(shù)據(jù)依賴直接定位到相應(yīng)的子節(jié)點(diǎn)上，從而實(shí)現(xiàn)更精細(xì)化的更新，進(jìn)一步提升UI更新效率。

3）三顆樹→一顆樹

原先架構(gòu)下多棵樹存在的主要目的是實(shí)現(xiàn)差量比較更新。通過最小化更新機(jī)制的引入，差量比較就不是必要的，同時(shí)，再結(jié)合數(shù)據(jù)結(jié)構(gòu)重構(gòu)，可在相關(guān)節(jié)點(diǎn)上生成渲染信息，這樣原先的三顆樹合并成了一棵樹，進(jìn)一步提升了組件渲染速度并降低內(nèi)存。

1.2.4方舟編譯器&運(yùn)行時(shí)

方舟編譯器&運(yùn)行時(shí)的關(guān)鍵目標(biāo)是要實(shí)現(xiàn)可對標(biāo)靜態(tài)類型語言（比如Swift/Java/Kotlin）的性能體驗(yàn)，以及和聲明式框架深度融合從而實(shí)現(xiàn)高效的聲明式開發(fā)。

Figure 8業(yè)界JS/TS的典型性能問題

上圖描述了業(yè)界JS/TS引擎的典型性能問題，主要包括三個(gè)方面：

1）源代碼運(yùn)行時(shí)編譯所帶來的較多的啟動(dòng)開銷；

2）無法直接利用類型信息帶來的優(yōu)化；

3）需要運(yùn)行時(shí)信息的熱點(diǎn)，行為特征收集分析所帶來的預(yù)熱開銷。

Figure 9方舟編譯器&運(yùn)行時(shí)解決方案

如上圖所示，方舟編譯器以及運(yùn)行時(shí)重點(diǎn)通過以下方式解決上述問題：

1）引入帶類型語言字節(jié)碼，并將源碼編譯過程從運(yùn)行時(shí)提前到編譯時(shí)；

2）利用類型信息并結(jié)合PGO信息進(jìn)行編譯時(shí)綜合優(yōu)化；

3）支持動(dòng)態(tài)類型語言類型對象持久化，并優(yōu)化機(jī)器碼的類型對象重綁。

另外，在并行化方面，傳統(tǒng)的Worker機(jī)制由于各自獨(dú)立，信息不共享，啟動(dòng)和資源開銷都比較大。方舟運(yùn)行時(shí)引入了輕量化Actor機(jī)制，通過公共的基礎(chǔ)設(shè)施以及不可變對象的共享，實(shí)現(xiàn)了性能和內(nèi)存的進(jìn)一步優(yōu)化，如下圖所示：

Figure10方舟輕量化Actor機(jī)制

同時(shí)，我們也在進(jìn)一步擴(kuò)展ArkTS，設(shè)計(jì)更輕量更簡便的并發(fā)機(jī)制– Taskpool，下圖是個(gè)簡要的示例：

Figure11Taskpool示例

通過Taskpool機(jī)制，從開發(fā)者維度，開發(fā)者更易于開發(fā)并發(fā)任務(wù)：

簡單直觀，減少代碼編寫量；無需關(guān)心并發(fā)實(shí)例的生命周期；無需關(guān)心場景下并發(fā)任務(wù)負(fù)載輕重。從運(yùn)行時(shí)角度，方舟運(yùn)行時(shí)會(huì)進(jìn)行統(tǒng)一任務(wù)負(fù)載資源管理，降低系統(tǒng)資源消耗 （注：減少線程數(shù)，減少線程的內(nèi)存等資源消耗），并結(jié)合統(tǒng)一調(diào)度機(jī)制，提升整體性能。

通過基于類型的編譯優(yōu)化，結(jié)合PGO信息的運(yùn)行時(shí)優(yōu)化，輕量并行化以及統(tǒng)一調(diào)度機(jī)制，ArkTS以及相應(yīng)的方舟編譯器和運(yùn)行時(shí)已具備了可對標(biāo)靜態(tài)類型語言性能的關(guān)鍵設(shè)施。另外方舟運(yùn)行時(shí)也提供了兼容機(jī)制來支持相應(yīng)的ECMAScript標(biāo)準(zhǔn)。后續(xù)會(huì)進(jìn)一步圍繞高性能以及高開發(fā)效率持續(xù)演進(jìn)，包括進(jìn)一步的共享對象的無鎖并發(fā)機(jī)制，并行化編譯/內(nèi)存管理，標(biāo)準(zhǔn)庫的完善，嚴(yán)格類型以及精細(xì)化類型，分布式類型等等。同時(shí)，也會(huì)逐步通過ECMAScript標(biāo)準(zhǔn)化組織來共同推進(jìn)和完善相關(guān)的語言標(biāo)準(zhǔn)。

1.2.5輕量化框架運(yùn)行時(shí)（可部署到百K級(jí)到M級(jí)內(nèi)存級(jí)別的輕量化設(shè)備）

近年來，越來越多輕量化設(shè)備（百K級(jí)到M級(jí)內(nèi)存）也逐步智能化，其中一個(gè)典型的代表就是運(yùn)動(dòng)手表。這些對應(yīng)用框架的進(jìn)一步解耦和輕量化提出了非常高的要求。ArkUI通過實(shí)現(xiàn)類Web范式的子集，結(jié)合預(yù)編譯機(jī)制部署簡化的JS語言子集的Bytecode, 輕量化的JS引擎（定制化的JerryScript引擎），核心JS框架下沉到C++層，輕量化的UIKit以及圖形引擎，實(shí)現(xiàn)了在輕量化設(shè)備的部署運(yùn)行的能力。以華為的運(yùn)動(dòng)手表系列為例，ArkUI支撐了手表系統(tǒng)內(nèi)置應(yīng)用以及包括微信在內(nèi)的三方應(yīng)用的商用。整體架構(gòu)如下圖所示。

Figure12ArkUI輕量化框架（類Web范式）

接下來，我們會(huì)持續(xù)增強(qiáng)能力（比如輕量設(shè)備上的后臺(tái)運(yùn)行能力），持續(xù)優(yōu)化相關(guān)體驗(yàn)，并探索如何將聲明式開發(fā)范式也進(jìn)一步輕量化，部署到相應(yīng)設(shè)備。

1.3生態(tài)融合設(shè)計(jì)（整體生態(tài)布局，分層對接，跨平臺(tái)）

衡量一個(gè)應(yīng)用框架最終是否成功，關(guān)鍵還是要看它對應(yīng)用開發(fā)者生態(tài)影響的深度和廣度。下圖描述了ArkUI生態(tài)構(gòu)建思路概覽。

Figure 13ArkUI生態(tài)構(gòu)建思路概覽

如圖所示，自底向上，整體生態(tài)構(gòu)建分為四個(gè)維度。

1）框架。這層主要是框架本身的特性完備度以及競爭力，并能夠滿足關(guān)鍵應(yīng)用的需求（包括關(guān)鍵自研應(yīng)用和關(guān)鍵三方應(yīng)用）。尤其是要通過關(guān)鍵垂類應(yīng)用（比如電商，地圖，游戲等）的突破來進(jìn)一步完善框架本身。另外，如之前所述，當(dāng)多個(gè)主流OS平臺(tái)會(huì)長時(shí)間并存的情況下，跨OS平臺(tái)是核心競爭力訴求?？蚣鼙仨毦邆湎鄳?yīng)的能力來進(jìn)一步提升開發(fā)效率。

2）工具。這層主要是配套開發(fā)工具的完備度以及三方主流開發(fā)工具的支持度。DevEco作為ArkUI的核心配套工具，需要在整體開發(fā)工作流進(jìn)一步完善，同步，也需逐步推進(jìn)和三方開發(fā)工具的整合，包括VSCode, 基于Chrome瀏覽器的調(diào)試等，進(jìn)一步方便開發(fā)者。

3）社區(qū)。這層主要是通過相應(yīng)的開源社區(qū)（開放原子開源基金會(huì)等），以及三方開源庫，組件倉庫等建設(shè)，以及結(jié)合主流的組件倉庫NPM（Node Package Manager）等推動(dòng)ArkUI的三方組件的進(jìn)一步完善。

4）標(biāo)準(zhǔn)。這層主要是通過標(biāo)準(zhǔn)化的參與，來構(gòu)建中長線影響力。包括W3C相關(guān)的標(biāo)準(zhǔn)組織（ArkUI類Web范式的進(jìn)一步標(biāo)準(zhǔn)化，WebAssembly的融合探索等），ECMAScript標(biāo)準(zhǔn)組織（ArkTS的增強(qiáng)語言特性的進(jìn)一步標(biāo)準(zhǔn)化等），軟件綠色聯(lián)盟（應(yīng)用質(zhì)量標(biāo)準(zhǔn)，原子化服務(wù)標(biāo)準(zhǔn)的完善/互通等）。

總之，ArkUI的整體生態(tài)推進(jìn)策略是以關(guān)鍵應(yīng)用為牽引，逐步夯實(shí)相應(yīng)能力構(gòu)建，通過工具、社區(qū)協(xié)同，并布局標(biāo)準(zhǔn)培育中長線影響力。

接下來，以ArkUI框架這層的生態(tài)分層接入接口設(shè)計(jì)，以及跨OS平臺(tái)設(shè)計(jì)為例，來進(jìn)一步展開說明。

1.3.1ArkUI生態(tài)分層接入接口設(shè)計(jì)

下圖描述了ArkUI的生態(tài)分層接入接口設(shè)計(jì)的整體視圖。移動(dòng)應(yīng)用生態(tài)發(fā)展至今，尤其是復(fù)雜的大型應(yīng)用，存在著多種技術(shù)棧并存的情況。ArkUI的生態(tài)分層接入接口設(shè)計(jì)的整體思路是在保證開發(fā)生態(tài)以及體驗(yàn)可控的前提下，提供必要的分層接口，方便相關(guān)技術(shù)棧的接入。

Figure 14ArkUI生態(tài)分層接入接口設(shè)計(jì)

如圖所示，相關(guān)的技術(shù)棧可大致分為4種類型：

Ⅰ、原生代碼，以及各廠商自研的動(dòng)態(tài)化模板引擎

這類代碼通過標(biāo)準(zhǔn)的ArkTS API來接入。應(yīng)用原來的原生代碼通過ArkUI聲明式開發(fā)范式來開發(fā)，以保證最優(yōu)開發(fā)以及性能體驗(yàn)；三方的動(dòng)態(tài)化模板引擎（比如前面章節(jié)提到的京東的MCube），可通過ArkTS提供的動(dòng)態(tài)化構(gòu)建組合的API來適配接入。

更進(jìn)一步，ArkUI也在同步設(shè)計(jì)基于ArkTS的動(dòng)態(tài)化內(nèi)容部署機(jī)制，這樣可以更高效的實(shí)現(xiàn)動(dòng)態(tài)化內(nèi)容接入。后續(xù)配合ArkUI跨OS平臺(tái)項(xiàng)目，可實(shí)現(xiàn)基于統(tǒng)一的聲明式開發(fā)范式來開發(fā)應(yīng)用和動(dòng)態(tài)化內(nèi)容，以及相應(yīng)的跨OS平臺(tái)部署，進(jìn)一步整體提升開發(fā)效率以及性能體驗(yàn)。

Ⅱ、類Web前端框架

類Web前端框架包括RAX/React/Vue等，這類代碼可通過JS DOM API來接入。不過，目前JS DOM API提供的接口范圍還相對比較有限，也不夠標(biāo)準(zhǔn)。這塊接口完備性，標(biāo)準(zhǔn)化（包括CSS能力支持等）以及相關(guān)的渲染路徑優(yōu)化等方面，需進(jìn)一步改進(jìn)和完善。

Ⅲ、標(biāo)準(zhǔn)HTML5

ArkUI提供了符合W3C標(biāo)準(zhǔn)的Web組件，底下是標(biāo)準(zhǔn)的Web運(yùn)行時(shí)。標(biāo)準(zhǔn)HTML5的內(nèi)容可直接通過相應(yīng)的Web組件來接入。

Ⅳ、自繪制引擎/中間件

對于三方基于C/C++實(shí)現(xiàn)的自繪制引擎/中間件，比如典型的游戲引擎、地圖、直播等，ArkUI提供了xComponent機(jī)制，通過提供基于C Surface的相關(guān)標(biāo)準(zhǔn)的OpenGL ES接口來幫助開發(fā)者接口，可以獨(dú)立顯示，或嵌入在ArkUI的UI組件中融合顯示。Cocos游戲引擎以及相關(guān)的IDE基于ArkUI的xComponent接入框架，協(xié)同相應(yīng)的編譯工具鏈，語言運(yùn)行時(shí)，系統(tǒng)API能力等已完成了相應(yīng)的適配接入，

相關(guān)信息可看參考資料 – Cocos Creator發(fā)布到OpenHarmony：

https://docs.cocos.com/creator/manual/zh/editor/publish/publish-openharmony.html

下圖顯示了Cocos游戲引擎接入ArkUI xComponent的示例，其它的游戲引擎/自繪制引擎的接入可參考類似方案。

Figure 15Cocos游戲引擎接入ArkUI xComponent示例

1.3.2 ArkUI跨OS平臺(tái)設(shè)計(jì)

ArkUI-X是ArkUI跨OS平臺(tái)項(xiàng)目名稱，它基于OpenHarmony中的ArkUI以及相關(guān)API，做了相應(yīng)跨OS平臺(tái)擴(kuò)展。整體視圖如下所示：

Figure 16ArkUI跨OS平臺(tái)整體視圖

ArkUI-X聚焦在構(gòu)建跨平臺(tái)框架的核心設(shè)施， 將ArkUI的能力擴(kuò)展到iOS和Android平臺(tái)上。開發(fā)者可以通過一份代碼，結(jié)合相應(yīng)的工具鏈，同時(shí)生成多個(gè)OS平臺(tái)的應(yīng)用工程，并可編譯出相應(yīng)的應(yīng)用程序，在相應(yīng)的平臺(tái)上高效的運(yùn)行。關(guān)鍵特性集包括以下幾個(gè)方面(具體的特性范圍以實(shí)際的演進(jìn)情況為準(zhǔn))：

Ⅰ、編譯工具鏈

編譯工具鏈提供了兩類能力：一類是面向ArkUI框架開發(fā)者，它可以構(gòu)建出相應(yīng)平臺(tái)的ArkUI SDK（比如iOS,Android），供應(yīng)用打包分發(fā)使用(OpenHarmony系統(tǒng)由于內(nèi)置了ArkUI，則無需和應(yīng)用一起打包）；另一類是面向應(yīng)用開發(fā)者，它提供創(chuàng)建不同平臺(tái)的應(yīng)用工程，基于相關(guān)的SDK編譯工程生成目標(biāo)平臺(tái)的應(yīng)用，啟動(dòng)應(yīng)用等相應(yīng)功能。命令行工具支持的PC平臺(tái)包括Windows（通過WSL - Windows Subsystem for Linux）, macOS, Linux。

Ⅱ、平臺(tái)橋接

平臺(tái)橋接提供了相應(yīng)的平臺(tái)能力橋接，包括目標(biāo)平臺(tái)的應(yīng)用加載入口，生命周期，事件處理，窗口系統(tǒng)，資源管理，剪切板，輸入法，攝像頭，以及其他高級(jí)組件接入等相關(guān)能力。

Ⅲ、UI組件適配

UI組件適配提供了UI組件在不同平臺(tái)上的繪制效果的一致性。由于ArkUI架構(gòu)上是通過自繪制能力實(shí)現(xiàn)相應(yīng)效果，這塊主要是以驗(yàn)證為主。

Ⅳ、基礎(chǔ)API能力適配

基礎(chǔ)API能力適配包括了兩方面內(nèi)容：API擴(kuò)展機(jī)制以及API的具體實(shí)現(xiàn)。API的擴(kuò)展機(jī)制基于N-API實(shí)現(xiàn)的，需要在不同的平臺(tái)上做相應(yīng)的適配；API的實(shí)現(xiàn)主要包括OpenHarmony的平臺(tái)能力JS API， HMS（Huawei Mobile Service）的JS API等在不同平臺(tái)上的實(shí)現(xiàn)。具體的API實(shí)現(xiàn)節(jié)奏會(huì)結(jié)合相應(yīng)的應(yīng)用需求來推進(jìn)。

Ⅴ、應(yīng)用嵌入集成

應(yīng)用嵌入集成提供了目標(biāo)平臺(tái)應(yīng)用和ArkUI集成的能力，目標(biāo)平臺(tái)應(yīng)用可以一部分基于現(xiàn)有的平臺(tái)代碼實(shí)現(xiàn)，另一部分引入ArkUI的實(shí)現(xiàn)，這樣有助于應(yīng)用逐步的平滑的遷移到ArkUI。

Ⅵ、調(diào)試能力

調(diào)試能力主要是指在非OpenHarmony平臺(tái)上的調(diào)試能力，需要對ArkUI在不同平臺(tái)上的調(diào)試能力做相應(yīng)的適配和使能，后續(xù)也會(huì)包括相應(yīng)的IDE插件能力的構(gòu)建。

Ⅶ、XTS（X Test Suite）基礎(chǔ)設(shè)施

XTS基礎(chǔ)設(shè)施主要是驗(yàn)證ArkUI框架能力在不同平臺(tái)上的兼容性，通過同一套的XTS測試集（包括UI以及API）在不同平臺(tái)上使能，來保證ArkUI框架能力在不同OS平臺(tái)實(shí)現(xiàn)效果的一致性。

Ⅷ、架構(gòu)演進(jìn)

架構(gòu)演進(jìn)主要包括可維護(hù)性的增強(qiáng)（架構(gòu)解耦-組件以及能力API按需加載，分層抽象-渲染后端的抽象以便平滑過渡等），以及在性能、內(nèi)存、包體積相關(guān)的優(yōu)化等。這塊會(huì)結(jié)合Open-Harmony上 ArkUI本身的演進(jìn)和跨平臺(tái)的相關(guān)需求逐步推進(jìn)。

ArkUI-X項(xiàng)目在2022年以定向開源方式啟動(dòng)，先聚焦iOS以及Android平臺(tái)。非常感謝我們的合作伙伴-美的IoT移動(dòng)端技術(shù)團(tuán)隊(duì)，阿里巴巴閑魚技術(shù)團(tuán)隊(duì)，深開鴻技術(shù)團(tuán)隊(duì)和我們共同創(chuàng)建了ArkUI跨OS平臺(tái)項(xiàng)目，并有了第一個(gè)初始版本。雖然目前版本還相對簡單，但整個(gè)跨平臺(tái)框架的基礎(chǔ)設(shè)施以及關(guān)鍵的基礎(chǔ)能力已具備，后續(xù)逐步會(huì)有相應(yīng)APP商用落地。接下來我們會(huì)持續(xù)圍繞上述關(guān)鍵特性，結(jié)合更多典型場景持續(xù)打磨、完善。同時(shí)，我們也在探索ArkUI如何進(jìn)一步擴(kuò)展到PC平臺(tái)以及Web平臺(tái)。也歡迎更多感興趣的開發(fā)者加入進(jìn)來，一起推進(jìn)。

1.4下一步探索

有關(guān)ArkUI的下一步，其實(shí)在前面相關(guān)章節(jié)的設(shè)計(jì)描述中已有涉及。這里進(jìn)一步從關(guān)鍵競爭力以及生態(tài)建設(shè)的角度，來分享幾個(gè)潛在的大顆粒的技術(shù)方向的一些想法。

1.4.1精細(xì)化的異構(gòu)并行加速&統(tǒng)一調(diào)度

目前越來越多的智能設(shè)備都具備多核能力（包括同一配置的多核以及不同配置的大小核），有些設(shè)備還會(huì)攜帶多種類型的計(jì)算芯片（GPU/NPU/...）。同時(shí)，對高端設(shè)備而言，復(fù)雜酷炫的應(yīng)用，結(jié)合需實(shí)時(shí)響應(yīng)的用戶交互處理等，都對計(jì)算性能提出了更高要求；而對低端設(shè)備而言，怎么基于較弱的芯片配置在典型場景也能達(dá)成60幀的流暢體驗(yàn)。一個(gè)潛在的方向是進(jìn)一步挖掘整體應(yīng)用處理、渲染過程中的并行化機(jī)會(huì)，并充分利用底層的多核能力，并結(jié)合統(tǒng)一的基于場景優(yōu)先級(jí)的調(diào)度進(jìn)一步提升相關(guān)體驗(yàn)。另外，在聲明式開發(fā)場景下，由于相關(guān)UI描述是獨(dú)立的，只讀的，相應(yīng)的數(shù)據(jù)流也有相關(guān)使用約束，是通過統(tǒng)一的數(shù)據(jù)來源來驅(qū)動(dòng)（比如只能在事件處理等相關(guān)回調(diào)中改變數(shù)據(jù)，而不是像傳統(tǒng)的命令式開發(fā)那樣開發(fā)者可以在任何地方修改數(shù)據(jù)），這些使得聲明式開發(fā)在理論上比傳統(tǒng)的命令式開發(fā)可以更容易也更有機(jī)會(huì)實(shí)現(xiàn)進(jìn)一步的并行化。目前，現(xiàn)有的ArkUI的聲明式渲染后端的數(shù)據(jù)結(jié)構(gòu)已完成細(xì)粒度任務(wù)分離的基礎(chǔ)設(shè)計(jì)，我們也在同步分析相應(yīng)的場景，尤其是復(fù)雜的自定義布局、大量數(shù)據(jù)處理相關(guān)的場景， 研究基于場景優(yōu)先級(jí)統(tǒng)一調(diào)度的細(xì)粒度的異構(gòu)并行化的可行性以及潛在收益。

1.4.2無縫的聲明式2D/3D融合體驗(yàn)

3D具備酷炫的呈現(xiàn)效果以及全方位的交互體驗(yàn)。典型場景包括3D數(shù)字人，3D模型商品，3D動(dòng)效，以及重度依賴3D的VR（Virtual Reality）/AR（Augmented Reality）體驗(yàn)等。以電商為例，包括手淘，京東，以及新型平臺(tái)比如得物等，基于3D模型的高端商品展示和交互是其中非常重要的一環(huán)。然而，面向3D的應(yīng)用開發(fā)，存在以下幾點(diǎn)挑戰(zhàn)：

1）三方3D引擎ROM占用動(dòng)輒幾十兆起步，RAM占用動(dòng)輒百兆起步，資源負(fù)擔(dān)較重；

2）3D引擎相關(guān)的SDK基本都是命令式編程接口，同時(shí)領(lǐng)域技能要求較高，使用較為復(fù)雜；如果再涉及2D、3D融合編程，復(fù)雜度則進(jìn)一步提升；

3）盡管Apple和Google都提供了各自的3D的SDK，然而都還沒有和聲明式開發(fā)融合，開發(fā)者負(fù)擔(dān)較重，另外Apple和Google各自支持的標(biāo)準(zhǔn)和體驗(yàn)都不一樣，難以實(shí)現(xiàn)一致的跨平臺(tái)體驗(yàn)。這種情況下導(dǎo)致一些重度依賴3D的廠商甚至不采用操作系統(tǒng)提供的原生方案，通過自行開發(fā)跨平臺(tái)的相對輕量的3D方案，或者使用比較重度的三方3D引擎，以便降低3D相關(guān)的維護(hù)成本。但這樣的話，開發(fā)門檻則變得非常之高，難以進(jìn)一步推廣。

如果應(yīng)用框架層面能夠提供簡潔自然的聲明式3D開發(fā)，并實(shí)現(xiàn)輕量化的可按需加載的資源占用，以及跨OS平臺(tái)一致性的體驗(yàn)，個(gè)人認(rèn)為，就具備非常強(qiáng)的競爭力，實(shí)現(xiàn)開發(fā)效率和用戶體驗(yàn)的比較大的飛躍。

我們在這個(gè)領(lǐng)域持續(xù)在做相應(yīng)的探索和研究。目前，已初步實(shí)現(xiàn)了相應(yīng)的原型，包括輕量化的3D引擎，以及融合了聲明式UI的API設(shè)計(jì)和初步實(shí)現(xiàn)。

通過兩三行簡潔的聲明式代碼，就可以實(shí)現(xiàn)2D和3D內(nèi)容融合渲染，并初步做到3D模型的操控（旋轉(zhuǎn)、縮放等）。另外，在跨OS平臺(tái)方面，也初步實(shí)現(xiàn)了OpenHarmony以及Android平臺(tái)的一致性體驗(yàn)，以及在PC上的一致性預(yù)覽體驗(yàn)。

個(gè)人認(rèn)為這是非常重要的體驗(yàn)升級(jí)。我們會(huì)持續(xù)打磨相關(guān)的基礎(chǔ)功能，核心性能體驗(yàn)，以及按需加載的機(jī)制等關(guān)鍵特性。從中長期來看，后續(xù)會(huì)進(jìn)一步結(jié)合3D手勢交互，3D立體化音效，以及結(jié)合AR/VR相關(guān)算法和能力做進(jìn)一步完善和增強(qiáng)，實(shí)現(xiàn)更加真實(shí)自然的用戶體驗(yàn)。

1.4.3多設(shè)備場景下的UI智能構(gòu)建

不同業(yè)務(wù)場景下UI復(fù)雜多變，而且變更頻繁，相關(guān)的上層業(yè)務(wù)開發(fā)正逐步由組件化模塊化開發(fā)向無代碼的智能化開發(fā)轉(zhuǎn)變。

通過UX(User eXperience)設(shè)計(jì)工具直接生成相應(yīng)的UI代碼，并能夠在不同類型設(shè)備上的達(dá)成UI最佳適配（或可以提供實(shí)時(shí)反饋建議讓UX設(shè)計(jì)做相應(yīng)調(diào)整），可以極大提升相應(yīng)的開發(fā)以及業(yè)務(wù)部署效率。目前業(yè)界有部分UX設(shè)計(jì)到代碼的實(shí)現(xiàn)，但涵蓋的能力還相對有限，另外，如何進(jìn)一步轉(zhuǎn)換成不同設(shè)備的最佳適配，目前還沒有相對成熟的方案。

一個(gè)潛在的研究方向是結(jié)合聲明式UI框架，相應(yīng)的IDE(Integrated Development Environ-ment)，以及業(yè)界主流的UX設(shè)計(jì)工具，構(gòu)建聲明式UI和UX設(shè)計(jì)之間準(zhǔn)確的對應(yīng)關(guān)系，并可融合演進(jìn)，通過AI（Artificial Intelligence）等相關(guān)技術(shù)實(shí)現(xiàn)典型的UX設(shè)計(jì)場景到聲明式UI代碼的智能匹配，并能進(jìn)一步擴(kuò)展到多設(shè)備適配（主流的各種分辨率/大小的手機(jī)、折疊機(jī)、平板、車機(jī)，并逐步延伸到各類的智能IoT設(shè)備）；同步的，構(gòu)建高效的多設(shè)備的屏幕模擬&檢測算法，自動(dòng)模擬各類不同設(shè)備上的UX效果并識(shí)別有問題的場景，并給出相應(yīng)的建議或自動(dòng)修正。

1.4.4極簡Web運(yùn)行時(shí)

經(jīng)過幾十年的發(fā)展，W3C Web相關(guān)的標(biāo)準(zhǔn)在形成廣泛的應(yīng)用生態(tài)的同時(shí)，也面臨著標(biāo)準(zhǔn)以及相對應(yīng)的Web引擎越來越膨脹，難以進(jìn)一步優(yōu)化的問題-龐大的體積和資源占用，再加上性能體驗(yàn)也和原生應(yīng)用有較大差距，難以滿足萬物互聯(lián)場景下不同類型設(shè)備的需求。

W3C的Web/HTML5相關(guān)的標(biāo)準(zhǔn)是應(yīng)用生態(tài)的重要組成，也形成了非常廣泛和活躍的開發(fā)者社區(qū)。如果能夠進(jìn)一步解決好相關(guān)的標(biāo)準(zhǔn)以及性能體驗(yàn)問題，并能方便的部署到更多不同類型的設(shè)備上，對萬物互聯(lián)的跨設(shè)備的應(yīng)用生態(tài)可以起到重要的促進(jìn)作用。

傳統(tǒng)的Web引擎架構(gòu)由于歷史負(fù)擔(dān)太重，難以基于現(xiàn)有架構(gòu)實(shí)現(xiàn)較大的飛躍。需要另外一個(gè)角度-從Web標(biāo)準(zhǔn)子集和運(yùn)行時(shí)維度思考整體架構(gòu)的演進(jìn)和實(shí)現(xiàn)。

1）從標(biāo)準(zhǔn)維度，根據(jù)80/20法則(20%功能決定了80%的需求)，結(jié)合移動(dòng)端Web的典型場景，研究梳理出相應(yīng)的Web標(biāo)準(zhǔn)子集，滿足大多數(shù)典型場景的需求。

2）結(jié)合相應(yīng)的標(biāo)準(zhǔn)子集，設(shè)計(jì)和實(shí)現(xiàn)滿足該標(biāo)準(zhǔn)子集的極簡的高性能的跨平臺(tái)運(yùn)行時(shí)，并達(dá)成以下幾個(gè)關(guān)鍵目標(biāo)：

a. 基于Web標(biāo)準(zhǔn)子集范圍，可方便對接典型的Web前端框架/類小程序；

b. 跨平臺(tái)一致的渲染能力，以及對標(biāo)原生框架的性能內(nèi)存體驗(yàn) （典型場景性能內(nèi)存差異在5%-10%以內(nèi)）；

c. 極簡的資源占用（5M-10M以內(nèi)的包大小以及5M-10M以內(nèi)的基礎(chǔ)運(yùn)行時(shí)內(nèi)存），同時(shí)架構(gòu)上模塊解耦，功能可積木式組合以及按需部署和加載。

另外，可以結(jié)合標(biāo)準(zhǔn)化的WebAssembly（高效的語言中間格式和運(yùn)行時(shí)），以及WebGPU（高效的渲染API）實(shí)現(xiàn)更優(yōu)的應(yīng)用體驗(yàn)。

2、總結(jié)

本文分析了應(yīng)用框架尤其是移動(dòng)端應(yīng)用框架所面臨的挑戰(zhàn)，相應(yīng)的演進(jìn)，并結(jié)合萬物智聯(lián)場景下的應(yīng)用框架所需的關(guān)鍵要素（開發(fā)效率/性能體驗(yàn)/跨設(shè)備/跨平臺(tái)），給出了如何設(shè)計(jì)有競爭力的應(yīng)用框架的系統(tǒng)化思考。然后結(jié)合OpenHarmony新一代開發(fā)框架-ArkUI，展開說明其具體實(shí)踐以及演進(jìn)路徑。

我們從2019年開始構(gòu)思ArkUI（當(dāng)時(shí)的名字是ACE），到目前為止，ArkUI已支撐了運(yùn)動(dòng)手表，智能手表，智慧屏，手機(jī)，車機(jī)等多款產(chǎn)品，以及OpenHarmony設(shè)備上所有系統(tǒng)應(yīng)用和三方應(yīng)用。ArkUI通過系統(tǒng)化的方式，深度結(jié)合編程語言，編譯器以及相應(yīng)運(yùn)行時(shí)，圖形引擎，開發(fā)工具等相關(guān)的根技術(shù)聯(lián)合創(chuàng)新，逐步構(gòu)建具備可超越業(yè)界主流OS系統(tǒng)原生框架能力的核心底座，目標(biāo)三分天下有其一。這是一條充滿挑戰(zhàn)的路，但同時(shí)我堅(jiān)信，這是一條正確的路。期待更多的同行者加入，共創(chuàng)萬物智聯(lián)的新生態(tài)！

審核編輯：湯梓紅