HarmonyOS應(yīng)用點擊響應(yīng)時延優(yōu)化指導(dǎo)

在HarmonyOS應(yīng)用生態(tài)高速發(fā)展的背景下，雖然移動設(shè)備的硬件運算性能已經(jīng)達到了新的高度，但與此同時應(yīng)用研發(fā)者也設(shè)計出更加多元化、智能化的產(chǎn)品，展現(xiàn)樣式百花齊放，這些產(chǎn)品對高性能的需求與日俱增，加上同類型相近功能的產(chǎn)品互相競爭，用戶也會對App產(chǎn)品質(zhì)量的要求越來越高，對響應(yīng)速度的要求也愈加嚴格。本文介紹在HarmonyOS應(yīng)用中，對應(yīng)用點擊響應(yīng)時延進行優(yōu)化的各種方法思路。

優(yōu)化指導(dǎo)

為了保障應(yīng)用操作響應(yīng)及時，看護用戶極致流暢體驗，開發(fā)者需要分析從手勢抬手到渲染上屏這段時間應(yīng)用做了哪些耗時的操作，進而針對性地優(yōu)化相關(guān)邏輯。點擊響應(yīng)優(yōu)化是指通過分析響應(yīng)階段、優(yōu)化應(yīng)用性能、加快點擊后頁面的響應(yīng)速度，使用戶可以得到流暢的操作體驗。

圖1 點擊響應(yīng)起止點示意圖

（一）UI優(yōu)化

應(yīng)用開發(fā)中的用戶界面UI（User Interface）是用戶與應(yīng)用程序交互的關(guān)鍵部分。使用不同類型的布局，能在界面顯示上達到預(yù)期效果，甚至某些方式能將頁面排布得更加美觀，但也容易引入不合理的結(jié)構(gòu)問題，如果UI界面中存在過度的布局計算，冗余的元素繪制，將會帶來設(shè)備資源的大量開銷，造成響應(yīng)性能的衰退。

減少嵌套層級

布局的嵌套層次過深會導(dǎo)致在創(chuàng)建節(jié)點及進行布局時耗費更多時間。因此開發(fā)者在開發(fā)時，應(yīng)避免冗余的嵌套，并盡量使用扁平化布局來優(yōu)化嵌套層級。

具體內(nèi)容見《精簡節(jié)點數(shù)》和《合理使用布局組件》。

減少渲染時間

if/else條件渲染是ArkUI應(yīng)用開發(fā)框架提供的渲染控制能力，可根據(jù)應(yīng)用的不同狀態(tài)，渲染對應(yīng)分支下的UI描述。

具體內(nèi)容見合理使用渲染控制語法。

用renderGroup緩存動效

頁面響應(yīng)時，可能大量使用屬性動畫和轉(zhuǎn)場動畫，當復(fù)雜度達到一定程度之后，就有可能出現(xiàn)卡頓的情況。renderGroup是組件通用方法，它代表了渲染繪制的一個組合。

具體原理是在首次繪制組件時，若組件被標記為啟用renderGroup狀態(tài)，將對組件及其子組件進行離屏繪制，將繪制結(jié)果合并保存到緩存中。此后當需要重新繪制相同組件時，就會優(yōu)先使用緩存而不必重新繪制了，從而降低繪制負載，進而加快響應(yīng)速度。

圖2 renderGroup使用場景示例

為了能使renderGroup功能生效，有以下限制條件：

組件內(nèi)容固定不變：組件及其子組件各屬性保持固定，不發(fā)生變化。如果組件內(nèi)容不是固定的，也就是說其子組件中存在某些屬性變化或者樣式變化，此時如果使用renderGroup，那么緩存的利用率將大大下降，并且有可能需要不斷執(zhí)行緩存更新邏輯，在這種情況下，不僅不能優(yōu)化卡頓效果，甚至還可能使卡頓惡化。例如：文本內(nèi)容使用雙向綁定的動態(tài)數(shù)據(jù)；圖片資源使用gif格式；使用video組件播放視頻。

子組件無動效：由組件統(tǒng)一應(yīng)用動效，其子組件均無動效。如果子組件上也應(yīng)用動效，那么子組件相對父組件就不再是靜止的，每一幀都有可能需要更新緩存，更新邏輯同樣需要消耗系統(tǒng)資源。

