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

”只能在UI主線程中更新View“。這句話很熟悉吧？來來，哥們，看一下下麵的例子代碼這麼寫，不是逗比嗎！肯定崩啊！但是，如果你試一下，你會發現，絕大多數是不會崩的。至於極少數會崩潰的原因，我一會再說。你可能會很疑惑，不是”只能在UI主線程中更新View“嗎？你這個在子線程裡面更新View，為 ...

”只能在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，希望上面說到的這些能對你有所幫助。