Android 4.4(KitKat)中的設(shè)計模式-Graphics子系統(tǒng)

原文地址：http://blog.csdn.net/jinzhuojun/article/details/17427491

本文主要從設(shè)計模式角度簡單地侃下Android4.4(KitKat)的Graphics子系統(tǒng)。作為一個操作系統(tǒng)，Android需要考慮到靈活性，兼容性，可用性，可維護性等方方面面 ，為了達到這些需求，它需要良好的設(shè)計。因此，在Android源碼中可以看到很多設(shè)計模式的身影。光是本文涉及的Graphics子系統(tǒng)中，就用到了如Observer, Proxy, Singleton, Command, Decorator,  Strategy, Adapter, Iterator和Simple Factory等模式。如果要學(xué)習(xí)設(shè)計模式，我想Android源代碼是一個比較好的實例教材。當然很多用法和GoF書中的經(jīng)典示例不一樣，但其理念還是值得學(xué)習(xí)的。本文仍以大體流程為綱，在涉及到時穿插相應(yīng)的設(shè)計模式。這樣既涵蓋了Android工作原理，又能一窺其設(shè)計理念，一舉兩得。這里本意是想自頂向下地展開，因為Android源代碼龐大，很容易迷失在code的海洋中。本著divide-and-conquer的原則，本文重點先介紹SurfaceFlinger也就是服務(wù)端的工作流程，而對于應(yīng)用程序端的App UI部分留到以后再講。

為了讓分析不過于抽象，首先，讓我們先找一個可以跑的實例為起點，使得分析更加有血有肉。這里選的是/frameworks/native/services/surfaceflinger/tests/resize/resize.cpp。選這個測試用例原因有幾：一、它是一個Native程序，不牽扯它們在Java層的那一坨代理和Jni調(diào)用。二、麻雀雖小，五臟俱全，應(yīng)用程序在Native層的主干它都有。三、程序無廢話，簡約而不簡單，高端洋氣上檔次。注意這個用例默認編譯有錯的，不過好在對于碼農(nóng)們不是大問題，改發(fā)改發(fā)也就過了。

下面是該用例中最核心的幾行，我們來看看這樣簡單的任務(wù)后面Android到底做了神馬。

這兒的大概流程是先創(chuàng)建SurfaceComposerClient，再通過它創(chuàng)建SurfaceControl，再得到Surface，然后通過lock()分配圖形緩沖區(qū)，接著把要渲染的東西（這里是簡單的紅色）畫好后，用unlockAndPost()交給SurfaceFlinger去放到硬件緩沖區(qū)中，也就是畫到屏幕上。最后結(jié)果是屏幕上應(yīng)該能看到一個小紅色塊。這里先不急著挖代碼，先放慢腳步直觀地理解下這些概念。SurfaceComposer可以理解為SurfaceFlinger的別稱，因為SurfaceFlinger主要就是用來做各個圖層的Composition操作的。但SurfaceFlinger是在服務(wù)端的，作為應(yīng)用程序要讓它為之服務(wù)需要先生成它所對應(yīng)的客戶端，也就是SurfaceComposerClient，因為SurfaceComposerClient是懂得和服務(wù)端打交道的協(xié)議的。SurfaceComposerClient位于服務(wù)端的代理叫Client，應(yīng)用程序通過前者發(fā)出的遠程過程調(diào)用就是通過后者來實現(xiàn)的。有了它之后，應(yīng)用程序就可以通過它來申請SurfaceFlinger為自己創(chuàng)建Surface，這個Surface就是要繪制的表面的抽象。去除次要元素，下圖簡要勾勒了這些類之間的總體結(jié)構(gòu)：

