androidview绘制完成

❶ android怎么绘制view的一部分

越少越好 为了加速视图，从那些调用频繁的活动中减少不必要的代码。在OnDraw()方法中开始绘制，它会给你最大的 效益。特别低，你也应该减少在onDraw()方法中的内存分配，因为任何内存分配都可能导致内存回收，这将会 引起不连贯。 在初始化或者...

❷ android 怎么知道自定义view图画完了

为什么我们觉得自定义View是学习Android的一道坎？
为什么那么多Android大神却认为自定义View又是如此的简单？
为什么google随便定义一个View都是上千行的代码？
以上这些问题，相信学Android的同学或多或少都有过这样的疑问。
那么，看完此文，希望对你们的疑惑有所帮助。

回到主题，自定义View ，需要掌握的几个点是什么呢？
我们先把自定义View细分一下，分为两种
1） 自定义ViewGroup
2） 自定义View

其实ViewGroup最终还是继承之View，当然它内部做了许多操作；继承之ViewGroup的View我们一般称之为容器，而今天我们不讲这方面，后续有机会再讲。
来看看自定义View 需要掌握的几点，主要就是两点

一、重写 protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {}方法。
二、重写 protected void onDraw(Canvas canvas) {}方法

空讲理论很难理解，我们还得用例子来说明，记得我前面来写了一篇 Android 微信6.1 tab栏图标和字体颜色渐变的实现 的博客，里面tab的每个item就是通过自定义View来实现的，那么接下来就通过此例子来说明问题。

我们可以把View理解为一张白纸，而自定义View就是在这张白纸上画上我们自己绘制的图案，可以在绘制任何图案，也可以在白纸的任何位置绘制，那么问题来了，白纸哪里来？图案哪里来？位置如何计算？

a）白纸好说，只要我们继承之View，在onDraw(Canvas canvas)中的canvas就是我们所说的白纸
/**
* Created by moon.zhong on 2015/2/13.
*/
public class CustomView extends View {
public CustomView(Context context) {
super(context);
}

public CustomView(Context context, AttributeSet attrs) {
super(context, attrs);
}

public CustomView(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
}

@Override
protected void onDraw(Canvas canvas) {
// canvas 即为白纸
super.onDraw(canvas);
}
}

b）图案呢？这里的图案就是有图片和文字组成，这个也好说，定义一个Bitmap 成员变量，和一个String的成员变量
private Bitmap mBitmap ;
private String mName ;
mName = "这里直接赋值";
mBitmap = BitmapFactory.decodeResource(getResources(),R.drawable.ic_launcher) ;1234

图片可以通过资源文件可以拿到。

c）计算位置
所以最核心的也是我们认为最麻烦的地方就是计算绘制的位置，计算位置就得先测量自身的大小，也就是我们必须掌握的两点中的第一点：需要重写
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec)
{}方法
先来看一下google写的TextView的onMeasure（）方法是如何实现的
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
int widthMode = MeasureSpec.getMode(widthMeasureSpec);
int heightMode = MeasureSpec.getMode(heightMeasureSpec);
int widthSize = MeasureSpec.getSize(widthMeasureSpec);
int heightSize = MeasureSpec.getSize(heightMeasureSpec);

int width;
int height;

BoringLayout.Metrics boring = UNKNOWN_BORING;
BoringLayout.Metrics hintBoring = UNKNOWN_BORING;

if (mTextDir == null) {
mTextDir = getTextDirectionHeuristic();
}

int des = -1;
boolean fromexisting = false;

if (widthMode == MeasureSpec.EXACTLY) {
// Parent has told us how big to be. So be it.
width = widthSize;
} else {
if (mLayout != null && mEllipsize == null) {
des = desired(mLayout);
}

if (des < 0) {
boring = BoringLayout.isBoring(mTransformed, mTextPaint, mTextDir, mBoring);
if (boring != null) {
mBoring = boring;
}
} else {
fromexisting = true;
}

if (boring == null || boring == UNKNOWN_BORING) {
if (des < 0) {
des = (int) FloatMath.ceil(Layout.getDesiredWidth(mTransformed, mTextPaint));
}
width = des;
} else {
width = boring.width;
}

final Drawables dr = mDrawables;
if (dr != null) {
width = Math.max(width, dr.mDrawableWidthTop);
width = Math.max(width, dr.mDrawableWidthBottom);
}

if (mHint != null) {
int hintDes = -1;
int hintWidth;

if (mHintLayout != null && mEllipsize == null) {
hintDes = desired(mHintLayout);
}

if (hintDes < 0) {
hintBoring = BoringLayout.isBoring(mHint, mTextPaint, mTextDir, mHintBoring);
if (hintBoring != null) {
mHintBoring = hintBoring;
}
}

if (hintBoring == null || hintBoring == UNKNOWN_BORING) {
if (hintDes < 0) {
hintDes = (int) FloatMath.ceil(Layout.getDesiredWidth(mHint, mTextPaint));
}
hintWidth = hintDes;
} else {
hintWidth = hintBoring.width;
}

if (hintWidth > width) {
width = hintWidth;
}
}

width += getCompoundPaddingLeft() + getCompoundPaddingRight();

if (mMaxWidthMode == EMS) {
width = Math.min(width, mMaxWidth * getLineHeight());
} else {
width = Math.min(width, mMaxWidth);
}

if (mMinWidthMode == EMS) {
width = Math.max(width, mMinWidth * getLineHeight());
} else {
width = Math.max(width, mMinWidth);
}

// Check against our minimum width
width = Math.max(width, getSuggestedMinimumWidth());

if (widthMode == MeasureSpec.AT_MOST) {
width = Math.min(widthSize, width);
}
}

