Android文章摘要教學(xué)教材

1、Good is good, but better carries it.精益求精，善益求善。Android文章摘要AndroidGDI之基本原理及其總體框架AndroidGDI基本框架在Android中所涉及的概念和代碼最多，最繁雜的就是GDI相關(guān)的代碼了。但是本質(zhì)從抽象上來(lái)講，這么多的代碼和框架就干了一件事情：對(duì)顯示緩沖區(qū)的操作和管理。GDI主要管理圖形圖像的輸出,從整體方向上來(lái)看,GDI可以被認(rèn)為是一個(gè)物理屏幕使用的管理器。因?yàn)樵趯?shí)際的產(chǎn)品中，我們需要在物理屏幕上輸出不同的窗口，而每個(gè)窗口認(rèn)為自己獨(dú)占屏幕的使用，對(duì)所有窗口輸出，應(yīng)用程序不會(huì)關(guān)心物理屏幕是否被別的窗口占用，而只是關(guān)心自己在本

2、窗口的輸出，至于輸出是否能在屏幕上看見(jiàn)，則需要GDI來(lái)管理。從最上層到最底層的數(shù)據(jù)流的分析可以看到實(shí)際上GDI在上層為GUI提供一個(gè)抽象的概念,就好像操作系統(tǒng)中的文件系統(tǒng)所提供文件，目錄等抽象概念一樣，GDI輸出抽象成了文本,畫(huà)筆,位圖操作等設(shè)備無(wú)關(guān)的操作,讓?xiě)?yīng)用程序員只需要面對(duì)邏輯的設(shè)備上下文進(jìn)行輸出操作,而不要涉及到具體輸出設(shè)備,以及輸出邊界的管理。GDI負(fù)責(zé)將文本、線條、位圖等概念對(duì)象映射到具體的物理設(shè)備，所以GDI的在大體方向上可以分為以下幾大要素：畫(huà)布字體文本輸出繪畫(huà)對(duì)象位圖輸出Android的GDI系統(tǒng)Android的GDI系統(tǒng)所涉及到概念太多，加之使用了OpenGL使得Andro

3、id的層次和代碼很繁雜。但是我們對(duì)于Android的GDI系統(tǒng)需要了解的方面不是他的靜態(tài)的代碼關(guān)系，而是動(dòng)態(tài)的對(duì)象關(guān)系，在邏輯運(yùn)行的架構(gòu)上理解GDI。我們首先還是需要從代碼結(jié)構(gòu)開(kāi)始我們的理解。Frameworks/Libs/SurfaceflingerFrameworks/base/core/jni/android_view_Surface.cppFrameworks/base/core/java/android/view/surface.javaFrameworks/base/Graphics：繪圖接口Frameworks/Libs/UiExternal/Skia其中External/Ski

4、a是一個(gè)C+的2D圖形引擎庫(kù)，Android的2D繪制系統(tǒng)都是建立在該基礎(chǔ)之上.Skia完成了：文本輸出，位圖，點(diǎn)，線，圖像解碼等功能。在這里給出AndroidGDI的基本框架示意圖。對(duì)于上面的GDI架構(gòu)圖我們只是一個(gè)大概的了解，我們有太多的問(wèn)題需要解決，有太多的疑問(wèn)需要得到答案，我就一直在想，為什么設(shè)計(jì)者有提出如此眾多的概念，這個(gè)概念的背景是什么？他要管理什么，他要抽象什么？從前面知道，Android的整個(gè)設(shè)計(jì)理念就是無(wú)邊界化，他是如何穿透Linux進(jìn)程這個(gè)鴻溝來(lái)達(dá)到無(wú)邊界的？Surface，Canvas，Layer，LayerBase,NativeBuffer，SurfaceFlinger

