Android之Window和彈窗問題

時間 2019-11-06

標籤 android window 問題欄目 Android 简体版

原文原文鏈接

目錄介紹

10.0.0.1 Window是什麼？如何經過WindowManager添加Window(代碼實現)？WindowManager的主要功能是什麼？
10.0.0.2 Window概念解析？WindowSession的建立過程是怎樣的？WindowSession的做用？Token的使用場景？
10.0.0.3 Activity、View、Window三者之間的關係，Window有哪幾種類型？
10.0.0.5 Activity的啓動過程是怎樣的？Activity建立和Dialog建立過程的異同？
10.0.0.6 如何處理快速連續點擊了屢次按鈕時Toast就觸發了屢次而關閉不掉？
10.0.0.7 DecorView什麼時候才被WindowManager真正添加到Window中？Window的addView源碼分析？
10.0.0.8 Dialog的Window建立過程?爲何Dialog不能用Application的Context？
10.0.0.9 什麼是DecorView？如何獲取到DecorView？DecorView的職責是什麼？DecorView如何被加載到Window中？
10.0.1.0 DecorView如何顯示出來，爲何setContentView()設置的界面，爲何在onResume()以後纔對用戶可見呢？
10.0.1.1 什麼是ViewRoot？ViewRoot屬於View樹的一份子嗎？ViewRoot的工做流程是怎麼樣的？
10.0.1.2 吐司爲什麼會出現內存泄漏？在Toast構造方法中建立NT對象是幹什麼用的？Toast是怎麼show出來的？
10.0.1.3 連續吐司是如何肯定吐司的前後順序？爲何Toast執行show後過了一下子就自動銷燬？
10.0.1.4 如何理解普通應用的Toast顯示數量是有限制的？爲何要判斷是不是系統吐司？爲什麼Activity銷燬後Toast仍會顯示？
10.0.1.5 爲何說Toast儘可能用全局上下文？說一下Toast的顯示和隱藏重點邏輯，說下你的理解？
10.0.1.6 Toast報錯Unable to add window是什麼意思？Toast運行在子線程會問題，在子線程或者service中能運行嗎？
10.0.1.7 爲何建議用DialogFragment替代Dialog？如何定義DialogFragment樣式？使用dialogFragment有何好處？
10.0.1.8 Dialog的Window建立過程是怎樣的？爲何Dialog不能用Application的Context，說一下緣由？
10.0.1.9 Dialog和Window有什麼關係？Dialog的dismiss和cancel()方法均可銷燬彈窗，它們有什麼區別？
10.0.2.0 PopupWindow中不設置爲何必須設置寬高？PopupWindow和Dialog有什麼區別？說下建立和銷燬的大概流程？
10.0.2.1 Snackbar與吐司有何區別在哪裏？Snackbar控件show時爲什麼從下往上移出來？爲何顯示在最下面？
10.0.2.2 說一下Snackbar和SnackbarManager類的設計有哪些奧妙的地方，如何處理消息的顯示順序？

好消息

博客筆記大彙總【15年10月到至今】，包括Java基礎及深刻知識點，Android技術博客，Python學習筆記等等，還包括平時開發中遇到的bug彙總，固然也在工做之餘收集了大量的面試題，長期更新維護而且修正，持續完善……開源的文件是markdown格式的！同時也開源了生活博客，從12年起，積累共計500篇[近100萬字]，將會陸續發表到網上，轉載請註明出處，謝謝！
連接地址：https://github.com/yangchong211/YCBlogs
若是以爲好，能夠star一下，謝謝！固然也歡迎提出建議，萬事起於忽微，量變引發質變！

彈窗博客筆記彙總

02.Toast源碼深度分析
- 最簡單的建立，簡單改造避免重複建立，show()方法源碼分析，scheduleTimeoutLocked吐司如何自動銷燬的，TN類中的消息機制是如何執行的，普通應用的Toast顯示數量是有限制的，用代碼解釋爲什麼Activity銷燬後Toast仍會顯示，Toast偶爾報錯Unable to add window是如何產生的，Toast運行在子線程問題，Toast如何添加系統窗口的權限等等
03.DialogFragment源碼分析
- 最簡單的使用方法，onCreate(@Nullable Bundle savedInstanceState)源碼分析，重點分析彈窗展現和銷燬源碼，使用中show()方法遇到的IllegalStateException分析
04.Dialog源碼分析
- AlertDialog源碼分析，經過AlertDialog.Builder對象設置屬性，Dialog生命週期，Dialog中show方法展現彈窗分析，Dialog的dismiss銷燬彈窗，Dialog彈窗問題分析等等
05.PopupWindow源碼分析
- 顯示PopupWindow，注意問題寬和高屬性，showAsDropDown()源碼，dismiss()源碼分析，PopupWindow和Dialog有什麼區別？爲什麼彈窗點擊一下就dismiss呢？
06.Snackbar源碼分析
- 最簡單的建立，Snackbar的make方法源碼分析，Snackbar的show顯示與點擊消失源碼分析，顯示和隱藏中動畫源碼分析，Snackbar的設計思路，爲何Snackbar老是顯示在最下面
07.彈窗常見問題
- DialogFragment使用中show()方法遇到的IllegalStateException,什麼常見產生的？Toast偶爾報錯Unable to add window，Toast運行在子線程致使崩潰如何解決？
08.Builder模式
- 你會發現，在這個彈窗封裝庫中，不少地方用到了builder模式，那麼能夠先了解下Builder模式使用場景，簡單案例，Builder模式實際案例Demo展現，看看AlertDialog.Builder源代碼如何實現，爲何AlertDialog要使用builder模式呢？builder模式優缺點分析。

10.0.0.1 Window是什麼？如何經過WindowManager添加Window(代碼實現)？WindowManager的主要功能是什麼？

Window是什麼？
- 表示一個窗口的概念，是全部View的直接管理者，任何視圖都經過Window呈現(點擊事件由Window->DecorView->View; Activity的setContentView底層經過Window完成)
- Window是一個抽象類，具體實現是PhoneWindow
- 建立Window須要經過WindowManager建立
- WindowManager是外界訪問Window的入口
- Window具體實現位於WindowManagerService中
- WindowManager和WindowManagerService的交互是經過IPC完成

