1 Android 渲染流程

一般情況下，一個布局寫好以后，使用 Activity#setContentView 調(diào)用該布局，這個 View tree 就創(chuàng)建好了。Activity#setContentView 其實是通過 LayoutInflate 來把布局文件轉(zhuǎn)化為 View tree 的（反射）。需要注意的是，LayoutInflate 雖然可以幫助創(chuàng)建 View tree，但到這里也僅是以單純的對象數(shù)據(jù)存在，這個時候是無法正確的獲取 View 的 GUI（Graphical User Interface 圖形用戶界面）的相關(guān)屬性的，如大小、位置和渲染狀態(tài)。

View tree 生成的最后一步就是把根節(jié)點送到 ViewRootImpl#setView 中，之后就會進入渲染流程，入口方法是 ViewRootImpl#requestLayout，之后是 ViewRootImpl#scheduleTraversals，最后調(diào)用的是 ViewRootImpl#performTraversals，View tree 的渲染流程全都在這里，也就是常說的 measure、layout、draw。View體系與自定義View（三）—— View的繪制流程

以下為 View 的繪制流程/視圖添加到 Window 的過程：

總結(jié)：文本數(shù)據(jù)（xml）—> 實例數(shù)據(jù)（java） —> 圖像數(shù)據(jù) bitmap，bitmap 才是屏幕（硬件）所需的數(shù)據(jù)。

在 ViewRootImpl#drawSoftware 方法中會通過 Surface#lockCanvas 方法創(chuàng)建一個 Canvas（在英文中是“畫布”的意思） 對象，然后進入 View#draw 流程，Canvas 才是實際制作圖像的工具，比如如何畫點，如何畫線，如何畫文字、圖片等等。

// /frameworks/base/core/java/android/view/ViewRootImpl.java
public final Surface mSurface = new Surface();
private boolean draw(boolean fullRedrawNeeded, boolean forceDraw) {Surface surface = mSurface; // 1...if (!drawSoftware(surface, mAttachInfo, xOffset, yOffset,scalingRequired, dirty, surfaceInsets)) {return false;}}private boolean drawSoftware(Surface surface, AttachInfo attachInfo, int xoff, int yoff, boolean scalingRequired, Rect dirty, Rect surfaceInsets) {// Draw with software renderer.final Canvas canvas; // 2try {canvas = mSurface.lockCanvas(dirty); // 3canvas.setDensity(mDensity);} catch (Surface.OutOfResourcesException e) {handleOutOfResourcesException(e);return false;} catch (IllegalArgumentException e) {mLayoutRequested = true;    // ask wm for a new surface next time.return false;}try {...mView.draw(canvas);...}finally {...    }
} 

一個 Canvas 對象從 ViewRootImpl 傳給 View，View 的各個方法（draw、dispatchDraw 和 drawChild）都只接收 Canvas 對象，每個 View 都要把其想要展示的內(nèi)容傳遞到 Canvas 對象中。

// /frameworks/base/core/java/android/view/View.java
public void draw(@NonNull Canvas canvas) {...
}protected void dispatchDraw(@NonNull Canvas canvas) { }// /frameworks/base/core/java/android/view/ViewGroup.java
protected boolean drawChild(@NonNull Canvas canvas, View child, long drawingTime) {return child.draw(canvas, this, drawingTime);
}

在 Canvas 中有一個 Bitmap 類型的對象，這個 Bitmap 才是真正的畫布。

// /frameworks/base/graphics/java/android/graphics/Canvas.java
public class Canvas extends BaseCanvas {private Bitmap mBitmap;
}

那么，Surface 是什么呢？以下是 Surface 的部分源碼：

/*** Handle onto a raw buffer that is being managed by the screen * 由屏幕管理的原始緩沖區(qū)*/
public class Surface implements Parcelable {private final Canvas mCanvas = new CompatibleCanvas();public Canvas lockCanvas(Rect inOutDirty)throws Surface.OutOfResourcesException, IllegalArgumentException {synchronized (mLock) {checkNotReleasedLocked();if (mLockedObject != 0) {throw new IllegalArgumentException("Surface was already locked");}mLockedObject = nativeLockCanvas(mNativeObject, mCanvas, inOutDirty);return mCanvas;}}
}