5、，SurfaceFlingerClient這些到底是一個(gè)什么東西？如何管理，傳遞的是什么？創(chuàng)建的是什么？這些都是抽象的概念，繪畫(huà)的終極的緩沖區(qū)到底是如何管理的？緩沖區(qū)到底在哪里？我們還是看看做終極的，最本質(zhì)的設(shè)計(jì)概念，在從這些概念出發(fā)，來(lái)探討這些概念的形成過(guò)程，是否有必要去生成寫(xiě)概念。SurfaceFlinger本質(zhì)上干什么的？SurfaceFlinger的確就是這個(gè)意義：應(yīng)用程序通過(guò)SurfaceFlinger將自己的“Surface”投擲到屏幕緩沖區(qū)。至于如何投擲的，我們將會(huì)在后面詳細(xì)描述。AndroidGDI之顯示緩沖管理AndroidGDI之屏幕設(shè)備管理-動(dòng)態(tài)鏈接庫(kù)萬(wàn)丈高樓從地起，從最

6、根源的硬件幀緩沖區(qū)開(kāi)始。我們知道顯示FrameBuffer在系統(tǒng)中就是一段內(nèi)存,GDI的工作就是把需要輸出的內(nèi)容放入到該段內(nèi)存的某個(gè)位置。我們從基本的點(diǎn)（像素點(diǎn)）和基本的緩沖區(qū)操作開(kāi)始。基本知識(shí)點(diǎn)的格式對(duì)于不同的LCD來(lái)講，F(xiàn)rameBuffer的二進(jìn)制格式不一樣，并且可以分為兩部分：1)點(diǎn)的格式：通常將Depth,即表示多少位表示一個(gè)點(diǎn)。1位表示一個(gè)點(diǎn)2位表示一個(gè)點(diǎn)16位表示一個(gè)點(diǎn)32位表示一個(gè)點(diǎn)（Alpha通道）2)點(diǎn)內(nèi)格式：RGB分量分布表示。例如對(duì)于我們常見(jiàn)的16位表示一個(gè)點(diǎn)格式之間的轉(zhuǎn)換所以屏幕輸出實(shí)際上是一個(gè)值映射的關(guān)系。我們可以有如下的點(diǎn)格式轉(zhuǎn)換，源格式可能來(lái)自單色位圖和彩色位圖

7、，對(duì)于具體的目標(biāo)機(jī)來(lái)講，我們的目標(biāo)格式可能就是一種，例如16位（5/6/5）格式。其實(shí)就只存在一種格式的轉(zhuǎn)換，即從目標(biāo)格式都是16位格式。但是，在設(shè)計(jì)GDI時(shí)，基本要求有一個(gè)可移植性好，所以我們還是必須考慮對(duì)于不同點(diǎn)格式LCD之間的轉(zhuǎn)換操作。所以在GDI的驅(qū)動(dòng)程序中涉及到區(qū)域操作(Blit)：我們?cè)陲@示緩沖區(qū)上做的最多的操作就是區(qū)塊搬運(yùn)。由此，很多的應(yīng)用處理器使用了硬件圖形加速器來(lái)完成區(qū)域搬運(yùn):blit.從我們的主要操作的對(duì)象來(lái)看,可以分為兩個(gè)方向:內(nèi)存區(qū)域到屏幕區(qū)域屏幕區(qū)域到屏幕區(qū)域屏幕區(qū)域到內(nèi)存區(qū)域內(nèi)存區(qū)域到內(nèi)存區(qū)域在這里我們需要特別提出的是，由于在Linux不同進(jìn)程之間的內(nèi)存不能自由的訪

8、問(wèn)，使得我們的每個(gè)Android應(yīng)用對(duì)于內(nèi)存區(qū)域和屏幕緩沖區(qū)的使用變得很復(fù)雜。在Android的設(shè)計(jì)中，在屏幕緩沖區(qū)和顯示內(nèi)存緩沖區(qū)的管理分類(lèi)很多的層次，最上層的對(duì)象是可以在進(jìn)程間自由傳遞，但是對(duì)于緩沖區(qū)內(nèi)容則使用共享內(nèi)存的機(jī)制?；谝陨系幕A(chǔ)知識(shí)，我們可以知道：（1）代碼中Config及其Format的意義所在了。也就理解了兼容性的意義：采用同硬件相同的點(diǎn)的描述對(duì)象（2）所有屏幕上圖形的移動(dòng)都是顯示緩沖區(qū)搬運(yùn)的結(jié)果。圖形加速器應(yīng)用處理器都可能帶有圖形加速器，對(duì)于不同的應(yīng)用處理器對(duì)其圖形加速器可能有不同的處理方式，對(duì)于2D加速來(lái)講，都可歸結(jié)為blit。多為數(shù)據(jù)的搬運(yùn)，放大縮小，旋轉(zhuǎn)等。Andr

