原文出處——>[Android系統Surface機制的SurfaceFlinger服務簡要介紹和學習計劃](http://blog.csdn.net/luoshengyang/article/details/8010977) 前面我們從Android應用程序與SurfaceFlinger服務的關系出發，從側面簡單學習了SurfaceFlinger服務。有了這些預備知識之后，我們就可以從正面來分析SurfaceFlinger服務的實現原理了。SurfaceFlinger服務負責管理系統的幀緩沖區設備，并且負責渲染系統的UI，即各個應用程序的UI。在本文中，我們就簡要介紹SurfaceFlinger服務，并且制定學習計劃。 在前面Android應用程序與SurfaceFlinger服務的關系概述和學習計劃一系列的文章中提到，SurfaceFlinger服務運行在System進程中，用來統一管理系統的幀緩沖區設備。由于SurfaceFlinger服務運行在System進程中，因此，Android應用程序就需要通過Binder進程間通信機制來請求它來渲染自己的UI。Android應用程序請求SurfaceFlinger服務渲染自己的UI可以分為三步曲：首先是創建一個到SurfaceFlinger服務的連接，接著再通過這個連接來創建一個Surface，最后請求SurfaceFlinger服務渲染該Surface。 由于SurfaceFlinger服務需要與Android應用程序執行Binder進程間通信，因此，它本身就是一個Binder本地對象，如圖1所示：  圖1 SurfaceFlinger服務的類關系圖 理解這個圖需要學習Binder進程間通信機制，具體可以參考Android進程間通信（IPC）機制Binder簡要介紹和學習計劃這一系列的文章。 SurfaceFlinger服務實現的接口為ISurfaceComposer，后者定義在文件frameworks/base/include/surfaceflinger/ISurfaceComposer.h中，如下所示： ~~~ class ISurfaceComposer : public IInterface { public: DECLARE_META_INTERFACE(SurfaceComposer); ...... /* create connection with surface flinger, requires * ACCESS_SURFACE_FLINGER permission */ virtual sp<ISurfaceComposerClient> createConnection() = 0; /* create a client connection with surface flinger */ virtual sp<ISurfaceComposerClient> createClientConnection() = 0; /* retrieve the control block */ virtual sp<IMemoryHeap> getCblk() const = 0; /* open/close transactions. requires ACCESS_SURFACE_FLINGER permission */ virtual void openGlobalTransaction() = 0; virtual void closeGlobalTransaction() = 0; /* [un]freeze display. requires ACCESS_SURFACE_FLINGER permission */ virtual status_t freezeDisplay(DisplayID dpy, uint32_t flags) = 0; virtual status_t unfreezeDisplay(DisplayID dpy, uint32_t flags) = 0; /* Set display orientation. requires ACCESS_SURFACE_FLINGER permission */ virtual int setOrientation(DisplayID dpy, int orientation, uint32_t flags) = 0; /* signal that we're done booting. * Requires ACCESS_SURFACE_FLINGER permission */ virtual void bootFinished() = 0; /* Capture the specified screen. requires READ_FRAME_BUFFER permission * This function will fail if there is a secure window on screen. */ virtual status_t captureScreen(DisplayID dpy, sp<IMemoryHeap>* heap, uint32_t* width, uint32_t* height, PixelFormat* format, uint32_t reqWidth, uint32_t reqHeight) = 0; virtual status_t turnElectronBeamOff(int32_t mode) = 0; virtual status_t turnElectronBeamOn(int32_t mode) = 0; /* Signal surfaceflinger that there might be some work to do * This is an ASYNCHRONOUS call. */ virtual void signal() const = 0; }; ~~~ ISurfaceComposer接口有13個成員函數，下面我們就簡單介紹一下： * createConnection：Android應用程序通過它來請求SurfaceFlinger服務建立一個連接，具體可以參考Android應用程序與SurfaceFlinger服務的連接過程分析一文。 * createClientConnection：Android應用程序通過它來請求SurfaceFlinger服務創建一塊共享UI元數據緩沖區，具體可以參考Android應用程序與SurfaceFlinger服務之間的共享UI元數據（SharedClient）的創建過程分析一文。 * getCblk：Android應用程序通過它來請求SurfaceFlinger服務返回一塊匿名共享內存，返回的匿名共享內存包含了設備顯示屏的信息，例如，寬度和高度信息。 * openGlobalTransaction：Android應用程序通過它請求SurfaceFlinger服務來增加一個全局Transaction計數，用來批量修改UI屬性信息。注意，這些被修改的UI屬性信息會被緩存起來，不會馬上生效。要使得這些被修改的UI屬性信息生效，需要調用另外一個成員函數closeGlobalTransaction，如下所述。 * closeGlobalTransaction：Android應用程序通過它請求SurfaceFlinger服務來減少一個全局Transaction計數。當這個全局Transaction計數減少至0的時候，前面通過openGlobalTransaction來請求修改的UI屬性信息就會馬上生效。 * freezeDisplay：Android應用程序通過它來請求SurfaceFlinger服務來凍結屏幕。屏幕在被凍結期間，所有UI渲染操作都會被緩存起來，等待被執行。 * unfreezeDisplay：Android應用程序通過它來請求SurfaceFlinger服務來解凍屏幕。屏幕被解凍之后，SurfaceFlinger服務就可以執行UI渲染操作了。 * setOrientation：Android應用程序通過它來請求SurfaceFlinger服務設備屏幕的旋轉方向。 * bootFinished：WindowManagerService通過它來告訴SurfaceFlinger服務，系統啟動完成了，這時候SurfaceFlinger服務就會停止執行開機動畫，具體可以參考Android系統的開機畫面顯示過程分析一文。 * captureScreen：Android應用程序通過它來請求SurfaceFlinger服務截取屏幕圖像。 * turnElectronBeamOff：Android應用程序通過它來請求SurfaceFlinger服務關閉屏幕。 * turnElectronBeamOn：Android應用程序通過它來請求SurfaceFlinger服務點亮屏幕。 * signal：Android應用程序通過它來請求SurfaceFlinger服務渲染UI，具體可以參考Android應用程序請求SurfaceFlinger服務渲染Surface的過程分析一文。 理解了ISurfaceComposer接口的定義之后，我們再來看SurfaceFlinger服務的Binder代理對象BpSurfaceComposer的實現，如圖2所示：  圖2 SurfaceFlinger服務的Binder代理對象的類關系圖 理解這個圖同樣需要學習Binder進程間通信機制，具體可以參考Android進程間通信（IPC）機制Binder簡要介紹和學習計劃這一系列的文章。 Android應用程序獲得了SurfaceFlinger服務的一個Binder代理對象，即一個BpSurfaceComposer對象之后，就可以請求SurfaceFlinger服務來創建以及渲染自己的UI了。 接下來，我們再簡單介紹一下SurfaceFlinger類的定義，如圖3所示：  圖3 SurfaceFlinger類的定義 SurfaceFlinger類有兩個類型為State的成員變量mCurrentState和mDrawingState。其中，成員變量mCurrentState用來描述系統下一次要渲染的UI的狀態；而mDrawingState用來描述當前正要渲染的UI的狀態。 State類用來描述一個UI狀態，它有四個重要的成員變量layersSortedByZ、orientation、orientationType和freezeDisplay。其中，成員變量layersSortedByZ是一個類型為LayerVector的向量，里面保存的系統所包含的Surface，每一個Surface使用一個LayerBase對象來描述，并且它們按照 Z軸順序來排列；成員變量orientation和orientationType的類型均為uint8_t，它們用來描述屏幕的方向； 成員變量freezeDisplay的類型也是uint8_t，用來描述屏幕是否處于被凍結狀態。 SurfaceFlinger類的成員變量mVisibleLayerSortedByZ是一個類型為sp<LayerBase>的Vector，它是用來保存SurfaceFlinger服務下一次要渲染的、處于可見狀態的Surface的，它們是來自SurfaceFlinger類的成員變量mDrawingState所描述的一個State對象的成員變量layersSortedByZ的。 SurfaceFlinger類的成員變量mGraphicPlanes是一個類型為GraphicPlane的數組，它是用來描述系統所有的顯示設備的。從這個數組的大小等于1可以知道，當前Android系統只支持一個顯示設備。 GraphicPlane類有四個重要的成員變量mHw、mOrientation、mWidth和mHeight。其中，成員變量mHw指向一個DisplayHardware對象，用來描述一個硬件顯示設備；成員變量mOrientation、mWidth和mHeight的類型均為int，分別用來描述一個硬件顯示設備的旋轉方向、寬度和高度。我們可以通過調用GraphicPlane類的成員函數setDisplayHardware和displayHardware來設備和獲取一個GraphicPlane對象內部所包含的一個硬件顯示設備。 DisplayHardware類有一個重要的成員變量mNativeWindow，它是一個類型為FramebufferNativeWindow的強指針。FramebufferNativeWindow類是用來描述一個Android系統本地窗口，而這個窗口代表的是系統的硬件幀緩沖區。DisplayHardware類的成員函數flip是用來渲染系統UI的，即將后端的圖形緩沖區翻轉為前端的圖形緩沖區，并且渲染在硬件幀緩沖區去。 FramebufferNativeWindow類與在前面Android應用程序請求SurfaceFlinger服務創建Surface的過程分析一文中所介紹的Surface類的作用是一樣的，即它是OpenGL庫和Android的UI系統之間的一個橋梁。OpenGL庫正是通過它的成員函數dequeueBuffer來獲得一個用來填充UI數據的圖形緩沖區，而通過它的成員函數queueBuffer來將一個已經填充好UI數據的圖形緩沖區渲染到系統的幀緩沖區中去。 FramebufferNativeWindow類有三個重要的成員變量fbDev、grDev和buffers。其中，成員變量fbDev和grDev分別指向一個framebuffer_device_t設備和一個alloc_device_t設備。從前面Android幀緩沖區（Frame Buffer）硬件抽象層（HAL）模塊Gralloc的實現原理分析一文可以知道，framebuffer_device_t設備和一個alloc_device_t設備是由HAL模塊Gralloc來提供的，它們分別用來分配圖形緩沖區和渲染圖形緩沖區；成員變量buffers是一個類型為NativeBuffer的數組，這個數組用來描述一個圖形緩沖區堆棧，堆棧的大小為NUM_FRAME_BUFFERS，這些圖形緩沖區是直接在硬件幀緩沖區中分配的，有別于Surface類所使用的圖形緩沖區，因為后者所使用的圖形緩沖區是在匿名共享內存分配的。 了解了SurfaceFlinger類的重要成員變量之后，我們再來了解它的幾個重要成員函數threadLoop、waitForEvent、signalEvent、handleConsoleEvents、handleTransaction、handlePageFlip、handleRepaint和postFramebuffer。 SurfaceFlinger服務雖然是在System進程中啟動的，但是它在啟動的時候創建一個線程來專門負責渲染UI。為了方便描述，我們將這個線程稱為UI渲染線程。UI渲染線程的執行函數就為SurfaceFlinger類的成員函數threadLoop，同時它有一個消息隊列。當UI渲染線程不需要渲染UI時，它就會在SurfaceFlinger類的成員函數waitForEvent中睡眠等待，直到SurfaceFlinger服務需要執行新的UI渲染操作為止。 SurfaceFlinger服務什么時候會需要執行新的UI渲染操作呢？當系統顯示屏屬性發生變化，或者應用程序窗口發生變化時，它就需要重新渲染系統的UI。這時候SurfaceFlinger服務就會從SurfaceFlinger類的成員函數waitEvent中喚醒，并且依次執行SurfaceFlinger類的成員函數handleConsoleEvents、handleTransaction、handlePageFlip、handleRepaint和postFramebuffer來具體執行渲染UI的操作。其中，成員函數handleConsoleEvents用來處理控制臺事件；成員函數handleTransaction用來處理系統顯示屏屬性變化以及應用程序窗口屬性變化；成員函數handlePageFlip用來獲得應用程序窗口下一次要渲染的圖形緩沖區，即設置應用程序窗口的活動圖形緩沖區；成員函數handleRepaint用來重繪應用程序窗口；成員函數postFramebuffer用來將系統UI渲染到硬件幀緩沖區中去。 我們知道，應用程序是運行在與SurfaceFlinger服務不同的進程中的，而從前面Android應用程序請求SurfaceFlinger服務渲染Surface的過程分析一文又可以知道，每當應用程序需要更新自己的UI時，它們就會通過Binder進程間通信機制來通知SurfaceFlinger服務。SurfaceFlinger服務接到這個通知之后，就會調用SurfaceFlinger類的成員函數signalEvent來喚醒UI渲染線程，以便它可以執行渲染UI的操作。注意，SurfaceFlinger服務是通過Binder線程來獲得應用程序的請求的，因此，這時候SurfaceFlinger服務的UI渲染線程實際上是被Binder線程喚醒的。SurfaceFlinger類的成員函數signalEvent實際上是通過向UI渲染線程的消息隊列發送一個類型為INVALIDATE的消息來喚醒UI渲染線程的。 前面提到， SurfaceFlinger服務在在執行UI渲染操作時，需要調用SurfaceFlinger類的成員函數handleConsoleEvents來處理控制臺事件。這怎么理解呢？原來，SurfaceFlinger服務在啟動的時候，還會創建另外一個線程來監控由內核發出的幀緩沖區硬件事件。為了方便描述，我們將這個線程稱為控制臺事件監控線程。每當幀緩沖區要進入睡眠狀態時，內核就會發出一個睡眠事件，這時候SurfaceFlinger服務就會執行一個釋放屏幕的操作；而當幀緩沖區從睡眠狀態喚醒時，內核就會發出一個喚醒事件，這時候SurfaceFlinger服務就會執行一個獲取屏幕的操作。 這樣，我們就簡要介紹完了SurfaceFlinger類的定義。從這些介紹可以知道： 1. SurfaceFlinger服務通過一個GraphicPlane對象來管理系統的顯示設備； 2. SurfaceFlinger服務有三種類型的線程，它們分別是Binder線程、控制臺事件監控線程和UI渲染線程； 3. SurfaceFlinger服務是在UI渲染線程中執行渲染系統UI的操作的。 圍繞上述三個內容，再結合SurfaceFlinger服務的啟動過程，接下來我們再通過以下四篇文章來系統地學習SurfaceFlinger服務的實現原理： 1. SurfaceFlinger服務是如何啟動的？ 2. SurfaceFlinger服務是如何通過GraphicPlane、DisplayHardware和FramebufferNativeWindow三個類來管理系統的顯示設備的？ 3. SurfaceFlinger服務的三個線程的協作模型是如何的？ 4. SurfaceFlinger服務是如何在UI渲染線程中執行UI渲染操作的？ 結合前面Android應用程序與SurfaceFlinger服務的關系概述和學習計劃的一系列文章，以及上述四篇文章，相信我們就可以對SurfaceFlinger服務有一個清晰的認識了，敬請關注！