I wonder if this is related to the default value of scrollRenderAheadDistance:

http://facebook.github.io/react-native/docs/listview.html#scrollrenderaheaddistance

It defaults to 2000 pixels unless you override it and with 15 rows it might not go above that and so will render everything when you scroll? This is just a guess but it might be worth tweaking the props for this component to see if you can affect this behaviour.

React Native is using a different optimization strategy than iOS. Here's a summary

Load balancing

In UITableView, when an element comes on screen, you have to synchronously render it. This means that you've got less than 16ms to do it. If you don't, then you drop one or multiple frames. If you are rendering complex elements like newsfeed stories, it's basically impossible to meet this schedule so you're doomed to drop frames.

With ListView, when you reach the end of the current screen, you can prepare in advance more rows to be rendered. Those rows will be rendered in a different thread so won't freeze the UI thread while processing. The reason why it is working is that the load is not evenly spread. You don't need to render a new story on every single frame, most frames are just scrolling and don't need new stories to appear.

ListView will also render one element at a time, so if you are interacting with some element while rendering more rows, it won't block until all the rows have been pre-rendered, it will only block for one row.

Memory management

UITableView is very conservative memory-wise, it aggressively reuses cells. This decision was made back in the iPhone 1 where memory was extremely scarce. The problem with this is that reusing cell is extremely error prone for the developer. You are given a dirty object, from which you have no idea what mutations happened, and you need to reconfigure it to look like what you want. In our iOS app, this caused SOOO many bugs.

The problem of reusing cell is that some cells have internal state (video player running, text input, horizontal scroll position...) When you reuse them, you need to be able to serialize that state and put it back. This is not always possible nor easy, so you usually either loose this state or it propagates on the new row and causes bugs.

What we found out on React Native is that it is fast enough on iphone 4s to create new cells for every single row. So, we don't need to impose this very hard constraint on ourself. In your screenshot, you noticed that we don't remove rows after you scrolled for a while. That's not entirely correct, we don't remove the virtual dom representation on the React side (what you see in the chrome dev tools), but we do remove those elements from the "dom" and keep their reference.

When they are visible again, we put them back on the dom. In case we have low memory or the list is too big, we may destroy those and recreate them from scratch (loosing the state as mentioned above) in the future. We haven't done this performance optimization yet, but the user code wouldn't be impacted.

We tried to delete the iOS views aggressively but we found out that doing so was actually very expensive. It was better to leave them hanging than to remove them.

Change Detection

In ListView, we have a DataSource object that favors immutability. If you have a list of 1000 elements to render, you want to make those 1000 elements immutable, meaning that you can check the previous one === the next one and instantly know if something changed. This way, when anything change, the only thing you've got to do is to traverse those two lists and do those very fast equality checks and know what rows changed. And then update only those.

Layout

In UITableView, you've got to specify the layout of every single row even when they are not being displayed on screen. So, in cases where it's not a fixed size, you've got to basically render the element to know its size, and pay that high cost up front. It's also very annoying to do so manually.

In ListView, since React Native owns the layout system, you don't need to do all that painstaking manual computation yourself. When a row is rendered, it'll update the size. The only downside is that the scrollbar is a little funky, but I'm sure we'll be able to come up with heuristics to smooth it out in the future.

@vjeux thx, it's really clear and useful.

Something doesn't seem to be working as intended just yet. After scrolling a very long list view with images, and 4 rows visible in vertical ipad air 2, everything seems to be working as @vjeux describes, except the memory just keeps climbing and climbing. And the most alarming thing is that scrolling (after scrolling to the bottom), can cause main thread to easily eat over 100-130% of cpu, while the JSCore thread stays quiet. This is very different to the 1-3% taken by just JSCore when scrolling from the top after the initial render. It is very apparent that the app is unstable while the listview's rows all remain in memory, and the main thread is blocked for about a second give or take while a listview in this state is unmounted, and can even result in a crash. Just a reminder, this is all on an iPad Air 2.

I also tried the "experimental feature" of removeClippedSubviews for ListView. This initially did seem to help with memory, but it was causing a crash. I assumed this was the "experimental" part, and haven't dug in there just yet ;)

What I'm wondering is if I am just missing something? Do I have the capability to remove images myself using onChangeVisibleRows, should I consider this? Would it be worth more getting removeClippedSubviews stable, or should I start contemplating a new version of list view with recycling?

Does Instruments provide any insight into what's leaking? (specifically wondering if the problem is in JS or Obj-C)

@ide I'm a noob at instruments profiler... So here's brief summary from me taking a look at it.

cpu profile looks like most of the time is spent here (recursing through subviews), in RCTView.m :

- (void)react_updateClippedSubviewsWithClipRect:(CGRect)clipRect relativeToView:(UIView *)clipView

In memory profile major causes of persisted memory (645 MB total) are:

• VM: CG Graphics Data (410 MB)
• VM: CoreAnimation (141 MB)
• VM: JS Garbage Collector (61 MB)
• ...

Unmount the ListView component, and total persisted memory drops to 74 MB total:

• VM: JS Garbage Collector 58 MB
• VM: CoreUI image data
• ...

I have to think I'm doing something wrong, or maybe the ListView just isn't prepared for what I'm throwing at it.

Those profiles were from attaching to iPad Air simulator.

cc @bryceredd who's been investigating React Native performance

Closing this since it's not very actionable.

@vjeux What would make this actionable? I asked a few questions in this thread that was answered by closing the issue? I've also still been digging through the innards of the ListView implementation, as well as the crash caused by removeClippedSubviews: true. The title "ListView renders all rows?" seems appropriate based on memory consumption no?

Sorry, trying to clean up the hundred plus issues we had, I was a bit too quick on this one.

@vjeux No worries, and thanks ;)

