主線程MainThread與渲染線程RenderThread

在Android 5.0以前，Android應用程序的主線程同時也是一個Open GL線程。可是從Android 5.0以後，Android應用程序的Open GL線程就獨立出來了，稱爲Render Thread.

Android系統的UI從繪製到顯示到屏幕是分兩步進行的：第一步是在Android應用程序進程這一側進行的；第二步是在SurfaceFlinger進程這一側進行的。前一步將UI繪製到一個圖形緩衝區中，而且將該圖形緩衝區交給後一步進行合成以及顯示在屏幕中。其中，後一步的UI合成一直都是以硬件加速方式完成的。

 注：在3.0前，Android應用程序UI繪製不支持硬件加速。不過從4.0開始，Android系統一直以「run fast, smooth, and responsively」爲目標對UI進行優化。 注意，上面咱們說Android系統不支持硬件加速的UI 繪製，針對的是Android應用程序2D UI繪製;  對於3D UI，例如遊戲，一直是支持硬件加速渲染的。

 

在支持Android應用程序UI硬件加速渲染以前，Android應用程序UI的繪製是以軟件方式進行的，爲了更好地理解Android應用程序UI硬件加速渲染技術，咱們先回顧在Android應用程序窗口（Activity）實現框架簡要介紹和學習計劃這個系列的文章說起的軟件渲染技術，如圖1所示：

圖1 Android應用程序UI軟件渲染過程

      在Android應用程序進程這一側，每個窗口都關聯有一個Surface。每當窗口須要繪製UI時，就會調用其關聯的Surface的成員函數lock得到一個Canvas，其本質上是向SurfaceFlinger服務Dequeue一個Graphic Buffer。Canvas封裝了由Skia提供的2D UI繪製接口，而且都是在前面得到的Graphic Buffer上面進行繪製的。繪製完成以後，Android應用程序進程再調用前面得到的Canvas的成員函數unlockAndPost請求顯示在屏幕中，其本質上是向SurfaceFlinger服務Queue一個Graphic Buffer，以便SurfaceFlinger服務能夠對Graphic Buffer的內容進行合成，以及顯示到屏幕上去。

 

      接下來咱們再來看Android應用程序UI硬件加速渲染技術，如圖2所示：

圖2 Android應用程序UI硬件加速渲染過程    

       從圖2能夠看到，硬件加速渲染和軟件渲染同樣，在開始渲染以前，都是要先向SurfaceFlinger服務Dequeue一個Graphic Buffer。不過對硬件加速渲染來講，這個Graphic Buffer會被封裝成一個ANativeWindow，而且傳遞給Open GL進行硬件加速渲染環境初始化。在Android系統中，ANativeWindow和Surface能夠是認爲等價的，只不過是ANativeWindow經常使用於Native層中，而Surface經常使用於Java層中。另外，咱們還能夠將ANativeWindow和Surface看做是像Skia和Open GL這樣圖形渲染庫與操做系統底層的圖形系統創建鏈接的一個橋樑。

       Open GL得到了一個ANativeWindow，而且進行了硬件加速渲染環境初始化工做以後，Android應用程序就能夠調用Open GL提供的API進行UI繪製了，繪製出來內容就保存在前面得到的Graphic Buffer中。當繪製完畢，Android應用程序再調用libegl庫提供的一個eglSwapBuffer接口請求將繪製好的UI顯示到屏幕中，其本質上與軟件渲染過程是同樣的，都是向SurfaceFlinger服務Queue一個Graphic Buffer，以便SurfaceFlinger服務能夠對Graphic Buffer的內容進行合成，以及顯示到屏幕上去。

 

   這裏咱們首先要明確什麼是硬件加速渲染，其實就是經過GPU來進行渲染。GPU做爲一個硬件，用戶空間是不能夠直接使用的，它是由GPU廠商按照Open GL規範實現的驅動間接進行使用的。也就是說，若是一個設備支持GPU硬件加速渲染，那麼當Android應用程序調用Open GL接口來繪製UI時，Android應用程序的UI就是經過硬件加速技術進行渲染的。所以，在接下來的描述中，咱們說起到GPU、硬件加速和Open GL時，它們表達的意思都是等價的。 

 

 

(一) Android應用程序UI硬件加速渲染技術簡要介紹和學習計劃

 

(二)Android應用程序UI硬件加速渲染環境初始化過程分析