深入解析ACE UI框架，帶你看懂UI渲染流程
UI 框架簡介以及業(yè)界發(fā)展趨勢
UI，即用戶界面，主要包含視覺(比如圖像、文字、動畫等可視化內容)以及交互(比如按鈕點擊、列表滑動、圖片縮放等用戶操作)。UI框架，則是為開發(fā)UI而提供的基礎設施，比如視圖布局，UI組件，事件響應機制等。
從操作系統(tǒng)平臺支持方式來看，UI框架一般可分為原生UI框架和跨平臺UI框架兩種。
1.原生UI框架。 一般是指操作系統(tǒng)自帶的UI框架，典型的例子包括iOS的UI Kit，Android的View框架等。這些UI框架和操作系統(tǒng)深度綁定，一般只能運行在相應的操作系統(tǒng)上。功能，性能，開發(fā)調測等方面和相應的操作系統(tǒng)結合較好。
2.跨平臺UI框架。 一般是指可以在不同的平臺(OS)上運行的獨立的UI框架。典型例子包括HTML5以及基于HTML5延伸出來的前端框架React Native， 以及Google 的Flutter等?？缙脚_UI框架的目標是代碼只需一次編寫，經過少量修改甚至不修改，可以部署到不同的操作系統(tǒng)平臺上。當然，實現(xiàn)跨平臺也是有代價的，由于不同平臺存在差異性(比如UI的呈現(xiàn)方式差異，API差異等等)，導致UI框架本身的架構實現(xiàn)，以及和不同平臺的融合都有不小的挑戰(zhàn)。
從編程方式上來看，UI框架一般可分為命令式UI框架和聲明式UI框架兩種：
1.命令式UI框架，過程導向 ——告訴“機器”具體步驟，命令“機器”按照指定步驟去做。比如Android原生UI框架(View框架)或iOS的UIKit，提供了一系列的API讓開發(fā)者直接操控UI組件-比如定位到某個指定UI組件，進行屬性變更等。這種方式的優(yōu)點是開發(fā)者可以控制具體的實現(xiàn)路徑，經驗豐富的開發(fā)者能夠寫出較為高效的實現(xiàn)。不過這種情況下，開發(fā)者需了解大量的API細節(jié)并指定好具體的執(zhí)行路徑，開發(fā)門檻較高。具體的實現(xiàn)效果上，也高度依賴開發(fā)者本身的開發(fā)技能。另外，由于和具體實現(xiàn)綁定較緊，在跨設備情況下，靈活性和擴展性相對有限。
2.聲明式UI框架，結果導向—— 告訴“機器”你需要什么，“機器”負責怎么去做。比如Web前端框架Vue,或iOS的SwiftUI等，框架會根據(jù)聲明式語法的描述，渲染出相應的UI，同時結合相應編程模型，框架會根據(jù)數(shù)據(jù)的變化來自動更新相應的UI。
這種方式的優(yōu)點是開發(fā)者只需描述好結果，相應的實現(xiàn)和優(yōu)化由框架來處理。另外，由于結果描述和具體實現(xiàn)分離，實現(xiàn)方式相對靈活同時容易擴展。不過這種情況下，對框架的要求較高，需要框架有完備的直觀的描述能力并能夠針對相應的描述信息實現(xiàn)高效的處理。
UI框架是應用開發(fā)的核心組成部分?？v觀業(yè)界UI框架，其主要發(fā)展趨勢表現(xiàn)為：
從命令式UI往聲明式UI發(fā)展
比如iOS中的UIKit到SwiftUI, Android中的View到Jetpack Compose。這樣可以實現(xiàn)更加直觀便捷的UI開發(fā)。
UI框架和語言運行時深度融合
SwiftUI，Jetpack Compose， Flutter都利用了各自的語言特性——比如在UI描述方面，SwiftUI中的Swift語言,Jetpack Compose中的Kotlin語言都精簡了UI描述語法;在性能方面， Swift通過引入輕量化結構體等語言特性更好的實現(xiàn)內存快速分配和釋放，F(xiàn)lutter中Dart語言則在運行時專門針對小對象內存管理做相應優(yōu)化等。
跨平臺(OS)能力
跨平臺(OS)能力可以讓一套代碼復用到不同的OS上，主要是為了提升開發(fā)效率，降低開發(fā)成本。不過這里面也有一系列的挑戰(zhàn)，比如運行在不同平臺上的性能問題，能力和渲染效果的一致性問題等。業(yè)界在這方面也是不斷的演進，主要有幾種方式：
1.JS/Web方案。 比如HTML5利用JS/Web的標準化生態(tài)，通過相應的Web引擎實現(xiàn)跨平臺目標;
2.JS+Native混合方式。 比如React Native、Weex等,結合JS橋接到原生UI組件的方式實現(xiàn)了一套應用代碼能夠運行到不同OS上;
3.平臺無關的UI自繪制能力+新的語言。 比如Flutter，整個UI基于底層畫布由框架層來繪制，同時結合Dart語言實現(xiàn)完整的UI框架。Flutter從設計之初就是將跨平臺能力作為重要的競爭力去吸引更多的開發(fā)者;
另外，有趣的是，部分原生開發(fā)框架也開始往跨平臺演進。比如，Android原生的開發(fā)框架Jetpack Compose也開始將跨OS支持作為其中的目標，計劃將Compose拓展到桌面平臺，比如Windows,MacOS等。
然而，隨著智能設備的普及，多設備場景下，設備的形態(tài)差異(屏幕大小、分辨率，形狀, 交互模式等)，設備的能力差異(從百K級內存到G級內存設備等)以及應用需要在不同設備間協(xié)同，這些都對UI框架以及應用開發(fā)帶來了新的挑戰(zhàn)。
為什么要重新設計一個ACE UI框架
ACE全稱是Ability Cross-platform Environment (元能力跨平臺執(zhí)行環(huán)境)。是華為設計的應用在HarmonyOS上的UI框架。ACE UI框架結合HarmonyOS的基礎運行單元Ability，語言和運行時，以及各種平臺(OS)能力API等共同構成HarmonyOS應用開發(fā)的基礎，實現(xiàn)了跨設備分布式調度，以及原子化服務免安裝等能力。
ACE提供兩種開發(fā)語言以供不同開發(fā)者進行選擇，分別為Java語言和JavaScript語言，其中Java僅支持在內存較大的設備上使用如大屏、手機、平板等設備使用，而JavaScript支持在百K級到G級設備上使用。
目前主流的UI框架都有各自的不足。另外，在多設備場景下，由于不同的設備形態(tài)以及設備能力的巨大差異，目前業(yè)界還沒有任何一個UI框架能夠較好的解決相應的問題。
而ACE UI框架的整體設計思路是：
1. 建立分層機制，引入高效的UI基礎后端，并能夠與OS平臺解耦，形成一致化的UI體驗
2. 通過多前端的方式擴展應用生態(tài)，并結合聲明式UI，在開發(fā)效率上持續(xù)演進
3. 框架層統(tǒng)一結合語言以及運行時，分布式，組件化設計等，圍繞跨設備，進一步提升體驗
ACE將應用的UI界面進行解析，通過創(chuàng)建后端具體UI組件、進行布局計算、資源加載等處理后生成具體繪制指令，并將繪制命令發(fā)送給渲染引擎，渲染引擎將繪制指令轉換為具體屏幕像素，最終通過顯示設備將應用程序轉換為可見的界面效果展示給用戶。
ACE UI框架的整體架構如下圖所示，主要由前端框架層、橋接層、引擎層和平臺抽象層四大部分組成，下面我們一一介紹。
1.前端框架層
該層主要包括相應的開發(fā)范式(比如主流的類Web開發(fā)范式)，組件/API，以及編程模型MVVM(Model-View-ViewModel)。其中Model是數(shù)據(jù)模型層，代表了從數(shù)據(jù)源讀取到的數(shù)據(jù);View是視圖UI層，通過一定的形式把系統(tǒng)中的數(shù)據(jù)向用戶呈現(xiàn)出來;ViewModel: 視圖模型層，是數(shù)據(jù)和視圖之間的橋梁。它雙向綁定了視圖和數(shù)據(jù)，使得數(shù)據(jù)的變更能夠及時在視圖上呈現(xiàn)，用戶在視圖上的修改也能夠及時傳遞給后臺數(shù)據(jù)，從而實現(xiàn)數(shù)據(jù)驅動的UI自動變更。
開發(fā)范式可以擴展，來支持生態(tài)發(fā)展。不同的開發(fā)范式可以統(tǒng)一適配到底層的引擎層
2.橋接層
該層主要是作為一個中間層，實現(xiàn)前端開發(fā)范式到底層引擎(包括UI后端，語言&運行時)的對接。
3.引擎層
該層主要包含兩部分：UI后端引擎和語言執(zhí)行引擎。
a.由C++構建的UI后端引擎，包括UI組件、布局視圖、動畫事件、自繪制渲染管線和渲染引擎 。
在渲染方面，我們盡可能把這部分組件設計得小而靈活。這樣的設計，為不同前端框架提供靈活的UI能力，這部分通過C++組件組合而成。通過底層組件的按需組合，布局計算和渲染并行化，并結合上層開發(fā)范式實現(xiàn)了視圖變化最小化的局部更新機制，從而實現(xiàn)高效的UI渲染。
除此之外，引擎層還提供了組件的渲染管線、動畫、主題、事件處理等基礎能力。目前復用了Flutter引擎提供基礎的圖形渲染能力、字體管理、文字排版等能力，底層使用Skia或其他圖形庫實現(xiàn)，并通過OpenGL實現(xiàn)GPU硬件渲染加速。
在多設備UI適配方面，通過多種原子化布局能力(自動折行、隱藏、等比縮放等)，多態(tài)UI控件(描述統(tǒng)一，表現(xiàn)形式多樣)，以及統(tǒng)一交互框架(不同的交互方式歸一到統(tǒng)一的事件處理)來滿足不同設備的形態(tài)差異化需求。
另外，引擎層也包含了能力擴展基礎設施，來實現(xiàn)自定義組件以及系統(tǒng)API的能力擴展
b.語言&運行時執(zhí)行引擎。 可根據(jù)需要切換到不同的運行時執(zhí)行引擎，滿足不同設備的能力差異化需求。
4.平臺抽象層
該層主要是通過平臺抽象，將平臺依賴聚焦到底層畫布，通用線程以及事件機制等少數(shù)必要的接口上，為跨平臺打造了相應的基礎設施，并能夠實現(xiàn)一致化UI渲染體驗。
相應的，配套的開發(fā)者工具(HUAWEI DevEco Studio)結合ACE UI的跨平臺渲染基礎設施，以及自適應渲染，可做到和設備比較一致的渲染體驗以及多設備上的UI實時預覽。
另外，ACE UI框架還設計了可伸縮的架構，即前端框架、語言運行時、UI后端等都做了解耦，可以有不同的實現(xiàn)。這樣就具備可部署到百K級內存的輕量級設備的能力，如下所示：
在ACE UI的輕量化實現(xiàn)中，通過前端框架核心下沉C++ 化，減小JS部分的內存占用，使用C++ 進行更為嚴格的內存分配與管理，并且采用更為輕量的JS引擎，UI部分采用輕量的UIKit并結合輕量圖形引擎，達到內存非常輕量占用的目標。接口能力保證是全量能力的子集，這樣可以保證輕量化設備上可執(zhí)行的應用，可以在更高等級的設備上執(zhí)行，而無需重新開發(fā)。這也就是采用ACE JS開發(fā)范式的優(yōu)勢所在，采用統(tǒng)一的開發(fā)范式進行應用開發(fā)后，開發(fā)者無需關心具體運行時的前端框架、JS引擎與后端UI組件，根據(jù)運行平臺不同，采用最佳的模塊，保障了應用在不同平臺都可具有最佳的運行性能。不過由于輕量級設備上的資源限制， 所支持的API 能力相對有限，但公共部分的API是完全共通的。
綜上所述，ACE UI框架具備如下特點：
支持主流的語言生態(tài) – JavaScript;
支持類Web開發(fā)范式， MVVM機制。并在架構上可支持多前端開發(fā)范式，進一步簡化開發(fā);
通過統(tǒng)一的UI后端，實現(xiàn)高性能以及跨平臺一致化的渲染體驗;
通過多態(tài)UI、原子化布局、統(tǒng)一交互，以及可伸縮的運行時設計，進一步降低不同設備形態(tài)下的UI開發(fā)門檻，并能夠通過統(tǒng)一的開發(fā)范式，實現(xiàn)一套代碼跨設備部署(覆蓋百K級到G級內存設備)。
ACE UI框架渲染流程解析
接下來我們通過一個手機側ACE JS應用渲染流程的完整流程來介紹ACE UI框架的具體渲染技術。
1.線程模型
ACE JS應用啟動時會創(chuàng)建一系列線程，形成獨立的線程模型，以實現(xiàn)高性能的渲染流程。
每個ACE JS應用的進程，包含唯一一個Platform線程和若干后臺線程組成的異步任務線程池：
- Platform線程： 當前平臺的主線程，也就是應用的主線程，主要負責平臺層的交互、應用生命周期以及窗口環(huán)境的創(chuàng)建
- 后臺線程池： 一系列后臺任務，用于一些低優(yōu)先級的可并行異步任務，如網(wǎng)絡請求、Asset資源加載等。除此之外，每個實例還包括一系列專有線程
- JS線程： JS前端框架的執(zhí)行線程，應用的JS邏輯以及應用UI界面的解析構建都在該線程執(zhí)行
- UI線程： 引擎的核心線程，組件樹的構建以及整個渲染管線的核心邏輯都在該線程：包括渲染樹的構建、布局、繪制以及動畫調度
- GPU線程： 現(xiàn)代的渲染引擎，為了充分發(fā)揮硬件性能，都支持GPU硬件加速，在該線程上，會通過系統(tǒng)的窗口句柄，創(chuàng)建GPU加速的OpenGL環(huán)境，負責將整個渲染樹的內容光柵化，直接將每一幀的內容渲染合成到該窗口的Surface上并送顯
- IO線程： 主要為了異步的文件IO讀寫，同時該線程會創(chuàng)建一個離屏的GL環(huán)境，這個環(huán)境和 GPU線程的GL環(huán)境是同一個共享組，可以共享資源，圖片資源解碼的內容可直接在該線程上傳生成GPU紋理，實現(xiàn)更高效的圖片渲染
每個線程的作用，在后續(xù)的渲染流程中還會進一步提到。
2.前端腳本解析
ACE UI框架支持不同的開發(fā)范式，可以對接到不同的前端框架上。
以類Web開發(fā)范式為例，開發(fā)者開發(fā)的應用，通過開發(fā)工具鏈的編譯，會生成引擎可執(zhí)行的Bundle文件。應用啟動時，會將Bundle文件在JS線程上進行加載，并且將該內容作為輸入，供JS引擎進行解析執(zhí)行，最終生成前端組件的結構化描述，并建立數(shù)據(jù)綁定關系。例如包含若干簡單文本的應用會生成類似下圖的樹形結構，每個組件節(jié)點會包含該節(jié)點的屬性及樣式信息。
3.渲染管線構建
如上圖，前端框架的解析后，根據(jù)具體的組件規(guī)范定義向前端框架對接層請求創(chuàng)建ACE渲染引擎提供的組件。
前端框架對接層 通過ACE引擎層提供的Component組件實現(xiàn)前端組件定義的能力。Component是一個由C++ 實現(xiàn)的UI組件的聲明式描述，描述了UI組件的屬性及樣式，用于生成組件的實體元素。每一個前端組件會對接到一個Composed Component，表示一個組合型的UI組件，通過不同的子Component組合，構造出前端對應的Composed組件。每個Composed組件是前后端對接的一個基礎的更新單位。
以上面的前端組件樹為例，每個節(jié)點會使用一組Composed組件進行組合描述，對應關系如下圖，該對應關系只是一個示例，實際場景的對應關系可能會更復雜。
有了每個前端節(jié)點對應的Component，就形成了一個完成Page的描述結構，通知渲染管線掛載新的頁面。
在Page掛載之前，渲染管線已經提前創(chuàng)建了幾個關鍵的核心結構，Element樹和Render樹：
Element樹， Element是Component的實例，表示一個具體的組件節(jié)點，它形成的Element樹負責維持界面在整個運行時的樹形結構，方便計算局部更新算法。另外對于一些復雜的組件，在該數(shù)據(jù)結構上會實現(xiàn)一些對子組件邏輯上的管理。
Render樹， 對于每個可顯示的Element都會為其創(chuàng)建對應的RenderNode，它負責一個節(jié)點的顯示信息，它形成的Render樹維護著整個界面的渲染需要用到的信息，包括它的位置、大小、繪制命令等，界面后續(xù)的布局、繪制都是在Render樹上進行的。
當應用啟動時，最初形成的Element樹只有幾個基礎的幾節(jié)點，一般包括root、overlay、stage，分別作用如下：
RootElement： Element樹的根節(jié)點，僅僅負責全局背景色的繪制
OverlayElement： 一個全局的懸浮層容器，用于彈窗等全局繪制場景的管理
StageElement： 一個Stack容器，作為全局的“舞臺”，每個加載完成的頁面都要掛載到這個“舞臺”下，它管理應用的多個頁面之間的轉場動效等。
在Element樹創(chuàng)建的過程中，也會同步的把Render樹也創(chuàng)建起來，初始狀態(tài)如下圖：
當前端框架對接層通知渲染管線準備好了頁面，在下一個幀同步信號(VSync)到來時，就會在渲染管線上進行頁面的掛載，具體流程就是通過Component來實例化生成Element的過程，創(chuàng)建成功的Element同步創(chuàng)建對應的RenderNode：
如上圖所示，目標要將整個Page的Component描述掛載到StageElement上，如果當前Stage下還未有任何Element節(jié)點，就會遞歸逐個節(jié)點生成Component對應的Element節(jié)點。對于組合類型的ComposedElement，則同時會把Element的引用記錄到一個Composed Map中，方便后續(xù)更新時快速查找。對于可見類型的容器節(jié)點或渲染節(jié)點，則會創(chuàng)建對應的RenderNode，并掛在Render樹上。
當生成了當前頁面的Element樹和Render樹，頁面渲染構建的完整過程就結束了。
4.布局繪制機制
接下來就進入了布局和繪制的階段，布局和繪制都是在Render樹上進行的。每個RenderNode都會實現(xiàn)自己的布局算法和繪制方法。
布局
布局的過程就是通過各類布局的算法計算出每個RenderNode在相對空間上的真實大小和位置。
如下圖所示，當某個節(jié)點的內容發(fā)生變化時，就會標記自己為needLayout，并一直向上標記到布局邊界(ReLayout Boundary)，布局邊界是重新布局的一個范圍標記，一般情況下，如果一個節(jié)點的布局參數(shù)信息(LayoutParam)是強約束的，例如它布局期望的最大尺寸和最小尺寸是相同的，那么它就可以作為一個布局邊界。布局是個深度優(yōu)先遍歷的過程。從布局邊界開始，父節(jié)點自頂向下將LayoutParam傳給子節(jié)點，子節(jié)點自底向上據(jù)此計算得到尺寸大小和位置。
對于每個節(jié)點來說，布局分為三個步驟：
① 當前節(jié)點遞歸調用子節(jié)點的layout方法，并傳遞布局的參數(shù)信息(LayoutParam)，包含了布局期望的最大尺寸和最小尺寸等;
② 子節(jié)點根據(jù)布局參數(shù)信息，使用自己定義的布局算法來計算自己的尺寸大小;
③ 當前節(jié)點獲取子節(jié)點布局后的大小，再根據(jù)自己的布局算法來計算每個子節(jié)點的位置信息，并將相對位置設置給子節(jié)點保存。
根據(jù)上述的流程，一次布局遍歷完成后，每個節(jié)點的大小和位置就都計算出來了，可以進行下一步的繪制。
繪制
同布局一樣，繪制也是一個深度遍歷的過程，遍歷調用每個RenderNode的Paint方法，此時的繪制只是根據(jù)布局算出來的大小和位置，在當前繪制的上下文記錄每個節(jié)點的繪制命令。
為什么是記錄命令，而不是直接繪制渲染呢?在現(xiàn)代的渲染引擎中，為了充分使用GPU硬件加速的能力，一般都會使用DisplayList的機制，繪制過程中僅僅將繪制的命令記錄下來，在GPU渲染的時候統(tǒng)一轉成OpenGL的指令執(zhí)行，能最大限度的提高圖形的處理效率。所以在上面提到的繪制上下文中，會提供一個可以記錄繪制命令的畫布(Canvas)。每一個獨立的繪制上下文可以看作是一個圖層。
為了提高性能，這里引入了圖層(Layer)的概念。通常繪制會將渲染內容分為多個層進行加速。對于會頻繁變化的內容，將其單獨創(chuàng)建一個圖層，那么這個獨立圖層的頻繁刷新就不必導致其他內容重新繪制，從而達到提升性能并減少功耗的效果，同時還可以支持GPU緩存等優(yōu)化。每個RenderNode都可以決定自己是否需要單獨分層。
如下圖所示，繪制流程會從需要繪制的節(jié)點中，挑選最近的且需要分層的節(jié)點開始，自頂向下的執(zhí)行每個節(jié)點的Paint方法。
對每個節(jié)點，繪制分為四個步驟：
① 如果當前節(jié)點需要分層，那么需要創(chuàng)建一個新的繪制上下文，并提供可以記錄繪制命令的畫布;
② 在當前的畫布上記錄背景的繪制命令;
③ 遞歸調用子節(jié)點的繪制方法，記錄子節(jié)點的繪制命令;
④ 在當前的畫布上記錄前景的繪制命令。
一次完整的繪制流程結束后，我們會得到一棵完整的Layer樹，Layer樹上包含了這一幀完整的繪制信息：包括每一層的位置、transform信息、Clip信息、以及每個元素的繪制命令。下一步就要經過光柵化和合成的過程，將這一幀的內容顯示到界面。
5.光柵化合成機制
在上面的繪制流程結束后，會通知GPU線程開始進行合成的流程。
如上圖所示，UI線程(UI Thread)在渲染管線中的輸出是LayerTree，它相當于一個生產者，將生產的LayerTree添加到渲染隊列中。GPU線程(GPU Thread)的合成器(Compositor)相當于消費者，每個新的渲染周期中，合成器會從渲染隊列中獲取一個LayerTree進行合成消費。
對于需要緩存的Layer,還要執(zhí)行光柵化生成GPU紋理，所謂光柵化就是將Layer里面記錄的命令進行回放，生成每個實體的像素的過程。像素是存儲在紋理的圖形內存中。
合成器會從系統(tǒng)的窗口中獲取當前的Surface，將每個Layer生成的紋理進行合成，最終合成到當前Surface的圖形內存(Graphic Buffer)中。這塊內存中存儲的就是當前幀的渲染結果內容。最終還需要將渲染結果提交到系統(tǒng)合成器中合成顯示。系統(tǒng)的合成過程如下圖所示：
當GPU線程的合成器完成一幀的合成后，會進行一次SwapBuffer的操作，將生成的Graphic Buffer提交到與系統(tǒng)合成器建立的幀緩沖隊列(Buffer Queue)中。系統(tǒng)合成器會從各個生產端獲取最新的內容進行最終的合成，以上圖為例，系統(tǒng)合成器會將當前應用的內容和系統(tǒng)其它的顯示內容，例如System UI的狀態(tài)欄、導航欄，進行一次合成，最終寫入到屏幕對應的幀緩沖區(qū)(Frame Buffer)中。液晶屏的驅動就會從緩沖區(qū)讀取內容進行屏幕的刷新，最終將內容顯示到屏幕上。
6.局部更新機制
經過上面1~5的流程，完成了首次完整的渲染的流程，在后續(xù)的運行中，例如用戶輸入、動畫、數(shù)據(jù)改變都有可能造成頁面的刷新，如果只是部分元素發(fā)生了變化，并不需要全局的刷新，只需要啟動局部更新即可。那么局部更新是怎么做到的?下面我們介紹一下局部 更新的流程。
以上圖為例，JS在代碼中更新了數(shù)據(jù)，通過數(shù)據(jù)綁定模塊會自動觸發(fā)前端組件屬性的更新，然后通過JS引擎異步發(fā)起更新屬性的請求。前端組件會根據(jù)變更的屬性，構建一組新的Composed的補丁(Patch)，作為渲染管線更新的輸入。
如上圖所示，在下一個VSync到來時，渲染管線會在UI線程開始更新的流程。通過Composed補丁的Id，在ComposedMap中查詢到對應的ComposedElement在Element樹上的位置。通過補丁對Element樹進行更新。以ComposedElement為起始，逐層進行對比，如果節(jié)點類型一致則直接更新對應屬性和對應的RenderNode，如果不一致則重新創(chuàng)建新的Element和RenderNode。并將相關的RenderNode標記為needLayout和needRender。
如上圖所示，根據(jù)標記需要重新布局和重新渲染的RenderNode，從最近的布局邊界和繪制圖層進行布局和繪制的流程，生成新的Layer樹，只需要重新生成變更RenderNode對應的Layer即可。
如上圖所示，接下來，根據(jù)刷新后的Layer樹作為輸入，在GPU線程進行光柵化和合成。對于已經緩存的Layer則不需要重新光柵化，合成器只需要將已緩存的Layer和未緩存或更新的Layer重新合成即可。最終經過系統(tǒng)合成器的合成，就會將新一幀的內容顯示。
以上就是一個ACE JS應用的渲染及更新的流程。最后，通過兩張流程圖回顧一下整體的流程：
了解完ACE JS應用的渲染及更新的流程，如果大家想了解更多關于HarmonyOS UI框架如何解決設備形態(tài)差異帶來的開發(fā)挑戰(zhàn)和應用示例，可參考我們之前推出的內容：
ACE UI框架目前的成熟度以及演進
截至目前，ACE UI框架已商用落地了華為運動手表，華為智能手表，華為智慧屏，華為手機，華為平板等一系列產品。使用場景包括日歷、出行、健身、實用工具等各類應用，手機-設備碰一碰全品類的應用，以及今年六月份發(fā)布的HarmonyOS中各類的服務卡片-圖庫、相機等。另外，在開發(fā)調測方面，開發(fā)者工具(HUAWEI DevEco Studio)中也集成了ACE UI框架，支持在PC端(MacOS，Windows)上的開發(fā)調測，實時預覽(包括實時多設備預覽，組件級預覽，雙向預覽等)，實現(xiàn)了在PC上和設備上一致的渲染體驗。
未來，面向開發(fā)者的極簡開發(fā)，面向消費者的流暢酷炫的體驗，以及能夠高效在不同設備不同平臺上部署，ACE UI框架會繼續(xù)沿著精簡開發(fā)和高性能兩個方面演進，結合語言更進一步簡化開發(fā)范式，結合運行時在跨語言交互，類型優(yōu)化等方面進一步增強性能體驗，結合分布式能力將編程模型從MVVM演進到分布式MVVM(Distributed Model-View-ViewModel)等。采用類自然語言的聲明式UI描述進行界面搭建，編程語言也進一步開放，未來考慮向TS進行演進，從動效、布局和性能方面進一步提升用戶使用體驗。
當然，應用生態(tài)還會涉及更多的方面，比如三方插件的繁榮，跨OS平臺的擴展，更具創(chuàng)新的分布式體驗等等。ACE UI框架還很年輕，期待和眾多開發(fā)者一起，重點圍繞著多設備組成的超級終端的新興場景，不斷打磨完善，共同構建領先的應用體驗和生態(tài)!
