? ? 界面是 Android 應用中直接影響用戶體驗最關鍵的部分。如果代碼實現得不好，界面容易發生卡頓且導致應用占用大量內存。

????????我司這類做 ROM 的公司更不一樣，預裝的應用一定要非常流暢，這樣給客戶或用戶的第一感覺就是快。又卡又慢的應用體驗，會影響客戶或用戶對產品的信心和評價，所以不可忽視。

目錄

• 一. Android渲染知識

• 1.1 繪制原理

• 1.2 掉幀

• 1.3 為什么是60Fps？

• 1.4 垃圾回收

• 1.5 UI 線程

• 1.6 垂直同步

• 1.7 UI 繪制機制與柵格化

• 二. 檢測和解決

• 2.1 檢測維度

• 2.2 調試工具

• 2.3 如何解決

• 三. 界面過度繪制

• 3.1 過度繪制概念

• 3.2 追蹤過度繪制

• 3.3 過度繪制的根源

• 3.4 不合理的xml布局對繪制的影響

• 3.5 源碼相關

• 四. 渲染性能

• 4.1 渲染性能概念

• 4.2 追蹤渲染性能

• 4.3 渲染性能差的根源

• 4.4 檢測說明

• 4.5 UI繪制機制的補充說明

• 五. 布局邊界合理性

• 六. 給開發的界面優化建議

• 6.1 優化布局的結構

• 6.2 優化處理邏輯

• 6.3 善用 DEBUG 工具

一. Android渲染知識

1.1 繪制原理

????????Android系統要求每一幀都要在 16ms 內繪制完成，平滑的完成一幀意味著任何特殊的幀需要執行所有的渲染代碼（包括 framework 發送給 GPU 和 CPU 繪制到緩沖區的命令）都要在 16ms 內完成，保持流暢的體驗。這個速度允許系統在動畫和輸入事件的過程中以約 60 幀每秒（ 1秒 / 0.016幀每秒 = 62.5幀/秒 ）的平滑幀率來渲染。

????????如果你的應用沒有在 16ms 內完成這一幀的繪制，假設你花了 24ms 來繪制這一幀，那么就會出現掉幀的情況。

????????系統準備將新的一幀繪制到屏幕上，但是這一幀并沒有準備好，所有就不會有繪制操作，畫面也就不會刷新。反饋到用戶身上，就是用戶盯著同一張圖看了 32ms 而不是 16ms ，也就是說掉幀發生了。

1.2 掉幀

????????掉幀是用戶體驗中一個非常核心的問題。丟棄了當前幀，并且之后不能夠延續之前的幀率，這種不連續的間隔會容易會引起用戶的注意，也就是我們常說的卡頓、不流暢。

????????引起掉幀的原因非常多，比如：

• 花了非常多時間重新繪制界面中的大部分東西，這樣非常浪費CPU周期；
  

• 過度繪制嚴重，在繪制用戶看不到的對象上花費了太多的時間；
  

• 有一大堆動畫重復了一遍又一遍，消耗 CPU 、 GPU 資源；
  

• 頻繁的觸發垃圾回收；

1.3 為什么是60Fps？

????????Android系統要求每一幀都要在 16ms 內繪制完成，那么1秒的幀率就是約 60 幀每秒（ 1秒 / 0.016幀每秒 = 62.5幀/秒 ），那為什么要以 60 Fps來作為 App 性能的衡量標準呢？這是因為人眼和大腦之間的協作無法感知到超過 60 Fps的畫面更新。

????????市面上絕大多數Android設備的屏幕刷新頻率是 60 HZ。當然，超過 60 Fps 是沒有意義的，人眼感知不到區別。24 Fps 是人眼能感知的連續線性的運動，所以是電影膠圈的常用幀率，因為這個幀率已經足夠支撐大部分電影畫面所要表達的內容，同時能最大限度地減少費用支出。但是，低于 30 Fps 是無法順暢表現絢麗的畫面內容的，此時就需要用到 60 Fps 來達到想要表達的效果。了解更多Fps知識詳見「?Wiki?」。

