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