software-mansion / software-mansion/react-native-screens
[Android] :: running foreground cause screen fragment memory leak
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 3.7k
- Forks
- 714
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 71
Description
Description
I have an issue with the app memory leak, I have read the old issue https://github.com/software-mansion/react-native-screens/issues/843#issuecomment-832034119
- my app is running foreground service so when I repeat it about 30 times close -> open -> it causes a memory leak does the react native screen have an option to destroy the screen?
- I keep the Android process running but when I close (swipe the app out normally in Android swipe the app out it would be killed) and open the app it increases the app memory do we have the option to destroy it?
- is there any better solution for this case ?
Steps to reproduce
- running foreground service and keeping the app processes alive
- open -> close -> repeat 10times
Snack or a link to a repository
https://github.com/chanphiromsok/rnn-screen-leak
Screens version
3.30.1
React Native version
0.74.2 and 0.73
Platforms
Android
JavaScript runtime
Hermes Engine
Workflow
Expo managed workflow
Architecture
Paper (Old Architecture)
Build type
Release mode
Device
Real device
Device model
Samsung Galaxy S10 + any Android devices
Acknowledgements
Yes
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked reproduction repository and reproduce the leak on Android by repeatedly opening and closing the app while the foreground service keeps the process alive. Trace the react-native-screens lifecycle during those transitions and compare memory behavior with the reported versions; done requires a confirmed cause and an actionable fix or documented limitation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, react-native, typescript
- Domain
- mobile, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100