從注釋上可以知道，Surface 是一塊原始緩沖區(qū)。 在 Android 中，所有的 View 都由窗口管理，而每個窗口都會關(guān)聯(lián)一個 Surface。在屏幕上繪制內(nèi)容之前，都需要先獲得 Surface，然后用 2D/3D 引擎（Skia/OpenGL）在這個緩沖區(qū)上繪制內(nèi)容。 繪制完成之后，會通知 SurfaceFlinger 將繪制內(nèi)容（Frame Buffer）渲染到屏幕上去。關(guān)于 SurfaceFlinger，之后會做詳細解釋。

屏幕渲染分為軟件渲染和硬件渲染，Canvas 對象的來源也有兩個：

• 一是走軟件渲染時，在 ViewRootImpl 中創(chuàng)建，從源碼上看，ViewRootImpl 本身就會創(chuàng)建一個 Surface 對象，然后用 Surface 獲取出一個 Canvas 對象，再傳遞給 View，由 View 進行具體的繪制；
• 二是走硬件加速，會由 hwui 創(chuàng)建 Canvas 對象；

因此，draw 的觸發(fā)邏輯也有兩條：

• 沒有硬件加速時，走的是 ViewRootImpl#performTraversals —> performDraw —> draw —> drawSoftware —> View#draw；
• 啟動硬件加速時，走的是 ViewRootImpl#performTraversals —> performDraw —> draw —> ThreadedRenderer.java#draw

2 軟件繪制和硬件繪制

Android 4.0 開始引入硬件加速機制，之前走的都是軟件渲染。如果有一些 API 是不支持硬件加速的，需要進行手動關(guān)閉。

UI 渲染需要要依賴兩個核心的硬件，CPU 和 GPU：

• CPU（Center Processing Unit 中央處理器），是計算機系統(tǒng)的運算和控制核心，是信息處理、程序運行的最終執(zhí)行單元；
• GPU（Graphics Processing Unit 圖形處理器），是一種專門用于圖像運算的處理器，在加計算機系統(tǒng)中通常被稱為“顯卡”的核心部位就是 GPU；

在沒有 GPU 的時代，UI 的繪制任務(wù)都是由 CPU 完成的，也就是說，CPU 除了負責邏輯運算、內(nèi)存管理還要負責 UI 繪制，這就導(dǎo)致 CPU 的任務(wù)繁重，性能也會受到影響。

CPU 和 GPU 在結(jié)構(gòu)設(shè)計上完全不同，如下所示：

• 黃色部分：Control 控制器，用于協(xié)調(diào)控制整個 CPU 的運行，包括讀取指令、控制其他模塊的運行等；
• 綠色部分：ALU（Arithmetic Logic Unit）是算數(shù)邏輯單元，用于進行數(shù)學、邏輯運算；
• 橙色部分：Cache 和 DRAM 分別為高速緩存和 RAM，用于存儲信息；

從上圖可以看出，CPU 的控制器較為復(fù)雜，而 ALU 數(shù)量較少，因此 CPU 更擅長各種復(fù)雜的邏輯運算，而不擅長數(shù)學尤其是浮點運算。而 GPU 的設(shè)計正是為了實現(xiàn)大量的數(shù)學運算。GPU 的控制器比較簡單，但包含大量的 ALU，GPU 中的 ALU 使用了并行設(shè)計，且具有較多的浮點運算單元，可以幫助我們加快 Rasterization（柵格化）操作。

柵格化將 UI 組件拆分到顯示器上的不同像素上進行顯示。UI 組件在繪制到屏幕之前都要經(jīng)過 Rasterization（柵格化）操作，是繪制 Button、Shape、Path、String、Bitmap 等顯示組件最基礎(chǔ)的操作。這是一個非常耗時的操作，GPU 的引入就是為了加快柵格化。

因此，硬件繪制的思想就是 CPU 將 XML 數(shù)據(jù)轉(zhuǎn)換成實例對象，然后將 CPU 不擅長的圖形計算交由 GPU 去處理，由 GPU 完成繪制任務(wù)，以便實現(xiàn)更好的性能（CPU 和 GPU 都是制圖者）。

底層圖像庫有很多，Android 選擇的是 Skia(2D) 和 OpenGL(3D) 來繪制圖形，圖形庫可以直接控制 GPU 產(chǎn)生圖形數(shù)據(jù)（Canvas.draw —> native —>Skia/OpenGL —> GPU）。

