背景

Toast是Android平臺上的常用技術(shù)。從用戶角度來看，Toast是用戶與App交互最基本的提示控件；從開發(fā)者角度來看，Toast是開發(fā)過程中常用的調(diào)試手段之一。此外，Toast語法也非常簡單，僅需一行代碼?；诤唵我子玫膬?yōu)點，Toast在Android開發(fā)過程中被廣泛使用。

但是，Toast是系統(tǒng)層面提供的，不依賴于前臺頁面，存在濫用的風險。為了規(guī)避這些風險，Google在Android系統(tǒng)版本的迭代過程中，不斷進行了優(yōu)化和限制。這些限制不可避免的影響到了正常的業(yè)務(wù)邏輯，在迭代過程中，我們遇到過以下幾個問題：

設(shè)置中關(guān)閉某個App的【顯示通知】開關(guān)，Toast不再彈出，極大的影響了用戶體驗。

Toast在Android 7.1.2(API25)以下會發(fā)生BadTokenException異常，導致App崩潰。

自定義TYPE_TOAST類型的Window，在Android 7.1.1、7.1.2發(fā)生token null is not valid異常，導致App崩潰。

與Toast斗爭

在美團平臺的業(yè)務(wù)中，Toast被用作主流程交互的提示控件，比如在完成下單、評價、分享后進行各種提示。Toast被限制之后會給用戶帶來誤解。為了解決正常的業(yè)務(wù)Toast被系統(tǒng)限制誤傷的問題，我們與Toast展開了一系列的斗爭。

斗爭一：Toast不彈出

舉個案例：某個用戶投訴美團App在分享朋友圈后沒有任何提示，不知道是否分享成功。具體原因是用戶在設(shè)置里關(guān)閉了美團App的【顯示通知】開關(guān)，導致通知權(quán)限無法獲取，這極大的影響了用戶體驗。然而，在Android 4.4(API19)以下系統(tǒng)中，這個開關(guān)的打開狀態(tài)，也就是通知權(quán)限是否開啟的狀態(tài)我們是無法判斷的，因此我們也無法感知Toast彈出與否，為了解決這個問題，需要從Toast的源碼入手，最后源碼總結(jié)步驟如下：

在Toast#show()源碼中，Toast的展示并非自己控制，而是通過AIDL使用INotificationManager獲取到NotificationManagerService(NMS)這個遠程服務(wù)。

調(diào)用service.enqueueToast(pkg, tn, mDuration)將當前Toast的顯示加入到通知隊列，并傳遞了一個tn對象，這個對象就是NMS用作回傳Toast的顯示狀態(tài)。

在tn的回調(diào)方法中，使用WindowManager將構(gòu)造的Toast添加到當前的window中，需要注意的是這個window的type類型是TYPE_TOAST。

Toast不彈出原因分析

那么為什么禁掉通知權(quán)限會導致Toast不再彈出呢？

通過以上分析，Toast的展示是由NMS服務(wù)控制的，NMS服務(wù)會做一些權(quán)限、token等的校驗，當通知權(quán)限一旦關(guān)閉，Toast將不再彈出。

可行性方案調(diào)研

如果能夠繞過NMS服務(wù)的校驗?zāi)敲淳涂梢赃_到我們的訴求，繞過的方法是按照Toast的源碼，實現(xiàn)我們自己的MToast，并將NMS替換成自己的ToastManager，如下圖：

方案定了后，需要做的事情就是代碼替換。作為平臺型App，美團App大量使用了Toast，人工替換肯定會出現(xiàn)遺漏的地方，為了能用更少的人力來解決這個問題，我們采用了如下方案。

解決方案

美團App在早期就因業(yè)務(wù)需要接入了AspectJ，AspectJ是Java中做AOP編程的利器，基本原理就是在代碼編譯期對切面的代碼進行修改，插入我們預先寫好的邏輯或者直接替換當前方法的實現(xiàn)。美團App的做法就是借用AspectJ，從源頭攔截并替換Toast的調(diào)用實現(xiàn)。

關(guān)鍵代碼如下：