LazyForEach懶加載

使用LazyForEach懶加載替換ForEach，避免像ForEach那樣一次性初始化和加載所有元素，從而使首幀繪制時創(chuàng)建列表元素時間大大減少，提升響應(yīng)性能表現(xiàn)。

相關(guān)原理及案例參考《優(yōu)化長列表加載慢丟幀問題》。

動態(tài)import

動態(tài)import是一種模塊加載機制，允許應(yīng)用程序在運行時按照實際需求去加載相關(guān)模塊。在某些條件滿足時（比如用戶交互時，或ABTest分支切換時）再加載特定模塊，可以減少初始化import的加載時間和資源消耗，這將有助于提高應(yīng)用程序的內(nèi)存性能和響應(yīng)速度。

與靜態(tài)import不同，動態(tài)import僅在需要時才消耗CPU等資源；相比靜態(tài)import在編譯時就確定了引入的所有模塊，動態(tài)import還有更佳的語法靈活性，借助這種靈活，能夠?qū)崿F(xiàn)代碼和路由級別的粒度分割，優(yōu)化模塊層次的懶加載性能。

具體的使用場景和實現(xiàn)方案參考《動態(tài)import》。

（二）并發(fā)優(yōu)化

并發(fā)是指多個任務(wù)在同一個時間段內(nèi)同時觸發(fā)執(zhí)行，具體邏輯中使用多線程異步執(zhí)行，與之相對的概念是串行任務(wù)，按順序同步執(zhí)行。

應(yīng)用中的并發(fā)優(yōu)化就是在響應(yīng)用戶操作期間，盡可能地讓主線程只執(zhí)行UI繪制相關(guān)的任務(wù)，而將非UI的耗時任務(wù)分配給其他線程或者延遲處理。這樣借助多線程的異步技術(shù)，充分利用多核處理器的能力，提高應(yīng)用程序的并發(fā)處理能力，減少用戶等待時間，保證用戶界面的響應(yīng)流暢性。

異步任務(wù)并發(fā)處理

使用多線程并發(fā)能力進行開發(fā)的過程中，主要實現(xiàn)方式有：

利用TaskPool執(zhí)行簡單并行任務(wù)：將一些耗時的操作放入異步任務(wù)中處理，避免阻塞主線程，提升應(yīng)用的響應(yīng)速度；

利用Worker完成周期類耗時操作：Worker可以空跑在后臺等待事件觸發(fā)，周期觸發(fā)耗時操作使用Worker，這樣可以避免TaskPool頻繁拉起影響性能。

二者原理和效果差異可參考《TaskPool和Worker的對比實踐》。

使用組件異步加載特性

Image組件支持異步加載特性：當應(yīng)用在頁面上展示一批圖片的時候，會先顯示空白占位塊，當圖片在其他線程加載完畢后，再替換占位塊。這樣圖片加載就可以不阻塞頁面的顯示，給用戶帶來良好的交互體驗。

相應(yīng)的，如果展示圖片數(shù)目很少，或加載本地圖片，耗時明顯較少時，這時建議配置syncLoad屬性為true，使圖片同步加載，避免特定情況下圖片加載出現(xiàn)的閃爍。

（三）代碼邏輯優(yōu)化

代碼邏輯的優(yōu)劣對應(yīng)用響應(yīng)速度的影響是比較明顯的，特別是點擊切換后新頁面中的aboutToAppear、onPageShow等生命周期回調(diào)，以及點擊操作頁面中的aboutToDisappear等，需要充分優(yōu)化代碼、減少冗余、避免耗時，提升執(zhí)行效率。

基于平臺SDK的開發(fā)框架下，對App生命周期的理解，可以幫助開發(fā)人員識別程序在不同階段的行為，弄清楚不同形態(tài)轉(zhuǎn)換時觸發(fā)的接口性質(zhì)、各函數(shù)被調(diào)用的頻率，進而挖掘出代碼優(yōu)化的方向。

下圖是頁面及自定義組件的生命周期流程：

圖3 生命周期流程

通?？梢圆捎玫倪壿媰?yōu)化方法有：

