I don't think I have really ever nested more than about three levels worth of Layouts (RelativeLayout, LinearLayout, FrameLayout) in Android. I am not thinking about list items which also use a custom layout for ListView but just normal layouts for an activity.
To the point though, I was chatting with another developer about nesting layouts for a certain layout we were discussing and he seemed to think that even a few nested layouts really slowed down performance. I figured there is some truth but it cant be that much.
Does anyone have a more expert approach to this? Any input? Opinion?
Thanks.
UPDATE for those who found on Google:
The first answer below is a great resource. It looks like a lot and people seem to skip over answers like that but please check it out. Very valuable.
I guess there is no silver bullet for this but I will give you some tips:
1) Try using the tools provided with the android sdk.
I tend to analyze my layouts with hierarchyviewer and layoutopt trying to reduce the amount of View used and the height of the tree.
2) Read Romain Guy's posts about <include>, <merge> and <ViewStub>
These tags are not used often but they provide great speed "hacks".
http://www.curious-creature.org/2009/03/01/android-layout-tricks-3-optimize-part-1/
http://www.curious-creature.org/2009/03/16/android-layout-tricks-4-optimize-part-2/
3) Use dmtracedump and measure how long does it take to inflate a view.
You can check how long it takes to inflate a view. Get an inflater and measure how long it takes to inflate each of your options.
I havent done any proper testing to support this, still, I believe that android was design to use nesting Layouts in order to provide adequate UI's to the user, its practically the only way to support multiple screens so I wouldn't really worry about which is the most efficient, just that it looks the way it should.
Any other kind of bad programming practice would probably have a bigger effect in efficiency than layout nesting.
The difference will be much more important when you use such a layout for every item in a ListView for instance. Hopefully this simple example showed you that getting to know your layouts is the best way to learn how to optimize your UI.
Can't give you a full answer, but Romain Guy has specifically stated that nested RelativeLayouts have an exponential time for measurement.
See video here at 38:08 mark
actually all of them are based on the same class..
but it would be better to use according to me as follows:
<RelativeLayout>
<LinearLayout>
<at> here we just create nested more as we wont></at>
</LinearLayout>
</RelativeLayout>
Related
I totally understand the advantage of having ConstraintLayout when flatenning nested UI's. But with the introduction of ConstraintLayout I see people adopting it instead of RelativeLayout even for simple layouts with a flat structure.
Does ConstraintLayout always performs better than RelativeLayout?
Specifically in the case when a view can be achieved with single flat
structure with no nested UI?
If yes, shouldn't Relative Layout be deprecated?
Any help would be much appreciated :)
I think that should be a matter of choice and customs. Some UI designers prefer RelativeLayout where others prefer ConstraintLayout. The ConstraintLayout can be used in many cases more than the RelativeLayout. And yes it performs better than the RelativeLayout but I think for just a single flat structure I can opt for RelativeLayout too though due to support tooling provided by the ConstraintLayout it makes it a better option if you need that feature.
That's my point of view.
Yes, it performs better, ConstraintLayout has designed with performance optimization in mind. Also, it's very straightforward to use by just drag and drop things.
I really like Constraint layout to develop complex layout faster than any other one, but in my opinion, it's harder to make changes on it when you need, but is just my point of view
Q1 - Does ConstraintLayout always performs better than RelativeLayout
A1 - I saw a lot of questions and answers on StackOverflow about that subject and here is what I can say base on those threads and my personal experience with ConstraintLayout :
In most cases, if you are using ConstraintLayout properly it will work faster but , there is no guaranty that this is what you will get all the time.
From my personal experience with ConstraintLayout, it is working really fast and in all of my layouts (both simple and complicated in terms of UI) it works faster than RelativeLayout.
Q2 - shouldn't Relative Layout be deprecated
A2 - Why I believe that Relative Layout should not be deprecated.
I honestly don't see any valid reason for RelativeLayout to be deprecated, altho I am using ConstaintLayout I first started with RelativeLayout and now I see it as another tool to build my UI.
If it's not broken don't fix it:
Don't forget that there are a lot of developers around the globe, some prefer
RelativeLayout and some prefer ConstraintLayout, let's keep it this way is what I believe - don't take the option to choose from the developers, give them the option to choose what to use.
ConstraintLayout is not a better solution for building UI as a fact, its just my opinion.
I really think that its something that depends on the developer and his decisions, therefore - no layout is better than the other and no layout should be deprecated (as long as it works)
I have been searching this on net and found various answers to this question.
I have been very confused to understand what is the best and standard way to create layouts in android.
Either,
Create a Parent Relative layout and put all items in the same
Layout.
Or
Create different relative or linear layout for each item, and a Parent layout that covers all the elements and child layouts.
Kindly guide me which one is the best and industry standard way.
Thanks
There isn't a standard way. All widgets are tools you can use for your convenience. However, be aware of performance when designing your layouts.
Maybe there is a golden rule:
The rule when constructing Android layouts is to make the layout shallow and wide rather than narrow and deep.
Please, read carefully this and this. Both tell us how to make fast Android layouts.
What is the use of <Space /> in andorid ui, how is it any different from an empty linearlayout.
Is there any special use of <Space> in android ?
From the docs:
Space is a lightweight View subclass that may be used to create gaps between components in general purpose layouts.
Yes it is different than a LinearLayout in that it cannot do all (any) of the things that a LinearLayout can do. It's purpose is solely to add a gap between some things. By taking out all of the LinearLayout functionality it makes the view "lighter" which will mean less resource intensive.
Space is used to define empty spaces (or gaps) inside a layout.
It was introduced in API level 14 alongside GridLayout.
To get a feel of what it's all about, check out this tutorial.
It’s often possible to take a complicated layout and break it down into a set of nested linear layouts and, provided this nesting doesn’t get too deep, this is still a good choice for many simple layouts.
For use in hierarchies that are too deep and there are performance problems, is a lightweight View subclass. The keyword being 'lightweight'.
I have a short question according to creating GUIs in android. What way is better xml or coding?
I always read that xml is way better but imagine you have a scrollview.
Inside the scrollview is a relativelayout. Inside that there shall be several rows with an ImageView next to a TextView next to a RadioButton. The number of rows can vary.
Is it really better to make lets say 50 Views in the xml or a loop in code where these views are created?
Each has its pros and cons. Just to name a few:
XML
pros -> fast GUI development, keep code clean
cons -> static
Dynamic (code)
pros -> able to react to runtime conditions
cons -> more code, which means poorer maintainability and potentially buggier
If you need to add components dynamically, only way is go with code (or) mixed approach (define layout in XML and add components in code). If your components are static XML may be best.
Dynamic content is, of course, added dynamically. So your example would require some java code. You should only add the dynamic part programmatically though, so you'd still use an xml document for the static parts (it's very unusual for a layout to be completely dynamic).
If you have a fixed number of views then yes, I'd write 50 of them in xml rather than with a loop. I guess you're wondering about code duplication and, as far as I know, you'll get some when using xml.
(One way to minimize code duplication within xmls' is with the usage of styles and themes)
I agree with the above. XML is a better approach to this even when you require dynamic updates you can still use XML bits and pieces to render the content. your code will be based on XML elements but XML files will be independent. hence if you break a funcitonality in the code you know that its your business logic thats broken not the UI part, which will make it easier to develop and find problems easily.
Why you do not use a ListView instead of a ScrollView.
It will be simplier to implement and performances must be better with it.
Create a XML file with a ListView and in your activity implements your own adapter to instanciate the rows.
You can find a lot of tutorials on internet talking about that, I'm sure you will find what you need !
Good luck.
Does it (and in what way) effect performance to have a complex Layout hierarchy?
In what way does it affect an application to have deeply nested layouts (e.g. RealitiveLayout which contains many LinearLayouts which each contain....)
It has an effect, the simpler the better is the rule.
Every view — or worse, every layout manager — that you add to your
application comes at a cost: initialization, layout and drawing become
slower. The layout pass can be especially expensive when you nest
several LinearLayout that use the weight parameter, which requires the
child to be measured twice.
From: http://android-developers.blogspot.com/2009/02/android-layout-tricks-1.html
You can use hierarchyviewer to gauge the performance of your layout hierarchy. For more details see http://developer.android.com/guide/developing/debugging/debugging-ui.html
Yes it does and more than 3 levels are supposedly not recommended. That is one reason why the new GridLayout was created. Also the lint and hierarchyviewer tools in the SDK will help you optimizing your layouts.
However depending on your needs you might have to nest deeper. Just use the SDK tools and some devices with hands on testing to see if your performance bottlenecks are with the rendering. Most likely they are somewhere else in your code..
One of the main performance slogs with regards to views is not the rendering but inflating them from xml files..