The list – which touches
react-navigation, the types of lists one can use, etc. – was originally posted as a comment on a Github Issue, but deserves way more attention, as it’s great for developers new to RN, who haven’t had to learn this stuff the hard way (yet).
- Try to use React Native’s
VirtualizedListwhere you can and not
array.map()as it allows for asynchronous rendering of components in your viewport which is important for mobile devices.
- With the nature of React, any component that has updates to it’s state/props will re-render all of it’s child components, and likely the children of those components as well. It’s up to you to make sure that your components should update or not by using
shouldComponentUpdateor changing the components to a
PureComponent. There’s often times where you don’t even know that components are re-rendering when they shouldn’t be. Start by checking the app root component and going down from there.
- React Navigation will typically have any screen you have in your navigation state rendered. State-heavy screens may suffer in performance especially when there’s background state updates. It’s also easy to add more routes to your navigation state and more difficult to take them off.
- Make sure that the screen you’re trying to navigate to isn’t heavy on it’s initial render. Your components should preferably be light on the first render and accumulate with data later from interaction and server responses. react-navigation will only transition to the screen once it’s typically fully rendered. One thing that could help is configuring
SectionListcomponent. Otherwise this may take seconds to render new screens using react-navigation.
renderItemfunction should render stateless list item components. If it needs state context (e.g. whether the list item is expanded or selected), it should be using the parent’s state as seen in the documentation.
- Unusual things may start happening if you render more than one
VirtualizedListin one component (e.g. rendering only the current render batch and no more).
- Avoid wrapping your
ScrollView, as it will render all child components.
FlatLists implement on top of
ScrollViews so you can use most
- Develop Android-first. iOS performance is guaranteed and you will notice performance issues sooner before having to rebuild much of your code base. React-Native was built first with iOS-only support.
react-native run android --variant=releaseso you can get a more accurate feel of the app’s performance.
- Remove any
console.log()statements from your app when releasing it to production with
react-navigationis a not very performant library especially for Android. It solely uses React Native’s library as a basis for all it’s navigation logic which means any additional screens/views are all loaded on to the one activity/viewcontroller which gives ‘native-like’ navigation but not true navigation. If you went to inspect the app on iOS while the app was running you’d see that the screens in your navigation state are essentially rendered and layered on top of each other.
react-native-navigation(v1) is a suitable alternative if you’d rather want to use the native navigation controllers.
/me nods along.
I’d also add: Implement
FlatList and the like.
I don’t run ads on my blog nor do I do this for profit. A donation however would always put a smile on my face though. Thanks!