This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Possible Memory Leaks and missing onDestroyView cleanup #933
Description
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.
Activity
yDelouis commentedon Mar 26, 2014
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 up
ViewsinonDestroyView.bastienvalentin commentedon May 6, 2014
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.
WonderCsabo commentedon May 6, 2014
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.yDelouis commentedon May 6, 2014
It doesn't cost so much so yes, we should.
nenick commentedon May 6, 2014
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.
bulatgaleev commentedon Jul 17, 2014
Any update on this?
WonderCsabo commentedon Aug 22, 2014
Feel free to contribute the feature. :)
bulatgaleev commentedon Aug 22, 2014
In progress already:)
WonderCsabo commentedon Aug 22, 2014
Great, thanks for your contribution! If you need any help on the implementation, just let us now.
DayS commentedon Sep 21, 2014
@LocalHostEu What's the status of your work on this ?
bulatgaleev commentedon Sep 22, 2014
@DayS Still need some time to finish.
WonderCsabo commentedon Sep 29, 2014
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.WonderCsabo commentedon Jun 10, 2015
Finally fixed.