摘要 ： 初学者一枚，每一次写的时候，都是从网上直接 复制+粘贴。。完全不为什么要这样写，为什么通过这样就可以实现，也想着要去看懂。可是看一下就不知道怎么下手。完全是一个球形，无法下手。有一些通过各种搜索后，能够知道了表皮意思，可以接下来自己动手的时。就又忘记了怎么下手。希望各位大大介绍一下大致的方向，再此感激不尽。后面考虑一下还是直接做笔记吧！每一去搜索慢慢的收藏也多了。完全找不到自己所需要的在哪里去了，又得重新搜索…
文摘摘抄至：株洲新城 IT教育 李赞红老师。非常感谢老师。想过摘抄一边的方式去让自己记住一些知识点。如果不适合，我会立刻删除
第一章 View的绘图流程
1.1、概述
Android中组件必须是View直接子类或间接子类，其中View有一个名为ViewGroup的子类。用于定义容器组件类（FrameLayout、LinearLayout都是是ViewGroup的子类）。二者的职责定义非常清晰，如果组件中还有子组件。就一定是从ViewGroup类继承，否则从View类继承。 View 类定义了组件相关的通用功能，并打通了组件在Activity整个活动周期中的绘制流程和效果等任督二脉。通过 OOP构建出基本的运行框架。1.2、Activity 的组成结构
Activity 代表一个窗口，事实上，这里的“窗口”是由 Activity的成员变量 mWindow来表示的，mWindow本质上是一个PhoneWindow 对象。PhoneWindow继承至 Window抽象类。负责窗口的管理。但是，PhoneWindow 并不是用来呈现界面效果，呈现界面是由 PhoneWindow 管理的 DecorView对象来完成的。DecorView 类是 FrameLayout的子类，也是整个 View树的“根”。DecorView由三部分构成： ActionBar、标题区和内容区。在 源码 platforms/android-21/data/res/layout 的目录下有一个名为 screen_title.xml 的布局文件，该布局文件是常见的窗口风格定义文件，打开后可以看到如下定义：<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:fitsSystemWindows="true">
<!-- Popout bar for action modes -->
<ViewStub android:id="@+id/action_mode_bar_stub"
android:inflatedId="@+id/action_mode_bar"
android:layout="@layout/action_mode_bar"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:theme="?attr/actionBarTheme" />
<FrameLayout
android:layout_width="match_parent"
android:layout_height="?android:attr/windowTitleSize"
style="?android:attr/windowTitleBackgroundStyle">
<TextView android:id="@android:id/title"
style="?android:attr/windowTitleStyle"
android:background="@null"
android:fadingEdge="horizontal"
android:gravity="center_vertical"
android:layout_width="match_parent"
android:layout_height="match_parent" />
</FrameLayout>
<FrameLayout android:id="@android:id/content"
android:layout_width="match_parent"
android:layout_height="0dip"
android:layout_weight="1"
android:foregroundGravity="fill_horizontal|top"
android:foreground="?android:attr/windowContentOverlay" />
</LinearLayout>下图所示描述上面各组件之间的关系：
从上图可以看出：
- Activity 类似于一个框架，负责容器的生命周期及活动，窗口通过 Window 来管理
- Window 负责窗口管理（实际是子类 PhoneWindow），窗口的绘制和渲染交给 DecorView完成
- DecorView 是 View的数的根，我们为 Activity定义的 layout 将转成 DecorView的子类视图 ContentParent 的子视图
- layout.xml是我们定义的布局文件，最终 inflate为 DecorView的子组件
需要说明的是，PhoneWindow 类还关联一个 名为 mWindowManager 的 windowmanager对象，windowmanager 会创建一个 ViewRootImpl 对象来和 WindowManagerService 进行沟通，windowmanagerservice 能获取触摸事件、键盘事件和轨迹球事件，并通过 ViewRootImpl 将事件分发给各个 Activity。另外，ViewRootImpl 还负责Activity 整个 GUI的绘制。
下图所示是 Activity涉及到各个组件的关系图（来源于网络）
1.3、View 树的绘制流程
上文提到，ViewRootImpl负责 Activity整个 GUI的绘制，而绘制是从 ViewRootImpl的 performTraversals(）方法开始。该方法是由 private 修饰，控制着 View树的绘制流程，禁止被重写。通过查看 ViewRootImpl类，在performTraversals(）中，提取出三行关键代码
private void performTraversals(){
......
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
......
performLayout(lp, desiredWindowWidth, desiredWindowHeight);
......
performDraw();
......
}- performMeasure(）方法测量组件的大小
- performLayout(）方法用于子组件的定位（放在窗口的什么位置）
- performDraw(）方法就是将组件的外观绘制出来
1.3.1 测量组件大小
performMeasure() 方法负责组件的自身尺寸的测量，在layout 布局文件中，每一个组件都必须设置 layout_width 和 layout_height属性，属性值有三种可选模式：wrap_content、match_parent 和 数值。preformMeasure() 方法根矩设置的模式计算出组件的宽度和高度。事实上，大多数情况下模式为 match_parent 和 数值的时候不需要计算的，传过来的就是父容器自己计算好的尺寸或是一个指定的精确值，只有当模式是 wrap_content 的时候，才需要根矩内容进行尺寸的测量。prefromMeasure()方法的源码摘录如下：
private void performMeasure(int childWidthMeasureSpec, int childHeightMeasureSpec) {
Trace.traceBegin(Trace.TRACE_TAG_VIEW, "measure");
try {
mView.measure(childWidthMeasureSpec, childHeightMeasureSpec);
} finally {
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
}对象 mView是 View树的根视图，代码中调用了 mView的 measure()方法，我们进入该方法的源代码如下：
public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
......
onMeasure(widthMeasureSpec, heightMeasureSpec);
......
}忽略了其与代码，只剩下了 onMeasure()这一行，onMeasure()方法是为组件尺寸的测量留的功能接口。当然，也定义了默认的实现，默认的实现并没有太多的意义，在绝大部分情况下，onMEasure()方法必须重写。
如果测量的是容器的尺寸，而容器的尺寸有依赖于子组件的大小，所以必须先测量容器中子类组件的大小。不然，测量出来的宽度和高度永远为 0.编程的时候往往容易忽略。
Android 中使用的单词 measure来计算组件的大小，背后其实颇有讲究。measure是“测量、评定”之意。说明其结果只能起参考作用，并不是一定非使用该值不可。组件真正的大小最终是由setFrame()方法决定的，该方法一般情况下回参考 measure出来的尺寸。
1.3.2 确定子组件的位置
preformLayout()方法用于确定子组件的位置。所以，该方法只针对 ViewGroup容器类。作为容器，必须为容器中的子类 View精确定义位置和大小。该方法源码如下：private void performLayout(WindowManager.LayoutParams lp,
int desiredWindowWidth, int desiredWindowHeight){
......
host.layout(0, 0, host.getMeasuredWidth(), host.getMeasuredHeight());
......
for (int i = 0; i < numValidRequests; ++i) {
final View view = validLayoutRequesters.get(i);
view.requestLayout();
}
}代码中的 host是 View树中根视图（DecorView），也就是最外层容器，容器的位置安排在左上角（0，0），其大小默认会填满 mContentParent容器。我们重点来看一下 layout()方法源码：
public void layout(int l, int t, int r, int b) {
if ((mPrivateFlags3 & PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT) != 0) {
onMeasure(mOldWidthMeasureSpec, mOldHeightMeasureSpec);
mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
}
int oldL = mLeft;
int oldT = mTop;
int oldB = mBottom;
int oldR = mRight;
boolean changed = isLayoutModeOptical(mParent) ?
setOpticalFrame(l, t, r, b) : setFrame(l, t, r, b);
onLayout(changed, l, t, r, b);
......
}
......
}在layout()方法中，在定位之前如果需要重新测量组件的大小，则先调用 onMeasure()方法，接下来执行 setOpticalFrame(）或 setFrame(）方法确定自身的位置与大小，此时只是保存了相关的值，与具体的绘制无关。随后，onLayout()方法被调用，该方法是空方法，如下：
protected void onLayout(boolean changed, int left, int top, int right, int bottom) {
}onLayout()方法在这里的作用是当前组件为容器时，负责定位容器中的子组件。这其实是一个递归的过程，如果子组件也是一个容器，该容器依然负责它的子组件的定位。依此类推，直到所有的组件都定位完成为止。也就是说：“从顶层的DecorView开始定位，像多米罗骨牌一样从上往下驱动，最后每一个组件都放到它对应该出现的位置上。”onLayout()方法和上节的 onMeasure()方法一样，是为开发人员预留的功能扩展接口，自定义容器时，该方法必须重写。
1.3.3 绘制组件
preformDraw()方法执行执行组件的绘制功能，组件的绘制是一个十分复杂的过程。不仅仅绘制组件本身，还要绘制背景、滚动条，好消息是每一个组件只需要负责自身的绘制。而且一般来说，容器组件不需要绘制，ViewGroup已经做了大量的工作。通过源码整理出的绘图流程如下： private void performDraw() {
......
final boolean fullRedrawNeeded = mFullRedrawNeeded;
mFullRedrawNeeded = false;
mIsDrawing = true;
.......
try {
draw(fullRedrawNeeded);
} finally {
mIsDrawing = false;
......
}
......
}在performDraw(）方法中调用 draw()方法
private void draw(boolean fullRedrawNeeded) {
......
if (!drawSoftware(surface, mAttachInfo, xOffset, yOffset, scalingRequired, dirty)) {
return;
}
......
}draw()方法又调用了 drawSoftware()方法
private boolean drawSoftware(Surface surface, AttachInfo attachInfo, int xoff, int yoff,
boolean scalingRequired, Rect dirty) {
final Canvas canvas;
try {
final int left = dirty.left;
final int top = dirty.top;
final int right = dirty.right;
final int bottom = dirty.bottom;
canvas = mSurface.lockCanvas(dirty);
........
if (!canvas.isOpaque() || yoff != 0 || xoff != 0) {
canvas.drawColor(0, PorterDuff.Mode.CLEAR);
}
......
mView.draw(canvas);
......
surface.unlockCanvasAndPost(canvas);
......
}如果说前面的代码倍感陌生，那么从 drawSoftware()开始，代码似乎越来越平易近人越来越接地气了。绘制组件是通过 Canvas类完成的，该类定义了若干个绘制图像的方案。通过 Paint类配置绘制参数，便能绘制出各种图案效果。为了提高绘图的性能，使用了 Surface技术，sureface提供了一套双缓存机制，能大大的加快绘图效率。而我们绘图是需要的 Canvas对象也由是 Surface创建的。
drawSoftware()方法中调用了 mView的 draw()方法。前面说过，mView是 ACtivity界面中 View树的根（DecorView），也是一个容器（具体来说就是一个FrameLayout布局容器）。所以，我们来看看 FrameLayout类的 draw()方法源码：
public void draw(Canvas canvas) {
super.draw(canvas);
......
final Drawable foreground = mForeground;
......
foreground.draw(canvas);
}FrameLayout类的 draw()方法做了两件事情，一是调用谷类的 draw()方法绘制自己；二是将前景位图画在 Canvas上，自然，super.draw(canvas)语句是我们关注重点，FrameLayout继承自 ViewGroup，遗憾的是 ViewGroup并没有重写 draw()方法，也就是说，ViewGroup的绘制完全重用了它的父类 View的 draw()方法。不过，ViewGroup中定义了一个名为 dispatchDraw()的方法。该方法在 View中定义，在 ViewGroup中实现。至于有什么用？ 暂且不说，我们先扒开 View的 drwa()方法源码看看：
public void draw(Canvas canvas) {
......
drawBackground(Canvas canvas)
......
if (!dirtyOpaque) onDraw(canvas);
......
dispatchDraw(canvas);
onDrawScrollBars(canvas);
......
}View 类的 draw()方法是组件绘制的核心方法，主要做了下面几件事情：
- 绘制背景：background.draw(canvas)
- 绘制自己 ：onDraw(canvas)
- 绘制子视图 ：dispatchDraw(canvas);
- 绘制滚动条 ：onDrawScrollBars(canvas);
backgroud是一个 Drawable对象，直接绘制在 Canvas上，并且与组件要绘制的内容互补干扰。跟多时候，这个特征能被某些场景利用。比如后面的“刮刮乐”就是一个很好的范例。
View 只是组件的抽象定义，它自己并不知道自己长神马样子。所以，View定义了一个空 onDraw()，如下 :
/**
* Implement this to do your drawing.
*
* @param canvas the canvas on which the background will be drawn
*/
protected void onDraw(Canvas canvas) {
}和前面的 onMeasure() 与 onLayout()一样，onDraw()方法同样是预留给子类扩展的功能接口。用于绘制组件自身，组件的外观有该方法来决定。
dispatchDraw()方法也是一个空方法，如下：
/**
* Called by draw to draw the child views. This may be overridden
* by derived classes to gain control just before its children are drawn
* (but after its own view has been drawn).
* @param canvas the canvas on which to draw the view
*/
protected void dispatchDraw(Canvas canvas) {
}该方法服务容器组件，容器中的子组件必须通过 dispatchDraw()方法进行绘制。所以，View虽然没有实现该方法但是它的子类 ViewGroup实现了该方法。
protected void dispatchDraw(Canvas canvas) {
......
final int count = mChildrenCount;
final View[] children = mChildren;
for (int i = 0; i < count; i++) {
final View child = children[i];
if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE
|| child.getAnimation() != null) {
more |= drawChild(canvas, child, drawingTime);
}
}
......
}在 dispatchDraw()方法中，循环遍历每一个子组件，并用 drawChild()方法绘制子组件。而子组件有调用 View的 draw()方法绘制自己。
protected boolean drawChild(Canvas canvas, View child, long drawingTime) {
return child.draw(canvas, this, drawingTime);
}组件的绘制委员会寺一个递归的过程，说到底 Activity的 UI界面的根一定是容器，根容器绘制结束后开始绘制子组件。子组件如果是容器继续往下递归绘制，直到说有的组件正确绘制为止。否则直接将子组件绘制出来。
总体来说，UI界面的绘制从开始到结束要经历的几个过程：
- 测量组件大小，回调 onMeasure()方法
- 组件定位，回调 onLayout()方法
- 组件绘制，回调 onDraw()方法
扫一扫
1198
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
