Toast與Snackbar的那點事
背景
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ù)的校驗那么就可以達到我們的訴求，繞過的方法是按照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)標記管理。但是我們的普通應用程序怎么能擁有添加系統(tǒng)窗口的權(quán)限呢？查看源碼后發(fā)現(xiàn)需要以下幾個步驟：
- 當顯示一個Toast時，NMS會生成一個token，而NMS本身就是一個系統(tǒng)級的服務(wù)，所以由它生成的token必然擁有權(quán)限添加系統(tǒng)窗口。
- NMS通過ITransientNotification也就是tn對象，將生成的token回傳到我們自己的應用程序進程中。
- 應用程序調(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，并回傳token
- record.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方法隱藏toast
- record.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;
- // 這里添加了token
- mParams.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的方法反應了這個改動。
問題二解決
比較復雜的問題是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后應該展示什么通知以及應該由誰觸發(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ū)別，不僅解決了用戶在禁掉通知的情況下無法看到通知的困境，也降低了客訴率。
【本文為51CTO專欄機構(gòu)“美團點評技術(shù)團隊”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號聯(lián)系機構(gòu)獲取授權(quán)】
