Toast原始碼深度分析

楊充發表於2019-03-04

AST原始碼

目錄介紹

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萬字]，轉載請註明出處，謝謝！
連結地址：github.com/yangchong21…
如果覺得好，可以star一下，謝謝！當然也歡迎提出建議，萬事起於忽微，量變引起質變！
Toast封裝庫專案地址：github.com/yangchong21…

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方法

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

/**
 * schedule handleHide into the right thread
 */
@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中去

當 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方法呢？
- 回撥了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將不再彈出。

具體可以參考我的彈窗封裝庫：github.com/yangchong21…

自定義對話方塊，其中包括：自定義Toast，採用builder模式，支援設定吐司多個屬性；自定義dialog控制元件，仿IOS底部彈窗；自定義DialogFragment彈窗，支援自定義佈局，也支援填充recyclerView佈局；自定義PopupWindow彈窗，輕量級，還有自定義Snackbar等等；還有自定義loading載入窗，簡單便用。

//判斷是否有許可權
NotificationManagerCompat.from(context).areNotificationsEnabled()

//如果沒有通知許可權，則直接跳轉設定中心設定
@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);
}
複製程式碼

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 能夠滿足的需求

可以設定吐司的位置，偏移，吐司文字顏色，吐司背景顏色等等。簡單的程式碼就可以實現你需要的多種場景。也可以設定定義佈局的吐司。專案地址：github.com/yangchong21…

4.2 具有的優勢

採用builder構造者模式，鏈式程式設計，一行程式碼呼叫即可設定吐司Toast。

為了避免靜態toast物件記憶體洩漏，固可以使用應用級別的上下文context。所以這裡我就直接採用了應用級別Application上下文，需要在application進行初始化一下。即可呼叫……

//初始化
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

報錯日誌，是不是有點眼熟呀？更多可以看我的開源專案：github.com/yangchong21…

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();
複製程式碼

報錯日誌如下所示：

然後找找報錯日誌從哪裡來的

子執行緒中吐司的正確做法，程式碼如下所示

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上搜尋，也較少得到這方面的解答，這塊有點難以解決這個問題。

關於其他內容介紹

01.關於部落格彙總連結

02.關於我的部落格

我的個人站點：www.yczbj.org，www.ycbjie.cn
github：github.com/yangchong21…
知乎：www.zhihu.com/people/yang…
簡書：www.jianshu.com/u/b7b2c6ed9…
csdn：my.csdn.net/m0_37700275
喜馬拉雅聽書：www.ximalaya.com/zhubo/71989…
開源中國：my.oschina.net/zbj1618/blo…
泡在網上的日子：www.jcodecraeer.com/member/cont…
郵箱：yangchong211@163.com
阿里雲部落格：yq.aliyun.com/users/artic… 239.headeruserinfo.3.dT4bcV
segmentfault頭條：segmentfault.com/u/xiangjian…

深度 Mybatis 3 原始碼分析（一）SqlSessionFactoryBuilder原始碼分析
2019-06-06
MyBatis原始碼SQLSessionUI
Android懸浮窗TYPE_TOAST小結: 原始碼分析
2016-02-19
AndroidAST原始碼
Flutter Dio原始碼分析(三)--深度剖析
2021-08-30
Flutter原始碼
Android學習筆記14-從原始碼分析Toast的建立過程
2019-05-12
Android筆記原始碼AST
Guava Cache：核心引數深度剖析和原始碼分析
2020-10-04
Guava原始碼
[Android] Toast問題深度剖析(二)
2018-11-20
AndroidAST
[Android] Toast問題深度剖析(一)
2018-11-20
AndroidAST
深度分析 Java 的 ClassLoader 機制（原始碼級別）
2015-12-14
Java原始碼
Retrofit原始碼分析三原始碼分析
2018-05-17
原始碼
OkHttp原始碼深度解析
2020-03-25
HTTP原始碼
深度解剖dubbo原始碼
2020-04-04
原始碼
SnapHelper原始碼深度解析
2019-01-19
原始碼
Vuex 原始碼深度解析
2018-09-10
Vue原始碼
VueRouter 原始碼深度解析
1970-01-01
Vue原始碼
集合原始碼分析[2]-AbstractList 原始碼分析
2019-04-11
原始碼
集合原始碼分析[1]-Collection 原始碼分析
2019-03-23
原始碼
集合原始碼分析[3]-ArrayList 原始碼分析
2019-04-12
原始碼
Guava 原始碼分析之 EventBus 原始碼分析
2018-08-01
Guava原始碼
Android 原始碼分析之 AsyncTask 原始碼分析
2019-03-04
Android原始碼
【JDK原始碼分析系列】ArrayBlockingQueue原始碼分析
2020-09-27
JDK原始碼BloC
以太坊原始碼分析(36)ethdb原始碼分析
2018-05-14
原始碼
以太坊原始碼分析(38）event原始碼分析
2018-05-14
原始碼
以太坊原始碼分析(41）hashimoto原始碼分析
2018-05-14
原始碼
以太坊原始碼分析(43）node原始碼分析
2018-05-14
原始碼
以太坊原始碼分析(52）trie原始碼分析
2018-05-14
原始碼
spark核心原始碼深度剖析
2018-08-15
Spark原始碼
React Hooks原始碼深度解析
2023-03-16
ReactHook原始碼
ThreadLocal原始碼深度剖析
2018-01-19
thread原始碼
以太坊原始碼分析(51）rpc原始碼分析
2018-05-14
原始碼RPC
【Android原始碼】Fragment 原始碼分析
2017-12-23
Android原始碼Fragment
【Android原始碼】Intent 原始碼分析
2017-12-23
Android原始碼Intent
[阿里DIEN] 深度興趣進化網路原始碼分析之 Keras版本
2021-01-26
阿里原始碼Keras
RecyclerView用法和原始碼深度解析
2019-02-18
View原始碼
【vue原始碼】深度理解v-for
2019-05-06
Vue原始碼
KubeSphere 後端原始碼深度解析
2022-01-21
後端原始碼
原始碼級深度理解 Java SPI
2022-11-07
原始碼Java
Netty原始碼深度解析(九)-編碼
2018-12-03
Netty原始碼
k8s client-go原始碼分析 informer原始碼分析(6)-Indexer原始碼分析
2022-06-19
K8SclientGo原始碼ORMIndex