1. WMS的概念
從名字可以看出，window表明它是與窗口相關的，Manager表明它具有管理者的身份。簡單來講，它是窗口管理員。窗口是一個抽象的概念，從用戶的角度來講，它是一個界面。從SufaceFlinger的角度來講，它是一個Layer,承載著和界面有關的數據和屬性。所以它是一個WindowState，用于管理和界面有關的狀態。
WMS也是系統服務，由SystemServer啟動。直到關機時才會退出。發生異常時必須重啟。
-
1.1 WMS涉及的元素：
-
WindowManagerPolicy-mPolicy:窗口策略類。
Android提供了WindowManagerPolicy接口定義Ui顯示策略，手機的實現類為PhoneWindowManager。也可以自己實現WindowManagerPolicy來自定義策略。
窗口策略：這里的initPolicy()初始化的PhoneWindowManager代表的是一種窗口策略。應用到WMS中則代表了Android顯示系統所遵循的統一的窗口顯示規則。針對不同的產品，UI顯示策略通常是不一樣的。如手機一般都有Status Bar，但是平板沒有。所以要設定不同的策略。
ArraySet<Session>-mSessions:主要用于進程間通信，其他應用程序想要和WMS通信就需要經過Session，每個應用程序進程都會對應一個Session，WMS保存這些Session用來記錄所有向WMS提出窗口管理服務的客戶端。
WindowHashMap<IBinder,WindowState>-mWindowMap:WindowState用于保存窗口信息，用來描述一個窗口。mWindowMap其實就是用來保存WMS中各種窗口的集合
-
ArrayList<AppWindowToken>-mFinishedStarting:AppWindowToken為WindowToken的子類，WindowToken主要有2個作用：
- 窗口令牌，當應用程序想要向WMS申請新創建一個窗口，則需要向WMS出示有效的WindowToken。AppWindowToken主要用來描述應用程序的WindowToken結構，應用程序中每個Activity都對應一個AppWindowToken
- WindowToken會將同一個組件(比如同一個Activity)的窗口(WindowState)集合在一起，方便管理
mFinishedStarting就是用于存儲已經完成啟動的應用程序窗口(比如Activity)的AppWindowToken列表。
ArrayList<WindowState>-mResizingWindows:用來存儲正在調整大小的窗口列表。
WindowAnimator-mAnimator:用于管理窗口的動畫以及特效動畫
H-h:系統的Handler類，用于將任務加入到主線程消息隊列中
InputManagerService-mInputManager:輸入系統的管理者。會對觸摸事件進行處理，他會尋找一個合適的窗口來處理觸摸返回信息，WMS是窗口的管理者，所以需要持有IMS引用
-
顯示圖形的需求
- Application Window：普通應用程序顯示申請所產生的window，和系統窗口相比，它們的窗口層級值比較低。
- System Window：系統頂部的系統狀態欄，壁紙等
- Sub Window：Toast等彈窗
ActivityManagerService：AMS管理者所有的Activity，而Activity的變化通常會帶來界面上的改變。那么界面上產生的變化（淡出等動畫效果）也要涉及WMS
-
-
1.2 WMS包含的功能
- 窗口的添加與刪除：當某個進程由顯示需求時，它可以請求WMS添加一個窗口，并于不再需要顯示時移除該窗口
- 啟動窗口：當增了一個窗口時，在某些條件下需要添加一個啟動窗口
- 窗口動畫：窗口切換時，采用窗口動畫可以加強UI特效。可以定制
- 窗口大小： Android系統支持顯示不同大小的窗口，如StatusBar就只是屏幕最頂層的一條Bar，還有對話框，浮窗等
- 窗口層級：由Z-Order決定，值越大，排序越靠后，會被值小的窗口蓋住
- 事件派發
-
1.3 內部組織方式
當一個新的Activity被啟動時，它首先需要在AMS中注冊，此時AMS會在內部生成一個ActivityRecord來記錄這個Activity；另外因為Activity是四大組件中專門用于UI顯示的，所以WMS也會對它以WindowState的形式進行記錄。
所以Activity在AMS中的表現形式為ActivityRecord，在WMS中的表現形式為WindowState，其中WMS還有一個變量AppWindowToken和AMS中的ActivityRecord相對應，這樣它們就關聯了起來。
2. WMS的啟動
WMS由SystemServer進程啟動，在SystemServer的main()中執行了 startOtherServices()，WMS就在這里啟動，看下代碼：
private void startOtherServices() {
//part1
final Watchdog watchdog = Watchdog.getInstance();
watchdog.init(context, mActivityManagerService);
//part2
inputManager = new InputManagerService(context);
//part4
wm = WindowManagerService.main(context, inputManager,
mFactoryTestMode != FactoryTest.FACTORY_TEST_LOW_LEVEL,
!mFirstBoot, mOnlyCore, new PhoneWindowManager());
//part5
ServiceManager.addService(Context.WINDOW_SERVICE, wm);
ServiceManager.addService(Context.INPUT_SERVICE, inputManager);
- part1部分初始化了WatchDog，WatchDog用來監控系統的一些關鍵服務運行的情況，如WMS，它每分鐘都會對被監控的系統服務進行檢查，如果被監控的服務出現了死鎖，則會殺死WatchDog所在進程，也就是SystemServer進程。前面提到過，WMS發生異常時必須重啟，就是在這里進行監控
- part2部分構造了IMS，IMS負責輸入消息，WMS需要持有它的引用
- part3部分通過WindowManagerService.main()構造了一個WMS對象，并傳入了構造好的IMS，這樣WMS就持有了IMS引用。
- part5中WMS，IMS注冊到了ServiceManager中，這樣如果某個客戶端想使用它們的功能，就可以去ServiceManager查詢，進而可以進行進程間通信
WMS是通過它自己的main()構造的，繼續看這個方法：
public static WindowManagerService main() {
DisplayThread.getHandler().runWithScissors(() ->
sInstance = new WindowManagerService(context, im, haveInputMethods, showBootMsgs,
onlyCore, policy), 0);
return sInstance;
}
在DisplayThread線程中創建了WMS，這個線程是一個單例的前臺線程，它用來處理需要低延遲顯示的相關操作，并只能由WM，DisplayManager和InputManager實時執行快速操作。由于WMS的優先級更高，所以system_server線程需要等待DisplayThread線程執行完創建WMS的操作，才會繼續執行，在這之前它會一直等待。
再看WMS的構造方法：
private WindowManagerService() {
//持有IMS引用
mInputManager = inputManager; // Must be before createDisplayContentLocked.
//獲取DisplayManager
mDisplayManager = (DisplayManager)context.getSystemService(Context.DISPLAY_SERVICE);
//獲取Display數組
mDisplays = mDisplayManager.getDisplays();
//遍歷Display，將Display封裝成DisplayContent，DisplayContent用來描述一塊屏幕
for (Display display : mDisplays) {
createDisplayContentLocked(display);
}
//持有AMS引用
mActivityManager = ActivityManager.getService();
//創建mAnimator，用于管理窗口動畫
mAnimator = new WindowAnimator(this);
//創建窗口策略管理類PhoneWindowManager
initPolicy();
//將WMS添加到WatchDog中
Watchdog.getInstance().addMonitor(this);
}
在WMS的構造中進行了一些初始化，持有了AMS，IMS引用，獲取了所有管理的屏幕對象DisplayContent，創建了策略管理類PWM,最后將自己添加到WathDog中。再看PWM的初始化，也就是initPolicy():
private void initPolicy() {
UiThread.getHandler().runWithScissors(new Runnable() {
@Override
public void run() {
WindowManagerPolicyThread.set(Thread.currentThread(), Looper.myLooper());
mPolicy.init(mContext, WindowManagerService.this, WindowManagerService.this);
}
}, 0);
}
PWM的init()運行在UI線程中，它的優先級高于Display線程，因此DisPlay線程要等待它執行完后才會執行。
總結：
- 首先在System_server線程中執行了SystemServer的starOtherService(),在starOtherService()中會調用WMS的main()，這個main()會創建WMS，創建的過程在disPlay線程中實現，因WMS的優先級更高，因此System_server線程要等WMS創建完成后，處于等待狀態的System_server線程才會被喚醒從而繼續執行下面的代碼
- 在WMS的構造中會調用WMS的initPolicy()，在initPolicy()中又會調用PWM的init(),這個init()在UI線程中運行，它的優先級要高于display線程，因此display線程要等到PWM的init()執行完畢后，才會被喚醒執行后面的代碼
- PWM的init()執行完畢后，disPlay線程就完成了WMS的創建，等待的system_server線程就會被喚起繼續執行main()之后的邏輯
3. Window添加過程
window的添加從WMS的addWindow()開始：
public int addWindow() {
//part1權限檢查
int res = mPolicy.checkAddPermission(attrs, appOp);
synchronized(mWindowMap) {
//part2尋找displayContent
final DisplayContent displayContent = mRoot.getDisplayContentOrCreate(displayId);
//避免重復添加
if (mWindowMap.containsKey(client.asBinder())) {
return WindowManagerGlobal.ADD_DUPLICATE_ADD;
}
//part3判斷是否子窗口
if (type >= FIRST_SUB_WINDOW && type <= LAST_SUB_WINDOW) {
//尋找父窗口
parentWindow = windowForClientLocked(null, attrs.token, false);
}
//part4獲取WindowToken
WindowToken token = displayContent.getWindowToken(
hasParent ? parentWindow.mAttrs.token : attrs.token);
//如果有父窗口就將父窗口的type賦值給rootType，如果沒有則將當前窗口的type賦值給rootType
final int rootType = hasParent ? parentWindow.mAttrs.type : type;
if (token == null) {
//part5如果token為null，則隱式創建token,這說明創建窗口時可以不向WMS提供提供WindowToken。這里的參數false代表token是隱式創建的，不是傳進來的
token = new WindowToken(this, binder, type, false, displayContent,
session.mCanAddInternalSystemWindow);
} else if (rootType >= FIRST_APPLICATION_WINDOW && rootType <= LAST_APPLICATION_WINDOW) {
//part6如果為應用程序窗口，將windowToken轉換為應用程序窗口的AppWindowToken
atoken = token.asAppWindowToken();
}
//part7創建windowState，它存有窗口的所有信息，代表一個窗口
final WindowState win = new WindowState(this, session, client, token, parentWindow, appOp[0], seq, attrs, viewVisibility, session.mUid, session.mCanAddInternalSystemWindow);
//part8判斷請求添加窗口的客戶端是否已經死亡
if (win.mDeathRecipient == null) {
return WindowManagerGlobal.ADD_APP_EXITING;
}
//part9判斷窗口的DisplayContent是否為null
if (win.getDisplayContent() == null) {
return WindowManagerGlobal.ADD_INVALID_DISPLAY;
}
//part10根據窗口的type對窗口的LayoutParams成員變量進行修改
mPolicy.adjustWindowParamsLw(win.mAttrs);
win.setShowToOwnerOnlyLocked(mPolicy.checkShowToOwnerOnly(attrs));
//part11準備將窗口添加到系統中
res = mPolicy.prepareAddWindowLw(win, attrs);
win.attach();
//part12將windowState添加到windowMap中
mWindowMap.put(client.asBinder(), win);
//part13將windowstate添加到該windowstate對應的windowtoken中，這樣windowtoken中就包含了同一個組件的windowstate
win.mToken.addWindow(win);
return res;
}
- part1處進行了權限檢查，如果沒有權限則不能添加系統窗口，需要在在manifest中注冊權限。沒有權限就不會執行后續代碼，但是Tost這種系統窗口是用戶可以創建的，所以這里需要對權限進行控制。
- part2處通過displayId來獲得窗口要添加到哪個DisplayContent上。
- part3處判斷了是否是子窗口，如果是子窗口，那么還要找出父窗口；而且父窗口本身不能是其他窗口的子窗口，否則會添加失敗
- part4處創建windowToken，如果有父窗口則把父窗口的type賦值給rootType,如果沒有則把自身的type賦值給rootType
- part5判斷如果token為null，則隱式創建token,這說明創建窗口時可以不向WMS提供提供WindowToken。這里的參數false代表token是隱式創建的，不是傳進來的
- part6如果token不為null且為應用程序窗口，將windowToken轉換為應用程序窗口的AppWindowToken
- part7創建windowState，它存有窗口的所有信息，代表一個窗口
- part8判斷請求添加窗口的客戶端是否已經死亡
- part9判斷窗口的DisplayContent是否為null
- part10根據窗口的type對窗口的LayoutParams成員變量進行修改
- part11準備將窗口添加到系統中
- part12將windowState添加到windowMap中
- part13將windowstate添加到該windowstate對應的windowtoken中，這樣windowtoken中就包含了同一個組件的windowstate
總結：addWindow()主要做了一下事情
- 對所要添加的窗口進行檢查，如果窗口不滿足一些條件，就不會執行下面的代碼。
- WindowToken的相關處理，有的窗口類型需要提供windowToken，沒有的話就不會執行下面的邏輯，有的則需要WMS隱式創建windowToken
- WindowState的創建和相關處理，將WindowToken和WindowState相關聯
- 創建和配置DisplayContent，完成窗口添加到系統前到準備工作
4. Window的刪除過程
窗口的刪除從WindowManagerGlobal.removeVIew()發起，看代碼：
public void removeView(View view, boolean immediate) {
synchronized (mLock) {
//獲取要刪除的view的索引
int index = findViewLocked(view, true);
//傳入索引
removeViewLocked(index, immediate);
}
這里獲取了要刪除的View的索引，然后調用了removeViewLocked():
private void removeViewLocked(int index, boolean immediate) {
//獲取viewRoot
ViewRootImpl root = mRoots.get(index);
View view = root.getView();
if (view != null) {
//獲取InputMethodManager實例
InputMethodManager imm = InputMethodManager.getInstance();
if (imm != null) {
//結束view的輸入法相關邏輯
imm.windowDismissed(mViews.get(index).getWindowToken());
}
}
boolean deferred = root.die(immediate);
}
這里調用了ViewRootImpl.die():
boolean die(boolean immediate) {
//immediate代表是否需要立即執行，及ViewRootImpl是否在執行performTraversals
if (immediate && !mIsInTraversal) {
doDie();
return false;
}
mHandler.sendEmptyMessage(MSG_DIE);
return true;
}
這里判斷了是否需要立即執行，以及ViewRootImpl是否在執行performTraversals，當ViewRootImpl在執行performTraversals時mIsInTraversal為被置為true,所以doDie()執行的條件是ViewRootImpl不執行performTraversals()時，再看doDie():
void doDie() {
//檢查線程，判斷執行doDie()方法線程是否是創建view的原始線程，如果不是就拋出異常。只有創建view的原始線程才能操作view
checkThread();
synchronized (this) {
//是否有子view
if (mAdded) {
//如果有則銷毀子view
dispatchDetachedFromWindow();
}
if (mAdded && !mFirst) {
//如果有子view并且不是第一次被添加
destroyHardwareRenderer();
}
}
WindowManagerGlobal.getInstance().doRemoveView(this);
}
這里做了線程檢查，只有創建view的原始線程才能操作view。然后判斷是否有子 view有的話則調用dispatchDetachedFromWindow()去銷毀，最后調用了WindowManagerGlobal.doRemoveView():
void doRemoveView(ViewRootImpl root) {
synchronized (mLock) {
final int index = mRoots.indexOf(root);
if (index >= 0) {
//
mRoots.remove(index);
mParams.remove(index);
final View view = mViews.remove(index);
mDyingViews.remove(view);
}
}
}
將要刪除的view從WindowManagerGlobal中維護的列表中移除。
再回頭去看dispatchDetachedFromWindow():
void dispatchDetachedFromWindow() {
mWindowSession.remove(mWindow);
}
這里調用了WindowSession.remove(),那么這里進行了進程間通訊，最終會調用到WMS的removeWindow():
void removeWindow(Session session, IWindow client) {
synchronized(mWindowMap) {
//獲取WindowState
WindowState win = windowForClientLocked(session, client, false);
win.removeIfPossible();
}
}
這里線獲取了WindowState,然后調用了WindowState.removeIfPossible():
void removeIfPossible() {
super.removeIfPossible();
removeIfPossible(false /*keepVisibleDeadWindow*/);
}
繼續看removeIfPossible(false):
private void removeIfPossible(boolean keepVisibleDeadWindow) {
//上面省略了一部分代碼，主要是進行條件判斷，如果滿足任何一條則會return,推遲刪除操作
removeImmediately();
}
在removeIfPossible()中會進行一系列判斷，如果滿足任何一個條件都會推遲操作，如view在進行動畫時等。
再看removeImmediately():
void removeImmediately() {
super.removeImmediately();
//如果當前要刪除的是StatusBar或者NavigationBar，將這個window從對應的控制器中刪除
mPolicy.removeWindowLw(this);
//將對應的session刪除
mSession.windowRemovedLocked();
//調用WMS進行一些清理工作
mService.postWindowRemoveCleanupLocked(this);
}
最后通過removeImmediately()完成了窗口的刪除。
總結：window的刪除可以總結為以下幾點
- 檢查刪除線程的正確性，如果不正確就拋出異常
- 從ViewRootImpl列表，布局列表和View列表中刪除對應的元素
- 判斷是否可以執行刪除操作，如果不能就推遲刪除操作
- 執行刪除操作，清理和釋放與V相關的一切資源
