Toast源碼深度分析

時間 2020-01-24

標籤 toast 源碼深度分析简体版

原文原文鏈接

目錄介紹

1.最簡單的建立方法
- 1.1 Toast構造方法
- 1.2 最簡單的建立
- 1.3 簡單改造避免重複建立
- 1.4 爲什麼會出現內存泄漏
- 1.5 吐司是系統級別的
2.源碼分析
- 2.1 Toast(Context context)構造方法源碼分析
- 2.2 show()方法源碼分析
- 2.3 mParams.token = windowToken是幹什麼用的
- 2.4 scheduleTimeoutLocked吐司如何自動銷燬的
- 2.5 TN類中的消息機制
- 2.6 普通應用的Toast顯示數量是有限制的
- 2.7 爲什麼Activity銷燬後Toast仍會顯示
3.經典總結
- 3.1 判斷應用程序獲取通知權限是否開啓
- 3.2 使用Toast注意事項
- 3.3 Toast的顯示和隱藏重點邏輯
- 3.4 Snackbar和Toast比較
4.Toast封裝庫介紹
- 4.1 可以知足的需求
- 4.2 具備的優點
5.Toast遇到的問題
- 5.1 Toast偶爾報錯Unable to add window
- 5.2 Toast運行在子線程問題
- 5.3 Toast如何添加系統窗口的權限
- 5.4 token null is not valid

好消息

博客筆記大彙總【16年3月到至今】，包括Java基礎及深刻知識點，Android技術博客，Python學習筆記等等，還包括平時開發中遇到的bug彙總，固然也在工做之餘收集了大量的面試題，長期更新維護而且修正，持續完善……開源的文件是markdown格式的！同時也開源了生活博客，從12年起，積累共計47篇[近20萬字]，轉載請註明出處，謝謝！
連接地址：https://github.com/yangchong211/YCBlogs
若是以爲好，能夠star一下，謝謝！固然也歡迎提出建議，萬事起於忽微，量變引發質變！
Toast封裝庫項目地址：https://github.com/yangchong211/YCDialog
02.Toast源碼深度分析
- 最簡單的建立，簡單改造避免重複建立，show()方法源碼分析，scheduleTimeoutLocked吐司如何自動銷燬的，TN類中的消息機制是如何執行的，普通應用的Toast顯示數量是有限制的，用代碼解釋爲什麼Activity銷燬後Toast仍會顯示，Toast偶爾報錯Unable to add window是如何產生的，Toast運行在子線程問題，Toast如何添加系統窗口的權限等等
03.DialogFragment源碼分析
- 最簡單的使用方法，onCreate(@Nullable Bundle savedInstanceState)源碼分析，重點分析彈窗展現和銷燬源碼，使用中show()方法遇到的IllegalStateException分析
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運行在子線程致使崩潰如何解決？

1.最簡單的建立方法

1.1 Toast構造方法

Toast只會彈出一段信息，告訴用戶某某事情已經發生了，過一段時間後就會自動消失。它不會阻擋用戶的任何操做。

Toast是沒有焦點，並且Toast顯示的時間有限，過必定的時間就會自動消失。

經過new Toast(context)直接建立，除了將mContext = context，還有一步重要的操做，建立TN，下面會說到……

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);
}

1.2 最簡單的建立

一行代碼調用，十分方便，可是這樣存在一種弊端。
- 使用中遇到的問題：例如，當點擊有些按鈕，須要吐司進行提示時；快速連續點擊了屢次按鈕，Toast就觸發了屢次。系統會將這些Toast信息提示框放到隊列中，等前一個Toast信息提示框關閉後纔會顯示下一個Toast信息提示框。可能致使Toast就長時間關閉不掉了。又或者咱們其實已在進行其餘操做了，應該彈出新的Toast提示，而上一個Toast卻還沒顯示結束
```
Toast.makeText(this,"吐司",Toast.LENGTH_SHORT).show();
```

1.3 簡單改造避免重複建立

爲了解決1.2中的重複建立問題，則能夠這樣解決

以下所示，簡易型代碼，須要注意問題，這裏傳遞的上下文context須要是activity.getApplicationContext()全局上下文，避免靜態toast對象內存泄漏

/**
* 吐司工具類    避免點擊屢次致使吐司屢次，最後致使Toast就長時間關閉不掉了
* 注意：這裏若是傳入context會報內存泄漏；傳遞activity..getApplicationContext()
* @param content       吐司內容
*/
private static Toast toast;
@SuppressLint("ShowToast")
public static void showToast(String content) {
checkContext();
if (toast == null) {
    toast = Toast.makeText(mApp, content, Toast.LENGTH_SHORT);
} else {
    toast.setText(content);
}
toast.show();
}

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

