Android繪製UI有兩種繪製模型：一是軟件繪製模型；二是硬件加速繪製模型。
軟件繪製模型
由CPU主導的，主要有兩個步驟
- 讓視圖結構(view hierarchy)失效
- 繪製整個視圖結構。
具體來說當應用程序需要更新它的部分UI時，都會調用內容發生改變的View對象的invalidate()方法。無效（invalidation）消息請求會在View對象層次結構中傳遞，以便計算出需要重繪的屏幕區域（髒區）。然後，Android系統會在View層次結構中繪製所有的跟髒區相交的區域。
存在的缺陷
- 繪製了不需要重繪的視圖（與髒區域相交的區域）
- 掩蓋了一些應用的bug（由於會重繪與髒區域相交的區域）
硬件加速繪製模型
由GPU主導的，主要有三個步驟
- 讓視圖結構失效。
- 記錄和更新顯示列表（Display List)。
- 繪製顯示列表。
具體來說就是Android系統依然會使用invalidate()方法和draw()方法來請求屏幕更新和展現View對象。但Android系統並不是立即執行繪製命令，而是首先把這些View的繪製函數作爲繪製指令記錄一個顯示列表中，然後再讀取顯示列表中的繪製指令調用OpenGL相關函數完成實際繪製。
另一個優化是，Android系統只需要針對由invalidate()方法調用所標記的View對象的髒區進行記錄和更新顯示列表。沒有失效的View對象就簡單重用先前顯示列表記錄的繪製指令來進行簡單的重繪工作。
使用顯示列表的目的是，把視圖的各種繪製函數翻譯成繪製指令保存起來，對於沒有發生改變的視圖把原先保存的操作指令重新讀取出來重放一次就可以了，提高了視圖的顯示速度。而對於需要重繪的View，則更新顯示列表，然後再調用OpenGL完成繪製。
在這種繪製模型下，我們不能依賴一個視圖與髒區(dirty region)相交而導致它的draw()方法被自動調用，所以必須要手動調用該視圖的invalidate()方法去更新顯示列表。如果忘記這麼做可能導致視圖在改變後不會發生變化。
關於Surface，Window，View，Canvas和SurfaceView的區別
Surface
Surface就是指向顯存的一個物體，用來被繪製到屏幕上，所有你能看見的Window都擁有可以在上面繪製的Surface,在安卓中，系統使用Surface Flinger服務來把Surface按照正確的深度信息渲染到最終的屏幕上。一個Surface一般擁有超過一個（通常是２個) buffer 單元（back buffer 與 front buffer)，系統通常在back buffer中進行渲染，完成之後與front buffer交換，這樣顯示到屏幕上，以實現流暢顯示的效果。
Window
Window擁有一個Surface，在Surface裏繪製Window裏的內容。一個application通過Windows Manager來創建窗口，Windows Manager爲每一個窗口創建Surface來讓application在上面繪製各種物體。
View
View就是窗口裏的UI元素，一個窗口只擁有一個View Hierarchy，這些View Hierarchy提供了窗口裏的所有表現。當一個窗口需要重新繪製時（比如一個View invalidate自己），鎖定Surface，並返回一個Canvas用來在上面繪製，如上圖所示，在view hierarchy樹向下傳遞Canvas，來繪製每個view。這一切都完成後，Surface被解鎖，並通過Surface Flinger交換前後Buffer來顯示到屏幕上。
Canvas
Canvas是Surface繪圖時返回的一個接口，並提供一些繪圖api用來進行實際的繪圖操作。目前Canvas可以繪製在bitmap或者openGL container上。
有個很好的例子
- 畫筆：Skia 或者 OpenGL。我們可以用 Skia 畫筆繪製 2D 圖形，也可以用 OpenGL 來繪 制2D/3D圖形。正如前面所說,前者使用CPU繪製,後者使用 GPU 繪製。
- 畫紙：Surface。所有的元素都在 Surface 這張畫紙上進行繪製和渲染。在 Android 中，Window 是 View 的容器，每個窗口都會關聯一個 Surface。而 Windowmanager 則負責管理這些窗口，並且把它們的數據傳遞給 Surfaceflinger。
- 展板：Graphic Buffer。Graphic Buffer 緩衝用於應用程序圖形的繪製。
- 顯示：Surfaceflinger。它將 Windowmanager 提供的所有 Surface，通過硬件合成器 Hardware Composer 合成並輸出到顯示屏。
參考：