Android GUI系統之SurfaceFlinger(4)

opengl es本地窗口SurfaceTextureClient

1.1.1 SurfaceTextureClient

針對應用程序端的本地窗口是SurfaceTextureClient，和FramebufferNativeWindow一樣，它必須繼承ANativeWindow：

class SurfaceTextureClient

   : publicANativeObjectBase<ANativeWindow, SurfaceTextureClient,RefBase>

這個本地窗口當然也需要實現ANativeWindow所制定的“協議”，我們的重點是關注它與前面的FramebufferNativeWindow有什麼不同。SurfaceTextureClient的構造函數只是簡單地調用了init函數，後者則對ANativeWindow::dequeueBuffer等函數指針及內部變量賦了初值。由於整個函數的功能很簡單，我們只摘錄其中的一部分：

/*frameworks/native/libs/gui/SurfaceTextureClient.cpp*/

void SurfaceTextureClient::init() {

   /*給ANativeWindow中的函數指針賦值*/

  ANativeWindow::setSwapInterval  =hook_setSwapInterval;

   ANativeWindow::dequeueBuffer    = hook_dequeueBuffer;

   …

   /*為各內部變量賦值，因為此時用戶還沒有真正發起申請，所以基本是0*/

   mReqWidth = 0;

   mReqHeight = 0;

   …

   mDefaultWidth = 0;

   mDefaultHeight = 0;

   mUserWidth = 0;

   mUserHeight = 0;…

}

SurfaceTextureClient是面向Android系統中所有UI應用程序的，也就是說它承擔著單個應用進程中的UI顯示需求。基於這點考慮，可以推測出它的內部實現至少會有以下幾點：

提供給上層(主要是java層)繪制圖像的“畫板”

前面說過，這個本地窗口分配的內存應該不是來自於幀緩沖區，那麼具體是由誰分配的，又是如何管理的呢？

它與SurfaceFlinger間是如何分工的

顯然SurfaceFlinger需要收集系統中所有應用程序繪制的圖像數據，然後集中顯示到物理屏幕上。在這個過程中，SurfaceTextureClient扮演了什麼樣的角色呢？