如何經過WindowManager添加Window(代碼實現)？

以下所示

//1. 控件 
Button button = new Button(this); 
button.setText("Window Button"); 
//2. 佈局參數 
WindowManager.LayoutParams layoutParams = new WindowManager.LayoutParams(WindowManager.LayoutParams.WRAP_CONTENT, WindowManager.LayoutParams.WRAP_CONTENT, 0, 0, PixelFormat.TRANSPARENT); 
layoutParams.flags = WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL | WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE | WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED; 
layoutParams.gravity = Gravity.LEFT | Gravity.TOP; 
layoutParams.x = 100; 
layoutParams.y = 300; 
// 必需要有type否則會異常: the specified window type 0 is not valid 
layoutParams.type = WindowManager.LayoutParams.TYPE_SYSTEM_ERROR; 
//3. 獲取WindowManager並添加控件到Window中 
WindowManager windowManager = getWindowManager(); 
windowManager.addView(button, layoutParams);

WindowManager的主要功能是什麼？

添加、更新、刪除View

public interface ViewManager{ 
    public void addView(View view, ViewGroup.LayoutParams params); 
    //添加View 
    public void updateViewLayout(View view, ViewGroup.LayoutParams params); 
    //更新View 
    public void removeView(View view); 
    //刪除View 
}

10.0.0.2 Window概念解析？WindowSession的建立過程是怎樣的？WindowSession的做用？Token的使用場景？

Window概念解析？
- Window和View經過ViewRootImpl創建聯繫
- Window並非實際存在的，而是以View的形式存在
- WindowManager的三個接口方法也是針對View的
- 實際使用中沒法直接訪問Window，必須經過WindowManager
- View是視圖的呈現方式，可是不能單獨存在，必須依附在Window這個抽象的概念上
- WMS把全部的用戶消息發給View/ViewGroup，可是在View/ViewGroup處理消息的過程當中，有一些操做是公共的, Window把這些公共行爲抽象出來, 這就是Window。
WindowSession的建立過程是怎樣的？
- 在WindowManager的addView中會建立ViewRootImpl，內部會經過WMS去獲取WindowSession
- WindowSession的類型是IWindowSession，自己是Binder對象，真正實現類是Session
WindowSession的做用？博客
- 表示一個Active Client Session
- 每一個進程通常都有一個Session對象
- 用於WindowManager交互
Token的使用場景？
- Popupwindow的showAtLocation第一個參數須要傳入View，這個View就是用來獲取Token的。
- Android 5.0新增空間SnackBar同理也須要一個View來獲取Token
Token是什麼？
- 類型爲IBinder，是一個Binder對象。
- 主要分兩種Token：
  - 指向Window的token: 主要是實現WmS和應用所在進程通訊。
  - 指向ActivityRecord的token: 主要是實現WmS和AmS通訊的。
Activity中的Token
- ActivityRecord是AmS中用來保存一個Activity信息的輔助類。
- AMS中須要根據Token去找到對應的ActivityRecord。

10.0.0.3 Activity、View、Window三者之間的關係，Window有哪幾種類型？

Activity、View、Window三者之間的關係
- 在Activity啓動過程其中的attach()方法中初始化了PhoneWindow，而PhoneWindow是Window的惟一實現類，而後Activity經過setContentView將View設置到了PhoneWindow上，而View經過WindowManager的addView()、removeView()、updateViewLayout()對View進行管理。
Window有哪幾種類型
- 應用Window：對應一個Activity。
- 子Window：不能單獨存在，需附屬特定的父Window。如Dialog。
- 系統Window：需申明權限才能建立。如Toast。
Activity 與 PhoneWindow 與 DecorView 關係圖

10.0.0.5 Activity的啓動過程是怎樣的？Activity的視圖加載的源碼分析？Activity建立和Dialog建立過程的異同？

Activity的啓動過程是怎樣的？
- 最終會由ActivityThread中的performLauchActivity來完成整個啓動過程
- performLauchActivity內部會經過類加載器建立Activity的實例對象
- 併爲Activity的實例對象調用attach方法，爲其關聯運行過程當中因此來的上下文環境變量
- attch方法中，系統會建立Activity所屬的Window對象，併爲其設置回調接口
- Window對象的建立是經過PolicyManager的makeNewWindow方法實現。博客
- Activity實現了window的callback接口，所以外界狀態改變時會回調Activity的方法(onAttachedToWindow、dispatchTouchEvent等等)
Activity的視圖加載的源碼分析
Dialog的Window建立過程
- 建立WindowDialog。和Activity相似，一樣是經過PolicyManager.makeNewWindow() 來實現。
- 初始化DecorView並將Dialog的視圖添加到DecorView中去。和Activity相似，一樣是經過Window.setContentView() 來實現。
- 將DecorView添加到Window中顯示。和Activity同樣，都是在自身要出如今前臺時纔會將添加Window。
  - Dialog.show() 方法：完成DecorView的顯示。
  - WindowManager.remoteViewImmediate() 方法：當Dialog被dismiss時移除DecorView。

10.0.0.6 如何處理快速連續點擊了屢次按鈕時Toast就觸發了屢次而關閉不掉？

使用中遇到的問題
- 例如：當點擊有些按鈕，須要吐司進行提示時；快速連續點擊了屢次按鈕，Toast就觸發了屢次。可能致使Toast就長時間關閉不掉了。又或者咱們其實已在進行其餘操做了，應該彈出新的Toast提示，而上一個Toast卻還沒顯示結束。博客

解決的辦法

建立工具類：
/**
* 吐司工具類    避免點擊屢次致使吐司屢次，最後致使Toast就長時間關閉不掉了
* @param context
* @param content
*/
private static Toast toast;
public static void showToast(Context context, String content) {
    if (toast == null) {
        toast = Toast.makeText(context.getApplicationContext(), content, Toast.LENGTH_SHORT);
    } else {
        toast.setText(content);
    }
    toast.show();
}