軟件繪制使用的是 Skia 庫，是一款能在低端設(shè)備，如手機上呈現(xiàn)高質(zhì)量的 2D 跨平臺圖形框架，Chrome、Flutter 內(nèi)部使用的都是 Skia 庫。需要注意的是，軟件繪制使用的是 Skia 庫，但這并不代表 Skia 庫不支持硬件加速，從 Android 8 開始，我們可以使用 Skia 進行硬件加速，Android 9 開始默認使用Skia 進行硬件加速。

在處理 3D 場景時，通常使用 OpenGL ES。在 Android 7.0 中添加了對 Vulkan 的支持。Vulkan 的設(shè)計目標是取代 OpenGL，Vulkan 是個相當?shù)图墑e的 API，并且提供了并行的任務(wù)處理。除了較低的 CPU 的使用率，VulKan 還能夠更好的在多個 CPU 內(nèi)核之間分配工作。在功耗、多核優(yōu)化提升會圖調(diào)用上有非常明顯的優(yōu)勢。

Skia、OpenGL、Vulkan 的區(qū)別：

• Skia：是 2D 圖形渲染庫。如果想完成 3D 效果需要 OpenGL、Vulkan、Metal 進行支持。Android 8 開始 Skia 支持硬件加速，Chrome、Flutter 都是用它來完成繪制的；
• OpenGL：是一種跨平臺的 2D/3D 圖形繪制規(guī)范接口，OpenGL ES 是針對嵌入式設(shè)備的，對手機做了優(yōu)化；
• Vulkan：Vulkan 是用來替換 OpenGL 的，它同時支持 2D 和 3D 繪制，也更加輕量級；

3 Android 黃油計劃（Project Butter）

雖然引入了硬件加速機制，加快了渲染的時間，但是對于 GUI（Graphical User Interface 圖形用戶界面）的流暢度、響應(yīng)度，特別是動畫這一塊的流暢程度和其他平臺（如 Apple）差距仍然是很大的。一個重要的原因就在于，GUI 整體的渲染缺少協(xié)同。 最大的問題在于動畫，動畫要求連續(xù)不斷的重繪，如果僅靠客戶端來觸發(fā)，幀率不夠，由此造成的流暢度也不好。

Google 在 2012 年的 I/O 大會上宣布了 Project Butter 黃油計劃，并且在 Android 4.1 中正式開啟這個機制。Project Butter 主要包含三個組成部分：

• VSync
• Choreographer
• TripBuffer

其中，VSync（Vertical Synchronization） 是理解 Project Butter 的核心。

3.1 VSync

幀率 vs 屏幕刷新頻率：

• 幀率（Frame Rate）：單位 fps，即 GPU 在一秒內(nèi)生成的幀數(shù)（圖片），幀率越高越好。例如電影界采用 24 幀的速度就可以畫面非常流暢了，而 Android 系統(tǒng)則采用更高的 60fps，即每秒生成 60 幀的畫面，也就是 1000/60 ≈ 16ms 生成一幀畫面；
  • 12 fps：由于人類眼睛的特殊生理結(jié)構(gòu)，如果所看畫面幀率高于 10～12 fps 的時候，就會認為是連貫的；
  • 24fps：有聲電影的拍攝及播放幀率均為 24fps，對一般人來說是可以接受的；
  • 30fps：早起的高動態(tài)電子游戲，幀率小于 30fps 時就會顯得不連貫，這是因為沒有動態(tài)模糊使流暢度降低；
  • 60fps：在與手機交互過程中，如果觸摸和反饋在 60fps 以下是可以被人感覺出來的，會感到畫面卡頓和遲滯現(xiàn)象；
• 屏幕刷新頻率（Refresh Rate）：單位是赫茲（Hz），表示屏幕在一秒內(nèi)刷新畫面的次數(shù)，刷新頻率取決于硬件的固定參數(shù)，該值對于特定的設(shè)備來說是一個常量。如 60Hz、144 Hz 表示每秒刷新 60 次或 144 次。

對于一個特定的設(shè)備來說，幀率和屏幕刷新速率沒有必然的關(guān)系。但是兩者需要協(xié)同工作，才能正確的獲取圖像數(shù)據(jù)并進行繪制。比如 Android 手機的刷新頻率是 60Hz，那么一幀數(shù)據(jù)需要在 16ms 內(nèi)完成。