????????應用的界面性能目標就是保持 60 Fps，這意味著每一幀你只有 16 ms（1秒 / 60幀率）的時間來處理所有的任務。

1.4 垃圾回收

????????垃圾回收器是一個在應用運行期間自動釋放那些不再引用的內存的機制，常稱 GC 。頻繁的 GC 也是導致嚴重性能問題的罪魁禍首之一。

????????前面提到，平滑的完成一幀意味著所有渲染代碼都必須在 16ms 內完成。頻繁的 GC 會嚴重限制一幀時間內的剩余時間，如果 GC 所做的工作超過了那些必須的工作，那么留給應用平滑的幀率的時間就越少。越接近 16ms ，在垃圾回收事件觸發的時候，就越容易導致卡頓。

????????注意，Android4.4 引進了新的 ART 虛擬機來取代 Dalvik 虛擬機。它們的機制大有不同，簡單而言：

• Dalvik 虛擬機的 GC 是非常耗資源的，并且在正常的情況下一個硬件性能不錯的Android設備也會很容易耗費掉 10 – 20 ms 的時間；

• ART 虛擬機的GC會動態提升垃圾回收的效率，在 ART 中的中斷，通常在 2 – 3 ms 間。 比 Dalvik 虛擬機有很大的性能提升；

????????ART 虛擬機相對于 Dalvik 虛擬機來說的垃圾回收來說有一個很大的性能提升，但 2 – 3 ms 的回收時間對于超過16ms幀率的界限也是足夠的。因此，盡管垃圾回收在 Android 5.0 之后不再是耗資源的行為，但也是始終需要盡可能避免的，特別是在執行動畫的情況下，可能會導致一些讓用戶明顯感覺的丟幀。

????????想了解更多詳細的 ART 和 Dalvik 虛擬機垃圾回收機制，可「?戳我?」和「?我?」進行深入了解。

1.5 UI 線程

????????UI 線程是應用的主線程，很多的性能和卡頓問題是由于我們在主線程中做了大量的工作。

????????所以，所有耗資源的操作，比如 IO 操作、網絡操作、SQL 操作、列表刷新等，都應該用后臺進程去實現，不能占用主線程，主線程是 UI 線程，是保持程序流暢的關鍵；

????????在 Android 5.0 版本里，Android 框架層引入了 “ Render Thread ” ，用于向 GPU 發送實際渲染的操作。這個線程減輕了一些 UI 線程減少的操作。但是輸入、滾動和動畫仍然在 UI thread，因為 Thread 必須能夠響應操作。

1.6 垂直同步

????????垂直同步是 Android4.1 通過 Project Butter 在 UI 架構中引入的新技術，同期引入的還有 Triple Buffer 和 HWComposer 等技術，都是為提高 UI 的流暢性而生。

????????舉個例子，你拍了一張照片，然后旋轉5度再拍另外一張照片，將兩照片的中間剪開并拼接在一起，得到下圖：

????????中間這部分有明顯區別的部分，等價于設備刷新率和幀速率不一致的結果。

????????一般而言， GPU 的幀速率應高于刷新率，才不會卡頓或掉幀。如果屏幕刷新率比幀速率還快，屏幕會在兩幀中顯示同一個畫面，這種斷斷續續情況持續發生時，用戶將會很明顯地感覺到動畫的卡頓或者掉幀，然后又恢復正常，我們常稱之為閃屏、跳幀、延遲。

????????應用應避免這些幀率下降的情況，以確保 GPU 能在屏幕刷新之前完成數據的獲取及寫入，保證動畫流暢。

1.7 UI 繪制機制與柵格化

????????絕大多數渲染操作都依賴兩個硬件： CPU 、 GPU 。 CPU 負責 Measure 、 layout 、 Record 、 Execute 的計算操作， GPU 負責柵格化（ Rasterization ）操作。 非必需的視圖組件會帶來多余的 CPU 計算操作，還會占用多余的 GPU 資源。

????????柵格化（ Rasterization ）能將 Button 、 Shape 、 Path 、 Bitmap 等資源組件拆分到不同的像素上進行顯示。這個操作很費時，所以引入了 GPU 來加快柵格化的操作。

