0

I am using a custom Backstack to manage the Application screens. Basically, the custom BackStack is a List. The problem is that this method does memory leaks.

This method checks if there is a Fragment in the cell already:

    private fun addToBackStack(fragment: Fragment){
    try {
        if (backStack.isNotEmpty() && backStack[backStackPosition] != null)
            fragmentUtils.removeFragment(backStack[backStackPosition]!!)
    } catch (e: IndexOutOfBoundsException) {
        e.printStackTrace()
    }
    backStack.add(backStackPosition, fragment)
}

And this is how I try to remove it:

fun removeFragment(fragment: Fragment?){
    fm.beginTransaction().remove(fragment).commit()
}

But I still have memory leaks, according to LeakCanary. What am I doing wrong, or how to completely destroy a Fragment?

MONK
  • 179
  • 2
  • 15
  • I mean if you have memory leaks then clearly the memory leak itself is elsewhere. though your backstack most definitely won't work if you check against process death, see https://stackoverflow.com/a/49107399/2413303 – EpicPandaForce Jul 03 '18 at 14:14
  • @EpicPandaForce The Backstack works good and with configuration changes. No crashes at all. The main problem is memory leak. CanaryLeak tracked it back to the BackStack. There is no other place that would keep an instance of unused Fragments. – MONK Jul 03 '18 at 14:25
  • Have you tested across **process death**, which is completely different from configuration changes? – EpicPandaForce Jul 03 '18 at 14:29
  • Why would you need a custom backstack? You obviously can't keep fragment instances because they will leak host activity context. – Pawel Jul 03 '18 at 18:22
  • @EpicPandaForce yes, everything works as usual. Maybe the app will start 1 sec longer but there are no problems. – MONK Jul 04 '18 at 08:05
  • @Pawel Because the native backstack is too simple and it doesn't give you that much control over the app. And I know that It causes memory leaks, that's why I'm here, asking for possible fixes. – MONK Jul 04 '18 at 08:07
  • Huh, that's a surprise to me, just making sure :D i maintain a library for [managing navigation state in a list/backstack](https://github.com/Zhuinden/simple-stack) and I don't store the Fragment instances directly because they're re-created by the system after process death and you'd need to find them by tag anyways. – EpicPandaForce Jul 04 '18 at 09:25
  • is your `fragmentManager` in `FragmentUtils` holding a reference to the activity's FM? and being re-referenced every time on new activity? Also I don't see the advantage of performing `removeFragment()` manually. If you need to handle a case where something should happen when fragment is removed from the stack use `addOnBackStackChangedListener` in the FM and implement your calls there. Further make sure you have `WeakReference` that would be safety mechanism for a class not to hold any collectable references. – HawkPriest Jul 04 '18 at 12:53
  • @HawkPriest, WeakReference doesn't work, cus GC collects Fragments once they go to backstack. But SoftReference seems to work. Gonna test that out later. Thanks for the clue though! – MONK Jul 05 '18 at 15:58

0 Answers0