从 XML 到 View 显示在屏幕上，都发生了什么?

锐湃

已于 2024-08-23 11:17:56 修改

阅读量63

点赞数

分类专栏：系统层面内容 framework 文章标签： xml

于 2024-08-23 11:17:00 首次发布

原文链接：https://juejin.cn/post/6991483318625632286

版权

系统层面内容同时被 2 个专栏收录

449 篇文章 23 订阅

订阅专栏

framework

82 篇文章 6 订阅

订阅专栏

前言

View绘制可以说是Android开发的必备技能，但是关于View绘制的的知识点也有些繁杂。
如果我们从头开始阅读源码，往往千头万绪，抓不住要领。
目前当我们写页面时，布局都是写在XML里的，我们可以思考下:布局从XML到显示到屏幕上，都发生了什么，可以分为哪几个部分?
我们将整个显示流程分解为以下几个部分

代码是怎么从XML转换成View的?
View是怎么添加到页面上的?
在内存中View到底是怎么绘制的?
View绘制完成后是怎么显示到屏幕上的?

本文目录如下所示：

1. `XML`是怎么转换成`View`的？

我们都知道，在android中写布局一般是通过XML，然后通过setContentView方法配置到页面中
看来XML转换成View就是在这个setContentView中了

1.1 `setContentView`中做了什么

public void setContentView(int resId) {
    ensureSubDecor();
    ViewGroup contentParent = mSubDecor.findViewById(android.R.id.content);
    contentParent.removeAllViews();
    LayoutInflater.from(mContext).inflate(resId, contentParent);
    mAppCompatWindowCallback.getWrapped().onContentChanged();
}

可以看到resId传给了我们熟悉的LayoutInflater,看来xml转化成View就是在LayoutInflater方法中实现的了。

1.2 LayoutInflater中做了什么？

public View inflate(@LayoutRes int resource, @Nullable ViewGroup root, boolean attachToRoot) {
    final Resources res = getContext().getResources();
    //预编译直接返回view,目前还未启用
    View view = tryInflatePrecompiled(resource, res, root, attachToRoot);
    if (view != null) {
        return view;
    }
    XmlResourceParser parser = res.getLayout(resource);
    try {
        //真正将`XML`转化为`View`
        return inflate(parser, root, attachToRoot);
    } finally {
        parser.close();
    }
}

代码也比较简单,我们一起来分析下:

1、首先我们需要明确，将XML转化为View牵涉到一些耗时操作，比如XML解析是一个io操作，将XML转化为View涉及到反射，这也是耗时的。

2、我们可以看到在解析前有个tryInflatePrecompiled方法,这个方法就是希望可以在编译阶段直接预编译XML，在运行时直接返回构建好的View，看起来Google希望通过这种方式解决XML的性能问题。不过这个功能目前还没有启用，因此此方法直接返回null,目前生效的还是下面的方法。

3、真正将XML解析为View的还是在inflate方法中,将标签名转化为View的名称,XML中的各种属性转化为AttributeSet对象,然后通过反射生成View对象。

由于篇幅原因，这里就不再粘贴inflate方法的源码了，里面主要需要注意下setFactory与setFactory2方法。

在真正进行反射前，会先调用这两个方法尝试创建一下View，而且系统开放了API，我们可以自定义解析XML方式。

这就给了我们一些面向切面编程的空间，可以利用这两个API实现换肤，替换字体，替换 View,提升View构建速度等操作。

希望进一步了解的同学可参考：探究 LayoutInflater setFactory

1.3 小结

XML转化为View转化为主要是通过LayoutInflator来完成的，将标签名转化为View的名称,XML中的各种属性转化为AttributeSet对象,然后通过反射生成View对象
这个过程中存在一些耗时操作，比如解析XML的IO操作，通过反射生成View等,我们可以通过多种方式优化这个过程,比如将反向的耗时转移到编译期，有兴趣的同学可以参阅:Android "退一步"的布局加载优化

2. `View`是怎么添加到页面上的?

经过上面这步，View已经被创建出来了，但是View又是怎么添加到页面(Activity)上的呢？

我们再来看下setContentView方法。

