Android面试题（28）-android的view加载和绘制流程

View的加载流程

view布局一直贯穿于整个android应用中，不管是activity还是fragment都给我们提供了一个view依附的对象，关于view的加载我们在开发中一直使用，在接下来的几篇文章中将介绍在android中的加载机制和绘制流程并且对于基于android6.0的源码进行分析探讨。这一部分先来分析一下activity中view的加载流程。

当我们打开activity时候，在onCreate方法里面都要执setContentView(R.layout.activity_main)方法，这个是干什么的呢？当然是加载布局的，首先贴上源码：

 

@Override
public void setContentView(@LayoutRes int layoutResID) {
    getDelegate().setContentView(layoutResID);
}

这个方法存在于AppCompatActivity类中，追踪到最底层发现他是继承自activity。AppCompatActivity 其实内部的实现原理也和之前的 ActionBarActivity 不同，它是通过 AppCompatDelegate 来实现的。AppCompatActivity 将所有的生命周期相关的回调，都交由 AppCompatDelegate 来处理。

 

@NonNull
public AppCompatDelegate getDelegate() {
    if (mDelegate == null) {
        mDelegate = AppCompatDelegate.create(this, this);
    }
    return mDelegate;
}

AppCompatDelegate：

AppCompatDelegate为了支持 Material Design的效果而设计，需要其内部的控件都具有自动着色功能，来实现这个极佳的视觉设计效果，但是原有的控件所不支持Material Design的效果，所以它只好将其需要的 UI 控件全部重写一遍来支持这个效果。这些效果被放置在android.support.v7.widget包下；

但是开发者不可能一个一个的修改已经开发好的产品，这样工作量是非常大的。因此，设计者用AppCompatDelegate以代理的方式自动为我们替换所使用的 UI 控件。注意到这里有个getDelegate()方法，他返回的就是AppCompatDelegate，内部的处理是调用AppCompatDelegate的静态方法create来获取不同版本的代理。如下：

 

private static AppCompatDelegate create(Context context, Window window,
        AppCompatCallback callback) {
    final int sdk = Build.VERSION.SDK_INT;
    if (BuildCompat.isAtLeastN()) {
        return new AppCompatDelegateImplN(context, window, callback);
    } else if (sdk >= 23) {
        return new AppCompatDelegateImplV23(context, window, callback);
    } else if (sdk >= 14) {
        return new AppCompatDelegateImplV14(context, window, callback);
    } else if (sdk >= 11) {
        return new AppCompatDelegateImplV11(context, window, callback);
    } else {
        return new AppCompatDelegateImplV9(context, window, callback);
    }
}

这里看到它通过不同版本的API做了区分判断来做具体的实现， AppCompatDelegateImplVxx的类，都是高版本的继承低版本的，最低支持到API9，而 AppCompatDelegateImplV9 中，就是通过 LayoutInflaterFactory 接口来实现 UI 控件替换的代理。

我们再来看看Activity中的setContentView（）方法：

 

public void setContentView(@LayoutRes int layoutResID) {
    getWindow().setContentView(layoutResID);
    initWindowDecorActionBar();
}

这里有一个getWindow（）方法，它返回的是一个Window对象，我们在上一篇就说过，Window是一个抽象类，它只定义了管理屏幕的接口，真正实现它的是phoneWindow，所以我们直接看phoneWindow的setContentView，这个方法有点长，就不在粘贴了，但是里面有这么一句

 

mWindow.getLayoutInflater().setPrivateFactory(this);

可以知道这里使用getLayoutInflater方法设置布局，追踪到这个方法才发现返回的是一个LayoutInflater：

此时我们发现原来是用LayoutInflater的inflate方法加载布局的它包括两种类型的重载形式，一种是加载一个view的id，另一种是加载XmlPullParser。

inflate加载布局源码分析

（1）首先根据id在layout中找到相应的xml布局。源码如下：

 

public static View inflate(Context context, @LayoutRes int resource, ViewGroup root) {
    LayoutInflater factory = LayoutInflater.from(context);
    return factory.inflate(resource, root);
}

（2）把找到的xml文件使用pull解析，一步一解析，再次调用inflate的XmlPullParser的参数形式的方法。在这个解析过程中采用递归的形式一步步解析，解析到相关的view添加到布局里面，递归的使用createViewFromTag()创建子View，并通过ViewGroup.addView添加到parent view中，源码如下：

 

