Android面试相关Android开发Android开发经验谈

子线程能更新UI吗

2019-03-01  本文已影响22人  Geekholt

前言

大家在最初学习Android的时候,应该都知道Android要在主线程更新UI,那么子线程是不是一定不能更新UI呢?

子线程能否更新UI

我们先来看一个简单的例子:

MainActivity.java

public class MainActivity extends Activity {
    private TextView txtMain;
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        txtMain = findViewById(R.id.txt_mian);
        new Thread(new Runnable() {
            @Override
            public void run() {
                txtMain.setText("hello world");
            }
        }).start();
    }
}

activity_main.xml

<?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"
    android:gravity="center">

    <TextView
        android:id="@+id/txt_mian"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />
</RelativeLayout>

程序运行结果

//todo 运行后截图

程序运行后没有任何问题,不是一直都说不能在子线程更新UI吗?为什么会出现这种情况呢?

下面我们在子线程更新UI之前模拟一个耗时操作

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        final TextView txtMain = findViewById(R.id.txt_mian);
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    //模拟耗时操作
                    Thread.sleep(500);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                txtMain.setText("hello world");
            }
        }).start();
    }
}

不出意外,这时候程序崩溃了

造成两种现象的唯一变量仅仅是耗时操作,仅凭这一点我们并不能找到根本的原因,但我们可以根据错误信息来定位报错的位置

异常信息.png

我们看到错误信息是从ViewRootImpcheckThread方法中抛出的

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

这个方法把当前更新UI的线程ViewRootImpl被创建的线程进行了对比,意思很明显,两个线程不一致,就会报错

由此我们很容易猜到ViewRootImpl就是在主线程被创建的,但是为什么我们一开始在MainActivityonCreate方法中创建一个子线程去更新UI,程序却可以正常运行呢?

ViewRoot对应ViewRootImpl类,它是连接WindowManager和DecorView的纽带,view的三大流程(measure,layout,draw)均是通过ViewRoot来完成的,ActivityThread中,当Activity对象被创建完毕后,会将DecorView添加到Window中,同时创建ViewRootImpl对象并和DecorView建立联系。DecorView作为顶级的View一般情况下它内部会包含一个竖向的LinearLayout,这个LinearLayout里面有上下两个部分(具体情况和Android版本及主题有关),上面是标题栏,下面是内容栏。

下面我们来看一下ViewRootImp是如何被创建的(这里我们主要关注ViewRootImp的创建时机,如果想了解整体的Activity的启动流程,可以看我的另一篇文章Activity启动流程分析

我们先找到ActivityThreadhandleResumeActivity的方法

final void handleResumeActivity(IBinder token,
        boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
    //代码省略
    //1.performResumeActivity
    r = performResumeActivity(token, clearHide, reason);

      if (r != null) {
        final Activity a = r.activity;
        //代码省略
        r.activity.mVisibleFromServer = true;
        mNumVisibleActivities++;
          if (r.activity.mVisibleFromClient) {
              //2.makeVisible()
              r.activity.makeVisible();
          }
      }
      //代码省略   
}

这里我们主要关心两个方法

这个方法就是回调onResume方法的入口,最终会调用InstrumentationcallActivityOnResume方法

public void callActivityOnResume(Activity activity) {
    activity.mResumed = true;
    activity.onResume();

    if (mActivityMonitors != null) {
        synchronized (mSync) {
            final int N = mActivityMonitors.size();
            for (int i=0; i<N; i++) {
                final ActivityMonitor am = mActivityMonitors.get(i);
                am.match(activity, activity, activity.getIntent());
            }
        }
    }
}

通过上面的分析,显然,这个方法是在ActivityonResume方法之后执行

void makeVisible() {
    if (!mWindowAdded) {
        ViewManager wm = getWindowManager();
        wm.addView(mDecor, getWindow().getAttributes());
        mWindowAdded = true;
    }
    mDecor.setVisibility(View.VISIBLE);
}

ViewManager是一个接口,WindowManager是继承了ViewManager的一个接口,而WindowManagerImp才是真正的实现类

我们来看WindowManagerImpaddView方法

public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
    applyDefaultToken(params);
    mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
}

继续看WIndowManagerGlobaladdView方法

public void addView(View view, ViewGroup.LayoutParams params,
        Display display, Window parentWindow) {
    //代码省略
    ViewRootImpl root;
    View panelParentView = null;
    //代码省略
      root = new ViewRootImpl(view.getContext(), display);

      view.setLayoutParams(wparams);
    
      mViews.add(view);
      mRoots.add(root);
      mParams.add(wparams);
    }

    try {
        root.setView(view, wparams, panelParentView);
    } catch (RuntimeException e) {
        synchronized (mLock) {
            final int index = findViewLocked(view, false);
            if (index >= 0) {
                removeViewLocked(index, true);
            }
        }
        throw e;
    }
}

原来ViewRootImp就是在WindowManagerGlobaladdView方法中被创建的!

总结

对前面的分析做一个总结,ViewRootImp是在Activity的onResume方法之后被创建的,在onCreate方法中开启子线程更新UI的时候,ViewRootImp还没有被创建,就不会执行checkThread方法,所以程序没有报错。而子线程休眠了500毫秒后,ViewRootImp已经被创建了,所以在执行checkThread时程序出现崩溃

正常情况时序图.png

文中提到的在子线程中更新UI这种场景其实是属于极端情况,实际运用中基本不会这样使用。所以我们在实际开发过程中还是需要记住一句话

Android UI操作并不是线程安全的,并且这些操作必须在UI线程执行

通过上面的例子,我们也体会到了遇到异常情况时,看看源码实现,问题往往就迎刃而解了

其实这篇文章我们主要讲了UI操作前会进行checkThread线程检查,如果不是ViewRootImp被创建的线程(主线程)就会报错。那么为什么一定要进行线程检查呢?如果两个不同的线程同时进行UI绘制是否可行呢?这样是否会更高效呢?请看我的另一篇文章Android为什么设计成单线程模型

上一篇下一篇

猜你喜欢

热点阅读