Potential leak on FlatList + images

[mfrachet]

Is this a bug report?

Yes, it seems so

Have you read the Contributing Guidelines?

Yes

Environment

1. react-native -v:

• react-native-cli: 2.0.1
• react-native: 0.47.2

2. node -v: v8.4.0
3. npm -v: v5.3.0
4. yarn --version: v1.0.0

• Target Platform: Android

• Development Operating System: macOS Sierra v10.12.6

Steps to Reproduce

(Write your steps here:)

1. use a low memory device (128mb for example)
2. create a FlatList with "infinite" images
3. See the app crash and android monitor

Expected Behavior

Image are well garbaged while scrolling FlatList (recycle view + fresco disk caching ?)

Actual Behavior

It 'actually throws OOM errors :

Here's the Android monitoring shot while I m playing with the app. We can see that the memory is always jumping but rarely dropping, and so forth, OOM at some moment

And here's what I can see from the Eclipse Memory Analyzer stuff :

Reproducible Demo

• Clone the following repo : https://github.com/mfrachet/potentialLeak
• Cd && npm i
• React-native run-android (on real device for myself)

[robbywh]

I encountered the same problem, any solution for this problem ?

[mfrachet]

Just a little up to not forget :/

[irwing-reza]

Any updates?

[kesha-antonov]

👍 +1

[ngoducduy]

Any solution for this ?

[suetming]

Any solution for this ?

[nico1510]

I'm seeing this too 🙁

[cglacet]

Its been two months, did you had any feedback on this?

[cglacet]

Isn't it related to this. I haven't ran your code, but mine had similar issue and stoping remote debugging worked.

[mfrachet]

We have this bug in production, the repo is simply a reproduction in dev mode, but it exists for us in production.

No feedbacks for now :/

[RafaelMagalhaesN]

Last month I had the same problem/bug with the app in production.

I found a momentary solution (workaround?) when I added the property 'removeClippedSubviews' in FlatList.

<FlatList data={this.state.dataSet} keyExtractor={this._keyExtractor} renderItem={this._renderItem} removeClippedSubviews />

In my case, it worked well and decreased memory leaks.

[lhfiii]

@RafaelMagalhaesN tried, but no help

[pavanmehta91]

Any solutions for this yet? Can anybody explain why it's happening despite using flatlist? Does flatlist not automatically garbage collect or free the memory of the images not in the view?

[pavanmehta91]

according to the docs removeClippedSubviews is by default true for FlatList

[pavanmehta91]

Okay

[brentvatne]

use removeClippedSubviews, it does not defualt to true for FlatList or SectionList, only for ListView

[react-native-bot]

Thanks for posting this! It looks like you may not be using the latest version of React Native, v0.53.0, released on January 2018. Can you make sure this issue can still be reproduced in the latest version?

I am going to close this, but please feel free to open a new issue if you are able to confirm that this is still a problem in v0.53.0 or newer.

_{How to Contribute • What to Expect from Maintainers}

[kelset]

(FYI, refer to #13413 for followup on this)

[alzalabany]

this is still active on .54, adding an Image to Flatlist cause huge memory leak on android.

[thewalrusisben]

I had been running to this with my application, which is a Flatlist that contains between 10 - 20 GIFs at a time. I was able to solve the crashing and subsequent choppiness that I got from using removeClippedSubviews by also implementing FLAnimatedImage. Here's what ended up doing the trick, in total:

1. Add removeClippedSubviews
2. Set initialNumToRender to some appropriate value that covers the contents of the initial view
3. Pass in State to extraData as recommended in the React Native Docs (0.54)
4. Implement my Flatlist's renderItem as a PureComponent.
5. Swap out Image elements for FLAnimatedImages instead.

1 - 4 all had performance benefits, and helped drastically reduce the total memory load, and #5 took it over the edge with extra memory reduction and (mostly) substantially smoother scrolling.

I haven't verified yet which of these changes are doing the heavy lifting, but all of them taken together definitely made the difference.

Also, don't forget to turn off the remote debugger when working with a real device.

hope this helps someone else!