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

[View] Best practice for large number of views (100s)? #3203

Closed
aroth opened this Issue Oct 2, 2015 · 9 comments

Comments

Projects
None yet
7 participants
@aroth
Contributor

aroth commented Oct 2, 2015

I've built a yearly calendar component that is made up of over 400 views (one per month, one per week, one per day, etc...). Unsurprisingly, performance suffers. Loading takes 3 to 5 seconds on the simulator and device.

screen shot 2015-10-02 at 6 39 39 pm

I don't need fine-grained interaction at this level, just a <Touchable.../> around each individual month that presents a detailed view.

Does React Native have a way to improve the performance of this use case? Or perhaps my component be designed without so many views.

I hoped shouldRasterizeIOS might help, but no such luck.

Thanks.

@leafduo

This comment has been minimized.

Show comment
Hide comment
@leafduo

leafduo Oct 9, 2015

I'm guessing you will get a performance problem even using UIKit, if it's the case, then react seems not be able to solve the problem because it's based on UIKit.

I'll try one CALayer for each day, using Core Graphic or one pre-rendered image for each month.

leafduo commented Oct 9, 2015

I'm guessing you will get a performance problem even using UIKit, if it's the case, then react seems not be able to solve the problem because it's based on UIKit.

I'll try one CALayer for each day, using Core Graphic or one pre-rendered image for each month.

@brentvatne

This comment has been minimized.

Show comment
Hide comment
@brentvatne
Collaborator

brentvatne commented Oct 9, 2015

@ide

This comment has been minimized.

Show comment
Hide comment
@ide

ide Oct 9, 2015

Collaborator

@leafduo might be right. With RN (very long-term idea -- not coming soon or even worked on necessarily...) we can apply the techniques from AsyncDisplayKit such as using CALayers instead of UIViews for certain components, and can also precomposite CALayers so that text and images don't necessarily take up their own CALayer even. A static layout could even have a dozen React components and produce just one CALayer!

Anyway as a more pragmatic solution, I would try a few things:

  • turn off dev mode (?dev=false)
  • play around with different ways to do the layout. I am not sure of the performance of flex-wrap but it could be more expensive than other layouts, in case you are using that.
  • use absolute sizes for each Text component. might help.
  • try writing a CalendarMonth view with mostly CALayers and then bridging it to React
Collaborator

ide commented Oct 9, 2015

@leafduo might be right. With RN (very long-term idea -- not coming soon or even worked on necessarily...) we can apply the techniques from AsyncDisplayKit such as using CALayers instead of UIViews for certain components, and can also precomposite CALayers so that text and images don't necessarily take up their own CALayer even. A static layout could even have a dozen React components and produce just one CALayer!

Anyway as a more pragmatic solution, I would try a few things:

  • turn off dev mode (?dev=false)
  • play around with different ways to do the layout. I am not sure of the performance of flex-wrap but it could be more expensive than other layouts, in case you are using that.
  • use absolute sizes for each Text component. might help.
  • try writing a CalendarMonth view with mostly CALayers and then bridging it to React
@aroth

This comment has been minimized.

Show comment
Hide comment
@aroth

aroth Oct 10, 2015

Contributor

@ide @leafduo Thanks for the suggestions. Much faster using CALayers.

With a lot of <View ...>s
With Views

With CALayer
With CALayers

And optimized...
Optimized

Contributor

aroth commented Oct 10, 2015

@ide @leafduo Thanks for the suggestions. Much faster using CALayers.

With a lot of <View ...>s
With Views

With CALayer
With CALayers

And optimized...
Optimized

@aroth aroth closed this Oct 10, 2015

@ide

This comment has been minimized.

Show comment
Hide comment
@ide

ide Oct 10, 2015

Collaborator

@aroth nice! Did you bridge over a higher-level component that contains multiple CALayers (so you no longer have a React component per day)?

Collaborator

ide commented Oct 10, 2015

@aroth nice! Did you bridge over a higher-level component that contains multiple CALayers (so you no longer have a React component per day)?

@aroth

This comment has been minimized.

Show comment
Hide comment
@aroth

aroth Oct 11, 2015

Contributor

@ide I did.

<ARCalendarMonth key={ key } 
               month={ month.title }  
               weeks={ month.weeks }  
                data={ dayData } />

The bridged module creates a CALayer with CATextLayer sublayers for each day. I then flatten the whole thing into a bitmap. Works great. Thanks again.

Contributor

aroth commented Oct 11, 2015

@ide I did.

<ARCalendarMonth key={ key } 
               month={ month.title }  
               weeks={ month.weeks }  
                data={ dayData } />

The bridged module creates a CALayer with CATextLayer sublayers for each day. I then flatten the whole thing into a bitmap. Works great. Thanks again.

@ide

This comment has been minimized.

Show comment
Hide comment
@ide

ide Oct 11, 2015

Collaborator

Thanks! Was curious about your approach and glad it's performing a lot zippier for you now.

Collaborator

ide commented Oct 11, 2015

Thanks! Was curious about your approach and glad it's performing a lot zippier for you now.

@sahrens

This comment has been minimized.

Show comment
Hide comment
@sahrens

sahrens Oct 11, 2015

Contributor

One of my favorite parts of react native is the ultimate escape hatch - you
can just write it in native and plug it in if you want :)

It would be nice to create some affordances to optimize this kind of thing
though. Computing your own layout instead of relying on text measurement
could help, as could some compositing and/or CALayer directives on .
ReactART might also work better for cases like this because it draws
straight to the canvas.

Thanks! Was curious about your approach and glad it's performing a lot
zippier for you now.


Reply to this email directly or view it on GitHub
#3203 (comment)
.

Contributor

sahrens commented Oct 11, 2015

One of my favorite parts of react native is the ultimate escape hatch - you
can just write it in native and plug it in if you want :)

It would be nice to create some affordances to optimize this kind of thing
though. Computing your own layout instead of relying on text measurement
could help, as could some compositing and/or CALayer directives on .
ReactART might also work better for cases like this because it draws
straight to the canvas.

Thanks! Was curious about your approach and glad it's performing a lot
zippier for you now.


Reply to this email directly or view it on GitHub
#3203 (comment)
.

@GaudamThiyagarajan

This comment has been minimized.

Show comment
Hide comment
@GaudamThiyagarajan

GaudamThiyagarajan May 24, 2018

What is the best practise for android on this issue? Rendering 100's of touchable is definitely slower.

GaudamThiyagarajan commented May 24, 2018

What is the best practise for android on this issue? Rendering 100's of touchable is definitely slower.

@facebook facebook locked as resolved and limited conversation to collaborators Jul 21, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.