9、oid的緩沖區(qū)抽象定義不同的硬件有不同的硬件圖形加速設(shè)備和緩沖內(nèi)存實(shí)現(xiàn)方法。AndroidGralloc動(dòng)態(tài)庫(kù)抽象的任務(wù)就是消除不同的設(shè)備之間的差別，在上層看來(lái)都是同樣的方法和對(duì)象。在Moudle層隱藏緩沖區(qū)操作細(xì)節(jié)。Android使用了動(dòng)態(tài)鏈接庫(kù)gralloc.xxx.so，來(lái)完成底層細(xì)節(jié)的封裝。2.1本地定義hardwarelibhandwaremodulesgralloc每個(gè)動(dòng)態(tài)鏈接庫(kù)都是用相同名稱(chēng)的調(diào)用接口：硬件圖形加速器的抽象：BlitEngine，CopyBit的加速操作。硬件FrameBuffer內(nèi)存管理共享緩存管理從數(shù)據(jù)關(guān)系上我們來(lái)考察動(dòng)態(tài)鏈接庫(kù)的抽象行為：在層次HYPERLI

10、NKmailto:Hardware.chardware%5ClibhardwareHardware.chardwarelibhardware中對(duì)動(dòng)態(tài)鏈接庫(kù)中的內(nèi)容作了全新的包裝。/system/lib/hw/gralloc.xxx.so動(dòng)態(tài)庫(kù)文件。從文件Gralloc.h(handwarelibhardwareincludehardware)是抽象的結(jié)果：hw_get_module從gralloc.xxx.so提取了HAL_MODULE_INFO_SYM（SYM變量）從展露在外部的數(shù)據(jù)結(jié)構(gòu)，HYPERLINKmailto:%E6%88%91%E4%BB%AC%E5%9C%A8Gralloc.c

11、pp我們?cè)贕ralloc.cpp看到到了這樣的布局：staticstructhw_module_methods_tgralloc_module_methods=open:gralloc_device_open;structprivate_module_tHAL_MODULE_INFO_SYM=base:common:tag:HARDWARE_MODULE_TAG,id:GRALLOC_HARDWARE_MODULE_ID,name:GraphicsMemoryAllocatorModule,author:TheAndroidOpenSourceProject,methods:&gralloc_

12、module_methods,registerBuffer:gralloc_register_buffer,unregisterBuffer:gralloc_unregister_buffer,lock:gralloc_lock,unlock:gralloc_unlock,framebuffer:0,flags:0,numBuffers:0,bufferMask:0,;我們建立了什么對(duì)象來(lái)支撐緩沖區(qū)的操作？buffer_handle_t：外部接口。methods.open，registerBuffer，unregisterBuffer，lock，unlock下面是外部接口和內(nèi)部對(duì)象的結(jié)構(gòu)關(guān)系，

13、該類(lèi)型的結(jié)構(gòu)充分利CStruct的數(shù)據(jù)排列特性：基本結(jié)構(gòu)體放置在最前面，本地私有放置在后面，滿(mǎn)足了抽象的需要。typedefconstnative_handle*buffer_handle_t;private_module_tHAL_MODULE_INFO_SYM向往暴露的動(dòng)態(tài)鏈接庫(kù)接口，通過(guò)該接口，我們直接可以使用該對(duì)象。幾個(gè)接口函數(shù)的解釋?zhuān)?1)fb_post對(duì)于幀緩沖區(qū)實(shí)際地址并不需要向上層報(bào)告，所有的操作都是通過(guò)fb_post了完成。fp_post的任務(wù)就是將一個(gè)Buffer的內(nèi)容傳遞到硬件緩沖區(qū)。其實(shí)現(xiàn)方式有兩種：（方式1）無(wú)需拷貝動(dòng)作，是把Framebuffer的后buffer切為

