I've been using some progressbars in my android app (Lazy loading GridViews). So when each item is loaded I set the progressbar to become INVISIBLE. I know that
INVISIBLE : This view is invisible, but it still takes up space for layout purposes.
GONE: This view is invisible, and it doesn't take any space for layout purposes.
My doubt is when I set the progressbar to INVISIBLE does it mean that the resources needed by that View are still being used in the background? (Example the progressbar animation). If I set it to GONE will there be any change in performance (I know it might be negligible). I'm curious to know it's implications on performance. Thanks.
The performance difference would likely vary on what the view's contents and complexity are, and if there are nested views within it. While the layout information still has to be inflated into memory for the entire layout, the view measurements would not have to be calculated for a view that is GONE or its children, and it would not be drawn, whereas INVISIBLE only removes the rendering of the view (and its children) while still calculating the view measurements and its children.
If you don't want the view to appear again in the current lifetime of the activity or fragment, you can use parent.removeView(progressView) to remove it entirely for the best performance and memory optimization.
In your case it may not help much, but if you're going for bleeding edge optimization then I would take the approach to remove the view once it's done.
Related
I have 3 layouts in my root layout. Only one of these layouts would be "visible" and rest 2 would be "gone". Since all these layouts are bulky, I am concerned :
Do all 3 layouts consume memory after I inflate the root xml ?
Every time the viewgroup invalidates or requests layout, are all the viewgroups measured and drawn, or just the "visible" ones ?
Additional details (if needed) - I am implementing a chat window which has 3 states - expanded, collapsed and multiple. This chat window popup will be at the bottom of all screens in my app, and the user can expand to chat. All 3 states are much more than an imageview + textview, so I went for 3 different layouts (for every state) and only 1 of them is visible at a time. I don't know if there is a better approach for achieving this.
1.- Yes all your Views will consume memory, even GONE views, the only difference is that those views will not be measured or draw, but they are still usable on the View and ready to be shown just by calling setVisibility, so they actually are loaded in memory, If you need a View that will not be fully loaded until specified look at the ViewStub
2.- Just the visible ones, but once again, the GONE views, are loaded in memory just not Measured-Drawn, in case you might wonder the difference between INVISIBLE and GONE, INVISIBLE will take the measured space but not visible and GONE will not take that space...
Hope it Helps!
Regards!
I'm making an app in which it might save me some time to
have a single layout for several activities, with some of the views set to GONE depending on which activity is being used.
I know that having a large number of views in a layout can lead to poor performance. If I had an activity with a large number of views, but a large portion of those views were to to GONE, would this activity still perform poorly. That is, do views that are set to GONE contribute to worsening performance? If yes, do they demand less processing power than VISIBLE or INVISIBLE views?
Thanks!
First thing you should know about gone vs invisible:
View.GONE This view is invisible, and it doesn't take any space for layout purposes.
View.INVISIBLE This view is invisible, but it still takes up space for layout purposes.
Thinking about the impact on measuring.
Which one is more efficient all depends on how frequently you are
changing the view's visibility.
For example, if the view is not visible for a majority of the time,
making it GONE would probably be more efficient, because the system
would not be needlessly measuring and laying out your invisible view
whenever it needs to adjust other views on the screen.
On the other hand, if the view changes between visible and invisible
frequently, you might get better performance from INVISIBLE as you
would potentially avoid an extra measure/layout on each transition.
Here is an interesting answer. I was wondering the same thing as you, and the answer is that View.GONE consumes more memory than simply calling removeView(view) on the view. However, GONE views do consume less memory than View.VISIBLE since they do not need to be drawn.
The memory amounts compare like this:
View.VISIBLE > View.GONE > removing the view from the container
What I do is use View.GONE on views that don't consume a lot of memory (like a TextView) and use parent.removeView(view) on views that are a lot of memory (like a WebView);
If foo is a view, what is the difference between foo.setVisibility(View.GONE) and fooParent.removeView(foo)? I am particularly interested in memory consumption of the view, before and after both statements.
Does a view with visibility set to GONE consume memory ?
If you need to remove them and then show them again, it could be better to just set visibility to gone and then change back to visible again.
If you on the other hand don't need them visible again, simply remove them.
suppose,
if you need to delete all the available option of flying once you
select a particular flight. then go with fooParent.removeView(foo).
or,
if you need to selection of a particular flight all the flying options
are disappeared, and deselection of flying option again show all the
available options then go with foo.setVisibility(View.GONE) and
foo.setVisibility(View.VISIBLE)
setVisibility(View.VISIBLE) = setVisibility(0)
setVisibility(View.GONE) = setVisibility(8)
setVisibility(View.INVISIBLE ) = setVisibility(4)
I know this question is too old, but after what I have encountered in my recent projects, I want to give an idea of how View.GONE works, and how it can come in handy for some runtime view position manipulations.
Suppose you have added two child views inside a RelativeLayout, cv1 and cv2, and that cv2 is relatively below cv1(using layout_below). Then if you plan to set visibility of cv1 to GONE in runtime, then it won't cause any runtime error.
That's amazing to see because cv2 was relative to cv1, and now cv1's visibility is GONE.
So what happens actually with visibility GONE is that,
view's height and width becomes zero, but, view stays in the parent,
like a tiny dot or point.
So, even if any view is placed relative to it, it will be like, that view will occupy its place(here cv2 will occupy place of cv1 in runtime). Later on, if cv2's visibility is turned back to VISIBLE, than, cv1 will now occupy its actual position, with cv2 below it.
This link describes my usecase.
This approach of showing and hiding view comes in handy, when you don't want to handle the hassle of manipulating the LayoutParams of a view in runtime, when your usecase is this simple.
On the other hand, parent.addView() / parent.removeView() approach is opted when your view hierarchy is complex, and you want to manipulate margins, paddings, and relative positions of the views drastically during runtime.
In Android, Which is the light weight view ?
ex:- View, Textview, Edittext, etc....
In some case we need to use a view to fill the area without showing the view to the user.
At the same time the screen should load fast.
You can use Space.
android.widget.Space
Space is a lightweight View subclass that may be used to create gaps between components in general purpose layouts.
If by "lightweight" you meant memory footprint, then there is none exists on Android, because each view have to derive from View, which itself is a massive object (well, not massive, it is about 8kB), so it's not that big.
But in terms of measure, layout and draw time the basic View performs well. You just have to set its visibility to INVISIBLE. And so it will be measured and put into the layout (contrary to GONE with which the view would not take up any space).
Unfortunately ViewStub is not meant to be used for this purpose. Its default visibility is GONE.
If you are really picky, then you can extend View and override methods like draw() (to do nothing, do not even call super), dispatchDraw(), setVillNotDraw(true), etc. (Take ViewStub as a sample).
You should have a look at ViewStub.
Use ViewStub if it is sufficient or LinearLayout which may be somewhat light weight.
If i set a views visibility which as been inflated, to gone, will it Speed up my UI?
It will speed up the actual drawing of the UI, because, well, you don't have to draw it anymore, but it will still be inflated and the inflation process will not be faster.
GONE = This view is invisible, and it doesn't take any space for layout purposes.