背景

在當(dāng)下移動互聯(lián)網(wǎng)后半場，手機已經(jīng)是人手必備的設(shè)備。App是離用戶最近的應(yīng)用，界面又是最直觀影響用戶體驗的關(guān)鍵部分，其流暢度直接影響用戶對產(chǎn)品的評價和留存。

技術(shù)是服務(wù)于人的，如果技術(shù)無法給你帶來良好的體驗，那技術(shù)本身的存在就具有爭議。

所以界面性能是至關(guān)重要的，不可忽視。

實踐過程

布局代碼是最基礎(chǔ)的，但也是最重要的。

首先我們看個簡單小案例

不同深淺的顏色來表示過度繪制：

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

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

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

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

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

如何渲染界面

CPU(中央處理器) :我們經(jīng)常聽到，是計算機的核心器件，多緩存多分支,適用于復(fù)雜的邏輯運算,主要負(fù)責(zé)Measure，Layout，Record，Execute的計算操作

GPU(圖像處理器):我們通常說的顯卡核心就是它了。用于結(jié)構(gòu)單一的數(shù)據(jù)處理（擅長圖形計算），主要負(fù)責(zé)Rasterization(柵格化)操作

谷歌官方對于流暢度的優(yōu)化也是高度重視的，有界面渲染三核心Vsync、Triple Buffer和Choreographer。

為何是16ms/為何每秒60幀

android系統(tǒng)每隔16ms繪制一幀UI且要在16ms內(nèi)完成，（ 1秒 / 0.016幀每秒 = 62.5幀/秒 ）差不多每秒更新60次。這是因為我們大腦和眼睛一般看24Fps的畫面就已經(jīng)是連續(xù)的運動了，看60Fps的畫面更看不出端倪，但是60幀可以表達出更加絢麗多彩的內(nèi)容。

一旦沒及時繪制，就會出現(xiàn)掉幀問題，也就是常說的卡頓。這是因為繪制的東西太多的話，CPU、GPU處理不及時。

當(dāng)然了，設(shè)備性能越好，處理能力越強，卡頓會越少，玩游戲的電腦配置高也是出于這方面考慮。

那么Android是如何把圖像繪制到界面上的呢？

這就用到了上面的CPU/GPU。

GPU負(fù)責(zé)柵格化操作（Resterization），柵格化是繪制那些Button，Shape，Path，String，Bitmap等組件最基礎(chǔ)的操作。它把那些組件拆分到不同的像素上進行顯示。這是一個很“費時”的操作（相比人類時間只是眨眼的功夫），GPU的引入就是為了加快柵格化的操作。

CPU負(fù)責(zé)把UI組件計算成Polygons，Texture紋理，然后交給GPU進行柵格化渲染。流程如下：

為了能夠使得App流暢，我們需要在每一幀16ms以內(nèi)處理完所有的CPU與GPU計算，繪制，渲染等等操作。

有興趣更深層學(xué)習(xí)的，可以去看看界面渲染容器DisplayList

什么是過度繪制

Overdraw(過度繪制)描述的是屏幕上的某個像素在同一幀的時間內(nèi)被繪制了N次。但是我們只能看到最上層的UI，這就會導(dǎo)致多層次的UI界面除最上層外對用戶都是不可見的，這樣就會浪費大量的CPU以及GPU資源，浪費可恥。

這就像我們在紙上固定區(qū)域不斷圖畫，但是有最上層最接近你，其他層有個鬼用？

如何查看繪制維度

開發(fā)工具有Hierarchy View、Systrace、Track等

真機在開發(fā)者選項中有：調(diào)試GPU繪制、硬件層更新、GPU視圖更新等等

界面優(yōu)化

在編寫Android布局時總會遇到這樣或者那樣的痛點，比如：

1.有些布局的在很多頁面都用到了，而且樣式都一樣，每次用到都要復(fù)制粘貼一大段，有沒有辦法可以復(fù)用呢？2.解決了1中的問題之后，發(fā)現(xiàn)復(fù)用的布局外面總要額外套上一層布局，要知道布局嵌套是會影響性能的吶；3.有些布局只有用到時才會顯示，但是必須提前寫好，雖然設(shè)置了為invisible或gone，還是多多少少會占用內(nèi)存的。

首先第一點也是最重要的一點，在剛開始寫布局的時候一定要提前想好和規(guī)劃好，盡可能的減少層級的嵌套。往往越復(fù)雜的布局越臃腫，越容易被忽視進而出現(xiàn)性能問題，所以我們寫布局就要知道一些技巧來展示布局

1. 如果圖片和文字在一起且文字不動態(tài)變的話，可以直接使用帶文字的圖片。

2. 移除沒用的布局和控件，假設(shè)添加個背景，盡可能在已經(jīng)布局上放，減少只有背景功能的控件。

3. 減少透明度的使用，假設(shè)：#55FFFFFF 和 #888888 顏色類似，建議使用后者，因為前者有Alpha，view需要至少繪制兩次。

4. 去掉多余的不可見顏色背景、圖片等，只保留最上層用戶可見即可

5. 減少布局層次結(jié)構(gòu)，避免多層嵌套推薦使用RelativeLayout、ConstraintLayout等父類布局

6. 基本控件LinearLayout 性能比RelativeLayout高一些，要提前根據(jù)UI想好哪個布局更合適，要有的方式，對癥下藥。