????????CPU 負責把 UI 組件計算成多邊形（ Polygons ），紋理（ Texture ），然后交給 GPU 進行柵格化渲染，再將處理結果傳到屏幕上顯示。

????????在 Android 里的那些資源組件的顯示（比如 Bitmaps 、 Drawable ），都是一起打包到統一的紋理（ Texture ）當中，然后再傳遞到 GPU 里面。

????????圖片的顯示，則是先經過 CPU 的計算加載到內存中，再傳給 GPU 進行渲染。

文字的顯示，則是先經過 CPU 換算成紋理（ Texture ），再傳給 GPU 進行渲染，返回到 CPU 繪制單個字符的時候，再重新引用經過 GPU 渲染的內容。

????????動畫的顯示更加復雜，我們需要在 16 ms 內處理完所有 CPU 和 GPU 的計算、繪制、渲染等操作，才能獲得應用的流暢體驗。

二. To檢測和解決

2.1 檢測維度

????????根據業務的不同與所需要的測試粒度的不同，就會有不同的檢測維度。目前我所在業務所需的界面性能檢測維度如下：

• 界面過度繪制；（檢測過度繪制）

• 渲染性能；（檢測嚴格模式下的UI渲染性能呈現）

• 布局邊界合理性；（檢測元素顯示的合理性）

????????還有專項測試中某些用戶場景可能還包含著另外一些隱形的檢測維度，比如：

• OpenGL 跟蹤分析；

• GPU 視圖更新合理性；

• Flash 硬件層更新合理性；

• 動畫加 / 減速狀態問題點檢測；

• ……

2.2 調試工具

????????檢測和解決界面性能問題很大程度上依賴于你的應用程序架構，幸運的是，Andorid 提供了很多調試工具，知道并學會使用這些工具很重要，它們可以幫助我們調試和分析界面性能問題，以讓應用擁有更好的性能體驗。下面列舉Android常見的界面性能調試工具：

2.2.1 Hierarchy View

????????Hierarchy View 在Android SDK里自帶，常用來查看界面的視圖結構是否過于復雜，用于了解哪些視圖過度繪制，又該如何進行改進。詳見官方使用教程（需要翻墻）:「?戳我?」，官方介紹「?戳我?」。

2.2.2 Lint

????????Lint 是 ADT 自帶的靜態代碼掃描工具，可以給 XML 布局文件和 項目代碼中不合理的或存在風險的模塊提出改善性建議。官方關于 Lint 的實際使用的提示，列舉幾點如下：

• 包含無用的分支，建議去除；

• 包含無用的父控件，建議去除；

• 警告該布局深度過深；

• 建議使用 compound drawables ；

• 建議使用?merge?標簽；

• ……

2.2.3 Systrace

????????Systrace 在Android DDMS 里自帶，可以用來跟蹤 graphics 、view 和 window 的信息，發現一些深層次的問題。很麻煩，限制大，實際調試中我基本用不到。官方介紹 「戳我」和 「我」。

2.2.4 Track

????????Track 在 Android DDMS里自帶，是個很棒的用來跟蹤構造視圖的時候哪些方法費時，精確到每一個函數，無論是應用函數還是系統函數，我們可以很容易地看到掉幀的地方以及那一幀所有函數的調用情況，找出問題點進行優化。官方介紹 「戳我」。

2.2.5 OverDraw

????????通過在 Android 設備的設置 APP 的開發者選項里打開 “ 調試 GPU 過度繪制 ” ，來查看應用所有界面及分支界面下的過度繪制情況，方便進行優化。官方介紹 「戳我」。

2.2.6 GPU 呈現模式分析

????????通過在 Android 設備的設置 APP 的開發者選項里啟動 “ GPU 呈現模式分析 ” ，可以得到最近 128 幀 每一幀渲染的時間，分析性能渲染的性能及性能瓶頸。官方介紹 「戳我」。

2.2.7 StrictMode

