Why Are Nested Weights Bad For Performance? Alternatives

Why are nested weights bad for performance? Alternatives?

Nested weights are bad for performance because:

Layout weights require a widget to be measured twice. When a
LinearLayout with non-zero weights is nested inside another
LinearLayout with non-zero weights, then the number of measurements
increase exponentially.

It's better to use RelativeLayouts and adjust your view according to the places of other views without using specific dpi values.

Nested weights are bad for performance in my XML code

You can only ignore this warning if you want to keep this layout.

Add to the root of your layout: xmlns:tools="http://schemas.android.com/tools". Then in your buttons add tools:ignore="NestedWeights".

This can be also done in eclipse by putting the cursor on the yellow line and pressing ctrl + 1. You can choose ignore.


If you want to improve performance, you can use a TableLayout

<?xml version="1.0" encoding="utf-8"?>
<TableLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/tableLayout1"
android:layout_width="fill_parent"
android:layout_height="fill_parent" >
<TableRow
android:id="@+id/tableRow1"
android:layout_weight="1"
android:layout_width="wrap_content"
android:layout_height="0dp"
android:padding="5dip" >

<Button
android:layout_width="0dip"
android:layout_height="fill_parent"
android:layout_weight="1"
android:text="A" />

<Button
android:layout_width="0dip"
android:layout_height="fill_parent"
android:layout_marginTop="10dp"
android:layout_weight="1"
android:text="B" />
</TableRow>
<TableRow
android:id="@+id/tableRow2"
android:layout_weight="1"
android:layout_width="wrap_content"
android:layout_height="0dp"
android:padding="5dip" >
<Button
android:layout_width="0dip"
android:layout_height="fill_parent"
android:layout_marginTop="10dp"
android:layout_weight="1"
android:text="C" />

<Button
android:layout_width="0dip"
android:layout_height="fill_parent"
android:layout_marginTop="10dp"
android:layout_weight="1"
android:text="D" />
</TableRow>
</TableLayout>

Nested weights warning

For better approach i posted the code below using ConstraintLayout

For your approach here is the solution
Remove from layouts android:layout_weight="1"

You should have reformat your code in the following order.

  1. LinearLayout (root) orientation vertical (containing 2 other LinearLayouts)
  2. LinearLayout (top, inside root) orientation horizontal ( with button weights to 1)
  3. LinearLayout (bottom,inside root) orientation horizontal( with button weights to 1)

Better approach would be Using ConstraintLayout

Sample Image

<?xml version="1.0" encoding="utf-8"?>
<android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent" android:layout_height="match_parent">

<Button
android:id="@+id/button2"
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_marginStart="8dp"
android:layout_marginEnd="8dp"
android:layout_marginBottom="8dp"
android:text="1"
app:layout_constraintBottom_toTopOf="@+id/button4"
app:layout_constraintEnd_toStartOf="@+id/button3"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent" />

<Button
android:id="@+id/button5"
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_marginStart="8dp"
android:layout_marginTop="8dp"
android:layout_marginEnd="8dp"
android:layout_marginBottom="8dp"
android:text="4"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toEndOf="@+id/button4"
app:layout_constraintTop_toBottomOf="@+id/button3" />

<Button
android:id="@+id/button4"
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_marginStart="8dp"
android:layout_marginTop="8dp"
android:layout_marginEnd="8dp"
android:layout_marginBottom="8dp"
android:text="3"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toStartOf="@+id/button5"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toBottomOf="@+id/button2" />

<Button
android:id="@+id/button3"
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_marginStart="8dp"
android:layout_marginTop="8dp"
android:layout_marginEnd="8dp"
android:layout_marginBottom="8dp"
android:text="2"
app:layout_constraintBottom_toTopOf="@+id/button5"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toEndOf="@+id/button2"
app:layout_constraintTop_toTopOf="parent" />

</android.support.constraint.ConstraintLayout>

Android layout with error Nested weights are bad for perfomance

The layout_weight attribute is another way of specifying a width or a height in percentage dimensions, and to optimize the calculation of the dimensions you should use 0dp to one of them (the one you are replacing with).

Another optimize tip is to remove the <RelativeLayout></RelativeLayout> that is not being used in your layout.

