歡迎大家前往雲+社群，獲取更多騰訊海量技術實踐乾貨哦~
作者： QQ音樂技術團隊
題記
Toast 作為 Android 系統中最常用的類之一，由於其方便的api設計和簡潔的互動體驗，被我們所廣泛採用。但是，伴隨著我們開發的深入，Toast 的問題也逐漸暴露出來。 本系列文章將分成兩篇: 第一篇，我們將分析 Toast 所帶來的問題 第二篇，將提供解決 Toast 問題的解決方案 (注:本文原始碼基於Android 7.0)
1.回顧
上一篇 [[Android] Toast問題深度剖析(一)] 筆者解釋了:
Toast系統如何構建視窗（通過系統服務NotificationManager來生成系統視窗）Toast異常出現的原因（系統呼叫Toast的時序紊亂）
而本篇的重點，在於解決我們第一章所說的 Toast 問題。
2.解決思路
基於第一篇的知識，我們知道，Toast 的視窗屬於系統視窗，它的生成和生命週期依賴於系統服務 NotificationManager。一旦 NotificationManager 所管理的視窗生命週期跟我們本地的程式不一致，就會發生異常。那麼，我們能不能不使用系統的視窗，而使用自己的視窗，並且由我們自己控制生命週期呢？事實上， SnackBar 就是這樣的方案。不過，如果不使用系統型別的視窗，就意味著你的Toast 介面，無法在其他應用之上顯示。(比如，我們經常看到的一個場景就是你在你的應用出呼叫了多次 Toast.show函式，然後退回到桌面，結果發現桌面也會彈出 Toast，就是因為系統的 Toast 使用了系統視窗，具有高的層級)不過在某些版本的手機上，你的應用可以申請許可權，往系統中新增 TYPE_SYSTEM_ALERT 視窗，這也是一種系統視窗，經常用來作為浮層顯示在所有應用程式之上。不過，這種方式需要申請許可權，並不能做到讓所有版本的系統都能正常使用。 如果我們從體驗的角度來看，當使用者離開了該程式，就不應該彈出另外一個程式的 Toast 提示去干擾使用者的。Android 系統似乎也意識到了這一點，在新版本的系統更新中，限制了很多在桌面提示視窗相關的許可權。所以，從體驗上考慮，這個情況並不屬於問題。
“那麼我們可以選擇哪些視窗的型別呢？”
- 使用子視窗: 在
Android程式內，我們可以直接使用型別為子視窗型別的視窗。在Android程式碼中的直接應用是PopupWindow或者是Dialog。這當然可以，不過這種視窗依賴於它的宿主視窗，它可用的條件是你的宿主視窗可用 - 採用
View系統: 使用View系統去模擬一個Toast視窗行為，做起來不僅方便，而且能更加快速的實現動畫效果，我們的SnackBar就是採用這套方案。這也是我們今天重點講的方案
“如果採用 View 系統方案，那麼我要往哪個控制元件中新增我的 Toast 控制元件呢？”
在Android程式中，我們所有的可視操作都依賴於一個 Activity 。 Activity 提供上下文(Context)和檢視視窗(Window) 物件。我們通過Activity.setContentView 方法所傳遞的任何 View物件 都將被檢視視窗( Window) 中的 DecorView 所裝飾。而在 DecorView 的子節點中，有一個 id 為android.R.id.content 的 FrameLayout 節點(後面簡稱 content 節點) 是用來容納我們所傳遞進去的 View 物件。一般情況下，這個節點佔據了除了通知欄的所有區域。這就特別適合用來作為 Toast 的父控制元件節點。
“我什麼時機往這個content節點中新增合適呢？這個 content 節點什麼時候被初始化呢？”
根據不同的需求，你可能會關注以下兩個時機:
Content節點生成Content內容顯示
實際我們只需要將我們的 Toast 新增到 Content 節點中，只要滿足第一條即可。如果你是為了完成效能檢測，測量或者其他目的，那麼你可能更關心第二條。 那麼什麼情況下 Content 節點生成呢？剛才我們說了，Content 節點包含在我們的 DecorView 控制元件中，而 DecorView 是由 Activity 的 Window物件所持有的控制元件。Window 在 Android 中的實現類是 PhoneWindow，(這部分程式碼有興趣可以自行閱讀) 我們來看下原始碼:
//code PhoneWindow.java
@Override
public void setContentView(int layoutResID) {
if (mContentParent == null) { //mContentParent就是我們的 content 節點
installDecor();//生成一個DecorView
} else {
mContentParent.removeAllViews();
}
mLayoutInflater.inflate(layoutResID， mContentParent);
final Callback cb = getCallback();
if (cb != null && !isDestroyed()) {
cb.onContentChanged();
}
}複製程式碼PhoneWindow 物件通過 installDecor 函式生成 DecorView 和 我們所需要的 content 節點(最終會存到 mContentParent) 變數中去。但是， setContentView 函式需要我們主動呼叫，如果我並沒有呼叫這個 setContentView 函式，installDecor 方法將不被呼叫。那麼，有沒有某個時刻，content 節點是必然生成的呢？當然有，除了在 setContentView 函式中呼叫installDecor外，還有一個函式也呼叫到了這個，那就是:
//code PhoneWindow.java
@Override
public final View getDecorView() {
if (mDecor == null) {
installDecor();
}
return mDecor;
}複製程式碼而這個函式，將在 Activity.findViewById 的時候呼叫：
//code Activity.java
public View findViewById(@IdRes int id) {
return getWindow().findViewById(id);
}
//code Window.java
public View findViewById(@IdRes int id) {
return getDecorView().findViewById(id);
}複製程式碼因此，只要我們只要呼叫了 findViewById 函式，一樣可以保證 content 被正常初始化。這樣我們解釋了第一個”就緒”(Content 節點生成)。我們再來看下第二個”就緒”，也就是 Android 介面什麼時候顯示呢？相信你可能迫不及待的回答不是 onResume 回撥的時候麼？實際上，在 onResume 的時候，根本還沒處理跟介面相關的事情。我們來看下 Android 程式是如何處理 resume 訊息的: (注: AcitivityThread 是 Android 程式的入口類， Android 程式處理 resume 相關訊息將會呼叫到 AcitivityThread.handleResumeActivity 函式)
//code AcitivityThread.java
void handleResumeActivity(...) {
...
ActivityClientRecord r = performResumeActivity(token， clearHide);
// 之後會呼叫call onResume
...
View decor = r.window.getDecorView();
//呼叫getDecorView 生成 content節點
decor.setVisibility(View.INVISIBLE);
....
if (r.activity.mVisibleFromClient) {
r.activity.makeVisible();//add to WM 管理
}
...
}
//code Activity.java
void makeVisible() {
if (!mWindowAdded) {
ViewManager wm = getWindowManager();
wm.addView(mDecor， getWindow().getAttributes());
mWindowAdded = true;
}
mDecor.setVisibility(View.VISIBLE);
}複製程式碼Android 程式在處理 resume 訊息的時候，將走以下的流程:
- 呼叫
performResumeActivity回撥Activity的onResume函式 - 呼叫
Window的getDecorView生成DecorView物件和content節點 - 將
DecorView納入WindowManager(程式內服務)的管理 - 呼叫
Activity.makeVisible顯示當前Activity
按照上述的流程，在 Activity.onResume 回撥之後，才將控制元件納入本地服務 WindowManager 的管理中。也就是說， Activity.onResume 根本沒有顯示任何東西。我們不妨寫個程式碼驗證一下:
//code DemoActivity.java
public DemoActivity extends Activity {
private View view ;
@Override
protected void onCreate( Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
view = new View(this);
this.setContentView(view);
}
@Override
protected void onResume() {
super.onResume();
Log.d("cdw"，"onResume :" +view.getHeight());// 有高度是顯示的必要條件
}
}複製程式碼這裡，我們通過在 onResume 中獲取高度的方式驗證介面是否被繪製，最終我們將輸出日誌:
D cdw : onResume :0複製程式碼那麼，介面又是在什麼時候完成的繪製呢？是不是在 WindowManager.addView 之後呢？我們在 onResume之後會呼叫Activity.makeVisible，裡面會呼叫WindowManager.addView。因此我們在onResume 裡post一個訊息就可以檢測WindowManager.addView 之後的情況：
@Override
protected void onResume() {
super.onResume();
this.runOnUiThread(new Runnable() {
@Override
public void run() {
Log.d("cdw"，"onResume :" +view.getHeight());
}
});
}
//控制檯輸出:
01-02 21:30:27.445 2562 2562 D cdw : onResume :0複製程式碼從結果上看，我們在 WindowManager.addView 之後，也並沒有繪製介面。那麼，Android的繪製是什麼時候開始的?又是到什麼時候結束?
在 Android 系統中，每一次的繪製都是通過一個 16ms 左右的 VSYNC 訊號控制的，這種訊號可能來自於硬體也可能來自於軟體模擬。每一次非動畫的繪製，都包含：測量，佈局，繪製三個函式。而一般觸發這一事件的的動作有:
View的某些屬性的變更View重新佈局Layout- 增刪
View節點
當呼叫 WindowManager.addView 將空間新增到 WM 服務管理的時候，會呼叫一次Layout請求，這就觸發了一次 VSYNC 繪製。因此，我們只需要在 onResume 裡post 一個幀回撥就可以檢測繪製開始的時間:
@Override
protected void onResume() {
super.onResume();
Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
@Override
public void doFrame(long frameTimeNanos) {
//TODO 繪製開始
}
});
}複製程式碼我們先來看下 View.requestLayout 是怎麼觸發介面重新繪製的：
//code View.java
public void requestLayout() {
....
if (mParent != null) {
...
if (!mParent.isLayoutRequested()) {
mParent.requestLayout();
}
}
}複製程式碼View 物件呼叫 requestLayout 的時候會委託給自己的父節點處理，這裡之所以不稱為父控制元件而是父節點，是因為除了控制元件外，還有 ViewRootImpl 這個非控制元件型別作為父節點，而這個父節點會作為整個控制元件樹的根節點。按照我們上面說的委託的機制，requestLayout 最終將會呼叫到 ViewRootImpl.requestLayout。
//code ViewRootImpl.java
@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
scheduleTraversals();//申請繪製請求
}
}
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
....
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL， mTraversalRunnable， null);//申請繪製
....
}
}複製程式碼ViewRootImpl 最終會將 mTraversalRunnable 處理命令放到 CALLBACK_TRAVERSAL 繪製佇列中去:
final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();//執行佈局和繪製
}
}
void doTraversal() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
...
performTraversals();
...
}
}複製程式碼mTraversalRunnable 命令最終會呼叫到 performTraversals() 函式:
private void performTraversals() {
final View host = mView;
...
host.dispatchAttachedToWindow(mAttachInfo， 0);//attachWindow
...
getRunQueue().executeActions(attachInfo.mHandler);//執行某個指令
...
childWidthMeasureSpec = getRootMeasureSpec(desiredWindowWidth， lp.width);
childHeightMeasureSpec = getRootMeasureSpec(desiredWindowHeight， lp.height);
host.measure(childWidthMeasureSpec， childHeightMeasureSpec);//測量
....
host.layout(0， 0， host.getMeasuredWidth()， host.getMeasuredHeight());//佈局
...
draw(fullRedrawNeeded);//繪製
...
}複製程式碼performTraversals 函式實現了以下流程:
- 呼叫
dispatchAttachedToWindow通知子控制元件樹當前控制元件被attach到視窗中 - 執行一個命令佇列
getRunQueue - 執行
meausre測量指令 - 執行
layout佈局函式 - 執行繪製
draw
這裡我們看到一句方法呼叫:
getRunQueue().executeActions(attachInfo.mHandler);複製程式碼這個函式將執行一個延時的命令佇列，在 View 物件被 attach 到 View樹之前，通過呼叫 View.post 函式，可以將執行訊息命令加入到延時執行佇列中去:
/code View.java
public boolean post(Runnable action) {
Handler handler;
AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
handler = attachInfo.mHandler;
} else {
// Assume that post will succeed later
ViewRootImpl.getRunQueue().post(action);
return true;
}
return handler.post(action);
}複製程式碼getRunQueue().executeActions 函式執行的時候，會將該命令訊息延後一個UI執行緒訊息執行，這就保證了執行的這個命令訊息發生在我們的繪製之後:
//code RunQueue.java
void executeActions(Handler handler) {
synchronized (mActions) {
...
for (int i = 0; i < count; i++) {
final HandlerAction handlerAction = actions.get(i);
handler.postDelayed(handlerAction.action， handlerAction.delay);//推遲一個訊息
}
}
}複製程式碼所以，我們只需要在檢視被 attach 之前通過一個 View 來丟擲一個命令訊息，就可以檢測檢視繪製結束的時間點:
//code DemoActivity.java
@Override
protected void onResume() {
super.onResume();
Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
@Override
public void doFrame(long frameTimeNanos) {
start = SystemClock.uptimeMillis();
log("繪製開始:height = "+view.getHeight());
}
});
}
@Override
protected void onCreate( Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
view = new View(this);
view.post(new Runnable() {
@Override
public void run() {
log("繪製耗時:"+(SystemClock.uptimeMillis()-start)+"ms");
log("繪製結束後:height = "+view.getHeight());
}
});
this.setContentView(view);
}
//控制檯輸出:
01-03 23:39:27.251 27069 27069 D cdw : --->繪製開始:height = 0
01-03 23:39:27.295 27069 27069 D cdw : --->繪製耗時:44ms
01-03 23:39:27.295 27069 27069 D cdw : --->繪製結束後:height = 1232複製程式碼我們帶著我們上面的知識儲備，來看下SnackBar是如何做的呢:
3.Snackbar
SnackBar 系統主要依賴於兩個類：
SnackBar作為門面，與業務程式互動SnackBarManager作為時序管理器，SnackBar與SnackBarManager的互動，通過Callback回撥物件進行
SnackBarManager 的時序管理跟 NotifycationManager 的很類似不再贅述
SnackBar 通過靜態方法 make 靜態構造一個 SnackBar:
public static Snackbar make(@NonNull View view， @NonNull CharSequence text，
@Duration int duration) {
Snackbar snackbar = new Snackbar(findSuitableParent(view));
snackbar.setText(text);
snackbar.setDuration(duration);
return snackbar;
}複製程式碼這裡有一個關鍵函式 findSuitableParent ，這個函式的目的就相當於我們上面的 findViewById(R.id.content) 一樣，給 SnackBar 所定義的 Toast 控制元件找一個合適的容器:
private static ViewGroup findSuitableParent(View view) {
ViewGroup fallback = null;
do {
if (view instanceof CoordinatorLayout) {
return (ViewGroup) view;
} else if (view instanceof FrameLayout) {
if (view.getId() == android.R.id.content) {//把 `Content` 節點作為容器
...
return (ViewGroup) view;
} else {
// It`s not the content view but we`ll use it as our fallback
fallback = (ViewGroup) view;
}
}
...
} while (view != null);
// If we reach here then we didn`t find a CoL or a suitable content view so we`ll fallback
return fallback;
}複製程式碼我們發現，除了包含 CoordinatorLayout 控制元件的情況， 預設情況下， SnackBar 也是找的 Content 節點。找到的這個父節點，作為 Snackbar 構造器的形參:
private Snackbar(ViewGroup parent) {
mTargetParent = parent;
mContext = parent.getContext();
...
LayoutInflater inflater = LayoutInflater.from(mContext);
mView = (SnackbarLayout) inflater.inflate(
R.layout.design_layout_snackbar， mTargetParent， false);
...
}複製程式碼Snackbar 將生成一個 SnackbarLayout 控制元件作為 Toast 控制元件。最後當時序控制器 SnackBarManager 回撥返回的時候，通知 SnackBar 顯示，即將SnackBar.mView 增加到 mTargetParent 控制元件中去。
這裡有人或許會有疑問，這裡使用強引用，會不會造成一段時間內的記憶體洩漏呢？ 假如你現在彈了 10 個 Toast ，每個 Toast 的顯示時間是 2s 。也就是說你的最後一個 SnackBar 將被 SnackBarManager 持有至少 20s。而 SnackBar 中又存在有父控制元件 mTargetParent 的強引用。相當於在這20s內， 你的mTargetParent 和它所持有的 Context (一般是 Activity)無法釋放
這個其實是不會的，原因在於 SnackBarManager 在管理這種回撥 callback 的時候，採用了弱引用。
private static class SnackbarRecord {
final WeakReference<Callback> callback;
....
}複製程式碼但是，我們從 SnackBar 的設計可以看出，SnackBar無法定製具體的樣式: SnackBar 只能生成 SnackBarLayout 這種控制元件和佈局，可能並不滿足你的業務需求。當然你也可以變更 SnackBarLayout 也能達到目的。不過，有了上面的知識儲備，我們完全可以寫一個自己的 Snackbar。
4.基於Toast的改法
從第一篇文章我們知道，我們直接在 Toast.show 函式外增加 try-catch 是沒有意義的。因為 Toast.show 實際上只是發了一條命令給 NotificationManager 服務。真正的顯示需要等 NotificationManager 通知我們的 TN 物件 show 的時候才能觸發。NotificationManager 通知給 TN 物件的訊息，都會被 TN.mHandler這個內部物件進行處理
//code Toast.java
private static class TN {
final Runnable mHide = new Runnable() {// 通過 mHandler.post(mHide) 執行
@Override
public void run() {
handleHide();
mNextView = null;
}
};
final Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
IBinder token = (IBinder) msg.obj;
handleShow(token);// 處理 show 訊息
}
};
}複製程式碼在NotificationManager 通知給 TN 物件顯示的時候，TN 物件將給 mHandler 物件傳送一條訊息，並在 mHandler 的 handleMessage 函式中執行。 當NotificationManager 通知 TN 物件隱藏的時候，將通過 mHandler.post(mHide) 方法，傳送隱藏指令。不論採用哪種方式傳送的指令，都將執行 Handler 的dispatchMessage(Message msg) 函式:
//code Handler.java
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);// 執行 post(Runnable)形式的訊息
} else {
...
handleMessage(msg);// 執行 sendMessage形式的訊息
}
}複製程式碼因此，我們只需要在 dispatchMessage 方法體內加入 try-catch 就可以避免 Toast 崩潰對應用程式的影響:
public void dispatchMessage(Message msg) {
try {
super.dispatchMessage(msg);
} catch(Exception e) {}
}複製程式碼因此，我們可以定義一個安全的 Handler 裝飾器:
private static class SafelyHandlerWarpper extends Handler {
private Handler impl;
public SafelyHandlerWarpper(Handler impl) {
this.impl = impl;
}
@Override
public void dispatchMessage(Message msg) {
try {
super.dispatchMessage(msg);
} catch (Exception e) {}
}
@Override
public void handleMessage(Message msg) {
impl.handleMessage(msg);//需要委託給原Handler執行
}
}複製程式碼由於 TN.mHandler 物件複寫了 handleMessage 方法，因此，在 Handler 裝飾器裡，需要將 handleMessage 方法委託給 TN.mHandler 執行。定義完裝飾器之後，我們就可以通過反射往我們的 Toast 物件中注入了：
public class ToastUtils {
private static Field sField_TN ;
private static Field sField_TN_Handler ;
static {
try {
sField_TN = Toast.class.getDeclaredField("mTN");
sField_TN.setAccessible(true);
sField_TN_Handler = sField_TN.getType().getDeclaredField("mHandler");
sField_TN_Handler.setAccessible(true);
} catch (Exception e) {}
}
private static void hook(Toast toast) {
try {
Object tn = sField_TN.get(toast);
Handler preHandler = (Handler)sField_TN_Handler.get(tn);
sField_TN_Handler.set(tn,new SafelyHandlerWarpper(preHandler));
} catch (Exception e) {}
}
public static void showToast(Context context,CharSequence cs, int length) {
Toast toast = Toast.makeText(context,cs,length);
hook(toast);
toast.show();
}
}複製程式碼我們再用第一章中的程式碼測試一下：
public void showToast(View view) {
ToastUtils.showToast(this,"hello", Toast.LENGTH_LONG);
try {
Thread.sleep(10000);
} catch (InterruptedException e) {}
}複製程式碼等 10s 之後，程式正常執行，不會因為 Toast 的問題而崩潰。
相關閱讀
此文已由作者授權雲加社群釋出，轉載請註明文章出處