屏幕并不是一次性的顯示畫面的，而是從左到右（行刷新，水平刷新，Horizontal Scanning）、從上到下（屏幕刷新，垂直刷新，Vertiacl Scanning）逐行掃描顯示，不過這一過程快到人眼無法察覺。以 60Hz 的刷新頻率的屏幕為例，即 1000/60 ≈ 16ms，16ms 刷新一次。

如果上一幀的掃描沒有結(jié)束，屏幕又開始掃描下一幀，就會出現(xiàn)掃描撕裂的情況：

因此，GPU 廠商開發(fā)出了一種防止屏幕撕裂的技術(shù)方案 —— Vertical Synchronization，即 VSync，垂直同步信號或時鐘中斷。VSync 是一個硬件信號，它和顯示器的刷新頻率相對應(yīng)，每當屏幕完成一次垂直刷新，VSync 信號就會被發(fā)出，作為顯示器和圖形引擎之間時間同步的標準，其本質(zhì)意義在于保證界面的流暢性和穩(wěn)定性。

3.2 Choreographer

Choreographer（編舞者）根據(jù) VSync 信號來對 CPU/GPU 進行繪制指導(dǎo)，協(xié)調(diào)整個渲染過程，對于輸入事件響應(yīng)、動畫和渲染在時間上進行把控，以保證流暢的用戶體驗。

Choreographer 在 ViewRootImpl 中的使用：

// /frameworks/base/core/java/android/view/ViewRootImpl.java
final Choreographer mChoreographer;
void scheduleTraversals() {if (!mTraversalScheduled) {mTraversalScheduled = true;mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);notifyRendererOfFramePending();pokeDrawLockIfNeeded();}
}final class TraversalRunnable implements Runnable {@Overridepublic void run() {doTraversal();}
}
final TraversalRunnable mTraversalRunnable = new TraversalRunnable();

Choreographer 的作用：

• 布局請求：當視圖需要進行布局操作時，Choreographer 發(fā)出布局請求并協(xié)調(diào)布局操作的執(zhí)行。它確保將布局請求與其他動畫和繪制操作同步，避免沖突和界面不一致；
• 繪制同步：Choreographer 負責將繪制操作與顯示器的刷新同步。它通過監(jiān)聽系統(tǒng)的 VSync 信號，去定繪制操作的時機，避免圖形撕裂和卡頓現(xiàn)象；
• 輸入事件處理：Choreographer 管理和分發(fā)用戶輸入事件，確保它們在正確的時間點被處理，并與動畫和渲染操作同步。這有助于提供更流暢和響應(yīng)敏捷的用戶交互體驗；
• 動畫調(diào)度：Choreographer 調(diào)度和管理應(yīng)用程序中的動畫效果，確保動畫按照預(yù)定的幀率和時間表進行播放，并平滑地過渡到下一個動畫階段；

Choreographer 使用了以下幾種機制來實現(xiàn)流暢的界面渲染：

• VSync（垂直同步信號）：Choreographer 監(jiān)聽系統(tǒng)發(fā)出的 VSync 信號。每當收到 VSync 信號時，Choreographer 就知道屏幕即將進行一次刷新。這樣，它可以根據(jù) VSync 信號的時間點來安排渲染和動畫操作的觸發(fā)和執(zhí)行；
• 時間戳（Timestamping）：Choreographer 在收到 VSync 信號時，會獲取一個時間戳，以記錄每次 VSync 信號的時間點。這個時間戳可以用于計算渲染和動畫的操作時間和持續(xù)時間，從而在合適的時機進行調(diào)度和執(zhí)行；
• 界面刷新（Frame Refresh）：Choreographer 使用 VSync 信號和時間戳來決定界面的刷新時機。它根據(jù)預(yù)定的邏輯和優(yōu)先級，調(diào)度動畫、布局和繪制操作，以確保它們在下一次 VSync 信號到來之前完成。這樣可以避免界面的撕裂或卡頓現(xiàn)象，提供流暢的用戶體驗；

其實這個 Choreogarpher 這個類本身并不會很復(fù)雜，簡單來說它就是負責定時回調(diào)，主要方法有 postFrameCallback 和 removeFrameCallback，FrameCallback 是個比較簡單的接口：

// /frameworks/base/core/java/android/view/Choreographer.java
public interface FrameCallback {public void doFrame(long frameTimeNanos);
}

