俗話說，一個好漢三個幫！WMS的強大是由很多重要的成員互相協調工作而實現的。了解WMS的構成將會為我們深入探索WMS打下良好的基礎，進而分析它的啟動過程，這是再合適不過了。 #### 1．WMS的誕生 和其他的系統服務一樣，WMS的啟動位于SystemServer.java中ServerThread類的run()函數內。 **SystemServer.java::ServerThread.run()** ``` Public void run() { ...... WindowManagerService wm = null; ...... try { ...... // **①創建WMS實例** /* 通過WindowManagerService的靜態函數main()創建WindowManagerService的實例。 注意main()函數的兩個參數wmHandler和uiHandler。這兩個Handler分別運行于由 ServerThread所創建的兩個名為“WindowManager”和“UI”的兩個HandlerThread中 */ wm =WindowManagerService.main(context, power, display, inputManager, uiHandler,wmHandler, factoryTest !=SystemServer.FACTORY_TEST_LOW_LEVEL, !firstBoot, onlyCore); // 添加到ServiceManager中去 ServiceManager.addService(Context.WINDOW_SERVICE,wm); ...... catch(RuntimeException e) { ...... } ...... try { //**②初始化顯示信息** wm.displayReady(); } catch(Throwable e) {......} ...... try { // ③通知WMS，系統的初始化工作完成 wm.systemReady(); } catch(Throwable e) {......} ...... } ``` 由此可以看出，WMS的創建分為三個階段： - 創建WMS的實例。 - 初始化顯示信息。 - 處理systemReady通知。 接下來，將通過以上三個階段分析WMS從無到有的過程。 看一下WMS的main()函數的實現： **WindowManagerService.java::WindowManagerSrevice.main()** ``` public static WindowManagerService main(finalContext context, finalPowerManagerService pm, final DisplayManagerService dm, finalInputManagerService im, finalHandler uiHandler, final Handler wmHandler, finalboolean haveInputMethods, final boolean showBootMsgs, finalboolean onlyCore) { finalWindowManagerService[] holder = new WindowManagerService[1]; // 通過由SystemServer為WMS創建的Handler新建一個WindowManagerService對象 // 此Handler運行在一個名為WindowManager的HandlerThread中 wmHandler.runWithScissors(newRunnable() { @Override publicvoid run() { holder[0]= new WindowManagerService(context, pm, dm, im, uiHandler,haveInputMethods, showBootMsgs, onlyCore); } }, 0); returnholder[0]; } ``` * * * * * **注意** Handler類在Android 4.2中新增了一個API：runWithScissors()。這個函數將會在Handler所在的線程中執行傳入的Runnable對象，同時阻塞調用線程的執行，直到Runnable對象的run()函數執行完畢。 * * * * * WindowManagerService.main()函數在ServerThread專為WMS創建的線程“WindowManager”上創建了一個WindowManagerService的新實例。WMS中所有需要的Looper對象，例如Handler、Choreographer等，將會運行在“WindowManager”線程中。 接下來看一下其構造函數，看一下WMS定義了哪些重要的組件。 **WindowManagerService.java::WindowManagerService.WindowManagerService()** ``` private WindowManagerService(Context context,PowerManagerService pm, DisplayManagerService displayManager, InputManagerService inputManager, Handler uiHandler, booleanhaveInputMethods, boolean showBootMsgs, boolean onlyCore) ...... mDisplayManager= (DisplayManager)context.getSystemService(Context.DISPLAY_SERVICE); mDisplayManager.registerDisplayListener(this,null); Display[]displays = mDisplayManager.getDisplays(); /* 初始化DisplayContent列表。DisplayContent是Android4.2為支持多屏幕輸出所引入的一個 概念。一個DisplayContent指代一塊屏幕，屏幕可以是手機自身的屏幕，也可以是基于Wi-FiDisplay 技術的虛擬屏幕[3]*/ for(Display display : displays) { createDisplayContentLocked(display); } ..... /* 保存InputManagerService。輸入事件最終要分發給具有焦點的窗口，而WMS是窗口管理者， 所以WMS是輸入系統中的重要一環。關于輸入系統的內容將在第5章中深入探討*/ mInputManager= inputManager; // 這個看起來其貌不揚的mAnimator，事實上具有非常重要的作用。它管理著所有窗口的動畫 mAnimator= new WindowAnimator(this, context, mPolicy); // 在“UI“線程中將對另一個重要成員mPolicy，也就是WindowManagerPolicy進行初始化 initPolicy(uiHandler); // 將自己加入到Watchdog中 Watchdog.getInstance().addMonitor(this); ...... } ``` 第二步，displayReady()函數的調用主要是初始化顯示尺寸的信息。其內容比較瑣碎，這里就先不介紹了。不過值得注意的一點是，再displayReady()完成后，WMS會要求ActivityManagerService進行第一次Configuration的更新。 第三步，在systemReady()函數中，WMS本身將不會再做任何操作了，直接調用mPolicy的systemReady()函數。 #### 2．WMS的重要成員 總結一下在WMS的啟動過程中所創建的重要成員，參考圖4-3。 :-:  圖 4-3 WMS的重要成員 以下是對圖4-3中重要成員的簡單介紹： - mInputManager，InputManagerService（輸入系統服務）的實例。用于管理每個窗口的輸入事件通道（InputChannel）以及向通道上派發事件。關于輸入系統的詳細內容將在本書第5章詳細探討。 - mChoreographer，Choreographer的實例，在SampleWindow的例子中已經見過了。Choreographer的意思是編舞指導。它擁有從顯示子系統獲取VSYNC同步事件的能力，從而可以在合適的時機通知渲染動作，避免在渲染的過程中因為發生屏幕重繪而導致的畫面撕裂。從這個意義上來講，Choreographer的確是指導Android翩翩起舞的大師。WMS使用Choreographer負責驅動所有的窗口動畫、屏幕旋轉動畫、墻紙動畫的渲染。 - mAnimator，WindowAnimator的實例。它是所有窗口動畫的總管（窗口動畫是一個WindowStateAnimator的對象）。在Choreographer的驅動下，逐個渲染所有的動畫。 - mPolicy，WindowPolicyManager的一個實現。目前它只有PhoneWindowManager一個實現類。mPolicy定義了很多窗口相關的策略，可以說是WMS的首席顧問！每當WMS要做什么事情的時候，都需要向這個顧問請教應當如何做。例如，告訴WMS某一個類型的Window的ZOrder的值是多少，幫助WMS矯正不合理的窗口屬性，會為WMS監聽屏幕旋轉的狀態，還會預處理一些系統按鍵事件（例如HOME、BACK鍵等的默認行為就是在這里實現的），等等。所以，mPolicy可謂是WMS中最重要的一個成員了。 - mDisplayContents，一個DisplayContent類型的列表。Android4.2支持基于Wi-fi Display的多屏幕輸出，而一個DisplayContent描述了一塊可以繪制窗口的屏幕。每個DisplayContent都用一個整型變量作為其ID，其中手機默認屏幕的ID由Display.DEFAULT\_DISPLAY常量指定。DisplayContent的管理是由DisplayManagerService完成的，在本章不會去探討DisplayContent的實現細節，而是關注DisplayContent對窗口管理與布局的影響。 下面的幾個成員的初始化并沒有出現在構造函數中，不過它們的重要性一點也不亞于上面幾個。 - mTokenMap，一個HashMap，保存了所有的顯示令牌（類型為WindowToken），用于窗口管理。在SampleWindow例子中曾經提到過，一個窗口必須隸屬于某一個顯示令牌。在那個例子中所添加的令牌就被放進了這個HashMap中。從這個成員中還衍生出幾個輔助的顯示令牌的子集，例如mAppTokens保存了所有屬于Activity的顯示令牌（WindowToken的子類AppWindowToken），mExitingTokens則保存了正在退出過程中的顯示令牌等。其中mAppTokens列表是有序的，它與AMS中的mHistory列表的順序保持一致，反映了系統中Activity的順序。 - mWindowMap，也是一個HashMap，保存了所有窗口的狀態信息（類型為WindowState），用于窗口管理。在SampleWindow例子中，使用IWindowSession.add()所添加的窗口的狀態將會被保存在mWindowMap中。與mTokenMap一樣，mWindowMap一樣有衍生出的子集。例如mPendingRemove保存了那些退出動畫播放完成并即將被移除的窗口，mLosingFocus則保存了那些失去了輸入焦點的窗口。在DisplayContent中，也有一個windows列表，這個列表存儲了顯示在此DisplayContent中的窗口，并且它是有序的。窗口在這個列表中的位置決定了其最終顯示時的Z序。 - mSessions，一個List，元素類型為Session。Session其實是SampleWindow例子中的IWindowSession的Bn端。也就是說，mSessions這個列表保存了當前所有想向WMS尋求窗口管理服務的客戶端。注意Session是進程唯一的。 - mRotation，只是一個int型變量。它保存了當前手機的旋轉狀態。 WMS定義的成員一定不止這些，但是它們是WMS每一種功能最核心的變量。讀者在這里可以線對它們有一個感性的認識。在本章后續的內容里將會詳細分析它們在WMS的各種工作中所發揮的核心作用。