今天碰到了在XML中应用以内部类形式定义的自定义view,结果遇到了一些坑。虽然通过看了一些前辈写的文章解决了这个问题,但是我看到的几篇都没有完整说清楚why,于是决定做这个总结。
使用自定义内部类view的规则
本文主要是总结why,所以先把XML布局文件中引用内部类的自定义view的做法摆出来,有四点:
1.自定义的类必须是静态类;
2.使用view作为XML文件中的tag,注意,v是小写字母,小写字母v,小写字母v;
3.添加class属性,注意,没有带android:命名空间的,表明该自定义view的完整路径,且外部类与内部类之间用美元“$”连接,而不是“.”,注意,要美元“$”,不要“.”;
4.自定义的view至少应该含有带有Context, AttributeSet这两个参数的构造函数
布局加载流程主要代码
首先,XML布局文件的加载都是使用LayoutInflater来实现的,通过这篇文章的分析,我们知道实际使用的LayoutInflater类是其子类PhoneLayoutInflater,然后通过这篇文章的分析,我们知道view的真正实例化的关键入口函数是createViewFromTag这个函数,然后通过createView来真正实例化view,下面便是该流程用到的关键函数的主要代码:
final Object[] mConstructorArgs = new Object[2];
static final Class>[] mConstructorSignature = new Class[] {
Context.class, AttributeSet.class};
//...
View createViewFromTag(View parent, String name, Context context, AttributeSet attrs,
boolean ignoreThemeAttr) {
//
if (name.equals("view")) {
name = attrs.getAttributevalue(null, "class");
}
// Apply a theme wrapper, if allowed and one is specified.
if (!ignoreThemeAttr) {
final TypedArray ta = context.obtainStyledAttributes(attrs, ATTRS_THEME);
final int themeResId = ta.getResourceId(0, 0);
if (themeResId != 0) {
context = new ContextThemeWrapper(context, themeResId);
}
ta.recycle();
}
if (name.equals(TAG_1995)) {
// Let's party like it's 1995!
return new BlinkLayout(context, attrs);
}
try {
View view;
if (mFactory2 != null) {
view = mFactory2.onCreateView(parent, name, context, attrs);
} else if (mFactory != null) {
view = mFactory.onCreateView(name, context, attrs);
} else {
view = null;
}
if (view == null && mPrivateFactory != null) {
view = mPrivateFactory.onCreateView(parent, name, context, attrs);
}
if (view == null) {
final Object lastContext = mConstructorArgs[0];
mConstructorArgs[0] = context;
try {
if (-1 == name.indexOf('.')) {
//
view = onCreateView(parent, name, attrs);
} else {
//
view = createView(name, null, attrs);
}
} finally {
mConstructorArgs[0] = lastContext;
}
}
return view;
}
//后面都是catch,省略
}
protected View onCreateView(View parent, String name, AttributeSet attrs)
throws ClassNotFoundException {
return onCreateView(name, attrs);
}
protected View onCreateView(String name, AttributeSet attrs)
throws ClassNotFoundException {
return createView(name, "android.view.", attrs);
}
public final View createView(String name, String prefix, AttributeSet attrs)
throws ClassNotFoundException, InflateException {
Constructor extends View> constructor = sConstructorMap.get(name);
Class extends View> clazz = null;
try {
Trace.traceBegin(Trace.TRACE_TAG_VIEW, name);
if (constructor == null) {
//
// Class not found in the cache, see if it's real, and try to add it
clazz = mContext.getClassLoader().loadClass(
prefix != null ? (prefix + name) : name).asSubclass(View.class);
if (mFilter != null && clazz != null) {
boolean allowed = mFilter.onLoadClass(clazz);
if (!allowed) {
failNotAllowed(name, prefix, attrs);
}
}
constructor = clazz.getConstructor(mConstructorSignature);
constructor.setAccessible(true);
sConstructorMap.put(name, constructor);
} else {
// If we have a filter, apply it to cached constructor
if (mFilter != null) {
// Have we seen this name before?
Boolean allowedState = mFilterMap.get(name);
if (allowedState == null) {
// New class -- remember whether it is allowed
clazz = mContext.getClassLoader().loadClass(
prefix != null ? (prefix + name) : name).asSubclass(View.class);
boolean allowed = clazz != null && mFilter.onLoadClass(clazz);
mFilterMap.put(name, allowed);
if (!allowed) {
failNotAllowed(name, prefix, attrs);
}
} else if (allowedState.equals(Boolean.FALSE)) {
failNotAllowed(name, prefix, attrs);
}
}
}
Object[] args = mConstructorArgs;
args[1] = attrs;
//
final View view = constructor.newInstance(args);
if (view instanceof ViewStub) {
// Use the same context when inflating ViewStub later.
final ViewStub viewStub = (ViewStub) view;
viewStub.setLayoutInflater(cloneInContext((Context) args[0]));
}
return view;
}
//后面都是catch以及finally处理,省略
}
PhoneLayoutInflater中用到的主要代码:
public class PhoneLayoutInflater extends LayoutInflater {
private static final String[] sClassPrefixList = {
"android.widget.",
"android.webkit.",
"android.app."
};
//......
@Override protected View onCreateView(String name, AttributeSet attrs) throws ClassNotFoundException {
//
for (String prefix : sClassPrefixList) {
try {
View view = createView(name, prefix, attrs);
if (view != null) {
return view;
}
} catch (ClassNotFoundException e) {
// In this case we want to let the base class take a crack
// at it.
}
}
return super.onCreateView(name, attrs);
}
//.........
}
WHY
对于任何一个XML中的元素,首先都是从“1”处开始(“1”即表示代码中标注“关键1”的位置,后同),下面便跟着代码的流程来一遍:
1.“1”处进行名字是否为“view”的判断,那么这里会有两种情况,我们先假设使用“view”
2.由于在“1”满足条件,所以name被赋值为class属性的值,比如“com.willhua.view.MyView”或者“com.willhua.view.MyClass$MyView”。其实这里也是要使用“view”来定义,而不是其他名字来定义的原因。
3.根据name的值,name中含有‘.'符号,于是代码走到“3”处,调用createView,且prefix参数为空
4.来到“4”处,prefix为空,于是loadClass函数的参数即为name,即在a.2中说的class属性的值。我们知道,传给loadClass的参数是想要加载的类的类名,而在Java中,内部类的类名表示都是在外部类类名的后面用符号“$”连接内部类类名而来,于是文章开头提到的第3点的答案也就是在这里了。补充一下,为什么是来到“4”,而不是对应的else块中呢?类第一次被加载的时候,构造器肯定是还不存在的,也就是if条件肯定是成立的。然后等到后面再次实例化的时候,就来到了else块中,而在else快中只是根据mFilter做一些是否可以加载该view的判断而已,并没有从本质上影响view的加载流程。
5.在“4”处还有一个很重要的地方,那就是constructor = class.getConstructor(mConstructorSignature)这句。首先,在代码开头已经给出了mConstructorSignature的定义:
static final Class>[] mConstructorSignature = new Class[] {Context.class, AttributeSet.class};
在Oracle的文档上找到getConstructor函数的说明:
Returns a Constructor object that reflects the specified public constructor of the class represented by this Class object. The parameterTypes parameter is an array of Class objects that identify the constructor's formal parameter types, in declared order. If this Class object represents an inner class declared in a non-static context, the formal parameter types include the explicit enclosing instance as the first parameter.
The constructor to reflect is the public constructor of the class represented by this Class object whose formal parameter types match those specified by parameterTypes.
于是,这里其实解答了我们两个问题:(1)getConstructor返回的构造函数是其参数与传getConstructor的参数完全匹配的那一个,如果没有就抛出NoSuchMethodException异常。于是我们就知道,必须要有一个与mConstructorSignature完全匹配,就需要Context和AttributeSet两个参数的构造函数;(2)要是该类表示的是非静态的内部类,那么应该把一个外部类实例作为第一个参数传入。而我们的代码中传入的mConstructorSignature是不含有外部类实例的,因此我们必须把我们自定义的内部类view声明为静态的才不会报错。有些同学的解释只是说到了非静态内部类需要由一个外部类实例来引用,但我想那万一系统在加载的时候它会自动构造一个外部类实例呢?于是这里给了否定的答案。
6. 拿到了类信息clazz之后,代码来到了“5”,在这里注意下mConstructorArgs,在贴出的代码最前面有给出它的定义,为Object[2],并且,通过源码中发现,mConstructorArgs[0]被赋值为创建LayoutInflater时传入的context。于是我们就知道 在“5”这里,传给newInstance的参数为Context和AttributeSet。然后在Oracl的文档上关于newInstance的说明中也有一句:If the constructor's declaring class is an inner class in a non-static context, the first argument to the constructor needs to be the enclosing instance; 我们这里也没有传入外部类实例,也就是说对于静态内部类也会报错。这里同样验证了自定义了的内部类view必须声明为静态类这个问题。
至此,我们已经在假设使用“view”,再次强调是小写‘v',作为元素名称的情况,推出了要在XML中应用自定义的内部类view必须满足的三点条件,即在class属性中使用“$”连接外部类和内部类,必须有一个接受Context和AttributeSet参数的构造函数,必须声明为静态的这三个要求。
而如果不使用“view”标签的形式来使用自定义内部类view,那么在写XML的时候我们发现,只能使用比如
在标识的“2”处,该出的调用流程为onCreateView(parent, name, attrs)——>onCreateView(name, attrs)——>createView(name, "android.view.", attrs),在前面提到过,我们真正使用的的LayoutInflater是PhoneLayoutInflater,而在PhoneLayoutInflater对这个onCreateView(name, attrs)函数是进行了重写的,在PhoneLayoutInflater的onCreateView函数中,即“6”处,该函数通过在name前面尝试分别使用三个前缀:"android.widget.","android.webkit.","android.app."来调用createView,若都没有找到则调用父类的onCreateView来尝试添加"android.view."前缀来加载该view。所以,这也是为什么我们可以比如直接使用,
总结
至此,开篇提到的四个要求我们都已经找到其原因了。其实,整个流程走下来,我们发现,要使定义的元素被正确的加载到相关的类,有三种途径:
1.只使用简单类名,即
2.使用<"完整类名" />的形式,比如
3.使用
为了搞清楚加载内部类view的问题,结果对整个加载流程都有了一定了解,感觉能说多若干个why了,还是收获挺大的。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持考高分网。



