Android技術分享|【Android踩坑】懷疑人生，主線程修改UI也會崩潰?
前言
某天早晨，吃完早餐，坐回工位，打開電腦，開啟chrome，進入友盟頁面，發現了一個崩潰信息：
java.lang.RuntimeException: Unable to resume activity {com.youdao.youdaomath/com.youdao.youdaomath.view.PayCourseVideoActivity}: android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3824)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3856)
at android.app.servertransaction.ResumeActivityItem.execute(ResumeActivityItem.java:51)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:145)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:70)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1831)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:201)
at android.app.ActivityThread.main(ActivityThread.java:6806)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:547)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:873)
Caused by: android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:8000)
at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:1292)
at android.view.View.requestLayout(View.java:23147)
at android.view.View.requestLayout(View.java:23147)
at android.widget.TextView.checkForRelayout(TextView.java:8914)
at android.widget.TextView.setText(TextView.java:5736)
at android.widget.TextView.setText(TextView.java:5577)
at android.widget.TextView.setText(TextView.java:5534)
at android.widget.Toast.setText(Toast.java:332)
at com.youdao.youdaomath.view.common.CommonToast.showShortToast(CommonToast.java:40)
at com.youdao.youdaomath.view.PayCourseVideoActivity.checkNetWork(PayCourseVideoActivity.java:137)
at com.youdao.youdaomath.view.PayCourseVideoActivity.onResume(PayCourseVideoActivity.java:218)
at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1413)
at android.app.Activity.performResume(Activity.java:7400)
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3816)
一眼看上去似乎是比較常見的子線程修改UI的問題。並且是在Toast上面報出的，常識吿訴我Toast在子線程彈出是會報錯，但是應該是提示Looper沒有生成的錯，而不應該是上面所報出的錯誤。那麼會不會是生成Looper以後報的錯的?
一、Demo 驗證
所以我先做了一個demo，如下：
@Override
protected void onResume() {
super.onResume();
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
Toast.makeText(MainActivity.this,"子線程彈出Toast",Toast.LENGTH_SHORT).show();
}
});
thread.start();
}
運行一下，果不其然崩潰掉,錯誤信息就是提示我必須準備好looper才能彈出toast：
java.lang.RuntimeException: Can't toast on a thread that has not called Looper.prepare()
at android.widget.Toast$TN.<init>(Toast.java:393)
at android.widget.Toast.<init>(Toast.java:117)
at android.widget.Toast.makeText(Toast.java:280)
at android.widget.Toast.makeText(Toast.java:270)
at com.netease.photodemo.MainActivity$1.run(MainActivity.java:22)
at java.lang.Thread.run(Thread.java:764)
接下來就在toast裏面準備好looper，再試試吧：
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
Looper.prepare();
Toast.makeText(MainActivity.this,"子線程彈出Toast",Toast.LENGTH_SHORT).show();
Looper.loop();
}
});
thread.start();
運行發現是能夠正確的彈出Toast的：
那麼問題就來了，為什麼會在友盟中出現這個崩潰呢？
二、再探堆棧
然後仔細看了下報錯信息有兩行重要信息被我之前略過了:
at com.youdao.youdaomath.view .PayCourseVideoActivity.onResume(PayCourseVideoActivity.java:218) android.widget.Toast.setText(Toast.java:332)
發現是在主線程報了Toast設置Text的時候的錯誤。這就讓我很納悶了，子線程修改UI會報錯，主線程也會報錯？
感覺這麼多年Android白做了。這不是最基本的知識麼？
於是我只能硬着頭皮往源碼深處看了:
先來看看Toast是怎麼setText的：
public static Toast makeText(@NonNull Context context, @Nullable Looper looper,
@NonNull CharSequence text, @Duration int duration) {
Toast result = new Toast(context, looper);
LayoutInflater inflate = (LayoutInflater)
context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
View v = inflate.inflate(com.android.internal.R.layout.transient_notification, null);
TextView tv = (TextView)v.findViewById(com.android.internal.R.id.message);
tv.setText(text);
result.mNextView = v;
result.mDuration = duration;
return result;
}
很常規的一個做法，先是inflate出來一個View對象，再從View對象找出對應的TextView，然後TextView將文本設置進去。
至於setText在之前有詳細説過，是在ViewRootImpl裏面進行checkThread是否在主線程上面。所以感覺似乎一點問題都沒有。那麼既然出現了這個錯誤，總得有原因吧，或許是自己源碼看漏了?
那就重新再看一遍ViewRootImpl#checkThread方法吧:
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
這一看，還真的似乎給我了一點頭緒，系統在checkThread的時候並不是將Thread.currentThread和MainThread作比較，而是跟mThread作比較，那麼有沒有一種可能mThread是子線程?
一想到這裏，我就興奮了，全類查看mThread到底是怎麼初始化的：
public ViewRootImpl(Context context, Display display) {
...代碼省略...
mThread = Thread.currentThread();
...代碼省略...
}
可以發現全類只有這一處對mThread進行了賦值。那麼會不會是子線程初始化了ViewRootimpl呢？似乎我之前好像也沒有研究過Toast為什麼會彈出來，所以順便就先去了解下Toast是怎麼show出來的好了：
/**
* Show the view for the specified duration.
*/
public void show() {
if (mNextView == null) {
throw new RuntimeException("setView must have been called");
}
INotificationManager service = getService();
String pkg = mContext.getOpPackageName();
TN tn = mTN;
tn.mNextView = mNextView;
try {
service.enqueueToast(pkg, tn, mDuration);
} catch (RemoteException e) {
// Empty
}
}
調用Toast的show方法時，會通過Binder獲取Service即NotificationManagerService，然後執行enqueueToast方法（NotificationManagerService的源碼就不做分析），然後會執行Toast裏面如下方法:
@Override
public void show(IBinder windowToken) {
if (localLOGV) Log.v(TAG, "SHOW: " + this);
mHandler.obtainMessage(SHOW, windowToken).sendToTarget();
}
發送一個Message，通知進行show的操作：
@Override
public void show(IBinder windowToken) {
if (localLOGV) Log.v(TAG, "SHOW: " + this);
mHandler.obtainMessage(SHOW, windowToken).sendToTarget();
}
在Handler的handleMessage方法中找到了SHOW的case，接下來就要進行真正show的操作了：
public void handleShow(IBinder windowToken) {
if (localLOGV) Log.v(TAG, "HANDLE SHOW: " + this + " mView=" + mView
+ " mNextView=" + mNextView);
// If a cancel/hide is pending - no need to show - at this point
// the window token is already invalid and no need to do any work.
if (mHandler.hasMessages(CANCEL) || mHandler.hasMessages(HIDE)) {
return;
}
if (mView != mNextView) {
// remove the old view if necessary
handleHide();
mView = mNextView;
Context context = mView.getContext().getApplicationContext();
String packageName = mView.getContext().getOpPackageName();
if (context == null) {
context = mView.getContext();
}
mWM = (WindowManager)context.getSystemService(Context.WINDOW_SERVICE);
// We can resolve the Gravity here by using the Locale for getting
// the layout direction
final Configuration config = mView.getContext().getResources().getConfiguration();
final int gravity = Gravity.getAbsoluteGravity(mGravity, config.getLayoutDirection());
mParams.gravity = gravity;
if ((gravity & Gravity.HORIZONTAL_GRAVITY_MASK) == Gravity.FILL_HORIZONTAL) {
mParams.horizontalWeight = 1.0f;
}
if ((gravity & Gravity.VERTICAL_GRAVITY_MASK) == Gravity.FILL_VERTICAL) {
mParams.verticalWeight = 1.0f;
}
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;
mParams.token = windowToken;
if (mView.getParent() != null) {
if (localLOGV) Log.v(TAG, "REMOVE! " + mView + " in " + this);
mWM.removeView(mView);
}
if (localLOGV) Log.v(TAG, "ADD! " + mView + " in " + this);
// Since the notification manager service cancels the token right
// after it notifies us to cancel the toast there is an inherent
// race and we may attempt to add a window after the token has been
// invalidated. Let us hedge against that.
try {
mWM.addView(mView, mParams);
trySendAccessibilityEvent();
} catch (WindowManager.BadTokenException e) {
/* ignore */
}
}
}
代碼有點長，我們最需要關心的就是mWm.addView方法。
相信看過ActivityThread的同學應該知道mWm.addView方法是在ActivityThread的handleResumeActivity裏面也有調用過，意思就是進行ViewRootImpl的初始化，然後通過ViewRootImp進行View的測量，佈局，以及繪製。
看到這裏，我想到了一個可能的原因：
那就是我的Toast是一個全局靜態的Toast對象，然後第一次是在子線程的時候show出來，這個時候ViewRootImpl在初始化的時候就會將子線程的對象作為mThread，然後下一次在主線程彈出來就出錯了吧？想想應該是這樣的。
三、再探Demo
所以繼續做我的demo來印證我的想法：
@Override
protected void onResume() {
super.onResume();
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
Looper.prepare();
sToast = Toast.makeText(MainActivity.this,"子線程彈出Toast",Toast.LENGTH_SHORT);
sToast.show();
Looper.loop();
}
});
thread.start();
}
public void click(View view) {
sToast.setText("主線程彈出Toast");
sToast.show();
}
做了個靜態的toast，然後點擊按鈕的時候彈出toast，運行一下：
發現竟然沒問題，這時候又開始懷疑人生了，這到底怎麼回事。ViewRootImpl此時的mThread應該是子線程啊，沒道理還能正常運行，怎麼辦呢？debug一步一步調試吧，一步一步調試下來，發現在View的requestLayout裏面parent竟然為空了：
然後在仔細看了下當前View是一個LinearLayout，然後這個View的子View是TextView，文本內容是"主線程彈出toast"，所以應該就是Toast在new的時候inflate的佈局
View v = inflate.inflate(com.android.internal.R.layout.transient_notification, null);
找到了對應的toast佈局文件，打開一看，果然如此：
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical"
android:background="?android:attr/toastFrameBackground">
<TextView
android:id="@android:id/message"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_weight="1"
android:layout_marginHorizontal="24dp"
android:layout_marginVertical="15dp"
android:layout_gravity="center_horizontal"
android:textAppearance="@style/TextAppearance.Toast"
android:textColor="@color/primary_text_default_material_light"
/>
</LinearLayout>
也就是説此時的View已經是頂級View了，它的parent應該就是ViewRootImpl，那麼為什麼ViewRootImpl是null呢，明明之前已經show過了。看來只能往Toast的hide方法找原因了
四、深入源碼
所以重新回到Toast的類中,查看下Toast的hide方法(此處直接看Handler的hide處理，之前的操作與show類似):
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);
}
// Now that we've removed the view it's safe for the server to release
// the resources.
try {
getService().finishToken(mPackageName, this);
} catch (RemoteException e) {
}
mView = null;
}
}
此處調用了mWm的removeViewImmediate，即WindowManagerImpl裏面的removeViewImmediate方法：
@Override
public void removeViewImmediate(View view) {
mGlobal.removeView(view, true);
}
會調用WindowManagerGlobal的removeView方法：
public void removeView(View view, boolean immediate) {
if (view == null) {
throw new IllegalArgumentException("view must not be null");
}
synchronized (mLock) {
int index = findViewLocked(view, true);
View curView = mRoots.get(index).getView();
removeViewLocked(index, immediate);
if (curView == view) {
return;
}
throw new IllegalStateException("Calling with view " + view
+ " but the ViewAncestor is attached to " + curView);
}
}
然後調用removeViewLocked方法：
private void removeViewLocked(int index, boolean immediate) {
ViewRootImpl root = mRoots.get(index);
View view = root.getView();
if (view != null) {
InputMethodManager imm = InputMethodManager.getInstance();
if (imm != null) {
imm.windowDismissed(mViews.get(index).getWindowToken());
}
}
boolean deferred = root.die(immediate);
if (view != null) {
//此處調用View的assignParent方法將viewParent置空
view.assignParent(null);
if (deferred) {
mDyingViews.add(view);
}
}
}
所以也就是説在Toast時間到了以後，會調用hide方法，此時會將parent置成空，所以我剛才試的時候才沒有問題。那麼按道理説只要在Toast沒有關閉的時候點擊再次彈出toast應該就會報錯。
所以還是原來的代碼，再來一次，這次不等Toast關閉，再次點擊：
果然如預期所料，此時在主線程彈出Toast就會崩潰。
五、發現原因
那麼問題原因找到了：
是在項目子線程中有彈出過Toast，然後Toast並沒有關閉，又在主線程彈出了同一個對象的toast，會造成崩潰。
此時內心有個困惑：
如果是子線程彈出Toast，那我就需要寫Looper.prepare方法和Looper.loop方法，為什麼我自己一點印象都沒有。
於是我全局搜索了Looper.prepare，發現並沒有找到對應的代碼。所以我就全局搜索了Toast調用的地方，發現在JavaBridge的回調當中找到了：
class JSInterface {
@JavascriptInterface
public void handleMessage(String msg) throws JSONException {
LogHelper.e(TAG, "msg::" + msg);
JSONObject jsonObject = new JSONObject(msg);
String callType = jsonObject.optString(JS_CALL_TYPE);
switch (callType) {
...代碼省略..
case JSCallType.SHOW_TOAST:
showToast(jsonObject);
break;
default:
break;
}
}
}
/**
* 彈出吐司
* @param jsonObject
* @throws JSONException
*/
public void showToast(JSONObject jsonObject) throws JSONException {
JSONObject payDataObj = jsonObject.getJSONObject("data");
String message = payDataObj.optString("data");
CommonToast.showShortToast(message);
}
但是看到這段代碼，又有疑問了，我並沒有在Javabridge的回調中看到有任何準備Looper的地方，那麼為什麼Toast沒有崩潰掉？
所以在此處加了一段代碼：
class JSInterface {
@JavascriptInterface
public void handleMessage(String msg) throws JSONException {
LogHelper.e(TAG, "msg::" + msg);
JSONObject jsonObject = new JSONObject(msg);
String callType = jsonObject.optString(JS_CALL_TYPE);
Thread currentThread = Thread.currentThread();
Looper looper = Looper.myLooper();
switch (callType) {
...代碼省略..
case JSCallType.SHOW_TOAST:
showToast(jsonObject);
break;
default:
break;
}
}
}
並且加了一個斷點，來查看下此時的情況：
確實當前線程是JavaBridge線程,另外JavaBridge線程中已經提前給開發者準備好了Looper。所以也難怪一方面奇怪自己怎麼沒有寫Looper的印象，一方面又很好奇為什麼這個線程在開發者沒有準備Looper的情況下也能正常彈出Toast。
總結
至此，真相終於找出來了。
相比較發生這個bug 的原因，解決方案就顯得非常簡單了。
只需要在CommonToast的showShortToast方法內部判斷是否為主線程調用，如果不是的話，new一個主線程的Handler，將Toast扔到主線程彈出來。
這樣就會避免了子線程彈出。
PS：本人還得吐槽一下Android，Android官方一方面明明宣稱不能在主線程以外的線程進行UI的更新， 另一方面在初始化ViewRootImpl的時候又不把主線程作為成員變量保存起來，而是直接獲取當前所處的線程作為mThread保存起來，這樣做就有可能會出現子線程更新UI的操作。 從而引起類似我今天的這個bug。
- 設計模式之狀態模式
- 如何實現數據庫讀一致性
- 我是怎麼入行做風控的
- C 11精要：部分語言特性
- 吳恩達來信：人工智能領域的求職小 tips
- EasyCV帶你復現更好更快的自監督算法-FastConvMAE
- 某車聯網App 通訊協議加密分析(四) Trace Code
- 帶你瞭解CANN的目標檢測與識別一站式方案
- EasyNLP玩轉文本摘要（新聞標題）生成
- PostgreSQL邏輯複製解密
- 基於 CoreDNS 和 K8s 構建雲原生場景下的企業級 DNS
- 循環神經網絡（RNN）可是在語音識別、自然語言處理等其他領域中引起了變革！
- 技術分享| 分佈式系統中服務註冊發現組件的原理及比較
- 利用谷歌地圖採集外貿客户的電話和手機號碼
- 跟我學Python圖像處理丨關於圖像金字塔的圖像向下取樣和向上取樣
- 帶你掌握如何使用CANN 算子ST測試工具msopst
- 一招教你如何高效批量導入與更新數據
- 一步步搞懂MySQL元數據鎖（MDL）
- 你知道如何用 PHP 實現多進程嗎？
- KubeSphere 網關的設計與實現（解讀）