与其他布局相比,约束布局是否昂贵?
它取决于您的使用情况。
ConstraintLayout 就像类固醇上的 RelativeLayout。
如果你想要一个简单的 2-3 ChildViews 布局,那么使用 ConstraintLayout 不会那么高效。选择线性布局。
“ConstraintLayout 的主要目的是解决 RelativeLayout 的问题,它做得很好。你可以做很多用RelativeLayout。您可以前所未有地简化布局。此外,它还修复了 RelativeLayout 长期存在的性能问题。测量/布局阶段的双重征税 . 所以我们在一个漂亮的包中获得了更好的性能、更多的多功能性和更简单的布局。”
由于性能改进是创建此新布局的主要原因之一,因此我进行了一些性能测试以检查是否满足此目标。
我比较了 RecyclerView 中使用的布局。没什么太花哨的,只是一些嵌套的 LinearLayout 和 RelativeLayout 容器。我手动将此布局移至 ConstraintLayout 并进行了一些相当草率的性能测试。
在模拟器和 Nexus 5 上比较这两者会在使用新的 ConstraintLayout 时产生总体性能损失。
表现最差的是测量。 onMeasure() 方法所用的时间大约是我用于比较的 LinearLayout 方法的十倍。它占用了大部分时间,大约是onLayout() 的 60 倍。因此,与所讨论的 LinearLayout 相比,ConstraintLayout 的 onLayout() 方法的 30% 命中几乎是无关紧要的。最后,与使用 LinearLayout 相比,使用 ConstraintLayout 的布局膨胀花费的时间也更长。
ConstraintLayout 做了很多计算来找出在哪里以及如何显示它的每个子元素。在内部(至少)三个相当长的类正在一起工作以获得结果:LinearSystem、ConstraintWidget 和 ConstraintWidgetContainer。为了完全理解性能行为,我必须深入挖掘这些类的深度(为此,我更喜欢谷歌发布源代码时的注释类)。但是粗略地看一下反编译的代码,看起来这些类需要做很多事情。
一些烦恼
不过,目前并非所有设备都能完美运行。现在最困扰我的是这些:
- 蓝图更改和设计预览之间存在明显滞后
变化
- 预览并不总是正确的
- 蓝图视图不注意文本布局约束
- 约束并不总是按预期工作
- 撤消操作非常不可靠
编辑器以意想不到的方式更新或更改内容
这个post 支持ConstraintLayout。
就我个人而言,当我想对齐超过 3 个视图时,我只使用 ConstraintLayout。它易于使用,但同时一开始很烦人。
tl:dr