安卓绘制原理概览_油炸板蓝根的博客-CSDN博客
搜了一下，全网居然没有人提过 measureCache。
在前文中提到过，measure的时候，如果命中了 measureCache，会跳过 onMeasure，同时会设置 PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT标志位，其作用顾名思义，需要在 layout 前进行 measure。
public class View {
public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
if (mMeasureCache == null) mMeasureCache = new LongSparseLongArray(2);
......
int cacheIndex = forceLayout? -1: mMeasureCache.indexOfKey(key);
if (cacheIndex < 0 || sIgnoreMeasureCache) {
// measure ourselves, this should set the measured dimension flag back
onMeasure(widthMeasureSpec, heightMeasureSpec);
mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
} else {
long value = mMeasureCache.valueAt(cacheIndex);
// Casting a long to int drops the high 32 bits, no mask needed
setMeasuredDimensionRaw((int) (value >> 32), (int) value);
mPrivateFlags3 |= PFLAG3_MEASURE_NEEDED_BEFORE_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;
}
...
}
}这里有点令人疑惑，为什么在 measure 中跳过了 onMeasure，但又在 layout 中找补了回来。不执行可以优化性能耗时，但这里又重新执行了一次，优化在哪里？既然有这段代码，那么就一定是优化的，我们先有一下两种猜测：
- 前一次和后一次执行的逻辑不同，前一次的性能耗时长，后一次的性能耗时短，所以有优化。
- 优化了执行次数，前者执行次数比后者多。
让我们先看一下引入 measureCache 的 commit message，看看作者怎么说的。
跳过 onMeasure虽然可以提高效率，但是有一些自定义 view 是依赖其 onMeasure 流程保证其正常工作的。换句话说，一些自定义 View 的 onMeasure 方法不仅仅完成了可以被跳过的 measurement，还执行了某些不能被跳过的流程。 例如 ViewPager
public class ViewPager {
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
// measure self and decor
...
// update children
populate();
// measure children
...
}
}ViewPager 依赖onMeasure 更新 page，如果 onMeasure 被跳过，就有可能出现 page 错位的情况。除了 ViewPager，RecyclerView、CoordinateLayout 等复杂度较高的组件也都在 onMeasure 中做了许多复杂的工作。既然 onMeasure 一定要执行，那么 measureCache 的优化工作又体现在哪里呢？毕竟 commit message 最后写了“but enough to optimize a number of layouts.”
measureCache 可以将一次 Traversal 中多次冗余 onMeasure 减少为一次，对于很多 ViewGroup，在 onMeasure 阶段往往会不止一次的调用 child 的 measure，例如RelativeLayout 、使用了 weight 的 LinearLayout、ConstraintLayout 等等，measureCache 的存在使得 child 本应该在 parent view onMeasure 阶段执行的多次 measure 被延后到 layout 阶段，且仅执行一次。
public class RelativeLayout extends ViewGroup {
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
measureChildHorizontal(child, params, myWidth, myHeight);
measureChild(child, params, myWidth, myHeight);
setMeasuredDimension(width, height);
}
}
假设 A、B、C 都是一个需要测量孩子两次的 ViewGroup，那么如果没有 MeasureCache，当执行 A 的 Measure 时候，将会调用 BBCC，共四次 measure，同样的调用DDEEDDEEFFGGFFGG，共 16 次 measure。但是如果有 measureCache，在 measure 阶段，将会调用 A 的 measure（如果 A 是顶 viewGroup），然后直接设置 B、C 的大小。只调用了 1 次。然后在 layout 阶段，调用一次 B 的 onMeasure、一次 C 的 onMeasure，DEFG 的 onMeasure 各一次。所以只调用了六次。已经足够优化了。
