写在前面
今天和老爸去医院了,老爸最近腰疼,幸好没什么事,各位也要多多爱惜自己的身体,等身体出了问题就来不及了。好了,闲话到此为止,话说《开发艺术探索》里面不少东西我早就看了,但是因为自己当时水平有限,而且有很多也看不大懂,所以看了忘是挺正常的事。不过感觉随着工作经验的增长,以前大学里上过《操作系统》、《计算机网络》、《数据结构》等一些课都被串到了一起,感觉很好,而且愈发能感觉到自己的不足了。这周的文主要算是一篇读书笔记吧,记一下读《开发艺术探索》第四章和View相关的笔记,至于ViewGroup我觉得还需要过段时间,在沉淀一下再来和各位一起探索一下。而且说真的,这篇文我也是硬着头皮写下来的,因为看源码看着看着发现我疑问越来越多,很多都是现阶段暂时无法解决的,不过问题总是一个一个去解决的,先过一遍View的measure流程再说其他的。
ViewRoot & DecorView
ViewRoot对应于ViewRootImpl类,在ViewRootImpl类中有如下一段注释:
/** * The top of a view hierarchy, implementing the needed * protocol between View and the WindowManager. */
View层最顶部,实现了View和WindowManager间所需的协议。这个类很重要,但是我现在对其理解也不是很深(一是因为读源码无力,一是没有系统的阅读过源码),所以就拿书上的话来说:它是连接WindowManager和DecorView的纽带,View的三大流程均是通过ViewRoot来完成的。在ActivityThread中(同样很有意思的一点是ActivityThread是一个类,并非线程什么的,当然了如果哪一天我读通了这一块回来和各位分享的),当Activity对象被创建完毕后,会将DecorView添加到Window中,同时会创建ViewRootImpl对象,并将ViewRootImpl对象和DecorView建立关联。
接下来直接放结论,尽快进入正题:
View的绘制流程是从ViewRoot的performTraversals开始的,它经过measure、layout和draw三个过程才能最终将一个View绘制出来。
MeasureSpec
在之前Android自定义View你需要知道的一些东西中我已经简要的介绍过MeasureSpec了,当然在这不敢再麻烦各位去看了,继续简介一下,熟悉的可以跳过这段。
首先咱直接看他的注释,看看注释是怎么解释这玩意的:
/** * A MeasureSpec encapsulates the layout requirements passed from parent to child. * Each MeasureSpec represents a requirement for either the width or the height. * A MeasureSpec is comprised of a size and a mode. There are three possible * modes: * <dl> * <dt>UNSPECIFIED</dt> * <dd> * The parent has not imposed any constraint on the child. It can be whatever size * it wants. * </dd> * * <dt>EXACTLY</dt> * <dd> * The parent has determined an exact size for the child. The child is going to be * given those bounds regardless of how big it wants to be. * </dd> * * <dt>AT_MOST</dt> * <dd> * The child can be as large as it wants up to the specified size. * </dd> * </dl> * * MeasureSpecs are implemented as ints to reduce object allocation. This class * is provided to pack and unpack the <size, mode> tuple into the int. */
最上面那段话的大概意思是一个MeasureSpec封装了一个从父(控件)传给子(控件)的布局要求。每个MeasureSpec代表的不是宽就是高的要求。一个MeasureSpec包含了一个尺寸和一个(测量)模式,这些模式如下:
UNSPECIFIED
父(容器)对子(控件)没有任何限制,子控件可以想要多大就有多大。EXACTLY
父容器已经决定了子控件的精确尺寸,子控件将会变成被给出的约束大小,不管他自己想要变成啥样。AT_MOST
子控件可以和和他想要的规格尺寸一样大。
最后一段话解释了一下为什么这么实现,暂时不需要咱关心这些。看完了注释基本上已经对MeasureSpec有了一个基本的认识了。但是看完这段注释,应该会产生一个疑惑,在注释中说MeasureSpec是父传递给子的,那么最顶层的DecorView的MeasureSpec是如何来的呢?《开发艺术探索》上说是在ViewRootImpl的measureHierarchy方法中创建的,主要代码如下:
childWidthMeasureSpec = getRootMeasureSpec(desiredWindowWidth,lp.width); childHeightMeasureSpec = getRootMeasureSpec(desiredWindowHeight,lp.width); performMeasure(childWidthMeasureSpec,childHeightmeasureSpec);
其中desiredWindowWidth和desiredWindowHeight就是屏幕的尺寸,追踪下getRootMeasureSpec()源码看看:
private static int getRootMeasureSpec(int windowSize, int rootDimension) { int measureSpec; switch (rootDimension) { case ViewGroup.LayoutParams.MATCH_PARENT: // Window can't resize. Force root view to be windowSize. measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.EXACTLY); break; case ViewGroup.LayoutParams.WRAP_CONTENT: // Window can resize. Set max size for root view. measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.AT_MOST); break; default: // Window wants to be an exact size. Force root view to be that size. measureSpec = MeasureSpec.makeMeasureSpec(rootDimension, MeasureSpec.EXACTLY); break; } return measureSpec; }
可以看到该方法中对于match_parent、wrap_content和其余情况的处理:
LayoutParams.MATCH_PARENT:采用精确模式测量,大小是窗口大小
LayoutParams.WRAP_CONTENT:大小不定,最大是窗口大小
其他:结合我们平时写xml和代码的经验,此处其他应该就是我们制定了大小(比如100dp),大小为指定大小。
View的MeasureSpec的获取
上面的MeasureSpec注释里说了,是从父传递到子的,那么View很明显是一个子布局,让我们上ViewGroup里找找child是如何获取MeasureSpec的:
/** * Ask all of the children of this view to measure themselves, taking into * account both the MeasureSpec requirements for this view and its padding. * We skip children that are in the GONE state The heavy lifting is done in * getChildMeasureSpec. * * @param widthMeasureSpec The width requirements for this view * @param heightMeasureSpec The height requirements for this view */ protected void measureChildren(int widthMeasureSpec, int heightMeasureSpec) { final int size = mChildrenCount; final View[] children = mChildren; for (int i = 0; i < size; ++i) { final View child = children[i]; if ((child.mViewFlags & VISIBILITY_MASK) != GONE) { measureChild(child, widthMeasureSpec, heightMeasureSpec); } } }
老规矩,先让我这个渣渣来翻译一下注释……
遍历View去测量他们自身,既要考虑MeasureSpec的要求又要考虑padding。跳过GONE状态的(不测量这个状态的View),更繁重的事在getChildMeasureSpec完成。
很明显,咱得看一下getChildMeasureSpec方法了:
/** * Does the hard part of measureChildren: figuring out the MeasureSpec to * pass to a particular child. This method figures out the right MeasureSpec * for one dimension (height or width) of one child view. * * The goal is to combine information from our MeasureSpec with the * LayoutParams of the child to get the best possible results. For example, * if the this view knows its size (because its MeasureSpec has a mode of * EXACTLY), and the child has indicated in its LayoutParams that it wants * to be the same size as the parent, the parent should ask the child to * layout given an exact size. * * @param spec The requirements for this view * @param padding The padding of this view for the current dimension and * margins, if applicable * @param childDimension How big the child wants to be in the current * dimension * @return a MeasureSpec integer for the child */ public static int getChildMeasureSpec(int spec, int padding, int childDimension) { int specMode = MeasureSpec.getMode(spec); int specSize = MeasureSpec.getSize(spec); int size = Math.max(0, specSize - padding); int resultSize = 0; int resultMode = 0; switch (specMode) { // Parent has imposed an exact size on us case MeasureSpec.EXACTLY: if (childDimension >= 0) { resultSize = childDimension; resultMode = MeasureSpec.EXACTLY; } else if (childDimension == LayoutParams.MATCH_PARENT) { // Child wants to be our size. So be it. resultSize = size; resultMode = MeasureSpec.EXACTLY; } else if (childDimension == LayoutParams.WRAP_CONTENT) { // Child wants to determine its own size. It can't be // bigger than us. resultSize = size; resultMode = MeasureSpec.AT_MOST; } break; // Parent has imposed a maximum size on us case MeasureSpec.AT_MOST: if (childDimension >= 0) { // Child wants a specific size... so be it resultSize = childDimension; resultMode = MeasureSpec.EXACTLY; } else if (childDimension == LayoutParams.MATCH_PARENT) { // Child wants to be our size, but our size is not fixed. // Constrain child to not be bigger than us. resultSize = size; resultMode = MeasureSpec.AT_MOST; } else if (childDimension == LayoutParams.WRAP_CONTENT) { // Child wants to determine its own size. It can't be // bigger than us. resultSize = size; resultMode = MeasureSpec.AT_MOST; } break; // Parent asked to see how big we want to be case MeasureSpec.UNSPECIFIED: if (childDimension >= 0) { // Child wants a specific size... let him have it resultSize = childDimension; resultMode = MeasureSpec.EXACTLY; } else if (childDimension == LayoutParams.MATCH_PARENT) { // Child wants to be our size... find out how big it should // be resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size; resultMode = MeasureSpec.UNSPECIFIED; } else if (childDimension == LayoutParams.WRAP_CONTENT) { // Child wants to determine its own size.... find out how // big it should be resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size; resultMode = MeasureSpec.UNSPECIFIED; } break; } return MeasureSpec.makeMeasureSpec(resultSize, resultMode); }
咱继续翻译一下……
做测量children困难的部分:算出MeasureSpec传递给
一个child。这个方法为一个子view的一个尺寸(高或宽)算出正确的MeasureSpec。
他的目的是组合MeasureSpec和LayoutParams的信息让child获取最好的可能结果。例如:如果这个view知道他的尺寸(因为测量模式是EXACTLY),这个child已经指出了他的LayoutParams,他想和他的父容器有一样的尺寸(match_parent),这时父容器应该要求child布局成被给的精确尺寸。
从上面的注释我们可以了解到,子View的MeasureSpec并不是由其自身的LayoutParams决定的,而是由其父容器和其自身的LayoutParams一同决定的。接下来看一下代码,看看究竟是怎么操作的:
首先从ViewGroup的宽/高的MeasureSpec中获取到对应的specMode,然后根据不同的mdoe去执行不同的操作
EXACTLY:如果子View指定了精确值的大小,那么测量模式是EXACTLY,尺寸是传入的childDimension,这两个值将会被打包成一个MeasureSpec并返回。如果childDimension等于MATCH_PARENT,那么就将上面获取到的自身尺寸和EXACTLY模式打包成一个MeasureSpec打包并返回。如果childDimension等于WRAP_CONTENT,那么将自身尺寸赋给孩子的尺寸,让子View的尺寸不要大于父容器就行了,将这个尺寸和AT_MOST模式打包并返回。
之后的AT_MOST和UNSPECIFIED测量模式和EXACTLY的套路差不多,就不一一看过去了,《Android开发艺术探索》上总结了一个表格:
columns:childLayoutParams/rows:parentSpecMode | EXACTILY | AT_MOST | UNSPECIFIED |
---|---|---|---|
dp/px | EXACTLY/childSize | EXACTLY/childSize | EXACTLY/childSize |
match_parent | EXACTLY/parentSize | AT_MOST/parentSize | UNSPECIFIED/0 |
wrap_content | AT_MOST/parentSize | AT_MOST/parentSize | UNSPECIFIED/0 |
最后要强调一句和《开发艺术探索》上一样的话,以上的表格并非是经验总结,而是将代码具现为一个表格罢了。
View的measure流程
终于填完了几个比较重要的坑,可以来讲讲View的measure流程了。View的测量是由measure()方法实现的 ,在measure()方法中会去调用onMeasure()方法,看一下View的onMeasure()方法的实现:
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec), getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec)); }
关于这个方法有一些要注意的地方,在以前的Android自定义View你需要知道的一些东西都有说过,而且这个方法的注释里都有写你需要注意的东西,感兴趣的可以去看看,这里就不赘述了。以上方法调用了setMeasuredDimension方法设置View宽高,因此我们看一下他是如何获取宽高的就可以了,不多说,看源码:
public static int getDefaultSize(int size, int measureSpec) { int result = size; int specMode = MeasureSpec.getMode(measureSpec); int specSize = MeasureSpec.getSize(measureSpec); switch (specMode) { case MeasureSpec.UNSPECIFIED: result = size; break; case MeasureSpec.AT_MOST: case MeasureSpec.EXACTLY: result = specSize; break; } return result; }
看得出来,这里只是进行了一些简单的判断和赋值操作,如果测量模式是AT_MOST和EXACTLY:那么就返回View测量后的大小,如果是UNSPECIFIED模式那么就返回传入的size值。接下来看看传入的这个size值是怎么获取的:
protected int getSuggestedMinimumWidth() { return (mBackground == null) ? mMinWidth : max(mMinWidth, mBackground.getMinimumWidth()); }
从以上代码我们可以看出,如果view有背景则从最小宽度和background的宽度中返回较大的那个,如果没有背景则返回最小宽度,这个最小宽度我们可以通过xml或者setMinimumWidth来设置,默认为0。
接下来通过一个问题来回忆一下今天所了解的东西:在View中使用wrap_content为什么效果和match_parent效果一样?
首先这个问题需要去ViewGroup里看看,因为View的MeasureSpec是从ViewGroup中传递而来的,前面我们画的那张表格就是处理代码的具现,我们可以直接查表~
查表可知在match_parent和wrap_content这两种情况下传递给View的size都是parentSize(忽略UNSPECIFIED的情况),那么再看看View有没有对这两种情况做特殊的处理就行了。而在上面的getDefaultSize方法里可以看到AT_MOST和EXACTLY两种模式返回值都是相同的,因此在自定义继承于View的控件时需要我们去重写onMeasure()方法来处理wrap_content的情况。
读到这你可能会发现View和ViewGroup这俩货根本分不开,事实也是如此,但是在这我就不继续记我的笔记了,因为有些事我也没想明白,所以留待以后填坑吧(立了个flag)。
后记
还有一个ViewGroup的measure流程这里并没有继续了,想留着以后再来填这个坑吧。记得原来读《Android开发艺术探索》都是:“哦,原来是这样的” 状态,现在读则是会对一些代码的流程产生疑惑,而这些疑惑以我现在水平还是有些难以解决的。不过学习就是不断完善和不断有新的问题的过程,如同我们初中高中所学的物理一样,很多时候我们学到的只是相对正确的知识,但是在以后不断学习的过程中,我们可以不断的纠正自己以前的错误和带有局限的理解。