FragNav3.0 has memory leak? #179
Comments
|
Hi @burakztrk, You're leaking the activity context here hence FragNav and other views too. (Possibly toast can live longer than the activity). While this error is not an actual leak (will be garbage collected after a while) you can make it go away by using:
instead of
|
|
Ok.Thanks for answer.Im trying |
|
I'm facing a similar issue and nowhere in my code am I using Toast.makeText, could you look into it further? |
|
In the above log it is clear that Toast is created. Maybe some of your 3rd party creates a Toast. @mihirrai please attach a log so we'll be able to see more |
|
Hi, I have the same strange toast leek dump as burakztrk have. Leek happens exactly after calling switchTab. And I also don't use Toasts |
|
@nbumakov @mihirrai @burakztrk Okkay, I've dived deeper a bit (in the sample application) and could reproduce the "leak". It is not a real leak per se so if you check the android profiler you'll see no constant raise of memory. What happens is ultimately we hold a reference to the fragmentmanager of the activity which still has a reference for the fragment (for a while) which has been detached (view destroyed) and since you put views in fields in the fragments we kinda "leak" those. So for instance in the sample application we have something like To not leak this btn view we need to add the following: or if you're using butterknife use unbind: After this change I had no longer seen the leaks For instance for the trace above make sure you null out the pullToRefreshLayout view field in the onDestroyView |
|
@mateherber Thanks for responding to this |
|
@ncapdevi I don't think this issue should be closed. Although I applied unbinding as @mateherber suggested, the memory leak issue still persists. |
|
@ugurcany That's because to avoid the leak, we also have to make the interface nullable and we can't afford to do that. |
|
Well this is not a real leak just leakcanary reports it because the view references live longer than the lifecycle of the activity. This has not much to do with FragNav and also solution is to not leak any context outside the activity life cycle which fragnav does not. I think this can stay closed while somebody finds evidence that FragNav is leaking the views. @ugurcany If you're using kotlin you could use the Kotlin Android Extensions https://kotlinlang.org/docs/tutorials/android-plugin.html which uses maps in the background and saves you the effort. |
Memory Leak give varning all times with FragNav3.0
but old version not problem.
Im writing java. new FragNav3.0 is kotlin.I know. but its a problem?
The text was updated successfully, but these errors were encountered: