網(wǎng)站移動(dòng)端做pc端的301跳轉(zhuǎn)windows優(yōu)化大師有哪些功能
文章目錄
- 理解Window和WindowManager
- Window和WindowManager
- Window的內(nèi)部機(jī)制
- Window的添加過程
- Window的刪除過程
- Window的更新過程
- Window的創(chuàng)建過程
- Activity的Window創(chuàng)建過程
- Dialog的Window創(chuàng)建過程
- Toast的Window創(chuàng)建過程
理解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)的WindowFLAG_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í)范圍是199,子Window的層級(jí)范圍是10001999,系統(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()方法分為如下幾步:
- 檢查參數(shù)是否合法,如果是子Window那么還需要調(diào)整一些布局參數(shù)
- 創(chuàng)建
ViewRootImpl
并將View添加到列表中。Window對(duì)應(yīng)的View, ViewRootImpl和待刪除的View對(duì)象都有對(duì)應(yīng)的列表。 - 通過
ViewRootImpl
的setView()
來更新界面(View的繪制由ViewRootImpl完成),setView()
中通過requestLayout()
完成異步刷新請(qǐng)求 - 通過
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)。主要做四件事:
- 垃圾回收的工作,比如清除數(shù)據(jù)和消息,移除回調(diào)。
- 通過Session的remove方法刪除Window,mWindowSession.remove(mWindow),這同樣是一個(gè)IP C過程,最終會(huì)調(diào)用WindowManagerService的removeWindow方法
- 調(diào)用View的dispatchDetachedFromWindow方法,在內(nèi)部調(diào)用View的onDetachedFromWindow()以及onDetachedFromWindowInternal()。
- 調(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è)步驟:
- 如果沒有
DecorView
(FrameLayout,頂級(jí)View,包含內(nèi)容和標(biāo)題欄),那么就創(chuàng)建它,通過gernerateLayout()
加載具體的布局文件。- 將View添加到DecorView的
mContentParent
中,- 回調(diào)Activity的
onCreateChanged()
方法通知Activity視圖已經(jīng)發(fā)生改變
Window更多表示的是一種抽象的功能集合…
Dialog的Window創(chuàng)建過程
Dialog的Window的創(chuàng)建過程和Activity類似,有如下步驟:
- 創(chuàng)建Window:Diolog中Window的創(chuàng)建同樣是通過PolicyManager的
makeNewWindow()
方法來完成的,創(chuàng)建后的對(duì)象實(shí)際上就是PhoneWindow。 - 初始化DecorView并將Dialog的視圖添加到DecorView中,與Activity類似。
- 調(diào)用Dialog的
show()
,將DecorView添加到Window中并顯示, 也與Activity類似。 - 普通的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添加或者移除。