7. 自定義View盡可能只更新渲染局部區(qū)域，杜絕不斷全部重繪。

8. 推薦使用IDE自帶的Lint或者阿里代碼檢查插件，對于標(biāo)黃警告等提示重視起來，能改的就改。

除了以上，我們就要解決過度繪制，我們還可以使用抽象布局，它們分別是include、merge和ViewStub三個標(biāo)簽，現(xiàn)在我們就來認(rèn)識認(rèn)識它們吧。

Include應(yīng)該是最常用的了，其翻譯是“包含”、“包括”，最佳使用就是把相同代碼抽離出來成一個獨立的xml文件，當(dāng)你在某個布局需要使用的時候直接include進來，這樣一搞，很好地起到復(fù)用布局的效果。不僅可以極大地減少代碼量，想要修改的話直接改這一個xml就行了。

它的兩個主要屬性：layout：必填屬性， id屬性；

我們還可以重寫寬高、邊距和可見性（visibility）這些布局屬性。但是一定要注意，單單重寫android:layout_height或者android:layout_width是不行，必須兩個同時重寫才起作用。

這些也能玩不不少花樣。

Merge介紹

凡事都有利有弊include標(biāo)簽除了上面的優(yōu)點，也有個問題就是布局嵌套。他必須有一個根布局，這也導(dǎo)致了最終布局嵌套層級可能多一層。

這時候又引出個新的標(biāo)簽標(biāo)簽，這次先說他的局限性：就是你需要提前明確要放到什么父布局中，然后提前設(shè)置好merge里面的控件位置。

優(yōu)點也明顯：他是消除多余層級的，標(biāo)簽必須作為根節(jié)點出現(xiàn)。不占用空間，他只是將子view“搬運”到你想嵌套的位置。

ViewStub

寫布局的時候我們經(jīng)常會遇到有些效果不必一直顯示，需要動態(tài)的來設(shè)置invisible或gone，這無形中影響了頁面加載速度。

Android提供的方案就是ViewStub，他是一個不可見的大小為0的視圖，具有懶加載功能，存在于視圖中，但只有設(shè)置setVisibility()和inflate()方法調(diào)用后才會渲染填充視圖，能為初始化加載xml布局分散壓力，就像負(fù)載均衡。

使用案例：進度條，加載網(wǎng)絡(luò)失敗，顯示錯誤消息等等

它有以下三個重要屬性：

android:layout：ViewStub需要填充的視圖名稱，為“R.layout.xx”的形式；

android:inflateId：重寫被填充的視圖的父布局id。

與include標(biāo)簽不同，ViewStub的android:id屬性是設(shè)置ViewStub本身id的，而不是重寫布局id，這一點可不要搞錯了。另外，ViewStub還提供了OnInflateListener接口，用于監(jiān)聽布局是否已經(jīng)加載了。

但是注意 viewStub.inflate();方法不能多次調(diào)用，否則拋出異常：

java.lang.IllegalStateException: ViewStubmusthaveanon-nullViewGroupviewParent

原因是ViewStub源碼調(diào)用了removeViewInLayout()方法把自己從布局移除了。到這里我們就明白了，ViewStub在填充布局成功之后就會自我銷毀，再次調(diào)用inflate()方法就會拋出IllegalStateException異常了。此時如果想要再次顯示布局，可以調(diào)用setVisibility()方法。

還有一個大坑：viewStub.getVisibility()的值一直為0，所以用他來判斷是否顯示沒作用。不要急，其實是setVisibility()方法實際上在設(shè)置內(nèi)部視圖的可見性，而不是ViewStub本身。

硬件加速原理

相信經(jīng)常看到有的文章說開啟硬件加速解決卡的問題，但硬件加速是什么呢？

硬件加速的主要原理是通多底層邏輯，將CPU不擅長的圖形計算轉(zhuǎn)換成GPU專用指令，讓更擅長圖形計算的GPU來完成渲染。

硬件加速過程中包含兩個步驟 ：

構(gòu)建階段 ： 遍歷所有視圖，將需要繪制的操作緩存下來，交給單獨的Render線程使用GPU進行硬件加速渲染。(這一階段在主線程中使用CPU構(gòu)建)

繪制階段 ： 調(diào)用OpenGL（即使用GPU）對構(gòu)建好的視圖進行繪制渲染，繪制的內(nèi)容保存在Graphic Buffer 并交由 SurfaceFlinger 顯示。(Android 5.0+ 使用Render Thread線程，專門負(fù)責(zé) UI 渲染和動畫顯示。)

以上證得硬件加速具有不錯的優(yōu)點，但它不是萬能的。

我們平時用的時候可能是直接在Application中用，一鍋端，這并不嚴(yán)謹(jǐn)，因為硬件加速還沒法做到支持所有的繪制操作（比如復(fù)雜的自定義View），這樣的話就會造成一定的影響：

1. 像素錯位等視覺問題

2. 不同設(shè)備版本API兼容問題

解決這些問題官方給了解決方案：使用四種級別控制是否硬件加速。

1. Application

2. Activity-為單獨頁面設(shè)置

3. Window級別

4. 單獨的view級別關(guān)閉加速（View目前不支持動態(tài)啟動硬件加速）

總結(jié)