14、前buffer，然后通過(guò)IOCTRL機(jī)制告訴FB驅(qū)動(dòng)切換DMA源地地址。這個(gè)實(shí)現(xiàn)方式的前提是Linux內(nèi)核必須分配至少兩個(gè)緩沖區(qū)大小的物理內(nèi)存和實(shí)現(xiàn)切換的ioctrol，這個(gè)實(shí)現(xiàn)快速切換。（方式2）利用Copy的方式。不修改內(nèi)核，則在適配層利用從拷貝的方式進(jìn)行，但是這個(gè)是費(fèi)時(shí)了。(2)gralloc的主要功能是要完成：1）打開(kāi)屏幕設(shè)備/dev/fb0,，并映射硬件顯示緩沖區(qū)。2）提供分配共享顯示緩存的接口3）提供BiltEngine接口（完成硬件加速器的包裝）（3）gralloc_alloc輸出buffer_handle_t句柄。這個(gè)句柄是共享的基本依據(jù)，其基本原理在后面的章節(jié)有詳細(xì)描述。3總

15、結(jié)總結(jié)一下，/system/lib/hw/gralloc.xxx.so是跟硬件體系相關(guān)的一個(gè)動(dòng)態(tài)鏈接庫(kù)，也可以叫做Android的硬件抽象層。他實(shí)現(xiàn)了Android的硬件抽象接口標(biāo)準(zhǔn)，提供顯示內(nèi)存的分配機(jī)制和CopyBit等的加速實(shí)現(xiàn)。而如何具體實(shí)現(xiàn)這些功能，則跟硬件平臺(tái)的配備有關(guān)系，所以我們看到了對(duì)于與不同的硬件架構(gòu)，有不同的配置關(guān)系。AndroirdGDI之共享緩沖區(qū)機(jī)制1Native_handle_t對(duì)private_handle_t的包裹private_handle_t是gralloc.so使用的本地緩沖區(qū)私有的數(shù)據(jù)結(jié)構(gòu)，而Native_handle_t是上層抽象的可以在進(jìn)程間傳遞的數(shù)

16、據(jù)結(jié)構(gòu)。在客戶(hù)端是如何還原所傳遞的數(shù)據(jù)結(jié)構(gòu)呢？首先看看native_handle_t對(duì)private_handle_t的抽象包裝。HYPERLINK/attachment/201006/14/0_12765041031rsn.gifnumFds=sNumFds=1;numInts=sNumInts=8;這個(gè)是Parcel中描述句柄的抽象模式。實(shí)際上是指的Native_handle所指向句柄對(duì)象的具體內(nèi)容：numFds=1表示有一個(gè)文件句柄：fd/numInts=8表示后面跟了8個(gè)INT型的數(shù)據(jù)：magic,flags,size,offset,base,lockState,writeOwner,

