Closed burakztrk closed 5 years ago
mateherber
commented
5 years ago 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:
Toast.makeText(context.getApplicationContext(), message, Toast.LENGTH_SHORT).show();
instead of
Toast.makeText(context, message, Toast.LENGTH_SHORT).show();
burakztrk
commented
5 years ago Ok.Thanks for answer.Im trying
mihirrai
commented
5 years ago I'm facing a similar issue and nowhere in my code am I using Toast.makeText, could you look into it further?
mateherber
commented
5 years ago 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
nbumakov
commented
5 years ago 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
mateherber
commented
5 years ago @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
open class BaseFragment : Fragment() {
var btn: Button? = null
...
override fun onCreateView(...): View? {
return inflater.inflate(R.layout.fragment_main, container, false)?.apply {
btn = findViewById(R.id.button)
}
}To not leak this btn view we need to add the following:
override fun onDestroyView() {
super.onDestroyView()
btn = null
}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
ncapdevi
commented
5 years ago @mateherber Thanks for responding to this
ugurcany
commented
5 years ago @ncapdevi I don't think this issue should be closed. Although I applied unbinding as @mateherber suggested, the memory leak issue still persists.
mihirrai
commented
5 years ago @ugurcany That's because to avoid the leak, we also have to make the interface nullable and we can't afford to do that.
mateherber
commented
5 years ago 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?