Android的UI訪問是沒有加鎖的，這樣在多個執行緒訪問UI是不安全的。所以Android中規定只能在UI執行緒中訪問UI。

但是有沒有極端的情況？使得我們在子執行緒中訪問UI也可以使程式跑起來呢？接下來我們用一個例子去證實一下。

新建一個工程，activity_main.xml佈局如下所示：

Java <?xml version="1.0" encoding="utf-8"?> <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" > <TextView android:id="@+id/main_tv" android:layout_width="wrap_content" android:layout_height="wrap_content" android:textSize="18sp" android:layout_centerInParent="true" /> </RelativeLayout>

123456789101112131415

<?xml version="1.0"encoding="utf-8"?><RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"android:layout_width="match_parent"android:layout_height="match_parent"><TextViewandroid:id="@+id/main_tv"android:layout_width ="wrap_content"android:layout_height="wrap_content"android:textSize="18sp"android:layout_centerInParent="true"/></RelativeLayout>

很簡單，只是添加了一個居中的TextView

MainActivity程式碼如下所示：

Java public class MainActivity extends AppCompatActivity { private TextView main_tv; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); main_tv = (TextView) findViewById(R.id.main_tv); new Thread(new Runnable() { @Override public void run() { main_tv.setText("子執行緒中訪問"); } }).start(); } }

12345678910111213141516171819202122

publicclassMainActivityextendsAppCompatActivity{privateTextView main_tv;@OverrideprotectedvoidonCreate(Bundle savedInstanceState){super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);main_tv=(TextView)findViewById(R.id.main_tv);newThread(newRunnable(){@Overridepublicvoidrun(){main_tv.setText("子執行緒中訪問");}}).start();}}

也是很簡單的幾行，在onCreate方法中建立了一個子執行緒，並進行UI訪問操作。

點選執行。你會發現即使在子執行緒中訪問UI，程式一樣能跑起來。結果如下所示：

咦，那為嘛以前在子執行緒中更新UI會報錯呢？難道真的可以在子執行緒中訪問UI？

先不急，這是一個極端的情況，修改MainActivity如下：

Java public class MainActivity extends AppCompatActivity { private TextView main_tv; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); main_tv = (TextView) findViewById(R.id.main_tv); new Thread(new Runnable() { @Override public void run() { try { Thread.sleep(200); } catch (InterruptedException e) { e.printStackTrace(); } main_tv.setText("子執行緒中訪問"); } }).start(); } }

123456789101112131415161718192021222324252627

publicclassMainActivityextendsAppCompatActivity{privateTextView main_tv;@OverrideprotectedvoidonCreate(Bundle savedInstanceState){super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);main_tv=(TextView)findViewById(R.id.main_tv);newThread(newRunnable(){@Overridepublicvoidrun(){try{Thread.sleep(200);}catch(InterruptedExceptione){e.printStackTrace();}main_tv.setText("子執行緒中訪問");}}).start();}}

讓子執行緒睡眠200毫秒，醒來後再進行UI訪問。

結果你會發現，程式崩了。這才是正常的現象嘛。丟擲瞭如下很熟悉的異常：

android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRootImpl.checkThread(ViewRootImpl.Java:6581)
at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:924)

……

作為一名開發者，我們應該認真閱讀一下這些異常資訊，是可以根據這些異常資訊來找到為什麼一開始的那種情況可以訪問UI的。那我們分析一下異常資訊：

首先，從以下異常資訊可以知道

Java at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:6581)

1	at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:6581)

這個異常是從android.view.ViewRootImpl的checkThread方法丟擲的。

那現在跟進ViewRootImpl的checkThread方法瞧瞧，原始碼如下：

Java void checkThread() { if (mThread != Thread.currentThread()) { throw new CalledFromWrongThreadException( "Only the original thread that created a view hierarchy can touch its views."); } }

123456

voidcheckThread(){if(mThread!=Thread.currentThread()){thrownewCalledFromWrongThreadException("Only the original thread that created a view hierarchy can touch its views.");}}