這樣用的原理
- 先判斷Toast對象是否爲空，若是是空的狀況下才會調用makeText()方法來去生成一個Toast對象，不然就直接調用setText()方法來設置顯示的內容，最後再調用show()方法將Toast顯示出來。因爲不會每次調用的時候都生成新的Toast對象，所以剛纔咱們遇到的問題在這裏就不會出現

10.0.0.7 DecorView什麼時候才被WindowManager真正添加到Window中？Window的addView源碼分析？

DecorView什麼時候才被WindowManager真正添加到Window中？
- 即便Activity的佈局已經成功添加到DecorView中，DecorView此時尚未添加到Window中
- ActivityThread的handleResumeActivity方法中，首先會調用Activity的onResume方法，接着調用Activity的makeVisible()方法
- makeVisible()中完成了DecorView的添加和顯示兩個過程
Window的addView源碼分析？
- WindowManager是一個接口，真正實現類是WindowManagerImpl，並最終以代理模式交給WindowManagerGlobal實現。
- addView: 1-建立ViewRootImpl；2-將ViewRoor、DecorView、佈局參數保存到WM的內部列表中；3-ViewRoot.setView()創建ViewRoot和DecorView的聯繫。
- setView：1-進行View繪製三大流程；2-會經過WindowSession完成Window的添加過程(一次IPC調用)
- requestLayout：內部調用scheduleTraversals(), 底層經過mChoreographer去監聽下一幀的刷新信號。
- mWindowSession.addToDisplay: 執行WindowManangerService的addWindow
- addWindow: 檢查參數等設置;檢查Token;將Token、Window保存到WMS中;將WindowState保存到Session中。
Window的remove源碼與解析
- WindowManager中提供了兩種刪除接口：removeView異步刪除、removeViewImmediate同步刪除(不建議使用)
- 調用WMGlobal的removeView
- 調用到WMGlobal的removeViewLocked進行真正的移除
- 執行ViewRoot的die方法(): 1-同步方法直接調用doDie 2-異步方法直接發送Message
- doDie(): 調用dispatchDetachedFromWindow()和WindowManagerGlobal.getInstance().doRemoveView(this)
- dispatchDetachedFromWindow:博客
  - 1回調onDetachedFromeWindow；
  - 2垃圾回收相關操做；
  - 3經過Session的remove()在WMS中刪除Window；
  - 4經過Choreographer移除監聽器

10.0.0.8 Dialog的Window建立過程?爲何Dialog不能用Application的Context？

Dialog的Window建立過程?
- 建立Window——一樣是經過PolicyManager的makeNewWindow方法完成，與Activity建立過程一致
- 初始化DecorView並將Dialog的視圖添加到DecorView中——和Activity一致(setContentView)
- 將DecorView添加到Window中並顯示——在Dialog的show方法中，經過WindowManager將DecorView添加到Window中(mWindowManager.addView(mDecor, 1))
- Dialog關閉時會經過WindowManager來移除DecorView：mWindowManager.removeViewImmediate(mDecor)
- Dialog必須採用Activity的Context，由於有應用token(Application的Context沒有應用token)，也能夠將Dialog的Window經過type設置爲系統Window就再也不須要token。
爲何Dialog不能用Application的Context？
- Dialog自己的Token爲null，在初始化時若是是使用Application或者Service的Context，在獲取到WindowManager時，獲取到的token依然是null。
- Dialog若是採用Activity的Context，獲取到的WindowManager是在activity.attach()方法中建立，token指向了activity的token。
- 由於經過Application和Service的Context將沒法獲取到Token從而致使失敗。

10.0.0.9 什麼是DecorView？如何獲取到DecorView？DecorView的職責是什麼？DecorView如何被加載到Window中？

什麼是DecorView
- DecorView是FrameLayout的子類，它能夠被認爲是Android視圖樹的根節點視圖。
- DecorView做爲頂級View，通常狀況下它內部包含一個豎直方向的LinearLayout，在這個LinearLayout裏面有上下三個部分，上面是個ViewStub，延遲加載的視圖（應該是設置ActionBar，根據Theme設置），中間的是標題欄(根據Theme設置，有的佈局沒有)，下面的是內容欄。
如何獲取到DecorView
- 在Activity中經過setContentView所設置的佈局文件其實就是被加到內容欄之中的，成爲其惟一子View，就是上面的id爲content的FrameLayout中，在代碼中能夠經過content來獲得對應加載的佈局。博客
```
ViewGroup content = (ViewGroup)findViewById(android.R.id.content);
ViewGroup rootView = (ViewGroup) content.getChildAt(0);
```
DecorView的職責是什麼
- 經過源碼瞭解能夠知道，Activity就像個控制器，不負責視圖部分。Window像個承載器，裝着內部視圖。DecorView就是個頂層視圖，是全部View的最外層佈局。ViewRoot像個鏈接器，負責溝通，經過硬件的感知來通知視圖，進行用戶之間的交互。
DecorView如何被加載到Window中？博客
- 從Activity中的setContentView()開始。在Activity中的attach()方法中，生成了PhoneWindow實例。既然有了Window對象，那麼咱們就能夠**設置DecorView給Window對象了。
- 從中獲取mContentParent。得到到以後，而後經過installDecor方法，而後生成DecorView，不過這裏操做很複雜，大概流程先從主題中獲取樣式，而後根據樣式，加載對應的佈局到DecorView中，爲mContentParent添加View，即Activity中的佈局。
- 具體能夠看這篇文章：10.DecorView介紹

10.0.1.0 DecorView如何顯示出來，爲何setContentView()設置的界面，爲何在onResume()以後纔對用戶可見呢？

經過setContentView()設置的界面，爲何在onResume()以後纔對用戶可見呢？這就要從ActivityThread開始提及。

