Differences between ConstraintLayout and RelativeLayout

Question

I am confused about the difference between ConstraintLayout and RelativeLayout. Could someone please tell me the exact differences between them?

Solution 1

The intention of ConstraintLayout is to optimize and flatten the view hierarchy of your layouts by applying some rules to each view to avoid nesting.

The Rules are similar to RelativeLayout, for example setting the bottom edge to the bottom of some other view.

app:layout_constraintBottom_toBottomOf="@+id/view1"

Unlike RelativeLayout, ConstraintLayout offers a bias value that is used to position a view in terms of 0% and 100% horizontal and vertical offset relative to the handles (marked with a red circle). These percentages (and fractions) offer seamless positioning of the view across different screen densities and sizes.

app:layout_constraintHorizontal_bias="0.33" <!-- from 0.0 to 1.0 -->
app:layout_constraintVertical_bias="0.53" <!-- from 0.0 to 1.0 -->

The Baseline handle (a long pipe with rounded corners, below the circle handle) is used to align the content of the view with another view reference.

Square handles (on each corner of the view) are used to resize the view in dps.

This is totally opinion based and my impression of ConstraintLayout

Solution 2

Relative Layout and Constraint Layout equivalent properties

(1) Relative Layout:

android:layout_centerInParent="true"    

(1) Constraint Layout equivalent :

app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintTop_toTopOf="parent"

---

(2) Relative Layout:

android:layout_centerHorizontal="true"

(2) Constraint Layout equivalent:

app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintEnd_toEndOf="parent"

---

(3) Relative Layout:

android:layout_centerVertical="true"    

(3) Constraint Layout equivalent:

app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintTop_toTopOf="parent"

---

(4) Relative Layout:

android:layout_alignParentLeft="true"   

(4) Constraint Layout equivalent:

app:layout_constraintLeft_toLeftOf="parent"

---

(5) Relative Layout:

android:layout_alignParentStart="true"

(5) Constraint Layout equivalent:

app:layout_constraintStart_toStartOf="parent"

---

(6) Relative Layout:

android:layout_alignParentRight="true"

(6) Constraint Layout equivalent:

app:layout_constraintRight_toRightOf="parent"

---

(7) Relative Layout:

android:layout_alignParentEnd="true"    

(7) Constraint Layout equivalent:

app:layout_constraintEnd_toEndOf="parent"

---

(8) Relative Layout:

android:layout_alignParentTop="true"

(8) Constraint Layout equivalent:

app:layout_constraintTop_toTopOf="parent"

---

(9) Relative Layout:

android:layout_alignParentBottom="true" 

(9) Constraint Layout equivalent:

app:layout_constraintBottom_toBottomOf="parent"

---

(10) Relative Layout:

android:layout_alignStart="@id/view"

(10) Constraint Layout equivalent:

app:layout_constraintStart_toStartOf="@id/view"

---

(11) Relative Layout:

android:layout_alignLeft="@id/view" 

(11) Constraint Layout equivalent:

app:layout_constraintLeft_toLeftOf="@id/view"

---

(12) Relative Layout:

android:layout_alignEnd="@id/view"  

(12) Constraint Layout equivalent:

app:layout_constraintEnd_toEndOf="@id/view"

---

(13) Relative Layout:

android:layout_alignRight="@id/view"

(13) Constraint Layout equivalent:

app:layout_constraintRight_toRightOf="@id/view"

---

(14) Relative Layout:

android:layout_alignTop="@id/view"  

(14) Constraint Layout equivalent:

app:layout_constraintTop_toTopOf="@id/view"

---

(15) Relative Layout:

android:layout_alignBaseline="@id/view" 

(15) Constraint Layout equivalent:

app:layout_constraintBaseline_toBaselineOf="@id/view"

---

(16) Relative Layout:

android:layout_alignBottom="@id/view"

(16) Constraint Layout equivalent:

app:layout_constraintBottom_toBottomOf="@id/view"

---

(17) Relative Layout:

android:layout_toStartOf="@id/view"

(17) Constraint Layout equivalent:

app:layout_constraintEnd_toStartOf="@id/view"

---

(18) Relative Layout:

android:layout_toLeftOf="@id/view"  

(18) Constraint Layout equivalent:

app:layout_constraintRight_toLeftOf="@id/view"

---

(19) Relative Layout:

android:layout_toEndOf="@id/view"

