android 在非UI線程更新UI仍然成功原因深入剖析，androidui

android 在非UI線程更新UI仍然成功原因深入剖析，androidui

”只能在UI主線程中更新View“。

這句話很熟悉吧？

來來，哥們，看一下下面的例子

@Override      protected void onCreate(Bundle savedInstanceState) {          super.onCreate(savedInstanceState);          setContentView(R.layout.activity_main);          tv = (TextView) findViewById(R.id.tv);          Thread.currentThread().setName("UIThread");                    new LooperThread("非主線程修改").start();      }        private class LooperThread extends Thread {            private String text;            public LooperThread(String text) {              this.text = text;          }            @Override          public void run() {              Thread.currentThread().setName("OtherThread");              tv.setText(text);          }      }  

代碼這麼寫，不是逗比嗎！肯定崩啊！但是，如果你試一下，你會發現，絕大多數是不會崩的。至於極少數會崩潰的原因，我一會再說。

你可能會很疑惑，不是”只能在UI主線程中更新View“嗎？你這個在子線程裡面更新View，為什麼不會崩呢？

那麼，你再看下面的代碼，這樣寫就肯定崩

public void changeNoUI(View view) {       new LooperThread("非主線程修改").start();  } 

調用的代碼和上面的一樣，只不過是我們是給一個Button設定了點擊事件，然後自己手動調用的，這樣就肯定會崩潰，報什麼錯呢？

 

報下面的錯

02-02 16:44:38.786: E/AndroidRuntime(17907): FATAL EXCEPTION: OtherThread  02-02 16:44:38.786: E/AndroidRuntime(17907): Process: com.example.demo, PID: 17907  02-02 16:44:38.786: E/AndroidRuntime(17907): android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.  02-02 16:44:38.786: E/AndroidRuntime(17907):    at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:6226)  02-02 16:44:38.786: E/AndroidRuntime(17907):    at android.view.ViewRootImpl.invalidateChildInParent(ViewRootImpl.java:883)  02-02 16:44:38.786: E/AndroidRuntime(17907):    at android.view.ViewGroup.invalidateChild(ViewGroup.java:4320)  02-02 16:44:38.786: E/AndroidRuntime(17907):    at android.view.View.invalidate(View.java:10947)  02-02 16:44:38.786: E/AndroidRuntime(17907):    at android.view.View.invalidate(View.java:10902)  02-02 16:44:38.786: E/AndroidRuntime(17907):    at android.widget.TextView.checkForRelayout(TextView.java:6673)  02-02 16:44:38.786: E/AndroidRuntime(17907):    at android.widget.TextView.setText(TextView.java:3860)  02-02 16:44:38.786: E/AndroidRuntime(17907):    at android.widget.TextView.setText(TextView.java:3718)  02-02 16:44:38.786: E/AndroidRuntime(17907):    at android.widget.TextView.setText(TextView.java:3693)  02-02 16:44:38.786: E/AndroidRuntime(17907):    at com.example.demo.MainActivity$LooperThread.run(MainActivity.java:78)  

意思就是說，只有建立View階層的線程才能修改View，我們在非UI主線程裡面更新了View，所以會報錯。

 

但是你還沒說為什麼第一種調用方法為什麼不報錯啊！！！

先別著急，先看一下上面的報錯資訊，裡面有好多東西可以研究呢！

    我們先從下面開始看，首先是LooperThread.run()報錯了，為什麼報錯呢，再往上，因為我們調用setText了，再往上就是TextView.checkForRelayout，然後上面是invalidate，我們修改了文字，肯定要invalidate啊，誰調用的呢？原來是ViewGroup.invalidateChild,往上找啊找，終於找到了罪魁禍首，ViewRootImpl.checkThread()報錯了！

   ViewRootImpl是什麼玩意？這個玩意可很強大，你現在就只需要知道它能做很多和介面有關的事情就ok了，其實我對這個類也是只瞭解一點點。。。

 

   checkThread()到底做了什麼啊，就報錯！ViewRootImpl是一個隱藏類，我們只能去看源碼，源碼如下

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

　　就是這個方法報錯了！ViewRootImpl是依附在AttachInfo這個類上的，而AttachInfo是View得一個隱藏類，你在Eclipse裡面是看不到的，需要直接看framework得源碼。所以說，這裡的Thread.currentThread()是UI主線程，就是這裡判斷是不是我們在非UI主線做了修改VIew的操作。

 

    那麼問題又來了，為啥第一種方式，不會報錯呢！！！

   ok，不要抓狂，咱們先回顧一下Activity的生命週期。靠！和Activity的生命週期怎麼又扯上關係了？

   Activity在onCreate中進行介面的資料準備，onStart()之後，Activity的介面就對使用者可見了，那麼知道這些有什麼用呢？當然有用！上面兩種調用方式的差別就在調用的時機不同！一個是在onCreate中開啟線程調用，一個是我們手動調用，暗示著，第二種方法是在onResume之後調用！

    這種調用時機的差別就決定了代碼中setText的意義！

    第一種做法中，雖然是在子線程中setText，但是這時候View還沒畫出來呢，所以並不會調用之後的invalidate，而相當於只是設定TextView的一個屬性，不會invalidate，就沒有後面的那些方法調用了，歸根結底，就不會調用ViewRootImpl的checkThread，也就不會報錯。而第二種方法，調用setText之後，就會引發後面的一系列的方法調用，VIew要重新整理介面，ViewGroup要更新布局，計運算元View的大小位置，到最後，ViewRootImpl就會checkThread，就崩了。

    所以，嚴格上來說，第一種方法雖然在子線程了設定View屬性，但是不能夠歸結到”更新View“的範疇，因為還沒畫出來呢，就沒有所謂的更新。

    那麼，為啥說絕大多數不會報錯呢？這是因為，如果我們在onCreate開啟子線程之後，在子線程又執行了耗時操作，比如Thread.sleep，那麼子線程再調用setText的時候，就會崩潰，因為這時候onStart、onResume都執行了，你再想在子線程更新View，那麼門都沒有！

 

    不知道有沒有同學會這樣想：我記得在子線程裡面用Toast也會報錯，加上Looper.prepare和Looper.loop就可以了，這裡可以這樣做嗎？

    答案當然是不可以。

    Toast和View本質上是不一樣的，Toast在子線程報錯，是因為Toast的顯示需要添加到一個MessageQueue中，然後Looper取出來，發給Handler調用顯示，子線程因為沒有Looper，所以需要加上Looper.prepare和Looper.loop建立一個Looper,但是實質上，這還是在子線程調用，所以還是會報錯的！

 

    那麼為什麼Android要求只能在UI主線程中更改View呢？這就要說到Android的單執行緒模式了，因為如果支援多線程修改View的話，由此產生的線程同步和安全執行緒問題將是非常繁瑣的，所以Android直接就定死了，View的操作必須在UI線程，從而簡化了系統設計。

 

    ok，希望上面說到的這些能對你有所協助。