int want = width - getCompoundPaddingLeft() - getCompoundPaddingRight();
int unpaddedWidth = want;

if (mHorizontallyScrolling) want = VERY_WIDE;

int hintWant = want;
int hintWidth = (mHintLayout == null) ? hintWant : mHintLayout.getWidth();

if (mLayout == null) {
makeNewLayout(want, hintWant, boring, hintBoring,
width - getCompoundPaddingLeft() - getCompoundPaddingRight(), false);
} else {
final boolean layoutChanged = (mLayout.getWidth() != want) ||
(hintWidth != hintWant) ||
(mLayout.getEllipsizedWidth() !=
width - getCompoundPaddingLeft() - getCompoundPaddingRight());

final boolean widthChanged = (mHint == null) &&
(mEllipsize == null) &&
(want > mLayout.getWidth()) &&
(mLayout instanceof BoringLayout || (fromexisting && des >= 0 && des <= want));

final boolean maximumChanged = (mMaxMode != mOldMaxMode) || (mMaximum != mOldMaximum);

if (layoutChanged || maximumChanged) {
if (!maximumChanged && widthChanged) {
mLayout.increaseWidthTo(want);
} else {
makeNewLayout(want, hintWant, boring, hintBoring,
width - getCompoundPaddingLeft() - getCompoundPaddingRight(), false);
}
} else {
// Nothing has changed
}
}

if (heightMode == MeasureSpec.EXACTLY) {
// Parent has told us how big to be. So be it.
height = heightSize;
mDesiredHeightAtMeasure = -1;
} else {
int desired = getDesiredHeight();

height = desired;
mDesiredHeightAtMeasure = desired;

if (heightMode == MeasureSpec.AT_MOST) {
height = Math.min(desired, heightSize);
}
}

int unpaddedHeight = height - getCompoundPaddingTop() - getCompoundPaddingBottom();
if (mMaxMode == LINES && mLayout.getLineCount() > mMaximum) {
unpaddedHeight = Math.min(unpaddedHeight, mLayout.getLineTop(mMaximum));
}

/*
* We didn't let makeNewLayout() register to bring the cursor into view,
* so do it here if there is any possibility that it is needed.
*/
if (mMovement != null ||
mLayout.getWidth() > unpaddedWidth ||
mLayout.getHeight() > unpaddedHeight) {
registerForPreDraw();
} else {
scrollTo(0, 0);
}

setMeasuredDimension(width, height);
}

哇！好长！而且方法中还嵌套方法，如果真要算下来，代码量不会低于500行，看到这么多代码，头都大了，我想这也是我们为什么在学习Android自定义View的时候觉得如此困难的原因。大多数情况下，因为我们是自定义的View，可以说是根据我们的需求定制的View，所以很多里面的功能我们完全没必要，只需要几十行代码就能搞定。看到几十行代码就能搞定，感觉顿时信心倍增(^.^)
在重写这个方法之前，得先了解一个类 MeasureSpec ，如果不了解，没关系，下面就一起来了解一下这个类。先把代码贴出来，膜拜一下
1234
public static class MeasureSpec {
private static final int MODE_SHIFT = 30;
private static final int MODE_MASK = 0x3 << MODE_SHIFT;
public static final int UNSPECIFIED = 0 << MODE_SHIFT;
public static final int EXACTLY = 1 << MODE_SHIFT;
public static final int AT_MOST = 2 << MODE_SHIFT;
public static int makeMeasureSpec(int size, int mode) {
if (sUseBrokenMakeMeasureSpec) {
return size + mode;
} else {
return (size & ~MODE_MASK) | (mode & MODE_MASK);
}
}
public static int getMode(int measureSpec) {
return (measureSpec & MODE_MASK);
}
public static int getSize(int measureSpec) {
return (measureSpec & ~MODE_MASK);
}
}

这里我把里面一些我认为没必要的代码都去掉了，只留了以上几行代码，这样看起来很清晰，也非常容易理解。
我们先做个转化，把上面几个成员变量转化成二进制

