for Android Developers

When to Use LinearLayout vs. RelativeLayout


By far the most commonly used ViewGroups in Android are LinearLayout and RelativeLayout. LinearLayout aligns multiple views horizontally or vertically; RelativeLayout aligns its child Views in relation to each other (or itself). There are other, more specialized ViewGroups (such as FrameLayout, TableLayout, or GridView) but the bulk of your hierarchy will be a mixture of LinearLayouts and RelativeLayouts.

They are similar in function so the question of which to use regularly comes up. Both have their use cases, and neither of them are appropriate all of the time. Problems which can be difficult using one layout can be a breeze with the other but it’s not always obvious which is correct.

This article will help guide you towards the right choice of layout for your hierarchies. Here are a few guidelines for usage, which I will go into more detail below:

  • Use whichever layout requires the fewest Views (typically RelativeLayout).
  • Views layered on top of each other is RelativeLayout’s job.
  • Dynamically sizing multiple Views inside of a layout is done with LinearLayout.
  • Keep in mind how your hierarchy will work with different content and screen sizes.
  • All other things equal, LinearLayout is preferable due to its ease of use.

The Fewer Views, the Better

The number one goal for your layouts should be using the fewest number of Views possible. The fewer Views you have to work with, the faster your application will run. Excessive nesting of Views further slows down your application.

A RelativeLayout hierarchy will typically use fewer Views and have a flatter tree than a LinearLayout hierarchy. With LinearLayout, you must create a new LinearLayout every time you want to change the orientation of your views – creating additional Views and a more nested hierarchy. As a result, it is recommended that you first use RelativeLayout for any layout that has any complexity. There is a high probability you will reduce the number of Views – and the depth of your View tree – by doing so.

As a reference, there is an excellent Android article on creating efficient layouts (which goes into more detail about reducing View usage). Here is a simpler version of their example:

Here is an abbreviated version of this layout using LinearLayouts. It requires two LinearLayouts and has a maximum depth of 3 (full source code):

<LinearLayout android:orientation="horizontal">
    <ImageView android:src="@drawable/icon" />
    <LinearLayout android:orientation="vertical">
        <TextView android:text="Title" />
        <TextView android:text="This is some summary text" />

However, this version (using RelativeLayout) can do the same with fewer Views and a max depth of 2 (full source code):

    <ImageView android:id="@+id/icon" />
    <TextView android:id="@+id/title" android:layout_toRightOf="@+id/icon" />
    <TextView android:layout_below="@+id/title" android:layout_toRightOf="@+id/icon" />

That said – don’t try to force yourself to use nothing but RelativeLayout! There are situations where LinearLayout is a better solution, even if it uses a few more Views.

Layer Views with RelativeLayout

Sometimes you will want Views to be overlap each other. In those situations, RelativeLayout is a natural candidate over LinearLayout. There are two ways to align Views on top of each other with RelativeLayout. The first is to align the Views in relation to the parent (either by centering them, or by aligning them to the parent’s edges). The second is to align Views’ edges with each other. The example below uses both:

(Source code)

(Note: While you can technically layer Views with a LinearLayout via negative layout margins, RelativeLayout is almost always the right choice because it is better designed for it.)

Dynamically Weight View Sizes with LinearLayout

LinearLayout has a unique and useful layout parameter, layout_weight. With it you can size the Views inside of a LinearLayout in relation to each other – such as having two Buttons side by side, where one takes up 1/3rd the screen and the other takes up 2/3rds the screen.

(Source code)

RelativeLayout has no such facilities. On some level, its Views must have set bounds – whether it be set in itself, set in relation to other Views, or the parent itself. Its Views can expand and contract, but only in reaction to its bounds changing.

Consider the Extremes

Sometimes the choice of layout will be determined on the extreme circumstances of your hierarchy. “Extreme circumstances” can be anything from the content in your Views being unexpectedly large (lots of text in a TextView, an extra large bitmap in an ImageVIew), or the viewport being much smaller or larger than you had anticipated (an ldpi screen, a tablet, or even just the difference between portrait/landscape orientations).

Let’s look at a simple example – two TextViews, each in one of the corners of the screen. What happens with a naive RelativeLayout solution when the text inside of them becomes too long?

(Source code)

You can account for this problem by making sure they won’t overlap, but you can’t control how much of the width each View gets in this case – say, if we want both to take up at most half of the screen. To do that, you’ll end up using a LinearLayout:

(Source code)

I cannot give much advice since you’ll need to handle these on a case-by-case basis – but it’s something to consider while first planning your hierarchy. You may be surprised by how often you fall back to LinearLayout, though, to solve problems with extremes.

For Simple Hierarchies, Use LinearLayout

LinearLayout is easier to use than RelativeLayout. If your hierarchy is simple enough that it can be contained within a single LinearLayout, then there’s no reason to complicate things – just use LinearLayout. This advice applies whether the LinearLayout is the root view, or if you need to group a few Views further down the hierarchy.


Ultimately, the decision between LinearLayout and RelativeLayout is up to you. The rules above are just rough guidelines. There may be cases which are not covered that necessitate one or the other. Or it may be significantly easier to use a few LinearLayouts instead of one RelativeLayout and performance won’t be significantly affected by it.

You should focus your time on the hierarchies that matter the most. If you’ve only got a few Views on the screen and you could use either RelativeLayout or LinearLayout, take your pick. But if you’re working with a ListView row, you’ll want to reduce your View usage as much as possible for performance.

Good luck with making your hierarchies as effective as possible! If you want to play around with any of the code from this article, you can find the source code for the samples here.


  1. Thank you! That was helpful!

  2. Excellent Post .Thats what i was really looking for.

  3. A very informative article. Thank you.

  4. Thanks for this tutorial. Simple and clean explanation of each use case.

  5. Nice examples

Leave a Reply

Required fields are marked *.