首先需要搞清楚WindowManager是什么。 準確的說，WindowManager是一個繼承自ViewManager的接口。ViewManager定義了三個函數，分別用于添加/刪除一個控件，以及更新控件的布局。 ViewManager接口的另一個實現者是ViewGroup，它是容器類控件的基類，用于將一組控件容納到自身的區域中，這一組控件被稱為子控件。ViewGroup可以根據子控件的布局參數（LayoutParams）在其自身的區域中對子控件進行布局。 讀者可以將WindowManager與ViewGroup進行一下類比：設想WindowManager是一個ViewGroup，其區域為整個屏幕，而其中的各個窗口就是一個一個的View。WindowManager通過WMS的幫助將這些View按照其布局參數（LayoutParams）將其顯示到屏幕的特定位置。二者的核心工作是一樣的，因此WindowManager與ViewGroup都繼承自ViewManager。 接下來看一下WindowManager接口的實現者。本章最開始的例子通過Context.getSystemService(Context.WINDOW\_SERVICE)的方式獲取了一個WindowManager的實例，其實現如下： **ContextImpl.java-->ContextImpl.getSystemService()** ``` public Object getSystemService(String name) { // 獲取WINDOW_SERVICE所對應的ServiceFetcher ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name); // 調用fetcher.getService()獲取一個實例 returnfetcher == null ? null : fetcher.getService(this); } ``` Context的實現者ContextImpl在其靜態構造函數中初始化了一系列的ServiceFetcher來響應getSystemService()的調用并創建對應的服務實例。看一下WINDOW\_SERVICE所對應的ServiceFetcher的實現： **ContextImpl.java-->ContextImpl.static()** ``` registerService(WINDOW_SERVICE, newServiceFetcher() { public Object getService(ContextImpl ctx) { // ① 獲取Context中所保存的Display對象 Display display = ctx.mDisplay; /* ② 倘若Context中沒有保存任何Display對象，則通過DisplayManager獲取系統 **主屏幕所對應的Display對象** */ if (display == null) { DisplayManager dm = (DisplayManager)ctx.getOuterContext().getSystemService( Context.DISPLAY_SERVICE); display = dm.getDisplay(Display.DEFAULT_DISPLAY); } // ③ 使用Display對象作為構造函數創建一個WindowManagerImpl對象并返回 return new WindowManagerImpl(display); }}); ``` 由此可見，通過Context.getSystemService()的方式獲取的WindowManager其實是WindowManagerImpl類的一個實例。這個實例的構造依賴于一個Display對象。第4章介紹過DisplayContent的概念，它在WMS中表示一塊的屏幕。而這里的Display對象與DisplayContent的意義是一樣的，也用來表示一塊屏幕。 再看一下WindowManagerImpl的構造函數： **WindowManagerImpl.java-->WindowManagerImpl.WindowManagerImpl()** ``` publicWindowManagerImpl(Display display) { this(display, null); } privateWindowManagerImpl(Display display, Window parentWindow) { mDisplay = display; mParentWindow = parentWindow; } ``` 其構造函數實在是出奇的簡單，僅僅初始化了mDisplay與mParentWindow兩個成員變量而已。從這兩個成員變量的名字與類型來推斷，它們將決定通過這個WindowManagerImpl實例所添加的窗口的歸屬。 說明 WindowManagerImpl的構造函數引入了一個Window類型的參數parentWindow。Window類是什么呢？以Activity為例，一個Activity顯示在屏幕上時包含了標題欄、菜單按鈕等控件，但是在setContentView()時并沒有在layout中放置它們。這是因為Window類預先為我們準備好了這一切，它們被稱之為窗口裝飾。除了產生窗口裝飾之外，Window類還保存了窗口相關的一些重要信息。例如窗口ID（IWindow.asBinder()的返回值）以及窗口所屬Activity的ID(即AppToken)。在6.6.1 介將會對這個類做詳細的介紹。 也許在WindowManagerImpl的addView()函數的實現中可以找到更多的信息。 **WindowManagerImpl.java-->WindowManagerImpl.addView()** ``` publicvoid addView(View view, ViewGroup.LayoutParams params) { mGlobal.addView(view, params, mDisplay, mParentWindow); } ``` WindowManagerImpl.addView()將實際的操作委托給一個名為mGlobal的成員來完成，它隨著WindowManagerImpl的創建而被初始化： ``` privatefinal WindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance(); ``` 可見mGlobal的類型是WindowManagerGlobal，而且WindowManagerGlobal是一個單例模式——即一個進程中最多僅有一個WindowManagerGlobal實例。所有WindowManagerImpl都是這個進程唯一的WindowManagerGlobal實例的代理。 此時便對WindowManager的結構體系有了一個清晰的認識，如圖6-2所示。 :-:  圖 6 - 2 WindowManager的結構體系 - ViewManager接口：WindowManager體系中最基本的接口。WindowManager繼承自這個接口說明了WindowManager與ViewGroup本質上的一致性。 - WindowManager接口：WindowManager接口繼承自ViewManager接口的同時，根據窗口的一些特殊性增加了兩個新的接口。getDefaultDisplay()用以得知這個WindowManager的實例會將窗口添加到哪個屏幕上去。而removeViewImmediate()則要求WindowManager必須在這個調用返回之前完成所有的銷毀工作。 - WindowManagerImpl類：WindowManager接口的實現者。它自身沒有什么實際的邏輯，WindowManager所定義的接口都是交由WindowManagerGlobal完成的。但是它保存了兩個重要的只讀成員，它們分別指明了通過這個WindowManagerImpl實例所管理的窗口將被顯示在哪個屏幕上，以及將會作為哪個窗口的子窗口。因此在一個進程中，WindowManagerImpl的實例可能有多個。 - WindowManagerGlobal類：它沒有繼承上述任何一個接口，但它是WindowManager的最終實現者。它維護了當前進程中所有已經添加到系統中的窗口的信息。另外，在一個進程中僅有一個WindowManagerGlobal的實例。 在理清了WindowManager的結構體系后，便可以探討WindowManager是如何完成窗口管理的。其管理方式體現在其對ViewManager的三個接口的實現上。為了簡潔起見，我們將直接分析WindowManagerGlobal中的實現。