这个就不需要转化了，这里代表的只是一个移动的位置，也就是一个单纯的数字
private static final int MODE_SHIFT = 30;
0x3 就是 11 左移30位 ，就是补30个0；
private static final int MODE_MASK = 1100 0000 0000 0000 0000 0000 0000 0000 ;
00 左移30位
public static final int UNSPECIFIED = 0000 0000 0000 0000 0000 0000 0000 0000 ;
01 左移30位
public static final int EXACTLY = 0100 0000 0000 0000 0000 0000 0000 0000 ;
10 左移30位
public static final int AT_MOST = 1000 0000 0000 0000 0000 0000 0000 0000 ;

你就会问了，这样写有什么好处呢？ 细心的人看了上面这几个方法就明白了，每个方法中都有一个 & 的操作，所以我们接下来看看这集几个方法的含义是什么，先从下往上看，先易后难
1、 public static int getSize(int measureSpec) {
return (measureSpec & ~MODE_MASK);
}
顾名思义，通过measureSpec这个参数，获取size ，两个都是int类型，怎么通过一个int类型的数获取另一个int类型的数。我们在学习java的时候知道，一个int类型是32位，任何int类型的数都是有32位，比如一个int类型的数值3，它也是占有32位，只是高30位全部为0。google 也是利用这一点，让这个int类型的measureSpec数存了两个信息，一个就是size，保存在int类型的低30位，另一个就是mode，保存在int类型的高2位。前面我们看到了有几个成员变量，UNSPECIFIED，EXACTLY，AT_MOST
者就是mode的三种选择，目前也只有这三种选择，所以只需要2位就能实现。
2、 ` public static int getMode(int measureSpec) {
return (measureSpec & MODE_MASK);
}`
这也好理解，获取模式，但这些模式有啥用处呢？
1）、EXACTLY 模式： 准确的、精确的；这种模式，是最容易理解和处理的，可以理解为大小固定，比如在定义layout_width的时候，定义为固定大小 10dp，20dp，或者match_parent(此时父控件是固定的)这时候，获取出来的mode就是EXACTLY
2）、AT_MOST 模式： 最大的；这种模式稍微难处理些，不过也好理解，就是View的大小最大不能超过父控件，超过了，取父控件的大小，没有，则取自身大小，这种情况一般都是在layout_width设为warp_content时。
3）、UNSPECIFIED 模式：不指定大小，这种情况，我们几乎用不上，它是什么意思呢，就是View的大小想要多大，就给多大，不受父View的限制，几个例子就好理解了，ScrollView控件就是。

❸ Android UI绘制之View绘制的工作原理

这是AndroidUI绘制流程分析的第二篇文章，主要分析界面中View是如何绘制到界面上的具体过程。

ViewRoot 对应于 ViewRootImpl 类，它是连接 WindowManager 和 DecorView 的纽带，View的三大流程均是通过 ViewRoot 来完成的。在 ActivityThread 中，当 Activity 对象被创建完毕后，会将 DecorView 添加到 Window 中,同时会创建 ViewRootImpl 对象，并将 ViewRootImpl 对象和 DecorView 建立关联。

measure 过程决定了 View 的宽/高， Measure 完成以后，可以通过 getMeasuredWidth 和 getMeasuredHeight 方法来获取 View 测量后的宽/高，在几乎所有的情况下，它等同于View的最终的宽/高，但是特殊情况除外。 Layout 过程决定了 View 的四个顶点的坐标和实际的宽/高，完成以后，可以通过 getTop、getBottom、getLeft 和 getRight 来拿到View的四个顶点的位置，可以通过 getWidth 和 getHeight 方法拿到View的最终宽/高。 Draw 过程决定了 View 的显示，只有 draw 方法完成后 View 的内容才能呈现在屏幕上。

DecorView 作为顶级 View ，一般情况下，它内部会包含一个竖直方向的 LinearLayout ，在这个 LinearLayout 里面有上下两个部分，上面是标题栏，下面是内容栏。在Activity中，我们通过 setContentView 所设置的布局文件其实就是被加到内容栏中的，而内容栏id为 content 。可以通过下面方法得到 content:ViewGroup content = findViewById(R.android.id.content) 。通过 content.getChildAt(0) 可以得到设置的 view 。 DecorView 其实是一个 FrameLayout , View 层的事件都先经过 DecorView ，然后才传递给我们的 View 。

MeasureSpec 代表一个32位的int值，高2位代表 SpecMode ,低30位代表 SpecSize , SpecMode 是指测量模式，而 SpecSize 是指在某种测量模式下的规格大小。
SpecMode 有三类，如下所示：

UNSPECIFIED

EXACTLY

AT_MOST

LayoutParams需要和父容器一起才能决定View的MeasureSpec，从而进一步决定View的宽/高。

对于顶级View，即DecorView和普通View来说，MeasureSpec的转换过程略有不同。对于DecorView，其MeasureSpec由窗口的尺寸和其自身的LayoutParams共同确定；

对于普通View，其MeasureSpec由父容器的MeasureSpec和自身的Layoutparams共同决定；

MeasureSpec一旦确定，onMeasure就可以确定View的测量宽/高。

小结一下

当子 View 的宽高采用 wrap_content 时，不管父容器的模式是精确模式还是最大模式，子 View 的模式总是最大模式+父容器的剩余空间。

