Background information:
I'm working on a small app for myself and a few friends, and it contains a few ListViews with items based on custom XML layouts. The layouts are somewhat heavy - a few ImageViews, TextViews, a LinearLayout and a RelativeLayout - so I started thinking about performance. I'm not personally experiencing any performance issues, but I know that some of my friends, who'll be using the app, don't have high-end phones and that they might have issues with these layouts.
I remember watching a video presentation regarding performance in Android, and I recall Romain Guy mentioning something about custom Views being better for performance than constantly inflating custom XML layouts. I believe the context was the early development of the Gmail application (around Android 1.5, I believe), where each item of the Listview was rather complex.
It's probably worth pointing out that I'm reusing Views in my application, and that I'm using the ViewHolder principle as recommended by Google.
My question: Is it better for performance to use custom Views or is it OK to inflate custom XML layouts?
As always, then answer is "it depends" - inflating view from XML imposes some performance penalty ( parsing overhead ) over plain creation in code, but also provides greater flexibility. You should definitely reuse views whenever possible ( especially in larger lists) - it improves scrolling performance dramatically
If you can create a custom layout instead of having a linear layouts and relative layouts it will be more beneficial for you to just create a custom layout. It's kind of like, instead of using nested linear layouts, you should just use a relative layout. If you use relative and linear and a whole bunch of views, then just coding a custom layout should be beneficial.
Related
So I have been writing some Android code for a week or two and some layouts are self-explanatory such as gird, table, and so on. However, I am still confused about when to use Linear layouts, when to use Constraint Layouts and when shall I use Relative Layouts. I know that Google prefers Constraint layouts but, a lot of code samples use other kinds of Layouts. I am confused if I shall even prefer other kinds of layouts or not?
The idea is to get the less nesting in your layout as possible, this for performance, if the layout is quite simple and show a vertical or horizontal layout, I will use LinearLayout, otherwise I will use ConstraintLayout because it's the more powerful layout and any layout can be implemented with ConstraintLayout even the simple ones and it's the evolution of RelativeLayout, also android recommends to use that layout.
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'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.