runOnUiThread的这个大问题，难道没人注意到吗？

Question

大家都知道，如果在线程中要更新UI的话，有两种方法，一种是handler,还一种就是runOnUiThread。
我这里要说的是runOnUiThread。
大家在网上看例子的时候，基本无一例外都是在线程中这么写的

                getActivity().runOnUiThread(new Runnable() {

                    @Override
                    public void run() {
                        // TODO Auto-generated method stub
                        myTextView.setText("更新");//UI更新
                    }

                });

那么问题来了，这样做是有巨大风险的。为什么这么说呢，原因很简单，如果用户在线程还没结束的时候退出了Activity，Activity虽然退出了，但在Activity里开的
线程还在执行，当执行到getActivity().runOnUiThread的时候，由于Activity已经退出了，这时候，getActivity().runOnUiThread显然是要报空指针错误的。

于是，细心些的人说，那么就先判断getActivity()是不是null吧，如果不是null,再做getActivity().runOnUiThread。
听起来挺合理，但有没有人想过，有可能判断getActivity()的时候，Activity没退出，所以还不是空，但恰巧判断完后，Activity退出了（虽然这种概率很低，但也存在），那判断语句后的getActivity().runOnUiThread还是报空指针啊。。。。。

请问大神，这问题该如何解决呢？谢谢！

Answer 1

兄弟，你还是看看runOnUiThread方法的源码吧，runOnUiThread方法主要是封装handler的操作而已。你所说的上面巨大风险，不管用handler机制还是RunOnUi方法都会一样的。一般情况你用handler机制时都会加一个判断 if ( mHandler != null ){ } ; 如果你用RunOnUi方法同样需要加上一个条件判断 getActivity()是不是null。还有你所说的：有可能判断getActivity()的时候，Activity没退出，所以还不是空，但恰巧判断完后，Activity退出了的问题。
if ( getActivity() !=null ) getActivity().runOnUiThread(.......); 这两行代码执行的时间间隔几乎为0ms。不可能发生你所说的问题出现。如果你硬要说有可能，那么请问一下：你在线程中执行任何代码时是不是都会崩溃。