為什么80%的碼農都做不了架構師？>>> ??

本文主要從設計模式角度簡單地侃下Android4.4(KitKat)的Graphics子系統。可以看到在KitKat中Google對code還是整理過的，比如替換了像SurfaceTexture這種第一眼看到不知所云的東西，去掉了像ISurface這種打醬油的定義，改掉了明明是SurfaceHolder類型卻死皮白臉叫surface的變量。自從修正了這些晦澀逆天的概念后，媽媽再也不用擔心我看不懂Android的code了。當然仍然有不少legacy code，如果沒看過以前版本的話會有些小迷茫，好在無傷大雅。接下來言歸正傳。作為一個操作系統，Android需要考慮到靈活性，兼容性，可用性，可維護性等方方面面 ，為了達到這些需求，它需要良好的設計。因此，在Android源碼中可以看到很多設計模式的身影。光是本文涉及的Graphics子系統中，就用到了如Observer, Proxy, Singleton, Command, Decorator, Strategy, Adapter, Iterator和Simple Factory等模式。如果要學習設計模式，我想Android源代碼是一個比較好的實例教材。當然很多用法和GoF書中的經典示例不一樣，但其理念還是值得學習的。本文仍以大體流程為綱，在涉及到時穿插相應的設計模式。這樣既涵蓋了Android工作原理，又能一窺其設計理念，一舉兩得。這里本意是想自頂向下地展開，因為Android源代碼龐大，很容易迷失在code的海洋中。本著divide-and-conquer的原則，本文重點先介紹SurfaceFlinger也就是服務端的工作流程，而對于應用程序端的App UI部分留到以后再講。

?

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

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

sp<surfacecomposerclient> client = new SurfaceComposerClient();sp<surfacecontrol> surfaceControl = client->createSurface(String8(resize),160, 240, PIXEL_FORMAT_RGB_565, 0);sp<surface> surface = surfaceControl->getSurface();SurfaceComposerClient::openGlobalTransaction();surfaceControl->setLayer(100000);SurfaceComposerClient::closeGlobalTransaction();ANativeWindow_Buffer outBuffer;surface->lock(&outBuffer, NULL);ssize_t bpr = outBuffer.stride * bytesPerPixel(outBuffer.format);android_memset16((uint16_t*)outBuffer.bits, 0xF800, bpr*outBuffer.height);surface->unlockAndPost();</surface></surfacecontrol></surfacecomposerclient>

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

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

?

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

?

大體結構講完，下面分步講流程。首先，創建SurfaceComposerClient的流程見下面的序列圖：

沒啥亮點，一筆帶過。前戲結束，下面進入正題，應用程序創建Surface過程如下：

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

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

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

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

?

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

?

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

?

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

?

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

?

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

?

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

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

?

另外，Adapter和Decorator模式在代碼中也經常會出現。從目的上講，由于被調用者提供的接口或功能常常不能滿足調用者的需求，如果是接口不滿足就用Adapter模式，如果要增加額外功能就用Decorator模式。從結構上講，Adapter可以是Subclassing結構也可以是Composition結構，而Decorator一般是Composition結構。事實上這兩個模式經常混在一起用。實用中我覺得沒必要太在意到底是什么模式，能起到作用就行。舉例來說，SurfaceFlingerConsumer是GLConsumer的Wrapper，當Layer調用SurfaceFlingerConsumer的接口，底層會部分使用GLConsumer的相應實現（事實上SurfaceFlingerConsumer和GLConsumer實現中有重復代碼）。我覺得它是用了subclassing結構來達到了類似Decorator模式的目的。當然這里模式用得不是很清晰，只是借機引下相關模式，例子跳過也罷。

?

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

SurfaceComposerClient::openGlobalTransaction();surfaceControl->setLayer(100000);SurfaceComposerClient::closeGlobalTransaction();?

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

ANativeWindow_Buffer outBuffer;surface->lock(&outBuffer, NULL);ssize_t bpr = outBuffer.stride * bytesPerPixel(outBuffer.format);android_memset16((uint16_t*)outBuffer.bits,0xF800, bpr*outBuffer.height);surface->unlockAndPost();

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

ssize_t bpr = outBuffer.stride * bytesPerPixel(outBuffer.format);android_memset16((uint16_t*)outBuffer.bits,0xF800, bpr*outBuffer.height);?

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

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

?

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

?

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

?

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

Region::const_iterator head(reg.begin()); Region::const_iterator tail(reg.end()); while(head != tail) {…}?

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

?

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

?

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

?

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

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

?

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

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

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

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

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

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

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

?

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

?

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

?

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

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

handleMessageInvalidate()主要調用handlePageFlip()函數。這里Page Flip是指從BufferQueue中取下一個圖形緩沖區內容，就好像是“翻頁”一樣。該函數主要是從各Layer對應的BufferQueue中拿圖形緩沖區數據，并根據內容更新臟區域。

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

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

?

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

轉載于:https://my.oschina.net/jerikc/blog/508779

總結

以上是生活随笔為你收集整理的Android 4.4(KitKat)中的设计模式-Graphics子系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。