Is Constraint Layout expensive compared to others?

Question

When I realize ConstraintLayout has:

• better layout drag-drop

• better view relative set-up with better naming "top-toBottomOf"

• better layout construction with ratios and percentage-guidelines

• and much more cant state here or I just didn't know

that I was always wanted to using it constantly because it is so comfortable. 　

Just like the title, I curious about did ConstraintLayout will give big performance impact when using it constantly?

Statement your opinion and evidence will be appreciated.

Editing are welcome if you have good edition/grammar, and down-voting please leave your conclusion below comment. Thanks Dennis for grammar correction.

Answer 1

Are Constraint Layout expensive compared to others?

It Depends upon your usage. A ConstraintLayout is like the RelativeLayouton Steroids.

If you want a simple 2-3 ChildViews layout, then using ConstraintLayout won't be so efficient. Go for Linear Layout.

"The main purpose of the ConstraintLayout is to fix problems with the RelativeLayout, and it does it so well. You can do so many things that were impossible with a RelativeLayout. And you can simplify your layout like you never could before. Additionally, it fixes long-standing performance issues of the RelativeLayout. The double taxation during the measure/layout phase. So we get better performance, more versatility and much simpler layouts in one nice package."

Since performance improvements are among the main reasons to create this new layout, I did some performance tests to check if this goal is met.

I compared a layout used within a RecyclerView. Nothing too fancy, just some nested LinearLayout and RelativeLayout containers. I moved this layout manually over to ConstraintLayout and did some rather sloppy performance tests.

Comparing those two on an emulator as well as on a Nexus 5 yielded overall a performance penalty when using the new ConstraintLayout.

Performing worst is the measurement. The onMeasure() method takes roughly ten times as long as the one of the LinearLayout I used for comparison. And it uses up the bulk of the time with taking about 60 times as long as onLayout(). Thus the 30 percent hit of the onLayout() method of ConstraintLayout compared to the one of the LinearLayout in question is nearly irrelevant. Finally, layout inflation also took longer with ConstraintLayout than with LinearLayout.

The ConstraintLayout does lots of calculations to find out where and how to display each of its children. Internally (at least) three rather lengthy classes are working together to get the results: LinearSystem, ConstraintWidget, and ConstraintWidgetContainer. To fully understand the performance behavior I would have to dig into the depth of these classes (and for this, I prefer the commented classes when their sources are released by Google). But just by having a cursory look at the decompiled code it looks like those classes have to do a lot.

Some annoyances

Not all is working perfectly at the moment, though. Right now these things bother me the most:

• There’s a noticeable lag between blueprint changes and design preview changes
• The preview is not always correct
• The blueprint view doesn’t heed text layout constraints
• Constraints do not always work as expected
• Undo works very unreliably

The editor updos stuff or changes stuff in unexpected ways

This post supports ConstraintLayout.

Personally, I only use ConstraintLayout, when I want to Align more than 3 views. It's easy to use but at the same time, annoying in the beginning.

tl:dr