Please try the solution below:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical" >

<LinearLayout
android:layout_width="match_parent"
android:layout_height="0dp"
android:layout_weight="0.80"
android:orientation="horizontal" >

<ImageView
android:layout_width="0dp"
android:layout_height="match_parent"
android:layout_weight="0.50"
android:padding="10dp" />

<LinearLayout
android:layout_width="0dp"
android:layout_height="match_parent"
android:layout_weight="0.50"
android:orientation="vertical" >
</LinearLayout>
</LinearLayout>

<LinearLayout
android:layout_width="match_parent"
android:layout_height="0dp"
android:layout_weight="0.20"
android:orientation="vertical" >
</LinearLayout>

</LinearLayout>

Layout Weight warning Nested weight bad performance

Nested weights are bad for performance because:

Layout weights require a widget to be measured twice. When a LinearLayout with non-zero weights is nested inside another LinearLayout with non-zero weights, then the number of measurements increase exponentially.

It's always better to use RelativeLayouts and adjust your view according to the places of other views without using specific dpi values.

courtesy: Why are nested weights bad for performance? Alternatives?

Why is Android lint showing nested weights are bad for performance when none are nested?

The TextView and ImageView in your @string/HOMEPAGE_CONTENT area are nested in their parent LinearLayout and have weights assigned. I suspect those are your problem, especially since the parent is wrap_content, so theoretically there shouldn't be any space for the child elements to stretch into.

Nested layout_weight bad for performance: Why do I get Lint warning when I set layout_width value to 0dp?

It's a warning, in this case you should be OK, it's more to keep you from abusing a lot of nested weights and bogging down your app. The other option is to get the screen size at run time and set the width of the Frame Layouts manually.

Nesting Linear Layouts with Weights, Why Considered Bad?

So what makes this such a bad idea?

It's not a bad idea. It is not free, either.

In particular, your scenario is fairly simple, despite your protestations to the contrary. While your layout is rather complex, it is rendered once. Hence, while you may drop a few frames while rendering it, that price is paid one time (or, more accurately, one time per activity/fragment that is using this layout).

Where per-layout expense becomes a much bigger problem is when it is magnified by having several of them that get animated around, such as rows in a ListView/RecyclerView, or pages in a ViewPager. Now, we are going through lots and lots of rendering passes, as the user swipes and causes us to redraw our content. Each individual row in the list might be significantly simpler than your layout, but we're also going to be trying to draw those many times per second. And, while a couple of dropped frames may not be noticeable in your case, dropped frames during animation is pretty much the definition of "jank" for an Android UI.

So long as you have no jank -- IOW, you are not dropping any frames, as reported by Choreographer in LogCat or as seen in the gfxinfo overlay through Developer Options -- then your layout is fine, at least as far as I and probably most users are concerned. Conversely, if you are dropping frames, trying to figure out more efficient layouts, perhaps even custom ViewGroups rather than general-purpose ones, may help alleviate that jank.

Alternative to nested weights with LinearLayouts

Yes we have the alternative for nested LinearLayout weight by android's percent support library

Code and concept HERE !

GitHub Project HERE !

Consider this simple layout where I have totally avoided weight property of LinearLayout

Percent support library

<android.support.percent.PercentRelativeLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent"
android:layout_height="match_parent">
<TextView
android:id="@+id/fifty_huntv"
android:layout_width="0dp"
android:layout_height="0dp"
android:background="#ff7acfff"
android:text="20% - 50%"
android:textColor="@android:color/white"
app:layout_heightPercent="20%"
app:layout_widthPercent="50%" />
<TextView
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_toRightOf="@id/fifty_huntv"
android:background="#ffff5566"
android:text="80%-50%"
app:layout_heightPercent="80%"
app:layout_widthPercent="50%"
/>

</android.support.percent.PercentRelativeLayout>

Really awesome !!!

Nested linear-layout weights is it bad for one vertical and one horizontal

In my experience, unless you have a lot of weighted components, the actual performance hit is negligible.

However, it shouldn't matter which way they're oriented. When a view is sized, it will remeasure each child in both directions. There's only a method to measure, which does both width and height at the same time.



Related Topics



Leave a reply



Submit