ConstraintLayout性能验证

概述

constarintLayout是16年IO大会引入的约束型布局,具体使用方法不多介绍,参考 官方介绍
虽然拖布局,guidelines,chains使用起来很方便,但是肉眼几乎没法察觉性能上的差异, 这里采用两种方法验证

• 使用HierarchyViewer 查看根布局layout和measure的时间
• 使用7.0提供的FrameMetrics API打印每一帧测量布局耗费的时间

通过HierarchyViewer 验证

我们主要查看的是mesure和layout的时间,首先想到的是上古时代的Hierarchy Viewer, 可惜hierarchyviewer 已经被废弃了（Android SDK Tools Revision 25.3.0 (Feb 2017)）,新方案提供的layoutInspector也只能查看view的层级信息.

想到DDMS里包括hierarchyviewer,可是DDMS也在AS3.0中被Android Profiler替代了, 好在tools目录下保留了启动DDMS的bat文件, 双击tools下的monitor.bat

找到HierarchyViewer

真机上不能查看HierarchyView, 参照这个配置 Android Debug Monitor hierarchy view not showing

结果如下:

1. 可以看到,draw所耗费的时间几乎一样,布局的优化确实不会影响到子view的onDraw()方法的执行
2. 在measure和layout耗费的时间constraint比传统布局要低

左边是传统布局,右边是约束布局

通过FrameMetrics验证

我们使用 Android 7.0（API 级别 24）中引入的 OnFrameMetricsAvailableListener 分析了 ConstraintLayout 和 RelativeLayout 这两种类型的布局所执行的每次测量和布局操作所花费的时间。通过该类，您可以收集有关应用界面渲染的逐帧时间信息。

参照googleSample里的方法, 在asyncTask内执行layout和measure方法,打印出100次执行时 当前帧layout和measure所耗费的时间.

    private val frameMetricsAvailableListener = Window.OnFrameMetricsAvailableListener { _, frameMetrics, _ ->
        val frameMetricsCopy = FrameMetrics(frameMetrics)
        // Layout measure duration in Nano seconds
        val layoutMeasureDurationNs = frameMetricsCopy.getMetric(FrameMetrics.LAYOUT_MEASURE_DURATION)

        total += layoutMeasureDurationNs

        Log.d(TAG, "layoutMeasureDurationNs: " + layoutMeasureDurationNs)
    }

结果如下:

取100帧的平均值, 传统布局耗时1.7ms. 约束布局耗时1.3ms

左边是约束布局,右边是传统布局

结论

层级越是复杂的布局,自上而下遍历测量和布局所花费的时间越多.
constarintLayout确实能一定程度的优化measure和layout的时间.