@Aspect public class ToastAspect {@Pointcut("call(* android.widget.Toast+.show(..))")public void toastShow() {}@Around("toastShow()")public void toastShow(ProceedingJoinPoint point) {Toast toast = (Toast) point.getTarget();Context context = (Context) ReflectUtils.getValue(toast, "mContext");if (Build.VERSION.SDK_INT >= 19 && NotificationManagerCompat.from(context).areNotificationsEnabled()) {point.proceed(point.getArgs());} else {floatToastShow(toast, context);}}private static void floatToastShow(Toast toast, Context context) {...new MToast(context).setDuration(mDuration).setView(mNextView).setGravity(mGravity, mX, mY).setMargin(mHorizontalMargin, mVerticalMargin).show();} }

其中MToast是TYPE_TOAST類型的的Window，這樣即使禁掉通知權(quán)限，業(yè)務(wù)代碼也可以不作任何修改，繼續(xù)彈出Toast。而底層已經(jīng)被無感知的替換成自己的MToast了，以最小的成本達到了目標。

斗爭二：BadTokenException

美團App在線上經(jīng)常會上報BadTokenExceptionCrash，而且集中在Android 5.0 - Android 7.1.2的機型上。具體Crash堆棧如下：

android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@6caa743 is not valid; is your activity running?at android.view.ViewRootImpl.setView(ViewRootImpl.java:607)at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:341)at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:106)at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3242)`BadTokenException`at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2544)at android.app.ActivityThread.access$900(ActivityThread.java:168)at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1378)at android.os.Handler.dispatchMessage(Handler.java:102)at android.os.Looper.loop(Looper.java:150)at android.app.ActivityThread.main(ActivityThread.java:5665)at java.lang.reflect.Method.invoke(Native Method)at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:822)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:712)

BadTokenException原因分析

我們知道在Android上，任何視圖的顯示都要依賴于一個視圖窗口Window，同樣Toast的顯示也需要一個窗口，前文已經(jīng)分析了這個窗口的類型就是TYPE_TOAST，是一個系統(tǒng)窗口，這個窗口最終會被WindowManagerService(WMS)標記管理。但是我們的普通應(yīng)用程序怎么能擁有添加系統(tǒng)窗口的權(quán)限呢？查看源碼后發(fā)現(xiàn)需要以下幾個步驟：

當顯示一個Toast時，NMS會生成一個token，而NMS本身就是一個系統(tǒng)級的服務(wù)，所以由它生成的token必然擁有權(quán)限添加系統(tǒng)窗口。

NMS通過ITransientNotification也就是tn對象，將生成的token回傳到我們自己的應(yīng)用程序進程中。

應(yīng)用程序調(diào)用handleShow方法，去向WindowManager添加窗口。

WindowManager檢查當前窗口的token是否有效，如果有效，則添加窗口展示Toast；如果無效，則拋出上述異常，Crash發(fā)生。

詳細的原理圖如下：

在Android 7.1.1的NMS源碼中，關(guān)鍵代碼如下：

