在Android开发的过程中，我们都碰到过一个问题，就是在非UI线程去做一些更新UI操作的时候会抛出如下异常：
android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRootImpl.checkThread(ViewRootImpl.[Java](http://lib.csdn.net/base/javaee "Java EE知识库"):6581)
at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:924)
这个异常是从ViewRootImpl这个类中抛出来的。我们跟进去看一下这个类。这个类在源码中的位置是
frameworks/base/core/java/android/view/ViewRootImpl.java
而关于抛出异常的位置源码如下：
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
其中mThread就是通过native方法获取到UI线程进行赋值。我们看到，viewRootImpl会在访问UI的时候去检查访问UI的线程，如果不是UI线程，则抛出这个异常。异常信息中有requestLayout这个函数，那我们继续去看下代码。
@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
scheduleTraversals();
}
}
这段代码同样很少，也看不出来什么，那我们继续去跟下去，发现最后会走到performTraversals()这个函数中，而view 的绘制过程就是从这个函数开始的，此时我们大概了解了为什么在非UI 线程操作UI会报错，但是具体原因是什么还是不太了解。
这特么就尴尬了。让我们梳理一下目前碰到的情况，我们知道在非UI 线程中操作UI 会抛出异常，异常描述也很清楚，在checkThread方法中会检查操作ui的线程。但是我们在开发过程中会发现一个问题，那就是在activity的onCreate()生命周期里 我们是可以做一个非UI线程操作UI的骚操作的。这是为什么呢。所以我们需要去看一下ViewRootImpl的创建流程。我们知道，在启动一个Android应用的时候，是从ActivityThread这个类中的main函数开始的，那我们去看一下这个类到底做了什么。
ActivityThread的源码位置在frameworks/base/core/java/android/app/ActivityThread.java
public static void main(String[] args) {
....
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
if (false) {
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, "ActivityThread"));
}
// End of event ActivityThreadMain.
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
我们发现在ActivityThread的main函数中会初始化一个供主线程使用的looper，先不去管他都干了什么，先去看这个handler都做了些什么。这个地方的代码比较长，具体就是监控Android的一些操作。我们发现里面跟创建activity有关的好像只有
case RESUME_ACTIVITY:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityResume");
SomeArgs args = (SomeArgs) msg.obj;
handleResumeActivity((IBinder) args.arg1, true, args.argi1 != 0, true,
args.argi3, "RESUME_ACTIVITY");
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
我们来看一下handleResumeActivity这个函数
final void handleResumeActivity(IBinder token,
boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
...
r = performResumeActivity(token, clearHide, reason);
...
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
...
ViewRootImpl impl = decor.getViewRootImpl();
if (impl != null) {
impl.notifyChildRebuilt();
}
}
...
if (r.activity.mVisibleFromClient) {
r.activity.makeVisible();
}
}
...
}
我们看到这段代码中会调用 r = performResumeActivity(token, clearHide, reason);不出意外这个地方是要回掉activity的onResume()生命周期。代码不详细去看了，想看的同学去看下源码。经过一系列骚操作。我们发现最后会调用WindowManagerGloable的addView函数。
代码位置在frameworks/base/core/java/android/view/WindowManagerImpl.java我们进去看一下
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);
}
...
}
经过一系列操作，发现ViewRootImpl被实例化出来了。
此时我们大概能想明白，为什么在Android中非ui线程操作UI会报错，但是有时在onCreate生命周期中可以做一些延时性不高的操作。原因是ViewRootImpl会在所有操作UI 的地方进行checkThread(). 而ViewRootImpl是在onResume()生命周期之后才被实例化出来，所以在onCreate中ViewRootImpl还没有实例化，无法做检测。所以在onResume生命周期之后，理论上就不可以在非ui线程操作ui了。
此时我们考虑一个问题。那就是ViewRootImpl 是在ActivityThread在启动Android应用的时候为app创建一个主线程，然后通过这个线程相关联的windowmanagergloabl实例化出来的，那我们在子线程中搞一个window，然后这个window在子线程中会实例化出一个ViewRootImpl，这个时候是不是可以在子线程中更新ui呢？大家可以试验一下。
OK，收，回到我们的主题handler。Handler主要是用来在Android中进行线程间通信的
一般操作流程子线程中使用handler 需要自己搞一个looper。否则会报错，主线程刚才大家在看ActivityThread源码的时候 发现在启动一个应用的时候 已经为app的主线程准备好了Looper.然后调用Looper.loop()函数，里面维护了一个死循环，一直在从messagequeue中取消息处理。OK，这个地方，考虑一个问题，主线程looper为什么没有阻塞线程，或者说主线程looper是怎么工作的。这个需要去看一下ActivityThread的main函数了。
下面是看到一个哥们的回答，摘抄一下。
主线程（UI线程）执行到这一步就进入了死循环，不断地去拿消息队列里面的消息出来处理？那么问题来了
1、UI线程一直在这个循环里跳不出来，主线程不会因为Looper.loop()里的死循环卡死吗，那还怎么执行其他的操作呢？
在looper启动后，主线程上执行的任何代码都是被looper从消息队列里取出来执行的。也就是说主线程之后都是通过其他线程给它发消息来实现执行其他操作的。生命周期的回调也是如此的，系统服务ActivityManagerService通过Binder发送IPC调用给APP进程，App进程接到到调用后，通过App进程的Binder线程给主线程的消息队列插入一条消息来实现的。
2、主线程是UI线程和用户交互的线程，优先级应该很高，主线程的死循环一直运行是不是会特别消耗CPU资源吗？App进程的其他线程怎么办？
这基本是一个类似生产者消费者的模型，简单说如果在主线程的MessageQueue没有消息时，就会阻塞在loop的queue.next()方法里，这时候主线程会释放CPU资源进入休眠状态，直到有下个消息进来时候就会唤醒主线程，在2.2 版本以前，这套机制是用我们熟悉的线程的wait和notify 来实现的，之后的版本涉及到Linux pipe/epoll机制，通过往pipe管道写端写入数据来唤醒主线程工作。原理类似于I/O,读写是堵塞的，不占用CPU资源。
image
网友评论