目录
- 前言
- 1.viewrootimpl哪来的？
- 2 viewrootimpl 一个view链渲染的中转站
- 3 不能在子线程操作view？
- 4 view 挂载
- 5 view.post()的runnable最终在哪执行了？
- 6 为什么view.post 可以获取宽高
- 7 还有一点值得注意
- 总结
前言
这两个类就是activitythread和viewrootimpl，之所以说碰不到是因为我们无法通过正常的方式引用这两个类或者其类的对象，调用方法或者直接拿他的属性。但他们其实又无处不在，应用开发中很多时候都和他们息息相关，阅读他们掌握其内部实现对我们理解android运行机理有醍醐灌顶之疗效，码读百变其义自见，常读常新。本文就尝试从几个我们经常接触的方面先谈谈viewrootimpl。
1.viewrootimpl哪来的？
首先是viewrootimpl，位于android.view包下，从它所处的位置大概能猜到，跟view相关。其作用一句话总结，就是连接window和view的纽带。
这个要从我们最熟悉的activity开始，我们知道activity的设置布局view是通过setcontentview() 方法这个方法里面也大有文章，我们简单的梳理下。
- activity setcontentview（）内部调用了
getwindow().setcontentview(layoutresid);也就是调用了window的setcontentview方法,android里window的唯一实现类就是phonewindow，phonewindow setcontentview，初始化decorview和把我们设置的view作为其子类。 - 目光转移到
activitythread没错是我们提及的另外一个主角，先关注他的handleresumeactivity()方法，里面关键的部门代码，
public void handleresumeactivity(){
r.window = r.activity.getwindow();
view decor = r.window.getdecorview();
viewmanager wm = a.getwindowmanager();
viewmanager wm = a.getwindowmanager();
windowmanager.layoutparams l = r.window.getattributes();
wm.addview(decor, l);
}
windowmanager的实现类windowmanageimpl的addview方法里调用了mglobal.updateviewlayout(view, params);- 最后我们在windowmanagerglobal的addview方法里找到了
public void addview(){
root = new viewrootimpl(view.getcontext(), display);
view.setlayoutparams(wparams);
mviews.add(view);
mroots.add(root);
mparams.add(wparams);
}
小结
- 通过梳理这个过程我们知道，setcontenview()其实只是在window的下面挂了一个view链，view链的根就是viewrootimpl。
- window通过把view和activity联系在一起。
- view链的真正添加操作最终交给了windowmanagerglobal执行。
- 补充一点：popupwindow本质就是在当前window下挂了一个view链，popupwindow本身没有window，就如雷锋塔没有雷锋一样；dialog是有自己的window关于这点可自行查阅源码考证。
2 viewrootimpl 一个view链渲染的中转站
view的渲染是自定而上层层向下发起的，大致经历测量布局和绘制，view链的管理者就是viewrootimpl。通过
scheduletraversals（）方法发起渲染动作。交给choreographer安排真正执行的时间关于choreographer不熟悉的可以参考我的其他文章。最终执行performtraversals() 方法。
private void performtraversals(){
performmeasure(childwidthmeasurespec, childheightmeasurespec);
performlayout(lp, mwidth, mheight);
performdraw();
}
3 不能在子线程操作view？
viewroot的requestlayout中有这样一段代码：
@override
public void requestlayout() {
if (!mhandlinglayoutinlayoutrequest) {
checkthread();
mlayoutrequested = true;
scheduletraversals();
}
}
void checkthread() {
if (mthread != thread.currentthread()) {
throw new calledfromwrongthreadexception(
"only the original thread that created a view hierarchy can touch its views.");
}
}
- 我们对view的操作，比如给textview设置text，最终都会触发viewrootimpl的
requestlayout()方法，该方法有如上的一个check逻辑。这就是我们常说的不能在子线程中更新view。 - 其实子线程中可以执行view的操作，但是有个前提是：view还未挂载时。 view未挂载时时不会触发requestlayout的，还只是一个普普通通的java对象。那挂载逻辑在哪？
4 view 挂载
- 在viewrootimpl的
performtraversals()里有这个代码
private void performtraversals(){
host.dispatchattachedtowindow(mattachinfo, 0);//此处的host为viewgroup
}
- viewgroup的
dispatchattachedtowindo()方法会把attachinfo对象分配每一个view，最终实现我们所谓的挂载。
void dispatchattachedtowindow(attachinfo info, int visibility) {
for (int i = 0; i < count; i ) {
final view child = children[i];
child.dispatchattachedtowindow(info,
combinevisibility(visibility, child.getvisibility()));
}
- 实现挂载的view有任何风吹草动就会把事件传递到大bossviewrootimpl这里了。
通过addview添加进的view也是会收到父view的mattachinfo这里不展开了。
5 view.post()的runnable最终在哪执行了？
public boolean post(runnable action) {
final attachinfo attachinfo = mattachinfo;
if (attachinfo != null) {
return attachinfo.mhandler.post(action);
}
getrunqueue().post(action);
return true;
}
- 以上是view post()的代码，可见如果已经实现挂载的view，会直接把post进来的消息交给hanlder处理了给执行，不然就post了handleractionqueue里。
void dispatchattachedtowindow(attachinfo info, int visibility) {
..
if (mrunqueue != null) {
mrunqueue.executeactions(info.mhandler);//内部也是调用handler.post()
mrunqueue = null;
}
..
}
- 最终这些runnable会在view挂载的时候执行，也就是
dispatchattachedtowindow()方法里执行。
6 为什么view.post 可以获取宽高
这个是是一个问题延伸，在activity中直接获取宽高是获取不到的，我们通常会使用view.post一个runnable来获取。原因就是activity
oncreate时通过setcontentview只是创建了view而未实现挂载，挂载是在onresume时，未挂载的view其实没有经历测量过程。。而通过post的方式，通过上一小节知道，未挂载的view上post之后，任务会在挂载之后，通过handler重新post，此时已经viewrootimpl已经执行了
performtraversals()完成了测量自然可以得到宽高。
7 还有一点值得注意
viewrootimpl 不单单是渲染的中转站，还是触摸事件的中转站。
硬件传感器接收到触摸事件经过层层传递分发到应用窗口的第一站就是viewrootimpl。为什么这么说？因为我有证据~。这是viewroot里的代码
public void setview(){
..
minputeventreceiver = new windowinputeventreceiver(inputchannel,
looper.mylooper());
}
- windowinputeventreceiver是viewrootimpl的一个内部类，其接收到input事件后，就会进行事件分发。
- 这里给我们的启发是，并不是所有的主线程任务执行都是通过handler机制， ontouch（）事件是底层直接回调过来的，这就和我们之前卡顿监控说的方案里有一项就是对ontouchevent的监控。
总结
- viewroot的代码有一万多行，本文分析的只是冰山一角，里面有大量细节直接研究。
- 通过viewrootimpl相关几个点，简单的做了介绍分析希望对你有帮助。
以上就是android那两个你碰不到但是很重要的类之viewrootimpl的详细内容，更多关于android viewrootimpl的资料请关注其它相关文章！
