理解Window和WindowManager

Window是一個(gè)抽象類，它的具體實(shí)現(xiàn)是PhoneWindow。WindowManager是外界訪問Window的入口，Window的具體實(shí)現(xiàn)位于WindowManagerService中，WindowManager和WindowManagerService的交互是一個(gè)IPC過程。Android中所有的視圖都是通過Window來呈現(xiàn)的，不管是Activity、Dialog還是Toast，它們的視圖實(shí)際上都是附加在Window上的，因此Window實(shí)際是View的直接管理者。

Window和WindowManager

為了分析Window的工作機(jī)制，先通過代碼了解如何使用WindowManager添加一個(gè)Window，下面一段代碼將一個(gè)Button添加到屏幕坐標(biāo)為(100, 300)的位置上

mFloatingButton = new Button(this);
mFloatingButton.setText("test button");
mLayoutParams = new WindowManager.LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT, 0, 0, PixelFormat.TRANSPARENT);//0,0 分別是type和flags參數(shù)
mLayoutParams.flags = LayoutParams.FLAG_NOT_TOUCH_MODAL | LayoutParams.FLAG_NOT_FOCUSABLE | LayoutParams.FLAG_SHOW_WHEN_LOCKED;
mLayoutParams.type = LayoutParams.TYPE_SYSTEM_ERROR;
mLayoutParams.gravity = Gravity.LEFT | Gravity.TOP;
mLayoutParams.x = 100;
mLayoutParams.y = 300;
mFloatingButton.setOnTouchListener(this);
mWindowManager.addView(mFloatingButton, mLayoutParams);

Flags參數(shù)表示W(wǎng)indow的屬性，以下列舉常用的選項(xiàng)：

• FLAG_NOT_FOCUSABLE：表示W(wǎng)indow不需要獲取焦點(diǎn)，也不需要接收各種輸入事件，此標(biāo)記會(huì)同時(shí)啟動(dòng)FLAG_NOT_TOUCH_MODEL，最終事件會(huì)傳遞給下層的具有焦點(diǎn)的Window
• FLAG_NOT_TOUCH_MODAL：在此模式下，系統(tǒng)會(huì)將當(dāng)前Window區(qū)域以外的單擊事件傳遞給底層的Window，當(dāng)前Window區(qū)域以內(nèi)的單擊事件則自己處理。這個(gè)標(biāo)記很重要，一般來說都需要開啟此標(biāo)記，否則其他Window將無法收到單擊事件。
• FLAG_SHOW_WHEN_LOCKED：開啟此模式可以讓顯示在鎖屏的界面

Type參數(shù)表示W(wǎng)indow的類型，Window有三種類型，分別是應(yīng)用Window、子Window和系統(tǒng)Window。

• 應(yīng)用類Window對(duì)應(yīng)著一個(gè)Activity。
• 子Window不能單獨(dú)存在，它需要附屬在特定的父Window之中，比如常見的一些Dialog就是一個(gè)子Window。
• 系統(tǒng)Window是需要聲明權(quán)限才能創(chuàng)建的Window，比如Toast和系統(tǒng)狀態(tài)欄這些都是系統(tǒng)Window。

Window是分層的，每個(gè)Window都有對(duì)應(yīng)的z-ordered，層級(jí)最大的會(huì)覆蓋在層級(jí)小的Window上面，這和HTML中的z-index的概念是完全一致的。在三類Window中，應(yīng)用Window的層級(jí)范圍是1_{99，子Window的層級(jí)范圍是1000}1999，系統(tǒng)Window的層級(jí)范圍是2000~2999，這些層級(jí)屬性范圍對(duì)應(yīng)著WindowManager.LayoutParams的type參數(shù)。

如果采用TYPE_SYSTEM_ERROR，只需要為type參數(shù)指定這個(gè)層級(jí)即可：

mLayoutParams.type = LayoutParams.TYPE_SYSTEM_ERROR

同時(shí)聲明權(quán)限：<uses-permissionandroid:name="android.permission.SYSTEM_ALERT_WINDOW" />

WindowManager所提供的功能很簡(jiǎn)單，常用的只有三個(gè)方法，即添加View、更新View和刪除View，這三個(gè)方法定義在ViewManager中，而WindowManager繼承了ViewManager。

WindowManager操作Window的過程更像是在操作Window中的View

Window的內(nèi)部機(jī)制

