Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ListView] renders all rows? #499

Closed
luics opened this issue Mar 30, 2015 · 83 comments
Closed

[ListView] renders all rows? #499

luics opened this issue Mar 30, 2015 · 83 comments

Comments

@luics
Copy link

@luics luics commented Mar 30, 2015

There're 8 visible rows in screen after refreshing, but there're 15 rows found in chrome react tab.

Will you implement ListView with UITableView in future version?

Thank you.

@colinramsay
Copy link
Contributor

@colinramsay colinramsay commented Mar 30, 2015

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.

@vjeux
Copy link
Contributor

@vjeux vjeux commented Mar 30, 2015

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.

@luics luics changed the title ListView renders all rows. ListView renders all rows? Mar 31, 2015
@luics
Copy link
Author

@luics luics commented Mar 31, 2015

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

@drkibitz
Copy link
Contributor

@drkibitz drkibitz commented Mar 31, 2015

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?

@ide
Copy link
Contributor

@ide ide commented Mar 31, 2015

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

@drkibitz
Copy link
Contributor

@drkibitz drkibitz commented Mar 31, 2015

@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.

@drkibitz
Copy link
Contributor

@drkibitz drkibitz commented Mar 31, 2015

Those profiles were from attaching to iPad Air simulator.

@vjeux
Copy link
Contributor

@vjeux vjeux commented Mar 31, 2015

cc @bryceredd who's been investigating React Native performance

@vjeux
Copy link
Contributor

@vjeux vjeux commented Apr 1, 2015

Closing this since it's not very actionable.

@vjeux vjeux closed this Apr 1, 2015
@drkibitz
Copy link
Contributor

@drkibitz drkibitz commented Apr 1, 2015

@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?

@vjeux vjeux reopened this Apr 1, 2015
@vjeux
Copy link
Contributor

@vjeux vjeux commented Apr 1, 2015

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

@drkibitz
Copy link
Contributor

@drkibitz drkibitz commented Apr 1, 2015

@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.

@Kureev
Copy link
Contributor

@Kureev Kureev commented Apr 3, 2015

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"

@sahrens
Copy link
Contributor

@sahrens sahrens commented Apr 3, 2015

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).

@samfriend
Copy link

@samfriend samfriend commented Apr 13, 2015

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

@leecade
Copy link

@leecade leecade commented Apr 14, 2015

👍

@Iragne
Copy link
Contributor

@Iragne Iragne commented May 31, 2015

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

@ghost
Copy link

@ghost ghost commented Aug 4, 2015

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.

@sghiassy
Copy link

@sghiassy sghiassy commented Aug 7, 2015

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
comparision

@josebalius
Copy link

@josebalius josebalius commented Aug 7, 2015

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

@tehong
Copy link

@tehong tehong commented Feb 10, 2016

@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.

@drkibitz
Copy link
Contributor

@drkibitz drkibitz commented Feb 11, 2016

@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.

@nicklockwood
Copy link
Contributor

@nicklockwood nicklockwood commented Feb 11, 2016

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.

@drkibitz
Copy link
Contributor

@drkibitz drkibitz commented Feb 11, 2016

@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!

@nicklockwood
Copy link
Contributor

@nicklockwood nicklockwood commented Feb 11, 2016

@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.

@jamesfzhang
Copy link
Contributor

@jamesfzhang jamesfzhang commented Feb 11, 2016

@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!

@x4080
Copy link

@x4080 x4080 commented Feb 24, 2016

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

@bvaughn
Copy link
Contributor

@bvaughn bvaughn commented Mar 30, 2016

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.

@THIAGOWESLLEY2
Copy link

@THIAGOWESLLEY2 THIAGOWESLLEY2 commented Mar 30, 2016

@mkonicek
Copy link
Contributor

@mkonicek mkonicek commented Jul 29, 2016

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.

@obaniu2006
Copy link

@obaniu2006 obaniu2006 commented Sep 26, 2016

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

@roysG
Copy link

@roysG roysG commented Nov 16, 2016

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

@roysG
Copy link

@roysG roysG commented Nov 21, 2016

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

@obaniu2006
Copy link

@obaniu2006 obaniu2006 commented Nov 21, 2016

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

@ptomasroos
Copy link
Contributor

@ptomasroos ptomasroos commented Dec 20, 2016

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

@obaniu2006
Copy link

@obaniu2006 obaniu2006 commented Dec 21, 2016

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

@sibelius
Copy link

@sibelius sibelius commented Jan 17, 2017

WindowedListView is working fine

@sibelius
Copy link

@sibelius sibelius commented Jan 25, 2017

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

@chuyik
Copy link

@chuyik chuyik commented Jan 25, 2017

So why this is closed if it's still not solved?

Seams like we don't have any existing solutions if we want to approach reuse cells on Android.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.