把這些個結(jié)構(gòu)畫出來后，優(yōu)美而對稱的C/S架構(gòu)就躍然電腦上了。中間為接口層，兩邊的服務(wù)端和客戶端（也就是應(yīng)用程序）通過接口就可以相互通信。這樣兩邊都可以做到設(shè)計中的“面向接口編程”。只要接口不變，兩邊實現(xiàn)怎么折騰都行?？梢钥吹?，應(yīng)用程序要通過SurfaceFlinger將自己的內(nèi)容渲染到屏幕上是一個客戶端請求服務(wù)的過程。其中應(yīng)用程序端為生產(chǎn)者，提供要渲染的圖形緩沖區(qū)，SurfaceFlinger為消費者，拿圖形緩沖區(qū)去合并渲染。從結(jié)構(gòu)上來看，可以看到應(yīng)用程序端的東西在服務(wù)端都有對應(yīng)的對象。注意它們的生成順序是由上到下的，即對于應(yīng)用程序來說，先有ComposerService，再有SurfaceComposerClient，再有Surface；對于服務(wù)端來說，依次有SurfaceFlinger，Client和Layer。

這里至少看到兩種設(shè)計模式 ：Singleton和Proxy模式。當然用法可能和教科書中不一樣，但是思想是一致的。ComposerService用來抽象SurfaceFlinger，SurfaceFlinger全局只有一個，所以ComposerService是Singleton對象。另一方面，應(yīng)用程序想要讓服務(wù)端為其做事，但服務(wù)端不在同一進程中，這就需要在服務(wù)端創(chuàng)建本地對象在服務(wù)端的代理（如Client），這就是Proxy模式了。Proxy模式應(yīng)用很廣，可用于遠程對象訪問(remote proxy)，虛擬化(virtual proxy)，權(quán)限控制(protection proxy)和智能指針(smart reference proxy)等。這里用的是remote proxy（當然也有protection proxy的因素）。另外smart reference proxy模式的例子如Android中的智能指針。

大體結(jié)構(gòu)講完，下面分步講流程。首先，創(chuàng)建SurfaceComposerClient的流程見下面的序列圖：

沒啥亮點，一筆帶過。前戲結(jié)束，下面進入正題，應(yīng)用程序創(chuàng)建Surface過程如下：

挺直觀的過程，細節(jié)從略。要注意的有幾點：

一、客戶端到服務(wù)端的調(diào)用都是通過Binder來進行的。如果不知道Binder是什么也沒關(guān)系，只要把它看作一個面向系統(tǒng)級的IPC機制就行。上面在客戶端和服務(wù)端之間很多的進程間過程調(diào)用就是用它來完成的。

二、現(xiàn)實中，像調(diào)用SurfaceFlinger的createLayer()函數(shù)這種并不那么直接，而是采用異步調(diào)用方式。這個一會再講。

三、IGraphicBufferProducer,IGraphicBufferConsumer, BufferQueue, SurfaceTextureLayer這幾個類是一脈相承的。所以圖中當服務(wù)端創(chuàng)建一個SurfaceTextureLayer對象，傳到客戶端被轉(zhuǎn)成IGraphicBufferProducer是完全OK的。這種面向接口編程的用法還有很多，其理論基礎(chǔ)是里氏替換原則。這里也體現(xiàn)了接口隔離原則，同樣的對象在客戶端只暴露作為生產(chǎn)者的接口，而在服務(wù)端暴露消費者的接口，避免了接口污染。

那么上面的過程中用到了哪些設(shè)計模式呢？我覺得比較明顯的有以下幾個：

Proxy模式這里被用來解除環(huán)形引用和避免對象被回收。ConsumerBase先創(chuàng)建一個類型為BufferQueue::ConsumerListerner的對象listerner，然后再在外面包了層類型為QueueBuffer::ProxyConsumerListener的代理對象proxy，它擁有一個指向listerner的弱指針（因弱引用不影響回收）。一方面，加了這一層代理相當于把相互的強引用變成了單向的強引用，之所以這樣做是為了避免對象間的環(huán)形引用導(dǎo)致難以回收。另一方面，如果用的強指針，那在ConsumerBase構(gòu)造函數(shù)中，一旦函數(shù)結(jié)束，對于ConsumerListener(即ConsumerBase)的強引用就沒有了，那么onLastStrongRef()就可能被調(diào)用，從而回收這個還有用的對象。前面我們看到Proxy模式在遠程對象訪問中的應(yīng)用，這里我們看到了另一種用法。