public View inflate(@LayoutRes int resource, @Nullable ViewGroup root, boolean attachToRoot) {
    final Resources res = getContext().getResources();
    if (DEBUG) {
        Log.d(TAG, "INFLATING from resource: \"" + res.getResourceName(resource) + "\" ("
                + Integer.toHexString(resource) + ")");
    }

    final XmlResourceParser parser = res.getLayout(resource);
    try {
        return inflate(parser, root, attachToRoot);
    } finally {
        parser.close();
    }
}

总结：

1.通过Activity的setContentView方法间接调用Phonewindow的setContentView（），在PhoneWindow中通过getLayoutInflate（）得到LayoutInflate对象

2.通过LayoutInflate对象去加载View，主要步骤是

（1）通过xml的Pull方式去解析xml布局文件，获取xml信息，并保存缓存信息，因为这些数据是静态不变的

（2）根据xml的tag标签通过反射创建View逐层构建View

（3）递归构建其中的子View，并将子View添加到父ViewGroup中；

四种xml文件加载的常用方法：

1、使用view的静态方法
View view=View.inflate(context, R.layout.child, null);
2、通过系统获取
LayoutInflater inflater = (LayoutInflater)context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
View view= inflater.inflate(R.layout.child, null);
3、通过LayoutInflater
LayoutInflater inflater = LayoutInflater.from(context);
View view= inflater.inflate(R.layout.child, null);
4、通过getLayoutInflater
View view=getLayoutInflater().inflate(R.layout.child, null);

 

在view加载结束之后，就开始绘制UI了，在这绘制的过程中如何绘制？执行了哪些方法步骤呢？

View的绘制流程

这一部分打算从四个方面来说：

1.View树的绘制流程

2.mesure（）方法

3.layout（）方法

4.draw（）方法

首先说说这个View树的绘制流程：

说到这个流程，我们就必须先搞清楚这个流程是谁去负责的

实际上，view树的绘制流程是通过ViewRoot去负责绘制的，ViewRoot这个类的命名有点坑，最初看到这个名字，翻译过来是view的根节点，但是事实完全不是这样，ViewRoot其实不是View的根节点，它连view节点都算不上，它的主要作用是View树的管理者，负责将DecorView和PhoneWindow“组合”起来，而View树的根节点严格意义上来说只有DecorView；每个DecorView都有一个ViewRoot与之关联，这种关联关系是由WindowManager去进行管理的；

那么decorView与ViewRoot的关联关系是在什么时候建立的呢？答案是Activity启动时，ActivityThread.handleResumeActivity()方法中建立了它们两者的关联关系，当建立好了decorView与ViewRoot的关联后，ViewRoot类的requestLayout()方法会被调用，以完成应用程序用户界面的初次布局。也就是说，当Activity获取到了用户的触摸焦点时，就会请求开始绘制布局，这也是整个流程的起点；而实际被调用的是ViewRootImpl类的requestLayout()方法，这个方法的源码如下：（ViewRootImpl源码是隐藏的，我在Android Studio通过普通方式无法获取到，最后在android-sdk文件中获取的  F:\android_sdk\sources\android-26\android\view）
 

@Overridepublic void requestLayout() { if (!mHandlingLayoutInLayoutRequest) { // 检查发起布局请求的线程是否为主线程 checkThread(); mLayoutRequested = true; scheduleTraversals(); }}

@Overridepublic void requestLayout() { if (!mHandlingLayoutInLayoutRequest) { // 检查发起布局请求的线程是否为主线程 checkThread(); mLayoutRequested = true; scheduleTraversals(); }}

@Overridepublic void requestLayout() { if (!mHandlingLayoutInLayoutRequest) { // 检查发起布局请求的线程是否为主线程 checkThread(); mLayoutRequested = true; scheduleTraversals(); }}

@Overridepublic void requestLayout() { if (!mHandlingLayoutInLayoutRequest) { // 检查发起布局请求的线程是否为主线程 checkThread(); mLayoutRequested = true; scheduleTraversals(); }}

@Override
public void requestLayout() {
    if (!mHandlingLayoutInLayoutRequest) {
        checkThread();
        mLayoutRequested = true;
        scheduleTraversals();
    }
}

上面的方法中调用了scheduleTraversals()方法来调度一次完成的绘制流程，该方法会向主线程发送一个“遍历”消息，最终会导致ViewRootImpl的performTraversals()方法被调用。下面，我们以performTraversals()为起点，来分析View的整个绘制