(19) Constraint Layout equivalent:

app:layout_constraintStart_toEndOf="@id/view"

---

(20) Relative Layout:

android:layout_toRightOf="@id/view"

(20) Constraint Layout equivalent:

app:layout_constraintLeft_toRightOf="@id/view"

---

(21) Relative Layout:

android:layout_above="@id/view" 

(21) Constraint Layout equivalent:

app:layout_constraintBottom_toTopOf="@id/view"

---

(22) Relative Layout:

android:layout_below="@id/view" 

(22) Constraint Layout equivalent:

app:layout_constraintTop_toBottomOf="@id/view"

---

Solution 3

Reported by @davidpbr ConstraintLayout performance

I made two similar 7-child layouts, one each with a parent ConstraintLayout and RelativeLayout. Based on Android Studio method tracing tool, it appears the ConstraintLayout spends more time in onMeasure and performs additional work in onFinishInflate.

Library used (support-v4, appcompat-v7…):

com.android.support.constraint:constraint-layout:1.0.0-alpha1

Devices/Android versions reproduced on: Samsung Galaxy S6 (SM-G920A. Sorry, no Nexus atm). Android 5.0.2

Quick method tracing comparison:

Sample Github repo: https://github.com/OnlyInAmerica/ConstraintLayoutPerf

Solution 4

Following are the differences/advantages:

1. Constraint Layout has dual power of both Relative Layout as well as Linear layout: Set relative positions of views ( like Relative layout ) and also set weights for dynamic UI (which was only possible in Linear Layout).

2. A very powerful use is grouping of elements by forming a chain. This way we can form a group of views which as a whole can be placed in a desired way without adding another layer of hierarchy just to form another group of views.

3. In addition to weights, we can apply horizontal and vertical bias which is nothing but the percentage of displacement from the centre. ( bias of 0.5 means centrally aligned. Any value less or more means corresponding movement in the respective direction ) .

4. Another very important feature is that it respects and provides the functionality to handle the GONE views so that layouts do not break if some view is set to GONE through java code. More can be found here: https://developer.android.com/reference/android/support/constraint/ConstraintLayout.html#VisibilityBehavior

5. Provides power of automatic constraint applying by the use of Blue print and Visual Editor tool which makes it easy to design a page.

All these features lead to flattening of the view hierarchy which improves performance and also helps in making responsive and dynamic UI which can more easily adapt to different screen size and density.

Here is the best place to learn quickly: https://codelabs.developers.google.com/codelabs/constraint-layout/#0

Solution 5

A big difference is that ConstraintLayout respects constraints even if the view is gone. So it won't break the layout if you have a chain and you want to make a view disappear in the middle.

View more solutions

Comments

[CopsOnRoad]

ConstraintLayout is mainly designed for the new programmers so that they can easily design the layout using the Visual Editor instead of building the layout with hand via XML.

[Moses Aprico]

@Jack definitely it also has deeper purpose for seasoned-expert devs

[CopsOnRoad]

@MosesAprico you are right it does have that. But I think seasoned expert devs already have lot of other ways (they already know like RealtiveLayout, LinearLayout, GridLayout etc.) to get the view hierarchy they want.

[Nick Turner]

@CopsOnRoad Actually you're wrong. Apple has been doing constraint layouts for 5+ years. You get responsive design to any size and don't have to write a ton of complex layouts. When you starting binding multiple views you only need 3 basic controls to create fully responsive design.

[Oleksandr]

from the same issue: I'm going to close this for now -- alpha 4/5 brought quite a bit of performance improvement. We'll probably be able to improve it more, but that might wait post 1.0.

[Nativ]

Can you please explain in which tool you used in order to create this great comparison?

[Andrey T]

@Nativ Monotirs->CPU->Time tracker icon

[Andrey T]

Run and profiled same code on with constraint-layout:1.0.1 on Nexus 5 with android 6.0.1, here results: Relative layout - init 2ms on Measure 30ms + 16ms = 62ms on Layouyt 7ms = 9ms total 54 ms Constraint Layout - init 7ms Constraint Layout generate layout params + add view ~ 7*2ms = 14ms On Measure 60ms + 52ms ~ 112ms On Layout 8ms total ~ 141ms First initialization of Relative layout almost three times faster than Constraint.

[Admin]

can you give me any example? let suppose 3 buttons are there. I will hide the 2nd button and the 3rd button is attach to 2nd button with the id as btn2. Suppose I hide 2nd button then how 3rd button could find the 2nd button's id?