3.3 TripBuffer 三緩存

3.3.1 單緩存

在沒有引入 Vsync 的時候，屏幕顯示圖像的工作流程是這樣的：

如上圖所示，CPU/GPU 將需要繪制的數(shù)據(jù)存放在圖像緩沖區(qū)中，屏幕從圖像緩沖區(qū)中獲取數(shù)據(jù)，然后刷新顯示，這是典型的生產(chǎn)者-消費者模型。

理想的情況是幀率（GPU）和刷新頻率（屏幕）相等，每繪制一幀，屏幕就顯示一幀。而實際情況是，二者之間沒有必然的聯(lián)系，如果沒有鎖來控制同步，很容易出現(xiàn)問題。

• 如果刷新頻率大于幀率的時候，屏幕拿不到下一幀數(shù)據(jù)，就會重復(fù)繪制當前幀數(shù)據(jù)。
• 如當幀率大于刷新頻率時，屏幕還沒有刷新到 n-1 幀的時候，GPU 已經(jīng)生成第 n 幀了，屏幕刷新的時候繪制的就是第 n 幀數(shù)據(jù)，這個時候屏幕上半部分顯示的是第 n 幀數(shù)據(jù)，屏幕的下半部分顯示的是第 n-1 幀之前的數(shù)據(jù)，這樣顯示的圖像就會出現(xiàn)明顯的偏差，也就是“tearing”，如下所示：
  
  

3.3.2 雙緩存（Double Buffer）

這里的雙緩存和計算機組成原理中的“二級緩存”不是一回事。

為了解決單緩存的 tearing 問題，雙緩存和 VSync 應(yīng)運而生。雙緩存的模型如下所示：

兩個緩存分別為 Back Buffer 和 Frame Buffer（幀緩沖區(qū)）。GPU 向 Back Buffer 中寫數(shù)據(jù)，屏幕從 Frame Buffer 中讀數(shù)據(jù)。VSync 信號負責調(diào)用 Back Buffer 到 Frame Buffer 的復(fù)制操作，可以認為該復(fù)制操作在瞬間完成。

在雙緩沖模式下，工作流程是這樣的：在某個時間點，一個屏幕刷新周期完成，進入短暫的刷新空白期。此時，VSync 信號產(chǎn)生，先完成復(fù)制操作，然后通知 CPU/GPU 繪制下一幀圖像。復(fù)制操作完成后屏幕開始下一個刷新周期，即將剛復(fù)制到 Frame Buffer 的數(shù)據(jù)顯示到屏幕上。

在雙緩沖模型下，只有當 VSync 信號產(chǎn)生時，CPU/GPU 才會開始繪制。這樣，當幀率大于刷新頻率時，幀率就會被迫跟刷新頻率保持同步，從而避免“tearing”現(xiàn)象。

需要注意的是，當 VSync 信號發(fā)出時，如果 CPU/GPU 正在生產(chǎn)幀數(shù)據(jù)，此時不會發(fā)生復(fù)制操作。當屏幕進入下一個刷新周期時，就會從 Frame Buffer 中取出“老”數(shù)據(jù)，而非正在產(chǎn)生的幀數(shù)據(jù)，即兩個刷新周期顯示的是同一幀數(shù)據(jù)，這就是“掉幀”現(xiàn)象（Dropped Frame，Skipped Frame，Jank）。因此，雙緩存的缺陷在于，當 CPU/GPU 繪制一幀的時間超過 16ms 時，就會產(chǎn)生 Jank。

如下圖所示，A、B 和 C 都是 Buffer。藍色代表 CPU 生成的幀數(shù)據(jù)，綠色代表 GPU 執(zhí)行生成幀數(shù)據(jù)，黃色代表生成幀完成：

CPU/GPU 處理數(shù)據(jù)的時間過長，超過了一幀繪制的時間，在第二個時間段內(nèi)，由于 GPU 還在處理 B 幀數(shù)據(jù)，無法進行數(shù)據(jù)交換，導(dǎo)致 A 幀被重復(fù)繪制。而 B 幀數(shù)據(jù)在繪制完成后又缺乏 VSync 信號，只能等待下一次的 VSync 信號的來臨。因此，在這一過程中，有一段時間是被浪費的。

3.3.3 三緩存（Triple Buffer）