17、pid;由于在上層系統(tǒng)不要關(guān)心buffer_handle_t中data的具體內(nèi)容。在進(jìn)程間傳遞buffer_handle_t(native_handle_t)句柄是其實(shí)是將這個(gè)句柄內(nèi)容傳遞到Client端。在客戶(hù)端通過(guò)Binder讀取readNativeHandleParcel.cpp新生成一個(gè)native_handle。native_handle*Parcel:readNativeHandle()constnative_handle*h=native_handle_create(numFds,numInts);for(inti=0;err=NO_ERROR&ih-datai=dup(read

18、FileDescriptor();if(h-dataidata+numFds,sizeof(int)*numInts);.returnh;這里需要提到的是為在構(gòu)造客戶(hù)端的native_handle時(shí)，對(duì)于對(duì)方傳遞過(guò)來(lái)的文件句柄的處理。由于不是在同一個(gè)進(jìn)程中，所以需要dup()一下為客戶(hù)端使用。這樣就將Native_handle句柄中的，客戶(hù)端感興趣的從服務(wù)端復(fù)制過(guò)來(lái)。這樣就將Private_native_t的數(shù)據(jù)：magic,flags,size,offset,base,lockState,writeOwner,pid;復(fù)制到了客戶(hù)端。客戶(hù)端利用這個(gè)新的Native_buffer被Mapper

19、傳回到gralloc.xxx.so中，獲取到native_handle關(guān)聯(lián)的共享緩沖區(qū)映射地址，從而獲取到了該緩沖區(qū)的控制權(quán)，達(dá)到了客服端和Server間的內(nèi)存共享。從SurfaceFlinger來(lái)看就是作圖區(qū)域的共享。2GraphicMapper是干什么的？服務(wù)端（SurfaceFlinger）分配了一段內(nèi)存作為Surface的作圖緩沖，客戶(hù)端怎樣在這個(gè)作圖緩沖區(qū)上工作呢？這個(gè)就是Mapper(GraphicBufferMapper)要干的事情。兩個(gè)進(jìn)程間如何共享內(nèi)存，如何獲取到共享內(nèi)存？Mapper就是干這個(gè)的。需要利用到兩個(gè)信息：共享緩沖區(qū)設(shè)備句柄，分配時(shí)的偏移量。Mapper利用這樣的

20、原理：客戶(hù)端只有l(wèi)ock,unlock,實(shí)質(zhì)上就是mmap和ummap的操作。對(duì)于同樣一個(gè)共享緩沖區(qū)，偏移量才是總要的，起始地址不重要。實(shí)際上他們操作了同一物理地址的內(nèi)存塊。我們?cè)谏厦嬗懻摿薾ative_handle_t對(duì)private_handle_t的包裹過(guò)程，從中知道服務(wù)端給客戶(hù)端傳遞了什么東西。進(jìn)程1在共享內(nèi)存設(shè)備上預(yù)分配了8M的內(nèi)存。以后所有的分配都是在這個(gè)8M的空間進(jìn)行。對(duì)以該文件設(shè)備來(lái)講，8M物理內(nèi)存提交后，就實(shí)實(shí)在在的占用了8M內(nèi)存。每個(gè)進(jìn)程都可以同個(gè)該內(nèi)存設(shè)備共享該8M的內(nèi)存，他們使用的工具就會(huì)mmap。由于在mmap都是用0開(kāi)始獲取映射地址，所以所有的客戶(hù)端進(jìn)程都是有了同一

21、個(gè)物理起始地址，所以此時(shí)偏移量和size就可以標(biāo)識(shí)一段內(nèi)存。而這個(gè)偏移量和size是個(gè)數(shù)值，從服務(wù)進(jìn)程傳遞到客戶(hù)端直接就可以使用。HYPERLINK/attachment/201006/14/0_1276504116JHZ8.gif3GraphicBuffer（緩沖區(qū)代理對(duì)象）typedefstructandroid_native_buffer_tstructandroid_native_base_tcommon;intwidth;intheight;intstride;intformat;intusage;buffer_handle_thandle;android_native_buffer

22、_t;關(guān)系圖表：GraphicBuffer:EGLNativeBase:android_native_buffer_tGraphicBuffer(parcel&)建立本地的GraphicBuffer的數(shù)據(jù)native_buffer_t。在通過(guò)接收對(duì)方的傳遞的native_buffer_t構(gòu)建GraphicBuffer。我們來(lái)看看在客戶(hù)端Surface：lock獲取操作緩沖區(qū)的函數(shù)調(diào)用：Surface:lock(SurfaceInfo*other,Region*dirtyIn,boolblocking)intSurface:dequeueBuffer(android_native_buffer_

23、t*buffer)（Surface）status_tSurface:getBufferLocked(intindex,intusage)spbuffer=s-requestBuffer(index,usage);virtualsprequestBuffer(intbufferIdx,intusage)remote()-transact(REQUEST_BUFFER,data,&reply);spbuffer=newGraphicBuffer(reply);Surface：Lock建立一個(gè)在Client端建立了一個(gè)新的GraphicBuffer對(duì)象，該對(duì)象通過(guò)（1）描述的原理將SurfaceFl

24、inger的buffer_handle_t相關(guān)數(shù)據(jù)構(gòu)成新的客戶(hù)端buffer_handle_t數(shù)據(jù)。在客戶(hù)的Surface對(duì)象就可以使用GraphicMapper對(duì)客戶(hù)端buffer_handle_t進(jìn)行mmap從而獲取到共享緩沖區(qū)的開(kāi)始地址了。4總結(jié)Android在該節(jié)使用了共享內(nèi)存的方式來(lái)管理與顯示相關(guān)的緩沖區(qū)，他設(shè)計(jì)成了兩層，上層是緩沖區(qū)管理的代理機(jī)構(gòu)GraphicBuffer,及其相關(guān)的native_buffer_t,下層是具體的緩沖區(qū)的分配管理及其緩沖區(qū)本身。上層的對(duì)象是可以在經(jīng)常間通過(guò)Binder傳遞的，而在進(jìn)程間并不是傳遞緩沖區(qū)本身，而是使用mmap來(lái)獲取指向共同物理內(nèi)存的映射地

25、址。AndroidGDI之SurfaceFlinger1AndroidGDI之SurfaceFlingerSurfaceFinger按英文翻譯過(guò)來(lái)就是Surface投遞者。SufaceFlinger的構(gòu)成并不是太復(fù)雜，復(fù)雜的是他的客戶(hù)端建構(gòu)。SufaceFlinger主要功能是：1）將Layers（Surfaces）內(nèi)容的刷新到屏幕上2）維持Layer的Zorder序列，并對(duì)Layer最終輸出做出裁剪計(jì)算。3）響應(yīng)Client要求，創(chuàng)建Layer與客戶(hù)端的Surface建立連接4）接收Client要求，修改Layer屬性（輸出大小，Alpha等設(shè)定）但是作為投遞者的實(shí)際意義，我們首先需要知道的

26、是如何投遞，投擲物，投遞路線，投遞目的地。2SurfaceFlinger的基本組成框架SurfaceFlinger管理對(duì)象為：mClientsMap：管理客戶(hù)端與服務(wù)端的連接。ISurface，IsurfaceComposer：AIDL調(diào)用接口實(shí)例mLayerMap：服務(wù)端的Surface的管理對(duì)象。mCurrentState.layersSortedByZ：以Surface的Z-order序列排列的Layer數(shù)組。graphicPlane緩沖區(qū)輸出管理OpenGLES：圖形計(jì)算，圖像合成等圖形庫(kù)。gralloc.xxx.so這是個(gè)跟平臺(tái)相關(guān)的圖形緩沖區(qū)管理器。pmemDevice：提供共享內(nèi)

27、存，在這里只是在gralloc.xxx.so可見(jiàn)，在上層被gralloc.xxx.so抽象了。3SurfaceFingerClient和服務(wù)端對(duì)象關(guān)系圖的HYPERLINK/attachment/201006/14/0_12765192744dUQ.gifClient端與SurfaceFlinger連接圖：Client對(duì)象：一般的在客戶(hù)端都是通過(guò)SurfaceComposerClient來(lái)跟SurfaceFlinger打交道。4主要對(duì)象說(shuō)明4.1DisplayHardware&FrameBuffer首先SurfaceFlinger需要操作到屏幕，需要建立一個(gè)屏幕硬件緩沖區(qū)管理框架。Androi

28、d在設(shè)計(jì)支持時(shí)，考慮多個(gè)屏幕的情況，引入了graphicPlane的概念。在SurfaceFlinger上有一個(gè)graphicPlane數(shù)組，每一個(gè)graphicPlane對(duì)象都對(duì)應(yīng)一個(gè)DisplayHardware.在當(dāng)前的Android（2.1）版本的設(shè)計(jì)中，系統(tǒng)支持一個(gè)graphicPlane，所以也就支持一個(gè)DisplayHardware。SurfaceFlinger，Hardware硬件緩沖區(qū)的數(shù)據(jù)結(jié)構(gòu)關(guān)系圖如下：4.2Layermethod:setBuffer在SurfaceFlinger端建立顯示緩沖區(qū)。這里的緩沖區(qū)是指的HW性質(zhì)的，PMEM設(shè)備文件映射的內(nèi)存。1)layer的繪

