ArFragment in Fragment problem

[dimiitpk]

Hello,

So I'm having a hard time with implementing ARFragment in Fragment. The current flow of the application is that we have a fragment(A) with a list of models from which you can pick one and send it with the navigation component to another fragment(B). That fragment contains FragmentContainerView and several other Views.

In that Fragment(B) we are using fragment transaction with childFragmentManager to add fragment. Fragment is initialized successfully every time and childFragmentManager contains only that ARFragment.

The problem is, however, if I go back and pick another model or the same one and re-enter fragment(B), that fragment B is initialized successfully again, but it is laggier and the memory profiler shows more memory usage than the first time.

By repeating this process, the newly initialized ARFragment is always laggier until the app just stops working, with no explanation, probably big memory usage.

childFragmentManager contains no fragments on creating fragment B. I tried with ARFragment's onDestroy, onStop, onResume, but nothing helps. Also, I tried using supportFragmentManager with Activity that contains that fragment B, also unsuccessfully.

Is that fragment still somewhere in memory, I really need your help.

Thanks in advance.

[frederic-c-dcode]

Why don't you just keep the same instance of ARFragment, remove the old object from the scene, then add the new object? You could use the Activity common to the fragments to communicate which objects to show in the ARFragment view, rather than using the navigation component.

[ThomasGorisse]

@frederic-c-dcode is right

First, it's true that we don't have the hand on the onDestroy() call and it might not be called if you still have references to it.
Over than that, does that mean that your user has to scan for planes every time he changes his model?

Anyway you might be facing a consuming issue that shouldn't happen and be sure we are hardly working on it.
I can advise you to try the actual coming release here #156 since it solved a lot of consuming issues.

Could you then send some performance monitor screenshots to help going further on your memory issue?

[dimiitpk]

@frederic-c-dcode @ThomasGorisse

Thanks for the fast response.

The application is quite complex with a lot of different screens(nav graphs and nested ones), so I need to remove ArFragment and add it back when it's necessary, otherwise, I'll have a laggy app. So for that matter, my users must scan for planes every time they select a model from a previous fragment.

I had a FragmentContainerView in MainActivity and when I got to the desired fragment when I needed it, I would add ArFragment with fragment transactions to Activity's supportFragmentManager, initialize listeners in OnAttachFragmentListener, and on destroying current fragment, removing ArFragment from fragment transactions with Activity's supportFragmentManager.

Results with memory are the same, and the app still crashes when it's got to the usage of around 2Gb without some log information.

I'll provide Memory Profiler screenshots as soon as I can.

Edit:

So I was investigating a bit and there were 2 leaks, one connected with my fragment, that I fixed by setting TapListener and SessionConfigurationListener on null while destroying. But this one is left

My CustomARFragment is just this:
I am not calling supper, for fullscreen performances, my status bar was lost. I tried with returning super back, still leaks.

class NakedArFragment : ArFragment() {

    override fun onWindowFocusChanged(hasFocus: Boolean) {
//        super.onWindowFocusChanged(hasFocus)
    }
}

[dimiitpk]

LeakCanary

┬───
│ GC Root: System class
│
├─ android.view.inputmethod.InputMethodManager class
│    Leaking: NO (InputMethodManager↓ is not leaking and a class is never
│    leaking)
│    ↓ static InputMethodManager.sInstance
├─ android.view.inputmethod.InputMethodManager instance
│    Leaking: NO (DecorView↓ is not leaking and InputMethodManager is a
│    singleton)
│    ↓ InputMethodManager.mCurRootView
├─ com.android.internal.policy.DecorView instance
│    Leaking: NO (View attached)
│    View is part of a window view hierarchy
│    View.mAttachInfo is not null (view attached)
│    View.mWindowAttachCount = 1
│    mContext instance of com.android.internal.policy.DecorContext, wrapping
│    activity rs.upgrade.ar.naked.presentation.MainActivity with mDestroyed =
│    false
│    ↓ View.mAttachInfo
│           ~~~~~~~~~~~
├─ android.view.View$AttachInfo instance
│    Leaking: UNKNOWN
│    Retaining 50.9 MB in 1080 objects
│    ↓ View$AttachInfo.mTreeObserver
│                      ~~~~~~~~~~~~~
├─ android.view.ViewTreeObserver instance
│    Leaking: UNKNOWN
│    Retaining 50.9 MB in 1038 objects
│    ↓ ViewTreeObserver.mOnWindowFocusListeners
│                       ~~~~~~~~~~~~~~~~~~~~~~~
├─ java.util.concurrent.CopyOnWriteArrayList instance
│    Leaking: UNKNOWN
│    Retaining 50.9 MB in 1027 objects
│    ↓ CopyOnWriteArrayList.array
│                           ~~~~~
├─ java.lang.Object[] array
│    Leaking: UNKNOWN
│    Retaining 50.9 MB in 1025 objects
│    ↓ Object[].[0]
│               ~~~
├─ com.google.ar.sceneform.ux.BaseArFragment$$ExternalSyntheticLambda0 instance
│    Leaking: UNKNOWN
│    Retaining 50.9 MB in 1024 objects
│    ↓ BaseArFragment$$ExternalSyntheticLambda0.f$0
│                                               ~~~
╰→ rs.upgrade.ar.naked.presentation.common.sceneform.NakedArFragment instance
​     Leaking: YES (ObjectWatcher was watching this because rs.upgrade.ar.naked.
​     presentation.common.sceneform.NakedArFragment received
​     Fragment#onDestroy() callback and Fragment#mFragmentManager is null)
​     Retaining 50.9 MB in 1023 objects
​     key = 782d500a-c096-4324-b08b-5516a1fed17f
​     watchDurationMillis = 6887
​     retainedDurationMillis = 1885

METADATA

Build.VERSION.SDK_INT: 29
Build.MANUFACTURER: Google
LeakCanary version: 2.6
App process name: rs.upgrade.ar.naked
Stats: LruCache[maxSize=3000,hits=3610,misses=71657,hitRate=4%]
RandomAccess[bytes=3733566,reads=71657,travel=25070416343,range=19559154,size=76
690240]
Heap dump reason: user request
Analysis duration: 10442 ms

[devbridie]

This lambda leaks a reference to your activity. https://github.com/ThomasGorisse/sceneform-android-sdk/blob/56cf752680206829296832719161c8e37453e9ca/ux/src/main/java/com/google/ar/sceneform/ux/BaseArFragment.java#L81-L82

[dimiitpk]

How can I prevent that from happening?

[devbridie]

Verify that this method is being called during or near fragment detach: https://github.com/ThomasGorisse/sceneform-android-sdk/blob/56cf752680206829296832719161c8e37453e9ca/ux/src/main/java/com/google/ar/sceneform/ux/BaseArFragment.java#L223