记一次 View.getContext() 遇到的大坑

2,245 阅读2分钟

有的时候不能盲目自信,不然会踩到大坑啊,哎。。还是因为太菜了。

事情的经过是这样子滴: 有一个特殊条件,需要把View的context强转为Activity。

大概是这样子的:

imageView.context as Activity

这个时候我是比较确信这个view的context一定是Activity的,所以没有加以下判断。

if (imageView.context is Activity)

然后坑就来了。。 4.x该蹦的全崩了。。当时我的心情犹如股市大跌,想要去跳楼。

确信的理由

为什么我当时认为这个context一定是Activity呢,其实不是没有理由的。因为我的imageView是写在xml里的,大家都知道,setContextView(),其实就是PhoneWindow的setContentView():

发现这个view是LayoutInflater解析xml反射出来的。view的context就是LayoutInflater的mContext:

这个LayoutInflater的context是PhoneWindow传进去的:

PhoneWindow的context就是Activity的this:

所以,也就是说,一个写在xml里的View,他的context就是Activity。 源码是这样告诉我的。可是为什么4.x都崩了呢,4.x的view的context到底是什么呢?

刨根问底

如果你听过LayoutInflaterFactory,那么大概就能想出是什么原因了,代码是不会骗人的,可是为什么View的context变了呢,那只能是有其他代码在搞鬼。所有Appcompat的Activity,创建View的时候,都会对基本View做一个风格的包装,也就是说ImageView会变成AppcompatImageView。 那么实际上,imageView.context 是AppcompatImageView的getContext().

研究发现,AppcompatImageView并没有重写getContext()方法,那么到底怎么回事呢,直接看他的构造器:

卧槽,坑爹呢这是! 发现即使context传进来是个activity,也回被包装成TintContextWrapper。

那么为什么5.0以上系统,获得的还是一个Activity呢?

继续看:

nnd,原来如此,看样子是v7包为了能加载到一些特殊资源,给包裹成了TintContextWrapper。 所以强转出错!!!

这个故事告诉我们,就算你有绝对的自信,你也不能保证你百分百正确,该遵守的一些优良习惯,还是要养成的。。