29、制voidLayer:onDraw(constRegion&clip)constintindex=mFrontBufferIndex;GLuinttextureName=mT;drawWithOpenGL(clip,mTexturesindex);4.3mCurrentState.layersSortedByZ以Surface的Z-order序列排列的LayerBase數(shù)組，該數(shù)組是層顯示遮擋的依據(jù)。在每個(gè)層計(jì)算自己的可見(jiàn)區(qū)域時(shí)，從Z-order頂層開(kāi)始計(jì)算，是考慮到遮擋區(qū)域的裁減，自己之前層的可見(jiàn)區(qū)域就是自己的不可見(jiàn)區(qū)域。而繪制Layer時(shí)，則從Z-orde

30、r底層開(kāi)始繪制，這個(gè)考慮到透明層的疊加。5SurfaceFlinger的運(yùn)行框架我們從前面的章節(jié)的基本原理可以知道，SurfaceFlinger的運(yùn)行框架存在于：threadLoop,他是SurfaceFlinger的主循環(huán)體。SurfaceFlinger在進(jìn)入主體循環(huán)之前會(huì)首先運(yùn)行：SurfaceFlinger:readyToRun()。5.1SurfaceFlinger:readyToRun()（1）建立GraphicPanle（2）建立FrameBufferHardware(確定輸出目標(biāo))初始化：OpenGLES建立兼容的mainSurface.利用eglCreateWindowSurf

