最近项目上大规模使用了ConstrainLayout,于是对性能进行一定的分析, 以及介绍一些使用心得。

性能分析

与RelativeLayout对比,基于HierarchyViewer

之前网上也有部分关于ConstrainLayout性能分析的文章,大部分是基于HierarchyViewer的,下面是分析的结果。

使用ConstrainLayout和RelativeLayout分别描述同样的布局,ConstrainLayout的measure时间明显比RelativeLayout的时间长。 基于ConstrainLayout 1.1.2。

随后Google搜下这类问题,发现同样有人遇到:

https://stackoverflow.com/questions/48704493/constraintlayout-onmeasure-very-slow

https://www.reddit.com/r/androiddev/comments/7ylbz3/is_constraintlayout_that_slow/

stackoverflow上ConstrainLayout团队给出了回答,大概是这样:

That’s definitely not expected — I’ll have to investigate more to see what’s causing it. Note that 1.1 beta is right now going to be slower than 1.0, all the optimizer passes aren’t enabled. At first glance there’s a lot of textview with 0dp width, which is pretty costly — like with linear layout, 0dp is going to result in a double measure.

就是说ConstrainLayout 1.1比1.0版本性能要差点。如果在ConstrainLayout中将View宽高指定成’MATCH_PARENT’,或者0dp。那么就会产生Measure两次的开销。

注意,此时有个关键点。ConstraintLayout子View的宽高尽量为具体数值或者WRAP_CONTENT,否则会重复进行测量两次

基于Android Runntime Test

下文同样提供了一种测试方案,我们尝试下。 同样基于ConstrainLayot 1.1.2。 https://medium.com/@krpiotrek/constraintlayout-performance-c1455c7984d7 https://github.com/krpiotrek/ConstraintLayoutPerformanceTest/blob/master/app/src/androidTest/java/com/krpiotrek/constraintlayoutstuff/PerformanceTest.java

测试结果如下:

可以看出ConstraintLayout的测量时间还是最长的。

基于Systrace的measure,layout性能分析

https://android-developers.googleblog.com/2017/08/understanding-performance-benefits-of.html

下面是我的测试数据 这次我们选用两个版本进行测量,看不同版本之间是否有明显的性能差异。

可以看出ConstrainLayout在1.1.X的版本性能确实比较糟糕,比RelativeLayout要差很多,上面几篇文章也印证了这个结论。

使用建议

  • 最好的选择还是FrameLayout和LinearLayout。

  • 如果单层LL,FL无法描述布局,使用单层RelativeLayout不需要嵌套的情况下,直接使用RelativeLayout即可。如果布局比较复杂,可以选用ConstrainLayout,ConstrainLayout在处理BaseLine之类的问题,比上面的布局都要方便。

  • 使用ConstrainLayout需要注意子View的MATCH_PARENT问题,在ConstrainLayout中,子View的MATCH_PARENT等同于0dp,都会造成两次测量。

总结

目前版本和RealtiveLayout性能还是有不小差距,如果你比较在乎性能,还是谨慎使用吧。 期待ConstrainLayout 2.0有更好的表现。

发表评论

电子邮件地址不会被公开。 必填项已用*标注