React-native: [Navigator Performance] Memory is not released after scene popped in Navigator

[chenjun1011]

I have a large list rendered in Navigator, but when I popped the scene, memory was not released.

The memory usage in Instruments was like this.

But if I destroy the list without Navigator, memory usage would drop quickly as the following picture show:

So anyone please could give me a hint on this problem? Or anyone else has this problem too?

[facebook-github-bot]

Hey chenjun1011, thanks for reporting this issue!

React Native, as you've probably heard, is getting really popular and truth is we're getting a bit overwhelmed by the activity surrounding it. There are just too many issues for us to manage properly.

• If this is a feature request or a bug that you would like to be fixed by the team, please report it on Product Pains. It has a ranking feature that lets us focus on the most important issues the community is experiencing.
• If you don't know how to do something or not sure whether some behavior is expected or a bug, please ask on StackOverflow with the tag react-native or for more real time interactions, ask on Discord in the #react-native channel.
• We welcome clear issues and PRs that are ready for in-depth discussion; thank you for your contributions!

[noscripter]

+1

[yuanyan]

Memory is big problem.

[ippa]

+1, I think I've experienced this as well (android, devmode & debug off) when transitioning between two Navigator scenes (one is a small list) are slow but getting slower and finally grinds to a halt.

[guangwong]

+1

[362228416]

+1

[dajomu]

+1

[ACCTFORGH]

+1, when a certain page is pushed onto the route stack again, the pope screens seem to be reused and variables with old data not re-initialized. This causes extra work in purposely clearing the variables declared and also confusion in usage.

[jozn]

+1 Memory usage is big problem for me. I wanted to post slimier problem for android. I have monitored android app memory usage, most of memory seems to be eated by none-java code(dalvik heap), in adb command report it reports most of memory is used by 'Unknown'. this is probably is javascript VM, (javascriptcore), and some other react-native c++ tools (NDK stuff). i hoe this problem resolve.

[satya164]

Please consider creating product pains post and upvoting there.

[cnsnake11]

+1

[toriumi0118]

I also run into this problem in the debug build.
Although, it may not be happened in the release build for my application, which is not the match memory remain.

[jozn]

This memory leak is related to #4963

[cosmith]

+1, please upvote here on Product Pains for more visibility! https://productpains.com/post/react-native/navigator-performance-memory-is-not-released-after-scene-popped-in-navigator/

[afilp]

+1

[afilp]

In our iOS app, memory is increasing even when the app is "idle" (user does nothing and views are settled).

If I use the replace instead of push in the Navigator then this does not happen, so it is clearly a Navigator issue. Is there any fix for this, as this made us use only the replace method which means that we have no back functionality?

[ericvicenti]

@af7 , Navigator does not unmount scenes that are off screen, because you might want to quickly go back and keep internal state like scroll position.

It sounds like we may be talking about 3 issues here:

1. Navigator does not unmount any of the current scenes - known design problem. We have ideas to address this in the RFC of the next navigator: https://github.com/ericvicenti/navigation-rfc/issues/4
2. Increasing memory usage while idle, as experienced by @af7 . We should track this in a separate issue. @hedgerwang, have you seen any memory issues with Navigator while idle?
3. This issue as described by the title: memory is not freed for popped scenes. From what I can tell on this thread, it seems to be Android-only and may be the same thing as #4963

[kiatweitan]

+1 old variables not re-initialized

[lacker]

This issue seems like it went a few different ways but overall I think it led into a feature request for better navigation which is in progress so I am going to close this issue.

[ephemer]

10789 contains a fix for this on iOS. We aren't running Android yet so that must be a separate issue (possibly with a similar fix though). That said, this bug does exist on iOS, as I realised last week, and as reported by OP @chenjun1011, so I'm assuming others will find it via this issue. @lacker can you re-open this until the PR gets merged?

@ericvicenti it is desirable for views still on the navigation stack to be retained, but not for views beyond the end of the navigation stack. As mentioned, this is definitely still an issue on iOS. It's easy to verify by making pushing a large view onto a NavigatorIOS (our custom view component loads a lot of images > 50MB) and then popping via navigator.pop() - that large view will not be cleaned up until something is pushed or popped again. Again, that is easy to verify by putting a log or breakpoint inside that view's deinitializer.

Logically it is unnecessary to retain views beyond the end of the stack, it's just that it doesn't matter unless that view is quite large like ours is. Happily, the fix is also simple and logically correct 👍

[ericvicenti]

This issue was about Navigator and not NavigatorIOS.

But regardless, thanks for fixing it! The issue is super clear as you have described it, and your fix makes sense, so I've started merging it.

[ephemer]

@ericvicenti thanks!

[otoinsa]

Android still never clears the whole route stack (after 40 views app becomes slow and will eventually crash). Why is this closed?

[jasongrishkoff]

Also having major issues with memory building up for each view that I go to -- to the point that the app becomes the #1 candidate for garbage collection/memory cleanup when it is backgrounded. This is a problem because it's a streaming music app, and staying alive in the background is essential.

[ambarc]

our app at rest (login view with 3 sliding images) takes up more mem (120MB) than a reasonably active slack app. agreed this is opaque feedback. RN 0.35. investigating instruments in iOS.