只有那麼幾行程式碼而已的，而mThread是主執行緒，在應用程式啟動的時候，就已經被初始化了。

由此我們可以得出結論：
在訪問UI的時候，ViewRootImpl會去檢查當前是哪個執行緒訪問的UI，如果不是主執行緒，那就會丟擲如下異常：

Java Only the original thread that created a view hierarchy can touch its views

1	Only the original thread that createdaview hierarchy can touch its views

這好像並不能解釋什麼？繼續看到異常資訊

Java at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:924)

1	at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:924)

那現在就看看requestLayout方法，

Java @Override public void requestLayout() { if (!mHandlingLayoutInLayoutRequest) { checkThread(); mLayoutRequested = true; scheduleTraversals(); } }

12345678

@OverridepublicvoidrequestLayout(){if(!mHandlingLayoutInLayoutRequest){checkThread();mLayoutRequested=true;scheduleTraversals();}}

這裡也是呼叫了checkThread()方法來檢查當前執行緒，咦？除了檢查執行緒好像沒有什麼資訊。那再點進scheduleTraversals()方法看看

Java void scheduleTraversals() { if (!mTraversalScheduled) { mTraversalScheduled = true; mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier(); mChoreographer.postCallback( Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); if (!mUnbufferedInputDispatch) { scheduleConsumeBatchedInput(); } notifyRendererOfFramePending(); pokeDrawLockIfNeeded(); } }

12345678910111213

voidscheduleTraversals(){if(!mTraversalScheduled){mTraversalScheduled=true;mTraversalBarrier=mHandler.getLooper().getQueue().postSyncBarrier();mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL,mTraversalRunnable,null);if(!mUnbufferedInputDispatch){scheduleConsumeBatchedInput();}notifyRendererOfFramePending();pokeDrawLockIfNeeded();}}

注意到postCallback方法的的第二個引數傳入了很像是一個後臺任務。那再點進去

Java final class TraversalRunnable implements Runnable { @Override public void run() { doTraversal(); } }

123456

finalclassTraversalRunnableimplementsRunnable{@Overridepublicvoidrun(){doTraversal();}}

找到了，那麼繼續跟進doTraversal()方法。

Java void doTraversal() { if (mTraversalScheduled) { mTraversalScheduled = false; mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier); if (mProfile) { Debug.startMethodTracing("ViewAncestor"); } performTraversals(); if (mProfile) { Debug.stopMethodTracing(); mProfile = false; } } }

1234567891011121314151617

voiddoTraversal(){if(mTraversalScheduled){mTraversalScheduled=false;mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);if(mProfile){Debug.startMethodTracing("ViewAncestor");}performTraversals();if(mProfile){Debug.stopMethodTracing();mProfile=false;}}}

可以看到裡面呼叫了一個performTraversals()方法，View的繪製過程就是從這個performTraversals方法開始的。PerformTraversals方法的程式碼有點長就不貼出來了，如果繼續跟進去就是學習View的繪製了。而我們現在知道了，每一次訪問了UI，Android都會重新繪製View。這個是很好理解的。

分析到了這裡，其實異常資訊對我們幫助也不大了，它只告訴了我們子執行緒中訪問UI在哪裡丟擲異常。
而我們會思考：當訪問UI時，ViewRootImpl會呼叫checkThread方法去檢查當前訪問UI的執行緒是哪個，如果不是UI執行緒則會丟擲異常，這是沒問題的。但是為什麼一開始在MainActivity的onCreate方法中建立一個子執行緒訪問UI，程式還是正常能跑起來呢？？
唯一的解釋就是執行onCreate方法的那個時候ViewRootImpl還沒建立，無法去檢查當前執行緒。

那麼就可以這樣深入進去。尋找ViewRootImpl是在哪裡，是什麼時候建立的。好，繼續前進

在ActivityThread中，我們找到handleResumeActivity方法，如下：