View 的工作流程主要是指 measure 、 layout 、 draw 三大流程，即测量、布局、绘制。其中 measure 确定 View 的测量宽/高， layout 确定 view 的最终宽/高和四个顶点的位置，而 draw 则将 View 绘制在屏幕上。

measure 过程要分情况，如果只是一个原始的 view ，则通过 measure 方法就完成了其测量过程，如果是一个 ViewGroup ，除了完成自己的测量过程外，还会遍历调用所有子元素的 measure 方法，各个子元素再递归去执行这个流程。

如果是一个原始的 View，那么通过 measure 方法就完成了测量过程，在 measure 方法中会去调用 View 的 onMeasure 方法，View 类里面定义了 onMeasure 方法的默认实现:

先看一下 getSuggestedMinimumWidth 和 getSuggestedMinimumHeight 方法的源码：

可以看到， getMinimumWidth 方法获取的是 Drawable 的原始宽度。如果存在原始宽度（即满足 intrinsicWidth > 0），那么直接返回原始宽度即可；如果不存在原始宽度（即不满足 intrinsicWidth > 0），那么就返回 0。

接着看最重要的 getDefaultSize 方法：

如果 specMode 为 MeasureSpec.UNSPECIFIED 即未指定模式，那么返回由方法参数传递过来的尺寸作为 View 的测量宽度和高度；
如果 specMode 不是 MeasureSpec.UNSPECIFIED 即是最大模式或者精确模式，那么返回从 measureSpec 中取出的 specSize 作为 View 测量后的宽度和高度。

看一下刚才的表格：

当 specMode 为 EXACTLY 或者 AT_MOST 时，View 的布局参数为 wrap_content 或者 match_parent 时，给 View 的 specSize 都是 parentSize 。这会比建议的最小宽高要大。这是不符合我们的预期的。因为我们给 View 设置 wrap_content 是希望View的大小刚好可以包裹它的内容。

因此：

如果是一个 ViewGroup，除了完成自己的 measure 过程以外，还会遍历去调用所有子元素的 measure 方法，各个子元素再递归去执行 measure 过程。

ViewGroup 并没有重写 View 的 onMeasure 方法，但是它提供了 measureChildren、measureChild、measureChildWithMargins 这几个方法专门用于测量子元素。

如果是 View 的话，那么在它的 layout 方法中就确定了自身的位置（具体来说是通过 setFrame 方法来设定 View 的四个顶点的位置，即初始化 mLeft ， mRight ， mTop ， mBottom 这四个值）， layout 过程就结束了。

如果是 ViewGroup 的话，那么在它的 layout 方法中只是确定了 ViewGroup 自身的位置，要确定子元素的位置，就需要重写 onLayout 方法；在 onLayout 方法中，会调用子元素的 layout 方法，子元素在它的 layout 方法中确定自己的位置，这样一层一层地传递下去完成整个 View 树的 layout 过程。

layout 方法的作用是确定 View 本身的位置，即设定 View 的四个顶点的位置，这样就确定了 View 在父容器中的位置；
onLayout 方法的作用是父容器确定子元素的位置，这个方法在 View 中是空实现，因为 View 没有子元素了，在 ViewGroup 中则进行抽象化，它的子类必须实现这个方法。

1.绘制背景（ background.draw(canvas); ）；
2.绘制自己（ onDraw ）；
3.绘制 children（ dispatchDraw(canvas) ）；
4.绘制装饰（ onDrawScrollBars ）。

dispatchDraw 方法的调用是在 onDraw 方法之后，也就是说，总是先绘制自己再绘制子 View 。

对于 View 类来说， dispatchDraw 方法是空实现的，对于 ViewGroup 类来说， dispatchDraw 方法是有具体实现的。

通过 dispatchDraw 来传递的。 dispatchDraw 会遍历调用子元素的 draw 方法，如此 draw 事件就一层一层传递了下去。dispatchDraw 在 View 类中是空实现的，在 ViewGroup 类中是真正实现的。

如果一个 View 不需要绘制任何内容，那么就设置这个标记为 true，系统会进行进一步的优化。

当创建的自定义控件继承于 ViewGroup 并且不具备绘制功能时，就可以开启这个标记，便于系统进行后续的优化；当明确知道一个 ViewGroup 需要通过 onDraw 绘制内容时，需要关闭这个标记。

参考：《Android开发艺术探索》

❹ Android View双缓冲机制

绘制图像时不用上述中逐个绘制的方案，先在内存中将所有的图像都绘制到一个Bitmap对象上，然后一次性将内存中的Bitmap绘制到屏幕，从而提高绘制的效率。View的onDraw()方法已经实现了这一层缓冲。

onDraw()方法的Canvas对象是和屏幕关联的，而onDraw()方法是运行在UI线程中的，如果要绘制的图像过于复杂，则有可能导致应用程序卡顿，甚至ANR。

