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.
Related
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
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.
I find myself using RelativeLayout more than any other types of layouts in Android XML files. Given that my apps use primarily simple and basic interfaces, it is quite easy to bang out a new RelativeLayout.
Currently I create a RelativeLayout and I assign each component of the layout properties such as Layout Below, or Layout Left, or Layout Right to anchor that component to the correct area of the user's interface.
While it's easy to define new layouts, it's hell trying to move a single component within a layout. Given that I've used components in my layout to space other components, once a component is moved, the layout around that component falls apart. Moving a component means I have to re-do the relationship for all components below that one. Surely I am doing this wrong? There must be a better way?
TL;DR I use RelativeLayouts and the components I put in the UI to space one-another relatively (of course). If I move a component say to the top, the items below it break as the relative relationship breaks. How can I more easily move components around and experiment with my UI without renaming tens of spacial relationships each time?!
This is one of the cases where the tooling is preferable over hand-coding the layout XML. Editing the XML using the Graphical Layout tab helps ease lot of this pain of refactoring RelativeLayouts. It is not the perfect solution, but it does make things a lot easier.
I should point out that these changes have come about in ADT 14 and newer. If you are using any older ADT, I suggest you upgrade. In case you do not know how to use the Graphical Editor to get the most out of your RelativeLayouts, check out this video.
Having said that, the inflexibility of RelativeLayout is the main reason I prefer using nested LinearLayouts over the former - in spite of Google's suggestions to use the former for performance reasons.
As a compromise, I use RelativeLayout only for items in a ListView, and nested LinearLayouts for everything else.
+1 for the question, since I've been looking for the solution myself. However, I think/feel the only way to do this is by declaring attributes like android:layout_alignParentBottom , android:layout_alignParentLeft etc. for the items that can afford to use those attributes, as they align with the parent, which according to my understanding is the layout itself. Otherwise, I don't see any other way with Relative Layouts. As Rafael T says, another way of binding those items to the layout is by using nested Linear Layouts. But then again, even that is a bit tedious. Finally it depends on the programmer who chooses the layout. Personally, I'd choose/prefer Relative Layouts.
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.