public void setContentView(int resId) {
    ensureSubDecor();
    ViewGroup contentParent = mSubDecor.findViewById(android.R.id.content);
    contentParent.removeAllViews();
    LayoutInflater.from(mContext).inflate(resId, contentParent);
    mAppCompatWindowCallback.getWrapped().onContentChanged();
}

LayoutInflater有两个参数，第二个参数就是root，即创建出的view要被添加的父view。

所以答案也就呼之欲出了，创建出来的view被添加到了contentParent上，即R.id.content上。

那么问题来了，这个R.id.content是哪来的呢？

2.1 R.id.content从何而来?

我们看到，setContentView开头调用了ensureSubDecor方法，一起来看下它的源码。

private void ensureSubDecor() {
    if (!mSubDecorInstalled) {
        mSubDecor = createSubDecor();
    }
}
private ViewGroup createSubDecor() {
    // Now let's make sure that the Window has installed its decor by retrieving it
    ensureWindow();
    mWindow.getDecorView();

    final LayoutInflater inflater = LayoutInflater.from(mContext);
    ViewGroup subDecor = null;

   //省略其他样式subDecor布局的实例化
   //包含 actionBar floatTitle ActionMode等样式
   subDecor = (ViewGroup) inflater.inflate(R.layout.abc_screen_simple, null);
   final ContentFrameLayout contentView = (ContentFrameLayout) subDecor.findViewById(R.id.action_bar_activity_content);

    final ViewGroup windowContentView = (ViewGroup) mWindow.findViewById(android.R.id.content);
    // 把`contentView`的id设置为android.R.id.content,把windowContentView的id设置为View.NO_ID
    windowContentView.setId(View.NO_ID);
    contentView.setId(android.R.id.content);

    //将subDecor添加到window
    mWindow.setContentView(subDecor);
    return subDecor;
}

可以看出，主要工作是创建subDecor并添加到window上

步骤一：确认window并attach(设置背景等操作)
步骤二：获取DecorView，因为是第一次调用所以会installDecor(创建DecorView和windowContentView)
步骤三：从xml中实例化出subDecor布局
步骤四：将subDecor的contentView的id设置为R.id.content
步骤四：将subDecor添加到window中

现在我们已经知道R.id.content从何而来了，并且知道了subDecor最终会添加到window中
那么问题来了，window又是什么呢？

2.2 `window`到底是什么？

我们上文提到，我们创建的view会被添加到subDecor上，最后会被添加到window中，那么window是什么？为什么要有window?

我们在应用中有多个页面，手机上也有多个应用，这么多页面同时只能有一个页面显示在手机上，这个时候就需要有一个机制来管理当前显示哪个页面
于是Android在系统进程中创建了一个系统服务WindowManagerService(WMS)专门用来管理屏幕上的窗口，而View只能显示在对应的窗口上，如果不符合规定就不开辟窗口进而对应的View也无法显示

window机制就是为了管理屏幕上的view的显示以及触摸事件的传递问题

值得注意的事，上面的window与窗口很容易混淆，Android SDK中的Window是一个抽象类，它有一个唯一实现类PhoneWindow，PhoneWindow内部会持有一个DecorView(根View)，它的职责就是对DecorView做一些标准化的处理，比如标题、背景、导航栏、事件中转等，很显然与我们前面所说的窗口概念不符合

总得来说PhoneWindow只是提供些标准的UI方案，与窗口不等价
窗口是一个抽象概念，即当前应该显示哪个页面，系统通过WindowManagerService(WMS)来管理
关于窗口机制，想了解更加详细的同学，可参考：通俗易懂 Android视图系统的设计与实现,写得非常通俗易懂，有兴趣的可以了解下

2.3 `View`什么时候真正可见?

上面提到PhoneWindow只是提供些标准的UI方案，并不是真正的窗口。

那么我们的View到底什么时候添加到窗口上，什么时候真正对用户可见？

#ActivityThread
public void handleResumeActivity(...) {
    //...
    //注释1
    r.window = r.activity.getWindow();
    View decor = r.window.getDecorView();
    decor.setVisibility(View.INVISIBLE);
    ViewManager wm = a.getWindowManager();
    WindowManager.LayoutParams l = r.window.getAttributes();
    ...
    //注释2
    wm.addView(decor, l);
    ...
}

