I am introducing view object recycling into my Android app to help performance. It does help with that. But when a new screen appears, I am seeing brief artifacts which I assume are related to the prior state of the views. The artifacts take the form of a rectangular region of some color that should not be there. The app adjusts itself to the correct state very quickly, but it's still annoying. I am wondering if there is a way to prevent this. What I am currently doing is removing the old view from the hierarchy and un-setting its event handlers. Obviously, that is not enough. LayoutParams typically relate a view to its parent; perhaps I need to be somehow "un-laying-out" the view when removing it? But I'm not sure how to do that.
If your performance issues lay in a ListView, you can use RecyclerView instead to help that: https://developer.android.com/training/material/lists-cards.html.
Besides that, how exactly are you recycling and what type of Views do you use?
Related
Whenever a new view is added or removed, everything is adjusted. I can see how in majority of use-cases this is a very good thing, but unfortunately for me, it's something I need to avoid. I'm assuming that onMeasure() is called whenever a view is removed or added, resulting in it changing the X and Y coordinates I gave it, however I want to "disable" this.
My app utilizes dynamically moving and resizing views, determined by the user at runtime, hence if whenever the user removes a view or adds a new one, it shifts everything around, it'd be extremely annoying. Also I'd think that (although not sure) that preventing this could only help performance right? Not measuring each view, in fact, I do not want it to measure it at all because, once again, the user decides the view size and location, not the linear layout.
I was thinking of creating my own ViewGroup, but I've never done this before. I know you can extend a pre-existing one, like LinearLayout or RelativeLayout, but I need help determining which one I should use, and whether or not I should just create a full on ViewGroup.
As I said, it doesn't need to measure the views at all, and in fact, if it were possible, a container that does nothing would be optimal, and I'd think would yield more performance. Can anyone help me with this problem?
Summary:
Need a way to either prevent a pre-existing ViewGroup, I.E FrameLayout, RelativeLayout and LinearLayout, that do not adjust the position nor size of the view, or create a new ViewGroup which doesn't do any measuring at all because the user defines the location and size at runtime and should not be altered by the container.
If this is a bad question or another question exists that answers this, please let me know.
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.
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.
For example, when you make some View to GONE, Android goes through all of your views, trying to determine if it should resize/move or whatever them.
I want to have quite a few views in a certain activity (I've got my reasons, I know it's bad ;) ), and I want them detached from one another. Is there a way to do this? Otherwise, you make some small, irrelevant view GONE, and the applications lags because unnecessary perform traversals are made.
Is there a way to optimize the architecture of the views in order to be sure for that?
Thanks in advance,
Dan
I have a LinearLayout that, throughout the course of the application, aggregates child views that can be removed. My question is, when a child is removed from a parent view, is there any way to animate the other children into place? In essence, I want to sort of recreate the effect of the ICS/Jelly Bean recent apps window - when one is swiped away the others sort of fall into place. I know that this specific implementation is made by Google and thus is probably outside the realm of possibilities that I can do, but how would I go about emulating that effect?
Thanks!!
Read about viewgroup animation in this answer. You can use animation API to create animation.
https://stackoverflow.com/a/6524820/940680