31、ace。建立OpenGLES進(jìn)程上下文。建立主Surface（OpenGLES）。DisplayHardware的Init()DisplayHardware.cpp函數(shù)對(duì)OpenGL做了初始化，并創(chuàng)建立主Surface。為什么叫主Surface，因?yàn)樗械腖ayer在繪制時(shí)，都需要先繪制在這個(gè)主Surface上，最后系統(tǒng)才將主Surface的內(nèi)容”投擲”到真正的屏幕上。（3）主Surface的綁定1)在DisplayHandware初始完畢后，hw.makeCurrent()將主Surface，OpenGLES進(jìn)程上下文綁定到SurfaceFlinger的上下文中，2)之后所有的Surface

32、Flinger進(jìn)程中使用EGL的所有的操作目的地都是HYPERLINKmailto:mSurfaceDisplayHardwaremSurfaceDisplayHardware。這樣，在OpenGL繪制圖形時(shí)，主Surface被記錄在進(jìn)程的上下文中，所以看不到顯示的主Surfce相關(guān)參數(shù)的傳遞。下面是Layer-Draw，Hardware.flip的動(dòng)作示意圖：5.2ThreadLoop(1)handleTransaction():主要計(jì)算每個(gè)Layer有無(wú)屬性修改，如果有修改著內(nèi)用需要重畫(huà)。(2)handlePageFlip()computeVisibleRegions：根據(jù)Z-Order序

33、列計(jì)算每個(gè)Layer的可見(jiàn)區(qū)域和被覆蓋區(qū)域。裁剪輸出范圍計(jì)算-在生成裁剪區(qū)域的時(shí)候，根據(jù)Z_order依次，每個(gè)Layer在計(jì)算自己在屏幕的可顯示區(qū)域時(shí)，需要經(jīng)歷如下步驟：1）以自己的W,H給出自己初始的可見(jiàn)區(qū)域2）減去自己上面窗口所覆蓋的區(qū)域在繪制時(shí)，Layer將根據(jù)自己的可將區(qū)域做相應(yīng)的區(qū)域數(shù)據(jù)Copy。（3）handleRepaint()composeSurfaces（需要刷新區(qū)域）：根據(jù)每個(gè)Layer的可見(jiàn)區(qū)域與需要刷新區(qū)域的交集區(qū)域從Z-Order序列從底部開(kāi)始繪制到主Surface上。（4）postFramebuffer()（DisplayHardware）hw.flip(mInvalidRegion);eglSwapBuffers(display,mSurface):將mSruface投遞到屏幕。6總結(jié)現(xiàn)在SurfaceFlinger干的事情利用下面的示意圖表示出來(lái)：SurfaceFlinger對(duì)象建立過(guò)程示意1SurfaceSession的建立客戶(hù)端請(qǐng)求建立Surface時(shí)，首先要與SurfaceFlinger建立一個(gè)Sessio