从 View 绘制谈性能优化

转载请注明出处：http://blog.csdn.net/wl9739/article/details/57416433

在开发过程中，往往会听到 “性能优化” 这个概念，这个概念很大，比如网络性能优化、耗电量优化等等，对我们开发者而言，最容易做的，或者是影响最大的，应该是 View 的性能优化。一般小项目或许用不上 View 性能优化，然而，当业务愈加庞大、界面愈加复杂的时候，没有一个良好的开发习惯和 View 布局优化常识，做出来的界面很容易出现 “卡顿” 现象，从而严重影响用户体验。而对于我们开发者来说，了解一些 View 性能优化的常识，增强开发技巧，可以说是一门必备的功课。

为了更好地理解 View 性能优化的原理，以及造成 “卡顿” 的可能原因，我们从 View 的绘制流程开始讨论。之后，会介绍一些写界面布局常用的一些标签及使用注意事项。

View 绘制流程

我们都知道，View 的绘制分为三个阶段：测量、布局和绘制，这三个阶段各自的作用如下：

• measure: 为整个 View 树计算实际的大小，即设置实际的高（对应属性：mMeasureHeight）和宽（对应属性：mMeasureWidth），每个 View 的控件的实际宽高都是由父视图和本身视图所决定的。
• layout：为将整个根据子视图的大小以及布局参数将 View 树放到合适的位置上。
• draw：利用前两部得到的参数，将视图显示在屏幕上。

当一个 Activity 对象被创建完成之后，会将一个 DecorView 对象添加到 Window 中，同时会创建一个 ViewRootImpl 对象，并将 ViewRootImpl 对象和 DecorView 对象建立联系，然后绘制流程就会从 ViewGroup 的 performTraversals() 方法开始执行，如下图所示：

整个绘制流程从 ViewRootImpl 的 performTraversals() 方法开始，在该方法内会调用 performMeasure() 方法进行测量子 View（也就是根 View，顶级的 ViewGroup）。然后在 performMeasure 中会调用 measure() 方法来执行具体的测量逻辑，这个时候，代码逻辑就从 ViewRootImp 跳转到了 View 类中了：

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);
    }
}

在 measure() 方法中，有一个 onMeasure() 方法，用于这个方法用来测量子元素的大小，也将测量流程从父元素传递到子元素当中去。紧接着子元素会重复父元素的测量流程，如此反复，就完成了一颗 View 树的遍历。当 measure() 方法完成后，会将结果存储在 LongSparseLongArray 类型的变量 mMeasureCache 中。

在 performTraversals() 方法中，调用完 performMeasure()，后，会接着调用 performLayout() 和 performDraw() 进行 View 的布局和绘制。这两个流程和测量的流程差不多，就不再叙述。

而这三个阶段分别作了什么呢？源码太长就不贴了，主要的作用如下：

Measure 过程

• 设置本 View 视图的最终大小。
• 如果该 View 对象是个 ViewGroup 类型，需要重写该 onMeasure() 方法，对其子视图进行遍历 measure() 过程。
  
  • measureChildren()，内部使用了一个 for 循环对子视图进行遍历，分别调用了子视图的 measure() 方法。
  • measureChild()，为指定的子视图 measure，会被 measureChildren 调用。
  • measureChildWidthMargins()，为指定的子视图考虑了 margin 和 padding 的 measure。

Layout 过程

• layout() 方法会设置该 View 视图位于父视图的坐标轴，即 mLeft, mTop, mRight, mBottom.（调用 setFrame() 方法去实现），接下来回调 onLayout() 方法（如果该 View 是 ViewGroup 对象，需要实现该方法，对每个视图进行布局）；
• 如果该 View 是个 ViewGroup 类型，需要遍历每个子视图 childView。调用该子视图的 layout() 方法去设置它的坐标值。

Draw 过程

• 绘制背景
• 如果要视图显示渐变框，这里会做一些准备工作
• 绘制视图本身，即调用 onDraw() 方法。在 view 中，onDraw() 是个空方法，也就是说具体的视图都啊哟覆盖该方法来实现自己的显示（比如 TextView 在这里实现了绘制文字的过程）。而对于 ViewGroup 则不需要实现该方法，因为作为容器是没有内容的，其包含了多个子 View，而子 View 已经实现了自己的绘制方法，因此只需要告诉子 View 绘制自己就行了，也就是下面的 dispatchDraw() 方法。
• 绘制视图，即 dispatchDraw() 方法。在 View 中这是个空方法，具体的视图不需要实现该方法，它是专门为容器类准备的，也就是容器必须实现该方法。
• 如果需要，开始绘制渐变框。
• 绘制滚动条。

因此，如果我们去掉不必要的背景，去掉渐变框，去掉滚动条，在一定程度上是能加快绘制速度的。

优化

帧率（frame per second，即 FPS），指的是每秒刷新的次数。一般电影的帧率为 24FPS、25FPS 和 30FPS。而游戏的帧率一般要保持 60FPS 才能叫做流畅，当游戏的 FPS 低于 30 时，我们就会感受到明显地卡顿。Android 系统每隔 16ms 触发一次 UI 刷新操作，这就要求我们的应用都能在 16ms 内绘制完成。如果有一次的界面绘制用了 22ms，那么，用户在 32ms 内看见的都是同一个界面。情况严重的就会让用户感受到应用运行”卡顿“。

因此，优化的目的，主要就是减少绘制时间，尽量保证每个界面都能在 16ms 内完成绘制。而优化的方案，从上面的分析，我们可以分两个方面：

从内优化

1. 减少 View 层级。这样会加快 View 的循环遍历过程。
2. 去除不必要的背景。由于 在 draw 的步骤中，会单独绘制背景。因此去除不必要的背景会加快 View 的绘制。
3. 尽可能少的使用 margin、padding。在测量和布局的过程中ÿ