從乾坤大挪移的知識可知，前面創建的所有對象都在WindowManagerService所在的進程system_server中，而writeToParcel則需要把一些信息打包到Parcel后，發送到Activity所在的進程。到底哪些內容需要回傳給Activity所在的進程呢？ 后文將Activity所在的進程簡稱為Activity端。 1. writeToParcel分析 writeToParcel比較簡單，就是把一些信息寫到Parcel中去。代碼如下所示： **SurfaceControl.cpp** ~~~ status_t SurfaceControl::writeSurfaceToParcel( const sp<SurfaceControl>& control, Parcel* parcel) { uint32_t flags = 0; uint32_t format = 0; SurfaceID token = -1; uint32_t identity = 0; uint32_t width = 0; uint32_t height = 0; sp<SurfaceComposerClient> client; sp<ISurface> sur; if(SurfaceControl::isValid(control)) { token = control->mToken; identity= control->mIdentity; client = control->mClient; sur = control->mSurface; width = control->mWidth; height = control->mHeight; format = control->mFormat; flags = control->mFlags; } //SurfaceComposerClient的信息需要傳遞到Activity端，這樣客戶端那邊會構造一個 //SurfaceComposerClient對象 parcel->writeStrongBinder(client!=0 ? client->connection() : NULL); //把ISurface對象信息也寫到Parcel中，這樣Activity端那邊也會構造一個ISurface對象 parcel->writeStrongBinder(sur!=0?sur->asBinder(): NULL); parcel->writeInt32(token); parcel->writeInt32(identity); parcel->writeInt32(width); parcel->writeInt32(height); parcel->writeInt32(format); parcel->writeInt32(flags); returnNO_ERROR; } ~~~ Parce包發到Activity端后，readFromParcel將根據這個Parcel包構造一個Native的Surface對象，一起來看相關代碼。 2. 分析Native的Surface創建過程 **android_view_Surface.cpp** ~~~ static void Surface_readFromParcel( JNIEnv* env, jobject clazz, jobject argParcel) { Parcel* parcel = (Parcel*)env->GetIntField( argParcel, no.native_parcel); const sp<Surface>& control(getSurface(env,clazz)); //根據服務端的parcel信息來構造客戶端的Surface sp<Surface> rhs = new Surface(*parcel); if(!Surface::isSameSurface(control, rhs)) { setSurface(env, clazz, rhs); } } ~~~ Native的Surface是怎么利用這個Parcel包的？代碼如下所示： **Surface.cpp** ~~~ Surface::Surface(const Parcel& parcel) :mBufferMapper(GraphicBufferMapper::get()), mSharedBufferClient(NULL) { /* Surface定義了一個mBuffers變量，它是一個sp<GraphicBuffer>的二元數組，也就是說Surface也存在二個GraphicBuffer，而之前在創建Layer的時候也有兩個GraphicBuffer，難道一共有四個GraphicBuffer？這個問題，后面再解答。 */ sp<IBinder> clientBinder =parcel.readStrongBinder(); //得到ISurface的Bp端BpSurface。 mSurface =interface_cast<ISurface>(parcel.readStrongBinder()); mToken = parcel.readInt32(); mIdentity = parcel.readInt32(); mWidth = parcel.readInt32(); mHeight = parcel.readInt32(); mFormat = parcel.readInt32(); mFlags = parcel.readInt32(); if (clientBinder != NULL) { /* 根據ISurfaceFlingerClient對象構造一個SurfaceComposerClient對象，注意我們 現在位于Activity端，這里還沒有創建SurfaceComposerClient對象，所以需要創建一個 */ mClient = SurfaceComposerClient::clientForConnection(clientBinder); //SharedBuffer家族的最后一員ShardBufferClient終于出現了。 mSharedBufferClient = new SharedBufferClient( mClient->mControl, mToken, 2,mIdentity); } init();//做一些初始化工作。 } ~~~ 在Surface創建完后，得到什么了呢？看圖8-18就可知道： :-:  圖8-18 Native Surface的示意圖 上圖很清晰地說明： - ShardBuffer家族依托共享內存結構SharedClient與它共同組成了Surface系統生產/消費協調的中樞控制機構，它在SF端的代表是SharedBufferServer，在Activity端的代表是SharedBufferClient。 - Native的Surface將和SF中的SurfaceLayer建立Binder聯系。 另外，圖中還特意畫出了承載數據的GraphicBuffer數組，在代碼的注釋中也針對GraphicBuffer提出了一個問題：Surface中有兩個GraphicBuffer，Layer也有兩個，一共就有四個GraphicBuffer了，可是為什么這里只畫出兩個呢？ 答案是，咱們不是有共享內存嗎？這四個GraphicBuffer其實操縱的是同一段共享內存，所以為了簡單，就只畫了兩個GraphicBuffer。在8.4.7節再介紹GraphicBuffer的故事。 下面，來看中樞控制機構的SharedBuffer家族。 3. SharedBuffer家族介紹 （1）SharedBuffer家族成員 SharedBuffer是一個家族名稱，它包括多少成員呢？來看SharedBuffer的家族圖譜，如圖8-19所示： :-:  圖8-19 SharedBuffer家族介紹 從上圖可以知道： - XXXCondition、XXXUpdate等都是內部類，它們主要是用來更新讀寫位置的。不過這些操作，為什么要通過類來封裝呢？因為SharedBuffer的很多操作都使用了C++中的Function Object（函數對象），而這些內部類的實例就是函數對象。函數對象是什么？它怎么使用？對此，在以后的分析中會介紹。 （2）SharedBuffer家族和SharedClient的關系 前面介紹過，SharedBufferServer和SharedBufferClient控制的其實只是SharedBufferStack數組中的一個，下面通過SharedBufferBase的構造函數，來看是否如此。 **SharedBufferStack.cpp** ~~~ SharedBufferBase::SharedBufferBase(SharedClient*sharedClient, int surface, int num, int32_t identity) : mSharedClient(sharedClient), mSharedStack(sharedClient->surfaces+ surface), mNumBuffers(num), //根據前面PageFlipping的知識可知，num值為2 mIdentity(identity) { /* 上面的賦值語句中最重要的是第二句： mSharedStack(sharedClient->surfaces +surface) 這條語句使得這個SharedBufferXXX對象，和SharedClient中SharedBufferStack數組 的第surface個元素建立了關系 */ } ~~~ 4. Native Surface總結 至此，Activity端Java的Surface對象，終于和一個Native Surface對象掛上了鉤，并且這個Native Surface還準備好了繪圖所需的一切，其中包括： - 兩個GraphicBuffer，這就是PageFlipping所需要的FrontBuffer和BackBuffer。 - SharedBufferServer和SharedBufferClient結構，這兩個結構將用于生產/消費的過程控制。 - 一個ISurface對象，這個對象連接著SF中的一個SurfaceLayer對象。 - 一個SurfaceComposerClient對象，這個對象連接著SF中的一個BClient對象。 資源都已經準備好了，可以開始繪制UI了。下面，分析兩個關鍵的函數lockCanvas和unlockCanvasAndPost。