Android的UI調優

標籤：ui

對於一個App的UI而言，在流暢性上的改進目標其實就是降低螢幕繪製的延遲，建立流暢和穩定的幀率以避免卡頓。

      在理想情況下，全部的測量、布局和繪製的時間最好在16ms以內，這樣才能保證螢幕啟動並執行順暢性。而如何對螢幕渲染和UI效能進行評估和分析呢，在Android SDK中整合了一些工具用來策略APP的渲染效能問題。

 

一、視圖的層級分析：

         對於每一個視圖而言，都需要經過三個步驟：測量、布局和渲染。而App如何繪製視圖，它需要從頂部節點開始測量，沿著布局樹逐個渲染，視圖樹的層級越多，嵌套測量的次數越多，測量的時間也會越長。而一旦測量完畢就會進行布局，每個視圖都會對自己的子視圖進行布局，子視圖布局完畢後回到父視圖，然後再到根視圖，布局完成後，每個視圖都會被繪製在螢幕上。

         顯然，App的視圖越多，層級越深就需要越長的時間測量、布局和繪製，為了減少這些時間，需要儘可能保持視圖層級的扁平化並刪除所有沒有必要渲染的視圖。

         雖然在XML布局檔案中可以查看布局的節點視圖，單很難找到多餘的視圖，為了找到這些多餘的視圖，可以利用Android Studio中的Hierarchy Viewer工具來分析Android App中的視圖。

         Hierarchy Viewer（階層查看器）能夠便捷地以可視化方式查看各種視圖嵌套關係，可用於研究XML視圖結構。（需要一個運行Android App的裝置）

        650) this.width=650;" src="http://images2015.cnblogs.com/blog/803699/201706/803699-20170620102342804-1413296137.png" style="border:0px;" />

 

 

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

一般的建議：

使用抽象布局標籤(include, viewstub, merge)主要是為了最佳化布局,去除不必要的嵌套和View節點。

1. 視圖重用

多用於ListView和RecylerView等列表形式

1. 使用include嵌套布局，實現布局的模組化設計，這裡需要考慮到下面談到的merge標籤的使用。

2. <merge>標籤

 

在使用了include後可能導致布局嵌套過多，多餘不必要的layout節點，從而導致解析變慢，不必要的節點和嵌套可通過hierarchy viewer或設定->開發人員選項->顯示布局邊界查看。merge標籤在UI的結構最佳化中起著非常重要的作用，它可以刪減多餘的層級，最佳化UI。 
merge多用於替換FrameLayout或者當一個布局包含另一個時，merge標籤消除視圖階層中多餘的視圖組。

 

merge標籤可用於兩種典型情況： 
a. 布局頂結點是FrameLayout且不需要設定background或padding等屬性，可以用merge代替，因為Activity內容視圖的parent view就是個FrameLayout，所以可以用merge消除只剩一個。 
b. 某布局作為子布局被其他布局include時，使用merge當作該布局的頂節點，這樣在被引入時頂結點會自動被忽略，而將其子節點全部合并到主布局中。

1. <ViewStub>

viewstub標籤同include標籤一樣可以用來引入一個外部布局，不同的是，viewstub引入的布局預設不會擴張，即既不會佔用顯示也不會佔用位置，從而在解析layout時節省cpu和記憶體。 
viewstub常用來引入那些預設不會顯示，只在特殊情況下顯示的布局，如進度布局、網路失敗顯示的重新整理布局、資訊出錯出現的提示布局等。

比如說，假設network_error.xml為只有在網路錯誤時才需要顯示的布局，預設不會被解析。 
當我們要使用的時候，有兩種方法可以使用，效果是一樣的：

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

// 或者

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

二、資源縮減

第一點提到的是將App的視圖結構變扁平，減少視圖的數量後，其實我們還可以嘗試減少每個視圖裡使用的資源數量。（如載入時引用一個資源，在運行時進行著色）

三．螢幕的過度繪製

         螢幕的過度繪製這個概念有點類似於PhotoShop中的圖層的概念，上面的圖層會覆蓋住下面的圖層，而使得下面的圖層不可見。當Android系統繪製螢幕時，首先繪製父視圖而後是子視圖，子視圖位於其父視圖上。

         重繪螢幕的行為被稱為過度繪製，多次的螢幕繪製會增加延遲，並且可以導致布局卡頓。

         既然過度繪製的影響那麼大，我們應該怎麼檢測呢？

         Android提供了一些很好的工具來檢測過度繪製，而一般採用的方式是在Debug GPU Overdraw菜單中選擇“Show Overdraw area”，（在本人手機中為開發人員選項中的調試GPU過度繪製），選擇之後會在App的不同地區覆蓋不同的顏色來表示過度繪製的次數。比較螢幕上的這些不同顏色，可以快速定位問題。

         白色：沒有過度繪製

藍色：1次過度繪製（螢幕繪製了2次）

綠色：2次過度繪製

淺紅色：3次過度繪製

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

 650) this.width=650;" src="http://images2015.cnblogs.com/blog/803699/201706/803699-20170620102359741-1035737567.png" style="border:0px;" />

而另外一種查看方法是藉助於前面提到的Hierarchy Viewer工具，將view hierarchy儲存為Photoshop文檔，開啟這些視圖後可以看到不同層次的過度繪製情況。

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

         在最佳化視圖的階層和過度繪製後，App還存在丟幀或者不流暢的情況，為了獲得獲得更加全面的卡頓檢測資訊，Android系統中有一個Profile GPU Rendering的開發人員選項，它能夠檢測出每一幀在螢幕上用了多久，策略資料可以儲存到記錄檔中，或者在裝置上即時顯示。一般而言，在螢幕上直接展示GPU的渲染資料能夠更加直觀地看到。

 650) this.width=650;" src="http://images2015.cnblogs.com/blog/803699/201706/803699-20170620102411585-1294844592.png" style="border:0px;" />

在本人的手機中，在開發人員選項中找到【GPU呈現模式分析】，選擇【在螢幕上顯示為橫條圖】，然後開啟一個手機QQ，就發現如所示情況

 650) this.width=650;" src="http://images2015.cnblogs.com/blog/803699/201706/803699-20170620102416773-1118816384.png" style="border:0px;" />

需要關注的是底部的那一條水平綠線，它表示裝置渲染一幀要16ms，每一幀就是一個水平條，如果有很多幀超過了這條綠線就說明裝置出現了卡頓情況。

五、讓它看起來更快

         前面講到了如果通過測試發現問題最佳化布局使得UI繪製更加流暢，其實還有一個方法使得UI繪製更快：讓它看起來更快。

1. 進度條

2. 動畫

3. 即時更新：指使用者更新了一個頁面後，頁面上的資料就會立刻發生變化，即使資料還沒有達到伺服器（這裡需要確定這些資料最終一定可以更新到伺服器）（離線上傳，離線發送網路請求）

或者是另外一種思路，在使用者添加有關圖片文章的文字時提前上傳圖片到伺服器。

Android的UI調優