對(duì)于一個(gè)App的UI而言，在流暢性上的改進(jìn)目標(biāo)其實(shí)就是降低屏幕繪制的延遲，創(chuàng)建流暢和穩(wěn)定的幀率以避免卡頓。

在理想情況下，全部的測(cè)量、布局和繪制的時(shí)間最好在16ms以內(nèi)，這樣才能保證屏幕運(yùn)行的順暢性。而如何對(duì)屏幕渲染和UI性能進(jìn)行評(píng)估和分析呢，在Android SDK中集成了一些工具用來策略APP的渲染性能問題。

一、視圖的層級(jí)分析：

對(duì)于每一個(gè)視圖而言，都需要經(jīng)過三個(gè)步驟：測(cè)量、布局和渲染。而App如何繪制視圖，它需要從頂部節(jié)點(diǎn)開始測(cè)量，沿著布局樹逐個(gè)渲染，視圖樹的層級(jí)越多，嵌套測(cè)量的次數(shù)越多，測(cè)量的時(shí)間也會(huì)越長(zhǎng)。而一旦測(cè)量完畢就會(huì)進(jìn)行布局，每個(gè)視圖都會(huì)對(duì)自己的子視圖進(jìn)行布局，子視圖布局完畢后回到父視圖，然后再到根視圖，布局完成后，每個(gè)視圖都會(huì)被繪制在屏幕上。

顯然，App的視圖越多，層級(jí)越深就需要越長(zhǎng)的時(shí)間測(cè)量、布局和繪制，為了減少這些時(shí)間，需要盡可能保持視圖層級(jí)的扁平化并刪除所有沒有必要渲染的視圖。

雖然在XML布局文件中可以查看布局的節(jié)點(diǎn)視圖，單很難找到多余的視圖，為了找到這些多余的視圖，可以利用Android Studio中的Hierarchy Viewer工具來分析Android App中的視圖。

Hierarchy Viewer（層次結(jié)構(gòu)查看器）能夠便捷地以可視化方式查看各種視圖嵌套關(guān)系，可用于研究XML視圖結(jié)構(gòu)。（需要一個(gè)運(yùn)行Android App的設(shè)備）

利用這個(gè)工具可以查看我們的View的層次，從而借助它修改我們的布局。

一般的建議：

使用抽象布局標(biāo)簽(include, viewstub, merge)主要是為了優(yōu)化布局,去除不必要的嵌套和View節(jié)點(diǎn)。

• 視圖重用

多用于ListView和RecylerView等列表形式

• 使用include嵌套布局，實(shí)現(xiàn)布局的模塊化設(shè)計(jì)，這里需要考慮到下面談到的merge標(biāo)簽的使用。
• <merge>標(biāo)簽

在使用了include后可能導(dǎo)致布局嵌套過多，多余不必要的layout節(jié)點(diǎn)，從而導(dǎo)致解析變慢，不必要的節(jié)點(diǎn)和嵌套可通過hierarchy viewer或設(shè)置->開發(fā)者選項(xiàng)->顯示布局邊界查看。merge標(biāo)簽在UI的結(jié)構(gòu)優(yōu)化中起著非常重要的作用，它可以刪減多余的層級(jí)，優(yōu)化UI。 
merge多用于替換FrameLayout或者當(dāng)一個(gè)布局包含另一個(gè)時(shí)，merge標(biāo)簽消除視圖層次結(jié)構(gòu)中多余的視圖組。

merge標(biāo)簽可用于兩種典型情況： 
a. 布局頂結(jié)點(diǎn)是FrameLayout且不需要設(shè)置background或padding等屬性，可以用merge代替，因?yàn)锳ctivity內(nèi)容視圖的parent view就是個(gè)FrameLayout，所以可以用merge消除只剩一個(gè)。 
b. 某布局作為子布局被其他布局include時(shí)，使用merge當(dāng)作該布局的頂節(jié)點(diǎn)，這樣在被引入時(shí)頂結(jié)點(diǎn)會(huì)自動(dòng)被忽略，而將其子節(jié)點(diǎn)全部合并到主布局中。

<ViewStub>

viewstub標(biāo)簽同include標(biāo)簽一樣可以用來引入一個(gè)外部布局，不同的是，viewstub引入的布局默認(rèn)不會(huì)擴(kuò)張，即既不會(huì)占用顯示也不會(huì)占用位置，從而在解析layout時(shí)節(jié)省cpu和內(nèi)存。 
viewstub常用來引入那些默認(rèn)不會(huì)顯示，只在特殊情況下顯示的布局，如進(jìn)度布局、網(wǎng)絡(luò)失敗顯示的刷新布局、信息出錯(cuò)出現(xiàn)的提示布局等。