Window是一個(gè)抽象的概念，并不是實(shí)際存在的，它是以View的形式存在，每一個(gè)Window都對(duì)應(yīng)著一個(gè)View和一個(gè)ViewRootImpl，Window和View通過ViewRootImpl來建立聯(lián)系。在實(shí)際使用中無法直接訪問Window，對(duì)Window的訪問必須通過WindowManager。

Window的添加過程

Window的添加過程需要通過WindowManager的addView()來實(shí)現(xiàn)，WindowManager是一個(gè)接口，它的真正實(shí)現(xiàn)是WindowManagerImpl類。WindowManager的實(shí)現(xiàn)類對(duì)于addView()、updateView()和removeView()方法都是委托給WindowManagerGlobal類。

WindowManagerGlobal的addView()方法分為如下幾步：

1. 檢查參數(shù)是否合法，如果是子Window那么還需要調(diào)整一些布局參數(shù)
2. 創(chuàng)建ViewRootImpl并將View添加到列表中。Window對(duì)應(yīng)的View, ViewRootImpl和待刪除的View對(duì)象都有對(duì)應(yīng)的列表。
3. 通過ViewRootImpl的setView()來更新界面(View的繪制由ViewRootImpl完成),setView()中通過requestLayout()完成異步刷新請(qǐng)求
4. 通過WindowSession來添加Window，添加過程的本質(zhì)是一個(gè)IPC過程，其中用到了Binder對(duì)象IWindowSession（實(shí)現(xiàn)類Session），實(shí)際添加是交給WindowManagerService去處理

Window的刪除過程

和添加過程一樣，都是先通過WindowManagerImpl后，再進(jìn)一步通過WindowManagerGlobal來實(shí)現(xiàn)的↓

調(diào)用removeView(),其中先找到待刪除的View索引，然后調(diào)用removeViewLocked()->ViewRootImpl,有同步刪除和異步刪除，在異步刪除中，就會(huì)發(fā)送一個(gè)信息，放進(jìn)剛剛ViewRootImpl中的待刪除View的列表。

真正刪除View的邏輯在dispatchDetachedFromWindow()方法的內(nèi)部實(shí)現(xiàn)。主要做四件事：

1. 垃圾回收的工作，比如清除數(shù)據(jù)和消息，移除回調(diào)。
2. 通過Session的remove方法刪除Window，mWindowSession.remove(mWindow)，這同樣是一個(gè)IP C過程，最終會(huì)調(diào)用WindowManagerService的removeWindow方法
3. 調(diào)用View的dispatchDetachedFromWindow方法，在內(nèi)部調(diào)用View的onDetachedFromWindow()以及onDetachedFromWindowInternal()。
4. 調(diào)用WindowManagerGlobal的doRemoveView方法刷新數(shù)據(jù)，包括mRoots、mParams以及mDyingViews，需要將當(dāng)前Window所關(guān)聯(lián)的這三類對(duì)象從列表中刪除。

Window的更新過程

調(diào)用WindowManagerGlobal 的updateViewLayout():

首先需要更新View的LayoutParams并替換掉老的LayoutParams，接著再更新ViewRootImpl中的LayoutParams，這一步是通過ViewRootImpl的setLayoutParams()方法來實(shí)現(xiàn)的。在ViewRootImpl中會(huì)通過scheduleTrversals方法來對(duì)View重新布局，包括測(cè)量、布局、重繪三個(gè)過程。除了View本身的重繪以外，ViewRootImpl還會(huì)通過WindowSession來更新Window的視圖，這個(gè)過程最終是由WindowManagerService的relayoutWindow()來具體實(shí)現(xiàn)的，同樣是一個(gè)IPC過程。

Window的創(chuàng)建過程

Activity的Window創(chuàng)建過程

1、Activity的啟動(dòng)過程很復(fù)雜，最終會(huì)由ActivityThread中的performLaunchActivity()來完成整個(gè)啟動(dòng)過程，在這個(gè)方法內(nèi)部會(huì)通過類加載器創(chuàng)建Activity的實(shí)例對(duì)象，并調(diào)用其attach()方法為其關(guān)聯(lián)運(yùn)行過程中所依賴的一系列上下文環(huán)境變量。

在attach()中，系統(tǒng)會(huì)創(chuàng)建所屬的Window對(duì)象并設(shè)置回調(diào)接口。

Window對(duì)象的創(chuàng)建是通過PolicyManager的makeNewWindow() 實(shí)現(xiàn)

2、Activity實(shí)現(xiàn)了Window的Callback接口，當(dāng)Window接收到外界的狀態(tài)變化時(shí)就會(huì)調(diào)用Activity的方法，例如onAttachedToWindow()、onDetachedFromWindow()、dispatchTouchEvent()等。

