這應該是目前最系統的 Android 界面性能調優資料了

Android界面性能調優手冊

注：本文是我在 Android 界面性能調優知識的系統性總結，純屬個人碎碎念。秉持開源分享的原則發佈本文出來，各位看官有需則取。原文見：https://androidtest.org/android-graphics-performance-pattens/

界面是 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 標籤；
• ……

更多 Lint 的官方介紹「 戳我 」。

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 ；
• 將可重複使用的組件抽取出來並用 </include> 標籤進行重用。如果應用多個地方的 UI 用到某個佈局，就將其寫成一個佈局部件，便於各個 UI 重用。官方詳解 「 戳我 」
• 使用 merge 標籤減少佈局的嵌套層次，官方詳解 「 戳我 」；
• 去掉多餘的不可見背景。有多層背景顏色的佈局，只留最上層的對用戶可見的顏色即可，其他用戶不可見的底層顏色可以去掉，減少無效的繪製操作；
• 儘量避免使用 layout_weight 屬性。使用包含 layout_weight 屬性的線性佈局 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提供的一些調試工具去追蹤應用主要功能的內存分配情況；

附錄Appendix

---

本文首發於androidtest.org：《Android界面性能調優手冊》

參考文章

• Developing for Android I Understanding the Mobile Context
• Developing for Android IX Tools
• Training for Android developers
• Android developers
• Google developers
• Google I/O 2013

知識共享許可協議

採用 知識共享署名 3.0 中國大陸許可協議 進行許可。可自由轉載、引用，但需署名作者且註明文章出處。