????????通過在 Android 設備的設置 APP 的開發者選項里啟動 “ 嚴格模式 ” ，來查看應用哪些操作在主線程上執行時間過長。當一些操作違背了嚴格模式時屏幕的四周邊界會閃爍紅色，同時輸出 StrictMode 的相關信息到 LOGCAT 日志中。

2.2.8 Animator duration scale

????????通過在 Android 設備的設置 APP 的開發者選項里打開 “ 窗口動畫縮放 ” / “ 過渡動畫縮放 ” / “ 動畫程序時長縮放 ”，來加速或減慢動畫的時間，以查看加速或減慢狀態下的動畫是否會有問題。

2.2.9 Show hardware layer updates

????????通過在 Android 設備的設置 APP 的開發者選項里啟動 “ 顯示硬件層更新 ”，當 Flash 硬件層在進行更新時會顯示為綠色。使用這個工具可以讓你查看在動畫期間哪些不期望更新的布局有更新，方便你進行優化，以獲得應用更好的性能。實例《 Optimizing Android Hardware Layers 》（需要翻墻）:「?戳我?」。

2.3 如何解決

????????前面提到過我司的目前所需的測試維度如下：

• 界面過度繪制；（檢測過度繪制）

• 渲染性能；（檢測嚴格模式下的UI渲染性能呈現）

• 布局邊界合理性；（檢測元素顯示的合理性）

????????故接下來將圍繞這三兩點，分別從概念、追蹤、挖掘根源以及排查的工具來具體講述如何解決，以及給開發的優化建議。

三. 界面過度繪制（OverDraw）

3.1 過度繪制概念

????????過度繪制是一個術語，表示某些組件在屏幕上的一個像素點的繪制次數超過 1 次。

????????通俗來講，繪制界面可以類比成一個涂鴉客涂鴉墻壁，涂鴉是一件工作量很大的事情，墻面的每個點在涂鴉過程中可能被涂了各種各樣的顏色，但最終呈現的顏色卻只可能是 1 種。這意味著我們花大力氣涂鴉過程中那些非最終呈現的顏色對路人是不可見的，是一種對時間、精力和資源的浪費，存在很大的改善空間。繪制界面同理，花了太多的時間去繪制那些堆疊在下面的、用戶看不到的東西，這樣是在浪費CPU周期和渲染時間！

????????官方例子，被用戶激活的卡片在最上面,而那些沒有激活的卡片在下面，在繪制用戶看不到的對象上花費了太多的時間。

3.2 追蹤過度繪制

????????通過在 Android 設備的設置 APP 的開發者選項里打開 “ 調試 GPU 過度繪制 ” ，來查看應用所有界面及分支界面下的過度繪制情況，方便進行優化。

????????Android 會在屏幕上顯示不同深淺的顏色來表示過度繪制：

• 沒顏色：沒有過度繪制，即一個像素點繪制了 1 次，顯示應用本來的顏色；

• 藍色：1倍過度繪制，即一個像素點繪制了 2 次；

• 綠色：2倍過度繪制，即一個像素點繪制了 3 次；

• 淺紅色：3倍過度繪制，即一個像素點繪制了 4 次；

• 深紅色：4倍過度繪制及以上，即一個像素點繪制了 5 次及以上；

????????設備的硬件性能是有限的，當過度繪制導致應用需要消耗更多資源（超過了可用資源）的時候性能就會降低，表現為卡頓、不流暢、ANR 等。為了最大限度地提高應用的性能和體驗，就需要盡可能地減少過度繪制，即更多的藍色色塊而不是紅色色塊。

????????實際測試，常用以下兩點來作為過度繪制的測試指標，將過度繪制控制在一個約定好的合理范圍內：

• 應用所有界面以及分支界面均不存在超過4X過度繪制（深紅色區域）；

• 應用所有界面以及分支界面下，3X過度繪制總面積（淺紅色區域）不超過屏幕可視區域的1/4；

3.3 過度繪制的根源

????????過度繪制很大程度上來自于視圖相互重疊的問題，其次還有不必要的背景重疊。