因此我们可以先创建一个临时的Canvas对象，将图像都绘制到这个临时的Canvas对象中，绘制完成之后再将这个临时Canvas对象中的内容(也就是一个Bitmap)，通过drawBitmap()方法绘制到onDraw()方法中的canvas对象中。这样的话就相当于是一个Bitmap的拷贝过程，比直接绘制效率要高，可以减少对UI线程的阻塞。

创建临时bitmap，进行相关绘制：

❺ Android 如何判断一个View重绘或加载完成

1、view重绘时回调（即监听函数，当view重绘完成自动动用，需要向view的观察者添加监听器）。格式：

view.getViewTreeObserver().addOnDrawListener(new OnDrawListener() {

@Override

public void onDraw() {

// TODO Auto-generated method stub

}

});

2、view加载完成时回调（当view加载完成自动动用，需要向view的观察者添加监听器）。格式：

view.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {

@Override

public void onGlobalLayout() {

// TODO Auto-generated method stub

}

});

(5)androidview绘制完成扩展阅读：

两种方式刷新：

1、主线程可以直接调用Invalidate()方法刷新

2、子线程可以直接调用postInvalidate()方法刷新。

API的描述 : Invalidatethe whole view. If the view is visible, onDraw(Canvas) will be called at somepoint in the future. This must be called from a UI thread. To call from anon-UI thread, call postInvalidate().。

API的描述译文：当Invalidate()被调用的时候，View的OnDraw()就会被调用，Invalidate()必须是在UI线程中被调用，如果在新线程中更新视图的就调用postInvalidate()。

❻ Android - View 绘制流程

我们知道，在 Android 中，View 绘制主要包含 3 大流程：

Android 中，主要有两种视图： View 和 ViewGroup ，其中：

虽然 ViewGroup 继承于 View ，但是在 View 绘制三大流程中，某些流程需要区分 View 和 ViewGroup ，它们之间的操作并不完全相同，比如：

对 View 进行测量，主要包含两个步骤：

对于第一个步骤，即求取 View 的 MeasureSpec ，首先我们来看下 MeasureSpec 的源码定义：

MeasureSpec 是 View 的一个公有静态内部类，它是一个 32 位的 int 值，高 2 位表示 SpecMode（测量模式），低 30 位表示 SpecSize（测量尺寸/测量大小）。
MeasureSpec 将两个数据打包到一个 int 值上，可以减少对象内存分配，并且其提供了相应的工具方法可以很方便地让我们从一个 int 值中抽取出 View 的 SpecMode 和 SpecSize。

一个 MeasureSpec 表达的是：该 View 在该种测量模式（SpecMode）下对应的测量尺寸（SpecSize）。其中，SpecMode 有三种类型：

对 View 进行测量，最关键的一步就是计算得到 View 的 MeasureSpec ，子View 在创建时，可以指定不同的 LayoutParams （布局参数）， LayoutParams 的源码主要内容如下所示：

其中：

LayoutParams 会受到父容器的 MeasureSpec 的影响，测量过程会依据两者之间的相互约束最终生成子View 的 MeasureSpec ，完成 View 的测量规格。

简而言之，View 的 MeasureSpec 受自身的 LayoutParams 和父容器的 MeasureSpec 共同决定（ DecorView 的 MeasureSpec 是由自身的 LayoutParams 和屏幕尺寸共同决定，参考后文）。也因此，如果要求取子View 的 MeasureSpec ，那么首先就需要知道父容器的 MeasureSpec ，层层逆推而上，即最终就是需要知道顶层View（即 DecorView ）的 MeasureSpec ，这样才能一层层传递下来，这整个过程需要结合 Activity 的启动过程进行分析。

我们知道，在 Android 中， Activity 是作为视图组件存在，主要就是在手机上显示视图界面，可以供用户操作， Activity 就是 Andorid 中与用户直接交互最多的系统组件。

Activity 的基本视图层次结构如下所示：

Activity 中，实际承载视图的组件是 Window （更具体来说为 PhoneWindow ），顶层View 是 DecorView ，它是一个 FrameLayout ， DecorView 内部是一个 LinearLayout ，该 LinearLayout 由两部分组成（不同 Android 版本或主题稍有差异）： TitleView 和 ContentView ，其中， TitleView 就是标题栏，也就是我们常说的 TitleBar 或 ActionBar ， ContentView 就是内容栏，它也是一个 FrameLayout ，主要用于承载我们的自定义根布局，即当我们调用 setContentView(...) 时，其实就是把我们自定义的布局设置到该 ContentView 中。

当 Activity 启动完成后，最终就会渲染出上述层次结构的视图。

因此，如果我们要求取得到子View 的 MeasureSpec ，那么第一步就是求取得到顶层View（即 DecorView ）的 MeasureSpec 。大致过程如下所示：

经过上述步骤求取得到 View 的 MeasureSpec 后，接下来就可以真正对 View 进行测量，求取 View 的最终测量宽/高：

Android 内部对视图进行测量的过程是由 View#measure(int, int) 方法负责的，但是对于 View 和 ViewGroup ，其具体测量过程有所差异。