3、Activity的Window是由PolicyManager來創(chuàng)建的 - > 真正實(shí)現(xiàn)是Policy類，它會(huì)新建一個(gè)PhoneWindow對(duì)象，Activity的setContentView()的實(shí)現(xiàn)是由PhoneWindow來實(shí)現(xiàn)的/

PhoneWindow的setContentView()方法大致遵循如下幾個(gè)步驟：

1. 如果沒有DecorView(FrameLayout,頂級(jí)View,包含內(nèi)容和標(biāo)題欄)，那么就創(chuàng)建它，通過gernerateLayout()加載具體的布局文件。
2. 將View添加到DecorView的mContentParent中,
3. 回調(diào)Activity的onCreateChanged()方法通知Activity視圖已經(jīng)發(fā)生改變

Window更多表示的是一種抽象的功能集合…

Dialog的Window創(chuàng)建過程

Dialog的Window的創(chuàng)建過程和Activity類似，有如下步驟：

1. 創(chuàng)建Window:Diolog中Window的創(chuàng)建同樣是通過PolicyManager的makeNewWindow()方法來完成的，創(chuàng)建后的對(duì)象實(shí)際上就是PhoneWindow。
2. 初始化DecorView并將Dialog的視圖添加到DecorView中，與Activity類似。
3. 調(diào)用Dialog的show(),將DecorView添加到Window中并顯示, 也與Activity類似。
4. 普通的Dialog有一個(gè)特殊之處，就是必須采用Activity的Context，如果采用Application的Context，那么就會(huì)報(bào)錯(cuò) -> 應(yīng)用token只有Activity擁有，所以這里只需要Activity作為Context來顯示對(duì)話框即可。

系統(tǒng)Window比較特殊，不需要token，系統(tǒng)Window的層級(jí)范圍type： 2000~2999，可以指定Dialog的Window類型為系統(tǒng)Window。

dialog.getWindow().setType(LayoutParams.TYPE_SYSTEM_ERROR);
//要聲明權(quán)限

Toast的Window創(chuàng)建過程

• 在Toast的內(nèi)部有兩類IPC過程，第一類是Toast訪問NotificationManagerService，第二類是NotificationManagerService回調(diào)Toast里的TN接口。
• Toast屬于系統(tǒng)Window，它內(nèi)部的視圖由兩種方式指定：一種是系統(tǒng)默認(rèn)的演示，另一種是通過setView方法來指定一個(gè)自定義的View
• Toast具有定時(shí)取消功能，所以系統(tǒng)采用了Handler。
• Toast的顯示show()和隱藏cancel()是IPC過程，都需要NotificationManagerService（NMS）來實(shí)現(xiàn)，在Toast和NMS進(jìn)行IPC過程時(shí)，NMS會(huì)跨進(jìn)程回調(diào)Toast中的TN類中的方法，TN類是一個(gè)Binder類，運(yùn)行在Binder線程池中，所以需要通過Handler將其切換到當(dāng)前發(fā)送Toast請(qǐng)求所在的線程，因?yàn)槭褂昧薍andler，所以Toast無法在沒有Looper的線程中彈出。

對(duì)于非系統(tǒng)應(yīng)用來說，mToastQueue最多能同時(shí)存在50個(gè)ToastRecord（應(yīng)用的mToastQueue隊(duì)列最多只能存在50個(gè)），這樣做是為了防止DOS(Denial of Service，拒絕服務(wù))。因?yàn)槿绻硞€(gè)應(yīng)用彈出太多的Toast會(huì)導(dǎo)致其他應(yīng)用沒有機(jī)會(huì)彈出Toast。

• Toast的顯示是通過ToastRecord的callback來完成，callback -> Tn對(duì)象的遠(yuǎn)程Binder，需要跨進(jìn)程，會(huì)運(yùn)行在Toast的應(yīng)用的Binder線程池中。

• 并且會(huì)發(fā)送一個(gè)延時(shí)消息，時(shí)長(zhǎng)取決于Toast的持續(xù)時(shí)長(zhǎng)，用來調(diào)用cancelToastLocked來隱藏Toast，并且從隊(duì)列中移除，然后繼續(xù)顯示隊(duì)列中的Toast

Toast的顯示和隱藏實(shí)際上通過Toast的TN類中的兩個(gè)Runnable --> handleShow() 和 handleHide() 方法，用于將Toast的視圖從Window添加或者移除。