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

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

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

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

（一）UI優(yōu)化

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

減少嵌套層級(jí)

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

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

減少渲染時(shí)間

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

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

用renderGroup緩存動(dòng)效

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

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

圖2 renderGroup使用場(chǎng)景示例

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

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

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

LazyForEach懶加載

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

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

動(dòng)態(tài)import

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

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

具體的使用場(chǎng)景和實(shí)現(xiàn)方案參考《動(dòng)態(tài)import》。

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

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

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

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

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

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

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

二者原理和效果差異可參考《TaskPool和Worker的對(duì)比實(shí)踐》。

使用組件異步加載特性

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

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

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

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

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

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

圖3 生命周期流程

通常可以采用的邏輯優(yōu)化方法有：

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

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

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

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

減小拖動(dòng)識(shí)別距離

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

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

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

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

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

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

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

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

總結(jié)

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

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

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