因此，对于测量过程，我们分别对 View 和 ViewGroup 进行分析：

综上，无论是对 View 的测量还是 ViewGroup 的测量，都是由 View#measure(int widthMeasureSpec, int heightMeasureSpec) 方法负责，然后真正执行 View 测量的是 View 的 onMeasure(int widthMeasureSpec, int heightMeasureSpec) 方法。

具体来说， View 直接在 onMeasure(...) 中测量并设置自己的最终测量宽/高。在默认测量情况下， View 的测量宽/高由其父容器的 MeasureSpec 和自身的 LayoutParams 共同决定，当 View 自身的测量模式为 LayoutParams.UNSPECIFIED 时，其测量宽/高为 android:minWidth / android:minHeight 和其背景宽/高之间的较大值，其余情况皆为自身 MeasureSpec 指定的测量尺寸。

而对于 ViewGroup 来说，由于布局特性的丰富性，只能自己手动覆写 onMeasure(...) 方法，实现自定义测量过程，但是总的思想都是先测量 子View 大小，最终才能确定自己的测量大小。

当确定了 View 的测量大小后，接下来就可以来确定 View 的布局位置了，也即将 View 放置到屏幕具体哪个位置。

View 的布局过程由 View#layout(...) 负责，其源码如下：

View#layout(...) 主要就做了两件事：

ViewGroup 的布局流程由 ViewGroup#layout(...) 负责，其源码如下：

可以看到， ViewGroup#layout(...) 最终也是通过 View#layout(...) 完成自身的布局过程，一个注意的点是， ViewGroup#layout(...) 是一个 final 方法，因此子类无法覆写该方法，主要是 ViewGroup#layout(...) 方法内部对子视图动画效果进行了相关设置。

由于 ViewGroup#layout(...) 内部最终调用的还是 View#layout(...) ，因此， ViewGroup#onLayout(...) 就会得到回调，用于处理 子View 的布局放置，其源码如下：

由于不同的 ViewGroup ，其布局特性不同，因此 ViewGroup#onLayout(...) 是一个抽象方法，交由 ViewGroup 子类依据自己的布局特性，摆放其 子View 的位置。

当 View 的测量大小，布局位置都确定后，就可以最终将该 View 绘制到屏幕上了。

View 的绘制过程由 View#draw(...) 方法负责，其源码如下：

其实注释已经写的很清楚了， View#draw(...) 主要做了以下 6 件事：

我们知道，在 Activity 启动过程中，会调用到 ActivityThread.handleResumeActivity(...) ，该方法就是 View 视图绘制的起始之处：

可以看到， ActivityThread.handleResumeActivity(...) 主要就是获取到当前 Activity 绑定的 ViewManager ，最后调用 ViewManager.addView(...) 方法将 DecorView 设置到 PhoneWindow 上，也即设置到当前 Activity 上。 ViewManager 是一个接口， WindowManager 继承 ViewManager ，而 WindowManagerImpl 实现了接口 WindowManager ，此处的 ViewManager.addView(...) 实际上调用的是 WindowManagerImpl.addView(...) ，源码如下所示：

WindowManagerImpl.addView(...) 内部转发到 WindowManagerGlobal.addView(...) ：

在 WindowManagerGlobal.addView(...) 内部，会创建一个 ViewRootImpl 实例，然后调用 ViewRootImpl.setView(...) 将 ViewRootImpl 与 DecorView 关联到一起：

ViewRootImpl.setView(...) 内部首先关联了传递过来的 DecorView （通过属性 mView 指向 DecorView 即可建立关联），然后最终调用 requestLayout() ，而 requestLayout() 内部又会调用方法 scheleTraversals() ：

ViewRootImpl.scheleTraversals() 内部主要做了两件事：

Choreographer.postCallback(...) 会申请一次 VSYNC 中断信号，当 VSYNC 信号到达时，便会回调 Choreographer.doFrame(...) 方法，内部会触发已经添加的回调任务， Choreographer 的回调任务有以下四种类型：

因此， ViewRootImpl.scheleTraversals(...) 内部通过 mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null) 发送的异步视图渲染消息就会得到回调，即回调 mTra

❼ Android 重学系列 View的绘制流程(六) 硬件渲染(上)

本文开始聊聊Android中的硬件渲染。如果跟着我的文章顺序，从SF进程到App进程的绘制流程一直阅读，我们到这里已经有了一定的基础，可以试着进行横向比对如Chrome浏览器渲染流程，看看软件渲染，硬件渲染，SF合成都做了什么程度的优化。

先让我们回顾一下负责硬件渲染的主体对象ThreadedRenderer在整个绘制流程中做了哪几个步骤。

在硬件渲染的过程中，有一个很核心的对象RenderNode，作为每一个View绘制的节点对象。

当每一次进行准备进行绘制的时候，都会雷打不动执行如下三个步骤：

如果遇到什么问题欢迎来到 https://www.jianshu.com/p/c84bfa909810 下进行讨论

