Android中的LayoutInflater分析（一）

PS：本文系转载文章，阅读原文可读性会更好，文章末尾有原文链接

ps：本篇文章是基于 Android Api 26 来分析的

1、LayoutInflater 创建过程

2、LayoutInflater 创建 View 过程

在 Android 中，LayoutInflater 一般叫做为布局解析器或者又叫填充器，LayoutInflater 就是将 XML 布局文件实例化为对应的 View 对象，LayoutInflater 不能直接通过 new 的方式获取，需要通过 Activity.getLayoutInflater() 或 Context.getSystemService() 获取与当前 Context 已经关联且正确配置的标准 LayoutInflater。

1、LayoutInflater 创建过程

在系统中，我们获取 LayoutInflater 对象的方式有2种，一种是通过 LayoutInflater 的 from(Context context) 方法获得；一种是通过 Activity 的 getLayoutInflater方法获得，通过 Activity 的 getLayoutInflater方法获得的 LayoutInflater 最终还是调用 LayoutInflater 的 from(Context context) 方法，如何证明？我们从 Activity 的 getLayoutInflater方法入手看看；

@NonNull
public LayoutInflater getLayoutInflater() {
    return getWindow().getLayoutInflater();
}

Activity 的 getWindow 方法得到的是 Window 类型的对象，而 Window 的实现类是 PhoneWindow（要想知道 Window 的实现类是 PhoneWindow 可以看Android中View事件的分发第一篇这篇文章），所以我们往下看 PhoneWindow 的 getLayoutInflater方法；

@Override
public LayoutInflater getLayoutInflater() {
    return mLayoutInflater;
}

可以看到 PhoneWindow 的 getLayoutInflater 方法直接返回 mLayout-Inflater 字段，那 mLayoutInflater 字段是在哪里赋值的呢？它被赋值的地方只有一次，那就是 PhoneWindow 的构造方法 PhoneWindow(Context context) ；

public PhoneWindow(Context context) {

    super(context);
    mLayoutInflater = LayoutInflater.from(context);

}

从这里可以证明出，通过 Activity 的 getLayoutInflater方法获得的 LayoutInflater 最终还是调用 LayoutInflater 的 from(Context context) 方法。

好了，我们现在开始进行分析 LayoutInflater 的创建过程，我们来看看 LayoutInflater 的 from(Context context) 方法；

