As far as I undestand, neither a ViewStub nor a View that's GONE participate in the measure and layout passes (or rendering anyway).
Is there a difference in rendering performance? What's the best practice about when to use which?
The rendering performance comes into picture when you are inflating the views.
My guess is that its much cheaper to inflate a ViewStub than to inflate a View, either from XML or by changing visibility. ViewStub is especially used when you need to add/remove (indefinite) views (eg. add phone numbers to a given contact). Hope this is what you were looking for.
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 have a ListView where each row of the listview contains about 10 ImageButtons. Most of these buttons have visibility = Gone and only show up in very rare scenarios. I am wondering if it's worth it to replace these ImageButtons with ViewStubs to avoid loading them (and the images they contain) all the time for all the rows of the listview. Then again their visibility is set to "Gone", so I am not sure what impact loading them has. Do their images actually get loaded or not?
Note that I am talking about replacing e.g. the 8 ImageButtons with 8 ViewStubs, not with 1
Cheers
A ViewStub is a dumb and lightweight view. It has no dimension, it does not draw anything and does not participate in the layout in any way. This means a ViewStub is very cheap to inflate and very cheap to keep in a view hierarchy. A ViewStub can be best described as a lazy include. The layout referenced by a ViewStub is inflated and added to the user interface only when you decide so.
Sometimes your layout might require complex views that are rarely used. Whether they are item details, progress indicators, or undo messages, you can reduce memory usage and speed up rendering by loading the views only when they are needed.
Simply a ViewStub is used to increase efficiency of rendering layout. By using ViewStub, manually views can be created but not added to view hierarchy. At the runtime, can be easily inflated, while ViewStub is inflated, the content of the viewstub will be replaced the defined layout in the viewstub.
The ViewStub will be loaded only when you actually use it/need it, i.e., when you set its visibility to VISIBLE (actually visible) or INVISIBLE (still not visible, but its size isn't 0 any more). ViewStub a nice optimization because you could have a complex layout with tons of small views or headers anywhere, and still have your Activity load up really fast. Once you use one of those views, it'll be loaded.
You must add ViewStub in Layout at first, after you can inflate it to another View.
Note: One drawback of ViewStub is that it doesn’t currently support the <merge/> tag in the layouts to be inflated. Alos ViewStub can’t be used more than once. Also keeping long-lived reference to a ViewStub is unnecessary, if it is required, it's good practice to null it after inflating, so GC can eat it.
Let's suppose your ViewStub ID is view_stub. You need to do the following in the activity:
ViewStub viewStub = (ViewStub) findViewById(R.id.view_stub);
View inflatedView = viewStub.inflate();
ImageButton button = (ImageButton) inflatedView.findViewById(R.id.button);
Now you can do whatever you want with the button :) That is, the inflate method returns the stub layout which contains the actual elements from the XML file.
Of course, you can always have the onClick XML attribute or can be dynamically called.
Is a ViewStub worth it?
->For the scenarios that you are specifying, I think `ViewStub` will be worth-shot.
See below urls about ViewStub
http://android-developers.blogspot.in/2009/03/android-layout-tricks-3-optimize-with.html
http://developer.android.com/reference/android/view/ViewStub.html
http://developer.android.com/training/improving-layouts/loading-ondemand.html
Instead of ViewStub you can try <\include> tag. The <include/> will just include the xml contents in your base xml file as if the whole thing was just a single big file. It's a nice way to share layout parts between different layouts.
Difference between <include> and <ViewStub> in android
Edit: just noticed that Endzeit commented regarding a similar direction before me.
I would start by doing some benchmarking around the inflating code with and without the views - just comment out the adapter code so it doesn't try to access the non existing views.
If the removal of the Views from the layout does gives you an improvement that you think is necessary and since you say the views are present only in rare scenarios which you are anyway checking for in your adapter,
then instead of inflating those views or even using view stubs, create them in code and add/remove them as needed (using the viewholder to reference them).
You could even go further and do a lazy creation of these views, similar to lazy loading of images, but I would only do that after running some benchmarking again.
I would use ViewStubs for loading complex layouts not simple ImageButtons.
Edit 2:
Looking into ViewStub inflate command, which is what it does when it needs to be visible you can see it infaltes the layout given and then adds it to the parent layout - since you are adding a simple ImageButton you can gain performance by not having a ViewStub and just adding the ImageButton in your code.
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.1.1_r1/android/view/ViewStub.java#ViewStub.inflate%28%29
According to Google's official documentation here.
ViewStub is a lightweight view with no dimension that doesn’t draw anything or participate in the layout. As such, it's cheap to inflate and cheap to leave in a view hierarchy. Each ViewStub simply needs to include the android:layout attribute to specify the layout to inflate.
To experiment this, I created a sample project and added a ViewStub to the layout hierarchy. On running layout inspector I can see that all the layout attributes for ViewStub are zero.
Let's compare it to having a layout which has 10 buttons hidden. What this actually means is, the layout hierarchy has 10 buttons hidden, which is sitting in the layout hierarchy and taking up some amount of memory. It's cheap to leave a ViewStub in hierarchy since it doesn't take up much memory, at the same time it's cheap to inflate.
My final verdict would be, use ViewStub extensively when you've complicated views which are inflated rarely as it definitely helps in saving memory and improving View inflating time.
Using the Android monitor's Memory tab in Android Studio (button for the Android monitor should be at the bottom bar), you could check it yourself:
Take a look at the memory usage when running the app with invisible buttons
Take a look at the memory usage when running the app with visible buttons
If there is any difference, then you can conclude not everything is preloaded when the views are Gone. Of course, you could also compare this to a ViewStub implementation to check whether that will help to decrease memory usage.
In short, using custom view instead of viewstub.
We are having a similar situation now, and we have also tried viewstub before, listview works a little faster. But when it comes to 8 viewstubs, i don't think its a good idea to use viewstub to avoid inflate too many widgets.
Since u (and also us) have a logic to control whether 10 buttons to show or not , why not just define a custom view, and draw different buttons according to different state machine? It's much fast, and need no inflation at all, and it's logic is much better controlled. We are using this method to accelerate listview now and it works good.
when you set a view visibility to gone this means that This view is invisible, and it doesn't take any space for layout but its data are loaded into it.
Now the ListViews they remove the unseen or lets say the views that are out of the screen bounds for performance reasons .
A ViewStub is an invisible, zero-sized View that can be used to lazily inflate layout resources at runtime.
So i think if you want from my opinion I prefer the Views with GONE Visibility rather than using much logic with ViewStub and Creating and inflating ... etc .
But on the other hand
The rendering performance comes into picture when you are inflating
the views.
My guess is that its much cheaper to inflate a ViewStub than to
inflate a View, either from XML or by changing visibility. ViewStub is
especially used when you need to add/remove (indefinite) views (eg.
add phone numbers to a given contact). Hope this is what you were
looking for.
reference : ViewStub vs. View.GONE
some good Brief presentation of DDMS here :
http://magicmicky.github.io/android_development/benchmark-using-traceview/
Use ViewStub instead ImageButton.
This is because
. ViewStub is zero sized view by default while image button not
. View Stub is naturally an invisible view . its performance is better than image button because it load runtime only when its state become visible.
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.
What are the differences between <\include> tag and <\ViewStub> tag and which one is preferrable while designing the layout.
The < include /> will just include the xml contents in your base xml file as if the whole thing was just a single big file. It's a nice way to share layout parts between different layouts.
The < ViewStub /> is a bit different because it is not directly included, and will be loaded only when you actually use it/need it, ie, when you set its visibility to VISIBLE (actually visible) or INVISIBLE (still not visible, but its size isn't 0 anymore). This a nice optimization because you could have a complex layout with tons of small views or headers anywhere, and still have your Activity load up really fast. Once you use one of those views, it'll be loaded.
include
It is used to reuse layout resource
ViewStub
It is used to lazily inflate layout resource
Sharing and reusing layouts is very easy with Android thanks to the tag, sometimes even too easy and you might end up with user interfaces that contain a large number of views, some of which are rarely used. Thankfully, Android offers a very special widget called ViewStub, which brings you all the benefits of the without polluting your user interface with rarely used views.
A ViewStub is a dumb and lightweight view. It has no dimension, it does not draw anything and does not participate in the layout in any way. This means a ViewStub is very cheap to inflate and very cheap to keep in a view hierarchy. A ViewStub can be best described as a lazy include. The layout referenced by a ViewStub is inflated and added to the user interface only when you decide so.
Another important difference is related to layout inflating. with it is not possible to change the layout already static inflated in XML, it is necessary to replace the view and set programmatically al the layout parameters.
With it is possible to define (for e.g.) height, width, etc... and inflate different layout at runtime time
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.