What I've found so far regarding the removeClippedSubviews: true crash

I'm seeing it happen on line 217 of RCTScrollView:

  UIView *nextHeader = nextDockedIndex >= 0 ? contentView.subviews[nextDockedIndex] : nil;

When I change the data source to contain only one section (same amount of rows), this crash does not occur, and I can see that the views are being clipped.

In this case, the memory is lowered to about 1/2-2/3 what is was before, but still very high, and cpu is not spiking as it did on minimal scroll, also about 1/2-2/3 of what is was before.

It's totally insane: my iPhone 5c crashes after 700 list items. If I'm going to write a chat - it's blocking for me.

Also I got a lot of "Cannot find single active touch"

removeClippedSubviews is our current stopgap that makes the groups app work - can you guys try scrolling in that app and see what you think of the perf/stability?

We definitely need to fix crashes when you have removeClippedSubviews - I don't think we tested thoroughly with sticky headers (they aren't used in groups), so that might be the issue.

Note on OP - the react tab just shows the react elements in JS. Just because they show up there doesn't mean they are in the actual UIView hierarchy (and you should find they are not all in the UIView hierarchy if you enable removeClippedSubviews).

my < ListView pagingEnabled={true} onEndReached={this.loadAnotherFiftyArticles} >

50 rows/pages of < Image / > < Title/ > < Description/ >

3rd Load append (total 150)

Received memory warning

Received memory warning

Received memory warning

Crash Physical iPhone 6 Plus

Also I got a lot of "Cannot find single active touch" time to time

👍

Hi all
i create the PR #1406
It's solve for me the issue if you have a better idea to solve it feel free

Thanks

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

I took a stab this.

In my perf testing I was seeing constant memory allocations using ListView as the user scrolls down long lists. This is obviously problematic for reasons that don't need to be explained.

In response, I created an NPM package react-native-sglistview: https://github.com/sghiassy/react-native-sglistview.

The package isn't where I want it yet - but its showing some process

@sghiassy This looks interesting, will def check it out.

My colleague is currently working on re-writing our RN ListView into a fully native view (we probably wouldn't have used RN at all had we initially known about this performance problem). In the tests I've seen him done, it's MUCH smoother. No promises, but I'll see if we can open source it.

@sghiassy's https://github.com/sghiassy/react-native-sglistview is still a good alternative. I'm using that currently in my app. I've reduced my background image to 1/3 of the size, this allows smoother frame rate and much less usage of the memory. However, I still prefer the native solution if possible.

@jamesfzhang funny you should say that, and an FYI to the RN team. This issue, this component, and the initial comments on this thread, were a huge reason why we did not go with RN. Yes most of the framework was pretty awesome, but this particular component is a huge misfire, and it was disappointing to see the debate that seemed to favor its implementation.

I'm afraid we didn't do a great job of communicating our position on this.

We created React Native to solve our own app development requirements (which include long scrolling lists of content) and when we found that ListView was satisfactory to meet our requirements, we prioritised other features (startup time, network and image loading/decoding performance, etc) over improving it further.

But that is not to say that we don't recognize its deficiencies, and now that we have met our performance and functionality targets in other areas of the framework, improving (or replacing) ListView has moved up to the top of our priority list.

If you are struggling with sluggish performance or out-of-memory issues when using the current ListView for hundreds or thousands of rows, you can expect to see some improvements from us in the near future.

That said, if you are already working on your own solutions, I encourage you to continue doing so, as there are many different types of requirement for this type of view, and we may not be working to solve exactly the same problems that you are.

@nicklockwood Thanks. I appreciate the thorough, timely, and very open response to my comment. Just to make sure you and the team knows it, whenever I make a comment like that, it's always meant as constructive criticism, I know you took it like that, so thank you. Just because we decided against RN for our needs, does not mean it isn't impressive piece of open source software. So keep up the good work, and I'll look forward to seeing the direction this component goes!

@drkibitz understood, and thank you for the constructive feedback - we do take this stuff on board, even if we aren't always in a position to act on it right away.

@nicklockwood Thanks for offering more info on that, much appreciated. The truth is that we absolutely love RN and will look forward to seeing the performance improvements. Thanks and keep up the good work!

Hi, i wondered if the issue is the same in the android part? And android part is using recyclerview right? And it is not using the recycle part?

And I think maybe for best is theres 2 implementation of listview. The react way and the native recycle way for lot of items

Just my 2cents

In belated response to @aleclarson's comment, I've been moving more and more of the core windowing logic for react-virtualized into util functions. I've wondered a little if it would be useful to abstract things further and maybe even move it out into its own package but I didn't know of any immediate uses and I didn't want to spend time doing it just for the sake of doing it.

That being said, if there's any interest or chance to contribute here I'd be happy to.

@drkibitz

Hi there! This issue is being closed because it has been inactive for a while.

But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/listview-renders-all-rows

ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub. GitHub issues have voting too, nevertheless
Product Pains has been very useful in highlighting the top bugs and feature requests:
https://productpains.com/product/react-native?tab=top

Also, if this issue is a bug, please consider sending a pull request with a fix.
We're a small team and rely on the community for bug fixes of issues that don't affect fb apps.

I worte Real Android recycles RecyclerView/ListView,
To solve the problem of RecyclerViewBackedScrollView.

any news from react native team about that?
Is this issue will be fixed in any release?

"removeClippedSubviews = {true}" saved my day!!

removeClippedSubviews work on ios, but don't work on android

@droidwolf according to this 25cd2c5 it should def be working on Android, where do you draw that conclusion from?

ListView experience was not very good。
see the RecyclerViewBackedScrollView source file.
the mViews variable hold all item views in memory.

WindowedListView is working fine

windowedlistview does not well on Android see here: #11950 (comment)