前言
你好,!
我是一只修仙的猿,,歡迎閱讀我的文章。
Window,,讀者可能更多的認(rèn)識(shí)是windows系統(tǒng)的窗口,。在windows系統(tǒng)上,我們可以多個(gè)窗口同時(shí)運(yùn)行,,每個(gè)窗口代表著一個(gè)應(yīng)用程序,。但在安卓上貌似并沒有這個(gè)東西,但讀者可以馬上想到,,不是有小窗口模式嗎,,像米UI最新的系統(tǒng),不就是可以隨意創(chuàng)建一個(gè)小窗口,,然后兩個(gè)應(yīng)用同時(shí)操作,?是的,那是屬于android中,,window的一種表現(xiàn)方式,。但是手機(jī)屏幕終究不能和電腦相比,因?yàn)槠聊惶×?,小到只能操作一款?yīng)用,,多個(gè)窗口就顯得非常不習(xí)慣,所以Android上關(guān)于窗口方面的知識(shí)讀者可能接觸不多。那window的意思就只是小米系統(tǒng)中那種小窗口嗎,?
當(dāng)然不是,。Android框架層意義上的window和我們認(rèn)識(shí)的window其實(shí)是有點(diǎn)不一樣的。我們?nèi)粘W钪庇^的,,每個(gè)應(yīng)用界面,,都有一個(gè)應(yīng)用級(jí)的window。再例如popupWindow,、Toast,、dialog、menu都是需要通過創(chuàng)建window來實(shí)現(xiàn),。所以其實(shí)window我們一直都見到,,只是不知道那就是window。了解window的機(jī)制原理,,可以更好地了解window,,進(jìn)而更好地了解android是怎么管理屏幕上的view。這樣,,當(dāng)我們需要使用dialog或者popupWindow的時(shí)候,,可以懂得他背后究竟做了什么,才能夠更好的運(yùn)用dialog,、popupWindow等,。
當(dāng)然,到此如果你有很多的疑問,,甚至質(zhì)疑我的理論,那就希望你可以閱讀完這一篇文章,。我會(huì)從window是什么,,有什么用,內(nèi)部機(jī)制是什么,,各種組件是如何創(chuàng)建window等等方面來闡述Android中的window,。文章內(nèi)容非常多,讀者可自選章節(jié)閱讀,。
什么是window機(jī)制
先假設(shè)如果沒有window,,會(huì)發(fā)生什么:
我們看到的界面ui是view,如我們的應(yīng)用布局,,更簡單是一個(gè)button,。假如屏幕上現(xiàn)在有一個(gè)Button,如圖1,,現(xiàn)在往屏幕中間添加一個(gè)TextView,,那么最終的結(jié)果是圖2,還是圖3:
在上圖的圖2中,如果我要實(shí)現(xiàn)點(diǎn)擊textView執(zhí)行他的監(jiān)聽事件邏輯,,點(diǎn)擊不是textView的區(qū)域讓textView消失,,需要怎么實(shí)現(xiàn)呢?讀者可能會(huì)說,,我們可以在Activity中添加這部分的邏輯,,那如果我們需要讓一個(gè)懸浮窗在所有界面顯示呢,如上文我講到的小米懸浮窗,,兩個(gè)不用應(yīng)用的view,,怎么確定他們的顯示次序?又例如我們需要彈出一個(gè)dialog來提示用戶,,怎么樣可以讓dialog永遠(yuǎn)處于最頂層呢,,包括顯示dialog期間應(yīng)用彈出的如popupWindow必須顯示在dialog的低下,但toast又必須顯示在dialog上面,。
很明顯,,我們的屏幕可以允許多個(gè)應(yīng)用同時(shí)顯示非常多的view,他們的顯示次序或者說顯示高度是不一樣的,,如果沒有一個(gè)統(tǒng)一的管理者,,那么每一家應(yīng)用都想要顯示在最頂層,那么屏幕上的view會(huì)非常亂,。
同時(shí),,當(dāng)我們點(diǎn)擊屏幕時(shí),這個(gè)觸摸事件應(yīng)該傳給哪個(gè)view,?很明顯我們都知道應(yīng)該傳給最上層的view,,但是接受事件的是屏幕,是另一個(gè)系統(tǒng)服務(wù),,他怎么知道觸摸位置的最上層是哪個(gè)view呢,?即時(shí)知道,他又怎么把這個(gè)事件準(zhǔn)確地傳給他呢,?
為了解決等等這些問題,,急需有一個(gè)管理者來統(tǒng)一管理屏幕上的顯示的view,才能讓程序有條不紊地走下去,。而這,,就是Android中的window機(jī)制。
window機(jī)制就是為了管理屏幕上的view的顯示以及觸摸事件的傳遞問題,。
什么是window?
那什么是window,,在Android的window機(jī)制中,每個(gè)view樹都可以看成一個(gè)window,。為什么不是每個(gè)view呢,?因?yàn)関iew樹中每個(gè)view的顯示次序是固定的,例如我們的Activity布局,每一個(gè)控件的顯示都是已經(jīng)安排好的,,對(duì)于window機(jī)制來說,,屬于“不可再分割的view”。
什么是view樹,?例如你在布局中給Activity設(shè)置了一個(gè)布局xml,,那么最頂層的布局如LinearLayout就是view樹的根,他包含的所有view就都是該view樹的節(jié)點(diǎn),,所以這個(gè)view樹就對(duì)應(yīng)一個(gè)window,。
舉幾個(gè)具體的例子:
- 我們?cè)谔砑觗ialog的時(shí)候,需要給他設(shè)置view,,那么這個(gè)view他是不屬于antivity的布局內(nèi)的,,是通過WindowManager添加到屏幕上的,不屬于activity的view樹內(nèi),,所以這個(gè)dialog是一個(gè)獨(dú)立的view樹,,所以他是一個(gè)window。
- popupWindow他也對(duì)應(yīng)一個(gè)window,,因?yàn)樗彩峭ㄟ^windowManager添加上去的,,不屬于Activity的view樹。
- 當(dāng)我們使用使用windowManager在屏幕上添加的任何view都不屬于Activity的布局view樹,,即使是只添加一個(gè)button,。
view樹(后面使用view代稱,后面我說的view都是指view樹)是window機(jī)制的操作單位,,每一個(gè)view對(duì)應(yīng)一個(gè)window,,view是window的存在形式,window是view的載體,,我們平時(shí)看到的應(yīng)用界面,、dialog、popupWindow以及上面描述的懸浮窗,,都是window的表現(xiàn)形式,。注意,,我們看到的不是window,,而是view。window是view的管理者,,同時(shí)也是view的載體,。他是一個(gè)抽象的概念,本身并不存在,,view是window的表現(xiàn)形式,。這里的不存在,指的是我們?cè)谄聊簧鲜强床坏絯indow的,他不像windows系統(tǒng),,如下圖:
有一個(gè)很明顯的標(biāo)志:看,,我就是window。但在Android中我們是無法感知的,,我們只能看到view無法看到window,,window是控制view需要怎么顯示的管理者。每個(gè)成功的男人背后都有一個(gè)女人,,每個(gè)view背后都有一個(gè)window,。
window本身并不存在,他只是一個(gè)概念,。舉個(gè)栗子:如班集體,,就是一個(gè)概念,他的存在形式是這整個(gè)班的學(xué)生,,當(dāng)學(xué)生不存在那么這個(gè)班集體也就不存在,。但是他的好處是得到了一個(gè)新的概念,我們可以以班為單位來安排活動(dòng),。因他不存在,,所以也很難從源碼中找到他的痕跡,window機(jī)制的操作單位都是view,,如果要說他在源碼中的存在形式,,筆者目前的認(rèn)知就是在WindowManagerService中每一個(gè)view對(duì)應(yīng)一個(gè)windowStatus。WindowManagerService是什么如果沒了解過可以先忽略后面會(huì)講到,。讀者可以慢慢思考一下這個(gè)抽象的概念,,后面會(huì)慢慢深入講源碼幫助理解。
- view是window的存在形式,,window是view的載體
- window是view的管理者,,同時(shí)也是view的載體。他是一個(gè)抽象的概念,,本身并不存在,,view是window的表現(xiàn)形式
思考:Android中不是有一個(gè)抽象類叫做window還有一個(gè)PhoneWindow實(shí)現(xiàn)類嗎,他們不就是window的存在形式,,為什么說window是抽象不存在的,?讀者可自行思考,后面會(huì)講到,。
Window的相關(guān)屬性
在了解window的操作流程之前,,先補(bǔ)充一下window的相關(guān)屬性。
window的type屬性
前面我們講到window機(jī)制解決的一個(gè)問題就是view的顯示次序問題,,這個(gè)屬性就決定了window的顯示次序,。window是有分類的,,不同類別的顯示高度范圍不同,例如我把1-1000m高度稱為低空,,1001-2000m高度稱為中空,,2000以上稱為高空。window也是一樣按照高度范圍進(jìn)行分類,,他也有一個(gè)變量Z-Order,,決定了window的高度。window一共可分為三類:
- 應(yīng)用程序窗口:應(yīng)用程序窗口一般位于最底層,,Z-Order在1-99
- 子窗口:子窗口一般是顯示在應(yīng)用窗口之上,,Z-Order在1000-1999
- 系統(tǒng)級(jí)窗口:系統(tǒng)級(jí)窗口一般位于最頂層,不會(huì)被其他的window遮住,,如Toast,,Z-Order在2000-2999。如果要彈出自定義系統(tǒng)級(jí)窗口需要?jiǎng)討B(tài)申請(qǐng)權(quán)限,。
Z-Order越大,,window越靠近用戶,也就顯示越高,,高度高的window會(huì)覆蓋高度低的window,。
window的type屬性就是Z-Order的值,我們可以給window的type屬性賦值來決定window的高度,。系統(tǒng)為我們?nèi)恮indow都預(yù)設(shè)了靜態(tài)常量,,如下(以下常用參數(shù)介紹轉(zhuǎn)自參考文獻(xiàn)第一篇文章):
-
應(yīng)用級(jí)window
// 應(yīng)用程序 Window 的開始值
public static final int FIRST_APPLICATION_WINDOW = 1;
// 應(yīng)用程序 Window 的基礎(chǔ)值
public static final int TYPE_BASE_APPLICATION = 1;
// 普通的應(yīng)用程序
public static final int TYPE_APPLICATION = 2;
// 特殊的應(yīng)用程序窗口,當(dāng)程序可以顯示 Window 之前使用這個(gè) Window 來顯示一些東西
public static final int TYPE_APPLICATION_STARTING = 3;
// TYPE_APPLICATION 的變體,,在應(yīng)用程序顯示之前,,WindowManager 會(huì)等待這個(gè) Window 繪制完畢
public static final int TYPE_DRAWN_APPLICATION = 4;
// 應(yīng)用程序 Window 的結(jié)束值
public static final int LAST_APPLICATION_WINDOW = 99;
-
子window
// 子 Window 類型的開始值
public static final int FIRST_SUB_WINDOW = 1000;
// 應(yīng)用程序 Window 頂部的面板。這些 Window 出現(xiàn)在其附加 Window 的頂部,。
public static final int TYPE_APPLICATION_PANEL = FIRST_SUB_WINDOW;
// 用于顯示媒體(如視頻)的 Window,。這些 Window 出現(xiàn)在其附加 Window 的后面。
public static final int TYPE_APPLICATION_MEDIA = FIRST_SUB_WINDOW + 1;
// 應(yīng)用程序 Window 頂部的子面板,。這些 Window 出現(xiàn)在其附加 Window 和任何Window的頂部
public static final int TYPE_APPLICATION_SUB_PANEL = FIRST_SUB_WINDOW + 2;
// 當(dāng)前Window的布局和頂級(jí)Window布局相同時(shí),,不能作為子代的容器
public static final int TYPE_APPLICATION_ATTACHED_DIALOG = FIRST_SUB_WINDOW + 3;
// 用顯示媒體 Window 覆蓋頂部的 Window, 這是系統(tǒng)隱藏的 API
public static final int TYPE_APPLICATION_MEDIA_OVERLAY = FIRST_SUB_WINDOW + 4;
// 子面板在應(yīng)用程序Window的頂部,,這些Window顯示在其附加Window的頂部,, 這是系統(tǒng)隱藏的 API
public static final int TYPE_APPLICATION_ABOVE_SUB_PANEL = FIRST_SUB_WINDOW + 5;
// 子 Window 類型的結(jié)束值
public static final int LAST_SUB_WINDOW = 1999;
-
系統(tǒng)級(jí)window
// 系統(tǒng)Window類型的開始值
public static final int FIRST_SYSTEM_WINDOW = 2000;
// 系統(tǒng)狀態(tài)欄,只能有一個(gè)狀態(tài)欄,,它被放置在屏幕的頂部,,所有其他窗口都向下移動(dòng)
public static final int TYPE_STATUS_BAR = FIRST_SYSTEM_WINDOW;
// 系統(tǒng)搜索窗口,,只能有一個(gè)搜索欄,,它被放置在屏幕的頂部
public static final int TYPE_SEARCH_BAR = FIRST_SYSTEM_WINDOW+1;
// 已經(jīng)從系統(tǒng)中被移除,,可以使用 TYPE_KEYGUARD_DIALOG 代替
public static final int TYPE_KEYGUARD = FIRST_SYSTEM_WINDOW+4;
// 系統(tǒng)對(duì)話框窗口
public static final int TYPE_SYSTEM_DIALOG = FIRST_SYSTEM_WINDOW+8;
// 鎖屏?xí)r顯示的對(duì)話框
public static final int TYPE_KEYGUARD_DIALOG = FIRST_SYSTEM_WINDOW+9;
// 輸入法窗口,位于普通 UI 之上,,應(yīng)用程序可重新布局以免被此窗口覆蓋
public static final int TYPE_INPUT_METHOD = FIRST_SYSTEM_WINDOW+11;
// 輸入法對(duì)話框,,顯示于當(dāng)前輸入法窗口之上
public static final int TYPE_INPUT_METHOD_DIALOG= FIRST_SYSTEM_WINDOW+12;
// 墻紙
public static final int TYPE_WALLPAPER = FIRST_SYSTEM_WINDOW+13;
// 狀態(tài)欄的滑動(dòng)面板
public static final int TYPE_STATUS_BAR_PANEL = FIRST_SYSTEM_WINDOW+14;
// 應(yīng)用程序疊加窗口顯示在所有窗口之上
public static final int TYPE_APPLICATION_OVERLAY = FIRST_SYSTEM_WINDOW + 38;
// 系統(tǒng)Window類型的結(jié)束值
public static final int LAST_SYSTEM_WINDOW = 2999;
Window的flags參數(shù)
flag標(biāo)志控制window的東西比較多,很多資料的描述是“控制window的顯示”,,但我覺得不夠準(zhǔn)確,。flag控制的范圍包括了:各種情景下的顯示邏輯(鎖屏,游戲等)還有觸控事件的處理邏輯,??刂骑@示確實(shí)是他的很大部分功能,但是并不是全部,。下面看一下一些常用的flag,,就知道flag的功能了(以下常用參數(shù)介紹轉(zhuǎn)自參考文獻(xiàn)第一篇文章):
// 當(dāng) Window 可見時(shí)允許鎖屏
public static final int FLAG_ALLOW_LOCK_WHILE_SCREEN_ON = 0x00000001;
// Window 后面的內(nèi)容都變暗
public static final int FLAG_DIM_BEHIND = 0x00000002;
// Window 不能獲得輸入焦點(diǎn),即不接受任何按鍵或按鈕事件,,例如該 Window 上 有 EditView,,點(diǎn)擊 EditView 是 不會(huì)彈出軟鍵盤的
// Window 范圍外的事件依舊為原窗口處理;例如點(diǎn)擊該窗口外的view,,依然會(huì)有響應(yīng),。另外只要設(shè)置了此Flag,都將會(huì)啟用FLAG_NOT_TOUCH_MODAL
public static final int FLAG_NOT_FOCUSABLE = 0x00000008;
// 設(shè)置了該 Flag,將 Window 之外的按鍵事件發(fā)送給后面的 Window 處理, 而自己只會(huì)處理 Window 區(qū)域內(nèi)的觸摸事件
// Window 之外的 view 也是可以響應(yīng) touch 事件,。
public static final int FLAG_NOT_TOUCH_MODAL = 0x00000020;
// 設(shè)置了該Flag,,表示該 Window 將不會(huì)接受任何 touch 事件,例如點(diǎn)擊該 Window 不會(huì)有響應(yīng),,只會(huì)傳給下面有聚焦的窗口,。
public static final int FLAG_NOT_TOUCHABLE = 0x00000010;
// 只要 Window 可見時(shí)屏幕就會(huì)一直亮著
public static final int FLAG_KEEP_SCREEN_ON = 0x00000080;
// 允許 Window 占滿整個(gè)屏幕
public static final int FLAG_LAYOUT_IN_SCREEN = 0x00000100;
// 允許 Window 超過屏幕之外
public static final int FLAG_LAYOUT_NO_LIMITS = 0x00000200;
// 全屏顯示,隱藏所有的 Window 裝飾,,比如在游戲,、播放器中的全屏顯示
public static final int FLAG_FULLSCREEN = 0x00000400;
// 表示比FLAG_FULLSCREEN低一級(jí),會(huì)顯示狀態(tài)欄
public static final int FLAG_FORCE_NOT_FULLSCREEN = 0x00000800;
// 當(dāng)用戶的臉貼近屏幕時(shí)(比如打電話),,不會(huì)去響應(yīng)此事件
public static final int FLAG_IGNORE_CHEEK_PRESSES = 0x00008000;
// 則當(dāng)按鍵動(dòng)作發(fā)生在 Window 之外時(shí),,將接收到一個(gè)MotionEvent.ACTION_OUTSIDE事件。
public static final int FLAG_WATCH_OUTSIDE_TOUCH = 0x00040000;
@Deprecated
// 窗口可以在鎖屏的 Window 之上顯示, 使用 Activity#setShowWhenLocked(boolean) 方法代替
public static final int FLAG_SHOW_WHEN_LOCKED = 0x00080000;
// 表示負(fù)責(zé)繪制系統(tǒng)欄背景,。如果設(shè)置,,系統(tǒng)欄將以透明背景繪制,
// 此 Window 中的相應(yīng)區(qū)域?qū)⑻畛?Window#getStatusBarColor()和 Window#getNavigationBarColor()中指定的顏色,。
public static final int FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS = 0x80000000;
// 表示要求系統(tǒng)壁紙顯示在該 Window 后面,,Window 表面必須是半透明的,才能真正看到它背后的壁紙
public static final int FLAG_SHOW_WALLPAPER = 0x00100000;
這一部分就是當(dāng)軟件盤彈起來的時(shí)候,,window的處理邏輯,,這在日常中也經(jīng)常遇到,,如:我們?cè)谖⑿帕奶斓臅r(shí)候,點(diǎn)擊輸入框,,當(dāng)軟鍵盤彈起來的時(shí)候輸入框也會(huì)被頂上去,。如果你不想被頂上去,也可以設(shè)置為被軟鍵盤覆蓋,。下面介紹一下常見的屬性(以下常見屬性介紹選自參考文獻(xiàn)第一篇文章):
// 沒有指定狀態(tài),,系統(tǒng)會(huì)選擇一個(gè)合適的狀態(tài)或者依賴于主題的配置
public static final int SOFT_INPUT_STATE_UNCHANGED = 1;
// 當(dāng)用戶進(jìn)入該窗口時(shí),隱藏軟鍵盤
public static final int SOFT_INPUT_STATE_HIDDEN = 2;
// 當(dāng)窗口獲取焦點(diǎn)時(shí),,隱藏軟鍵盤
public static final int SOFT_INPUT_STATE_ALWAYS_HIDDEN = 3;
// 當(dāng)用戶進(jìn)入窗口時(shí),,顯示軟鍵盤
public static final int SOFT_INPUT_STATE_VISIBLE = 4;
// 當(dāng)窗口獲取焦點(diǎn)時(shí),顯示軟鍵盤
public static final int SOFT_INPUT_STATE_ALWAYS_VISIBLE = 5;
// window會(huì)調(diào)整大小以適應(yīng)軟鍵盤窗口
public static final int SOFT_INPUT_MASK_ADJUST = 0xf0;
// 沒有指定狀態(tài),系統(tǒng)會(huì)選擇一個(gè)合適的狀態(tài)或依賴于主題的設(shè)置
public static final int SOFT_INPUT_ADJUST_UNSPECIFIED = 0x00;
// 當(dāng)軟鍵盤彈出時(shí),,窗口會(huì)調(diào)整大小,例如點(diǎn)擊一個(gè)EditView,,整個(gè)layout都將平移可見且處于軟件盤的上方
// 同樣的該模式不能與SOFT_INPUT_ADJUST_PAN結(jié)合使用;
// 如果窗口的布局參數(shù)標(biāo)志包含F(xiàn)LAG_FULLSCREEN,,則將忽略這個(gè)值,,窗口不會(huì)調(diào)整大小,但會(huì)保持全屏,。
public static final int SOFT_INPUT_ADJUST_RESIZE = 0x10;
// 當(dāng)軟鍵盤彈出時(shí),,窗口不需要調(diào)整大小, 要確保輸入焦點(diǎn)是可見的,
// 例如有兩個(gè)EditView的輸入框,一個(gè)為Ev1,,一個(gè)為Ev2,,當(dāng)你點(diǎn)擊Ev1想要輸入數(shù)據(jù)時(shí),當(dāng)前的Ev1的輸入框會(huì)移到軟鍵盤上方
// 該模式不能與SOFT_INPUT_ADJUST_RESIZE結(jié)合使用
public static final int SOFT_INPUT_ADJUST_PAN = 0x20;
// 將不會(huì)調(diào)整大小,,直接覆蓋在window上
public static final int SOFT_INPUT_ADJUST_NOTHING = 0x30;
window的其他屬性
上面的三個(gè)屬性是window比較重要也是比較復(fù)雜 的三個(gè),,除此之外還有幾個(gè)日常經(jīng)常使用的屬性:
- x與y屬性:指定window的位置
- alpha:window的透明度
- gravity:window在屏幕中的位置,使用的是Gravity類的常量
- format:window的像素點(diǎn)格式,,值定義在PixelFormat中
如何給window屬性賦值
window屬性的常量值大部分存儲(chǔ)在WindowManager.LayoutParams類中,,我們可以通過這個(gè)類來獲得這些常量。當(dāng)然還有Gravity類和PixelFormat類等,。
一般情況下我們會(huì)通過以下方式來往屏幕中添加一個(gè)window:
// 在Activity中調(diào)用
WindowManager.LayoutParams windowParams = new WindowManager.LayoutParams();
windParams.flags = WindowManager.LayoutParams.FLAG_FULLSCREEN;
TextView view = new TextView(this);
getWindowManager.addview(view,windowParams);
我們可以直接給WindowManager.LayoutParams對(duì)象設(shè)置屬性,。
第二種賦值方法是直接給window賦值,如
getWindow().flags = WindowManager.LayoutParams.FLAG_FULLSCREEN;
除此之外,,window的solfInputMode屬性比較特殊,,他可以直接在AndroidManifest中指定,如下:
<activity android:windowSoftInputMode="adjustNothing" />
最后總結(jié)一下:
- window的重要屬性有type,、flags,、solfInputMode、gravity等
- 我們可以通過不同的方式給window屬性賦值
- 沒必要去全部記下來,,等遇到需求再去尋找對(duì)應(yīng)的常量即可
Window的添加過程
通過理解源碼之后,,可以對(duì)之前的理論理解更加的透徹,。window的添加過程,指的是我們通過WindowManagerImpl的addView方法來添加window的過程,。
想要添加一個(gè)window,我們知道首先得有view和WindowManager.LayoutParams對(duì)象,,才能去創(chuàng)建一個(gè)window,,這是我們常見的代碼:
Button button = new Button(this);
WindowManager.LayoutParams windowParams = new WindowManager.LayoutParams();
// 這里對(duì)windowParam進(jìn)行初始化
windowParam.addFlags...
// 獲得應(yīng)用PhoneWindow的WindowManager對(duì)象進(jìn)行添加window
getWindowManager.addView(button,windowParams);
然后接下來我們進(jìn)入addView方法中看看。我們知道這個(gè)windowManager的實(shí)現(xiàn)類是WindowManagerImpl,,上面講過,,進(jìn)入他的addView方法看一看:
@Override
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
applyDefaultToken(params);
mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
}
可以發(fā)現(xiàn)他把邏輯直接交給mGlobal去處理了。這個(gè)mGlobal是WindowManagerGlobal,,是一個(gè)全局單例,,是WindowManager接口的具體邏輯實(shí)現(xiàn)。這里運(yùn)用的是橋接模式,。那我們進(jìn)WindowManagerGlobal的方法看一下:
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
// 首先判斷參數(shù)是否合法
if (view == null) {
throw new IllegalArgumentException("view must not be null");
}
if (display == null) {
throw new IllegalArgumentException("display must not be null");
}
if (!(params instanceof WindowManager.LayoutParams)) {
throw new IllegalArgumentException("Params must be WindowManager.LayoutParams");
}
final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams) params;
// 如果不是子窗口,,會(huì)對(duì)其做參數(shù)的調(diào)整
if (parentWindow != null) {
parentWindow.adjustLayoutParamsForSubWindow(wparams);
} else {
final Context context = view.getContext();
if (context != null
&& (context.getApplicationInfo().flags
& ApplicationInfo.FLAG_HARDWARE_ACCELERATED) != 0) {
wparams.flags |= WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED;
}
}
synchronized (mLock) {
...
// 這里新建了一個(gè)viewRootImpl,并設(shè)置參數(shù)
root = new ViewRootImpl(view.getContext(), display);
view.setLayoutParams(wparams);
// 添加到windowManagerGlobal的三個(gè)重要list中,,后面會(huì)講到
mViews.add(view);
mRoots.add(root);
mParams.add(wparams);
// 最后通過viewRootImpl來添加window
try {
root.setView(view, wparams, panelParentView);
}
...
}
}
代碼有點(diǎn)長,,一步步看:
- 首先對(duì)參數(shù)的合法性進(jìn)行檢查
- 然后判斷該窗口是不是子窗口,如果是的話需要對(duì)窗口進(jìn)行調(diào)整,,這個(gè)好理解,,子窗口要跟隨父窗口的特性。
- 接著新建viewRootImpl對(duì)象,,并把view,、viewRootImpl、params三個(gè)對(duì)象添加到三個(gè)list中進(jìn)行保存
- 最后通過viewRootImpl來進(jìn)行添加
補(bǔ)充一點(diǎn)關(guān)于WindowManagerGlobal中的三個(gè)list,,他們分別是:
private final ArrayList<View> mViews = new ArrayList<View>();
private final ArrayList<ViewRootImpl> mRoots = new ArrayList<ViewRootImpl>();
private final ArrayList<WindowManager.LayoutParams> mParams =
new ArrayList<WindowManager.LayoutParams>();
每一個(gè)window所對(duì)應(yīng)的這三個(gè)對(duì)象都會(huì)保存在這里,,之后對(duì)window的一些操作就可以直接來這里取對(duì)象了。當(dāng)window被刪除的時(shí)候,,這些對(duì)象也會(huì)被從list中移除,。
可以看到添加的window的邏輯就交給ViewRootImpl了。viewRootImpl是window和view之間的橋梁,,viewRootImpl可以處理兩邊的對(duì)象,,然后聯(lián)結(jié)起來。下面看一下viewRootImpl怎么處理:
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
synchronized (this) {
...
try {
mOrigWindowType = mWindowAttributes.type;
mAttachInfo.mRecomputeGlobalAttributes = true;
collectViewAttributes();
// 這里調(diào)用了windowSession的方法,,調(diào)用wms的方法,,把添加window的邏輯交給wms
res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
getHostVisibility(), mDisplay.getDisplayId(), mTmpFrame,
mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
mAttachInfo.mOutsets, mAttachInfo.mDisplayCutout, mInputChannel,
mTempInsets);
setFrame(mTmpFrame);
}
...
}
}
viewRootImpl的邏輯很多,重要的就是調(diào)用了mWindowSession的方法調(diào)用了WMS的方法,。這個(gè)mWindowSession很重要重點(diǎn)講一下,。
mWindowSession是一個(gè)IWindowSession對(duì)象,,看到這個(gè)命名很快地可以像到這里用了AIDL跨進(jìn)程通信。IWindowSession是一個(gè)IBinder接口,,他的具體實(shí)現(xiàn)類在WindowManagerService,,本地的mWindowSession只是一個(gè)Binder對(duì)象,通過這個(gè)mWindowSession就可以直接調(diào)用WMS的方法進(jìn)行跨進(jìn)程通信,。
那這個(gè)mWindowSession是從哪里來的呢,?我們到viewRootImpl的構(gòu)造器方法中看一下:
public ViewRootImpl(Context context, Display display) {
...
mWindowSession = WindowManagerGlobal.getWindowSession();
...
}
可以看到這個(gè)session對(duì)象是來自WindowManagerGlobal。再深入看一下:
public static IWindowSession getWindowSession() {
synchronized (WindowManagerGlobal.class) {
if (sWindowSession == null) {
try {
...
sWindowSession = windowManager.openSession(
new IWindowSessionCallback.Stub() {
...
});
}
...
}
return sWindowSession;
}
}
這熟悉的代碼格式,,可以看出來這個(gè)session是一個(gè)單例,,也就是整個(gè)應(yīng)用的所有viewRootImpl的windowSession都是同一個(gè),也就是一個(gè)應(yīng)用只有一個(gè)windowSession,。對(duì)于wms而言,,他是服務(wù)于多個(gè)應(yīng)用的,如果說每個(gè)viewRootImpl整一個(gè)session,,那他的任務(wù)就太重了,。WMS的對(duì)象單位是應(yīng)用,他在內(nèi)部給每個(gè)應(yīng)用session分配了一些數(shù)據(jù)結(jié)構(gòu)如list,,用于保存每個(gè)應(yīng)用的window以及對(duì)應(yīng)的viewRootImpl,。當(dāng)需要操作view的時(shí)候,通過session直接找到viewRootImpl就可以操作了,。
后面的邏輯就交給WMS去處理了,,WMS就會(huì)創(chuàng)建window,然后結(jié)合參數(shù)計(jì)算window的高度等等,,最后使用viewRootImpl進(jìn)行繪制,。這后面的代碼邏輯就不講了,這是深入到WMS的內(nèi)容,,再講進(jìn)去就太復(fù)雜了(筆者也還沒讀懂WMS),。讀源碼的目的是了解整個(gè)系統(tǒng)的本質(zhì)與工作流程,對(duì)系統(tǒng)整體的感知,,而不用太深入代碼細(xì)節(jié),,Android系統(tǒng)那么多的代碼,如果深入進(jìn)去會(huì)出不來的,,所以點(diǎn)到為止就好了,。
我們知道windowManager接口是繼承viewManager接口的,viewManager還有另外兩個(gè)接口:removeView,、updateView,。這里就不講了,有興趣的讀者可以自己去閱讀源碼。講添加流程主要是為了理解window系統(tǒng)的運(yùn)作,,對(duì)內(nèi)部的流程感知,,以便于更好的理解window。
最后做個(gè)總結(jié):
window的添加過程是通過PhoneWindow對(duì)應(yīng)的WindowManagerImpl來添加window,,內(nèi)部會(huì)調(diào)用WindowManagerGlobal來實(shí)現(xiàn),。WindowManagerGlobal會(huì)使用viewRootImpl來進(jìn)行跨進(jìn)程通信讓W(xué)MS執(zhí)行創(chuàng)建window的業(yè)務(wù)。
每個(gè)應(yīng)用都有一個(gè)windowSession,,用于負(fù)責(zé)和WMS的通信,,如ApplicationThread與AMS的通信。
window機(jī)制的關(guān)鍵類
前面的源碼流程中涉及到很多的類,,這里把相關(guān)的類統(tǒng)一分析一下,。先看一張圖:
這基本上是我們這篇文章涉及到的所有關(guān)鍵類,。且聽我慢慢講,。(圖中綠色的window并不是一個(gè)類,而是真正意義上的window)
window相關(guān)
window的實(shí)現(xiàn)類只有一個(gè):PhoneWindow,,他繼承自Window抽象類,。后面我會(huì)重點(diǎn)分析他。
WindowManager相關(guān)
顧名思義,,windowManager就是window管理類,。這一部分的關(guān)鍵類有windowManager,viewManager,,windowManagerImpl,,windowManagerGlobal。windowManager是一個(gè)接口,,繼承自viewManager,。viewManager中包含了我們非常熟悉的三個(gè)接口:addView,removeView,updateView 。
windowManagerImpl和PhoneWindow是成對(duì)出現(xiàn)的,,前者負(fù)責(zé)管理后者,。WindowManagerImpl是windowManager的實(shí)現(xiàn)類,但是他本身并沒有真正實(shí)現(xiàn)邏輯,,而是交給了WindowManagerGlobal,。WindowManagerGlobal是全局單例,windowManagerImpl內(nèi)部使用橋接模式,,他是windowManager接口邏輯的真正實(shí)現(xiàn)
view相關(guān)
這里有個(gè)很關(guān)鍵的類:ViewRootImpl,。每個(gè)view樹都會(huì)有一個(gè)。當(dāng)我使用windowManager的addView方法時(shí),,就會(huì)創(chuàng)建一個(gè)ViewRootImpl,。ViewRootImpl的作用很關(guān)鍵:
- 負(fù)責(zé)連接view和window的橋梁事務(wù)
- 負(fù)責(zé)和WindowManagerService的聯(lián)系
- 負(fù)責(zé)管理和繪制view樹
- 事件的中轉(zhuǎn)站
每個(gè)window都會(huì)有一個(gè)ViewRootImpl,viewRootImpl是負(fù)責(zé)繪制這個(gè)view樹和window與view的橋梁,每個(gè)window都會(huì)有一個(gè)ViewRootImpl,。
WindowManagerService
這個(gè)是window的真正管理者,,類似于AMS(ActivityManagerService)管理四大組件。所有的window創(chuàng)建最終都要經(jīng)過windowManagerService,。整個(gè)Android的window機(jī)制中,,WMS絕對(duì)是核心,他決定了屏幕所有的window該如何顯示如何分發(fā)點(diǎn)擊事件等等,。
window與PhoneWindow的關(guān)系
解釋一下標(biāo)題,,window是指window機(jī)制中window這個(gè)概念,而PhoneWindow是指PhoneWindow這個(gè)類,。后面我在講的時(shí)候,,如果是指類,我會(huì)在后面加個(gè)'類’字,。如window是指window概念,,window類是指window這個(gè)抽象類。讀者不要混淆,。
還記得我在講window的概念的時(shí)候留了一個(gè)思考嗎,?
思考:Android中不是有一個(gè)抽象類叫做window還有一個(gè)PhoneWindow實(shí)現(xiàn)類嗎,他們不就是window的存在形式,,為什么說window是抽象不存在的
這里我再拋出幾個(gè)問題:
- 有一些資料認(rèn)為PhoneWindow就是window,,是view容器,負(fù)責(zé)管理容器內(nèi)的view,,windowManagerImpl可以往里面添加view,,如上面我們講過的addView方法。但是,,同時(shí)它又說每個(gè)window對(duì)應(yīng)一個(gè)viewRootImpl,,但卻沒解釋為什么每次addView都會(huì)新建一個(gè)viewRootImpl,前后發(fā)送矛盾,。
- 有一些資料也是認(rèn)為PhoneWindow是window,,但是他說addView方法不是添加view而是添加window,同時(shí)拿這個(gè)方法的名字作為論據(jù)證明view就是window,,但是他沒解釋為什么在使用addView方法創(chuàng)建window的過程卻沒有創(chuàng)建PhoneWindow對(duì)象,。
我們一步步來看。我們首先來看一下源碼中對(duì)于window抽象類的注釋:
Abstract base class for a top-level window look and behavior policy. An
instance of this class should be used as the top-level view added to the
window manager. It provides standard UI policies such as a background, title
area, default key processing, etc.
頂層窗口外觀和行為策略的抽象基類,。此類的實(shí)例應(yīng)用作添加到窗口管理器的頂層視圖,。
它提供標(biāo)準(zhǔn)的UI策略,如背景,、標(biāo)題區(qū)域,、默認(rèn)鍵處理等,。
大概意思就是:這個(gè)類是頂級(jí)窗口的抽象基類,頂級(jí)窗口必須繼承他,,他負(fù)責(zé)窗口的外觀如背景,、標(biāo)題、默認(rèn)按鍵處理等,。這個(gè)類的實(shí)例被添加到windowManager中,,讓windowManager對(duì)他進(jìn)行管理。PhoneWindow是一個(gè)top-level window(頂級(jí)窗口),,他被添加到頂級(jí)窗口管理器的頂層視圖,,其他的window,都需要添加到這個(gè)頂層視圖中,,所以更準(zhǔn)確的來說,,PhoneWindow并不是view容器,而是window容器,。
那PhoneWindow的存在意義是什么,?
第一、提供DecorView模板,。如下圖:
我們的Activity是通過setContentView把布局設(shè)置到DecorView中,,那么DecorView本身的布局,,就成為了Activity界面的背景,。同時(shí)DecorView是分為標(biāo)題欄和內(nèi)容兩部分,所以也可以可界面設(shè)置標(biāo)題欄,。同時(shí),,由于我們的界面是添加在的DecorView中,屬于DecorView的一部分,。那么對(duì)于DecorView的window屬性設(shè)置也會(huì)對(duì)我們的布局界面生效,。還記得谷歌的官方給window類注釋的最后一句話嗎:它提供標(biāo)準(zhǔn)的UI策略,如背景,、標(biāo)題區(qū)域,、默認(rèn)鍵處理等。 這些都可以通過DecorView實(shí)現(xiàn),,這是PhoneWindow的第一個(gè)作用,。
第二、抽離Activity中關(guān)于window的邏輯,。Activity的職責(zé)非常多,,如果所有的事情都自己做,那么會(huì)造成本身代碼極其臃腫,。閱讀過Activity啟動(dòng)的讀者可能知道,,AMS也通過ActivityStarter這個(gè)類來抽離啟動(dòng)Activity啟動(dòng)的邏輯。這樣關(guān)于window相關(guān)的事情,就交給PhoneWindow去處理了,。(事實(shí)上,,Activity調(diào)用的是WindowManagerImpl,但因PhoneWindow和WindowManagerImpl兩者是成對(duì)存在,,他們共同處理window相關(guān)的事務(wù),,所以這里就簡單寫成交給PhoneWindow處理。)當(dāng)Activity需要添加界面時(shí),,只需要一句setContentView,,調(diào)用了PhoneWindow的setContentView方法,就把布局設(shè)置到屏幕上了,。具體怎么完成,,Activity不必管。
第三,、限制組件添加window的權(quán)限,。PhoneWindow內(nèi)部有一個(gè)token屬性,用于驗(yàn)證一個(gè)PhoneWindow是否允許添加window,。在Activity創(chuàng)建PhoneWindow的時(shí)候,,就會(huì)把從AMS傳過來的token賦值給他,從而他也就有了添加token的權(quán)限,。而其他的PhoneWindow則沒有這個(gè)權(quán)限,,因而也無法添加window。這部分內(nèi)容我在另一篇文章有詳細(xì)講解,,感興趣的讀者可以前往了解一下傳送門,。
當(dāng)然,PhoneWindow的作用肯定遠(yuǎn)不止如此,,這里列出很重要的三條,,也是筆者目前學(xué)習(xí)到的三個(gè)最重要的作用。官方對(duì)于一個(gè)類的設(shè)計(jì)的考慮肯定是非常多,,不是筆者簡單的分析所能闡述,,而只是給出一個(gè)新的思考方向,帶大家認(rèn)識(shí)真正的window,。
總結(jié)一下:
- PhoneWindow本身不是真正意義上的window,,他更多可以認(rèn)為是輔助Activity操作window的工具類。
- windowManagerImpl并不是管理window的類,,而是管理PhoneWindow的類,。真正管理window的是WMS。
- PhoneWindow可以配合DecorView可以給其中的window按照一定的邏輯提供標(biāo)準(zhǔn)的UI策略
- PhoneWindow限制了不同的組件添加window的權(quán)限,。
常見組件的window創(chuàng)建流程
上面講的是通過windowManagerImpl創(chuàng)建window的過程,,我們通過前面的講解了解到,,WindowManagerImpl是管理PhoneWindow的,他們是同時(shí)出現(xiàn)的,。因而有兩種創(chuàng)建window的方式:
- 已經(jīng)存在PhoneWindow,,直接通過WindowManagerImpl創(chuàng)建window
- PhoneWindow尚未存在,先創(chuàng)建PhoneWindow,,再利用windowManagerImpl來創(chuàng)建window
當(dāng)我們?cè)贏ctivity中使用getWindowManager方法獲取到的就是應(yīng)用的PhoneWindow對(duì)應(yīng)的WindowManagerImpl,。下面來講一下不同的組件是如何創(chuàng)建window的,
Activity
如果有閱讀過Activity的啟動(dòng)流程的讀者,,會(huì)知道Activity的啟動(dòng)最后來到了ActivityThread的handleLaunchActivity 這個(gè)方法,。
關(guān)于Activity的啟動(dòng)流程,我寫過一篇文章,,有興趣的讀者可以點(diǎn)擊下方鏈接前往:
Activity啟動(dòng)流程詳解(基于api28)
至于為什么是這個(gè)方法這里就不講了,,有興趣的讀者可以去看上面的文章。我們直接來看這個(gè)方法的代碼:
public void handleLaunchActivity(IBinder token, boolean finalStateRequest, boolean isForward,
String reason) {
...;
// 這里對(duì)WindowManagerGlobal進(jìn)行初始化
WindowManagerGlobal.initialize();
// 啟動(dòng)Activity并回調(diào)activity的onCreate方法
final Activity a = performLaunchActivity(r, customIntent);
...
}
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
try {
// 這里創(chuàng)建Application
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
...
if (activity != null) {
...
Window window = null;
if (r.mPendingRemoveWindow != null && r.mPreserveWindow) {
window = r.mPendingRemoveWindow;
r.mPendingRemoveWindow = null;
r.mPendingRemoveWindowManager = null;
}
appContext.setOuterContext(activity);
// 這里將window作為參數(shù)傳到activity的attach方法中
// 一般情況下這里window==null
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window, r.configCallback,
r.assistToken);
...
// 最后這里回調(diào)Activity的onCreate方法
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
}
...
}
handleLaunchActivity 的代碼中首先對(duì)WindowManagerGlobal進(jìn)行初始化,,然后調(diào)用了performLaunchActivity 方法,。代碼很多,這里只截取了重要部分,。首先會(huì)創(chuàng)建Application對(duì)象,,然后再調(diào)用Activity的attach方法,把window作為參數(shù)傳進(jìn)去,,最后回調(diào)activity的onCreate方法,。所以這里最有可能創(chuàng)建window的方法就是Activity的attach 方法了。我們進(jìn)去看一下:
final void attach(...,Context context,Window window, ...) {
...;
// 這里新建PhoneWindow對(duì)象,,并對(duì)window進(jìn)行初始化
mWindow = new PhoneWindow(this, window, activityConfigCallback);
// Activity實(shí)現(xiàn)window的callBack接口,,把自己設(shè)置給window
mWindow.setWindowControllerCallback(this);
mWindow.setCallback(this);
mWindow.setOnWindowDismissedCallback(this);
mWindow.getLayoutInflater().setPrivateFactory(this);
...
// 這里初始化window的WindowManager對(duì)象
mWindow.setWindowManager(
(WindowManager)context.getSystemService(Context.WINDOW_SERVICE),
mToken, mComponent.flattenToString(),
(info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
}
同樣只截取了重要代碼,,attach方法參數(shù)非常多,,我只留下了window相關(guān)的參數(shù)。在這方法里首先利用傳進(jìn)來的window創(chuàng)建了PhoneWindow,。Activity實(shí)現(xiàn)window的callBack接口,,可以把自己設(shè)置給window當(dāng)觀察者。當(dāng)window發(fā)生變化的時(shí)候可以通知activity,。然后再創(chuàng)建WindowManager和PhoneWindow綁定在一起,,這樣我們就可以通過windowManager操作PhoneWindow了。(這里不是setWindowManager嗎,,windowManager是什么時(shí)候創(chuàng)建的,?)我們進(jìn)去setWindowManager 方法看一下:
public void setWindowManager(WindowManager wm, IBinder appToken, String appName,
boolean hardwareAccelerated) {
mAppToken = appToken;
mAppName = appName;
mHardwareAccelerated = hardwareAccelerated;
if (wm == null) {
wm = (WindowManager)mContext.getSystemService(Context.WINDOW_SERVICE);
}
// 這里創(chuàng)建了windowManager
mWindowManager = ((WindowManagerImpl)wm).createLocalWindowManager(this);
}
這個(gè)方法里首先會(huì)獲取到應(yīng)用服務(wù)的WindowManager(實(shí)現(xiàn)類也是WindowManagerImpl),然后通過這個(gè)應(yīng)用服務(wù)的WindowManager創(chuàng)建了新的windowManager,。
從這里可以看到是利用系統(tǒng)服務(wù)的windowManager來創(chuàng)建新的windowManagerImpl,,因而這個(gè)應(yīng)用所有的WindowManagerImpl都是同個(gè)內(nèi)核windowManager,,而創(chuàng)建出來的僅僅是包了個(gè)殼。
這樣PhoneWindow和WindowManagerImpl就綁定在一起了,。Activity可以通過WindowManagerImpl來操作PhoneWindow,。
到這里Activity的PhoneWindow和WindowManagerImpl對(duì)象就創(chuàng)建完成了,接下來是如何把Activity的布局文件設(shè)置給PhoneWindow,。在上面我講到調(diào)用Activity的attach方法之后,,會(huì)回調(diào)Activity的onCreate方法,在onCreate方法我們會(huì)調(diào)用setContentView 來設(shè)置布局,,如下:
public void setContentView(View view, ViewGroup.LayoutParams params) {
getWindow().setContentView(view, params);
initWindowDecorActionBar();
}
這里的getWindow就是獲取到我們上面創(chuàng)建的PhoneWindow對(duì)象,。我們繼續(xù)看下去:
// 注意他有多個(gè)重載的方法,要選擇參數(shù)對(duì)應(yīng)的方法
public void setContentView(int layoutResID) {
// 創(chuàng)建DecorView
if (mContentParent == null) {
installDecor();
} else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
mContentParent.removeAllViews();
}
if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
final Scene newScene = Scene.getSceneForLayout(mContentParent, layoutResID,
getContext());
transitionTo(newScene);
} else {
// 這里根據(jù)布局id加載布局
mLayoutInflater.inflate(layoutResID, mContentParent);
}
mContentParent.requestApplyInsets();
final Callback cb = getCallback();
if (cb != null && !isDestroyed()) {
// 回調(diào)activity的方法
cb.onContentChanged();
}
mContentParentExplicitlySet = true;
}
同樣我們只看重點(diǎn)代碼:
- 首先看decorView創(chuàng)建了沒有,,沒有的話創(chuàng)建DecorView
- 把布局加載到DecorView中
- 回調(diào)Activity的callBack方法
這里補(bǔ)充一下什么是DecorView,。DecorView是在PhoneWindow中預(yù)設(shè)好的一個(gè)布局,這個(gè)布局長這樣:
他是一個(gè)垂直排列的布局,,上面是ActionBar,,下面是ContentView,他是一個(gè)FrameLayout,。我們的Activity布局就加載到ContentView里進(jìn)行顯示,。所以Decorview是Activity布局最頂層的viewGroup。
然后我們看一下怎么初始化DercorView的:
private void installDecor() {
mForceDecorInstall = false;
if (mDecor == null) {
// 這里創(chuàng)建了DecorView
mDecor = generateDecor(-1);
...
} else {
mDecor.setWindow(this);
}
if (mContentParent == null) {
// 對(duì)DecorView進(jìn)行初始化,,得到ContentView
mContentParent = generateLayout(mDecor);
...
}
}
installDecor 方法中主要是新建一個(gè)DecorView對(duì)象,,然后加載預(yù)設(shè)好的布局對(duì)DecorView進(jìn)行初始化,(預(yù)設(shè)好的布局就是上面講述的布局)并獲取到這個(gè)預(yù)設(shè)布局的ContentView,。好了然后我們?cè)倩氐絯indow的setContentView方法中,,初始化了DecorView之后,把Activity布局加載到DecorView的ContentView中如下代碼:
// 注意他有多個(gè)重載的方法,,要選擇參數(shù)對(duì)應(yīng)的方法
public void setContentView(int layoutResID) {
...
if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
final Scene newScene = Scene.getSceneForLayout(mContentParent, layoutResID,
getContext());
transitionTo(newScene);
} else {
// 這里根據(jù)布局id加載布局
mLayoutInflater.inflate(layoutResID, mContentParent);
}
...
mContentParent.requestApplyInsets();
final Callback cb = getCallback();
if (cb != null && !isDestroyed()) {
// 回調(diào)activity的方法
cb.onContentChanged();
}
}
所以可以看到Activitiy的布局確實(shí)是添加到DecorView的ContentView中,,這也是為什么onCreate中使用的是setContentView而不是setView。最后會(huì)回調(diào)Activity的方法告訴Activity,,DecorView已經(jīng)創(chuàng)建并初始化完成了,。
到這里DecorView創(chuàng)建完成了,但還缺少了最重要的一步:把DecorView作為window添加到屏幕上,。從前面的介紹我們知道添加window需要用到WindowManagerImpl的addView方法,。這一步是在ActivityThread的handleResumeActivity 方法中被執(zhí)行:
public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,
String reason) {
// 調(diào)用Activity的onResume方法
final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
...
// 讓decorView顯示到屏幕上
if (r.activity.mVisibleFromClient) {
r.activity.makeVisible();
}
這一步方法有兩個(gè)重點(diǎn):回調(diào)onResume方法,把decorView添加到屏幕上,。我們看一下makeVisible 方法做了什么:
void makeVisible() {
if (!mWindowAdded) {
ViewManager wm = getWindowManager();
wm.addView(mDecor, getWindow().getAttributes());
mWindowAdded = true;
}
mDecor.setVisibility(View.VISIBLE);
}
是不是非常熟悉,?直接調(diào)用WindowManagerImpl的addView方法來吧decorView添加到屏幕上,至此,,我們的Activity界面就會(huì)顯示在屏幕上了,。
好了,,這部分很長,最后來總結(jié)一下:
- 從Activity的啟動(dòng)流程可以得到Activity創(chuàng)建Window的過程
- 創(chuàng)建PhoneWindow -> 創(chuàng)建WindowManager -> 創(chuàng)建decorView -> 利用windowManager把DecorView顯示到屏幕上
- 回調(diào)onResume方法的時(shí)候,,DecorView還沒有被添加到屏幕,,所以當(dāng)onResume被回調(diào),指的是屏幕即將到顯示,,而不是已經(jīng)顯示
popupWindow日常使用的也比較多,,最常見的需求是彈一個(gè)菜單出來等。popupWindow也是利用windowManager來往屏幕上添加window,,但,,popupWindow是依附于activity而存在的,當(dāng)Activity未運(yùn)行時(shí),,是無法彈出popupWindow的,,通過源碼可以知道,當(dāng)調(diào)用onResume方法的時(shí)候,,其實(shí)后續(xù)還有很多事情在做,,這個(gè)時(shí)候Activity也是尚未完全啟動(dòng),所以popupWindow不能在onCreate,、onStart,、onResume方法中彈出。
彈出popupWindow的過程分為兩個(gè):創(chuàng)建view,;通過windowManager添加window,。首先看到PopupWindow的構(gòu)造方法:
public PopupWindow(View contentView, int width, int height, boolean focusable) {
if (contentView != null) {
mContext = contentView.getContext();
mWindowManager = (WindowManager) mContext.getSystemService(Context.WINDOW_SERVICE);
}
setContentView(contentView);
setWidth(width);
setHeight(height);
setFocusable(focusable);
}
他有多個(gè)重載方法,但最終都會(huì)調(diào)用到這個(gè)有四個(gè)參數(shù)的方法,。主要是前面的得到context和根據(jù)context獲得WindowManager,。
然后我們看到他的顯示方法。顯示方法有兩個(gè):showAtLocation 和showAsDropDown ,。主要是處理顯示的位置不同,,其他都是相似的。我們看到第一個(gè)方法:
public void showAtLocation(View parent, int gravity, int x, int y) {
mParentRootView = new WeakReference<>(parent.getRootView());
showAtLocation(parent.getWindowToken(), gravity, x, y);
}
邏輯很簡單,,父view的根布局存儲(chǔ)了起來,,然后調(diào)用另外的重載方法:
public void showAtLocation(IBinder token, int gravity, int x, int y) {
// 如果contentView是空直接返回
if (isShowing() || mContentView == null) {
return;
}
TransitionManager.endTransitions(mDecorView);
detachFromAnchor();
mIsShowing = true;
mIsDropdown = false;
mGravity = gravity;
// 得到WindowManager.LayoutParams對(duì)象
final WindowManager.LayoutParams p = createPopupLayoutParams(token);
// 做一些準(zhǔn)備工作
preparePopup(p);
p.x = x;
p.y = y;
// 執(zhí)行popupWindow顯示工作
invokePopup(p);
}
這個(gè)方法的邏輯主要有:
- 判斷contentView是否為空或者是否進(jìn)行顯示
- 做一些準(zhǔn)備工作
- 進(jìn)行popupWindow顯示工作
這里我們看一下他的準(zhǔn)備工作做了什么:
private void preparePopup(WindowManager.LayoutParams p) {
...
if (mBackground != null) {
mBackgroundView = createBackgroundView(mContentView);
mBackgroundView.setBackground(mBackground);
} else {
mBackgroundView = mContentView;
}
// 創(chuàng)建了DecorView
// 注意,這里的DecorView并不是我們之前講的DecorView,,而是他的內(nèi)部類:PopupDecorView
mDecorView = createDecorView(mBackgroundView);
mDecorView.setIsRootNamespace(true);
...
}
接下來再看他的顯示工作:
private void invokePopup(WindowManager.LayoutParams p) {
...
// 調(diào)用windowManager添加window
mWindowManager.addView(decorView, p);
...
}
到這里popupWindow就會(huì)被添加到屏幕上了。
最后總結(jié)一下:
- 根據(jù)參數(shù)構(gòu)建popupDecorView
- 把popupDecorView添加到屏幕上
Dialog
dialog的創(chuàng)建過程Activity比較像:創(chuàng)建PhoneWindow,,初始化DecorView,,添加DecorView。我這里就簡單講解一下,。首先看到他的構(gòu)造方法:
Dialog(@NonNull Context context, @StyleRes int themeResId, boolean createContextThemeWrapper) {
...
// 獲取windowManager
mWindowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
// 構(gòu)造PhoneWindow
final Window w = new PhoneWindow(mContext);
mWindow = w;
// 初始化PhoneWindow
w.setCallback(this);
w.setOnWindowDismissedCallback(this);
w.setOnWindowSwipeDismissedCallback(() -> {
if (mCancelable) {
cancel();
}
});
w.setWindowManager(mWindowManager, null, null);
w.setGravity(Gravity.CENTER);
mListenersHandler = new ListenersHandler(this);
}
這里和前面的Activity創(chuàng)建過程非常像,,但是有個(gè)重點(diǎn)需要注意mWindowManager其實(shí)是Activity的WindowManager,,這里的context一般是activity(實(shí)際上也只能是activity,非activity會(huì)拋出異常,,相關(guān)內(nèi)容讀者有興趣可以閱讀這篇文章window的token驗(yàn)證),,我們看到activity的getSystemService方法:
public Object getSystemService(@ServiceName @NonNull String name) {
if (getBaseContext() == null) {
throw new IllegalStateException(
"System services not available to Activities before onCreate()");
}
// 獲取activity的windowManager
if (WINDOW_SERVICE.equals(name)) {
return mWindowManager;
} else if (SEARCH_SERVICE.equals(name)) {
ensureSearchManager();
return mSearchManager;
}
return super.getSystemService(name);
}
可以看到這里的windowManager確實(shí)是Activity的WindowManager。接下來看到他的show方法:
public void show() {
...
// 回調(diào)onStart方法,,獲取前面初始化好的decorview
onStart();
mDecor = mWindow.getDecorView();
...
WindowManager.LayoutParams l = mWindow.getAttributes();
...
// 利用windowManager來添加window
mWindowManager.addView(mDecor, l);
...
mShowing = true;
sendShowMessage();
}
注意這里的mWindowManager是Activity的WindowManager,,所以實(shí)際上,這里是添加到了Activity的PhoneWindow中,。接下來的和前面的添加流程一樣,,這里我也不多講解了。
總結(jié)一下:
- dialog和popupWindow不同,,dialog創(chuàng)建了新的PhoneWindow,,使用了PhoneWindow的DecorView模板。而popupWindow沒有
- dialog的顯示層級(jí)數(shù)更高,,會(huì)直接顯示在Activity上面,,在dialog后添加的popUpWindow也會(huì)顯示在dialog下
- dialog的創(chuàng)建流程和activity非常像
從Android架構(gòu)角度看Window
前面我們介紹過關(guān)于PhoneWindow和window之間的關(guān)系,了解到PhoneWindow其實(shí)不是Window,,只是一個(gè)window容器,。不知讀者有沒想過一個(gè)問題,為什么谷歌要建一個(gè)不是window但卻名字是window的類,?是故意要迷惑我們嗎,?要了解這個(gè)問題,我們先來回顧一下整個(gè)android的window機(jī)制結(jié)構(gòu),。
首先從WindowManagerService開始,,我們知道WMS是window的最終管理者,在WMS中為每一個(gè)應(yīng)用持有一個(gè)session,,關(guān)于session前面我們講過,,每個(gè)應(yīng)用都是全局單例,負(fù)責(zé)和WMS通信的binder對(duì)象,。WMS為每個(gè)window都建立了一個(gè)windowStatus對(duì)象,,同一個(gè)應(yīng)用的window使用同個(gè)session進(jìn)行跨進(jìn)程通信,結(jié)構(gòu)大概如下:
而負(fù)責(zé)與WMS通信的,,是viewRootImpl,。前面我們講過每個(gè)view樹即為一個(gè)window,viewRootImpl負(fù)責(zé)和WMS進(jìn)行通信,,同時(shí)也負(fù)責(zé)view的繪制,。如果把上面的圖畫仔細(xì)一點(diǎn)就是:
圖中每一個(gè)windowStatus對(duì)應(yīng)一個(gè)viewRootImpl,WMS通過viewRootImpl來控制view,。這也就是window機(jī)制的管理結(jié)構(gòu),。當(dāng)我們需要添加window的時(shí)候,,最終的邏輯實(shí)現(xiàn)是WindowManagerGlobal,他的內(nèi)部使用自己的session創(chuàng)建一個(gè)viewRootImpl,,然后向WMS申請(qǐng)?zhí)砑觲indow,,結(jié)構(gòu)圖大概如下:
windowManagerGlobal使用自己的IWindowSession創(chuàng)建viewRootImpl,這個(gè)IWindowSession是全局單例,。viewRootImpl和WMS申請(qǐng)創(chuàng)建window,,然后WMS允許之后,再通知viewRootImpl繪制view,,同時(shí)WMS通過windowStatus存儲(chǔ)了viewRootImpl的相關(guān)信息,,這樣如果WMS需要修改view,直接通過viewRootImpl就可以修改view了,。
從上面的描述中可以發(fā)現(xiàn)我全程沒有提及到PhoneWindow和WindowManagerImpl,。這是因?yàn)?strong>他們不屬于window機(jī)制內(nèi)的類,而是封裝于window機(jī)制之上的框架,。假設(shè)如果沒有PhoneWindow和WindowManager我們?cè)撊绾翁砑右粋€(gè)window,?首先需要調(diào)用WindowGlobal獲取session,再創(chuàng)建viewRootImpl,,再訪問wms,,然后再利用viewRootImpl繪制view,是不是很復(fù)雜,,而這僅僅只是整體的步驟,。而WindowManagerImpl正是這個(gè)功能。他內(nèi)部擁有WindowManagerGlobal的單例,,然后幫助我們完成了這一系列的步驟,。同時(shí),windowManagerImpl也是只有一個(gè)實(shí)例,,其他的windowManagerImpl都是建立在windowManagerImpl單例上,。這一點(diǎn)在前面有通過源碼介紹到。
另外,,上面我講到PhoneWindow并不是window而是一個(gè)輔助Activity管理的工具類,,那為什么他不要命名為windowUtils呢?首先,,PhoneWindow這個(gè)類是谷歌給window機(jī)制進(jìn)行更上一層的封裝,。PhoneWindow內(nèi)部擁有一個(gè)DecorView,我們的布局view都是添加到decorView中的,,因?yàn)槲覀兛梢酝ㄟ^給decorView設(shè)置背景,,寬高度,標(biāo)題欄,,按鍵反饋等等,,來間接給我們的布局view設(shè)置。這樣一來,,PhoneWindow的存在,,向開發(fā)者屏蔽真正的window,暴露給開發(fā)者一個(gè)“存在的”window,。我們可以認(rèn)為PhoneWindow就是一個(gè)window,,window是view容器。當(dāng)我們需要在屏幕上添加view的時(shí)候,,只需要獲得應(yīng)用window對(duì)應(yīng)的windowManagerImpl,,然后直接調(diào)用addView方法添加view即可。這里也可以解釋為什么windowManager的接口方法是addView而不是addWindow,,一是window確實(shí)是以view的存在形式?jīng)]錯(cuò),,二是為了向開發(fā)者屏蔽真正的window,讓我們以為是在往window中添加view,,window是真實(shí)存在的東西,。他們的關(guān)系畫個(gè)圖如下:
黃色部分輸于谷歌提供給開發(fā)者的window框架,而綠色是真正的window機(jī)制結(jié)構(gòu),。通過PhoneWindow我們可以很方便地進(jìn)行window操作,,而不須了解底層究竟是如何工作的。PhoneWindow的存在,,更是讓window的“可見性”得到了實(shí)現(xiàn),,讓window變成了一個(gè)“view容器”。
好了最后來總結(jié)一下:
- Android內(nèi)部的window機(jī)制與谷歌暴露給我們的api是不一樣的,,谷歌封裝的目的是為了讓我們更好地使用window,。
- dialog、popupWindow等框架更是對(duì)具體場景進(jìn)行更進(jìn)一步的封裝,。
- 我們?cè)诹私鈝indow機(jī)制的時(shí)候,,需要跳過應(yīng)用層,看到window的本質(zhì),,才能更好地幫助我們理解window,。
- 在android的其他地方也是一樣,利用封裝向開發(fā)者屏蔽底層邏輯,,讓我們更好地運(yùn)用,。但如果我們需要了解他的機(jī)制的時(shí)候,就需要繞過這層封裝,,看到本質(zhì),。
總結(jié)
全文到這里,就基本結(jié)束了。下面先總結(jié)一下我這篇文章說了什么:
- 詳述了什么是window
- 對(duì)window的各種參數(shù)進(jìn)行講解
- 講解window機(jī)制內(nèi)的關(guān)鍵類
- 從源碼講解window的添加流程以及各大組件的window添加流程
- 詳解了PhoneWindow與window的關(guān)系,,談了關(guān)于谷歌的封裝思想
文中最重要的一點(diǎn)就是認(rèn)識(shí)window的本質(zhì),,區(qū)分好window和view之間的關(guān)系以及window與PhoneWindow的關(guān)系。
筆者在寫這篇文章的時(shí)候,,對(duì)于各節(jié)的安排是比較猶豫的:如果先講概念,,沒有源碼流程的講解很難懂;先講源碼流程,,沒有概念的認(rèn)知很難讀懂源碼,。最終還是決定了先講window的真正概念,先讓讀者有個(gè)整體上的感知,。
文章很長,,筆者對(duì)于window想要講的都在這篇文章中。
希望文章對(duì)你有幫助,。
全文到此,,感謝你的閱讀
原創(chuàng)不易,覺得有幫助可以點(diǎn)贊收藏評(píng)論轉(zhuǎn)發(fā)關(guān)注,。
筆者才疏學(xué)淺,,有任何錯(cuò)誤歡迎評(píng)論區(qū)或私信交流。
如需轉(zhuǎn)載請(qǐng)私信或評(píng)論區(qū)交流,。
另外歡迎光臨筆者的個(gè)人博客:傳送門
參考文獻(xiàn)
《Android開發(fā)藝術(shù)探索》
《Android進(jìn)階解密》
|