Observer模式被用做在應(yīng)用程序渲染完后提交給服務(wù)端時的通知機制。首先consumerConnect()會建立起BufferQueue到ConsumerBase對象的引用，放于成員變量mConsumerListener之中，接著setFrameAvailableListener()建立起ConsumerBase對象到Layer的引用。這樣就形成了下面這樣一個鏈式Observer模式：

注意雖是鏈式，但和Chain of Responsiblity模式?jīng)]啥關(guān)系。注冊完成之后，日后當應(yīng)用程序處理完圖形緩沖區(qū)后調(diào)用queueBuffer()時，BufferQueue就會調(diào)用這個listener的回調(diào)函數(shù)onFrameAvailable()，然后途經(jīng)ConsumerBase調(diào)用Layer的回調(diào)函數(shù)onFrameAvailable()，最后調(diào)用signalLayerUpdate()使SurfaceFlinger得到通知。這樣就使得SurfaceFlinger可以專心干自己的事，當有需求來時自然會被通知到。事實上，當被通知有新幀需要渲染時，SurfaceFlinger也不是馬上停下手上的事，而是先做一個輕量級的處理，也就是把相應(yīng)消息放入消息隊列留到以后處理。這就使得各個應(yīng)用程序和SurfaceFlinger可以異步工作，保證SurfaceFlinger的性能不被影響。而這又引入了下面的Command模式。

Command模式被用來使得SurfaceFlinger可以和其它模塊異步工作。Command模式常被用來實現(xiàn)undo操作或是延遲處理，這里顯然是用了后者。簡單地概括下就是：當有消息來(如INVALIDATE消息)，先把它通過MessageQueue存起來（實際是存在Looper里），然后SurfaceFlinger線程會不斷去查詢這個消息隊列。如果隊列不為空且約定處理時間已到，就會取出做相應(yīng)處理。具體流程后面談到SurfaceFlinger時再說。為什么要這么麻煩呢，主要還是要保證SurfaceFlinger的穩(wěn)定和高效。消息可以隨時過來，但SurfaceFlinger可以異步處理。這樣就可以保證不打亂SurfaceFlinger那最搖擺的節(jié)奏，從而保證用戶體驗。

創(chuàng)建不同功能的BufferQueue使用的是類似于Builder的設(shè)計模式。當BufferQueue被創(chuàng)建出來后，它擁有默認的參數(shù)，客戶端為把它打造成想要的BufferQueue，通過其接口設(shè)定一系列的參數(shù)即可，就像Wizard一樣。為什么要這么做呢，先了解下背景知識。一個圖形緩沖區(qū)從應(yīng)用程序到屏幕的路上兩個地方用到了BufferQueue。一個用來將應(yīng)用程序渲染好的圖形緩沖傳給SurfaceFlinger，另一個用來把SurfaceFlinger合成好的圖形緩沖放到硬件圖形緩沖區(qū)上。

