Android graphic: windows manager

學習目的：

我閱讀過網絡上相關的資料，有一些過度的簡略，另一些，直接在分析代碼，而忽略了思路的介紹，容易讓人無所適從。

交代清楚是什麼，比交代清楚過程更重要。首先要側重交代一下重要的實體，作什麼的？之間的大概關係。更細節的，須要交代一下流程。

  1） wms是android service中最複雜的一部分。理解它，對於理解android顯示過程以及整個的工做流程，大有裨益。

2） 不須要深刻到每一行代碼。首先須要知道它的做用，它和外部模塊的交互做用；更進一步的，須要瞭解裏面關鍵的數據結構和代碼。

 

 

windows manager窗口管理要解決的問題是什麼？

1）z-order的計算。須要計算哪些窗口應該顯示，哪些窗口應該隱藏。

2）分發用戶輸入的事件。

　　　　windowmanagerService把窗口信息傳遞給InputManager，這樣InputDispatcher就能根據當前窗口的狀態進行消息處理。

 （引用自http://www.cnblogs.com/noTice520/archive/2012/10/25/2738050.html）

2） 窗口的顯示和隱藏控制

4.      焦點窗口(focus window)管理

5.      輸入法窗口管理和牆紙窗口管理

6.      切換動畫

7.      系統消息收集和分發

 

採起的是什麼架構？？

c-s模式。客戶端有窗口管理相關的東西，服務器端有windows manager service。

 

Iwindow 接口的主要做用是，當用戶有操做時，wms會經過Iwindow的接口，通知客戶端（下文的viewrootimpl）

以下圖所示。

 

IwindowSession 接口的主要做用是，當客戶端要建立window，添加window， 從新佈局等操做時，會經過該接口，向wms 申請服務。

以下圖所示：

 

 

窗口管理在客戶端的部分主要作什麼？？？總結一下？？？

---》在客戶端，window的建立過程須要從這裏告訴server。須要處理添加視圖。須要處理server段傳遞過來的輸入輸出事情，並做出相應。

另外，顯示過程的measure, layout 過程也涉及了它？

 

首先關注一下客戶端的幾個重要的組成部分的意思。

Window

  按照google的解釋，window是一個比較抽象的概念。

》》》》》》

Abstract base class for a top-level window look and behavior policy. An instance of this class should be used as the top-level view added to the window manager. It provides standard UI policies such as a background, title area, default key processing, etc.

》》》》》》

舉個例子，實際app中,app activity建立出來後，顯示ui 控件的那一層，就有一個window。假如彈出了一個對話框，這個對話框又會單首創建一個window。

（Q? window和dumpsys看到的layer數目是對應的嗎？surfaceview是一個單獨的window嗎？window 還有什麼具體的功能？？）

window 是抽象的基類。它的具體實現是一個叫作Phonewindow的類。

 

windowmanagerimpl

WindowManagerImp是窗口管理器在客戶端的一個代理，經過它，能夠和windows manager service通訊，申請一些服務。

 

decorview

decorview是定義在前面提到的phonewindow 類裏面的一個內部類。它是一個viewgroup，至關因而子view的一個容器。

 

ViewrootImpl

viewroot 是一個很是重要的類。它和wms之間有兩個binder接口通訊，一個是申請wms的服務的，一個被wms通知事件的。

它也是做圖的起點。它裏面的PerformTraversal 函數是做圖的入口函數。這個函數從decorview出發，對真個的view hierachy作圖。

  

在服務器端, windows manager service 會處理一些客戶端很差處理的事情，好比

1）管理好window的建立和刪除工做。

客戶端建立window的請求會在wms中處理，wms會經過一個windowstate 類型的數組，保存好全部的window，這樣才方便作z-order處理。

另外wms會幫忙客戶端向surfaceflinger去申請建立surface。統一建立的surface 方便共享訪問。客戶端拿到surface後，方能夠做圖顯示。

 2)

　　計算activity 窗口的大小。只有知道了這個大小，客戶端才能進行隨後的ui 元素的Measuare, layout, draw的工做。

　　 activity窗口的大小，由於涉及到了status bar, input window等東西，因此須要經過wms才能計算。

 

3）將各個窗口的屬性，例如，大小、位置等屬性，通知SurfaceFlinger服務了，也就是讓SurfaceFlinger服務更新它裏面的各個Layer的屬性值，以即可以對這些Layer執行可見性計算、合成等操做，最後渲染到硬件幀緩衝區中去。SurfaceFlinger服務計算系統中各個窗口，即各個Layer的可見性，以便將它們合成、渲染到硬件幀緩衝區的過程能夠參考前面Android系統Surface機制的SurfaceFlinger服務渲染應用程序UI的過程分析一文

 

 
3） 窗口的動畫顯示過程和窗口的可見性更新過程是wms最核心的部分

 4）

 

 下面表述一下主要的數據結構之間的關係：

　 這張圖片不錯，解釋一下。圖片表示的是通過windowManager.addview操做後，造成的數據結構之間的關係。

View 是decorview， 每個decorview會有一個viewroot對應着。每個viewroot 會有兩個binder接口，負責和wms通訊。

一個activity 可能有多個decorview/viewroot, 有數組來保存他們。當須要Update /delete/ add view的時候，這個數組就有用。

 

（notes: 這裏使用了一個數據結構：WindowManagerGlobal。它裏面保存了進程裏面全部的decorview, viewroot.它是一個singleton。爲何windowmanagerimpl不是singleton??? 由於

假如彈出一個對話框，Dialog，它的構造函數裏面，就會要求建立一個新的Phonewindow和windowmanagerimpl

因此一個activity裏面，可能有多個windowmanagerimpl。可是這些windowmanagerimpl，共享了一個WindowManagerGlobal 。

）每個viewroot在server端，又對應了一個winowstate來記錄窗口狀態。

 

 

這張圖表示了幾個數據結構之間的關係。 首先會建立一個phonewindow，往這個window上面，添加一個decorview.

建立一個新的viewroot。viewroot建立的過程當中，會建立binder接口和wms通訊。

在wms那邊，添加window的過程，會建立一個對應的windowstate.