#ViewRootImpl.java
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
    synchronized (this) {
        if (mView == null) {
            //记录DecorView
            mView = view;
            //省略
            //开启View的三大流程（measure、layout、draw)
            requestLayout();
            try {
                //添加到WindowManagerService里，这里是真正添加window到底层
                //这里的返回值判断window是否成功添加，权限判断等。
                //比如用Application的context开启dialog，这里会添加不成功
                // 注释3
                res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
                        getHostVisibility(), mDisplay.getDisplayId(), mTmpFrame,
                        mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
                        mAttachInfo.mOutsets, mAttachInfo.mDisplayCutout, mInputChannel,
                        mTempInsets);
                setFrame(mTmpFrame);
            } catch (RemoteException e) {
            }
            //省略
            //输入事件接收
        }
    }
}

1、注释1处会从Activity中取出PhoneWindow,DecorView,WindowManager。

2、注释2处调用了WindowManager的addView方法，顾名思义就是将DecorView添加至窗口当中。

3、最后会调到ViewRootImpl中注释3处，这里才是真正的通过WMS在屏幕上开辟一个窗口，到这一步我们的View也就可以显示到屏幕上了。

可以看出，当我们打开一个Activity时，界面真正可见是在onResume之后。

2.4 Activity,PhoneWindow,View的关系

Phonewindow 是 activity 的一个成员变量,会在Activity.attatch时初始化
PhoneWindow是View的容器,对DecorView做一些标准化的处理，比如标题、背景、导航栏、事件中转等
Activity则提供了窗口的生命周期,屏蔽了窗口机制的复杂细节，开发者只需要基于模板方法开发即可

如下图所示：

https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7443ba71659d4cd0afb9e41b3de4d145~tplv-k3u1fbpfcp-zoom-in-crop-mark:1512:0:0:0.awebp

2.5 小结

View添加到页面上，主要经过了这么几个过程

1.启动activity
2.创建PhoneWindow
3.设置布局setContentView,将layoutId转化为View
4.确认subDecorView的初始化，将subDecorView添加到PhoneWindow中
5.添加layoutId转化后的View到android.R.id.content上
6.在onResume中将DecorViewView添加到WindowManager中
7.View真正显示到屏幕上了

3. `View`到底是怎么绘制的?

经过上一步，View已经添加到window上了，接下来就是View本身的绘制了
View的绘制主要经过以下几步
1、首先需要确定View占的空间尺寸(measure)
2、确定了空间尺寸，就需要确定摆放在哪个位置(layout)
3、确认了摆放位置，就需要确定在上面展示些什么东西(draw)

这几个阶段，View已经封装了模板方法给我们，我们直接重写onMeasure,onLayout,onDraw这几个方法就好了
而绘制的入口，就是上面ViewRootImpl.setView中的requestLayout

3.1 `requestLayout`如何触发绘制

上文说到requestLayout会触发绘制，我们一起来看下源码。

ViewRootImpl.java
    public void requestLayout() {
        if (!mHandlingLayoutInLayoutRequest) {
            //检查是否是主线程，如果不是则直接抛出异常，ViewRootImpl创建的时候生成一个主线程引用
            //用当前线程和引用比较，如果是同一个则是主线程
            //这也是为什么在子线程对View进行更新、绘制会报错的原因
            checkThread();
            //用来标记需要进行layout
            mLayoutRequested = true;
            //绘制请求
            scheduleTraversals();
        }
    }

    void scheduleTraversals() {
        if (!mTraversalScheduled) {
            //标记一次绘制请求，用来屏蔽短时间内的重复请求
            mTraversalScheduled = true;
            //往主线程Looper队列里放同步屏障消息，用来控制异步消息的执行
            mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
            //放入mChoreographer队列里
            //主要是将mTraversalRunnable放入队列
            mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
            //省略
        }
    }

    final class TraversalRunnable implements Runnable {
        @Override
        public void run() {
            doTraversal();
        }
    }

    void doTraversal() {
        //没有取消绘制的话则开始绘制
        if (mTraversalScheduled) {
            mTraversalScheduled = false;
            //移除同步屏障
            mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);

            //真正开始执行measure、layout、draw等方法
            performTraversals();
        }
    }

