Repository navigation
Possible Memory Leaks and missing onDestroyView cleanup #933
Description
Activity
If I understand the post correctly, the memory leak happens only if you call
setRetainInstance(true)on theFragment.
AndroidAnnotations doesn't generate this call. So, I don't think it shouldn't be responsible for cleaning upViewsinonDestroyView.Hi,
I'm currently working on a project using android annotation 3.0.1. As far as I know I'm not using the retainInstance method with a true value. On the other hand I'm using the addToBackstack method in order to have a correct user navigation when the user press back.
My problem is an out of memory error which may be caused by the non-implementation of the onDestroyView of the fragment. Indeed when I'm on the fragment A, going to the fragment B and then going back to the fragment A using the back button (and so the backStack) I can see that this fragment is not destroyed as well as the view inside it. In my case this results in a memory leak.
To solve the bleeding I'm forced to directly edit the generated file and override the onDestroyView in order to put the contentView_ to null and clean the memory a bit.
I may be mistaken but I think that this method should be override by android annotation.
If I'm mistaken please let me know.
Kind regards.So if you set all the injected
Viewfields inonDestroyView, theFragmentdoes not leak, but if you just leave the generated code as is, theFragmentstays in memory?@yDelouis Maybe we should clear the fields anyway, since the client code can call
setRetainInstanceState(true), but it has no chance cleaning up theViews because they are in the generated subclasses.It doesn't cost so much so yes, we should.
Nice to hear about that. I'm facing the same issue with growing memory.
But also we should look if that a mistake by our own app implementations.
Currently I'm working on a simple project template with aa and just there I see growing memory usage when switching between activities.
You can also reproduce it with simple app sample? When not I will just search the error in my code.
Any update on this?
Feel free to contribute the feature. :)
In progress already:)
Great, thanks for your contribution! If you need any help on the implementation, just let us now.
@LocalHostEu What's the status of your work on this ?
@DayS Still need some time to finish.
Cleaning the
contentView_reference is now merged. We will also clean the injectedViewfields, but that will be in the next major release (4.0), because that is a breaking change.Finally fixed.
Just read some discussion about the problem with fragments, that a missing cleanup of view references can cause a memory leak.
http://stackoverflow.com/questions/13421945/retained-fragments-with-ui-and-memory-leaks
I checked the generated classes of android annotations and could not find any place, where views will be cleaned. We are able to see, that just switching fragments increases memory usage. We will try to write a small cleanup ourself shortly, but maybe it would be great to implement it at android annotations.