選擇合適的數(shù)據(jù)結(jié)構(gòu) 索引存取考慮使用array數(shù)組，hash查找考慮使用map，去重邏輯考慮使用set等； 有時開發(fā)者使用object變量作為容器去處理map的邏輯，可以考慮使用ArkTS提供的高性能容器類，直接使用HashMap； 遇到純數(shù)值計算的場合，推薦使用TypedArray的數(shù)據(jù)結(jié)構(gòu)，比如Int8Array、Int32Array、Float32Array、BigInt64Array等。

合理使用緩存 當某些運算結(jié)果會反復(fù)使用時，以空間換時間，提前緩存以便于下次調(diào)用。

注意對象new和delete的頻率 new和delete可能會觸發(fā)內(nèi)存管理回收，占用CPU資源從而影響界面渲染的能力，需要根據(jù)情況調(diào)整其頻次。尤其在循環(huán)代碼中，頻繁的new、delete更會帶來惡化的性能表現(xiàn)，應(yīng)該盡量將new/delete優(yōu)化到循環(huán)外去處理。

延遲執(zhí)行資源釋放操作 將資源關(guān)閉和釋放操作放在setTimeout函數(shù)中執(zhí)行，使其延遲到系統(tǒng)相對空閑的時刻進行，可以避免在程序忙碌時段占用關(guān)鍵資源，提升整體性能及響應(yīng)能力。具體的使用場景和實現(xiàn)方案參考《延遲執(zhí)行資源釋放操作》。

減小拖動識別距離

應(yīng)用識別拖動手勢事件時需要設(shè)置合理的拖動距離，設(shè)置不合理的拖動距離會導(dǎo)致滑動不跟手、響應(yīng)時延慢等問題。針對此類問題可以通過設(shè)置distance大小來解決。具體的使用場景和實現(xiàn)方案參考《減小拖動識別距離》。

（四）視覺感知優(yōu)化

上述幾節(jié)內(nèi)容，是從減少時延絕對值的角度來提升響應(yīng)體驗，而視覺感知優(yōu)化則是通過交互設(shè)計的優(yōu)化，提升用戶響應(yīng)速度的感知。

從響應(yīng)速度的反面角度來講，應(yīng)用的卡頓其實就是視覺上出現(xiàn)了不流暢的畫面，引起了用戶的注意，令其產(chǎn)生了一定的不適感。這也就意味著，在用戶操作后，需要第一時間從視覺層面給予反饋響應(yīng)，從而解決視覺動作帶來的不適。

開發(fā)者可以在用戶的交互動作開始時，從感知角度添加一些動畫元素，比如單擊效果、轉(zhuǎn)場縮放、加載進度條、共享動畫等，這些可以告訴用戶目前狀態(tài)發(fā)生了變化，APP在快速地運作著；而動畫的背后是：數(shù)據(jù)的計算，布局的渲染，內(nèi)容的加載等等，當新界面渲染顯示完成，上述動畫元素就可通過漸變消失、移出屏外等友好的方式退出視覺區(qū)域。

圖4 應(yīng)用響應(yīng)的兩個視角

使用這樣連貫的感知元素，能提供一種視覺隱喻，將用戶的注意力從上個頁面平滑地過渡到下個頁面；交互動畫表現(xiàn)得友好、有趣和實用，則用戶在響應(yīng)側(cè)的體驗會更加舒適，從主觀上也會認為應(yīng)用性能好、反應(yīng)速度快。

具體的使用場景和實現(xiàn)方案參考《轉(zhuǎn)場動畫場景案例》和《動畫時延場景案例》。

總結(jié)

本文探討了點擊響應(yīng)時延優(yōu)化的各種方法，為開發(fā)者提供重要的指導(dǎo)思路。

在移動應(yīng)用生態(tài)發(fā)展的今天，用戶對應(yīng)用響應(yīng)的體驗要求越來越高，開發(fā)者對點擊響應(yīng)做性能優(yōu)化是十分有必要的。

通過文中的UI優(yōu)化、并發(fā)優(yōu)化、代碼邏輯優(yōu)化、視覺感知優(yōu)化等常見優(yōu)化方法，可以有效提高應(yīng)用的點擊響應(yīng)性能，提升用戶體驗。