????????官方例子，比如一個應用所有的View都有背景的話，就會看起來像第一張圖中那樣，而在去除這些不必要的背景之后（指的是Window的默認背景、Layout的背景、文字以及圖片的可能存在的背景），效果就像第二張圖那樣，基本沒有過度繪制的情況。

3.4 不合理的xml布局對繪制的影響

????????當布局文件的節點樹的深度越深，XML 中的標簽和屬性設置越多，對界面的顯示有災難性影響。

????????一個界面要顯示出來，第一步會進行解析布局，在 requestLayout 之后還要進行一系列的 measure 、 layout 、 draw 操作，若布局文件嵌套過深、擁有的標簽屬性過于臃腫，每一步的執行時間都會受到影響，而界面的顯示是進行完這些操作后才會顯示的，所以每一步操作的時間增長，最終顯示的時間就會越長。

3.5 源碼相關

????????有能力且有興趣看源碼的童鞋，過度繪制的源碼位置在: /frameworks/base/libs/hwui/OpenGLRenderer.cpp ，有興趣的可以去研究查看。

? ??if (Properties::debugOverdraw & getTargetFbo() == 0) {

????????const Rect* clip = &mTilingClip;

????????mRenderState.scissor().setEnabled(true);

????????mRenderState.scissor().set(clip->left,

????????????????mState.firstSnapshot()->getViewportHeight() - clip->bottom,

????????????????clip->right - clip->left,

????????????????clip->bottom - clip->top);

?

????????// 1x overdraw

????????mRenderState.stencil().enableDebugTest(2);

????????drawColor(mCaches.getOverdrawColor(1), SkXfermode::kSrcOver_Mode);

?

????????// 2x overdraw

????????mRenderState.stencil().enableDebugTest(3);

????????drawColor(mCaches.getOverdrawColor(2), SkXfermode::kSrcOver_Mode);

?

????????// 3x overdraw

????????mRenderState.stencil().enableDebugTest(4);

????????drawColor(mCaches.getOverdrawColor(3), SkXfermode::kSrcOver_Mode);

?

????????// 4x overdraw and higher

????????mRenderState.stencil().enableDebugTest(4, true);

????????drawColor(mCaches.getOverdrawColor(4), SkXfermode::kSrcOver_Mode);

?

????????mRenderState.stencil().disable();

????}

}

四. 渲染性能（Rendering）

4.1 渲染性能概念

????????渲染性能往往是掉幀的罪魁禍首，這種問題很常見，讓人頭疼。好在 Android 給我們提供了一個強大的工具，幫助我們非常容易追蹤性能渲染問題，看到究竟是什么導致你的應用出現卡頓、掉幀。

4.2 追蹤渲染性能

????????通過在 Android 設備的設置 APP 的開發者選項里打開 “ GPU 呈現模式分析 ” 選項，選擇 ” 在屏幕上顯示為條形圖 “ 。

????????這個工具會在Android 設備的屏幕上實時顯示當前界面的最近 128 幀 的 GPU 繪制圖形數據，包括 StatusBar 、 NavBar 、 當前界面的 GPU 繪制圖形柱狀圖數據。我們一般只需關心當前界面的 GPU 繪制圖形數據即可。

????????界面上一共有 128 個小柱狀圖，代表的是當前界面最近的 128 幀 GPU 繪制圖形數據。一個小柱狀圖代表的這一幀畫面渲染的耗時，柱狀圖越高代表耗時越長。隨著界面的刷新，柱狀圖信息也會實時滾動刷新。

????????中間有一條綠線，代表 16 ms ，保持動畫流暢的關鍵就在于讓這些垂直的柱狀條盡可能地保持在綠線下面,任何時候超過綠線,你就有可能丟失一幀的內容。

????????每一個柱狀圖都是由三種顏色構成：藍、紅、黃。

• 藍色代表的是這一幀繪制 Display List 的時間。通俗來說，就是記錄了需要花費多長時間在屏幕上更新視圖。用代碼語言來說，就是執行視圖的 onDraw 方法，創建或更新每一個視圖的 Display List 的時間。

  
  