private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) {

    //就是在這裏調用了Activity.attach()呀，接着調用了Activity.onCreate()和Activity.onStart()生命週期，
    //可是因爲只是初始化了mDecor，添加了佈局文件，尚未把
    //mDecor添加到負責UI顯示的PhoneWindow中，因此這時候對用戶來講，是不可見的
    Activity a = performLaunchActivity(r, customIntent);

    ......

    if (a != null) {
    //這裏面執行了Activity.onResume()
    handleResumeActivity(r.token, false, r.isForward,
                        !r.activity.mFinished && !r.startsNotResumed);

    if (!r.activity.mFinished && r.startsNotResumed) {
        try {
                r.activity.mCalled = false;
                //執行Activity.onPause()
                mInstrumentation.callActivityOnPause(r.activity);
                }
        }
    }
}

重點看下handleResumeActivity(),在這其中，DecorView將會顯示出來，同時重要的一個角色：ViewRoot也將登場。
- 這個方法裏面會調用performResumeActivity方法，這個時候，Activity.onResume()已經調用了，可是如今界面仍是不可見的
- 接着講decorView添加進WindowManager了，可是這個時候，仍是不可見的
- 最後執行makeVisible，執行了重要的操做,使得DecorView可見
當咱們執行了Activity.makeVisible()方法以後，界面纔對咱們是可見的。博客
```
void makeVisible() {
   if (!mWindowAdded) {
        ViewManager wm = getWindowManager();
        wm.addView(mDecor, getWindow().getAttributes());//將DecorView添加到WindowManager
        mWindowAdded = true;
    }
    mDecor.setVisibility(View.VISIBLE);//DecorView可見
}
```
- 到此DecorView即可見，顯示在屏幕中。可是在這其中,wm.addView(mDecor, getWindow().getAttributes());起到了重要的做用，由於其內部建立了一個ViewRootImpl對象，負責繪製顯示各個子View。
最後經過WindowManagerImpl的addView方法將DecorView加載出來
- 看到其中實例化了ViewRootImpl對象，而後調用其setView()方法。其中setView()方法通過一些列折騰，最終調用了performTraversals()方法，而後依照下圖流程層層調用，完成繪製，最終界面才顯示出來。
- 具體更加詳細的過程，能夠看10.DecorView介紹

10.0.1.1 什麼是ViewRoot？ViewRoot屬於View樹的一份子嗎？ViewRoot的工做流程是怎麼樣的？

什麼是ViewRoot
- ViewRoot可能比較陌生，可是其做用很是重大。全部View的繪製以及事件分發等交互都是經過它來執行或傳遞的。
- ViewRoot對應ViewRootImpl類，它是鏈接WindowManagerService和DecorView的紐帶，View的三大流程（測量（measure），佈局（layout），繪製（draw））均經過ViewRoot來完成。
ViewRoot屬於View樹的一份子嗎？
- ViewRoot並不屬於View樹的一份子。
- 從源碼實現上來看，它既非View的子類，也非View的父類，可是，它實現了ViewParent接口，這讓它能夠做爲View的名義上的父視圖。RootView繼承了Handler類，能夠接收事件並分發，Android的全部觸屏事件、按鍵事件、界面刷新等事件都是經過ViewRoot進行分發的。博客
下面結構圖能夠清晰的揭示四者之間的關係：

10.0.1.2 吐司爲什麼會出現內存泄漏？在Toast構造方法中建立NT對象是幹什麼用的？Toast是怎麼show出來的？

吐司爲什麼會出現內存泄漏
- 緣由在於：若是在 Toast 消失以前，Toast 持有了當前 Activity，而此時，用戶點擊了返回鍵，致使 Activity 沒法被 GC 銷燬, 這個 Activity 就引發了內存泄露。
在Toast構造方法中建立NT對象是幹什麼用的？
- TN是屬於Toast內部一個私有靜態類，它是經過aidl進行通訊，主要做用是實現吐司的show和hide功能。
- 在構造方法中，建立了NT對象，那麼有人便會問，NT是什麼東西呢？看看NT的源碼，能夠發現NT實現了ITransientNotification.Stub，提到這個感受是否是很熟悉，沒錯，在aidl中就會用到這個。
```
public Toast(Context context) {
    mContext = context;
    mTN = new TN();
    mTN.mY = context.getResources().getDimensionPixelSize(
            com.android.internal.R.dimen.toast_y_offset);
    mTN.mGravity = context.getResources().getInteger(
            com.android.internal.R.integer.config_toastDefaultGravity);
}
```
- 在TN類中，能夠看到，實現了AIDL的show與hide方法
  - TN是Toast內部的一個私有靜態類，繼承自ITransientNotification.Stub，ITransientNotification.Stub是出如今服務端實現的Service中，就是一個Binder對象，也就是對一個aidl文件的實現而已
```
@Override
public void show(IBinder windowToken) {
    if (localLOGV) Log.v(TAG, "SHOW: " + this);
    mHandler.obtainMessage(0, windowToken).sendToTarget();
}

@Override
public void hide() {
    if (localLOGV) Log.v(TAG, "HIDE: " + this);
    mHandler.post(mHide);
}
```
- 接着看下這個ITransientNotification.aidl文件
```
/** @hide */
oneway interface ITransientNotification {
    void show();
    void hide();
}
```
Toast是怎麼show出來的？
- 經過AIDL（Binder）通訊拿到NotificationManagerService的服務訪問接口，而後把TN對象和一些參數傳遞到遠程NotificationManagerService中去
- 當 Toast在show的時候，而後把這個請求放在 NotificationManager 所管理的隊列中，而且爲了保證 NotificationManager 能跟進程交互，會傳遞一個TN類型的Binder對象給NotificationManager系統服
- 而後經過service.enqueueToast方法，record是將Toast封裝成ToastRecord對象，放入mToastQueue中。經過下面代碼能夠得知：經過isSystemToast判斷是否爲系統Toast。若是當前Toast所屬的進程的包名爲「android」，則爲系統Toast。若是是系統Toast必定能夠進入到系統Toast隊列中，不會被黑名單阻止。

10.0.1.3 連續吐司是如何肯定吐司的前後順序？爲何Toast執行show後過了一下子就自動銷燬？

