runOnUiThread的这个大问题,难道没人注意到吗?

xiaoxuwei1 发布于 2018/07/09 11:01
阅读 3K+
收藏 0

【开源中国 APP 全新上线】“动弹” 回归、集成大模型对话、畅读技术报告”

大家都知道,如果在线程中要更新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还是报空指针啊。。。。。

请问大神,这问题该如何解决呢?谢谢!

加载中
0
x
xiaoxuwei1

谢谢回答,我觉得您的概念有很大错误,Activity退出后,在Activity里面开的线程是不会自动退出的。如果您手头有程序,您可以试一下。

0
开源中国首席C菜鸟
开源中国首席C菜鸟
你说的这种问题其实不是问题,主要是在底层的时候你开启一个线程,主线程如果退出,子线程也会退出的,跟进程是有区别的,当然如果子线程里面是while循环或者抢占cpu的线程那么会出现底层的段错误问题,其余没问题的。
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部