于是有了三緩存：

工作原理同雙緩沖類似，只是多了一個 Back Buffer。三緩沖機制有效的利用了等待 VSync 信號的時間，可以幫助我們減少 jank。

如果有第三個 Buffer 能讓 CPU/GPU 在這個時候繼續(xù)工作，那就完全可以避免第二個 Jank 產(chǎn)生了。

需要注意的是，第三個緩存并不是總存在的，只有當需要的時候才會創(chuàng)建。 之所以這樣，是因此三緩存會顯著增加用戶輸入到顯示的延遲時間。如上圖，幀 C 是在第 2 個刷新周期產(chǎn)生的，卻是在第 4 個周期顯示的。

4 Android 渲染的整體架構(gòu)

以下是 Android 渲染的整體架構(gòu)：

Android 渲染的整體架構(gòu)可以分為以下幾部分：

• 圖像生產(chǎn)者（image stream producers）：主要有 MediaPlayer、CameraPreview、NDK(Skia)、OpenGL ES。其中，MediaPlayer 和 Camera Preview 是通過直接讀取圖像源來生成圖像數(shù)據(jù)。NDK(Skia)、OpenGL ES 是通過自身的繪制能力產(chǎn)生的圖像數(shù)據(jù)。
• 圖像緩沖區(qū)（BufferQueue）：一般是三緩沖區(qū)。NDK(Skia)、OpenGL ES、Vulkan 將繪制的數(shù)據(jù)存放在圖像緩沖區(qū)；
• 圖像消費者（image stream consumers）： SurfaceFlinger 從圖像緩沖區(qū)將數(shù)據(jù)取出，通過硬件合成器 Hardware Composer 進行加工及合成 layer，最終交給 HAL 展示；
• HAL：硬件抽象層，把圖形數(shù)據(jù)展示到設(shè)備屏幕；

整個圖像渲染系統(tǒng)就是采用了生產(chǎn)者-消費者模式，屏幕渲染的核心，是對圖像數(shù)據(jù)的生產(chǎn)和消費。 生產(chǎn)和消費的對象是 BufferQueue 中的 Buffer。

前面我們已經(jīng)說過，Surface 是一塊原始緩沖區(qū)，每個窗口都會管理一個 Surface，屏幕在繪制內(nèi)容之前，先要獲得 Surface，然后在再用 2D/3D 引擎（Skia/OpenGL）在這個緩沖區(qū)上進行繪制（Surface —> Canvas）。

SurfaceFlinger 是圖像數(shù)據(jù)的消費者，它的作用主要是接收 Graphic Buffer，然后交給 HWComposer 合成，合成完的數(shù)據(jù)，最終交給了 Frame Buffer(幀緩沖區(qū))。

軟件渲染

再沒有硬件加速之前主要是通過 Skia 這種軟件方式渲染 UI，如下所示：

整個渲染流程看上去比較簡單，但是正如前面所說，CPU 對于圖形處理器并不是那么高效，這個過程完全沒有利用 GPU 的高性能。

硬件渲染

Android 3.0，支持硬件加速，需要手動打開，Android 4.0 就默認開啟硬件加速了，開啟硬件加速流程如下：

硬件加速繪制最核心就是通過 GPU 完成 Graphic Buffer 的內(nèi)容繪制。

RenderThread 線程

經(jīng)過 Android 4.1 的 Projcet Butter 黃油計劃之后，Android 的渲染性有了很大的改善。不過你有沒有注意到這樣一個問題，雖然利用了 GPU 的圖形高性能運算，但是從計算到通過 GPU 繪制到 Frame Buffer，整個計算和繪制都在 UI 主線程中完成。UI 線程任務(wù)過于繁重。如果整個渲染過程比較耗時，可能造成無法響應(yīng)用戶的操作，進而出現(xiàn)卡頓的情況。GPU 對圖形的渲染能力更勝一籌，如果使用 GPU 并在不同的線程繪制渲染圖形，那么整個流程會更加順暢。

在 Android 5.0 之通過引進 RenderThread（渲染線程），我們就可將 UI 渲染工作從 Main Thread 釋放出來，交由 RenderThread 來處理，從而也使得 Main Thread 可以更專注高效地處理用戶輸入，這樣使得在提高 UI 繪制效率的同時，也使得 UI 具有更高的響應(yīng)。