BufferQueue中核心數(shù)據(jù)是一個GraphicBuffer的隊列。而GraphicBuffer根據(jù)使用場合的不同可以從共享內(nèi)存(即Ashmem，因為這塊內(nèi)存要在應(yīng)用程序和服務(wù)端程序兩個進程間共享）或者從硬件圖形緩沖區(qū)(即Framebuffer，因為它是SurfaceFlinger渲染完要放到屏幕上的)中分配。另外因為用途不同，它的格式，大小，以及在BufferQueue中的數(shù)量都可能是不同的。雖然是同一個類，用于不同場合出身就不同，那又怎么區(qū)分哪個是高富帥，哪個是矮窮挫呢。很簡單，當BufferQueue被創(chuàng)建出來之后，由Layer或是FramebufferSurface來充當導(dǎo)演的角色，打造相應(yīng)的BufferQueue。它們調(diào)用一系列的函數(shù)（如setConsumerUsageBits()和setDefaultMaxBufferCount()等）將構(gòu)建出來的BufferQueue變得適用于自己。

另外，Adapter和Decorator模式在代碼中也經(jīng)常會出現(xiàn)。從目的上講，由于被調(diào)用者提供的接口或功能常常不能滿足調(diào)用者的需求，如果是接口不滿足就用Adapter模式，如果要增加額外功能就用Decorator模式。從結(jié)構(gòu)上講，Adapter可以是Subclassing結(jié)構(gòu)也可以是Composition結(jié)構(gòu)，而Decorator一般是Composition結(jié)構(gòu)。事實上這兩個模式經(jīng)?；煸谝黄鹩谩嵱弥形矣X得沒必要太在意到底是什么模式，能起到作用就行。舉例來說，SurfaceFlingerConsumer是GLConsumer的Wrapper，當Layer調(diào)用SurfaceFlingerConsumer的接口，底層會部分使用GLConsumer的相應(yīng)實現(xiàn)（事實上SurfaceFlingerConsumer和GLConsumer實現(xiàn)中有重復(fù)代碼）。我覺得它是用了subclassing結(jié)構(gòu)來達到了類似Decorator模式的目的。當然這里模式用得不是很清晰，只是借機引下相關(guān)模式，例子跳過也罷。

回到我們的測試用例主線上，現(xiàn)在應(yīng)用程序中Surface創(chuàng)建好了，下面幾行主要功能是把應(yīng)用程序所繪圖層的z軸值設(shè)得很大，也就是很牛逼肯定能看到的地方。

像這種更改屏幕或是應(yīng)用程序窗口屬性的動作需要用openGlobalTransaction()和closeGlobalTransaction()包起來，這樣中間的更改操作就成為一個事務(wù)。事務(wù)中的操作暫時只在本地，只有當closeGlobalTransaction()被調(diào)用時才一起通過Binder發(fā)給SurfaceFlinger處理。這主要是由另一個Singleton對象Compoesr來實現(xiàn)的。屬性改變的事務(wù)化優(yōu)化了系統(tǒng)資源，因為更改這些屬性的操作往往很heavy，意味著很多東西需要重新計算，所以這里把這些費時操作打了一個包，避免重復(fù)勞動。由于這塊并不復(fù)雜也不是重點，而且部分流程和后面重復(fù)，所以就跳過直接進入高潮 - 寫圖形緩沖區(qū)和交由SurfaceFlinger合成輸出到屏幕。讓我們看看下面這幾行背后都做了些什么：

代碼首先定義了圖形緩沖區(qū)，它就是應(yīng)用程序用來畫圖的緩沖區(qū)了。但這里只有元信息，放繪制數(shù)據(jù)的地方還沒分配出來。先看下面這兩行繪制緩沖區(qū)的語句，它們的目的很簡單，就是把圖形緩沖區(qū)整成紅色。注意Surface格式是PIXEL_FORMAT_RGB_565，所以紅色對應(yīng)0xF800。

繪制緩沖區(qū)前后分別用lock()和unlockAndPost()包起來，這兩個函數(shù)主要用途是向服務(wù)端申請圖形緩沖區(qū)，再把繪制好的圖形緩沖區(qū)交給SurfaceFlinger處理。大體流程如下：

這樣應(yīng)用程序就把自己渲染好的圖形緩沖區(qū)華麗麗地交給SurfaceFlinger了。其中最主要的是圖形緩沖區(qū)的傳遞處理，圖形緩沖區(qū)對應(yīng)的類為GraphicBuffer。BufferQueue為它的緩沖隊列，可以看作是一個元素為GraphicBuffer的隊列。插播下背景知識，BufferQueue中的GraphicBuffer有以下幾種狀態(tài)，之間的轉(zhuǎn)換關(guān)系如下：

這部分用到的設(shè)計模式主要有以下幾個：

Memento模式。從BufferQueue傳回的GraphicBuffer是在共享內(nèi)存中分配的，而這塊內(nèi)存又是用句柄來表示的。我們知道一個進程的句柄或地址到另一個進程中就不一定合法了。那么為什么Surface的lock()函數(shù)拿到這個GraphicBuffer后就直接拿來當本地對象用了呢。這里就要引入Memento模式了。GraphicBuffer繼承了Flattenable類，實現(xiàn)了flatten()和unflatten函數(shù)。當GraphicBuffer被從進程A經(jīng)由Binder傳遞到進程B時，先在進程A中它的flatten()函數(shù)被調(diào)用，再在進程B中unflatten()函數(shù)被調(diào)用。這樣就可以保證GraphicBuffer跨進程后仍然有效。簡要地看下flatten()和unflatten()的實現(xiàn)。服務(wù)端在傳遞GraphicBuffer前調(diào)用flatten()函數(shù)把GraphicBuffer的基本信息存在結(jié)構(gòu)體中，應(yīng)用程序端拿到后調(diào)用unflatten()將這個結(jié)構(gòu)體拿出來后調(diào)用GraphicBufferMapper::registerBuffer()(它接著會調(diào)用gralloc模塊中的gralloc_register_buffer()，接著調(diào)用gralloc_map()，最后用mmap()完成映射)將遠端GraphicBuffer映射到本地地址空間，然后據(jù)此在BpGraphicBufferProducer::requestBuffer()中重新構(gòu)建了一個GraphicBuffer。這樣應(yīng)用程序端和服務(wù)端中的GraphicBuffer就被映射到了同一塊物理空間，達到了共享的目的，而且對于上層應(yīng)用這個轉(zhuǎn)化的過程完全是透明的。QueueBufferOutput和QueueBufferInput的處理與GraphicBuffer的處理目的相同，都是進程間傳遞對象，不同之處在于前兩者相當于在另一個進程中拷貝了一份。因為它們只包含少量POD成員，所以拷貝對性能影響不大。

Iterator模式在Android源碼中也很散落地應(yīng)用著。如Surface::lock()中，為了使得frontBuffer可以重用（圖形渲染一般采用雙緩沖，frontBuffer用于顯示輸出，backBuffer用于作圖，這樣兩者可以同時進行互不影響。很多時候其實下一幀和前一幀比只有一小塊是需要重新渲染的，如切水果時很多時候其實就水果周圍一塊區(qū)域需要重渲染，這塊區(qū)域即為臟區(qū)域），我們需要知道臟區(qū)域。臟區(qū)域信息用Region表示。而Region本身是由多個矩形組成的，而作為客戶端要訪問Region中的這些矩形，不需要知道它們的內(nèi)在實現(xiàn)。這樣在訪問這個臟區(qū)域時就可以這么寫：

這樣客戶端的代碼就不依賴于Region的實現(xiàn)了，無論Region中是數(shù)組也好，隊列也好，上層代碼不變，無比優(yōu)美。同理還有BufferQueue::queueBuffer()中用到的Fifo::iterator等。

Strategy模式用于讓系統(tǒng)可以優(yōu)雅地適應(yīng)不同平臺中的HAL模塊。盡管這兒部分代碼是用C寫的，和標準的Strategy用法略有不同，但精神是一樣的。舉例來說，由于gralloc模塊是平臺相關(guān)的，在不同平臺有不同的實現(xiàn)。那么作為上層客戶端，如GraphicBufferMapper來說，它不希望依賴于這種變化。于是要求所有平臺提供的gralloc模塊提供統(tǒng)一的接口，而這個接口對應(yīng)的對象的符號統(tǒng)一為HAL_MODULE_INFO_SYM。這樣不管是哪個平臺，上層客戶端就只要用dlopen()和dlsym()去載入和查詢這個結(jié)構(gòu)體就可以得到這些接口相應(yīng)的實現(xiàn)了（載入流程見hw_get_module() ->hw_get_module_by_class() -> load()）。這里涉及到的是gralloc_module_t接口，也就是GraphicBufferMapper要用到的接口，各個平臺提供的gralloc都要實現(xiàn)這個接口。同理的還有對同在HAL層的hwcomposer模塊的處理。

另外，我們還看到了前面提到過的設(shè)計模式又一次次地出現(xiàn)，如死亡通知是基于Binder的Observer模式，另外GraphicBufferMapper對gralloc模塊gralloc_module_t的封裝可看作是Adapter模式的應(yīng)用。

回到主線，前面的流程進行到Layer調(diào)用signalLayerUpdate()通知SurfaceFlinger就結(jié)束了。下面分析下SurfaceFlinger的流程及對于應(yīng)用程序圖形緩沖區(qū)的后續(xù)處理過程。為了讓文章看起來更加完整些，我們還是從SurfaceFlinger的初始化開始，然后再接著講那signalLayerUpdate()之后的故事。這里就從SurfaceFlinger的創(chuàng)建開始講起吧。本來SurfaceFlinger有兩種啟動方式，由SystemServer以線程方式啟動，或是由init以進程方式啟動。不過Android 4.4上好像前者去掉了，反正我是沒找到。。。。那故事就從main_surfaceflinger.cpp講起吧。

上半部分是SurfaceFlinger的初始化，下半部分是SurfaceFlinger對于VSync信號的處理，也就是一次合并渲染的過程。由于代碼里分支較多，為了說明簡便，這里作了幾點假設(shè)：首先假設(shè)平臺支持硬件VSync信號，這樣就不會創(chuàng)建VSyncThread來用軟件模擬了。另外假設(shè)INVALIDATE_ON_VSYNC為1，也就是把INVALIDATE操作放到VSync信號來時再做。值得注意的是SurfaceFlinger線程模型相較之前版本有了較大變化，主要原因是引入了VSync的虛擬化。相關(guān)的線程有EventThread(vsyncSrc), EventThread(sfVsyncSrc), EventControlThread和DispSyncThread。這個東西比較好玩，所以單獨放一篇文章來講（http://blog.csdn.net/jinzhuojun/article/details/17293325）。

先粗略介紹下幾個重要類的基本作用：

EventControlThread是一個簡單地另人發(fā)指的線程，用來根據(jù)標志位開關(guān)硬件VSync信號。但為毛要單獨放到個線程，難道是開關(guān)硬件VSync信號的代價很大?

RenderEngine是對一坨egl和gl函數(shù)的封裝。引入它可能是覺得egl和gl函數(shù)混雜在其它模塊中里看起來太亂了。它把GL相關(guān)的東西封裝起來了，只暴露出GL無關(guān)的接口，這樣SurfaceFlinger等模塊作為客戶端不需要了解底層細節(jié)。

Looper是一個通用的類，負責(zé)將事件和消息存成隊列，并提供輪詢接口處理隊列中的事件和消息。在這里主要用于處理TRANSACTION, INVALIDATE和REFRESH消息以及VSync事件。

MessageQueue主要操作Looper。由于Looper不是專用于SurfaceFlinger的，MessageQueue封裝了一些SurfaceFlinger專用的信息，使得EventThread和SurfaceFlinger等模塊可以通過它來間接使用Looper類。

SurfaceFlinger，DisplayDevice，FramebufferSurface和HWComposer這幾個類之間的關(guān)系比較曖昧。SurfaceFlinger是這部分里最大的客戶端。DisplayDevice抽象了顯示設(shè)備，封裝了用于渲染的Surface和HWComposer模塊等，從而盡可能使得SurfaceFlinger只要和它打交道。FramebufferSurface抽象了SurfaceFlinger用來畫圖的Surface，該Surface對應(yīng)一個BufferQueue用于多緩沖渲染。它和之前提到的應(yīng)用端用到的Surface區(qū)別在于它是基于硬件圖形緩沖區(qū)的，而不是Ashmem。HWComposer封裝了兩個重要的HAL模塊，即framebuffer和hwcomposer，前者對應(yīng)硬件緩沖區(qū)，后者對應(yīng)hwcomposer硬件。hwcomposer控制VSync信號，管理屏幕信息和操作framebuffer。HWComposer主要工作是負責(zé)將平臺相關(guān)的HAL模塊加載好，并且使得上層模塊通過它來使用HAL模塊。注意兩個容易混淆的概念：HWComposer是類，肯定會有；hwcomposer是硬件模塊，在某些平臺可能會不可用。這幾個類的大致結(jié)構(gòu)如下：

SurfaceFlinger的渲染工作主要是由VSync信號驅(qū)動的。EventThread負責(zé)發(fā)出虛擬VSync信號（由硬件VSync信號偏移指定相位虛擬化得到）。初始化時，MessageQueue在setEventThread()函數(shù)中先與EventThread建立連接，然后將與EventThread之間通信的socket（BitTube）句柄注冊進Looper，同時也注冊了自己的回調(diào)函數(shù)。另一方面，SurfaceFlinger會通過Looper不斷輪詢這個句柄，看該句柄上有沒有數(shù)據(jù)。當在該句柄上接收到數(shù)據(jù)，就會調(diào)用MessageQueue相應(yīng)的回調(diào)函數(shù)。經(jīng)過一番處理后，最后MessageQueue的Handler基于收到的消息調(diào)用到SurfaceFlinger的相應(yīng)處理函數(shù)。就這樣，EventThread->Looper->MessageQueue->SurfaceFlinger的事件消息傳遞過程形成了。

這里又看到了比較熟悉的設(shè)計模式，如Iterator模式用于遍歷所有圖層(HWComposer::LayerListIterator)， Observer模式用于虛擬VSync信號線程向DispSyncThread申請?zhí)摂MVSync事件(DispSyncThread::EventListener)，還有前面提到過的Command模式用于消息的延遲處理(postMessageAsync())。