• 紅色代表的是這一幀 OpenGL 渲染 Display List 所需要的時間。通俗來說，就是記錄了執行視圖繪制的耗時。用代碼語言來說，就是 Android 用 OpenGL ES 的 API 接口進行 2D 渲染 Display List 的時間。

  
  

• 黃色代表的是這一幀 CPU 等待 GPU 處理的時間。通俗來說，就是 CPU 等待 GPU 發出接到命令的回復的等待時間。用代碼語言來說，就是這是一個阻塞調用。

????????實際測試，常用以下兩點來作為渲染性能的測試指標，將渲染性能控制在一個約定好的合理范圍內：

• 執行應用的所有功能及分支功能，操作過程中涉及的柱狀條區域應至少 90 % 保持到綠線下面；

• 從用戶體檢的角度主觀判斷應用在 512 M 內存的 Android 設備下所有操作過程中的卡頓感是否能接受，不會感覺突兀怪異；

4.3 渲染性能差的根源

????????當你看到藍色的線較高的時候，可能是由于你的視圖突然無效了需要重新繪制，或者是自定義的視圖過于復雜耗時過長。

????????當你看到紅色的線較高的時候，可能是由于你的視圖重新提交了需要重新繪制導致的（比如屏幕從豎屏旋轉成橫屏后當前界面重新創建），或者是自定義的視圖很復雜，繪制起來很麻煩，導致耗時過長。比如下面這種視圖：

????????當你看到黃色的線較高的時候，那就意味著你給 GPU 太多的工作，太多的負責視圖需要 OpenGL 命令去繪制和處理，導致 CPU 遲遲沒等到 GPU 發出接到命令的回復。

4.4 檢測說明

????????這個工具能夠很好地幫助你找到渲染相關的問題，幫助你找到卡頓的性能瓶頸，追蹤究竟是什么導致被測應用出現卡頓、變慢的情況，以便在代碼層面進行優化。甚至讓負責產品設計的人去改善他的設計，以獲得良好的用戶體驗。

????????檢測渲染性能時，常伴隨著開啟“ 嚴格模式 ” 查看應用哪些情景在 UI 線程（主線程）上執行時間過長。

????????另外有些強大但可能少用的工具在測試性能渲染時輔助分析，比如：

• HierarchyViewer：這個工具常用來查看界面的視圖結構是否過于復雜，用于了解哪些視圖過度繪制，又該如何進行改進；

• Tracer for OpenGL：這個工具收集了所有UI界面發給GPU的繪制命令。常用于輔助開發人員 DEBUG 、定位一些 HierarchyViewer 工具定位不了的疑難渲染細節問題。

4.5 UI繪制機制的補充說明

????????如上面所說，布局和 UI 組件等都會先經過 CPU 計算成 GPU 能夠識別并繪制的多邊形（ Polygons ），紋理（ Texture ），然后交給 GPU 進行柵格化渲染，再將處理結果傳到屏幕上顯示。 “ CPU 計算成 GPU 能夠識別并繪制的對象 ” 這個操作是在 DisplayList 的幫助下完成的。DisplayList 擁有要交給 GPU 柵格化渲染到屏幕上的數據信息。

????????DisplayList 會在某個視圖第一次需要渲染時創建。當該視圖有類似位置被移動等變化而需要重新渲染這個視圖的時候，則只需 GPU 額外執行一次渲染指令冰更新到屏幕上就夠了。但如果視圖中的繪制內容發生變化時（比如不可見了），那之間的 DisplayList 就無法繼續使用了，這時系統就會重新執行一次重新創建 DisplayList 、渲染DisplayList 并更新到屏幕上。這個流程的表現性能取決于該視圖的復雜程度。

五. 布局邊界合理性

????????這一章節比較簡單，考慮到應該沒受眾，故不展開討論。

六. 給開發的界面優化 Advice

6.1 優化布局的結構

????????布局結構太復雜，會減慢渲染的速度，造成性能瓶頸。我們可以通過以下這些慣用、有效的布局原則來優化：

