UI 优化系列专题，来聊一聊 Android 渲染相关知识，主要涉及 UI 渲染背景知识、如何优化 UI 渲染两部分内容。
UI 优化系列专题
- UI 渲染背景知识
《View 绘制流程之 setContentView() 到底做了什么？》
《View 绘制流程之 DecorView 添加至窗口的过程》
《深入 Activity 三部曲（3）View 绘制流程》
《Android 之 LayoutInflater 全面解析》
《关于渲染，你需要了解什么？》
《Android 之 Choreographer 详细分析》
- 如何优化 UI 渲染
《Android 之如何优化 UI 渲染（上）》
《Android 之如何优化 UI 渲染（下）》
在 View 绘制流程系列，分别介绍了 View 的创建以及添加至窗口的过程，它们也是为今天要分析的 View 绘制任务做的铺垫，View 的绘制流程主要包含三个阶段：measure -> layout -> draw。
在具体分析之前，还是通过几个问题来了解下今天要分析的内容：
- Handler 异步消息的作用？
- Android 是如何解决不确定的布局尺寸？即 MATCH_PARENT 或 WRAP_CONTENT。
- 为什么 View.GONE 不会占用布局空间？
- getWidth() 和 getMeasuredWidth() 有什么区别？在什么时候调用才会有值？
requestLayout()
View 绘制的起始点是在 ViewRootImpl 的 requestLayout 方法，前面有分析到在该方法首先会检查是否在原线程。这里简单说下，UI 的绘制并非一定要在主线程，但是它要求是在原线程，绝大多数操作系统 UI 框架都是单线程的，这主要是因为多线程的 UI 框架在设计上会非常复杂。
然后通过 scheduleTraversals 方法发送消息开始 View 绘制流程：
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
//同步屏障
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
//编舞者，可以用它来监听帧频
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
//... 省略
}
}
注意 postSyncBarrier() 发送同步屏障消息，可能很多人不知道 Handler 有两种 Message 类型。
- 同步消息（普通消息）
- 异步消息（Android 4.1 新增，配合 VSYNC 信号）
Handler 的构造方法提供了用于区分两种消息的构造方法，不过它们被 @hide 了，但是 Message 为我们敞开了：
//设置为异步消息
public void setAsynchronous(boolean async) {
if (async) {
flags |= FLAG_ASYNCHRONOUS;
} else {
flags &= ~FLAG_ASYNCHRONOUS;
}
}
//获取当前消息类型，是同步消息还是异步消息
public boolean isAsynchronous() {
return (flags & FLAG_ASYNCHRONOUS) != 0;
}
一般情况下同步消息和异步消息的处理方式并没有什么区别，只有在设置了同步屏障时才会出现差异。同步屏障为 Handler 消息机制增加了一种简单的优先级关系，异步消息的优先级要高于同步消息，用于配合系统的 VSYNC 信号。简单点说，设置了同步屏障之后，Handler 只会处理异步消息。
但是发送同步屏障的接口并没有对应用开发者公开，其实它的主要作用是为了更快的响应 UI 绘制事件，避免长时间等待于消息队列。
继续分析，发送 UI 绘制任务 mTraversalRunnable 到 Choreographer。
//编舞者，可以用它来监听帧频
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
- Choreographer 是负责获取 VSYNC 同步信号并统一调度 UI 的绘制任务。Choreographer 是线程级别单例，并且具有处理当前线程消息队列（MessageQueue）的能力。关于 Choreographer 更详细的分析，可以参考《Android 之 Choreographer 详细分析》。
// 线程级别单例，肯定不会感到默认，最简单的方式使用ThreadLocal
private static final ThreadLocal<Choreographer> sThreadInstance =
new ThreadLocal<Choreographer>() {
@Override
protected Choreographer initialValue() {
// 当前线程Looper，当前的分析在主线程
Looper looper = Looper.myLooper();
if (looper == null) {
throw new IllegalStateException("The current thread must have a looper!");
}
// 为当前线程创建一个Choreographer
return new Choreographer(looper, VSYNC_SOURCE_APP);
}
};
看下 Choreographer 的构造方法，注意 FrameHandler 接收对应线程的 Looper 对象。
private Choreographer(Looper looper) {
//当前线程Looper
mLooper = looper;
//创建handle对象，用于处理消息
mHandler = new FrameHandler(looper);
//创建VSYNC的信号接受对象
mDisplayEventReceiver = USE_VSYNC ? new FrameDisplayEventReceiver(looper) : null;
//初始化上一次frame渲染的时间点
mLastFrameTimeNanos = Long.MIN_VALUE;
//计算帧率，也就是一帧所需的渲染时间，getRefreshRate是刷新率，一般是60
mFrameIntervalNanos = (long)(1000000000 / getRefreshRate());
//创建消息处理队列
mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1];
for (int i = 0; i <= CALLBACK_LAST; i++) {
mCallbackQueues[i] = new CallbackQueue();
}
}
- mTraversalRunnable
mTraversalRunnable 本质是一个 Runnable，通过 mChoreographer.postCallback() 发送到主线程消息队列（这里以主线程绘制流程做分析）。
final class TraversalRunnable implements Runnable {
@Override
public void run() {
//开始执行绘制遍历
doTraversal();
}
}
doTraversal() 真正开始执行 UI 绘制的遍历过程：
void doTraversal() {
if (mTraversalScheduled) {
//防止重复
mTraversalScheduled = false;
//移除屏障消息
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
if (mProfile) {
Debug.startMethodTracing("ViewAncestor");
}
//执行UI绘制的遍历过程
performTraversals();
if (mProfile) {
Debug.stopMethodTracing();
mProfile = false;
}
}
}
mTraversalScheduled 变量主要防止重复的绘制任务，removeSyncBarrier 方法移除同步屏障，因为此时 View 绘制任务已经处于执行过程中。performTraversals() 将依次完成 View 的三大绘制流程：performMeasure()、performLayout() 和 performDraw()。
private void performTraversals() {
// 当前DecorView
final View host = mView;
// ... 省略
//想要展示窗口的宽高
int desiredWindowWidth;
int desiredWindowHeight;
if (mFirst) {
//将窗口信息依附给DecorView
host.dispatchAttachedToWindow(mAttachInfo, 0);
}
//开始进行布局准备
if (mFirst || windowShouldResize || insetsChanged ||
viewVisibilityChanged || params != null) {
// ... 省略
if (!mStopped) {
boolean focusChangedDueToTouchMode = ensureTouchModeLocally(
(relayoutResult&WindowManagerGlobal.RELAYOUT_RES_IN_TOUCH_MODE) != 0);
if (focusChangedDueToTouchMode || mWidth != host.getMeasuredWidth()
|| mHeight != host.getMeasuredHeight() || contentInsetsChanged) {
// DecorView默认LayoutParams的属性是MATCH_PARENT
// 此时的宽度测量模式为EXACTLY（表示确定大小）, 测量大小为窗口宽度大小，因为DecorView的LayoutParams为MATCH_PARENT
int childWidthMeasureSpec = getRootMeasureSpec(mWidth, lp.width);
// 高度测量模式也是确定的EXACTLY，测量大小为窗口高度大小
int childHeightMeasureSpec = getRootMeasureSpec(mHeight, lp.height);
// 执行View测量工作，计算出每个View尺寸
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
int width = host.getMeasuredWidth();
int height = host.getMeasuredHeight();
boolean measureAgain = false;
/*******部分代码省略**********/
if (measureAgain) {
//View的测量
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
}
layoutRequested = true;
}
}
} else {
/*******部分代码省略**********/
}
final boolean didLayout = layoutRequested /*&& !mStopped*/ ;
boolean triggerGlobalLayoutListener = didLayout
|| mAttachInfo.mRecomputeGlobalAttributes;
if (didLayout) {
//View的布局
performLayout(lp, desiredWindowWidth, desiredWindowHeight);
/*******部分代码省略**********/
}
/*******部分代码省略**********/
if (!cancelDraw && !newSurface) {
if (!skipDraw || mReportNextDraw) {
/*******部分代码省略**********/
//View的绘制
performDraw();
}
} else {
if (viewVisibility == View.VISIBLE) {
// Try again
scheduleTraversals();
} else if (mPendingTransitions != null && mPendingTransitions.size() > 0) {
for (int i = 0; i < mPendingTransitions.size(); ++i) {
mPendingTransitions.get(i).endChangingAnimations();
}
mPendingTransitions.clear();
}
}
mIsInTraversal = false;
}
}
首先需要说明 DecorView 的 LayoutParams 宽高默认为 MATCH_PARENT，即窗口尺寸。
public LayoutParams() {
//默认是MATCH_PARENT
super(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT);
type = TYPE_APPLICATION;
format = PixelFormat.OPAQUE;
}
在具体分析测量过程之前，先要讲下 Android 系统为自适应布局尺寸引入了 LayoutParams.MATCH_PARENT 和 LayoutParams.WRAP_CONTENT，这样就会有不确定的情况，那 Android 又是如何解决不确定的布局尺寸呢？
答案就是 MeasureSpec（ 测量规格），它本质是 4 个字节的 int 数值，主要包含两部分：高 2 位表示测量模式，低 30 位表示测量大小。
- 测量模式
MeasureSpec.EXACTLY：精确大小，父容器已经测量出所需要的精确大小，这也是我们 childView 的最终大小 — MATCH_PARENT。
MeasureSpec.AT_MOST： 最终的大小不能超过我们的父容器 — WRAP_CONTENT。
UNSPECIFIED：不确定的，源码内部使用，一般在 ScorllView、ListView 中能看到这些，需要动态测量。
在 MeasureSpec 中测量模式关键方法：
/**
* 获取测量模式，取最高两位
*/
public static int getMode(int measureSpec) {
//noinspection ResourceType
//MODE_MASK为110000000000000000000000000000
return (measureSpec & MODE_MASK);
}
- 测量大小
测量大小是根据测量模式来确定，在 Measure 流程中，系统将 View 的 LayoutParams 根据父容器施加的规则转化成对应的 MeasureSpec，在 onMeasure() 中根据这个 MeasureSpec 来确定 View 的测量宽高。
在 MeasureSpec 中测量大小关键方法：
/**
* 获取测量大小，取低30位
*/
public static int getSize(int measureSpec) {
//~MODE_MASK为00111111111111111111111111111111
return (measureSpec & ~MODE_MASK);
}
说道这里，需要先看下表示窗口视图 DecorView 的测量模式和测量大小：
// 获取DecorView的宽高测量规格
private static int getRootMeasureSpec(int windowSize, int rootDimension) {
int measureSpec;
switch (rootDimension) {
// DecorView默认走这里
case ViewGroup.LayoutParams.MATCH_PARENT:
// 此时测量大小就是窗口大小，测量模式就是EXACTLY，表示确定的
measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.EXACTLY);
break;
case ViewGroup.LayoutParams.WRAP_CONTENT:
// 此时测量模式可调整的，即AT_MOST(最大)，最大为窗口大小
measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.AT_MOST);
break;
default:
measureSpec = MeasureSpec.makeMeasureSpec(rootDimension, MeasureSpec.EXACTLY);
break;
}
//返回测量规格
return measureSpec;
}
由于 DecorView 的宽高为 MATCH_PARENT，故它的宽高测量规格都为：EXACTLY + windowSize（窗口大小，视具体手机屏幕决定）。
1. performMeasure()
接下来开始 View 的测量工作，注意 mView 实际是 DecorView 如下：
/**
* 执行View的测量工作
*/
private void performMeasure(int childWidthMeasureSpec, int childHeightMeasureSpec) {
if (mView == null) {
return;
}
Trace.traceBegin(Trace.TRACE_TAG_VIEW, "measure");
try {
// mView实际是DecorView
// 也就是真正测量工作是从DecorView开始的
mView.measure(childWidthMeasureSpec, childHeightMeasureSpec);
} finally {
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
}
调用 DecorView 的 measure 方法，不过 measure 方法是 View 独有的，并且被声明为 final。
/**
* View的measure方法
*/
public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
// 是否有光学边界
boolean optical = isLayoutModeOptical(this);
if (optical != isLayoutModeOptical(mParent)) {
Insets insets = getOpticalInsets();
int oWidth = insets.left + insets.right;
int oHeight = insets.top + insets.bottom;
widthMeasureSpec = MeasureSpec.adjust(widthMeasureSpec, optical ? -oWidth : oWidth);
heightMeasureSpec = MeasureSpec.adjust(heightMeasureSpec, optical ? -oHeight : oHeight);
}
// Suppress sign extension for the low bytes
// 将宽度测量规格和高度测量规格整合成long，高32位为宽度，低32位为高度测量规格
long key = (long) widthMeasureSpec << 32 | (long) heightMeasureSpec & 0xffffffffL;
// 缓存当前测量结果的容器
if (mMeasureCache == null) mMeasureCache = new LongSparseLongArray(2);
// 是否强制布局
final boolean forceLayout = (mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT;
// 这里主要是做优化，防止在未发生变化的情况下，无谓的测量工作
// 宽度和高度测量规格是否发生过变化
final boolean specChanged = widthMeasureSpec != mOldWidthMeasureSpec
|| heightMeasureSpec != mOldHeightMeasureSpec;
// 宽高的测量模式是否为EXACTLY
final boolean isSpecExactly = MeasureSpec.getMode(widthMeasureSpec) == MeasureSpec.EXACTLY
&& MeasureSpec.getMode(heightMeasureSpec) == MeasureSpec.EXACTLY;
// 新的测量大小是否等于当前测量大小
final boolean matchesSpecSize = getMeasuredWidth() == MeasureSpec.getSize(widthMeasureSpec)
&& getMeasuredHeight() == MeasureSpec.getSize(heightMeasureSpec);
// 如果与上次测量结果发生变化此时需要重写测量
final boolean needsLayout = specChanged
&& (sAlwaysRemeasureExactly || !isSpecExactly || !matchesSpecSize);
if (forceLayout || needsLayout) {
// first clears the measured dimension flag
mPrivateFlags &= ~PFLAG_MEASURED_DIMENSION_SET;
resolveRtlPropertiesIfNeeded();
int cacheIndex = forceLayout ? -1 : mMeasureCache.indexOfKey(key);
// < 0 表示当前测量已经失效（缓存不存在），需要重新测量
if (cacheIndex < 0 || sIgnoreMeasureCache) {
// measure ourselves, this should set the measured dimension flag back
onMeasure(widthMeasureSpec, heightMeasureSpec);
mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
} else {
// 否则测量结果未发生变化，value高32位为宽度，低32位为高度
long value = mMeasureCache.valueAt(cacheIndex);
// Casting a long to int drops the high 32 bits, no mask needed
setMeasuredDimensionRaw((int) (value >> 32), (int) value);
// 注意这个标志位，标记在layout之前需要measure
mPrivateFlags3 |= PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
}
// 如果自定义View中没有调用setMeasuredDimension()，会抛出异常。
if ((mPrivateFlags & PFLAG_MEASURED_DIMENSION_SET) != PFLAG_MEASURED_DIMENSION_SET) {
throw new IllegalStateException("View with id " + getId() + ": "
+ getClass().getName() + "#onMeasure() did not set the"
+ " measured dimension by calling"
+ " setMeasuredDimension()");
}
mPrivateFlags |= PFLAG_LAYOUT_REQUIRED;
}
// 保存最新测量规格
mOldWidthMeasureSpec = widthMeasureSpec;
mOldHeightMeasureSpec = heightMeasureSpec;
// 缓存当前测量结果
mMeasureCache.put(key, ((long) mMeasuredWidth) << 32 |
(long) mMeasuredHeight & 0xffffffffL); // suppress sign extension
}
可以看到系统对 View 的测量工作做了大量的优化，只为有效减少无谓的测量工作，提高 UI 渲染性能。
- 注意代码中 if ((mPrivateFlags & PFLAG_MEASURED_DIMENSION_SET) != PFLAG_MEASURED_DIMENSION_SET)，如果我们在自定义 View 过程中，最后没有给 View 设置测量大小，即 setMeasuredDimension() ，此时将会抛出异常。后面会分析到。
如果需要测量，此时调用 onMeasure 方法，onMeasure 方法的设计与 measure 方法不同，measure 方法在 View 中设计为 final，而 onMeasure 方法旨在子 View 重写该方法，这也很容易理解，View 的最终大小需要自行去测量。
- 注意：onMeasure 方法是需要具体 View 自行实现，所以在 ViewGroup 中没有实现该方法。
我们先来看下 View 的默认测量过程 onMeasure 方法如下：
/**
* View默认的onMeasure方法
*/
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
//getSuggestedMinimumWidth确定当前View的最小尺寸，根据最小尺寸与背景尺寸取较大值
//getDefaultSize()确定子View的尺寸
setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec),
getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));
}
- getSuggestedMinimumXxx()，从名字看是获取 View 最小建议尺寸，以宽度为例：
/**
* 确定View的最小宽度，根据最小宽度和背景宽度取较大值
*/
protected int getSuggestedMinimumWidth() {
// 没有背景图，则使用最小宽度
// 否则取最小宽度和背景宽度的较大值
return (mBackground == null) ? mMinWidth : max(mMinWidth, mBackground.getMinimumWidth());
}
- getDefaultSize()，根据最小建议尺寸和测量大小决定 View 的最终尺寸：
/**
* size为当前View的最小尺寸
* measureSpec，当前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:
//如果测量模式为不确定
//此时尺寸就是View的最小尺寸
result = size;
break;
case MeasureSpec.AT_MOST:
case MeasureSpec.EXACTLY:
//此时为View的测量大小
result = specSize;
break;
}
return result;
}
- setMeasuredDimension() 最终执行到 setMeasuredDimensionRaw() 设置 View 的测量大小：
private void setMeasuredDimensionRaw(int measuredWidth, int measuredHeight) {
// 赋值给View成员
mMeasuredWidth = measuredWidth;
mMeasuredHeight = measuredHeight;
// 标志，已经设置View的测量大小
mPrivateFlags |= PFLAG_MEASURED_DIMENSION_SET;
}
记得上面说到的自定义 View ，如果在其 onMeasure 方法中没有调用 setMeasureDimension 方法，将会抛出异常，此时在方法最后修改该标志位：
// 标志，已经设置View的测量大小
mPrivateFlags |= PFLAG_MEASURED_DIMENSION_SET;
注意，文章开头提出的问题 getMeasuredWidth() / getMeasuredHeight() 在什么时候才会获取到值？答案就在这里，setMeasuredDimensionRaw 方法执行结束，此时调用 View 的 getMeasureXxx()，便可以拿到 View 的测量大小了。
// 获取测量宽度
public final int getMeasuredWidth() {
// measuredWidth & 0x00ffffff，舍去高2为测量模式，取低30位测量大小
return mMeasuredWidth & MEASURED_SIZE_MASK;
}
// 获取测量高度
public final int getMeasuredHeight() {
// 原理一致
return mMeasuredHeight & MEASURED_SIZE_MASK;
}
即 View 的测量大小在 measure 阶段完成之后便可以获取到。注意此时 getWidth() / getHeight() 仍然无法争取获取！
分析完了 View 的默认测量规则，但由于 DecorView 继承自 FrameLayout，所以此时 onMeasure 实际调用的是 FrameLayout 的 onMeasure 方法：
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
// 获取子View数量
int count = getChildCount();
// 确定当前View宽高测量模式存在非EXACTLY，注意这将有可能导致FrameLayout二次测量
final boolean measureMatchParentChildren =
MeasureSpec.getMode(widthMeasureSpec) != MeasureSpec.EXACTLY ||
MeasureSpec.getMode(heightMeasureSpec) != MeasureSpec.EXACTLY;
mMatchParentChildren.clear();
int maxHeight = 0;
int maxWidth = 0;
int childState = 0;
// 遍历子View
for (int i = 0; i < count; i++) {
final View child = getChildAt(i);
// 为什么GONE不占用空间就在这里
if (mMeasureAllChildren || child.getVisibility() != GONE) {
// 测量子View的大小
measureChildWithMargins(child, widthMeasureSpec, 0, heightMeasureSpec, 0);
// 获取子View的LayoutParams，获取其他布局参数
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
// 记录当前最大宽度
maxWidth = Math.max(maxWidth,
child.getMeasuredWidth() + lp.leftMargin + lp.rightMargin);
// 记录当前最大高度
maxHeight = Math.max(maxHeight,
child.getMeasuredHeight() + lp.topMargin + lp.bottomMargin);
childState = combineMeasuredStates(childState, child.getMeasuredState());
//如果当前FrameLayout宽高存在不是EXACTLY。
if (measureMatchParentChildren) {
//如果子View存在需要依赖父容器的测量大小
if (lp.width == LayoutParams.MATCH_PARENT ||
lp.height == LayoutParams.MATCH_PARENT) {
//加入需要二次测量
mMatchParentChildren.add(child);
}
}
}
}
// 最大宽度累加自身padding
maxWidth += getPaddingLeftWithForeground() + getPaddingRightWithForeground();
// 最大高度累加自身padding
maxHeight += getPaddingTopWithForeground() + getPaddingBottomWithForeground();
// 与最小高度取较大值
maxHeight = Math.max(maxHeight, getSuggestedMinimumHeight());
// 与最小宽度取较大值
maxWidth = Math.max(maxWidth, getSuggestedMinimumWidth());
// Check against our foreground's minimum height and width
final Drawable drawable = getForeground();
//如果存在foreground drawable
if (drawable != null) {
// 判断与foreground drawable 高度取较大值
maxHeight = Math.max(maxHeight, drawable.getMinimumHeight());
// 判断与foreground drawable 宽度取较大值
maxWidth = Math.max(maxWidth, drawable.getMinimumWidth());
}
//设置测量大小
setMeasuredDimension(resolveSizeAndState(maxWidth, widthMeasureSpec, childState),
resolveSizeAndState(maxHeight, heightMeasureSpec,
childState << MEASURED_HEIGHT_STATE_SHIFT));
/**
* 1.如果FrameLayout 的宽高测量模式存在非EXACTLY
* 2.与包含的子View需要依赖父View的测量大小时，（子View存在MATCH_PARENT）
* 此时需要二次测量
* */
count = mMatchParentChildren.size();
//此时需要二次测量
if (count > 1) {
for (int i = 0; i < count; i++) {
final View child = mMatchParentChildren.get(i);
final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams();
final int childWidthMeasureSpec;
if (lp.width == LayoutParams.MATCH_PARENT) {
final int width = Math.max(0, getMeasuredWidth()
- getPaddingLeftWithForeground() - getPaddingRightWithForeground()
- lp.leftMargin - lp.rightMargin);
childWidthMeasureSpec = MeasureSpec.makeMeasureSpec(
width, MeasureSpec.EXACTLY);
} else {
childWidthMeasureSpec = getChildMeasureSpec(widthMeasureSpec,
getPaddingLeftWithForeground() + getPaddingRightWithForeground() +
lp.leftMargin + lp.rightMargin,
lp.width);
}
final int childHeightMeasureSpec;
if (lp.height == LayoutParams.MATCH_PARENT) {
final int height = Math.max(0, getMeasuredHeight()
- getPaddingTopWithForeground() - getPaddingBottomWithForeground()
- lp.topMargin - lp.bottomMargin);
childHeightMeasureSpec = MeasureSpec.makeMeasureSpec(
height, MeasureSpec.EXACTLY);
} else {
childHeightMeasureSpec = getChildMeasureSpec(heightMeasureSpec,
getPaddingTopWithForeground() + getPaddingBottomWithForeground() +
lp.topMargin + lp.bottomMargin,
lp.height);
}
child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
}
}
}
注意 measureMatchParentChildren 变量，它用于标注当前 FrameLayout 宽/高测量模式是否存在非 MeasureSpec.EXACTLY。这会导致 FrameLayout 在测量阶段的性能问题 — 二次测量，后面分析到。
第一个 for 循环开始遍历测量所有子 View，注意条件：
child.getVisibility() != GONE
这就是为什么 View.GONE 不会占用布局空间，View.GONE 在测量阶段默认被忽略。
开始测量子 View 过程，measureChildWithMargins 方法如下：
protected void measureChildWithMargins(View child,
int parentWidthMeasureSpec, int widthUsed,
int parentHeightMeasureSpec, int heightUsed) {
final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams();
// 子View的宽度测量规格，根据父容器施加的规则，加上宽度内边距
final int childWidthMeasureSpec = getChildMeasureSpec(parentWidthMeasureSpec,
mPaddingLeft + mPaddingRight + lp.leftMargin + lp.rightMargin
+ widthUsed, lp.width);
// 子View的高度测量规格，根据父容器施加的规则，加上高度内边距
final int childHeightMeasureSpec = getChildMeasureSpec(parentHeightMeasureSpec,
mPaddingTop + mPaddingBottom + lp.topMargin + lp.bottomMargin
+ heightUsed, lp.height);
// 调用子View的measure方法
child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
}
看下如何确定子 View 的测量规格，getChildMeasureSpec 方法如下：
/**
* 根据父容器的测量规格确定子View的测量规格
*/
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);
//返回当前View的测量大小
int resultSize = 0;
//返回当前View的测量模式
int resultMode = 0;
switch (specMode) {
// Parent has imposed an exact size on us
case MeasureSpec.EXACTLY:
//如果子View的尺寸是固定的
//测量大小就是View设置的具体值childDimension(lp.width)
//测量模式就是精确的EXACTLY
if (childDimension >= 0) {
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size. So be it.
//如果是MATCH_PARENT，此时表示子View使用父容器尺寸
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.
//子View的大小不确定，但是最大不超过父容器大小
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
//此时子View的尺寸也是确定的
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.
//此时子View的最大大小为父容器大小
//测量模式是AT_MOST
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.
// 子View的尺寸不能确定，但是最大不能超过父容器
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
// 子View的尺寸是确定的
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size... find out how big it should
// be
//子View需要动态的测量
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
//子View需要动态的测量
resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
resultMode = MeasureSpec.UNSPECIFIED;
}
break;
}
//noinspection ResourceType
//生成子View的测量规格
return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
}
前面也有简单提到子 View 要根据父 View 施加的测量规格决定自己的测量大小。关于子 View 的测量规格这里做下简单总结：
如果子 View 的 LayoutParams 为具体数值，此时无论父 View 施加测量模式是什么，子 View 的测量规格都为 EXACTLY + childDimension（在 LayoutParams 中设置的具体数值）。
如果子 View 的 LayoutParams 为 MATCH_PARENT，当父 View 的测量模式为 EXACTLY 时，子 View 的测量规格为 EXACTLY + 小于等于父 View 的测量大小；当父 View 的测量模式为 AT_MOST 时，子 View 的测量规格为 AT_MOST + 小于等于父 View 的测量大小；当父 View 的测量大小为 UNSPECIFIED 时，子 View 的测量规格为 UNSPECIFIED + 0。
如果子 View 的 LayoutParams 为 WRAP_CONTENT，当父 View 的测量模式为 EXACTLY，子 View 的测量规格为 AT_MOST + 小于等于父 View 测量大小；当父 View 的测量规格为 AT_MOST 时，子 View 的测量规格为 AT_MOST + 小于等于父 View 的测量大小；当父 View 的测量模式为 UNSPECIFIED 时，子 View 的测量规格为 UNSPECIFIED + 0。
在 measureChildWithMargins 方法最后，调用 View 的 measure 方法完成测量结果，关于 View 的默认测量流程前面已经做过分析，感兴趣的朋友可以去分析下例如 ImageView、TextView 的测量过程。
重新回到 FrameLayout 的 onMeasure 方法，注意看在第一个 for 循环，如果当前 FrameLayout 的宽 / 高测量模式存在非 EXACTLY（即 measureMatchParentChildren == true），此时它所包含的子 View 存在 LayoutParams 为 MATCH_PARENT 时，会将该 View 记录在 mMatchParentChilden 中。被记录下的 View 需要二次测量确定大小。
小结
- 用一张图再来了解下 View 的整个测量过程：
View 树的源码 measure 流程图
- 用一张表格总结下子 View 的测量规格：
| ParentSpceMode | ParentSpceSize | ChildDimension | ChildSpecMode | ChildSpceSize |
|---|---|---|---|---|
| EXACTLY | Size | >= 0 | EXACTLY | ChildDimension |
| 同上 | 同上 | MATCH_PARENT | EXACTLY | Size |
| 同上 | 同上 | WRAP_CONTENT | AT_MOST | Size |
| AT_MOST | 同上 | >= 0 | EXACTLY | childDimension |
| 同上 | 同上 | MATCH_PARENT | AT_MOST | Size |
| 同上 | 同上 | WRAP_CONTENT | AT_MOST | Size |
| UNSPECIFIED | 同上 | >= 0 | EXACTLY | 0 |
| 同上 | 同上 | MATCH_PARENT | UNSPECIFIED | 0 |
| 同上 | 同上 | WRAP_CONTENT | UNSPECFIFE | 0 |
- 应尽可能避开在使用 FrameLayout 时发生二次测量。
确定大小的 FrameLayout，即就是保证 FrameLayout 的测量模式为 MeasureSpec.EXACTLY。
确定大小的 ChildView，或者使用 WRAP_CONTENT 。
至此 View 的测量过程就分析完了，不过测量过程涉及的细节内容非常多，感兴趣的朋友可以继续深入分析。
measure 阶段实际就是确定 View 的大小，那接下来的 layout 阶段就要开始摆放 View 的在容器中的位置了。
2. performLayout()
相比起 View 的测量过程，布局阶段可能相对简单一些。
private void performLayout(WindowManager.LayoutParams lp, int desiredWindowWidth,
int desiredWindowHeight) {
mLayoutRequested = false;
mScrollMayChange = true;
mInLayout = true;
// mView是DecorView
final View host = mView;
if (host == null) {
return;
}
Trace.traceBegin(Trace.TRACE_TAG_VIEW, "layout");
// layout就是确定View的摆放位置
try {
// host为DecorView
// 由于DecorView的LayoutParams为MATCH_PARENT,故它的left和top都为0
// 获取到DecorView的测量宽度，left + 测量宽度即 right
// 获取到DecorView的测量高度，top + 测量高度即 bottom
host.layout(0, 0, host.getMeasuredWidth(), host.getMeasuredHeight());
// ... 省略
} finally {
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
mInLayout = false;
}
注意 host 仍然是 DecorView，layout 方法与 measure 方法在 View 中的策略类似，不过 layout 方法并没有被声明为 final。
// View 的 layout
public void layout(int l, int t, int r, int b) {
// layout之前需要先进行measure测量工作
// 注意前面分析measure阶段，如果当前需要测量，但是发现已经缓存了该测量结果时，measure阶段
// 并没有真正执行onMeasure，只是将mPrivateFlags3标记为PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT
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;
// 根据是否有光影效果
// changed标志View坐标是否发生变化
// setFrame 保存新的坐标位置
boolean changed = isLayoutModeOptical(mParent) ?
setOpticalFrame(l, t, r, b) : setFrame(l, t, r, b);
// 这也是做一层优化，避免无谓的遍历layout过程
if (changed || (mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == PFLAG_LAYOUT_REQUIRED) {
// 执行布局摆放，当前实际是 DecorView，这里实际调用了FrameLayout的onLayout
onLayout(changed, l, t, r, b);
if (shouldDrawRoundScrollbar()) {
if (mRoundScrollbarRenderer == null) {
mRoundScrollbarRenderer = new RoundScrollbarRenderer(this);
}
} else {
mRoundScrollbarRenderer = null;
}
mPrivateFlags &= ~PFLAG_LAYOUT_REQUIRED;
// 回调OnLayoutChange，表示当前布局坐标发生新的变化
ListenerInfo li = mListenerInfo;
if (li != null && li.mOnLayoutChangeListeners != null) {
ArrayList<OnLayoutChangeListener> listenersCopy =
(ArrayList<OnLayoutChangeListener>) li.mOnLayoutChangeListeners.clone();
int numListeners = listenersCopy.size();
for (int i = 0; i < numListeners; ++i) {
listenersCopy.get(i).onLayoutChange(this, l, t, r, b, oldL, oldT, oldR, oldB);
}
}
}
mPrivateFlags &= ~PFLAG_FORCE_LAYOUT;
mPrivateFlags3 |= PFLAG3_IS_LAID_OUT;
if ((mPrivateFlags3 & PFLAG3_NOTIFY_AUTOFILL_ENTER_ON_LAYOUT) != 0) {
mPrivateFlags3 &= ~PFLAG3_NOTIFY_AUTOFILL_ENTER_ON_LAYOUT;
notifyEnterOrExitForAutoFillIfNeeded(true);
}
}
changed 变量同样是避免无谓的 layout 操作，这里重点看下 setFrame 方法（setOpticalFrame() 最终也是调用了 setFrame()）：
protected boolean setFrame(int left, int top, int right, int bottom) {
// 标志View坐标是否真的发生变化
boolean changed = false;
// 判断View的坐标信息是否发生变化
if (mLeft != left || mRight != right || mTop != top || mBottom != bottom) {
// 表示当前View坐标发生变化
changed = true;
// Remember our drawn bit
int drawn = mPrivateFlags & PFLAG_DRAWN;
// 原宽度
int oldWidth = mRight - mLeft;
// 原高度
int oldHeight = mBottom - mTop;
// 新宽度
int newWidth = right - left;
// 新高度
int newHeight = bottom - top;
// View大小是否发生变化，
boolean sizeChanged = (newWidth != oldWidth) || (newHeight != oldHeight);
// Invalidate our old position
invalidate(sizeChanged);
// 保存View最后坐标位置
mLeft = left;
mTop = top;
mRight = right;
mBottom = bottom;
mRenderNode.setLeftTopRightBottom(mLeft, mTop, mRight, mBottom);
mPrivateFlags |= PFLAG_HAS_BOUNDS;
if (sizeChanged) {
// View的sizeChange方法被回调
// 注意如果仅是坐标位置发生变化，View自身尺寸未发生变化sizeChange是不会被调用的
sizeChange(newWidth, newHeight, oldWidth, oldHeight);
}
// ... 省略
}
return changed;
}
setFrame 方法就是为 View 赋值新的 left、right、top 和 bottom 四个坐标点，View 的坐标位置真正发生变化， changed 变量才会返回 true。
- 注意看 sizeChanged 变量，只有当 View 的宽 / 高发生变化才会回调 sizeChange 方法。
这里还需要重点关注下 View 的宽 / 高获取，注意结合上面 View 的四个坐标点：
// 获取View的宽度，right - left 即 View 宽度
public final int getWidth() {
return mRight - mLeft;
}
// 获取View的高度，bottom - top 即 View 高度
public final int getHeight(){
return mBottom - mTop;
}
也就是说 View 的 getWidth() / getHeight() 是在 layout 阶段完成之后，才能够正确获取值。
大家肯定有过这样的疑问，如何能在 Activity 的 onCreate 方法获取到 View 的宽高呢？要知道此时 View 的绘制流程还未开始，这里推荐 2 种思路供大家参考。
- ViewTreeObserver
view.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
@Override
public void onGlobalLayout() {
// performLayout方法执行结束之后，回调
// 此时表示所有的View都已经布局完成，可以获取到任何View组件的宽度、高度、左边、右边等信息
// 需要注意多次调用带来的影响
}
});
performLayout 方法执行完毕，此时所有的 View 已经布局完成，便会回调 onGlobalLayout 通知。
- view.post()
相信很多人都使用过该方法，并且知道任务会被添加到主线程（当前分析主线程渲染）消息队列等待执行；但是它背后的执行原理可能大多数开发者并不一定了解，简单来说，它保证了在 View 绘制流程结束后回调相关任务，此时我们就可以正确获取到 View 的宽高了。具体你可以参考《Android 之你真的了解 View.post() 原理吗？》
重新回到 DecorView 的 layout 方法，如果需要布局则调用 onLayout 方法，onLayout() 在 View 中默认为空实现，但是在 ViewGroup 将其重写为 abstract，即强制 ViewGroup 的子类重写该方法，因为布局容器必须实现 childView 的布局摆放任务。
DecorView 继承自 FrameLayout，此时实际调用 FrameLayout 的 onLayout()：
protected void onLayout(boolean changed, int left, int top, int right, int bottom) {
// 遍历子View完成摆放
layoutChildren(left, top, right, bottom, false /* no force left gravity */);
}
开始遍历执行所有子 View 的 layout 过程如下：
void layoutChildren(int left, int top, int right, int bottom, boolean forceLeftGravity) {
// 获取View数量
final int count = getChildCount();
// 获取父View左侧起始点，就是 - paddingLeft
final int parentLeft = getPaddingLeftWithForeground();
// 获取父View的右侧结束点，宽度 - paddRight
final int parentRight = right - left - getPaddingRightWithForeground();
// 获取父View的top点
final int parentTop = getPaddingTopWithForeground();
// 获取父View的bottom结束点
final int parentBottom = bottom - top - getPaddingBottomWithForeground();
// 遍历摆放所有子View
for (int i = 0; i < count; i++) {
final View child = getChildAt(i);
// 忽略Visibility为GONE的View，在测量阶段它已经被忽略掉了
if (child.getVisibility() != GONE) {
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
// 获取View的测量宽度
final int width = child.getMeasuredWidth();
// 获取View的测量高度
final int height = child.getMeasuredHeight();
int childLeft;
int childTop;
int gravity = lp.gravity;
if (gravity == -1) {
gravity = DEFAULT_CHILD_GRAVITY;
}
final int layoutDirection = getLayoutDirection();
final int absoluteGravity = Gravity.getAbsoluteGravity(gravity, layoutDirection);
final int verticalGravity = gravity & Gravity.VERTICAL_GRAVITY_MASK;
// 确定Left坐标
switch (absoluteGravity & Gravity.HORIZONTAL_GRAVITY_MASK) {
//水平居中
case Gravity.CENTER_HORIZONTAL:
// (parentRight - parentLeft - width) / 2 找到中间坐标
// parentLeft+, 表示确定启示坐标
// 最后根据View设置的边距
childLeft = parentLeft + (parentRight - parentLeft - width) / 2 +
lp.leftMargin - lp.rightMargin;
break;
case Gravity.RIGHT:
if (!forceLeftGravity) {
childLeft = parentRight - width - lp.rightMargin;
break;
}
case Gravity.LEFT:
default:
childLeft = parentLeft + lp.leftMargin;
}
// 确定Top坐标
switch (verticalGravity) {
case Gravity.TOP:
childTop = parentTop + lp.topMargin;
break;
case Gravity.CENTER_VERTICAL:
childTop = parentTop + (parentBottom - parentTop - height) / 2 +
lp.topMargin - lp.bottomMargin;
break;
case Gravity.BOTTOM:
childTop = parentBottom - height - lp.bottomMargin;
break;
default:
childTop = parentTop + lp.topMargin;
}
// 确定了ChildView的left,和top
// left + width 即 right
// top + height 即使 bottom
child.layout(childLeft, childTop, childLeft + width, childTop + height);
}
}
}
可以看到在 layout 阶段默认也会忽略 View.GONE。实际上 layout 过程就是确定 View 四个点的坐标信息，计算出 left 点坐标后，left + View 测量宽度即 right 点坐标，同理计算出 top 点坐标后，top + View 测量高度即 bottom 点坐标。
至此 View 绘制流程的测量和布局两大阶段就已经分析完了，不过你是否能够依照前面的分析，自己实现一个流式布局呢？
另外，大家是否有思考过 ScollView 里面嵌套 ListView，ListView 为什么只能显示第一行的高度？感兴趣的朋友可以去分析下它们的测量过程。
3. performDraw()
private void performDraw() {
// 屏幕是否已经关闭
if (mAttachInfo.mDisplayState == Display.STATE_OFF && !mReportNextDraw) {
return;
} else if (mView == null) {
// DecorView == null
return;
}
// 是否需要全部重绘
final boolean fullRedrawNeeded = mFullRedrawNeeded;
mFullRedrawNeeded = false;
// 正在绘制标记
mIsDrawing = true;
Trace.traceBegin(Trace.TRACE_TAG_VIEW, "draw");
try {
// 调用draw方法
draw(fullRedrawNeeded);
} finally {
// 绘制完成修改标志位
mIsDrawing = false;
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
}
执行绘制任务 draw 方法如下：
private void draw(boolean fullRedrawNeeded) {
// 窗口都关联有一个 Surface
// 在 Android 中，所有的元素都在 Surface 这张画纸上进行绘制和渲染，
// 普通 View（例如非 SurfaceView 或 TextureView） 是没有 Surface 的，
// 一般 Activity 包含多个 View 形成 View Hierachy 的树形结构，只有最顶层的 DecorView 才是对 WindowManagerService “可见的”。
// 而为普通 View 提供 Surface 的正是 ViewRootImpl。
Surface surface = mSurface;
if (!surface.isValid()) {
// Surface 是否还有效
return;
}
// 跟踪FPS
if (DEBUG_FPS) {
trackFPS();
}
// ... 省略
// View 滑动通知
if (mAttachInfo.mViewScrollChanged) {
mAttachInfo.mViewScrollChanged = false;
// getViewTreeObserver().addOnScrollChangedListener()
mAttachInfo.mTreeObserver.dispatchOnScrollChanged();
}
// ... 省略
if (fullRedrawNeeded) {
mAttachInfo.mIgnoreDirtyState = true;
dirty.set(0, 0, (int) (mWidth * appScale + 0.5f), (int) (mHeight * appScale + 0.5f));
}
// 通知View开始绘制
// getViewTreeObserver().addOnDrawListener();
mAttachInfo.mTreeObserver.dispatchOnDraw();
// ... 省略
if (!dirty.isEmpty() || mIsAnimating || accessibilityFocusDirty) {
if (mAttachInfo.mThreadedRenderer != null && mAttachInfo.mThreadedRenderer.isEnabled()) {
// 开启硬件加速绘制执行这里，最终还是执行View的draw开始
mAttachInfo.mThreadedRenderer.draw(mView, mAttachInfo, this);
} else {
// 最终调用到drawSoftware
// surface，每个 View 都由某一个窗口管理，而每一个窗口都关联有一个 Surface
// mDirty.set(0, 0, mWidth, mHeight); dirty 表示画纸尺寸，对于DecorView，left = 0,
if (!drawSoftware(surface, mAttachInfo, xOffset, yOffset, scalingRequired, dirty)) {
return;
}
}
}
}
Surface，前面文章也有多次提到，在 Android 中，Window 是 View 的容器，每个窗口都会关联一个 Surface，为窗口提供 Surface 的正是 ViewRootImpl。
- Surface。每个 View 都由某一个窗口管理，而每一个窗口都关联有一个 Surface。
在 Android 3.0 之前，或者没有启用硬件加速时，系统都会使用软件方式来渲染 UI。软件绘制需要依赖 CPU，不过 CPU 对于图形处理并不是那么高效，这个过程完全没有利用到 GPU 的高性能。
所以从 Android 3.0 开始，Android 开始支持硬件加速，直到 Android 4.0 时，才默认开启硬件加速。
虽然硬件加速绘制与软件绘制整个流程差异非常大，但是在 View 层绘制逻辑是一样的，这里仅以软件绘制流程为例：
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 实际代表某块绘制区域在Sruface
// Canvas 可以简单理解为 Skia 底层接口的封装
canvas = mSurface.lockCanvas(dirty);
// The dirty rectangle can be modified by Surface.lockCanvas()
if (left != dirty.left || top != dirty.top || right != dirty.right
|| bottom != dirty.bottom) {
// 需要绘制的矩形区域有变化
attachInfo.mIgnoreDirtyState = true;
}
// 设置像素密度
// mDensity = context.getResources().getDisplayMetrics().densityDpi;
canvas.setDensity(mDensity);
} catch (Surface.OutOfResourcesException e) {
handleOutOfResourcesException(e);
return false;
} catch (IllegalArgumentException e) {
mLayoutRequested = true; // ask wm for a new surface next time.
return false;
}
try {
// ... 省略
try {
canvas.translate(-xoff, -yoff);
if (mTranslator != null) {
mTranslator.translateCanvas(canvas);
}
canvas.setScreenDensity(scalingRequired ? mNoncompatDensity : 0);
attachInfo.mSetIgnoreDirtyState = false;
// mView实际类型是DecorView
// draw调用到View中
mView.draw(canvas);
drawAccessibilityFocusedDrawableIfNeeded(canvas);
} finally {
if (!attachInfo.mSetIgnoreDirtyState) {
// Only clear the flag if it was not set during the mView.draw() call
attachInfo.mIgnoreDirtyState = false;
}
}
} finally {
try {
surface.unlockCanvasAndPost(canvas);
} catch (IllegalArgumentException e) {
mLayoutRequested = true; // ask wm for a new surface next time.
return false;
}
}
return true;
}
注意 Canvas 的获取，通过 Surface 的 lock 方法获得一个 Canvas，Canvas 可以简单理解为 Skia 底层接口的封装。
Canvas 作为参数，调用 DecorView 的 draw 方法，实际调用其父类 View 的 draw()。
关于绘制流程的三个阶段在 View 源码中都提供了默认的规则 measure()、layout() 和 draw()，只不过 Android 强制将 measure() 声明为 final。
public void draw(Canvas canvas) {
final int privateFlags = mPrivateFlags;
final boolean dirtyOpaque = (privateFlags & PFLAG_DIRTY_MASK) == PFLAG_DIRTY_OPAQUE &&
(mAttachInfo == null || !mAttachInfo.mIgnoreDirtyState);
mPrivateFlags = (privateFlags & ~PFLAG_DIRTY_MASK) | PFLAG_DRAWN;
/*
* Draw traversal performs several drawing steps which must be executed
* in the appropriate order:
*
* 1. Draw the background
* 2. If necessary, save the canvas' layers to prepare for fading
* 3. Draw view's content
* 4. Draw children
* 5. If necessary, draw the fading edges and restore layers
* 6. Draw decorations (scrollbars for instance)
*/
// Step 1, 如果需要，绘制背景
int saveCount;
// 背景不是透明的
if (!dirtyOpaque) {
// 绘制View的背景
// 重复设置背景色，会导致过度绘制
// 避免在布局容器重复设置背景
drawBackground(canvas);
}
// 如果可能，跳过第2步和第5步(常见情况)
final int viewFlags = mViewFlags;
boolean horizontalEdges = (viewFlags & FADING_EDGE_HORIZONTAL) != 0;
boolean verticalEdges = (viewFlags & FADING_EDGE_VERTICAL) != 0;
if (!verticalEdges && !horizontalEdges) {
// Step 3, 绘制View视图内容
// 通常情况下自定义 ViewGroup 不会回调onDraw
if (!dirtyOpaque) onDraw(canvas);
// Step 4, 绘制子视图
dispatchDraw(canvas);
drawAutofilledHighlight(canvas);
// Overlay is part of the content and draws beneath Foreground
if (mOverlay != null && !mOverlay.isEmpty()) {
// 绘制浮动View视图
mOverlay.getOverlayView().dispatchDraw(canvas);
}
// Step 6, 绘制装饰(前景，滚动条)
onDrawForeground(canvas);
// Step 7, 绘制默认的焦点突出显示
drawDefaultFocusHighlight(canvas);
if (debugDraw()) {
debugDrawFocus(canvas);
}
// we're done...
return;
}
}
Google 工程师非常贴心，将绘制阶段的任务和步骤做了详细介绍。
- 绘制 Vew 背景
- 如果需要，保存画布的图层以备褪色
- 绘制视图内容
- 分发绘制子视图
- 如果需要，画出渐退的边缘并恢复图层
- 绘制装饰(例如，滚动条)
绘制背景，就是绘制通过 setBackground 设置的 Drawable，关于背景设置，我们要避免重复设置，这会带来过渡绘制的问题。比如被完全遮盖的布局容器是没有必要为其设置背景的。
通常情况下，在定义 ViewGroup 时不会回调 onDraw 方法，这取决于是否设置了背景。
dispatchDraw 方法主要分发给 childView 进行绘制任务，在自定义 ViewGroup 实现绘制逻辑时一般会重写 dispatchDraw() 而不是 onDraw()。
在开发过程中，大家是否有注意 LinearLayout、FrameLayout 和 RelativeLayout 的渲染性能更好？其实三者在 layout、draw 的耗时相差不大，性能差异主要体现在 measure 阶段。LinearLayout 只会测量一次，水平或垂直方向，但需要注意 weight 的问题；FrameLayout 如果使用正确也会测量一次；而 RelativeLayout 要测量多次来确定水平和垂直方向的关联关系，但在扁平化布局更具有优势，这就需要在根据业务场景选择更优的布局容器。
- ps：现在 Google 更加推荐使用 ConstraintLayout，感兴趣的朋友可以深入了解下。
Android 的整个 UI 渲染框架的设计是非常庞大和复杂的，经过三篇文章介绍 View 绘制流程其实也仅仅是涉及皮毛而已，如果需要更深入了解这块内容，还需要不断地学习和查阅相关资料。
UI 渲染这一块也是 Google 长期以来非常重视的，基本每次 Google I/O 都会花很多篇幅讲这一块。为了弥补跟 iOS 的差距，在每个版本都做了大量的优化。在后面文章也会聊一聊 Android 渲染的演进，一起来看下 Google 工程师都做了哪些努力！
至此 View 绘制流程就已经分析完了，正如文中所讲这只不过是整个渲染框架的皮毛而已，感兴趣的朋友可以继续深入研究学习。文中如有不妥或有更好的分析结果，欢迎您的指出。
文章如果对你有帮助，请留个赞吧！
推荐阅读
其他系列专题
