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);
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 fragment that contains a LinearLayout that is conditionnaly displayed or not. In terms of performance what is the best? Mark the LinearLayout as android:visibility="gone" in the XML, and then in code I set its visibility if needed, or the opposite?
Inflating a layout with some views with a visibility set to GONE is bad for performances, especially if the view is a bit complex.
check url :http://magicmicky.github.io/android_development/benchmark-using-traceview/
Unless that layout is very complex and has too many views, I wouldn't worry about it, it won't matter very much.
But it does seem more logical to initially set it to be gone unless you decide that it should be visible afterwards.
You could also think of it from a UX point of view, should the user see it very briefly then it disappears? or should it work the other way around?
I think there is nothing much with the performance in these two implementation unless you are hiding the layout after a long running network calls or something like this which requires some time to make the decision of hiding and showing the layout or the layout is too complex.
However, I would suggest you to keep the following things in mind.
In case of orientation changes of your activity, you need to handle the layout visibility in your onCreate or onResume function as the activity gets recreated. If you are hiding the layout and not keeping a track of it in a global static variable, the decision might get lost and you might get inconsistency in your overall layout design. However, if you are hiding your LinearLayout based on a decision which is being made in your onCreate function, you will not face this exact situation.
If this LinearLayout is inside an item of your RecyclerView or ListView, think of handling each of your layouts items carefully.
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.
In my app, for instance, when a user creates a new post, he or she can select a type of media (photo, video, text, place, etc.) and then review it in the following activity.
The way I have been doing it is to have all of the views (i.e. ImageView, VideoView, WebView, etc.) there, but set their visibility to invisible, unless the user chooses that type of media.
For instance, all of the views are invisible until the user takes a photo and then only the ImageView is visible. This seems wasteful though. Before I start the activity, I know which type of media the user chooses, but still have the invisible, unused views.
Would it be smarter to have separate layouts for each type of media with the repeated elements (the create post button, the privacy and venue buttons, etc.)? But this would violate the DRY principle...
How costly are invisible views? What is the correct way of doing this?
Depends on the complexity of the Layouts, I had this issue in previous app, in first iteration I did like you, but in 2nd iteration I found its hard to optimise single layout with bunch of invisible views; much less the if else cases to toggle views visibility.
and about layout performance, also it depends on layout/design complexity, I don't think unused view will consume that much of memory or cpu.
so if your layout is simple, its okay for now, if not I recommend to use separate layout for each design/type.
and as #ashishduh said, the best is to set visibility to GONE instead of INVISIBLE, since the parent layout will not measure GONE views, but this doesn't prevent view usage of memory or cpu (mostly in custom views)
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!