From 6b2ac413d12b9b7bbc754c8dcd22a570790fecf1 Mon Sep 17 00:00:00 2001 From: Website Deployment Script Date: Wed, 26 Apr 2017 20:10:45 +0000 Subject: [PATCH] Updated docs for next --- releases/next/docs/performance.html | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/releases/next/docs/performance.html b/releases/next/docs/performance.html index bd8f9b92ce3..459109857bf 100644 --- a/releases/next/docs/performance.html +++ b/releases/next/docs/performance.html @@ -28,7 +28,14 @@ and so they are not interrupted by frame drops on the JavaScript thread.

S The scroll events are dispatched to the JS thread, but their receipt is not necessary for the scroll to occur.

Common sources of performance problems #

Running in development mode (dev=true) #

JavaScript thread performance suffers greatly when running in dev mode. This is unavoidable: a lot more work needs to be done at runtime to provide you with good warnings and error messages, such as validating propTypes and various other assertions. Always make sure to test performance in release builds.

Using console.log statements #

When running a bundled app, these statements can cause a big bottleneck in the JavaScript thread. This includes calls from debugging libraries such as redux-logger, -so make sure to remove them before bundling.

ListView initial rendering is too slow or scroll performance is bad for large lists #

Use the new FlatList or SectionList component instead. +so make sure to remove them before bundling. +You can also use this babel plugin that removes all the console.* calls. You need to install it first with npm i babel-plugin-transform-remove-console --save, and then edit the .babelrc file under your project directory like this:

{ + "env": { + "production": { + "plugins": ["transform-remove-console"] + } + } +}

This will automatically remove all console.* calls in the release (production) versions of your project.

ListView initial rendering is too slow or scroll performance is bad for large lists #

Use the new FlatList or SectionList component instead. Besides simplifying the API, the new list components also have significant performance enhancements, the main one being nearly constant memory usage for any number of rows.

JS FPS plunges when re-rendering a view that hardly changes #

If you are using a ListView, you must provide a rowHasChanged function that can reduce a lot of work by quickly determining whether or not a row needs to be re-rendered. If you are using immutable data structures, this would be as simple as a reference equality check.

Similarly, you can implement shouldComponentUpdate and indicate the exact conditions under which you would like the component to re-render. If you write pure components (where the return value of the render function is entirely dependent on props and state), you can leverage PureRenderMixin to do this for you. Once again, immutable data structures are useful to keep this fast -- if you have to do a deep comparison of a large list of objects, it may be that re-rendering your entire component would be quicker, and it would certainly require less code.

Dropping JS thread FPS because of doing a lot of work on the JavaScript thread at the same time #

"Slow Navigator transitions" is the most common manifestation of this, but there are other times this can happen. Using InteractionManager can be a good approach, but if the user experience cost is too high to delay work during an animation, then you might want to consider LayoutAnimation.

The Animated api currently calculates each keyframe on-demand on the JavaScript thread, while LayoutAnimation leverages Core Animation and is unaffected by JS thread and main thread frame drops.

One case where I have used this is for animating in a modal (sliding down from top and fading in a translucent overlay) while initializing and perhaps receiving responses for several network requests, rendering the contents of the modal, and updating the view where the modal was opened from. See the Animations guide for more information about how to use LayoutAnimation.

Caveats:

Moving a view on the screen (scrolling, translating, rotating) drops UI thread FPS #

This is especially true when you have text with a transparent background positioned on top of an image, or any other situation where alpha compositing would be required to re-draw the view on each frame.