［android深入學習］android視窗管理機制

在學習 WindowManager 介面的時候，瞭解到這個介面很重要，因為它可以直接與Window Manager（視窗管理器）進行互動，那這個 Window Manager 究竟是怎麼一回事呢？

     通過尋找資料，我知道了 Window Manager 其實是一個 service（服務）。它是全域的，系統中唯一的，是獨立於android應用程式的，所有android應用程式公用的 一個單獨的C++服務。（這個“單獨的C++服務”的說法，建議先看看：android概念空間及seviceManager 的介紹）

 

1. 基本架構原理

    要瞭解這個服務，我們首先要對android的基本架構原理有個瞭解。

    Android 是基於 C/S 模式的。在我們的根深蒂固的想法中，C/S架構就是 用戶端和服務端直接通過Binder互動資料，開啟Binder寫入資料，通過Binder讀取資料，通訊就可以完成了。如：

 

 

    然而，在 Android 的概念中，Binder 是一個很低層的概念，是 Linux 核心提供的 Binder 通訊機制。上面一層根本都看不到 Binder ，而是 Activity 跟一個 Service 的對象直接通過方法調用，擷取服務。

    這個就是Android提供給我們的外特性：在Android中，要完成某個操作，所需要做的就是請求某個有能力的服務物件去完成動作，而無需知道這個通訊是怎樣工作的，以及服務在哪裡。所以 Andoid 的 IPC（處理序間通訊）在本質上屬於對象請求代理架構（對象請求代理架構：CORBA ）。就是說它不僅解決了進程間的通訊問題，還是一個架構，提出了一種設計理念。

 

    既然android的IPC 的本質是CORBA，那麼我們就來分析一下CORBA。

   【CORBA】

    由OMG組織制訂的一種標準的物件導向應用程式體系規範，或者說 CORBA體繫結構是對象管理組織（OMG）為解決分散式處理環境(DCE)中，硬體和軟體系統的互連而提出的一種解決方案。

    CORBA定議了一系列API，通訊協定，和 物件/服務資訊模型 用於使得異質應用程式能夠互相操作，這些應用程式用不同的程式語言編寫，運行在不同的平台上。CORBA因此為定義明確的物件提供了平台和位置的透明性，這些物件是分散式運算平台的基礎。

    COBRA標準主要分為3個層次：對象請求代理、公用物件服務和公用設施。最底層最核心就是ORB(對象請求代理)。

    ORB規定了分布對象的定義（介面）和語言映射，實現對象間的通訊和互操作，是分布對象系統中的"軟匯流排"；在ORB之上定義了很多公用服務，可以提供諸如並發服務、名字服務、事務(交易)服務、安全服務等各種各樣的服務；最上層的公用設施則定義了組件架構，提供可直接為業務對象使用的服務，規定業務對象有效協作所需的協定規則

        【ORB】     

         ORB是一個在對象間建立客戶/伺服器聯絡的中件。使用ORB，客戶可以調用伺服器的對象或對象中的應用，被調用的對象不要求在同一台機器上。由ORB負責進行通訊，同時ORB也會在調用對象完成後返回結果。客戶對象完全可以不關心伺服器對象的位置，實現它所採用的具體技術和工作的硬體平台，甚至不必關心伺服器對象的與服務無關的介面資訊，這就大大簡化了客戶程式的工作。既然能夠這麼方便，那ORB就需要提供在不同機器間應用程式間的通訊，資料轉換，並提供多個物件系統的無縫串連。

    CORBA 的本質以圖的形式展現就是如下：

    

  

    在服務端，多了個代理器：

    

   

 

    分析了CORBA的大體理論架構，下面我們來看一下Android的對象代理結構：

    

 

在結構圖中，我們可以較為清楚的把握Android的ＩＰＣ包含了如下的概念：

• 裝置上下文什（ContextObject）

        裝置上下文包含關於客服端，環境或者請求中沒有作為參數傳遞個操作的上下文資訊，應用程式開發人員用ContextObject介面上定義的操作來建立和操作上下文。

• Android代理：這個是指服務端在用戶端的代理對象
• Binder ：Linux核心提供的Binder通訊機制（底層）
• AIDL : Android 中的遠程介面

Android的外特性空間是不需要知道服務在那裡，只要通過代理對象完成請求。

 

 