public static LayoutInflater from(Context context) {

    
    //1、
    LayoutInflater LayoutInflater =
            (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
    if (LayoutInflater == null) {
        throw new AssertionError("LayoutInflater not found.");
    }
    return LayoutInflater;

}

注释1 这里，用 Context 的 getSystemService(@ServiceName @NonNull String name) 方法来创建 LayoutInflater 对象，但是 Context 的 getSys-temService(@ServiceName @NonNull String name) 方法是一个抽象方法，而在于它的实现类上，这里的 context 可以是 Activity、Application 和 Service 中的一个实例，我们就以 context 是 Activity 实例化的来进行分析，但在 Activity 中还是没有重写getSystemService(@ServiceName @NonNull String name) 方法，只是在 Activity 的父类 ContextWrapper 进行了重写；

@Override
public Object getSystemService(String name) {
    
    //2、
    return mBase.getSystemService(name);
}

注释2 中的 mBase 是 Context 类型的对象，它的实现类是 ContextImpl（要想知道为什么mBase 的实现类是 ContextImpl，可以看Android中Application、Activity和Service它们真正干活的Context是什么？这篇文章），所以我们看 ContextImpl 类的 getSystemService(String name) 方法；

@Override
public Object getSystemService(String name) {
    
    //3、
    return SystemServiceRegistry.getSystemService(this, name);
}

看注释3，ContextImpl 类的 getSystemService(String name) 方法调用了 SystemServiceRegistry 的 getSystemService(ContextImpl ctx, String name) 方法；

public static Object getSystemService(ContextImpl ctx, String name) {

    
    //4、
    ServiceFetcher fetcher = SYSTEM_SERVICE_FETCHERS.get(name);
    
    //5、
    return fetcher != null ? fetcher.getService(ctx) : null;
}

我们看注释4 的代码，特别是 SYSTEM_SERVICE_FETCHERS 这个常量，它是个 HashMap 类型的，只是看到它通过 key 为 name 而取出 value 为 ServiceFetcher 的操作，那它又是在哪里保存的呢？我们看一下 SystemServiceRegistry 的静态代码块；

final class SystemServiceRegistry {

    ......
    static {
        ......
        //6、
        registerService(Context.LAYOUT_INFLATER_SERVICE, LayoutInflater.class,
                new CachedServiceFetcher() {
                    @Override
                    public LayoutInflater createService(ContextImpl ctx) {
                        return new PhoneLayoutInflater(ctx.getOuterContext());
                    }});
        ......
    }
    ......
}

看注释6 的代码，name 为 Context.LAYOUT_INFLATER_SERVICE，这里把 CachedServiceFetcher（并重写 createService(ContextImpl ctx) 方法返回 PhoneLayoutInflater 对象）对象作为参数之一并调用 SystemServiceRegistry 的 registerService 方法（参数比较多，我这不方便列举出来，具体看下面的代码）；

private static void registerService(String serviceName, Class serviceClass,

                                        ServiceFetcher serviceFetcher) {
    SYSTEM_SERVICE_NAMES.put(serviceClass, serviceName);
    
    //7、
    SYSTEM_SERVICE_FETCHERS.put(serviceName, serviceFetcher);
}

看注释7 的代码，当 serviceName 为 Context.LAYOUT_INFLAT-ER_SERVICE 时，SYSTEM_SERVICE_FETCHERS 保存的是 CachedServiceFetcher 对象；回到注释4 的代码，fetcher 变量不为空，且本质是 CachedServiceFetcher 对象；再看注释5 的代码，也就是 CachedServiceFetcher（该类是 SystemServiceRegistry 的内部类）的 getService(ContextImpl ctx) 方法；

static abstract class CachedServiceFetcher implements ServiceFetcher {

    ......
    @Override
    @SuppressWarnings("unchecked")
    public final T getService(ContextImpl ctx) {
        final Object[] cache = ctx.mServiceCache;
        synchronized (cache) {
            // Fetch or create the service.
            Object service = cache[mCacheIndex];
            if (service == null) {
                try {

                    //8、
                    service = createService(ctx);
                    cache[mCacheIndex] = service;
                } catch (ServiceNotFoundException e) {
                    onServiceNotFound(e);
                }
            }
            return (T)service;
        }
    }

    public abstract T createService(ContextImpl ctx) throws ServiceNotFoundException;

}

CachedServiceFetcher 的 getService(ContextImpl ctx) 方法返回的对象是通过 CachedServiceFetcher 的 createService(ContextImpl ctx) 方法创建的，上面分析注释6 的代码的时候就已经说过 CachedServiceFetcher 对象创建后就重写了 createService(ContextImpl ctx) 方法返回 PhoneLayoutIn-flater 对象，所以 PhoneWindow 创建的 LayoutInflater 本质上是创建 PhoneLayoutInflater 对象。

我们知道，通过 Activity、Application 和 Service 都能拿到一个 PhoneLayoutInflater 对象，它们拿到的 PhoneLayoutInflater 对象是有区别的吗？答案是有区别的，Application 和 Service 拿到的是同一个 PhoneLayoutInflater 对象；而每一个 Activity 拿到的是不同的 PhoneLayoutInflater 对象，更别说 Activity 和它们（Application 和 Service）的拿到的是同一个对象了。好了，我们先分析 Application 和 Service 拿到的 PhoneLayoutInflater 对象，我们知道 Application 和 Service都继承于 ContextWrapper，在 ContextWrapper 的 getSystemService(String name) 方法并没有做特殊处理（看注释2 的代码），都是用 ContextImpl 的 getSystemService(String name) 方法调用 SystemServiceRegistry 的静态方法 getSystemService(ContextImpl ctx, String name) 拿到同一个 CachedServiceFetcher 对象，而且 CachedServiceFetcher 重写的 createService(ContextImpl ctx) 方法只会被调用一次，因为只有 service为空的时候才会被调用（看注释8 的代码），创建好 PhoneLayoutInflater 对象后将其保存到 cache 数组中，所以Application 和 Service 拿到的是同一个 PhoneLayoutInflater 对象。

但是 Activity 就不一样了，Activity 继承了 ContextThemeWrapper 并让 ContextThemeWrapper 重写了 getSystemService(String name)方法；

@Override
public Object getSystemService(String name) {
    if (LAYOUT_INFLATER_SERVICE.equals(name)) {
        if (mInflater == null) {
            
            //9、
            mInflater = LayoutInflater.from(getBaseContext()).cloneInContext(this);
        }
        return mInflater;
    }
    return getBaseContext().getSystemService(name);
}

看注释9 的代码并通过前面的分析，LayoutInflater.from(getBaseContext()) 这行代码本质上拿到的是 PhoneLayoutInflater 对象，然后调用 PhoneLayoutInflater 的 cloneInContext(Context newContext)方法；

public LayoutInflater cloneInContext(Context newContext) {

    
    //10、
    return new PhoneLayoutInflater(this, newContext);
}

看见注释10 的代码没有，每个 Activity 拿到的 PhoneLayoutInflater 都是重新创建的，我们再往下追踪 PhoneLayoutInflater的构造器；

protected PhoneLayoutInflater(LayoutInflater original, Context newContext) {
    
    //11、
    super(original, newContext);
}

看注释11 的代码，这里的 super 表示 LayoutInflater，我们再跟踪父类 LayoutInflater的构造器；

protected LayoutInflater(LayoutInflater original, Context newContext) {

    mContext = newContext;
    mFactory = original.mFactory;
    mFactory2 = original.mFactory2;
    mPrivateFactory = original.mPrivateFactory;
    setFilter(original.mFilter);
}

参数 original 是应用进程级的 LayoutInflater，即在 SystemServiceRegistry 中保存，并把应用进程级的配置给了Activity 的 LayoutInflater ，这也符合了 LayoutInflater 的自我介绍 “ 且是正确配置的标准 LayoutInflater ”。

2、LayoutInflater 创建 View 过程

在日常开发中，我们也会用到 LayoutInflater来创建一个 View ，常写的语句如下所示；

LayoutInflater.from(context).inflate(R.layout.item,root,false);

首先 LayoutInflater.from(context) 拿到的肯定是 PhoneLayoutInflater对象，我们来看一下 PhoneLayoutInflater 的 inflate 方法（该方法在 LayoutInflater 里实现，因为 PhoneLayoutInflater 继承于 LayoutInflater，还有一个是该方法参数太多，我不方便写，具体参数看下面的代码，我又给它另起名 method1）；

public View inflate(@LayoutRes int resource, @Nullable ViewGroup root, boolean attachToRoot) {

    ......
    try {
        //12、
        return inflate(parser, root, attachToRoot);
    } finally {
        parser.close();
    }
}

看注释12 的代码，PhoneLayoutInflater 的 inflate 方法（method1）又调用重载的另一个 inflate 方法（该方法也是在 LayoutInflater 里实现，参数不一样，同时参数太多不方便写，具体参数看下面的代码，我又给它另起名 method2）；

public View inflate(XmlPullParser parser, @Nullable ViewGroup root, boolean attachToRoot) {

    synchronized (mConstructorArgs) {
        ......
        //13、
        final AttributeSet attrs = Xml.asAttributeSet(parser);
        Context lastContext = (Context) mConstructorArgs[0];
        mConstructorArgs[0] = inflaterContext;

        //14、
        View result = root;

        try {
            // Look for the root node.
            int type;
            while ((type = parser.next()) != XmlPullParser.START_TAG &&
                    type != XmlPullParser.END_DOCUMENT) {
                // Empty
            }

            //15、
            if (type != XmlPullParser.START_TAG) {
                throw new InflateException(parser.getPositionDescription()
                        + ": No start tag found!");
            }
            ......
            //16、
            if (TAG_MERGE.equals(name)) {

                //17、
                if (root == null || !attachToRoot) {
                    throw new InflateException(" can be used only with a valid "
                            + "ViewGroup root and attachToRoot=true");
                }

                //18、
                rInflate(parser, root, inflaterContext, attrs, false);
            } else {
                // Temp is the root view that was found in the xml
                //19、
                final View temp = createViewFromTag(root, name, inflaterContext, attrs);

                ViewGroup.LayoutParams params = null;

                //20、
                if (root != null) {
                    ......
                    // Create layout params that match root, if supplied
                    //21、
                    params = root.generateLayoutParams(attrs);
                    if (!attachToRoot) {
                        // Set the layout params for temp if we are not
                        // attaching. (If we are, we use addView, below)
                        //22、
                        temp.setLayoutParams(params);
                    }
                }
                ......
                // Inflate all children under temp against its context.
                //23、
                rInflateChildren(parser, temp, attrs, true);

                if (DEBUG) {
                    System.out.println("-----> done inflating children");
                }

                // We are supposed to attach all the views we found (int temp)
                // to root. Do that now.
                //24、
                if (root != null && attachToRoot) {
                    root.addView(temp, params);
                }

                // Decide whether to return the root that was passed in or the
                // top view found in xml.
                //25、
                if (root == null || !attachToRoot) {
                    result = temp;
                }
            }

        } catch (XmlPullParserException e) {
            ......
        } catch (Exception e) {
            ......
        } finally {
            ......
        }

        return result;
    }

}

分析上面的 PhoneLayoutInflater 的 inflate 方法（method2）之前，我们先给出2张图；

图片

                                         图1

图片

图2

注释13 的代码表示获取 xml 布局文件的属性；注释14 的代码表示保存根视图，最终会将根视图返回；注释15 的代码表示如果找不到根标签，那么就会抛出异常；注释19 的代码表示创建具体的 View；注释21 的代码表示如果根视图 root 不为空，那么通过 root 创建对应的 LayoutParams 对象；注释22 的代码表示如果创建的 View 不需要添加到根视图 root 中，那么直接设置 View 的 LayoutParams；注释22 的代码表示如果根视图 root 不为空且需要添加到 root 中，那么就将创建好的 View 添加到 root 里面；注释25 的代码表示如果根视图 root 为空且不需要添加根视图里面，那么就用第一次创建的 View 作为根视图。

下面我们举个例子，再详细解释一下，假设图1 的布局文件叫 layout_1.xml，图2 的布局文件叫 layout_2.xml，root 为 Activity 里的 setContentView 方法里面的布局文件里的一个 ViewGroup，那么我已知的3个东西创建一个 View，看下面代码咯（下面代码的 this，我假设它是 Activity）；

    //26、
    View view = LayoutInflater.from(this).inflate(R.layout.layout_1,root,false);
    
    //27、
    View view2 = LayoutInflater.from(this).inflate(R.layout.layout_1,root,true);
    
    //28、
    View view3 = LayoutInflater.from(this).inflate(R.layout.layout_1,null,false);
    
    //29、
    View view4 = LayoutInflater.from(this).inflate(R.layout.layout_2,root,true);

看注释26 的代码中的 inflate 方法（method2），由于 layout_1.xml 文件中根标签不是 merge，而是 RelativeLayout ，所以会执行注释19 的代码，由于 root 不为空，attachToRoot 为 false，所以也会执行注释20、21、22 的代码，注释26 的代码执行完后最终返回 root。

看注释27 的代码中的 inflate 方法（method2），由于 layout_1.xml 文件中根标签不是 merge，而是 RelativeLayout ，所以会执行注释19 的代码，由于 root 不为空，attachToRoot 为 true，所以会执行注释20、21 、24的代码，注释27 的代码执行完后最终返回 root。

看注释28 的代码中的 inflate 方法（method2），由于 layout_1.xml 文件中根标签不是 merge，而是 RelativeLayout ，所以会执行注释19 的代码，由于 root 为空，attachToRoot 为 false，所以会执行注释25的代码，注释28 的代码执行完后最终返回 RelativeLayout 对象。

看注释29 的代码中的 inflate 方法（method2），由于 layout_2.xml 文件中根标签是 merge，所以会执行注释16 的代码，注释16 的代码表示判断是否是 merge 标签，这里的 root 不能为空，且 attachToRoot 要为true，不然会执行注释17 的代码引发报错，29 的代码执行完后最终返回 root。

注释18 的代码和注释23 的代码本质上都是解析子标签，只是参数不一样而已，都是调用同一个方法；本篇文章先写到这里，由于还没有分析完，注释18、23 的代码分析，下一篇文章见。

本篇文章写到这里就结束了，由于技术水平有限，文章中难免会出错，欢迎大家批评指正。

Android中的LayoutInflater分析（一）

你可能感兴趣的:(androidjava)