除了這些熟悉的身影外，我們還能看到些新面孔。如RenderEngine::create()應(yīng)用了簡單工廠模式，它根據(jù)GLES版本號創(chuàng)建相應(yīng)的RenderEngine。這樣，作為RenderEngine的使用者SurfaceFlinger和Layer自然就成了Strategy模式的受益者，它們不用關(guān)心RenderEngine在各個不同版本間實現(xiàn)的差異。還有Mediator模式在Service管理中的應(yīng)用。SurfaceFlinger進程中，addService()函數(shù)向Service Manager注冊了SurfaceFlinger服務(wù)。這樣Service Manager作為中介的角色在Client和Service之間做溝通，它使得一個網(wǎng)狀的模塊結(jié)構(gòu)變成了一個優(yōu)美的星形結(jié)構(gòu)。當然在這里因為就一個服務(wù)看不出來，因此這個另作章節(jié)再講。

可以看到，當VSync信號到來時，SurfaceFlinger最主要是通過處理INVALIDATE和REFRESH消息來做合并渲染和輸出的工作的。這里的核心思想是能少處理一點是一點，所以在渲染前有很多臟區(qū)域的計算工作，這樣后面只要處理那些區(qū)域的更新就可以了。這樣是有現(xiàn)實意義的，一方面由于圖層間的遮蓋，有些不可見圖層不需要渲染。另一方面，因為我們的應(yīng)用程序中前后幀一般只有一小部分變化，要是每幀都全變估計人都要看吐了。這里主要是調(diào)用了這幾個函數(shù)：