实际上整个硬件渲染的设计还是比较庞大。因此本文先聊聊ThreadedRender整个体系中主要对象的构造以及相关的原理。

首先来认识下面几个重要的对象有一个大体的印象。

在Java层中面向Framework中，只有这么多，下面是一一映射的简图。

能看到实际上RenderNode也会跟着View 树的构建同时一起构建整个显示层级。也是因此ThreadedRender也能以RenderNode为线索构建出一套和软件渲染一样的渲染流程。

仅仅这样？如果只是这么简单，知道我习惯的都知道，我喜欢把相关总结写在最后。如果把总揽写在正文开头是因为设计比较繁多。因为我们如果以流水线的形式进行剖析容易造成迷失细节的困境。

让我继续介绍一下，在硬件渲染中native层的核心对象。

如下是一个思维导图：

有这么一个大体印象后，就不容易迷失在源码中。我们先来把这些对象的实例化以及上面列举的ThreadedRenderer在ViewRootImpl中执行行为的顺序和大家来聊聊其原理，先来看看ThreadedRenderer的实例化。

当发现mSurfaceHolder为空的时候会调用如下函数：

而这个方法则调用如下的方法对ThreadedRenderer进行创建：

文件：/ frameworks / base / core / java / android / view / ThreadedRenderer.java

能不能创建的了ThreadedRenderer则决定于全局配置。如果ro.kernel.qemu的配置为0，说明支持OpenGL 则可以直接返回true。如果qemu.gles为-1说明不支持OpenGL es返回false，只能使用软件渲染。如果设置了qemu.gles并大于0，才能打开硬件渲染。

我们能看到ThreadedRenderer在初始化，做了三件事情：

关键是看1-3点中ThreadRenderer都做了什么。

文件：/ frameworks / base / core / jni / android_view_ThreadedRenderer.cpp

能看到这里是直接实例化一个RootRenderNode对象，并把指针的地址直接返回。

能看到RootRenderNode继承了RenderNode对象，并且保存一个JavaVM也就是我们所说的Java虚拟机对象，一个java进程全局只有一个。同时通过getForThread方法，获取ThreadLocal中的Looper对象。这里实际上拿的就是UI线程的Looper。

在这个构造函数有一个mDisplayList十分重要，记住之后会频繁出现。接着来看看RenderNode的头文件：
文件：/ frameworks / base / libs / hwui / RenderNode.h

实际上我把几个重要的对象留下来：

文件：/ frameworks / base / core / java / android / view / RenderNode.java

能看到很简单，就是包裹一个native层的RenderNode返回一个Java层对应的对象开放Java层的操作API。

能看到这个过程生成了两个对象：

这个对象实际上让RenderProxy持有一个创建动画上下文的工厂。RenderProxy可以通过ContextFactoryImpl为每一个RenderNode创建一个动画执行对象的上下文AnimationContextBridge。

文件：/ frameworks / base / libs / hwui / renderthread / RenderProxy.cpp

在这里有几个十分重要的对象被实例化，当然这几个对象在聊TextureView有聊过( SurfaceView和TextureView 源码浅析 )：

我们依次看看他们初始化都做了什么。

文件：/ frameworks / base / libs / hwui / renderthread / RenderThread.cpp

能看到其实就是简单的调用RenderThread的构造函数进行实例化，并且返回对象的指针。

RenderThread是一个线程对象。先来看看其头文件继承的对象：
文件：/ frameworks / base / libs / hwui / renderthread / RenderThread.h

其中RenderThread的中进行排队处理的任务队列实际上是来自ThreadBase的WorkQueue对象。

文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h

ThreadBase则是继承于Thread对象。当调用start方法时候其实就是调用Thread的run方法启动线程。

另一个更加关键的对象，就是实例化一个Looper对象到WorkQueue中。而直接实例化Looper实际上就是新建一个Looper。但是这个Looper并没有获取当先线程的Looper，这个Looper做什么的呢？下文就会揭晓。

WorkQueue把一个Looper的方法指针设置到其中，其作用可能是完成了某一件任务后唤醒Looper继续工作。

而start方法会启动Thread的run方法。而run方法最终会走到threadLoop方法中，至于是怎么走进来的，之后有机会会解剖虚拟机的源码线程篇章进行讲解。

在threadloop中关键的步骤有如下四个：

在这个过程中创建了几个核心对象：

另一个核心的方法就是，这个方法为WorkQueue的Looper注册了监听：

能看到在这个Looper中注册了对DisplayEventReceiver的监听，也就是Vsync信号的监听，回调方法为displayEventReceiverCallback。

我们暂时先对RenderThread的方法探索到这里，我们稍后继续看看回调后的逻辑。

文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h

能看到这里的逻辑很简单实际上就是调用Looper的pollOnce方法，阻塞Looper中的循环，直到Vsync的信号到来才会继续往下执行。详细的可以阅读我写的 Handler与相关系统调用的剖析 系列文章。

文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h

实际上调用的是WorkQueue的process方法。

