Toast源碼深度分析

阿新 • • 發佈：2018-11-01

move obsolete def DApp 前臺 remove state sim 更多

目錄介紹

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方法
- 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
  br/>*/
  @Override
  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將不再彈出。
具體可以參考我的彈窗封裝庫：https://github.com/yangchong211/YCDialog
- 自定義對話框，其中包括：自定義Toast，采用builder模式，支持設置吐司多個屬性；自定義dialog控件，仿IOS底部彈窗；自定義DialogFragment彈窗，支持自定義布局，也支持填充recyclerView布局；自定義PopupWindow彈窗，輕量級，還有自定義Snackbar等等；還有自定義loading加載窗，簡單便用。
```
//判斷是否有權限
NotificationManagerCompat.from(context).areNotificationsEnabled()
```
//如果沒有通知權限，則直接跳轉設置中心設置@SuppressLint("ObsoleteSdkInt")
br/>@SuppressLint("ObsoleteSdkInt")
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 能夠滿足的需求

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

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

報錯日誌，是不是有點眼熟呀？更多可以看我的開源項目：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上搜索，也較少得到這方面的解答，這塊有點難以解決這個問題。

關於其他內容介紹

01.關於博客匯總鏈接

1.技術博客匯總
2.開源項目匯總
3.生活博客匯總
4.喜馬拉雅音頻匯總
5.其他匯總

02.關於我的博客

我的個人站點：www.yczbj.org，www.ycbjie.cn
github：https://github.com/yangchong211
知乎：https://www.zhihu.com/people/yang-chong-69-24/pins/posts
簡書：http://www.jianshu.com/u/b7b2c6ed9284
csdn：http://my.csdn.net/m0_37700275
喜馬拉雅聽書：http://www.ximalaya.com/zhubo/71989305/
開源中國：https://my.oschina.net/zbj1618/blog
泡在網上的日子：http://www.jcodecraeer.com/member/content_list.php?channelid=1
郵箱：[email protected]
阿裏雲博客：https://yq.aliyun.com/users/article?spm=5176.100- 239.headeruserinfo.3.dT4bcV
segmentfault頭條：https://segmentfault.com/u/xiangjianyu/articles

Toast源碼深度分析

move obsolete def DApp 前臺 remove state sim 更多目錄介紹 1.最簡單的創建方法 1.1 Toast構造方法 1.2 最簡單的創建 1.3 簡單改造避免重復創建 1.4 為何會出現內存泄漏 1.5 吐司是系統級別的 2.源碼分

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

關於其他內容介紹

01.關於博客匯總鏈接

02.關於我的博客

相關推薦