Java final void handleResumeActivity(IBinder token, boolean clearHide, boolean isForward, boolean reallyResume) { // If we are getting ready to gc after going to the background, well // we are back active so skip it. unscheduleGcIdler(); mSomeActivitiesChanged = true; // TODO Push resumeArgs into the activity for consideration ActivityClientRecord r = performResumeActivity(token, clearHide); if (r != null) { final Activity a = r.activity; //程式碼省略 r.activity.mVisibleFromServer = true; mNumVisibleActivities++; if (r.activity.mVisibleFromClient) { r.activity.makeVisible(); } } //程式碼省略 }

123456789101112131415161718192021222324

finalvoidhandleResumeActivity(IBinder token,booleanclearHide,booleanisForward,booleanreallyResume){// If we are getting ready to gc after going to the background, well// we are back active so skip it.unscheduleGcIdler();mSomeActivitiesChanged=true;// TODO Push resumeArgs into the activity for considerationActivityClientRecordr=performResumeActivity(token,clearHide);if(r!=null){finalActivitya=r.activity;//程式碼省略r.activity.mVisibleFromServer=true;mNumVisibleActivities++;if(r 相關推薦 Android子執行緒中更新UI的3種方法 //UI執行緒中執行 new DownloadImageTask().execute( "www.91dota.com" ); private class DownloadImageTask extends AsyncTask { protected String doInBackgrou 多執行緒學習之--真的不能在子執行緒裡更新UI嗎？ 在我們學習多執行緒的路上，都會聽到這樣一句話： 不能在子執行緒裡更新UI，UI更新必須在UI執行緒中 why？為什麼不能在子執行緒中更新UI？如果在子執行緒中更新UI會怎樣？ 為了模擬在子執行緒中更新UI的場景，簡單地寫了幾行程式碼： Android 中子執行緒真的不能更新UI嗎？ Android的UI訪問是沒有加鎖的，這樣在多個執行緒訪問UI是不安全的。所以Android中規定只能在UI執行緒中訪問UI。 但是有沒有極端的情況？使得我們在子執行緒中訪問UI也可以使程式跑起來呢？接下來我們用一個例子去證實一下。 新建一個工程，activity_main.x Android執行緒模型--在子執行緒中更新UI        Android是支援多執行緒的。主執行緒也稱UI執行緒，子執行緒也稱工作執行緒。一般耗時操作在子執行緒中進行，更新UI操作在主執行緒中進行。在主執行緒中執行耗時操作容易發生ANR錯誤，即應用程式無響應。而Android中又規定只有建立UI的執行緒 android-如何在子執行緒中更新ui 正如我們知道的，android是不讓在子執行緒中更新ui的。在子執行緒中更新ui會直接丟擲異常 Only the original thread that created a view hierarchy can touch its views 那麼這種檢查 Android多執行緒之（一）View.post()原始碼分析——在子執行緒中更新UI        提起View.post()，相信不少童鞋一點都不陌生，它用得最多的有兩個功能，使用簡便而且實用：        1）在子執行緒中更新UI。從子執行緒中切換到主執行緒更新UI，不需要額外new一個Handler例項來實 在子執行緒中更新UI        和許多其他的GUI庫一樣，Android的UI也是執行緒不安全的。也就是說，如果想要更新應用程式裡的UI元素，則必須在主執行緒中進行，否則就會出現異常。 一、新建一個AndroidThreadTest專案，然後修改activity_main. Qt子執行緒如何更新UI，完整的程式碼示例，有圖有真相       Qt涉及到大量的資料更新，影象處理，視訊編解碼時，在主執行緒直接進行會讓主執行緒阻塞，程式直接卡死，直達阻塞的部分完成，介面才更新，例如，我們需要在TextBrowser上迴圈顯示資料。        我需要點選【新增新行資料】，然後每隔1秒迴圈顯示資料，之 為什麼我們可以在非UI執行緒中更新UI                 尊重原創轉載請註明：From AigeStudio（http://blog.csdn.net/aigestudio）Power by Aige 侵權必究！炮兵鎮樓看到這樣的標題……估計N多人會說我是逗比…………因為很多盆友在學習Android（特別是從4.0之後開始入門的）的時 跨執行緒直接更新UI控制元件彙總 成文表分享交流之意，惶恐水平有限，文中理解和表述有錯誤之處還請大家多被批評指正。 更新記錄： 2018年2月3日，根據網友評論提示更新錯別字，BegainInvoke=》BeginInvoke。 正文 1. 通過UI執行緒的SynchronizationCon Looper.prepare()和Looper.loop()，在子執行緒中更新UI 當子執行緒想直接更新UI時，例如進行Toast提示。 可以先Looper.prepare(),然後Looper.loop()，程式碼如下(加黑處)： public class CrashHandler implements UncaughtExceptionHandler 安卓學習筆記（一）——執行緒的用法及怎樣在子執行緒中更新UI 建立執行緒方法： 1、新建一個繼承自Thread的類MyThread，然後重寫父類的run()方法，在裡面寫要執行的內容； class MyThread extends Thread { @Ove 使用Handler在子執行緒中更新UI 我們知道，使用者的耐性是有極限的。一般來說，一個請求如果2到5秒鐘沒有響應，使用者就會想砸機器。為了優化使用者的互動設計，就不能阻塞UI執行緒，也就是不能在UI執行緒中執行耗時的操作，比如說網路請求。但是這種耗時操作是不可避免的，所以耗時操作只能放到子執行緒中。一個耗時操作 執行緒與更新UI，消除偏見，細談原理 ## 前言 相信不少讀者都閱讀過相類似的文章了，但是我還是想完整的把這之間的關係梳理清楚，細節聊好，希望你也能從中學到一些。 進入正題，大家應該都聽過這樣一句話——**“UI更新要在主執行緒，子執行緒更新UI會崩潰”**。久而久之就感覺這是個真理，甚至被認為是“官方結論”。 但是如果問你，官方什麼時候在 Android子執行緒真的不能更新UI嗎？讓我們從原始碼的角度一探究竟 關於主執行緒更新UI這已經是個老生常談的話題，幾乎所有人都知道Android要在主執行緒更新UI。 Android官方文件這樣描述：Android UI操作並不是執行緒安全的，並且這些操作必須在UI執行緒執行。 那麼，子執行緒到底能否更新UI，如果不能更新U Android 子執行緒更新UI【通過RunOnUI】 在Fragment中無法直接使用runonuithread   runOnUiThread這個方法只存在於Activity中，想用它必須獲取Activity的例項。   MainActiivty.this.runOnUiThread()，就沒問 Android 子執行緒UI更新操作之二------AsyncTask 為了更方便的對子執行緒的中的UI進行操作，android提供了一些好用的工具，比如AsyncTask。藉助這個就可以簡單的從子執行緒切換到主執行緒。 當然這個工具也是基於非同步訊息處理機制的，只是安卓做了很好的封裝。 首先要說明的是AsyncTask是一個抽線類，要使用它 Android 子執行緒更新UI 異常 眾所周知，Android是不可以在子執行緒中直接更新UI的，需要藉助Handler或者View.post(Runnable runnable)或者runOnUIThread(Runnable runnable)將更新的程式碼切入到主執行緒中去實現UI更新。 我們來試一下，在Activity的 onCreat android後臺執行緒更新UI Android中後臺執行緒是無法直接更新UI程式的，這和Qt是一樣的； 如果想要線上程中更新UI，一般有一下幾個方法： 方法一： 在主執行緒中，繼承重新Handler類，重寫handleMessage函式，接受通過myHandler物件傳送的訊息； Handler my android為什麼不允許在子執行緒中訪問UI 首先，UI控制元件不是執行緒安全的，如果多執行緒併發訪問UI控制元件可能會出現不可預期的狀態 那為什麼系統不對UI控制元件的訪問加上鎖機制呢？ 缺點有兩個： 加上鎖機制會讓UI訪問的邏輯變得複雜； 鎖機制會降低UI訪問的效率，因為鎖機制會阻塞某些執行緒的執行