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

结果如下:

可以看到,draw所耗费的时间几乎一样,布局的优化确实不会影响到子view的onDraw()方法的执行
在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的时间.

最后编辑于：2018.11.03 16:00:58