1.4 爲什麼會出現內存泄漏

緣由在於：若是在 Toast 消失以前，Toast 持有了當前 Activity，而此時，用戶點擊了返回鍵，致使 Activity 沒法被 GC 銷燬, 這個 Activity 就引發了內存泄露。

1.5 吐司是系統級別的

常常看到的一個場景就是你在你的應用出調用了屢次 Toast.show函數，而後退回到桌面，結果發現桌面也會彈出 Toast，就是由於系統的 Toast 使用了系統窗口，具備高的層級

2.源碼分析

2.1 Toast(Context context)構造方法源碼分析

在構造方法中，建立了NT對象，那麼有人便會問，NT是什麼東西呢？因而帶着好奇心便去看看NT的源碼，能夠發現NT實現了ITransientNotification.Stub，提到這個感受是否是很熟悉，沒錯，在aidl中就會用到這個。
- 針對aidl，若是有人不明白，能夠參考個人這邊文章Aidl進程間通訊詳細介紹主要是Aidl相關屬性介紹，實際開發中案例操做，部分源碼解析，客戶端綁定服務端service原理
```
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方法php
- TN是Toast內部的一個私有靜態類，繼承自ITransientNotification.Stub，ITransientNotification.Stub是出如今服務端實現的Service中，就是一個Binder對象，也就是對一個aidl文件的實現而已
```
/**
* schedule handleShow into the right thread
*/
@Override
public void show(IBinder windowToken) {
if (localLOGV) Log.v(TAG, "SHOW: " + this);
mHandler.obtainMessage(0, windowToken).sendToTarget();
}
```
/**android
- schedule handleHide into the right threadbr/>*/
  @Override
  public void hide() {
  if (localLOGV) Log.v(TAG, "HIDE: " + this);
  mHandler.post(mHide);
  }

接着看下這個ITransientNotification.aidl文件

/** @hide */
oneway interface ITransientNotification {
    void show();
    void hide();
}

2.2 show()方法源碼分析

經過AIDL（Binder）通訊拿到NotificationManagerService的服務訪問接口，而後把TN對象和一些參數傳遞到遠程NotificationManagerService中去git

當 Toast在show的時候，而後把這個請求放在 NotificationManager 所管理的隊列中，而且爲了保證 NotificationManager 能跟進程交互，會傳遞一個TN類型的 Binder對象給NotificationManager系統服務，接着看下面getService方法作了什麼？程序員

public void show() {
if (mNextView == null) {
    throw new RuntimeException("setView must have been called");
}

//經過AIDL（Binder）通訊拿到NotificationManagerService的服務訪問接口，當前Toast類至關於上面例子的客戶端！！！至關重要！！！
INotificationManager service = getService();
String pkg = mContext.getOpPackageName();
TN tn = mTN;
tn.mNextView = mNextView;

try {
    //把TN對象和一些參數傳遞到遠程NotificationManagerService中去
    service.enqueueToast(pkg, tn, mDuration);
} catch (RemoteException e) {
    // Empty
}
}

接着看看getService方法

經過單利模式獲取sService對象。

//遠程NotificationManagerService的服務訪問接口
private static INotificationManager sService;
static private INotificationManager getService() {
//單例模式
if (sService != null) {
    return sService;
}
//經過AIDL（Binder）通訊拿到NotificationManagerService的服務訪問接口
sService = INotificationManager.Stub.asInterface(ServiceManager.getService("notification"));
return sService;
}

接下來看看service.enqueueToast(pkg, tn, mDuration)這段代碼，相信有的小夥伴會質疑，這段代碼報紅色，如何查看呢？

因而，我直接在studio中全局搜索NotificationManagerService，終於給找到了，以下所示：

下面就到重點呢……注意：record是將Toast封裝成ToastRecord對象，放入mToastQueue中。經過下面代碼能夠得知：經過isSystemToast判斷是否爲系統Toast。若是當前Toast所屬的進程的包名爲「android」，則爲系統Toast。若是是系統Toast必定能夠進入到系統Toast隊列中，不會被黑名單阻止。

synchronized (mToastQueue) {
int callingPid = Binder.getCallingPid();
long callingId = Binder.clearCallingIdentity();
try {
    ToastRecord record;
    int index;
    //判斷是不是系統級別的吐司
    if (!isSystemToast) {
        index = indexOfToastPackageLocked(pkg);
    } else {
        index = indexOfToastLocked(pkg, callback);
    }
    if (index >= 0) {
        record = mToastQueue.get(index);
        record.update(duration);
        record.update(callback);
    } else {
        //建立一個Binder類型的token對象
        Binder token = new Binder();
        //生成一個Toast窗口，而且傳遞token等參數
        mWindowManagerInternal.addWindowToken(token, TYPE_TOAST, DEFAULT_DISPLAY);
        record = new ToastRecord(callingPid, pkg, callback, duration, token);
        //添加到吐司隊列之中
        mToastQueue.add(record);
        //對當前索引從新進行賦值
        index = mToastQueue.size() - 1;
    }
    //將當前Toast所在的進程設置爲前臺進程
    keepProcessAliveIfNeededLocked(callingPid);
    if (index == 0) {
        //若是index爲0,說明當前入隊的Toast在隊頭，須要調用showNextToastLocked方法直接顯示
        showNextToastLocked();
    }
} finally {
    Binder.restoreCallingIdentity(callingId);
}
}

接下來看一下showNextToastLocked()方法中的源代碼，看看這個方法中作了什麼……
- 首先獲取吐司消息隊列中第一個ToastRecord對象，而後判斷該對象若是不爲null的話，就開始經過callback進行show，且傳遞了token參數，注意這個show是通知進程顯示。而後再調用scheduleTimeoutLocked(record)方法執行超時後自動取消的邏輯【下面詳細分析】。同時須要注意的時，若是出現了異常，則會從吐司消息隊列中移除該record……
- 那麼callback是幹嗎的呢，通常印象中callback是處理回調的？從ITransientNotification callback得知，這個callback哥們居然是是一個 ITransientNotification 類型的對象，也就是前面說到的TN的Binder代理對象，那麼他傳遞的這個token參數是幹什麼用的呢？這裏咱們程序員小夥伴能夠接着往下看哈！

2.3 mParams.token = windowToken是幹什麼用的

若是你仔細一點，你能夠看到在handleShow(IBinder windowToken)這個方法中，將windowToken賦值給mParams.token，那麼就會思考這個token是幹什麼用的呢？它是哪裏傳遞過來的呢？
- 這個所須要的這個系統窗口 token ，是由咱們的 NotificationManager 系統服務所生成，因爲系統服務具備高權限，果然是厲害呀。
- 上文2.3中我已經分析了showNextToastLocked()方法部分源碼record.callback.show(record.token)，能夠知道callback對象的show方法中須要傳遞的參數 record.token實際上就是上面所說的NotificationManager服務所生成的窗口的 token。
這個顯示窗口的方法比較簡單，就是將所傳遞過來的窗口 token 賦值給窗口屬性對象 mParams，而後經過調用 WindowManager.addView 方法，將 Toast中的mView對象歸入WindowManager中，而WindowManager看源碼可知是一個接口，具體是放在WindowManagerService中處理。

2.4 scheduleTimeoutLocked吐司如何自動銷燬的

接下來再來看看scheduleTimeoutLocked(record)這部分代碼，這個主要是超時監聽消息邏輯
- 經過看這段代碼知道，handler延遲delay時間後發送消息，而且這個delay時間只有原生自帶的兩種時間類型，沒法開發者本身定義。
既然發送了消息，那確定有地方接收消息而且處理消息呀。接着看下面代碼，重點看cancelToastLocked源碼！
- 能夠看到當接收到消息時，先判斷是否吐司，若是是有的話，也就是索引index>=0，那麼就去cancel，在cancelToastLocked(int index)這段源碼裏面，咱們終於能夠看到record.callback.hide()這個方法了，前面咱們知道callback是前面提到TN的binder代理對象，因此這個方法是調用了TN類中的hide()方法，下面2.5中將詳細講解TN中的消息機制。
- 同時結束吐司以後，移除消息隊列中對象，同時判斷吐司消息隊列中是否還有剩下的消息，若是是有的話，則會接着調用showNextToastLocked()繼續彈吐司，關於showNextToastLocked()能夠看2.3中的源碼分析。
cancelToastLocked源碼邏輯主要是
- 調用 ITransientNotification.hide 方法，通知客戶端隱藏窗口，而且移除隊列中對象
- 將給Toast 生成的窗口Token從WMS 服務中刪除
- 判斷吐司消息隊列中是否存在消息，若是存在消息，則繼續開始show吐司……

2.5 TN類中的消息機制

看源碼可知，TN中的消息機制也是經過handler消息機制實現的。若是對handler 消息機制還不太熟悉，能夠查看個人這篇博客：Handler消息機制
當建立TN對象的時候，就建立了handler和runnable對象。
- 而後看看show與hide方法，在show方法中發送消息，當mHandler接受到消息以後，就調用handleShow(token)處理邏輯，經過WindowManager將view添加進來，同時在該方法中也設置了大量的佈局屬性。
- 在把Toast的View添加以前發現Toast的View已經被添加過（有partent）則刪掉；把Toast的View添加到窗口，其中mParams.type在構造函數中賦值爲TYPE_TOAST！
同時，當toast執行show以後，過了一下子會自動銷燬，那麼這又是爲啥呢？那麼是哪裏調用了hide方法呢？github
- 回調了Toast的TN的show，當timeout可能就是hide呢。從上面我分析NotificationManagerService源碼中的showNextToastLocked()的scheduleTimeoutLocked(record)源碼，能夠知道在NotificationManagerService經過handler延遲delay時間發送消息，而後經過callback調用hide，因爲callback是TN中Binder的代理對象，因此即可以調用到TN中的hide方法達到銷燬吐司的目的。handleHide()源碼以下所示面試
```
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;
}
}
```

2.6 普通應用的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

2.7 爲什麼Activity銷燬後Toast仍會顯示

記得之前昊哥問我，爲什麼toast在activity銷燬後仍然會彈出呢，我絕不思索地說，由於toast是系統級別的呀。那麼是如何實現的呢，我就無言以對呢……今天終於能夠回答呢！
- 仍是回到NotificationManagerService類中的enqueueToast方法中，直接查看keepProcessAliveIfNeededLocked(callingPid)方法。這段代碼的意思是將當前Toast所在進程設置爲前臺進程，這裏的mAm = ActivityManager.getService()，調用了setProcessImportant方法將當前pid的進程置爲前臺進程，保證不會系統殺死。這也就解釋了爲何當咱們finish當前Activity時，Toast還能夠顯示，由於當前進程還在執行。

3.經典總結

3.1 判斷應用程序獲取通知權限是否開啓

一行代碼調用便可：DialogUtils.requestMsgPermission(this);
大部分手機通知權限是開啓的。若是關閉了，則吐司是沒法顯示的，可是仍有部分手機，好比某型號小米手機，錘子手機等就權限須要手動開啓。
Toast的展現是由NMS服務控制的，NMS服務會作一些權限、token等的校驗，當通知權限一旦關閉，Toast將再也不彈出。
具體能夠參考個人彈窗封裝庫：https://github.com/yangchong211/YCDialogsegmentfault
- 自定義對話框，其中包括：自定義Toast，採用builder模式，支持設置吐司多個屬性；自定義dialog控件，仿IOS底部彈窗；自定義DialogFragment彈窗，支持自定義佈局，也支持填充recyclerView佈局；自定義PopupWindow彈窗，輕量級，還有自定義Snackbar等等；還有自定義loading加載窗，簡單便用。
```
//判斷是否有權限
NotificationManagerCompat.from(context).areNotificationsEnabled()
```
//若是沒有通知權限，則直接跳轉設置中心設置br/>@SuppressLint("ObsoleteSdkInt")
private static void toSetting(Context context) {
Intent localIntent = new Intent();
localIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
if (Build.VERSION.SDK_INT >= 9) {
localIntent.setAction("android.settings.APPLICATION_DETAILS_SETTINGS");
localIntent.setData(Uri.fromParts("package", context.getPackageName(), null));
} else if (Build.VERSION.SDK_INT <= 8) {
localIntent.setAction(Intent.ACTION_VIEW);
localIntent.setClassName("com.android.settings",
"com.android.setting.InstalledAppDetails");
localIntent.putExtra("com.android.settings.ApplicationPkgName", context.getPackageName());
}
context.startActivity(localIntent);
}markdown

3.2 使用Toast注意事項

經過分析TN類的handler能夠發現，若是想在非UI線程使用Toast須要自行聲明Looper，不然運行會拋出Looper相關的異常；UI線程不須要，由於系統已經幫忙聲明。
在使用Toast時context參數儘可能使用getApplicationContext()，能夠有效的防止靜態引用致使的內存泄漏。
有時候咱們會發現Toast彈出過多就會延遲顯示，由於上面源碼分析能夠看見Toast.makeText是一個靜態工廠方法，每次調用這個方法都會產生一個新的Toast對象，當咱們在這個新new的對象上調用show方法就會使這個對象加入到NotificationManagerService管理的mToastQueue消息顯示隊列裏排隊等候顯示；因此若是咱們不每次都產生一個新的Toast對象（使用單例來處理）就不須要排隊，也就能及時更新呢。

3.3 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中刪除，而且判斷吐司消息隊列中是否還有消息，若是有，則繼續吐司！

3.4 Snackbar和Toast比較

可使用snackBar替代Toast，即便用戶禁掉了通知權限，也能夠顯示出來。SnackBar，其實就是使用View系統去模擬一個窗口行爲，並且還能更加快速的實現動畫效果，是否是很棒。
Snackbar是Android自5.0系統推出MaterialDesign後官方推薦的控件，在交互友好性方面比Toast要好

4.Toast封裝庫介紹

4.1 可以知足的需求

能夠設置吐司的位置，偏移，吐司文字顏色，吐司背景顏色等等。簡單的代碼就能夠實現你須要的多種場景。也能夠設置定義佈局的吐司。項目地址：https://github.com/yangchong211/YCDialog

4.2 具備的優點

採用builder構造者模式，鏈式編程，一行代碼調用便可設置吐司Toast。

爲了不靜態toast對象內存泄漏，固可使用應用級別的上下文context。因此這裏我就直接採用了應用級別Application上下文，須要在application進行初始化一下。便可調用……app

//初始化
ToastUtils.init(this);

//能夠自由設置吐司的背景顏色，默認是純黑色
ToastUtils.setToastBackColor(this.getResources().getColor(R.color.color_7f000000));

//直接設置最簡單吐司，只有吐司內容
ToastUtils.showRoundRectToast("自定義吐司");

//設置吐司標題和內容
ToastUtils.showRoundRectToast("吐司一下","他發的撒經濟法的解放軍");

//第三種直接設置自定義佈局的吐司
ToastUtils.showRoundRectToast(R.layout.view_layout_toast_delete);

//或者直接採用bulider模式建立
ToastUtils.Builder builder = new ToastUtils.Builder(this.getApplication());
builder
        .setDuration(Toast.LENGTH_SHORT)
        .setFill(false)
        .setGravity(Gravity.CENTER)
        .setOffset(0)
        .setDesc("內容內容")
        .setTitle("標題")
        .setTextColor(Color.WHITE)
        .setBackgroundColor(this.getResources().getColor(R.color.blackText))
        .build()
        .show();

由於看到網上有許多toast的封裝，須要傳遞上下文，後來感受是否是不須要傳遞這個參數，直接統一初始化一下就好呢。因此纔有了這個toast的改良版。
- 若是沒有調用ToastUtils.init(this)初始化，則會提示報錯ToastUtils context is not null，please first init",具體看下面代碼。
```
/**
* 檢查上下文不能爲空，必須先進性初始化操做
*/
private static void checkContext(){
if(mApp==null){
    throw new NullPointerException("ToastUtils context is not null，please first init");
}
}
```

5.Toast遇到的異常問題

5.1 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 的超時時間，仍是會出現問題

5.2 Toast運行在子線程問題

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

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

報錯日誌以下所示：

而後找找報錯日誌從哪裏來的
- ![image]()

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

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非空的線程」。
- Handler的構造函數以下所示：

5.3 Toast如何添加系統窗口的權限

做爲程序員，都知道任何視圖的顯示都要依賴於一個視圖窗口Window，一樣Toast的顯示也須要一個窗口，並且它仍是一個系統窗口，這個窗口最終會被WindowManagerService(WMS)標記管理。當顯示一個Toast時，調用show方法後，會經過TN 類中的handleShow方法處理展現的邏輯，同時WMS會生成一個token，而咱們知道WMS自己就是一個系統級的服務，因此由它生成的token必然擁有權限添加系統窗口，最後WMS調用addView方法將view和mParams參數帶進來，這樣就能夠展現吐司呢。
須要注意：WindowManager檢查當前窗口的token是否有效，若是有效，則添加窗口展現Toast；若是無效，則拋出異常，會發生5.1這種類型的異常。
- 在那個地方檢查token呢？在mWM.addView(mView, mParams)這裏檢查token，點擊去能夠發現ViewManager是個接口，這時候能夠去看WindowManagerImpl類，繼承ViewManager。

5.4 token null is not valid

看了美團的技術文檔分享得知，這個異常其實並不是是Toast的異常，而是Google對WindowManage的一些限制致使的。Android從7.1.1版本開始，對WindowManager作了一些限制和修改，特別是TYPE_TOAST類型的窗口，必需要傳遞一個token用於權限校驗才容許添加。在stackoverflow上搜索，也較少獲得這方面的解答，這塊有點難以解決這個問題。