handleMessageTransaction()主要處理之前對屏幕和應(yīng)用程序窗口的改動。因這些改動很有可能會改變圖層的可見區(qū)域，進而影響臟區(qū)域的計算。

handleMessageInvalidate()主要調(diào)用handlePageFlip()函數(shù)。這里Page Flip是指從BufferQueue中取下一個圖形緩沖區(qū)內(nèi)容，就好像是“翻頁”一樣。該函數(shù)主要是從各Layer對應(yīng)的BufferQueue中拿圖形緩沖區(qū)數(shù)據(jù)，并根據(jù)內(nèi)容更新臟區(qū)域。

handleMessageRefresh()就是合并和渲染輸出了。作為重頭戲，這步步驟多一些，大體框架如下：

文章一開始的測試用例主干部分背后的故事大概就這么些了。篇幅有限，省略了很多細節(jié)。我們可以看到，在服務(wù)端做了這么多的事，而對于應(yīng)用程序來說只要先lock()，再填buffer，最后unlockAndPost()就OK了。這也算是Facade模式的體現(xiàn)了吧。

總結(jié)地說，從Android源碼中我們可以溫習(xí)到應(yīng)用設(shè)計模式的基本原則：一是只在合適的地方用。很多時候我們學(xué)習(xí)設(shè)計模式恰恰是為了不用，準確地說是不濫用。二是要用的話不需要過于拘泥于原有的或經(jīng)典的用法，以解決問題為目的適當自由發(fā)揮。