連續吐司是如何肯定吐司的前後順序？
- 主要是說一下showNextToastLocked()方法中的源代碼
  - 首先獲取吐司消息隊列中第一個ToastRecord對象，而後判斷該對象若是不爲null的話，就開始經過callback進行show，且傳遞了token參數，注意這個show是通知進程顯示。而後再調用scheduleTimeoutLocked(record)方法執行超時後自動取消的邏輯。同時須要注意的時，若是出現了異常，則會從吐司消息隊列中移除該record……
  - 那麼callback是幹嗎的呢，通常印象中callback是處理回調的？從ITransientNotification callback得知，這個callback哥們居然是是一個 ITransientNotification 類型的對象，也就是前面說到的TN的Binder代理對象。
- 簡而言之，也就是說，TN中的消息機制也是經過handler進行實現的。在show方法中發送消息，當mHandler接受到消息以後，就調用handleShow(token)處理邏輯，經過WindowManager將view添加進來，同時在該方法中也設置了大量的佈局屬性。
爲何Toast執行show後過了一下子就自動銷燬？博客
- 回調了Toast的TN的show，當timeout可能就是hide呢。分析NotificationManagerService源碼中的showNextToastLocked()的scheduleTimeoutLocked(record)源碼，能夠知道在NotificationManagerService經過handler延遲delay時間發送消息，而後經過callback調用hide，因爲callback是TN中Binder的代理對象，因此即可以調用到TN中的hide方法達到銷燬吐司的目的。
- handleHide()源碼以下所示，可知當銷燬後先將view移除，而後在置空操做。
```
public void handleHide() {
    if (localLOGV) Log.v(TAG, "HANDLE HIDE: " + this + " mView=" + mView);
    if (mView != null) {
        // note: checking parent() just to make sure the view has
        // been added...  i have seen cases where we get here when
        // the view isn't yet added, so let's try not to crash.
        if (mView.getParent() != null) {
            if (localLOGV) Log.v(TAG, "REMOVE! " + mView + " in " + this);
            mWM.removeViewImmediate(mView);
        }

        mView = null;
    }
}
```

10.0.1.4 如何理解普通應用的Toast顯示數量是有限制的？爲何要判斷是不是系統吐司？爲什麼Activity銷燬後Toast仍會顯示？

如何理解普通應用的Toast顯示數量是有限制的？
- 如何判斷是不是系統吐司呢？若是當前Toast所屬的進程的包名爲「android」，則爲系統Toast，或者調用isCallerSystem()方法
```
final boolean isSystemToast = isCallerSystem() || ("android".equals(pkg));
```
- 接着看看isCallerSystem()方法源碼，isCallerSystem的源碼也比較簡單，就是判斷當前Toast所屬進程的uid是否爲SYSTEM_UID、0、PHONE_UID中的一個，若是是，則爲系統Toast;若是不是，則不爲系統Toast。
```
private static boolean isUidSystem(int uid) {
    final int appid = UserHandle.getAppId(uid);
    return (appid == Process.SYSTEM_UID || appid == Process.PHONE_UID || uid == 0);
}

private static boolean isCallerSystem() {
    return isUidSystem(Binder.getCallingUid());
}
```
爲何要判斷是不是系統吐司？
- 從源碼可知：首先系統Toast必定能夠進入到系統Toast隊列中，不會被黑名單阻止。而後系統Toast在系統Toast隊列中沒有數量限制，而普通pkg所發送的Toast在系統Toast隊列中有數量限制。
- 那麼關於數量限制這個結果從何而來，大概是多少呢？查看將要入隊的Toast是否已經在系統Toast隊列中。這是經過比對pkg和callback來實現的。經過下面源碼分析可知：只要Toast的pkg名稱和tn對象是一致的，則系統把這些Toast認爲是同一個Toast。
- 而後再看看下面這個源碼截圖，可知，非系統Toast，每一個pkg在當前mToastQueue中Toast有總數限制，不能超過MAX_PACKAGE_NOTIFICATIONS，也就是50
爲什麼Activity銷燬後Toast仍會顯示
- 記得之前昊哥問我，爲什麼toast在activity銷燬後仍然會彈出呢，我絕不思索地說，由於toast是系統級別的呀。那麼是如何實現的呢，我就無言以對呢……今天終於能夠回答呢！
- 仍是回到NotificationManagerService類中的enqueueToast方法中，直接查看keepProcessAliveIfNeededLocked(callingPid)方法。這段代碼的意思是將當前Toast所在進程設置爲前臺進程，這裏的mAm = ActivityManager.getService()，調用了setProcessImportant方法將當前pid的進程置爲前臺進程，保證不會系統殺死。這也就解釋了爲何當咱們finish當前Activity時，Toast還能夠顯示，由於當前進程還在執行。

10.0.1.5 爲何說Toast儘可能用全局上下文？說一下Toast的顯示和隱藏重點邏輯，說下你的理解？

爲何說Toast儘可能用全局上下文？
- 在使用Toast時context參數儘可能使用getApplicationContext()，能夠有效的防止靜態引用致使的內存泄漏。
- 有時候咱們會發現Toast彈出過多就會延遲顯示，由於上面源碼分析能夠看見Toast.makeText是一個靜態工廠方法，每次調用這個方法都會產生一個新的Toast對象，當咱們在這個新new的對象上調用show方法就會使這個對象加入到NotificationManagerService管理的mToastQueue消息顯示隊列裏排隊等候顯示；因此若是咱們不每次都產生一個新的Toast對象（使用單例來處理）就不須要排隊，也就能及時更新呢。
說一下Toast的顯示和隱藏重點邏輯，說下你的理解？博客
- Toast調用show方法，其實就是是將本身歸入到NotificationManager的Toast管理中去，期間傳遞了一個本地的TN類型或者是 ITransientNotification.Stub的Binder對象
- NotificationManager 收到 Toast 的顯示請求後，將生成一個 Binder 對象，將它做爲一個窗口的 token 添加到 WMS 對象，而且類型是 TOAST
- NotificationManager 將這個窗口token經過ITransientNotification的show方法傳遞給遠程的TN對象，而且拋出一個超時監聽消息 scheduleTimeoutLocked
- TN 對象收到消息之後將往 Handler 對象中 post 顯示消息，而後調用顯示處理函數將 Toast 中的 View 添加到了 WMS 管理中，Toast窗口顯示
- NotificationManager的WorkerHandler收到MESSAGE_TIMEOUT消息， NotificationManager遠程調用hide方法進程隱藏Toast 窗口，而後將窗口token從WMS中刪除，而且判斷吐司消息隊列中是否還有消息，若是有，則繼續吐司！