• 避免復雜的View層級。布局越復雜就越臃腫，就越容易出現性能問題，尋找最節省資源的方式去展示嵌套的內容；

  
  

• 盡量避免在視圖層級的頂層使用相對布局?RelativeLayout?。相對布局?RelativeLayout?比較耗資源，因為一個相對布局?RelativeLayout?需要兩次度量來確保自己處理了所有的布局關系，而且這個問題會伴隨著視圖層級中的相對布局?RelativeLayout?的增多，而變得更嚴重；

  
  

• 布局層級一樣的情況建議使用線性布局?LinearLayout?代替相對布局?RelativeLayout，因為線性布局?LinearLayout?性能要更高一些；確實需要對分支進行相對布局?RelativeLayout?的時候，可以考慮更優化的網格布局?GridLayout?，它已經預處理了分支視圖的關系，可以避免兩次度量的問題；

  
  

• 相對復雜的布局建議采用相對布局?RelativeLayout?，相對布局?RelativeLayout?可以簡單實現線性布局?LinearLayout?嵌套才能實現的布局；

  
  

• 不要使用絕對布局?AbsoluteLayout?；

  
  

• 將可重復使用的組件抽取出來并用?標簽進行重用。如果應用多個地方的 UI 用到某個布局，就將其寫成一個布局部件，便于各個 UI 重用。官方詳解 「?戳我?」

  
  

• 使用?merge?標簽減少布局的嵌套層次，官方詳解 「?戳我?」；

  
  

• 去掉多余的不可見背景。有多層背景顏色的布局，只留最上層的對用戶可見的顏色即可，其他用戶不可見的底層顏色可以去掉，減少無效的繪制操作；

  
  

• 盡量避免使用 layoutweight 屬性。使用包含 layoutweight 屬性的線性布局?LinearLayout?每一個子組件都需要被測量兩次，會消耗過多的系統資源。在使用?ListView?標簽與?GridView?標簽的時候，這個問題顯的尤其重要，因為子組件會重復被創建。平分布局可以使用相對布局?RelativeLayout?里一個 0dp 的 view 做分割線來搞定，如果不行，那就……；

  
  

• 合理的界面的布局結構應是寬而淺，而不是窄而深；

6.2 優化處理邏輯

• 按需載入視圖。某些不怎么重用的耗資源視圖，可以等到需要的時候再加載，提高UI渲染速度；

  
  

• 使用?ViewStub?標簽來加載一些不常用的布局；

  
  

• 動態地 inflation view 性能要比用?ViewStub?標簽的 setVisiblity 性能要好，當然某些功能的實現采用?ViewStub?標簽更合適；

  
  

• 盡量避免不必要的耗資源操作，節省寶貴的運算時間；

  
  

• 避免在 UI 線程進行繁重的操作。耗資源的操作（比如 IO 操作、網絡操作、SQL 操作、列表刷新等）耗資源的操作應用后臺進程去實現，不能占用 UI 線程，UI 線程是主線程，主線程是保持程序流暢的關鍵，應該只操作那些核心的 UI 操作，比如處理視圖的屬性和繪制；

  
  

• 最小化喚醒機制。我們常用廣播來接收那些期望響應的消息和事件，但過多的響應超過本身需求的話，會消耗多余的 Android 設備性能和資源。所以應該最小化喚醒機制，當應用不關心這些消失和事件時，就關閉廣播，并慎重選擇那些要響應的 Intent 。

  
  

• 為低端設備考慮，比如 512M 內存、雙核 CPU 、低分辨率，確保你的應用可以滿足不同水平的設備。

  
  

• 優化應用的啟動速度。當應用啟動一個應用時，界面的盡快反饋顯示可以給用戶一個良好的體驗。為了啟動更快，可以延遲加載一些 UI 以及避免在應用?Application?層級初始化代碼。

6.3 善用 DEBUG 工具

• 多使用Android提供的一些調試工具去追蹤應用主要功能的性能情況；

• 多使用Android提供的一些調試工具去追蹤應用主要功能的內存分配情況；

來源：http://www.apkbus.com/blog-873057-72671.html