乐趣区

关于android: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<LayoutInflater>() {
                    @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 <T> void registerService(String serviceName, Class<T> serviceClass,

                                        ServiceFetcher<T> 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<T> implements ServiceFetcher<T> {

    ......
    @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("<merge /> 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 的代码剖析,下一篇文章见。

本篇文章写到这里就完结了,因为技术水平无限,文章中难免会出错,欢送大家批评指正。

退出移动版