10.0.1.6 Toast報錯Unable to add window是什麼意思？Toast運行在子線程會問題，在子線程或者service中能運行嗎？

Toast偶爾報錯Unable to add window
- 報錯日誌，是否是有點眼熟呀？更多能夠看個人開源項目：https://github.com/yangchong211
```
android.view.WindowManager$BadTokenException
    Unable to add window -- token android.os.BinderProxy@7f652b2 is not valid; is your activity running?
```
- 查詢報錯日誌是從哪裏來的
- 發生該異常的緣由
  - 這個異常發生在Toast顯示的時候，緣由是由於token失效。一般狀況下，通常是不會出現這種異常。可是因爲在某些狀況下， Android進程某個UI線程的某個消息阻塞。致使 TN 的 show 方法 post 出來 0 (顯示) 消息位於該消息以後，遲遲沒有執行。這時候，NotificationManager 的超時檢測結束，刪除了 WMS 服務中的 token 記錄。刪除 token 發生在 Android 進程 show 方法以前。這就致使了上面的異常。
  - 測試代碼。模擬一下異常的發生場景，其實很容易，只須要這樣作就能夠出現上面這個問題
```
Toast.makeText(this，"瀟湘劍雨-yc"，Toast.LENGTH_SHORT).show();
    try {
        Thread.sleep(20000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
```
- 解決辦法，目前見過好幾種，思考一下那種比較好……
  - 第一種，既然是報is your activity running，那能夠不能夠在吐司以前先判斷一下activity是否running呢？
  - 第二種，拋出異常增長try-catch，代碼以下所示，最後仍然沒法解決問題
    - 按照源碼分析，異常是發生在下一個UI線程消息中，所以在上一個ui線程消息中加入try-catch是沒有意義的。並且用到吐司地方這麼多，這樣作也不方便啦！
  - 第三種，那就是自定義相似吐司Toast的view控件。我的建議除非要求很是高，否則不要這樣作。畢竟發生這種異常仍是比較少見的
- 哪些狀況會發生該問題？
  - UI 線程執行了一條很是耗時的操做，好比加載圖片等等，就相似上面用 sleep 模擬狀況
  - 進程退後臺或者息屏了，系統爲了減小電量或者某種緣由，分配給進程的cpu時間減小,致使進程內的指令並不能被及時執行，這樣同樣會致使進程看起來」卡頓」的現象
  - 當TN拋出消息的時候，前面有大量的 UI 線程消息等待執行，而每一個 UI 線程消息雖然並不卡頓，可是總和若是超過了 NotificationManager 的超時時間，仍是會出現問題

Toast運行在子線程問題

先來看看問題代碼，會出現什麼問題呢？

new Thread(new Runnable() {
    @Override
    public void run() {
        ToastUtils.showRoundRectToast("瀟湘劍雨-楊充");
    }
}).start();

報錯日誌以下所示：

子線程中吐司的正確作法，代碼以下所示

new Thread(new Runnable() {
    @Override
    public void run() {
        Looper.prepare();
        ToastUtils.showRoundRectToast("瀟湘劍雨-楊充");
        Looper.loop();
    }
}).start();

得出的結論
- Toast也能夠在子線程執行，不過須要手動提供Looper環境的。
- Toast在調用show方法顯示的時候，內部實現是經過Handler執行的，所以天然是不阻塞Binder線程，另外，若是addView的線程不是Loop線程，執行完就結束了，固然就沒機會執行後續的請求，這個是由Hanlder的構造函數保證的。能夠看看handler的構造函數，若是Looper==null就會報錯，而Toast對象在實例化的時候，也會爲本身實例化一個Hanlder，這就是爲何說「必定要在主線程」，其實準確的說應該是「必定要在Looper非空的線程」。博客

10.0.1.7 爲何建議用DialogFragment替代Dialog？如何定義DialogFragment樣式？使用dialogFragment有何好處？

爲何建議用DialogFragment替代Dialog
- Android比較推薦採用DialogFragment實現對話框，它徹底可以實現Dialog的全部需求，而且還能複用Fragment的生命週期管理，被後臺殺死後，能夠恢復重建。
- 在手機配置變化致使 Activity 須要從新建立時，例如旋轉屏幕，基於 DialogFragment 的對話框將會由 FragmentManager 自動重建，然而基於 Dialog 實現的對話框卻沒有這樣的能力。

如何定義DialogFragment樣式

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    if (local == BOTTOM) {
        setStyle(DialogFragment.STYLE_NO_TITLE, R.style.BottomDialog);
    } else if (local == CENTER || local == TOP) {
        setStyle(DialogFragment.STYLE_NO_TITLE, R.style.CenterDialog);
    }
}

建立theme主題樣式，而且進行設置

設置樣式，以DialogFragment爲例，只須要在onCreate中setStyle(DialogFragment.STYLE_NO_TITLE, R.style.CenterDialog)便可。
注意，CenterDialog中能夠設置彈窗的動畫效果。

注意一下style常量，這裏只是展現經常使用的。

STYLE_NORMAL：會顯示一個普通的dialog
STYLE_NO_TITLE：不帶標題的dialog
STYLE_NO_FRAME：無框的dialog
STYLE_NO_INPUT：沒法輸入內容的dialog，即不接收輸入的焦點，並且觸摸無效。

注意動畫設置以下所示

