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.
Related
I have inherited a project where its user input screens are using single layout file. Depending on the type of user input required to show, a group of views are hidden or shown via View.GONE and View.VISIBLE. I don't understand why the old programmers did this. Is there a performance gain in this approach?
Official guideline about Improving Layout Performance
Sometimes your layout might require complex views that are rarely
used. Whether they are item details you can reduce memory usage and
speed up rendering by loading the views only when they are needed.
You can use ViewStub. It is zero sized invisible View that can be used to lazily inflate layout resource at runtime.
Sometimes might need to re-use larger components that require a special layout. To efficiently achieve this, You can try with Re-using Layouts with <include/>. Good way to share layout parts between different layout’s.
It could be a case of performance gain as Views will not be rendered. However, I am not certain why those developers went with this approach. If there are multiple views are not going to be used then rather create two separate layouts and based on the user, inflate one or the another.
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.
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'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.