I've always been using RelativeLayout everytime I needed a View container, because of it's flexibility, even if I just wanted to display something really simple.
Is it ok to do so, or should I try using a LinearLayout when I can, from a performance/good practices standpoint?
Thanks!
In a talk at Google I/O 2013 (Writing Custom Views for Android), Romain Guy clarified the misunderstanding that caused everyone to start using RelativeLayouts for everything. A RelativeLayout always has to do two measure passes. Overall it is negligible as long as your view hierarchy is simple. But if your hierarchy is complex, doing an extra measure pass could potentially be fairly costly. Also if you nest RelativeLayouts, you get an exponential measurement algorithm.
https://www.youtube.com/watch?v=NYtB6mlu7vA&t=1m41s
https://www.youtube.com/watch?v=NYtB6mlu7vA&t=38m04s
Unless you're laying out lots of Views (e.g. in a ListView), the performance of choosing between LinearLayout or RelativeLayout is negligible. Pick whichever is most convenient to use for the job, and worry about performance only when you need to.
And here's what the official docs about Creating Efficient Layouts says about performance of RelativeLayout and LinearLayout:
Sticking to the basic features is
unfortunately not the most efficient
way to create user interfaces. A
common example is the abuse of
LinearLayout, which leads to a
proliferation of views in the view
hierarchy. 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.
Relativelayout is more effective than Linearlayout.
From here:
It is a common misconception that using the basic layout structures leads to the most efficient layouts. However, each widget and layout you add to your application requires initialization, layout, and drawing. For example, using nested instances of LinearLayout can lead to an excessively deep view hierarchy. Furthermore, nesting several instances of LinearLayout that use the layout_weight parameter can be especially expensive as each child needs to be measured twice. This is particularly important when the layout is inflated repeatedly, such as when used in a ListView or GridView.
2018 UPDATE: In the N release of Android, the ConstraintLayout class provides similar functionality to RelativeLayout, but at a significantly lower cost. It is very powerful layout manager and it should be used whenever it is necessary to build a complex GUI.
You can try
<LinearLayout>
<ViewPager/><!--Loading images from net, it is very good as a testing case.-->
<ViewPagerIndicator/>
<TextView/> <!--Show some info about page-->
</LinearLayout>
<RelativeLayout>
<ViewPager/><!--Loading images from net, it is very good as a testing case.-->
<ViewPagerIndicator below="id of ViewPager"/>
<TextView below="id of ViewPagerIndicator"/> <!--Show some info about page-->
</RelativeLayout>
You will find that there're a lot of different, if your Pages loading some images from internet. In this case the LinearLayout is 100% better than RelativeLayout ever.
Related
I am creating complex layouts with many Views on various screens of my app.The documentation says that:
It is a common misconception that using the basic layout structures leads to the most efficient layouts. However, each widget and layout you add to your application requires initialization, layout, and drawing. For example, using nested instances of LinearLayout can lead to an excessively deep view hierarchy. Furthermore, nesting several instances of LinearLayout that use the layout_weight parameter can be especially expensive as each child needs to be measured twice.
So an alternative is to use Relative Layout or Constraint layout.
This late 2018 article says Relative layout is better.
Today in terms of performance which one is better? Relative layout or Constraint layout?
I would use the constraint layout. It shall perform better.
In the N release of Android, the ConstraintLayout class provides similar functionality to RelativeLayout, but at a significantly lower cost.
Quote from performance/rendering/optimizing-view-hierarchies at the bottom
Note that the late 2018 article referenced in the question discusses the performance of RelativeLayout vs nested LinearLayouts and doesn't mention ConstraintLayout. ConstraintLayout has a better performance since it's introduced. A performance benchmark of ConstraintLayout vs RelativeLayout is available in this official blog post by Google - ConstraintLayout is ~40% faster.
I can see that Google actively promotes ConstraintLayout.
Is this means that it should be used in any case where this is possible?
I mean, if we have even some simple view with one or two child views, should we still use ConstraintLayout or this is not justifiable for simple views?
I mean from the performance perspective.
Are there any restrictions where usage is forbidden?
Performance suffers when you have multiple nested views eg relative layout contains a linear layout which contains a scroll view etc etc
The nature of constraint layout is that you can achieve things possible only by nesting other views, in a single constraint layout without nesting.
As long as the simple layout does not contain nested views, there is no strong performance gain by using constraint layout.
According to #Vardaan performances improvement is seen in the application which is also given in android developer blog and using it eliminates deep nesting, but it’s way too hard to do complex layouts with it since we don't deal with simple layout now days check this
I was ready some articles about performance optimization for android layouts. Most of them recommended using RelativeLayouts over other layouts because this might help you avoid Nested Layouts, that consume memory.
Personally, I believe that every thing has its Advantages and Disadvantages. But I could not figure out the disadvantages of the RelativeLayouts over the different types of layouts.
What is the disadvantages of RelativeLayouts?
When I should avoid using RelativeLayouts?
Thanks in advance.
For me, RelativeLayout is too much time consuming if you have to reorganize your components. That is the biggest downside.
For this reason, I would say RelativeLayout are really good as top level layout, and bottom level layout. But the mid-level layouts, are better served using the taylored (Linear, Table...) layout.
For example, when creating a form, the very top layout of my Activity or Fragment will be a RelativeLayout, but my form will be created as one big vertical LinearLayout. And inside this Linear, each line will be a RelativeLayout in which I will have a Text View and an Edit Text.
This way I can very easily sort the fields of my form and (I think) I keep my layout memory friendly by not overusing nested LinearLayout.
Relative Layout is the most used layout in most cases and from my experience, no disadvantage using this layout.Like I said before pick whichever is the best for the job, and worry about performance later.
update :
I copied comment from Is a RelativeLayout more expensive than a LinearLayout?
In a talk at Google I/O 2013 (Writing Custom Views for Android),
Romain Guy clarified the misunderstanding that caused everyone to
start using RelativeLayouts for everything. A RelativeLayout always
has to do two measure passes. Overall it is negligible as long as your
view hierarchy is simple. But if your hierarchy is complex, doing an
extra measure pass could potentially be fairly costly. Also if you
nest RelativeLayouts, you get an exponential measurement algorithm.
https://www.youtube.com/watch?v=NYtB6mlu7vA&t=1m41s
https://www.youtube.com/watch?v=NYtB6mlu7vA&t=38m04s
https://developers.google.com/events/io/sessions/325615129
My app is quite complex, i have a lot of views and viewgroups.
I have already turned some of the nested linearlayouts into relativelayouts, but the tree is still quite deep.
In the views tree there are branches that i need to display only sometimes, i would like to know what performs better: a sub-tree to show and hide or a dialog?
Here's a rough image i've done to try to explain:
Image clearly shows: 4 views is better than 7, but what if i hide (gone) viewgroup #5?
How heavy is opening/managing a "complex" dialog?
What are the pros and cons?
Thanx.
Using nested layouts is not recommended because of performance issues.
Well some layouts can only be made by doing some level of nesting. But you should avoid having too many nested LinearLayouts and even more important NEVER nest LinearLayouts with weights. You can read a little more about optimizing layouts in the official docs.
Personally I use LinearLayouts for simple stuff and start using RelativeLayout when the layout gets more complex. So, my suggestion would be to use the dialog. It will also help in making the code easier to read.
I'm developing an App with lot's of custom views and ran into performance issues with a quite complex one of them. The time they take for measuring and drawing is to high (>= 30ms typical). To give some more details: It's a custom ViewGroup (extending RelativeLayout) with custom Views (extending RelativeLayout although) as it's children.
So I'm it came across my mind what might be the better/quicker approach for getting rid of this performance problems: Optimize the children and layouts or switch to a completely custom drawn view (lines, rectangles and stuff like these)?
Do any of you have experience in one or another? Or even some done some benchmarks and is willing to share them?
The simple approach would be to work on simplifying and flattening the current view hierarchy and maybe you'll be able to make the measuring and drawing process much cheaper(or decent at least). You didn't posted a layout so there isn't something specific to say, I've seen you mentioned RelativeLayouts in RelativeLayouts, maybe you could remove one and move the views up one level(even with the expense of adding other helper views), every level counts(especially with nesting RelativeLayouts). You probably know already but the merge and include tags in layouts could prove quite useful.
RelativeLayout being in the standard SDK was built as a general widget so it most likely can't achieve the performance of a custom designed layout. It would make much more sense to make your current layouts extending RelativeLayout to extend ViewGroup and implement the measuring and layout of children manually especially as you probably know the use case scenarios in your apps(for example a RelativeLayout always needs to handle all the size constraint cases it could be in, your custom layout on the other hand could handle this much faster if you know that the custom view will have a certain size).
Related to a completely custom drawn view, it's an option but it depends on the complexity of your layout.
Or even some done some benchmarks and is willing to share them?
I don't see how various view benchmarks(which most likely will not apply to your specific situation) will help.