<style name="CenterDialog" parent="@android:style/Theme.Dialog">
    <item name="android:windowTitleStyle">@null</item>
    <item name="android:windowBackground">@android:color/transparent</item>
    <item name="android:colorBackgroundCacheHint">@null</item>
    <item name="android:windowAnimationStyle">@style/CenterDialogAnimationStyle</item>
    <item name="android:windowSoftInputMode">stateUnspecified|adjustPan</item>
</style>

使用dialogFragment有何好處？
- DialogFragment是繼承Fragment，具備Fragment的生命週期，本質上說就是Fragment，只是其內部還有一個dialog而已。你既能夠當它是Dialog使用，也能夠把它做爲Fragment使用。
- onCreateView能夠加載客戶化更高的對話框，onCreateDialog加載系統AlertDialog類型對話框比較合適。
- DialogFragmnet對話框橫屏時對話框不會關閉，由於DailogFragment有Fragment屬性，會在屏幕發生變化時從新建立DialogFragment。博客
- setStyle的調用點，要放在onCreateView前，通常是放在onCreat方法中執行，不然，設置的style和theme將不起做用！setStyle中，style的參數是不能夠相互一塊兒使用的，只能用一個，若是還不知足你使用，能夠經過設置theme來知足。

10.0.1.8 Dialog的Window建立過程是怎樣的？爲何Dialog不能用Application的Context，說一下緣由？

Dialog的Window建立過程是怎樣的?
- 建立Window——一樣是經過PolicyManager的makeNewWindow方法完成，與Activity建立過程一致
- 初始化DecorView並將Dialog的視圖添加到DecorView中——和Activity一致(setContentView)
- 將DecorView添加到Window中並顯示——在Dialog的show方法中，經過WindowManager將DecorView添加到Window中(mWindowManager.addView(mDecor, 1))
- Dialog關閉時會經過WindowManager來移除DecorView：mWindowManager.removeViewImmediate(mDecor)
- Dialog必須採用Activity的Context，由於有應用token(Application的Context沒有應用token)，也能夠將Dialog的Window經過type設置爲系統Window就再也不須要token。
爲何Dialog不能用Application的Context，說一下緣由？
- Dialog自己的Token爲null，在初始化時若是是使用Application或者Service的Context，在獲取到WindowManager時，獲取到的token依然是null。
- Dialog若是採用Activity的Context，獲取到的WindowManager是在activity.attach()方法中建立，token指向了activity的token。
- 由於經過Application和Service的Context將沒法獲取到Token從而致使失敗。

10.0.1.9 Dialog和Window有什麼關係？Dialog的dismiss和cancel()方法均可銷燬彈窗，它們有什麼區別？

Dialog和Window有什麼關係？

看源碼可知在Dialog的構造方法中直接直接構造了一個PhoneWindow，並賦值給Dialog的成員變量mWindow，從這裏能夠看出其實Dialog和Activity的顯示邏輯都是相似的，都是經過對應的Window變量來實現窗口的加載與顯示的。而後咱們執行了一些Window對象的初始化操做，好比設置回調函數爲自己，而後調用Window類的setWindowManager方法，並傳入了WindowManager。而後建立一個對話框監聽handler對象。

Dialog(@NonNull Context context, @StyleRes int themeResId, boolean createContextThemeWrapper) {
    if (createContextThemeWrapper) {
        if (themeResId == 0) {
            final TypedValue outValue = new TypedValue();
            context.getTheme().resolveAttribute(R.attr.dialogTheme, outValue, true);
            themeResId = outValue.resourceId;
        }
        //建立一個Context
        mContext = new ContextThemeWrapper(context, themeResId);
    } else {
        mContext = context;
    }

    //獲取一個WindowManager對象
    mWindowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
    //建立一個Window對象
    final Window w = new PhoneWindow(mContext);
    //將Window對象w賦值給mWindow
    mWindow = w;
    //爲Windowd對象設置回調，而且它自己實現了這些回調函數
    w.setCallback(this);
    w.setOnWindowDismissedCallback(this);
    //爲Window對象設置WindowManager對象
    w.setWindowManager(mWindowManager, null, null);
    w.setGravity(Gravity.CENTER);
    //建立一個對話框監聽Handler
    mListenersHandler = new ListenersHandler(this);
}

Dialog的dismiss和cancel()方法均可銷燬彈窗，它們有什麼區別？

調用alertDialog.cancel()或者alertDialog.dismiss()均可以達到銷燬彈窗的效果。
若是沒有設置setOnCancelListener事件，則兩個方法是等效的。爲何這樣說呢？
首先看一下Dialog的cannel方法的具體實現：能夠看到方法體中，若當前Dialog沒有取消，而且設置了取消message，則調用Message.obtain(mCancelMessage).sendToTarget()。而這個mCancelMessage則是在setOnCancelListener方法中建立的。調用的是設置的OnCancelListener的onCancel方法，也就是說調用dialog.cancel方法時首先會判斷dialog是否調用了setOnCancelListener若設置了，則先調用OnCancelListener的onCancel方法，而後再次執行dismiss方法，若咱們沒有爲Dialog.Builder設置OnCancelListener那麼cancel方法和dismiss方法是等效的。博客

public void cancel() {
    if (!mCanceled && mCancelMessage != null) {
        mCanceled = true;
        // Obtain a new message so this dialog can be re-used
        Message.obtain(mCancelMessage).sendToTarget();
    }
    dismiss();
}

public void setOnCancelListener(final OnCancelListener listener) {
    if (listener != null) {
        mCancelMessage = mListenersHandler.obtainMessage(CANCEL, listener);
    } else {
        mCancelMessage = null;
    }
}

private static final class ListenersHandler extends Handler {
    private WeakReference<DialogInterface> mDialog;

    public ListenersHandler(Dialog dialog) {
        mDialog = new WeakReference<DialogInterface>(dialog);
    }

    @Override
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case DISMISS:
                ((OnDismissListener) msg.obj).onDismiss(mDialog.get());
                break;
            case CANCEL:
                ((OnCancelListener) msg.obj).onCancel(mDialog.get());
                break;
            case SHOW:
                ((OnShowListener) msg.obj).onShow(mDialog.get());
                break;
        }
    }
}