文件：/ frameworks / base / libs / hwui / thread / WorkQueue.h

能看到这个过程中很简单，几乎和Message的loop的逻辑一致。如果Looper的阻塞打开了，则首先找到预计执行时间比当前时刻都大的WorkItem。并且从mWorkQueue移除，最后添加到toProcess中，并且执行每一个WorkItem的work方法。而每一个WorkItem其实就是通过从某一个压入方法添加到mWorkQueue中。

到这里，我们就明白了RenderThread中是如何消费渲染任务的。那么这些渲染任务又是哪里诞生呢？

上文聊到了在RenderThread中的Looper会监听Vsync信号，当信号回调后将会执行下面的回调。

能看到这个方法的核心实际上就是调用drainDisplayEventQueue方法，对ui渲染任务队列进行处理。

能到在这里mVsyncRequested设置为false，且mFrameCallbackTaskPending将会设置为true，并且调用queue的postAt的方法执行ui渲染方法。

还记得queue实际是是指WorkQueue，而WorkQueue的postAt方法实际实现如下：
/ frameworks / base / libs / hwui / thread / WorkQueue.h

情景带入，当一个Vsync信号达到Looper的监听者，此时就会通过WorkQueue的drainDisplayEventQueue 压入一个任务到队列中。

每一个默认的任务都是执行dispatchFrameCallback方法。这里的判断mWorkQueue中是否存在比当前时间更迟的时刻，并返回这个WorkItem。如果这个对象在头部needsWakeup为true，说明可以进行唤醒了。而mWakeFunc这个方法指针就是上面传下来：

把阻塞的Looper唤醒。当唤醒后就继续执行WorkQueue的process方法。也就是执行dispatchFrameCallbacks方法。

在这里执行了两个事情：

先添加到集合中，在上面提到过的threadLoop中，会执行如下逻辑：

如果大小不为0，则的把中的IFrameCallback全部迁移到mFrameCallbacks中。

而这个方法什么时候调用呢？稍后就会介绍。其实这部分的逻辑在TextureView的解析中提到过。

接下来将会初始化一个重要对象：

这个对象名字叫做画布的上下文，具体是什么上下文呢？我们现在就来看看其实例化方法。
文件：/ frameworks / base / libs / hwui / renderthread / CanvasContext.cpp

文件：/ device / generic / goldfish / init.ranchu.rc

在init.rc中默认是opengl，那么我们就来看看下面的逻辑：

首先实例化一个OpenGLPipeline管道，接着OpenGLPipeline作为参数实例化CanvasContext。

文件：/ frameworks / base / libs / hwui / renderthread / OpenGLPipeline.cpp

能看到在OpenGLPipeline中，实际上就是存储了RenderThread对象，以及RenderThread中的mEglManager。透过OpenGLPipeline来控制mEglManager进而进一步操作OpenGL。

做了如下操作：

文件：/ frameworks / base / libs / hwui / renderstate / RenderState.cpp

文件：/ frameworks / base / libs / hwui / renderthread / DrawFrameTask.cpp

实际上就是保存这三对象RenderThread；CanvasContext；RenderNode。

文件：/ frameworks / base / core / jni / android_view_ThreadedRenderer.cpp

能看到实际上就是调用RenderProxy的setName方法给当前硬件渲染对象设置名字。

文件：/ frameworks / base / libs / hwui / renderthread / RenderProxy.cpp

能看到在setName方法中，实际上就是调用RenderThread的WorkQueue，把一个任务队列设置进去，并且调用runSync执行。

能看到这个方法实际上也是调用post执行排队执行任务，不同的是，这里使用了线程的Future方式，阻塞了执行，等待CanvasContext的setName工作完毕。

❽ android view的绘制中,View绘制的时间如何和vsync屏幕刷新频率...

两者并不同步。硬件Vsync被转化为两个不同delay的软件信号，分别供给Choreographer和SurfaceFlinger(并且前者的延时可能是负值)，用以在两者之间制造出充分的时间窗。当硬件产生Vsync后，经过Delay1，开始所有当前窗口的绘制；经过Delay2,SurfaceFlinger服务开始合并所有窗口(Layer)的最新内容,将结果提交给fb来刷新显示。所以如果某应用未能在时间窗内及时完成显示工作(queueBuffer),它只能等到SurfaceFlinger的下一轮合并了。以上流程依赖具体平台实现，仅供参考。

❾ android怎么判断view有没有绘制结束

可以设置这个回调函数

//view重绘时回调
view.getViewTreeObserver().addOnDrawListener(new OnDrawListener() {
@Override
public void onDraw() {
// TODO Auto-generated method stub

}
});

//view加载完成时回调
view.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {
@Override
public void onGlobalLayout() {
// TODO Auto-generated method stub

}
});

❿ android怎么动态调用View.ondraw实现动态绘制自定义View

在自定义的时候，复写该方法，在代码中绘制控件时，会自动调用该方法，在修改了控件，需要重新绘制时，则使用View的invalidate()即可实现重绘！！！