比如說，假設(shè)network_error.xml為只有在網(wǎng)絡(luò)錯(cuò)誤時(shí)才需要顯示的布局，默認(rèn)不會(huì)被解析。 
當(dāng)我們要使用的時(shí)候，有兩種方法可以使用，效果是一樣的：

((ViewStub) findViewById(R.id.layout_error)).setVisibility(View.VISIBLE); 

// 或者

View importPanel = ((ViewStub) findViewById(R.id.layout_error)).inflate(); 

二、資源縮減

第一點(diǎn)提到的是將App的視圖結(jié)構(gòu)變扁平，減少視圖的數(shù)量后，其實(shí)我們還可以嘗試減少每個(gè)視圖里使用的資源數(shù)量。（如加載時(shí)引用一個(gè)資源，在運(yùn)行時(shí)進(jìn)行著色）

三．屏幕的過度繪制

屏幕的過度繪制這個(gè)概念有點(diǎn)類似于PhotoShop中的圖層的概念，上面的圖層會(huì)覆蓋住下面的圖層，而使得下面的圖層不可見。當(dāng)Android系統(tǒng)繪制屏幕時(shí)，首先繪制父視圖而后是子視圖，子視圖位于其父視圖上。

重繪屏幕的行為被稱為過度繪制，多次的屏幕繪制會(huì)增加延遲，并且可以導(dǎo)致布局卡頓。

既然過度繪制的影響那么大，我們應(yīng)該怎么檢測(cè)呢？

Android提供了一些很好的工具來檢測(cè)過度繪制，而一般采用的方式是在Debug GPU Overdraw菜單中選擇“Show Overdraw area”，（在本人手機(jī)中為開發(fā)者選項(xiàng)中的調(diào)試GPU過度繪制），選擇之后會(huì)在App的不同區(qū)域覆蓋不同的顏色來表示過度繪制的次數(shù)。比較屏幕上的這些不同顏色，可以快速定位問題。

白色：沒有過度繪制

藍(lán)色：1次過度繪制（屏幕繪制了2次）

綠色：2次過度繪制

淺紅色：3次過度繪制

深紅色：4次或更多次過度繪制

而另外一種查看方法是借助于前面提到的Hierarchy Viewer工具，將view hierarchy保存為Photoshop文檔，打開這些視圖后可以看到不同層次的過度繪制情況。

四、分析卡頓（策略GPU的渲染能力）

在優(yōu)化視圖的層次結(jié)構(gòu)和過度繪制后，App還存在丟幀或者不流暢的情況，為了獲得獲得更加全面的卡頓檢測(cè)信息，Android系統(tǒng)中有一個(gè)Profile GPU Rendering的開發(fā)者選項(xiàng)，它能夠檢測(cè)出每一幀在屏幕上用了多久，策略數(shù)據(jù)可以保存到日志文件中，或者在設(shè)備上實(shí)時(shí)顯示。一般而言，在屏幕上直接展示GPU的渲染數(shù)據(jù)能夠更加直觀地看到。

在本人的手機(jī)中，在開發(fā)者選項(xiàng)中找到【GPU呈現(xiàn)模式分析】，選擇【在屏幕上顯示為條形圖】，然后打開一個(gè)手機(jī)QQ，就發(fā)現(xiàn)如下圖所示情況

需要關(guān)注的是底部的那一條水平綠線，它表示設(shè)備渲染一幀要16ms，每一幀就是一個(gè)水平條，如果有很多幀超過了這條綠線就說明設(shè)備出現(xiàn)了卡頓情況。

五、讓它看起來更快

前面講到了如果通過測(cè)試發(fā)現(xiàn)問題優(yōu)化布局使得UI繪制更加流暢，其實(shí)還有一個(gè)方法使得UI繪制更快：讓它看起來更快。

• 進(jìn)度條
• 動(dòng)畫
• 即時(shí)更新：指用戶更新了一個(gè)頁面后，頁面上的數(shù)據(jù)就會(huì)立刻發(fā)生變化，即使數(shù)據(jù)還沒有達(dá)到服務(wù)器（這里需要確定這些數(shù)據(jù)最終一定可以更新到服務(wù)器）（離線上傳，離線發(fā)送網(wǎng)絡(luò)請(qǐng)求）

或者是另外一種思路，在用戶添加有關(guān)圖片帖子的文字時(shí)提前上傳圖片到服務(wù)器。

以上就是Android的UI調(diào)優(yōu)教程的詳細(xì)內(nèi)容，更多關(guān)于Android UI調(diào)優(yōu)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論