dismiss方法主要是作了什麼？
- 能夠看到，這裏首先判斷當前線程的Looper是不是主線程的Looper（因爲mHandler是在主線程中建立的，因此mHandler.getLooper返回的是主線程中建立的Looper對象），如果的話，則直接執行dismissDialog()方法，不然的話，經過mHandler發送異步消息至主線程中，簡單來講就是判斷當前線程是不是主線程，如果主線程則執行dismissDialog方法不然發送異步消息。而這裏的異步消息最終也是調用的dismissDialog方法
```
public void dismiss() {
    if (Looper.myLooper() == mHandler.getLooper()) {
        dismissDialog();
    } else {
        mHandler.post(mDismissAction);
    }
}
```

10.0.2.0 PopupWindow中不設置爲何必須設置寬高？PopupWindow和Dialog有什麼區別？說下建立和銷燬的大概流程？

PopupWindow中不設置爲何必須設置寬高？
- 先看問題代碼，下面這個不會出現彈窗，思考：爲何？
```
PopupWindow popupWindow = new PopupWindow(this);
View inflate = LayoutInflater.from(this).inflate(R.layout.view_pop_custom, null);
popupWindow.setContentView(inflate);
popupWindow.setAnimationStyle(R.style.BottomDialog);
popupWindow.showAsDropDown(mTv1);
```
- 注意：必須設置寬和高，不然不顯示任何東西
  - 這裏的WRAP_CONTENT能夠換成fill_parent 也能夠是具體的數值，它是指PopupWindow的大小，也就是contentview的大小，注意popupwindow根據這個大小顯示你的View，若是你的View自己是從xml獲得的，那麼xml的第一層view的大小屬性將被忽略。至關於popupWindow的width和height屬性直接和第一層View相對應。
PopupWindow和Dialog有什麼區別？
- 二者最根本的區別在於有沒有新建一個window，PopupWindow沒有新建，而是將view加到DecorView；Dialog是新建了一個window，至關於走了一遍Activity中建立window的流程
- 從源碼中能夠看出，PopupWindow最終是執行了mWindowManager.addView方法，全程沒有新建window
說下建立和銷燬的大概流程？
- 建立PopupWindow的時候，先建立WindowManager，由於WIndowManager擁有控制view的添加和刪除、修改的能力。這一點關於任主席的藝術探索書上寫的很詳細……博客
- 而後是setContentView，保存contentView，這個步驟就作了這個
- 顯示PopupWindow，這個步驟稍微複雜點，建立並初始化LayoutParams，設置相關參數，做爲之後PopupWindow在應用DecorView裏哪裏顯示的憑據。而後建立PopupView，而且將contentView插入其中。最後使用WindowManager將PopupView添加到應用DecorView裏。
- 銷燬PopupView，WindowManager把PopupView移除，PopupView再把contentView移除，最後把對象置爲null
爲什麼彈窗點擊一下就dismiss呢？
- PopupWindow經過爲傳入的View添加一層包裹的佈局，並重寫該佈局的點擊事件，實現點擊PopupWindow以外的區域PopupWindow消失的效果

10.0.2.1 Snackbar與吐司有何區別在哪裏？Snackbar控件show時爲什麼從下往上移出來？爲何顯示在最下面？

Snackbar與吐司有何區別
- 與Toast進行比較，SnackBar有優點：
- 1.SnackBar能夠自動消失，也能夠手動取消(側滑取消，可是須要在特殊的佈局中，後面會仔細說)
- 2.SnackBar能夠經過setAction（）來與用戶進行交互
- 3.經過CallBack咱們能夠獲取SnackBar的狀態
Snackbar控件show時爲什麼從下往上移出來？
- 至於說Snackbar控件show時爲什麼從下往上移出來，看下面這段代碼就知道呢，以下所示
爲何顯示在最下面？
- 直接找到make方法中的填充佈局，而後去看design_layout_snackbar_include的佈局參數，結果以下：
Snackbar顯示會致使FloatingActionButton上移？
- 爲何CoordinatorLayout + FloatingActionButton，當Snackbar顯示的時候FloatingActionButton會上移呢，這個是怎麼實現的？
- 把CoordinatorLayout替換成FrameLayout確不行。這個問題咱們還沒說。其實這個不是在Snackbar裏面處理的，是經過CoordinatorLayout和Behavior來處理的。那具體的處理在哪裏呢。FloatingActionButton類裏面Behavior類。正是Behavior裏面的兩個函數layoutDependsOn()和onDependentViewChanged()函數做用的結果。直接進去看下FloatingActionButton內部類Behavior裏面這兩個函數的代碼。

10.0.2.2 說一下Snackbar和SnackbarManager類的設計有哪些奧妙的地方，如何處理消息的顯示順序？

Snackbar和SnackbarManager，SnackbarManager內部有兩個SnackbarRecord，一個mCurrentSnackbar，一個mNextSnackbar，SnackbarManager經過這兩個對象實現Snackbar的順序顯示，若是在一個Snackbar顯示以前有Snackbar正在顯示，那麼使用mNextSnackbar保存第二個Snackbar，而後讓第一個Snackbar消失，而後消失以後再調用SnackbarManager顯示下一個Snackbar，如此循環，實現了Snackbar的順序顯示。博客
Snackbar負責顯示和消失，具體來講其實就是添加和移除View的過程。Snackbar和SnackbarManager的設計很巧妙，利用一個SnackbarRecord對象保存Snackbar的顯示時間以及SnackbarManager.Callback對象，前面說到每個Snackbar都有一個叫作mManagerCallback的SnackbarManager.Callback對象，下面看一下SnackRecord類的定義：
Snackbar向SnackbarManager發送消息主要是調用SnackbarManager.getInstace()返回一個單例對象；而SnackManager向Snackbar發送消息就是經過show方法傳入的Callback對象。SnackbarManager中的Handler只處理一個MSG_TIMEOUT事件，最後是調用Snackbar的hideView消失的；Snackbar的sHandler處理兩個消息，showView和hideView，而消息的發送者是mManagerCallback，控制者是SnackbarManager。