requestLayout中其实主要也是做了以下几件事：

1、检查绘制的线程与View创建的线程是否是同一个线程。

2、通过Handler同步屏障机制，保证UI绘制消息优先级是最高的。

3、将mTraversalRunnable传入Choreographer，监听vsync信号。

4、收到vsync信号后会回调TraversalRunnable,移除同步屏障并开始真正的measure,layout,draw。

View绘制流程图如下：

3.2 `MeasureSpec`分析

在测量过程中，会传入一个MeasureSpec参数,MeasureSpec封装了View的规格尺寸参数，包括View的宽高以及测量模式。
它的高2位代表测量模式，低30位代表尺寸。其中测量模式总共有3中。

UNSPECIFIED：未指定模式不对子View的尺寸进行限制。
AT_MOST：最大模式对应于wrap_content属性，父容器已经确定子View的大小，并且子View不能大于这个值。
EXACTLY：精确模式对应于match_parent属性和具体的数值，子View可以达到父容器指定大小的值。

普通view的MeasureSpec创建规则如下

结合这个表，我们可以一起来看一个问题：

<FrameLayout
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:background="@android:color/red"
    xmlns:android="http://schemas.android.com/apk/res/android">
    <View
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:background="@android:color/blue"/>
</FrameLayout>

请问这样一个布局，最后是什么颜色呢？

答案是蓝色，并且占满屏幕。

简单来说，当我们自定义View 时，如果没有对MODE做处理，设置wrap_content和match_content结果其实是一样的，View 的宽高都是取父 View 的宽高。

本问题的详细解析可见：一道滴滴面试题

3.3 小结

View的绘制需要定位，测量，绘制三个步骤，为了简化自定义View的过程，官方已经提供了模板方法，我们重写相关方法即可
ViewRootImpl中的requestLayout是绘制的入口，当然我们在View中调用invalidate或者requestLayout也会触发重绘
绘制过程本质上也是通过Handler发送消息，为了提高绘制消息的优先级，会开启同步屏蔽机制
将mTraversalRunnable传入Choreographer，监听vsync信号。注意，vsync信号注册了才会监听。
收到vsync信号后会回调TraversalRunnable,移除同步屏障并开始真正的measure,layout,draw过程
接下来就是回调各个View的onMeasure,onLayout,onDraw过程

4 `View`绘制完成后是怎么显示到屏幕上的?

目前我们已经知道了，从XML到调用View.onDraw的过程，但是从onDraw到显示到屏幕上似乎还有些距离
我们知道，View最后要显示在屏幕上，CPU负责计算帧数据，把计算好的数据交给GPU，GPU会对图形数据进行渲染，渲染好后放到buffer(图像缓冲区)里存起来，然后Display（屏幕或显示器）负责把buffer里的数据呈现到屏幕上

那么问题来了，canvas.draw是怎么转化成Graphic Buffer的呢？

其大概流程如图所示：

可以看出，这个过程还是相当复杂的，由于篇幅原因，这里就不展开了，感兴趣的同学可以参阅苍耳叔叔的系列文章：Android图形系统综述(干货篇)

总结

从XML到View显示到屏幕上主要涉及到以下知识点

Activity的启动
LayoutInflater填充View的原理
PhoneWindow,Activity,View的关系
Android窗口机制与WindowManagerService管理窗口
View的绘制流程，measure,layout,draw等与Handler同步屏障机制
Android屏幕刷新机制,VSync信号监听，三级缓冲等
Android图形绘制，包括SurfaceFinger工作流程，软件绘制，硬件加速等

这篇文章其实已经比较长了，但是要完全了解从XML到显示到屏幕上的过程，还是不够详细，有很多地方只做了简述，如果有什么错误或者需要补充的地方，欢迎在评论区提出
由于篇幅原因，有一些知识点没有写得很详细，下面列出一些更好的文章供参考：
Android窗口机制：通俗易懂 Android视图系统的设计与实现
Android屏幕刷新机制： “终于懂了” 系列：Android屏幕刷新机制—VSync、Choreographer 全面理解！
Android图形系统: Android图形系统综述(干货篇)
Handler同步屏障机制：关于Handler同步屏障你可能不知道的问题