一. 情況簡介
最近在crash 平臺上出現了一個BadTokenException 的crash
android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@8493c73 is not valid; is your activity running?
at android.view.ViewRootImpl.setView(ViewRootImpl.java:826)
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:369)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:94)
at android.widget.Toast$TN.handleShow(Toast.java:459)
at android.widget.Toast$TN$2.handleMessage(Toast.java:342)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:185)
at android.app.ActivityThread.main(ActivityThread.java:6493)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:916)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:806)
從崩潰棧中可以看出這是一個和Toast 相關的crash。那么這個crash 是怎么產生的呢？
二. 產生原因
1. 穩定復現步驟：
在Toast.show()之后，UI線程做了耗時的操作阻塞了Handler message的處理，如使用Thread.sleep(5000)，然后這個崩潰就出現了。
Toast.makeText(TestActivity.this, "hhhhhhh", Toast.LENGTH_SHORT).show();
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
上面這段代碼，在7.1 以下系統不會發生崩潰，但Toast 也不會顯示，在7.1 系統則會在5s 后崩潰。這是因為7.1 系統對Toast 新添加了一些改變。
2. Android 7.1系統做的改變
7.1 系統（N MR1），主要改變就是Toast 顯示時需要一個Window Token（是一個Binder），當Toast 執行show 方法時會將自己的信息傳給NotificationManagerService ，該Service 有個內部類ToastRecord 用來記錄Toast 的信息，這時會為Toast 創建一個token，7.1 之前ToastRecord 并沒有token 屬性
所以，NotificationManagerService 在通知Toast 顯示時會將這個token 傳過去
上面代碼中的callback 的show 方法最后會調用Toast 中的TN 中的 Handler 的handleMessage 方法，然后執行handleShow 方法
然后這個token 被傳遞給WindowManager.LayoutParams ，WindowManager 執行addView 方法來顯示Toast，在addView 方法中如果token 失效就會拋出BadTokenException。通過上面的對比圖可以看出7.1 之前Toast 顯示不需要token 所以不會crash。
至于token 是怎么失效的，有這樣一個流程：
Toast 顯示會有一個時長，所以在NotificationManagerService 內也有兩個超時時長，跟Toast 的duration 有關，如果Toast 的duration設置的是LONG，則為3.5 s，如果是SHORT，則為2s。NotificationManagerService 會在調用Toast 的show 之后發送一個延時消息，延時時長就是超時時長，這個延時消息就是用來取消Toast 的顯示，取消顯示會有如下操作：
1）調用Toast 中TN 的hide 方法；
2）將相應index 的ToastRecord 從mToastQueue 隊列中移除；
3）將對應的token 移除
4）如果Toast 隊列不為空，顯示下一個Toast
可以看到有一步操作是移除token。所以，結論來了，當Toast 調用了show 發送了一個Message之后，UI 線程被阻塞住了，超時之后token 失效，這時show 操作接著執行addView 操作時，程序就會發現token 已失效從而拋出異常。
三. 解決方案
這個crash 在8.0（O）是不會存在，因為Google 大佬們也發現了這個問題并用神乎其技的方式進行了修復，沒錯就是try catch。下面是8.0 源碼
那么針對7.1 系統該怎么辦呢，可以考慮使用下面兩種方式
1. 使用其他提示方式代替Toast
?比如 SnackBar
2. 繼承一個Toast 并通過反射的方式將Handler 執行Message 的部分try catch 住
Google 大大都用的try catch 說明這個問題暫時沒有更好的解決方案，所以我們也可以用這種方式來做，下面是示例代碼
ToastCompat
class ToastCompat(context: Context) : Toast(context) {
companion object {
@JvmField val TAG = "ToastCompat"
@JvmStatic fun makeTextCompat(context: Context, text: CharSequence, duration: Int): Toast{
val result = ToastCompat(context)
val inflate = context.getSystemService(Context.LAYOUT_INFLATER_SERVICE) as LayoutInflater
val view = inflate.inflate(context.resources.getIdentifier("transient_notification", "layout", "android"), null)
val tv = view.findViewById<TextView>(android.R.id.message)
tv.text = text
result.view = view
result.duration = duration
return result
}
@JvmStatic private fun setFieldValue(obj: Any, fieldName: String, newValue: Any) {
val field = getDeclaredField(obj, fieldName)
field?.let {
val modifierField = Field::class.java.getDeclaredField("accessFlags")
modifierField.isAccessible = true
modifierField.setInt(field, field.modifiers and Modifier.FINAL.inv())
if (!field.isAccessible) {
field.isAccessible = true
}
field.set(obj, newValue)
}
}
@JvmStatic private fun getFieldValue(obj: Any, fieldName: String): Any? {
val field = getDeclaredField(obj, fieldName)
field?.let {
if (!field.isAccessible) {
field.isAccessible = true
}
return field.get(obj)
}
return null
}
@JvmStatic private fun getDeclaredField(obj: Any, fieldName: String): Field? {
var superClass = obj.javaClass
while (superClass != Any::class.java) {
try {
return superClass.getDeclaredField(fieldName)
} catch (e: NoSuchFieldException) {
superClass = superClass.getSuperclass()
continue// new add
}
}
return null
}
}
override fun show() {
if (Build.VERSION.SDK_INT == Build.VERSION_CODES.N_MR1) {
fixBug()
}
super.show()
}
private fun fixBug() {
try {
val mTN = getFieldValue(this, "mTN")
mTN?.let {
val rawHandler = getFieldValue(mTN, "mHandler") as? Handler
rawHandler?.let {
setFieldValue(rawHandler, "mCallback", InternalHandlerCallback(rawHandler))
}
}
} catch (e: Throwable) {
e.printStackTrace()
}
}
private class InternalHandlerCallback(private val mHandler: Handler) : Handler.Callback {
override fun handleMessage(msg: Message?): Boolean {
try {
mHandler.handleMessage(msg)
} catch (e: Throwable) {
e.printStackTrace()
}
return true
}
}
}
參考：
不同版本代碼區別