void showNextToastLocked() {ToastRecord record = mToastQueue.get(0);while (record != null) {try {// 調(diào)用tn對象的show方法展示toast，并回傳tokenrecord.callback.show(record.token);// 超時處理scheduleTimeoutLocked(record);return;} catch (RemoteException e) {...}} }private void scheduleTimeoutLocked(ToastRecord r) {mHandler.removeCallbacksAndMessages(r);Message m = Message.obtain(mHandler, MESSAGE_TIMEOUT, r);long delay = r.duration == Toast.LENGTH_LONG ? LONG_DELAY : SHORT_DELAY;// 根據(jù)toast顯示的時長，延遲觸發(fā)消息，最終調(diào)用下面的方法mHandler.sendMessageDelayed(m, delay); }private void handleTimeout(ToastRecord record) {synchronized (mToastQueue) {int index = indexOfToastLocked(record.pkg, record.callback);if (index >= 0) {cancelToastLocked(index);}} }void cancelToastLocked(int index) {ToastRecord record = mToastQueue.get(index);try {// 調(diào)用tn對象的hide方法隱藏toastrecord.callback.hide();} catch (RemoteException e) {...}ToastRecord lastToast = mToastQueue.remove(index);// 移除當前的toast的token，token就此失效mWindowManagerInternal.removeWindowToken(lastToast.token, true, DEFAULT_DISPLAY);... }

問題驗證

通過以上分析showNextToastLocked()被調(diào)用后，如果此時主線程由于其它原因被阻塞導致handleShow()不能及時調(diào)用，從而觸發(fā)超時邏輯導致token失效。主線程阻塞結(jié)束后，繼續(xù)執(zhí)行Toast的show方法時，發(fā)現(xiàn)token已經(jīng)失效了，于是拋出BadTokenException異常從而導致上述Crash。

可以使用以下的代碼驗證此異常：

Toast.makeText(this, "測試Crash", Toast.LENGTH_SHORT).show(); try {Thread.sleep(5000); } catch (InterruptedException e) {e.printStackTrace(); }

解決方案

那么如何解決這個異常呢？首先想到就是對Toast加上try-catch，但是發(fā)現(xiàn)不起作用，原因是這個異常并非在當前線程中立即被拋出的，而是添加到了消息隊列中，等待消息真正執(zhí)行時才會被拋出。Google在Android 8.0的代碼提交中修復了這個問題，把8.0的源碼和前一版本對比可以發(fā)現(xiàn)，如同我們的分析，Google在消息執(zhí)行處將異常catch住了。那么針對8.0之前的版本發(fā)生的Crash怎么辦呢？美團平臺使用了一個類似代理反射的通用解決方案，結(jié)構(gòu)如下圖：

基本原理：使用我們自己實現(xiàn)的ToastHandler替換Toast內(nèi)部的Handler，ToastHandler作用就是把異常catch住，這種修改思路和Android 8.0修復思路保持一致，只不過一個是在系統(tǒng)層面解決，一個是在用戶層面解決。

斗爭三：token null is not valid

在Android 7.1.1、7.1.2和去年8月發(fā)布的Android 8.0系統(tǒng)中，我們的方案出現(xiàn)了另一個異常token null is not valid，這個異常堆棧如下：

android.view.WindowManager$BadTokenException: Unable to add window -- token null is not valid; is your activity running?at android.view.ViewRootImpl.setView(ViewRootImpl.java:683)at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:342)at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:94)

token null is not valid原因分析

這個異常其實并非是Toast的異常，而是Google對WindowManage的一些限制導致的。Android從7.1.1版本開始，對WindowManager做了一些限制和修改，特別是TYPE_TOAST類型的窗口，必須要傳遞一個token用于權(quán)限校驗才允許添加。Toast源碼在7.1.1及以上也有了變化，Toast的WindowManager.LayoutParams參數(shù)額外添加了一個token屬性，這個屬性的來源就已經(jīng)在上文分析過了，它是在NMS中被初始化的，用于對添加的窗口類型進行校驗。當用戶禁掉通知權(quán)限時，由于AspectJ的存在，最終會調(diào)用我們封裝的MToast，但是MToast沒有經(jīng)過NMS，因此無法獲取到這個屬性，另外就算我們按照NMS的方法自己生成一個token，這個token也是沒有添加TYPE_TOAST權(quán)限的，最終還是無法避免這個異常的發(fā)生。

源碼中關(guān)鍵代碼如下：

// 方法簽名多了一個IBinder類型的token，它是在NMS中創(chuàng)建的 public void handleShow(IBinder windowToken) {...if (mView != mNextView) {...mWM = (WindowManager)context.getSystemService(Context.WINDOW_SERVICE);mParams.x = mX;mParams.y = mY;mParams.verticalMargin = mVerticalMargin;mParams.horizontalMargin = mHorizontalMargin;mParams.packageName = packageName;mParams.hideTimeoutMilliseconds = mDuration == Toast.LENGTH_LONG ? LONG_DURATION_TIMEOUT : SHORT_DURATION_TIMEOUT;// 這里添加了tokenmParams.token = windowToken;if (mView.getParent() != null) {if (localLOGV) Log.v(TAG, "REMOVE! " + mView + " in " + this);mWM.removeView(mView);}...try {// 8.0版本的系統(tǒng)，將這里的異常catch住了mWM.addView(mView, mParams);trySendAccessibilityEvent();} catch (WindowManager.BadTokenException e) {/* ignore */}} }

解決方案

經(jīng)過調(diào)研，發(fā)現(xiàn)Google對WindowManager的限制，讓我們不得不放棄使用TYPE_TOAST類型的窗口替代Toast，也代表了我們上述使用WindowManager方案的終結(jié)。

斗爭總結(jié)

我們的核心目標只是希望在用戶關(guān)閉通知消息開關(guān)的情況下，能繼續(xù)看到通知，所以我們使用了WindowManager添加自定義window的方式來替換Toast，但是在替換的過程中遇到了一些Toast的Crash異常，為了解決這些Crash，我們提出了使用自定義ToastHandler的方式來catch住異常，確保app正常運行。在方案推廣上，為了能用更少的人力，更高的效率完成替換，我們使用了AspectJ的方案。最后，在Android 7.1.1版本開始，由于Google對WindowManager的限制，導致這種使用自定義window的替換Toast的方式不再可行，我們便開始尋找替換Toast的其它可行方案。

替換Toast的可行方案

為了繼續(xù)能讓用戶在禁掉通知權(quán)限的情況下，也能看到通知以及屏蔽上述Toast帶來的Crash，我們經(jīng)過調(diào)研、分析并嘗試了以下幾種方案。

在7.1.1以上系統(tǒng)中繼續(xù)使用WindowManager方式，只不過需要把type改為TYPE_PHONE等懸浮窗權(quán)限。

使用Dialog、DialogFragment、PopupWindow等彈窗控件來實現(xiàn)一個通知。

按照Snackbar的實現(xiàn)方式，找到一個可以添加布局的父布局，采用addView的方式添加通知。

以上幾種方案的共同點是為了繞過通知權(quán)限的檢查，即使用戶禁掉了通知權(quán)限，我們自定義的通知依然可以不受影響的彈出來，但是也有很明顯的缺陷，如下圖：

經(jīng)過對比，我們也采用了Snackbar替換Toast的方案，原因是Snackbar是Android自5.0系統(tǒng)推出MaterialDesign后官方推薦的控件，在交互友好性方面比Toast要好，例如：支持手勢操作，支持與CoordinatorLayout聯(lián)動等，Snackbar作為提示控件目前在市面上也被廣泛使用，而其它方案有明顯的缺陷如下：

首先，使用WindowManager添加懸浮窗的方式，雖然這種方式能和原生的Toast保持完美的一致性，但是需要的權(quán)限太高，坑也太多。TYPE_PHONE的權(quán)限要比TYPE_TOAST權(quán)限敏感太多，而且在Android 8.0系統(tǒng)上必須使用TYPE_APPLICATION_OVERLAY這個type，并且要申請以下兩個權(quán)限，這兩個權(quán)限不僅需要在清單文件中聲明，而且絕大部分手機默認是關(guān)閉狀態(tài)，需要我們引導用戶開啟，如果用戶選擇不開啟，那么Toast還是不能彈出。同時還需要適配眾多定制化ROM的國產(chǎn)機型。繞過了通知權(quán)限的坑，又跳入了懸浮窗權(quán)限的坑，這是不可取的。

<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/> <uses-permission android:name="android.permission.SYSTEM_OVERLAY_WINDOW"/>

其次，使用Dialog方式也有明顯的缺陷，Dialog、DialogFragment、PopupWindow都嚴重依賴于Activity，沒有Activity作為上下文時，它們是無法創(chuàng)建和顯示的，并且簡單的通知使用這種控件過重。此外，在UI展示和API一致性上，幾乎和Toast沒有什么關(guān)系，需要額外做封裝的成本比較大。

遇到問題

我們在使用Snackbar替換Toast時遇到了以下兩個問題：

Snackbar彈出的時候，被Dialog，PopupWindow等控件遮住。

Snackbar無法進行跨頁面展示，這是Snackbar實現(xiàn)原理決定的。

解決方案

首先，為了滿足自身業(yè)務(wù)的擴展性、靈活性，我們參照系統(tǒng)Snackbar的源碼，進行了按需定制，比如多樣化的樣式擴展、進入進出的動畫擴展、支持自定義布局的擴展等，接口更加豐富。一方面是為了解決以上遇到的問題，另一方面也是為了在業(yè)務(wù)的迭代過程中能快速開發(fā)和適配。以下是基本的類圖依賴關(guān)系：

問題一解決

針對Snackbar彈出的時候，被Dialog，PopupWindow等控件遮住的問題，原因在于Snackbar依賴于View，當把Activity布局的View傳給Snackbar做為Snackbar展示依賴的父View時，后面再彈Dialog，PopupWindow等控件，Snackbar就會被控件遮擋。正確的做法是直接把PopupWindow和Dialog所依賴的View傳給Snackbar。那么我們定制化的Snackbar不僅支持傳遞這個View，也支持直接傳遞PopupWindow和Dialog的實例，上圖中SnackbarBuilder的方法反應(yīng)了這個改動。

問題二解決

比較復雜的問題是Snackbar不支持跨頁面展示，我們在項目中有大量這樣的代碼：

Toast.makeText(this, "彈出消息", Toast.LENGTH_SHORT).show(); finish();

當直接把Toast替換成Snackbar后，這個消息會一閃而過，用戶來不及查看，因為Snackbar依賴的Activity被銷毀了，為了解決這個問題，我們一共探討了三種方案：

方案一：

使用startActivityForResult替換所有跨頁面展示的通知，也就是在A頁面使用startActivityForResult跳轉(zhuǎn)到B頁面，把原本在B頁面彈出Toast的邏輯，改寫到A頁面自己彈出Snackbar。

這種方案：優(yōu)點在于責任清晰明確，頁面被finish后應(yīng)該展示什么通知以及應(yīng)該由誰觸發(fā)這個通知的展示，這個責任本身就在調(diào)用方；缺點在于代碼改動比較大。因此我們舍棄了這種方案。

方案二： 使用Application.ActivityLifecycleCallbacks全局監(jiān)聽Activity的生命周期，當一個頁面關(guān)閉的時候，記錄下Snackbar剩余需要展示的時間，在進入下一個Activity后，讓沒有展示完的Snackbar繼續(xù)展示。

這種方案：優(yōu)點在于代碼改動量小；缺點在于在頁面切換過程中，如果Snackbar沒有展示結(jié)束，會出現(xiàn)一次閃爍。雖然在技術(shù)上這種方案很好，代碼的侵入性極低，但是這個閃爍對于產(chǎn)品來說無法接受，因此這種方案也不做考慮。

方案三：

使用本地廣播進行跨頁面展示，這也是美團最終使用的解決方案，具體原理如下

在A頁面跳轉(zhuǎn)B頁面前，使用當前傳入的Context注冊一個廣播。

在B頁面finish之前，發(fā)送A在跳轉(zhuǎn)前注冊的廣播，并把需要展示的消息使用Intent返回。

在廣播中獲取A頁面的實例，使用Snackbar展示B頁面回傳的消息，并把當前廣播unRegister反注冊掉。

這是方案一的自動化版本，為了達到自動化的效果和對原有代碼的最小侵入性，我們設(shè)計了一個輔助類，就是上圖中的SnackbarHelper，原理圖如下：

SnackbarHelper提供統(tǒng)一的入口，接入成本低，只需要將原有使用context.startActivity()、context.startActivityForResult()、context.finish()的地方改成SnackBarHelper下面的同名方法即可。這樣通過廣播的方法完成了Snackbar的跨頁面展示，業(yè)務(wù)方的代碼修改量僅僅是改一下調(diào)用方式，改動極小。

結(jié)語

目前這套解決方案在美團業(yè)務(wù)中被廣泛使用，能覆蓋到絕大部分場景。通知的展現(xiàn)形式基本與Toast沒有區(qū)別，不僅解決了用戶在禁掉通知的情況下無法看到通知的困境，也降低了客訴率。

作者簡介

• 子堯，美團高級工程師，2017年加入美團，負責平臺搜索、平臺首頁等研發(fā)工作。
• 騰飛，美團資深工程師，2015年加入美團，平臺基礎(chǔ)業(yè)務(wù)組負責人，負責平臺業(yè)務(wù)的迭代。

招聘

美團平臺客戶端技術(shù)團隊長期招聘技術(shù)專家，有興趣的同學可以發(fā)送簡歷到：fangjintao#meituan.com。

詳情請點擊：詳細JD。

總結(jié)

以上是生活随笔為你收集整理的Toast与Snackbar的那点事的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。