react-native-screens: Memory leak while moving from one screen to another in the same stack

Description

One can observe retained memory while moving across different screens in the application. Even if you have one single stack with 3 different pages, you can observer a memory leak there. I have created a sample project to reproduce this issue. The link is given below

https://github.com/abhaynpai/rn-screens-leak

Screenshots

This is a YouTube video showcasing the leak in the project.

IMAGE ALT TEXT HERE

Steps To Reproduce

The steps are given in this GitHub link - https://github.com/abhaynpai/rn-screens-leak

Expected behavior

No memory leak should be displayed while moving across page.

Actual behavior

While moving between pages you can observe multiple memory leaks.

Snack or minimal code example

// App.js

import React from 'react';
import {NavigationContainer} from '@react-navigation/native';
import {StatusBar} from 'react-native';

import {enableScreens} from 'react-native-screens';

import TestStack from './src/TestStack';

enableScreens();

const App: () => React$Node = () => {
  return (
    <NavigationContainer>
      <StatusBar barStyle="dark-content" />
      {TestStack()}
    </NavigationContainer>
  );
};

export default App;

// ________________________

// TestStack.js

import React from 'react';
import {createNativeStackNavigator} from 'react-native-screens/native-stack';

import TestPage1 from './TestPage1';
import TestPage2 from './TestPage2';
import TestPage3 from './TestPage3';

const Stack = createNativeStackNavigator();

const TestStack = () => {
  return (
    <Stack.Navigator>
      <Stack.Screen name="TestPage1" component={TestPage1} />
      <Stack.Screen name="TestPage2" component={TestPage2} />
      <Stack.Screen name="TestPage3" component={TestPage3} />
    </Stack.Navigator>
  );
};

export default TestStack;

Package versions

  • React: 16.13.1
  • React Native: 0.63.4
  • React Native Screens: 2.18.1

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 5
  • Comments: 16 (5 by maintainers)

Most upvoted comments

The behavior described by the tools as a leak is the consequence of keeping the ScreenFragments in the memory. It is done like this because, in react-native, we cannot destroy and then make new views by restoring the state of the Fragment, since each view has its reactTag etc. The behavior is shown as a leak due to heuristics of the leak detector tools, which say that if onDestroy was called on a Fragment, then the reference to it should not be kept anywhere, but, as mentioned above, it is not applicable to react-native apps, since we do not recreate the views of the Fragment, but rather call remove on the them when they become invisible and then add them back on the Screen becoming visible with the same Screen attached to it.

I hope this resolves the issue, so I will close it since I don’t think we can do much more about it. If you have any questions or can propose other solutions, please write here and I can reopen it.

@omaryoussef - I think the it is somewhat related but not exactly. This issue highlights the actual issue with native navigation + screens.

If you disable enableScreens and run the exact same test then you will not be able to see the memory leak.

I’ve profiled the Navigation router and it doesn’t show any memory leaks. The Navigation router uses Android’s native back stack to manage the scenes. Android doesn’t call onDestroy on a Fragment in the back stack until it’s popped and the pop animation has completed.

Same issue, not sure if it’s a good idea to upgrade to 3.0.0 with this still happening (as the latest release enables screens by default)

@WoLewicki A couple of benefits that spring to mind

  1. Native custom animations - when you add a fragment to the back stack you specify the 4 different animations (enter, exit, popEnter and popExit). Android takes care of running them depending on how the scene is moving through or off the stack. The medley Navigation router example has 4 scenes called north, south, east and west and Android animates them from and to these compass points as they’re popped and pushed. The animations are specified in React and point at a java resource file
  2. Native shared elements - the fragment back stack supports shared element animations. Android plays these animations when the scene is pushed and plays them in reverse when the scene is popped. The zoom Navigation router example shows a list of colors and a color details scene. Android animates the selected color as the details scene is pushed and popped. Notice that you can change the color on the details scene and Android will correctly run the shared element animation on the new color when its popped. Again the animations are fully customisable in React but must point at a java resource file