2.視窗管理概述

    瞭解了Android 的基本架構原理，現在我們回到視窗管理這一塊。

    Android 的視窗管理是基於 C/S 模式的，用戶端就是應用程式，服務端 就是 Window Manager服務。如：

 

     

   

    Activity 建立一個主視窗之後，在將主視窗添加到 Window Manager 時，首先要建立 Window Manager的代理對象，並開啟一個Session（session：會話；實現 IWindowSession AIDL 介面），並維持該會話（Activity 將通過該會話與 Window Manager 建立聯絡，這個Session 是C/S 體系的基礎）。Client 通過這個Session 將 window 加入到 Window Manager 中。

    一個完整的視窗概念包含了 View，ViewRoot，Window Manager Service，Window，Decor View，IWindow，ISession，WindowState。他們之間的關係如下：

 

     

   

    Client 端的 Activity 通過 IWindowSession 會話與Window Manager Service 建立對話，而 Window Manager Service 通過 IWindow 介面訪問 Client，將訊息傳遞到Client 端，在通過訊息分發渠道，將訊息傳遞到具體的訊息處理函數。（使用者輸入等操作最先是到 視窗管理服務，由視窗管理服務發給使用中視窗，再一步步傳遞到焦點）。

 

 

3. Client 端

 

   用戶端組成：

       Window，View，ViewRoot，Window Manager Proxy

 

   View：

       View 在 Android 中包含了 互動 和顯示。

       在Activity 在 performLaunchActivity 時，會使用Activity.attach() 建立一個 PhoneWindow 主視窗。這個主視窗的建立並不是一個重點。handleResumeActivity 真正要啟動一個Activity 的時候，會將主視窗加入到 Window Manager，當然並不是主視窗本身，而是指的主視窗的 DecorView 。

      DecorView ：實際上是一個ViewGroup ，在依存關係上來講，對看這主視窗來講，DecorView 是 Top-Level View 。如：

 

     View 的成員變數 mParent 用來管理 View 上級關係。而 ViewGroup 裡構建了焦點管理和子 View 節點數組。這樣通過 View 的mParent 和 ViewGroup的 mChildren 構建了 Android 中View直接的關係網。如：

 

        

 

 

  Focus Path

     所謂的 Foucs Path 就是我們的KeyEvent 傳遞的路線。一般的我們的KeyEvent 在主迴圈中，主View 通過View的焦點記錄關係傳遞到焦點 View。例如，View22是焦點，最頂層的View 通過 mFoucs 的關係鏈找到最後形成的路徑就是 Foucs Path。如紅線所示：

 

       

 

 

  ViewRoot

• ViewRoot 實際上是一個 Handler，ViewRoot 簡曆主View 與 WindowsManager 通訊的橋樑。
• ViewRoot 本質上就是一個 Handler，我們知道 Handler 的準系統 就是處理回調，發送訊息。

     ViewRoot 通過 IWindowSession AIDL 添加視窗到 Window Manager ，而 IWindow AIDL 是Window Manager 分發訊息給 Client ViewRoot 的渠道。

 

       

 

 

  Window Manager Proxy

     Activity 在使用 getSystemService 擷取 WindowManagerImpl 時，建立了一個 WindowManagerImpl 的執行個體，這就是 Window Manager服務 的代理。

     wm=(WindowManagerImpl )context.getSystemService(Context.WINDOW_SERVICE);

     並調用 wm.addview 添加視窗到 WMService 中。

     在這個過程中用戶端建立了什麼樣的管理架構，並如何這個會話？

     在 Window Manager Proxy 中建立了 View，Layout，ViewRoot 散著的對應關係表。構造一個ViewRoot 就會開啟一個Session，並利用 IWindowSession 簡曆會話上下文。如：

 

      

 

 

4. 服務端 ---- Window Manager Service

    Window Manager Service 管理的視窗是應用程式的 Top-Level 視窗，這裡稱之為 主視窗，為什麼主視窗要放到 Service 來管理呢？其實 放在一起管理是為了計算 Z-order 序列，根據應用程式的狀態來顯示/隱藏應用程式的視窗。

    在 Service 維護了一個 mWindow 數組，這個 mWindow 就是 Window 的 Z-order序 數組。mWindowMap 用於記錄 <Client:Binder,WindowState對象>。

    在服務端的視窗對象叫做 WindowState 。WindowState 有一個叫做 mClient 成員變數來記錄用戶端 IWindow 執行個體，通過 IWindow 介面執行個體，Service可以訪問用戶端的資訊，可以傳遞訊息到用戶端。所以說呢 IWindow 是 Service 連結 View 的橋樑。

 

http://blog.sina.com.cn/s/blog_4b3c1f950100qe9m.html

轉自：