文章来源:http://blog.csdn.net/windskier/article/details/6957901
ViewRoot是GUI管理系统与GUI呈现系统之间的桥梁,根据ViewRoot的定义,我们发现它并不是一个View类型,而是一个Handler。
它的主要作用如下:
A. 向DecorView分发收到的用户发起的event事件,如按键,触屏,轨迹球等事件;
B. 与WindowManagerService交互,完成整个Activity的GUI的绘制。
事件处理和GUI绘制的具体实现在后面的文章中再描述,这篇文章就主要介绍ViewRoot对象如何同WindowManagerService桥接起来的。
在完成Activity的ContentView设置之后,下面的工作就是准备显示了,准备显示的主要工作就是建立起Application和WindowManagerService之间的联系,第一步的工作就是向WindowManager添加前面涉及到的DecorView,我们已经知道这个DecorView包含了整个Activity的GUI,所以我们只需要把这个DecorView交给WindowManager打理就可以了。
下面看看整个的过程
A. 向WindowManager添加DecorView;
B. WindowManagerImpl保存DecorView到mViews,创建对应的ViewRoot;
C.调用ViewRootsetView()方法
在这个方法中只需要关注两个步骤
(1) requestLayout()
请求WindowManagerService绘制GUI,但是注意一点的是它是在与WindowManagerService建立连接之前绘制,为什么要在建立之前请求绘制呢?
其实两者实际的先后顺序是正好相反的,与WMS建立连接在前,绘制GUI在后,那么为什么代码的顺序和执行的顺序不同呢?这里就涉及到ViewRoot的属性了,我们前面提到ViewRoot并不是一个View,而是一个Handler,那么执行的具体流程就是这样的:
a) ActivityThread的handler函数注册了启动一个新的Activity的请求处理LAUNCH_ACTIVITY,LAUNCH_ACTIVITY的处理过程调用到了ViewRoot的setView()方法,因此上图代码在被执行时正处于LAUNCH_ACTIVITY消息的处理过程中。
b) requestLayout()其实是向messagequeue发送了一个请求绘制GUI的消息,并且ViewRoot和ActivityThread共用同一个MessageQueue(如下图),因此绘制GUI的过程一定是在LAUNCH_ACTIVITY消息被处理完之后,也就是sWindowSessoin.add()方法调用完之后。
(2) sWindowSessoin.add()
从字面意思理解的话,IWindowSession sWindowSessoin是ViewRoot和WindowManagerService之间的一个会话层,它的实体是在WMS中定义,作为ViewRoot requests WMS的桥梁。
add()方法的第一个参数mWindow是ViewRoot提供给WMS,以便WMS反向通知ViewRoot的接口。由于ViewRoot处在application端,而WMS处在system_server进程,它们处在不同的进程间,因此需要添加这个IWindow接口便于GUI绘制状态的同步。