深入理解Android的渲染機制
基礎知識
CPU: 中央處理器,它集成了運算,緩沖,控制等單元,包括繪圖功能.CPU將對象處理為多維圖形,紋理(Bitmaps、Drawables等都是一起打包到統一的紋理)。
GPU:一個類似于CPU的專門用來處理Graphics的處理器, 作用用來幫助加快格柵化操作,當然,也有相應的緩存數據(例如緩存已經光柵化過的bitmap等)機制。
OpenGL ES：是手持嵌入式設備的3DAPI,跨平臺的、功能完善的2D和3D圖形應用程序接口API,有一套固定渲染管線流程. OpenGL ES詳解
DisplayList 在Android把XML布局文件轉換成GPU能夠識別并繪制的對象。這個操作是在DisplayList的幫助下完成的。DisplayList持有所有將要交給GPU繪制到屏幕上的數據信息。
格柵化 是 將圖片等矢量資源,轉化為一格格像素點的像素圖,顯示到屏幕上。
垂直同步VSYNC:讓顯卡的運算和顯示器刷新率一致以穩定輸出的畫面質量。它告知GPU在載入新幀之前，要等待屏幕繪制完成前一幀。下面的三張圖分別是GPU和硬件同步所發生的情況,Refresh Rate:屏幕一秒內刷新屏幕的次數,由硬件決定,例如60Hz.而Frame Rate:GPU一秒繪制操作的幀數,單位是30fps,正常情況過程圖如下：
渲染機制分析
渲染流程簡介
Android整體的繪制流程如下：
UI對象—->CPU處理為多維圖形,紋理 —–通過OpeGL ES接口調用GPU—-> GPU對圖進行光柵化(Frame Rate ) —->硬件時鐘(Refresh Rate)—-垂直同步—->投射到屏幕
Android系統每隔16ms發出VSYNC信號(1000ms/60=16.66ms)，觸發對UI進行渲染， 如果每次渲染都成功，這樣就能夠達到流暢的畫面所需要的60fps，為了能夠實現60fps，這意味著計算渲染的大多數操作都必須在16ms內完成。
渲染時間線
正常情況下Android的GPU會在16ms完成頁面的繪制，如果一幀畫面渲染時間超過16ms的時候,垂直同步機制會讓顯示器硬件 等待GPU完成柵格化渲染操作,然后再次繪制界面，這樣就會看起來畫面停頓。
當GPU渲染速度過慢,就會導致如下情況,某些幀顯示的畫面內容就會與上一幀的畫面相同。
渲染常見問題
GPU過度繪制
OverDraw是開發中常見的優化點，是指一個界面出現層層繪制的情況，如：
我們可以使用一些第三方工具來查看是否過渡繪制。如小米魅族。
任何時候View中的繪制內容發生變化時，都會重新執行創建DisplayList，渲染DisplayList，更新到屏幕上等一 系列操作。這個流程的表現性能取決于你的View的復雜程度，View的狀態變化以及渲染管道的執行性能。
當View的大小發生改變,DisplayList就會重新創建,然后再渲染,而當View發生位移,則DisplayList不會重新創建,而是執行重新渲染的操作。
所以當界面過于復雜的時候，DisplayList繪制界面就會出現延遲而造成卡頓。
我們可以使用渲染工具檢測，工具中,不同手機呈現方式可能會有差別.分別關于StatusBar，NavBar，激活的程序Activity區域的GPU Rending信息。激活的程序Activity區域的GPU Rending信息。
我們打開手機的GPU Rending呈現的信息，我們以魅族為例：
說明：每一條柱狀線都包含三部分，
藍色代表測量繪制Display List的時間，
紅色代表OpenGL渲染Display List所需要的時間，
黃色代表CPU等待GPU處理的時間。
Android渲染優化
讀懂Android的渲染機制對于優化，特別是在寫布局的時候是很有幫助的。減少布局層級，減少GPU的渲染這對我們提供app的質量是很有幫助的。
去掉不必要的界面：
布局層級優化
使用Hierarchy Viewer工具可以查看界面的層級，關于這塊的介紹請查看我之前的博客：Android布局優化
當然Android在某些系統版本也增加了檢測overdraw的工具。如Android 在4。2版本中增加了Debug GPU Overdraw選項，如果你用的是Jelly Bean 4.3 或者 KitKat 設備，在屏幕的左下角會有一個計數展示屏幕overdraw的程度。
另一種查看overdraw的方式是在Debug GPU overdraw菜單里選擇“Show Overdraw areas”選項。選擇之后，會在app的不同區域覆蓋不同的顏色來表示overdraw的次數。比較屏幕上這些不同的顏色，可以快速方便的定位overdraw問題。
圖片格式選擇
Android的界面能用png最好是用png了，因為32位的png顏色過渡平滑且支持透明。jpg是像素化壓縮過的圖片，質量已經下降了，再拿來做9path的按鈕和平鋪拉伸的控件必然慘不忍睹，要盡量避免。有條件的可以選擇webpp，這種格式的圖片占據的大小比較小，并且能滿足手機顯示的需要。
當背景無法避免,盡量用Color.TRANSPARENT
因為透明色Color.TRANSPARENT是不會被渲染的,他是透明的。
所以我們在設置界面的時候需要做一個判斷：
- Bean bean=list.get(i);
- if (bean.img == 0) {
- Picasso.with(getContext()).load(android.R.color.transparent).into(holder.imageView);
- holder.imageView.setBackgroundColor(bean.backPic);
- } else {
- Picasso.with(getContext()).load(bean.img).into(holder.imageView);
- holder.imageView.setBackgroundColor(Color.TRANSPARENT);
- }
