画布是无穷大的,即可以绘制任意多的内容或任意大的图形(只要内存足够大) ,然而实际应用中并不会绘制一个无穷大的界面,那么到底应该绘制一个多大的界面呢?对于不同类型的View,其绘制的大小有所不同,一般分为两种情况,一种是内容型视图,另一种是图形型视图 。所谓内容型视图一般是指,该视图将显示一段文本内容,比如TextView,其绘制指的就是显示一段文本内容,内容有多少,就应该绘制多少,所以视图的大小由内容的多少决定。所谓图形型视图一般是指,该视图显示的是一个图形,比如三角形、正方形、背景图等,此时该视图的大小往往会根据父视图为该View 开了一个多大的“ 窗口 ” 而动态调整。 “ 窗口 ” 是指,在父视图看 来 该 View 应该占多大的区域,即 布 局 (layout)大小。换句话说,该视图的大小是“ 被父窗体主宰” 的。layoutxml文件中layout_height和 layout_width属性设置的宽和高不是指视图的大小,而是指父视图给该View设置的“窗
口” 大小,这就是为什么这个属性的名称是以“ layout—” 为前缀,而不是直接使用width和 height的原因。该属性值可以是一个“ 相对值”,比如 WRAP—CONTENT、 MATCH—PARENT等 ,也可以是一个具体值,比 如 lOOdip。View类内部用两个变量measuredWidth和 measuredHeight保存 视 图 的 布 局 (layout)大小值。这两个更应
该被命名为layoutWidth和 layoutHeigh,View内部不是有mLeft、mRigth、mTop、mBottom四个变量吗,它 与 measuredWidth又有什么关系呢?
实际上,这四个变量指的是该View在父视图中所占的区域, mRight-mLeft的大小一般就是measuredWidth的大小, mBottom-mTop就是measuredHeigth的大小。measure过程的本质是把视图布局时使用的“ 相对值” 转换为具体值的过程,即 把 WRAP_COTENT及 MATCH_PARENT转换为具体的值。如果 Framework中不使用相对值,那么也就完全不需要measure过程了。
View系统启动measure过程是从ViewRoot中调用 host.measure()开始
ViewGroup类 是 一 个abstract类 ,应用程序必须实现一个具体的ViewGroup实例。在该实例中,程序员应该调用 measureChildWithMarginO对 下 一 层 的 子 视 图 继 续 进 行 measure()操 作 ,但 这 不 是 必 需 的 , 因 为 measure()的结果仅仅是把layout width和 layout—height所设置的相对值转换为具体值,这些值将在layout过程中辅助父视图对子视图进行布局操作。如 果 某 个ViewGroup实例对子视图的布局不依赖子视图的大小,那么就不需要对所包含的子视图进行measure操作。
View中 measure()函数原型为void measure(int widthMeasureSpec, int heightMeasureSpec)
参数 widthMeasureSpec 和 heightMeaureSpec 分别对应宽和高的 measureSpec., 该参数是父视图传递给子视图的,measureSpec是 一 个int型值,当父视图对子视图进行measure操作时,会调用子视图的measure()函数,该参数的意思是父视图所提供的measure的 “ 规格”,因为父视图最终为子视图提供的“ 窗口”大小是由父视图和子视图共同决定的 。该值由高32位 和 低16位组成,其中高 32位保存的是specMode,低 16位 为 specSize。specMode有三种,分别如下。MeasureSpec.EXACTLY AT_MOST UNSPECIFIED
MeasureSpec.EXACTLY: “ 确定的”,父元素确定子元素的确切大小,子元素将被限定在给定的边界而忽略自身的大小。
? MeasureSpec .AT_MOST: “ 最多”,意思是说,子视图的大小最多是specSize中指定的值。在一般情况下, View 的设计者应该尽可能小地设置视图的大小,并且不能超过specSize,当然,也可以超过specSize。
? MeasureSpec .UNSPECIFIED:未指定,父元素不对元素施加任何束缚,子元素可以得到任意的大小。
视图大小是由父视图和子视图共同决定的. LinearLayout中 的 layout—height扮演了两个角色,一个是 和 LinearLayout的父视图一起对LinearLayout本 身 进 行measure操作;另一个角色是作为 TextView的 measureSpec,并 和 TextView中 的 layout_heigtht —起 对 TextView进 行 measure操作.也就是说onMeasure中的两个参数就是父视图的layout_witdh等大小。
ViewGroup提供了三个类似的函数用于对子视图进行measure()操作。
? measureChildren():如其名称所示, children是 child 的复数,该 函 数 内 部 使 用 for()循环调用measureChild()对每一个子视图进行measure操作。
? measureChild():为指定的子视图进行measure操作。
? measureChildWithMarginsO:该函数与 measureChild 的唯一区别在于, measure 时考虑把 margin及 padding也作为子视图大小的一部分。
static int MeasureSpec.getMode(int measureSpec) : 根据提供的测量值(格式),提取模式(上述三个模式之一)
static int MeasureSpec.getSize(int measureSpec) : 根据提供的测量值(格式),提取大小值(这个大小也就是我们通常所说的大小)
static int makeMeasureSpec(int size,int mode) : 根据提供的大小值和模式,创建一个测量值(格式)
View 中 的 measure()函数是不能被重载的,以保证View系 统 中 measure()的基本流程。ViewGroup的实例一般需要重载0nMeasure()函数,并在该函数中调用 ViewGroup的 measureChild()相关函数对每一个子视图进行measure操作 。 LinearLayout中 的 onMeasure()函数内部,首先判断该LinearLayout是水平的还是垂直的,并分别调用 measureHorizontal()和 measureVertical().
先计算所有子视图的高度: 由于ListView本身的高度仅share剩余部分,所 以 TextView将有足够的空间显示,其 height为 60,所以将首先获得60 高度,此时父窗口 LinearLayout将 剩 余40,再把这40 均匀分配给TextView和 ListView,因为它们的weight值 都 为 2。最终的结果是TextView将获得80高度,而 ListView获 得 20 高度
接下来需要判断父视图中是否还有剩余空间,并将剩余空间均匀分配给weight>0的子视图们.
在 layout()函数中,首先调用 setFrame()函数给当前视图设置参数中指定的位置,然后回调onLayoutO函数。 ViewGroup类中重载了 onLayout()函数,并且将其函数类型设置成了一个abstract类型,因此,所 有 的 ViewGroup实例必须实现onLayout()。View系统希望程序员能够在onLayout()函数中对该视图所包含的子视图进行layout操作,当该视图是ViewGroup时,程序员一般会在onLayout()函数中调用子视图 child的 layoutO方法,从而完成对子视图的位置分配。当然,如果子视图也是一个ViewGroup实例,就又会调用相应的onLayout()函数。
View类 中 layout()函数的:
1. 调用setFrame(1,t,r,b)将位置参数保存起来,这些参数将保存到View内 部 变 量(mLeft、 mTop、mRight、 mBottom)o保存完变量前,会先对比这些参数是否和原来的相同,如果相同,则什么都不做,如果不同才进行重新赋值,并且在赋值前,会 给 mPrivateFlags中添加DRAWN标识,同时调用invalidate^告 诉 View系统原来占用的位置需要重绘。注意是先调用 invalidateO,而后赋值的,因为需要重绘的是老的区域。
2. 回 调 onLayout(), View中定义的onLayout()函数默认什么都不做,View系统提供onLayout()函数的目的是为了使系统包含有子视图的父视图能够在onLayoutO函数对子视图进行位置分配,正因为如此 ,如果是父视图,就必须重载onLayout(),也正因为如此, ViewGroup类 才 把 onLayout()重载修改为了一个 abstract 类型。
onLayout()函 数 中 首 先 根 据 mOrientation变 量 判 断 是 水 平 还 是 垂 直 ,如 果 是 垂 直 则调用layoutVertical()开始进行 layout 操作。
1.获得子视图可用的宽度。读者可能觉得奇怪,这里是进行垂直方向上的布局,为什么却要可用的宽度,而不是可用的髙度呢?因为,就算是垂直方向,子视图本身也货以水平居中,而要居中就得知道的宽度是多少,从而计算出子视图左边沿的位置
2.根据父视图中的gravity属性,决定子视图的起始位置。在默认情况下, gravity是 TOP,应用程序可以设置为BOTTOM或 者 CENTER_VERTICAL
3. 此时已经确定了子视图的垂直方向上的位置,于是就开始for()循环为每一个子视图分配位置
子视图中 gravity的值并不是android:gravity的值,而 是 android:layout__gravity?
在 LayoutInflater类中有一个inflater(resId,root)函数,在大多数情况下,大家调用该函数时,第二个参数root都为空。那么这个参数的意义又是什么?为什么大多数情况下都要为空呢?
该段代码包含了一个LinearLayout,其中又包含两个子视图,分别是一个TextView及 一 个ListView。从 X M L 文件中构造对应的View树 是 在 Layoutlnflater中 的 inflate()函数中完成的,如果该段代码是作为 setContentView()的参数,则会被当作Activity的界面,那么 LinearLayout中定义的layout_width及 height都是有意义的。但如果这段代码仅仅是应用程序调用inflate()函数创建一个View对象,那 么 layout—width及 height就没有任何意义。
inflateO函数会首先判断参数root是否为空,如果为空,就 以 X M L 文件中的根视图构造一个临时的 View对象,此 处 是 LinearLayout对象,此 时 该 LinearLayout中声明的layout_width及 height都没有任何用处。接下来继续读取X M L 文 件 中 TextView,读 取 TextView后,就 需 要 把 该 TextView添加到LinearLayout中。因为要添加,所以必须有一个LayoutParams对象,于是, inflate()函数中就以TextView中定义的layout_width及 height为参数,回 调 TextView父视 图 的 generateLayoutParams()函数
<TextView>标签中包含的android:layout—width、 height等并没有定义 LayoutParams对象,它只是提供了构造LayoutParams参数所需要的值,而真正构造LayoutParams对象的 是它的父视图,这 些 参 数 最 终 会 产 生 什 么 样 的LayoutParams取 决 于 该 TextView的父视图中generateLayoutParams(attrs)的具体实现。
这也就是上一节中所说的为什么要使用layout_gravity而 不 是 gravity的原因,因为在LinearLayout的 generateLayoutParams()函数中,是把 android:layout_gravity 属性值赋值给了 LayoutParams.gravity,而不 是 android:gravity。事实上, android:gravity属 性 将 作 为 TextView内部的参数, TextView在内部的onDraw()函数中将根据android:gravity的值决定把文字显示在什么地方
root参数的意义在于它将提供 generateLayoutParams()函数,该函数产生的LayoutParams对象将作为 X M L 文件中包含的视图被添加 到 root时的布局属性。
如果你在一个XM L 文件中仅仅定义了一个TextView标签,然后调用 inflate(xml, null)从这个XML文 件 中 infalte出一个TextView对象,那 么 该 TextView标签中所包含的android:layout__width、 height将没有任何意义。当 你 想 把 infalte 出 来 的 TextView对 象 添 加 到 某 个ViewGroup时,还必须构造一个LayoutParams 对象
如果该View是 一 个ViewGroup,则需要递归绘制 该 ViewGroup中所包含的所有子视图。
mView对象就是窗口的根视图,对 于 Activity而言,就是 PhoneWindow.DecorView 对象。
在一般情况下,View对象不应该重载dmw()函数,因此,mView.draw()就调用到了 View类 的 draw()函数。该函数的内部过程也就是View系统绘制过程的核心过程,该函数中会依次绘制上一节所讲的四种绘制兀素,其中绘制视图本身的具体实现就是回调onDraw()函数,应用程序一^般 会 重 载 onDraw()函数以绘制所设计的View的真正界面内容。绘制完界面内容后,如果该视图内部还包含子视图,贝U调 用 dispatchDraw()函数, ViewGroup重载了该函数。因此,实际调用的是ViewGroup中 的 dispatchDraw()函数,应用程序不应该再重载ViewGroup类 中 的 dispatchDmwO函数,因为该函数内部已经有了默认的实现,并且该实现代表了 View 系统的内.
1. 绘制背景.首先根据滚动值对canvas的坐标进行调整,然后再恢复坐标.为什么需要先调用tmnslateO平 移 Canvas的坐标呢?因为对每一个视图而言, Canvas的 坐 标 原 点 (0 , 0 ) 对应的都是该视图的内部区域,如 图 13-35所示。
2. 显示视图的渐变框,daoying, setVerticalFadingEdgeO, setHorizontalFadingEdgeO
3. 绘制视图本身. 实 际 上 回 调 onDmw()函数即可, View 的设计者可以在onDraw()函数中调用canvas的各种绘制函数进行绘制。
4. 调 用 dispatchDmwO绘制子视图。如果该视图内部不包含子视图,则不需要重载该函数,而对所有 的 ViewGroup实例而言,都必须重载该函数,否则它也就不是vfewGroup 了。
5. 回 调 onDrawScrollbars()绘制滚动条
根据动画的参数对当前View做一定的图形变换,比如缩放、平移等,然后将变换后的图像绘制到屏幕上。绘制完后,再发起一个重绘的消息,就这样连续绘制,直到动画参数指示动画结束。
从效果的角度看, View系统中包含的动画可以分为三类,分别是窗口动画、视图动画、布局动画.
对 于 View系统而言,所能提供的动画更是有限, Android中 View系统仅支持基本的五种动画,分别为平移、缩放、旋转、扭曲及颜色阿尔法通道变化,这 称 之 为 “ 动画参数” 或 “ 动画类型”. 动画使用一个Animation类来表示,当 View要开始动画时,从 Animation类中获取动画的参数,并根据这些参数对View进行图形变换, 然后将变换后的图形绘制到屏幕上。
视图动画是在ViewGroup类 中 drawChild()函数中完成的。 drawChild()函数首先会判断该视图是否包 含 Animation对象,如果包含,则 利用 Animation中的动画参数对该视图进行变换,然后把变换后的图像绘制到canvas中。应用程序可以使用 res/anim/xxx.xml文件描述一个动画,对于视图动画而言,一般使用如下的xml标签描述一个动画。
<Set><scale/><alpha/>
<l a y o u t A n i m a t i o n>
原文:http://blog.csdn.net/andywuchuanlong/article/details/43938555