Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I heard that the Weight setting inside Layout Parameters can dramatically incrase app's performance. So I am going to use it cautiously, or better - completely avoid using it...
What is the best performance way to build Button that fills 2/3 of avalible width and second Button using the rest (1/3 of width)?
and
What is the best performance way to build Button that fills 100dp of avalible width and second Button using the rest?
Yes, I searched it, but didn't find nothing about the performance, really! :)
Thanks in advance!
So I am going to use it cautiously, or better - completely avoid using it...
Get this thought out of your head quickly. layout_weight can be very handy in the right situations. I would definitely not rule out using it completely. As far as cautiously, I'm not sure what your concerns are but if you use it properly then you will be fine.
What is the best performance way to build Button that fills 2/3 of avalible width and second Button using the rest (1/3 of width)?
The main thing to remember when using layout_weight is that your width of child Views should be 0dp with a horizontal LinearLayout and your height 0dp when using a vertical LinearLayout. See below for a short example. Using layout_weight can help keep your layouts looking the same on different screen sizes/resolutions. If you do something like the below code and don't declare a weightSum in your parent LinearLayout then the CPU will calculate it for you. You only need to declare weightSum if you are doing something where you want empty space or maybe other cases but in general it is best to let it be calculated for you.
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"/>
<Button
...
android:layout_width="0dp"
android:layout_height="wrap_content"/>
<Button
...
android:layout_width="0dp"
android:layout_height="wrap_content"/>
</LinearLayout>
What is the best performance way to build Button that fills 100dp of avalible width and second Button using the rest?
Using a LinearLayout you can set the width of your first Button to 100dp and the width of your second Button to match_parent. This will result in your first Button being drawn first and your second Button will use the available width.
You can and should use layout_weight when it makes your XML easier. It won't be a problem unless you are having very deep, nested layouts (which is not the case when simply aligning two buttons).
If you worry about performance, take a look at the hierarchy viewer every now and then and check if your layout trees are not too large. Click on one of the top right buttons that estimates the measure/layout/draw times, and see if there are any red dots. Those layouts are possibly too slow, and might need to be optimised.
In general; layout_weights are not that bad.
About implementing, use layout weights for the first question, and 100dp & fill_parent width for the second ( inside linear).
Related
I am trying to have 3 LinearLayouts ordered horizontally (basically forming three columns) within another LinearLayout where the width of the middle layout can vary depending on it's content.
All columns should be visible at all times filling the viewport from left. The left and irght column will be assigned a max width. So only the size of middle layout varies. If the total width of all columns exceeds the viewport size the middle column must not overlap or push out the other columns. But instead it should use the remaining space.
I tried using layout weights but that would put the right column always on the right side and the middle column would fill up all the space even though it's content would not require that.
When I try to use a RelativeLayout as a container I either end up with all three columns overlapping each other or the first column disappears.
I thought the below code (only schematic for now, as I don't have access to the code atm) should work, but as written above the first LinearLayout does not show up. The last LinearLayout seems to be in place as desired.
<RelativeLayout>
<LinearLayout
android:layout_alignParentStart>
</LinearLayout>
<LinearLayout>
</LinearLayout>
<LinearLayout
android:layout_alignParentEnd>
</LinearLayout>
</RelativeLayout>
Does anyone know how I can fix this? Please let me know if you need more detailed code examples etc. I will try to provide them as soon as possible.
I found a few other questions concerning this or similar topics but the solutions always used either layout weights or something like the code snippet above. So far I had no luck with those approaches, maybe because those questions where either for slightly different use cases or a few years old so that the api has changed in the mean time.
Any pointers are greatly appreciated :-)
Yes. You want to defined the center columns with a layout_width="0dp" and a layout_weight="1". The left and right columns will be layout_width="wrap_content".
A LinearLayout should contain the 3 inner "column" LinearLayouts.
I finally found a solution that works.
Using the layout_weight as describe by Jeffrey Blattman alone does only work when the views get large enough to fill the screen.
But as long as the views only fill a part you get gaps between them as the middle view fills up the remaining space. This is something I want to avoid in this case.
For some other reason I had to put my layout into a fragment. Now when I set the dimensions of the fragment to wrap_content the behavior is exactly as I want it. So the views do not get blown up while they are to small but are laid out as if there was no layout_weight defined. But still when growing larger the edge views stay within the screen.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
someone said people must use relative layout when make android app. Because if use linear layout, app's screen doesn't adjust device screen. (I mean width and height doesn't adjust). But if I use relative layout, it's make me annoyed when I set image. Is opinion which I hear right ?
In my view i would prefer RelativeLayout as parent.
And i go for LinearLayout for all the inner layouts where i can use
android:orientation and android:height as match_parent/fill_parent that will fill only the space available with in LinearLayout.
I never prefer to use dp values for android:height and android:width
I'll go with Relative Layout as we can set different views easily in this layout.
Both have it's own pros and cons. Both can adjust without any problem to device screen. What really matter are the views that you will put inside of them (children) and how they will be organized.
In addition to that, you may want to modify the gravity, margin, padding, alignment or any other to achieve a desired result.
I was just building some UI in xml, and Lint gave me a warning and said to set android:baselineAligned to false to improve performance in ListView.
The docs for the Lint changes that added this warning say
Layout performance: Finds LinearLayouts with weights where you should
set android:baselineAligned="false" for better performance, and also
finds cases where you have nested weights which can cause performance
problems.
Can somebody explain why this improves performance, specifically when weight is involved?
By setting android:baselineAligned="false" , you're preventing the extra work your app's layout has to do in order to Align its children's baselines; which can obviously increase the performance. (Fewer unnecessary operations on UI => Better performance)
how android:baselineAligned="false" help . It may not be the answer but help to get concept.
I've just managed to get 3 items (icon, text, button) centered
vertically in horizontal LinearLayout.
This may seem simple, but in reality specifying
android:gravity="center_vertical" as LinearLayout attribute is not
enough - icon is centered, but text and button are not. This is
because (presumably) text have a baseline, and centering algorithm
uses it instead of 'real' vertical center. But what is worse - button
(which comes next to text) is centered using text's baseline!
Specifying android:baselineAligned="false" in LinearLayout turns this
off, and everything centers correctly.
// Baseline alignment requires to measure widgets to obtain the
// baseline offset (in particular for TextViews). The following
// defeats the optimization mentioned above. Allow the child to
// use as much space as it wants because we can shrink things
// later (and re-measure).
if (baselineAligned) {
final int freeSpec = MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED);
child.measure(freeSpec, freeSpec);
}
https://github.com/android/platform_frameworks_base/blob/master/core/java/android/widget/LinearLayout.java#L1093
I'm trying to divide a page in three parts. I'd like to do it in percentage values, however that is not supported by Android. Instead I have to use android:layout_weight. But I have a hard time understanding it and getting it right. Especially how the actual size gets calculated. Is there a way to get a percentage value (0..100%) out of android:layout_weight?
I went through a few cases (see attached screenshot) to describe the problems. The colored fields are all <LinearLayout> with android:layout_height="fill_parent", because I want the full screen to be divided between those.
Case 1
Okay, simple. Every <LinearLayout> gets 33%.
Case 2
Ups?! The first (yellow) <LinearLayout> disappears completely? Why?
Case 3
Confused again. The yellow <LinearLayout> is back. However, the two first <LinearLayout> with the heavier weight get smaller? What is going on?
Case 4
I have absolutely no idea what the maths behind all this is.
Is there a way to get a percentage value (0..100%) out of android:layout_weight?
Sure. Make them add up to 100.
For your "percentage value", you want the android:layout_height of the individual items within the LinearLayout to be 0px.
When you use android:layout_height="fill_parent" for the bars, you are not leaving any available space. (Since they are filling the parent.) Because all 3 are set to fill, the requested height is actually 3x the parent height, so the weights are being applied to a negative remaining space. This explains the weird behavior you are seeing, and why setting layout_height to 0px solves it.
I need to have a linear Layout whose height is wrap_content,
but how can I specify a child of this linear layout to stretch to its parent?
I tried
... some other children ...
But this does not work. The image does not scretch.
wrap_content will stretch it to however big the content inside it is.
fill_parent will stretch it to the size of the parent container.
I would try fill_parent for the child.
android:layout_width="fill_parent"
android:layout_height="fill_parent"
This should fill the parent with the child.
If you have multiple children within the parent and wish to leave no free space in the parent you should use
http://developer.android.com/reference/android/widget/LinearLayout.LayoutParams.html#weight
android:layout_weight" is the factor
the view will be stretched, when the
parent is larger than its childs in
sum.
well i think this would not make so much sense.(i don't mean anything rude)
Your child layout can not stretch out to the parent's size because the size of the parent layout is only as big/small as your child class could- attempting to wrap around however big/small the child could get. Therefore, it's just basically like two people who can't decide who should decide. The other waits for the other's decision, and vice versa. Those layouts are dependent on each other's size, when the problem is there is not an established size to relate to then move on. You could maybe, reconsider your logic dude. ^^ I got so confused that by formulating an answer i got lost in confusion myself.
I hope this helps. This might help beginners in the future. This seems to be a fairly old question left unanswered.