[Admin]

We can still create flatten layout using RelativeLayout that's why I'm confused where ConstraintLayout take care where RelativeLayout can't?

[zapotec]

That's not true. If you set the visibility of a Button as "INVISIBLE" instead of "GONE" you won't break the constraints. As for me, the biggest different as @Nikola said is the bias which helps you create more "Responsive" views.

[Herrbert74]

@Nothing Let's suppose that the buttons are under each other. Even if you hide tButton 2, it's still there in the "view contract", either in your xml or code. ConstraintLayout will respect it and Button 3 will be under Button 1. In a RelativeLayout Button 2 is gone, the contraint is gone with it, so Button 3 will be in the default position, so top left of the screen.

[Herrbert74]

@zapotec I respect that other stuff is more important to you, but for me this is a really cool difference. Fixes the only thing I hated in RelativeLayout. Using invisible is not an option, because it will claim the space.

[Christopher Perry]

RelativeLayout is a two-pass layout, suffering from double taxation. It must measure/layout at least twice. ConstraintLayout doesn't suffer this performance penalty.

[Eugene Brusov]

@Nothing Yep, we can still create flatten layout using RelativeLayout. But in addition to everyone mentioned here, ConstraintLayout lets you use negative margins and size subviews in predefined ratio. Last one is the most robust way to keep 16:9 ratio for your ImageView in CardView in accordance with Material design

[Gak2]

There are some layouts that are impossible in RelativeLayout unless you nest a LinearLayout or another RelativeLayout. For example: centering a "stack" of 3 Views vertically relative to another View

[Eugene Brusov]

6) ConstraintLayout makes it possible to size subviews in pre-defined ratios medium.com/google-developers/…. It'd useful for example when you're going to keep your ImageView in 16:9.

[Jakub S.]

We need to make this test again. When Constraint it not in Alpha.

[Rajesh Nasit]

Is there any proof it faster?

[Tatarize]

Yes. It's faster. The layout is down in a single solver rather than iterating through a tree. For most things it won't matter because it's done at the call to the layout. But, the view tree thing while easy, creates a bunch of views inside views which requires calls requiring calls. While it's nicer theoretically, in practice performing the layout in one bit of code is far easier than to iterate through the entire view tree. It would get more impressive with more views but here's a benchmark from May: medium.com/@krpiotrek/constraintlayout-performance-c1455c798‌​4d7

[serv-inc]

@JacktheRipper: Google says Constraint is faster. See stackoverflow.com/a/47289870/1587329

[The incredible Jan]

@Gak2 I can't see anything impossible in your example without a nested layout. Maybe you mean something else with "stack" than I do. I just use "layout_alignEnd", "layout_below", "layout_..." and can build any kind of stack with it...

[yehyatt]

View > Tool Windows > Android Profiler in Android 3.0 and later

[codepeaker]

Constraint Layout is introduced so that the nested view hierarchy can be reduced. So, Less hierarchy means less time to traverse from top to down in the view tree. So, What's the Point to make a nested view hierarchy that may not be needed in Constraint layout and comparing it with Relative Layout in which you have more chances to end up with nested structure?

[Vijayadhas Chandrasekaran]

Can you post as text instead of image? So that it will be very useful to me and also others in future.

[grantespo]

Everybody beginning to learn Constraint Layouts needs to see this. Thanks.

[Yonatan Nir]

It seems like you can use ConstraintLayout for pretty much everything without the need for anything else?

[Sreekanth Karumanaghat]

I am facing another question, should I replace all existing Relativelayouts in the app I am working on? Will it significantly improve performance?

[Tatarize]

@SreekanthKarumanaghat it seems like you'd never make back the time it takes to replace those back in the time switching would save you. We're talking 3.5ms cycles dropping to 3.25ms in most cases. If it gives you an extra feature or something you need then sure, but purely on speed grounds nah. Though we are talking hitting a convert button.

[YetAnotherRandomUser]

This is valuable information, but does not answer the question. Nor does it even address the question.

[YetAnotherRandomUser]

This is useful information, but is simply a documentation dump and doesn't do anything to explain the difference between them.

[CodeToLife]

No, I dont have time to look in docs, this is certainly useful. And written in simple language. Upvoting.

[Andrew S]

In 2022 are relative layouts still important with significant unique advantages?