Facebook/react-native
1
0
Fork 0
mirror of https://github.com/facebook/react-native.git synced 2025-11-01 09:14:26 +00:00
Code Issues Packages Projects Releases Wiki Activity

Deploy website

Browse Source 
Deploy website version based on bfb715698c5027ce91946d725d36b101a512db97
This commit is contained in:
Website Deployment Script
2019-06-18 01:27:59 +00:00
parent aef807fd9a
commit 3dd5bc230b
2 changed files with 44 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/next/optimizing-flatlist-configuration.html
+22 -21
View File
@@ -75,11 +75,12 @@
<li><p><strong>VirtualizedList:</strong> The component behind <code>FlatList</code> (React Native's implementation of the '<a href="https://bvaughn.github.io/react-virtualized/#/components/List">Virtual List</a>' concept.)</p></li>
<li><p><strong>Memory consumption:</strong> How much information about your list is being stored in memory, which could lead to a app crash.</p></li>
<li><p><strong>Responsiveness:</strong> Application ability to respond to interactions. Low responsiveness, for instance, is when you touch on a component and it waits a bit to respond, instead of responding immediately as expected.</p></li>
<li><p><strong>Blank areas:</strong> When <code>VirtualizedList</code> couldn't render your items fast enough, you enter on a part of your list with non rendered components.</p></li>
<li><p><strong>Window:</strong> The viewport (the area size in which items should be rendered).</p></li>
<li><p><strong>Blank areas:</strong> When <code>VirtualizedList</code> can't render your items fast enough, you may enter a part of your list with non-rendered components that appear as blank white space.</p></li>
<li><p><strong>Viewport:</strong> The visible area of content that is rendered to pixels.</p></li>
<li><p><strong>Window:</strong> The area in which items should be mounted, which is generally much larger than the viewport.</p></li>
</ul>
<h2><a class="anchor" aria-hidden="true" id="props"></a><a href="#props" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Props</h2>
<p>Here are a list of props that can help to improve the <code>FlatList</code>:</p>
<p>Here are a list of props that can help to improve <code>FlatList</code> performance:</p>
<h3><a class="anchor" aria-hidden="true" id="removeclippedsubviews"></a><a href="#removeclippedsubviews" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>removeClippedSubviews</h3>
<table>
<thead>
@@ -89,9 +90,9 @@
<tr><td>Boolean</td><td>False</td></tr>
</tbody>
</table>
<p>If <code>true</code>, unmount components that are off of the window.</p>
<p><strong>Pros:</strong> This is very memory friendly, as you will always have a little amount of rendered items instead of the whole list.</p>
<p><strong>Cons:</strong> Be aware that this implementation can have bugs, such as missing content (mainly observed on iOS) if you use it on a component that will not unmount (such as a root navigation scene). It also can be less performant, having choppy scroll animations for big lists with complex items on old devices, as it makes complicated calculations per scroll.</p>
<p>If <code>true</code>, views that are outside of the viewport are detached from the native view hierarchy.</p>
<p><strong>Pros:</strong> This reduces time spent on the main thread, and thus reduces the risk of dropped frames, by excluding views outside of the viewport from the native rendering and drawing traversals.</p>
<p><strong>Cons:</strong> Be aware that this implementation can have bugs, such as missing content (mainly observed on iOS), especially if you are doing complex things with transforms and/or absolute positioning. Also note this does not save significant memory because the views are not deallocated, just detached.</p>
<h3><a class="anchor" aria-hidden="true" id="maxtorenderperbatch"></a><a href="#maxtorenderperbatch" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>maxToRenderPerBatch</h3>
<table>
<thead>
@@ -101,9 +102,9 @@
<tr><td>Number</td><td>10</td></tr>
</tbody>
</table>
<p>It is a <code>VirtualizedList</code> prop that can be passed directly to <code>FlatList</code>. Control the amount of items rendered per batch, which is the next chunk of items rendered on every scroll.</p>
<p><strong>Pros:</strong> Setting a bigger number means less visual blank areas when scrolling (a better the fill rate).</p>
<p><strong>Cons:</strong> More items per batch means less javascript performance, which means less responsiveness (clicking a item and opening the detail). If you have a static and non-interactive list, this could be the way to go.</p>
<p>It is a <code>VirtualizedList</code> prop that can be passed through <code>FlatList</code>. This controls the amount of items rendered per batch, which is the next chunk of items rendered on every scroll.</p>
<p><strong>Pros:</strong> Setting a bigger number means less visual blank areas when scrolling (increases the fill rate).</p>
<p><strong>Cons:</strong> More items per batch means longer periods of JavaScript execution potentially blocking other event processing, like presses, hurting responsiveness.</p>
<h3><a class="anchor" aria-hidden="true" id="updatecellsbatchingperiod"></a><a href="#updatecellsbatchingperiod" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>updateCellsBatchingPeriod</h3>
<table>
<thead>
@@ -113,9 +114,9 @@
<tr><td>Number</td><td>50</td></tr>
</tbody>
</table>
<p>While <code>maxToRenderPerBatch</code> tells the amount of items rendered per batch, setting <code>updateCellsBatchingPeriod</code> tells to your <code>VirtualizedList</code> the delay in milliseconds between batch renders (how frequently your component will be rendering the windowed items).</p>
<p>While <code>maxToRenderPerBatch</code> tells the amount of items rendered per batch, setting <code>updateCellsBatchingPeriod</code> tells your <code>VirtualizedList</code> the delay in milliseconds between batch renders (how frequently your component will be rendering the windowed items).</p>
<p><strong>Pros:</strong> Combining this prop with <code>maxToRenderPerBatch</code> gives you the power to, for example, render more items in a less frequent batch, or less items in a more frequent batch.</p>
<p><strong>Cons:</strong> Less frequent batches may cause blank areas, More frequent batches may cause responsiveness and performance loss.</p>
<p><strong>Cons:</strong> Less frequent batches may cause blank areas, More frequent batches may cause responsiveness issues.</p>
<h3><a class="anchor" aria-hidden="true" id="initialnumtorender"></a><a href="#initialnumtorender" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>initialNumToRender</h3>
<table>
<thead>
@@ -126,8 +127,8 @@
</tbody>
</table>
<p>The initial amount of items to render.</p>
<p><strong>Pros:</strong> Define precise number of items that would cover the screen for every device. This can be a big performance boost when rendering the list component.</p>
<p><strong>Cons:</strong> Setting a low <code>initialNumToRender</code> may cause to see blank areas.</p>
<p><strong>Pros:</strong> Define precise number of items that would cover the screen for every device. This can be a big performance boost for the initial render.</p>
<p><strong>Cons:</strong> Setting a low <code>initialNumToRender</code> may cause blank areas, especially if it's too small to cover the viewport on initial render.</p>
<h3><a class="anchor" aria-hidden="true" id="windowsize"></a><a href="#windowsize" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>windowSize</h3>
<table>
<thead>
@@ -138,8 +139,8 @@
</tbody>
</table>
<p>The number passed here is a measurement unit where 1 is equivalent to your viewport height. The default value is 21 (10 viewports above, 10 below, and one in between).</p>
<p><strong>Pros:</strong> Bigger <code>windowSize</code> will result in less blank space while scrolling (more performance). On the other hand, Smaller <code>windowSize</code> will result in to render smaller list (less memory consumption).</p>
<p><strong>Cons:</strong> For a bigger <code>windowSize</code>, you will have a bigger memory consumption. For a lower <code>windowSize</code>, you will have lower performance and bigger chance of seeing blank areas.</p>
<p><strong>Pros:</strong> Bigger <code>windowSize</code> will result in less chance of seeing blank space while scrolling. On the other hand, smaller <code>windowSize</code> will result in fewer items mounted simultaneously, saving memory.</p>
<p><strong>Cons:</strong> For a bigger <code>windowSize</code>, you will have more memory consumption. For a lower <code>windowSize</code>, you will have a bigger chance of seeing blank areas.</p>
<h3><a class="anchor" aria-hidden="true" id="legacyimplementation"></a><a href="#legacyimplementation" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>legacyImplementation</h3>
<table>
<thead>
@@ -149,13 +150,13 @@
<tr><td>Boolean</td><td>False</td></tr>
</tbody>
</table>
<p>Make <code>FlatList</code> rely on the older <code>ListView</code> instead of <code>VirtualizedList</code>.</p>
<p><strong>Pros:</strong> This will make your list definitely perform better, as it removes virtualization and render all your items at once.</p>
<p><strong>Cons:</strong> Extra memory consumption and more app crash risk in large lists (100+) with complex items. It also warns that the above tweaks will not work because now it is using <code>ListView</code>.</p>
<p>Make <code>FlatList</code> rely on the older and deprecated <code>ListView</code> instead of <code>VirtualizedList</code>.</p>
<p><strong>Pros:</strong> No risk of seeing blank areas while scrolling. May avoid bugs in <code>VirtualizedList</code>.</p>
<p><strong>Cons:</strong> Extra memory consumption and more app crash risk in large lists (100+) with complex items. It also warns that the above tweaks will not work because now it is using <code>ListView</code>. Many other features are not supported. There may be other bugs since <code>ListView</code> is deprecated.</p>
<h2><a class="anchor" aria-hidden="true" id="list-items"></a><a href="#list-items" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>List items</h2>
<p>There are also some tips about list item components. They are being managed by <code>VirtualizedList</code> a lot, so they need to be fast.</p>
<p>Below are some tips about list item components. They are the core of your list, so they need to be fast.</p>
<h3><a class="anchor" aria-hidden="true" id="use-simple-components"></a><a href="#use-simple-components" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Use simple components</h3>
<p>The more complex your components are, the slower they will render. Try to avoid a lot of logic and nesting in your list items. If you are reusing this list item component a lot in your app, create a component just for your big lists and make them with less logic and less nested as possible.</p>
<p>The more complex your components are, the slower they will render. Try to avoid a lot of logic and nesting in your list items. If you are reusing this list item component a lot in your app, create a component just for your big lists and make them with as little logic and nesting as possible.</p>
<h3><a class="anchor" aria-hidden="true" id="use-light-components"></a><a href="#use-light-components" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Use light components</h3>
<p>The heavier your components are, the slower they render. Avoid heavy images (use a cropped version or thumbnail for list items, as small as possible). Talk to your design team, use as little effects and interactions and information as possible in your list. Show them in your item's detail.</p>
<h3><a class="anchor" aria-hidden="true" id="use-shouldcomponentupdate"></a><a href="#use-shouldcomponentupdate" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Use shouldComponentUpdate</h3>
@@ -167,7 +168,7 @@
<h3><a class="anchor" aria-hidden="true" id="use-cached-optimized-images"></a><a href="#use-cached-optimized-images" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Use cached optimized images</h3>
<p>You can use the community packages (such as <a href="https://github.com/DylanVann/react-native-fast-image">react-native-fast-image</a> from <a href="https://github.com/DylanVann">@DylanVann</a>) for more performant images. Every image in your list is a <code>new Image()</code> instance. The faster it reaches the <code>loaded</code> hook, the faster your Javascript thread will be free again.</p>
<h3><a class="anchor" aria-hidden="true" id="use-getitemlayout"></a><a href="#use-getitemlayout" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Use getItemLayout</h3>
<p>If all your list item components have the same height (or width, for a horizontal list), passing <a href="https://facebook.github.io/react-native/docs/flatlist#getitemlayout">getItemLayout</a> prop removes the need for your <code>FlatList</code> to dynamically calculate it every time. This is a very desirable optimization technique.</p>
<p>If all your list item components have the same height (or width, for a horizontal list), providing the <a href="https://facebook.github.io/react-native/docs/flatlist#getitemlayout">getItemLayout</a> prop removes the need for your <code>FlatList</code> to manage async layout calculations. This is a very desirable optimization technique.</p>
<p>If your components have dynamic size and you really need performance, consider asking your design team if they may think of a redesign in order to perform better.</p>
<h3><a class="anchor" aria-hidden="true" id="use-keyextractor-or-key"></a><a href="#use-keyextractor-or-key" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Use keyExtractor or key</h3>
<p>You can set the <a href="https://facebook.github.io/react-native/docs/flatlist#keyextractor"><code>keyExtractor</code></a> to your <code>FlatList</code> component. This prop is used for caching and as the React <code>key</code> to track item re-ordering.</p>
docs/next/optimizing-flatlist-configuration/index.html
+22 -21
View File
@@ -75,11 +75,12 @@
<li><p><strong>VirtualizedList:</strong> The component behind <code>FlatList</code> (React Native's implementation of the '<a href="https://bvaughn.github.io/react-virtualized/#/components/List">Virtual List</a>' concept.)</p></li>
<li><p><strong>Memory consumption:</strong> How much information about your list is being stored in memory, which could lead to a app crash.</p></li>
<li><p><strong>Responsiveness:</strong> Application ability to respond to interactions. Low responsiveness, for instance, is when you touch on a component and it waits a bit to respond, instead of responding immediately as expected.</p></li>
<li><p><strong>Blank areas:</strong> When <code>VirtualizedList</code> couldn't render your items fast enough, you enter on a part of your list with non rendered components.</p></li>
<li><p><strong>Window:</strong> The viewport (the area size in which items should be rendered).</p></li>
<li><p><strong>Blank areas:</strong> When <code>VirtualizedList</code> can't render your items fast enough, you may enter a part of your list with non-rendered components that appear as blank white space.</p></li>
<li><p><strong>Viewport:</strong> The visible area of content that is rendered to pixels.</p></li>
<li><p><strong>Window:</strong> The area in which items should be mounted, which is generally much larger than the viewport.</p></li>
</ul>
<h2><a class="anchor" aria-hidden="true" id="props"></a><a href="#props" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Props</h2>
<p>Here are a list of props that can help to improve the <code>FlatList</code>:</p>
<p>Here are a list of props that can help to improve <code>FlatList</code> performance:</p>
<h3><a class="anchor" aria-hidden="true" id="removeclippedsubviews"></a><a href="#removeclippedsubviews" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>removeClippedSubviews</h3>
<table>
<thead>
@@ -89,9 +90,9 @@
<tr><td>Boolean</td><td>False</td></tr>
</tbody>
</table>
<p>If <code>true</code>, unmount components that are off of the window.</p>
<p><strong>Pros:</strong> This is very memory friendly, as you will always have a little amount of rendered items instead of the whole list.</p>
<p><strong>Cons:</strong> Be aware that this implementation can have bugs, such as missing content (mainly observed on iOS) if you use it on a component that will not unmount (such as a root navigation scene). It also can be less performant, having choppy scroll animations for big lists with complex items on old devices, as it makes complicated calculations per scroll.</p>
<p>If <code>true</code>, views that are outside of the viewport are detached from the native view hierarchy.</p>
<p><strong>Pros:</strong> This reduces time spent on the main thread, and thus reduces the risk of dropped frames, by excluding views outside of the viewport from the native rendering and drawing traversals.</p>
<p><strong>Cons:</strong> Be aware that this implementation can have bugs, such as missing content (mainly observed on iOS), especially if you are doing complex things with transforms and/or absolute positioning. Also note this does not save significant memory because the views are not deallocated, just detached.</p>
<h3><a class="anchor" aria-hidden="true" id="maxtorenderperbatch"></a><a href="#maxtorenderperbatch" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>maxToRenderPerBatch</h3>
<table>
<thead>
@@ -101,9 +102,9 @@
<tr><td>Number</td><td>10</td></tr>
</tbody>
</table>
<p>It is a <code>VirtualizedList</code> prop that can be passed directly to <code>FlatList</code>. Control the amount of items rendered per batch, which is the next chunk of items rendered on every scroll.</p>
<p><strong>Pros:</strong> Setting a bigger number means less visual blank areas when scrolling (a better the fill rate).</p>
<p><strong>Cons:</strong> More items per batch means less javascript performance, which means less responsiveness (clicking a item and opening the detail). If you have a static and non-interactive list, this could be the way to go.</p>
<p>It is a <code>VirtualizedList</code> prop that can be passed through <code>FlatList</code>. This controls the amount of items rendered per batch, which is the next chunk of items rendered on every scroll.</p>
<p><strong>Pros:</strong> Setting a bigger number means less visual blank areas when scrolling (increases the fill rate).</p>
<p><strong>Cons:</strong> More items per batch means longer periods of JavaScript execution potentially blocking other event processing, like presses, hurting responsiveness.</p>
<h3><a class="anchor" aria-hidden="true" id="updatecellsbatchingperiod"></a><a href="#updatecellsbatchingperiod" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>updateCellsBatchingPeriod</h3>
<table>
<thead>
@@ -113,9 +114,9 @@
<tr><td>Number</td><td>50</td></tr>
</tbody>
</table>
<p>While <code>maxToRenderPerBatch</code> tells the amount of items rendered per batch, setting <code>updateCellsBatchingPeriod</code> tells to your <code>VirtualizedList</code> the delay in milliseconds between batch renders (how frequently your component will be rendering the windowed items).</p>
<p>While <code>maxToRenderPerBatch</code> tells the amount of items rendered per batch, setting <code>updateCellsBatchingPeriod</code> tells your <code>VirtualizedList</code> the delay in milliseconds between batch renders (how frequently your component will be rendering the windowed items).</p>
<p><strong>Pros:</strong> Combining this prop with <code>maxToRenderPerBatch</code> gives you the power to, for example, render more items in a less frequent batch, or less items in a more frequent batch.</p>
<p><strong>Cons:</strong> Less frequent batches may cause blank areas, More frequent batches may cause responsiveness and performance loss.</p>
<p><strong>Cons:</strong> Less frequent batches may cause blank areas, More frequent batches may cause responsiveness issues.</p>
<h3><a class="anchor" aria-hidden="true" id="initialnumtorender"></a><a href="#initialnumtorender" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>initialNumToRender</h3>
<table>
<thead>
@@ -126,8 +127,8 @@
</tbody>
</table>
<p>The initial amount of items to render.</p>
<p><strong>Pros:</strong> Define precise number of items that would cover the screen for every device. This can be a big performance boost when rendering the list component.</p>
<p><strong>Cons:</strong> Setting a low <code>initialNumToRender</code> may cause to see blank areas.</p>
<p><strong>Pros:</strong> Define precise number of items that would cover the screen for every device. This can be a big performance boost for the initial render.</p>
<p><strong>Cons:</strong> Setting a low <code>initialNumToRender</code> may cause blank areas, especially if it's too small to cover the viewport on initial render.</p>
<h3><a class="anchor" aria-hidden="true" id="windowsize"></a><a href="#windowsize" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>windowSize</h3>
<table>
<thead>
@@ -138,8 +139,8 @@
</tbody>
</table>
<p>The number passed here is a measurement unit where 1 is equivalent to your viewport height. The default value is 21 (10 viewports above, 10 below, and one in between).</p>
<p><strong>Pros:</strong> Bigger <code>windowSize</code> will result in less blank space while scrolling (more performance). On the other hand, Smaller <code>windowSize</code> will result in to render smaller list (less memory consumption).</p>
<p><strong>Cons:</strong> For a bigger <code>windowSize</code>, you will have a bigger memory consumption. For a lower <code>windowSize</code>, you will have lower performance and bigger chance of seeing blank areas.</p>
<p><strong>Pros:</strong> Bigger <code>windowSize</code> will result in less chance of seeing blank space while scrolling. On the other hand, smaller <code>windowSize</code> will result in fewer items mounted simultaneously, saving memory.</p>
<p><strong>Cons:</strong> For a bigger <code>windowSize</code>, you will have more memory consumption. For a lower <code>windowSize</code>, you will have a bigger chance of seeing blank areas.</p>
<h3><a class="anchor" aria-hidden="true" id="legacyimplementation"></a><a href="#legacyimplementation" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>legacyImplementation</h3>
<table>
<thead>
@@ -149,13 +150,13 @@
<tr><td>Boolean</td><td>False</td></tr>
</tbody>
</table>
<p>Make <code>FlatList</code> rely on the older <code>ListView</code> instead of <code>VirtualizedList</code>.</p>
<p><strong>Pros:</strong> This will make your list definitely perform better, as it removes virtualization and render all your items at once.</p>
<p><strong>Cons:</strong> Extra memory consumption and more app crash risk in large lists (100+) with complex items. It also warns that the above tweaks will not work because now it is using <code>ListView</code>.</p>
<p>Make <code>FlatList</code> rely on the older and deprecated <code>ListView</code> instead of <code>VirtualizedList</code>.</p>
<p><strong>Pros:</strong> No risk of seeing blank areas while scrolling. May avoid bugs in <code>VirtualizedList</code>.</p>
<p><strong>Cons:</strong> Extra memory consumption and more app crash risk in large lists (100+) with complex items. It also warns that the above tweaks will not work because now it is using <code>ListView</code>. Many other features are not supported. There may be other bugs since <code>ListView</code> is deprecated.</p>
<h2><a class="anchor" aria-hidden="true" id="list-items"></a><a href="#list-items" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>List items</h2>
<p>There are also some tips about list item components. They are being managed by <code>VirtualizedList</code> a lot, so they need to be fast.</p>
<p>Below are some tips about list item components. They are the core of your list, so they need to be fast.</p>
<h3><a class="anchor" aria-hidden="true" id="use-simple-components"></a><a href="#use-simple-components" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Use simple components</h3>
<p>The more complex your components are, the slower they will render. Try to avoid a lot of logic and nesting in your list items. If you are reusing this list item component a lot in your app, create a component just for your big lists and make them with less logic and less nested as possible.</p>
<p>The more complex your components are, the slower they will render. Try to avoid a lot of logic and nesting in your list items. If you are reusing this list item component a lot in your app, create a component just for your big lists and make them with as little logic and nesting as possible.</p>
<h3><a class="anchor" aria-hidden="true" id="use-light-components"></a><a href="#use-light-components" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Use light components</h3>
<p>The heavier your components are, the slower they render. Avoid heavy images (use a cropped version or thumbnail for list items, as small as possible). Talk to your design team, use as little effects and interactions and information as possible in your list. Show them in your item's detail.</p>
<h3><a class="anchor" aria-hidden="true" id="use-shouldcomponentupdate"></a><a href="#use-shouldcomponentupdate" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Use shouldComponentUpdate</h3>
@@ -167,7 +168,7 @@
<h3><a class="anchor" aria-hidden="true" id="use-cached-optimized-images"></a><a href="#use-cached-optimized-images" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Use cached optimized images</h3>
<p>You can use the community packages (such as <a href="https://github.com/DylanVann/react-native-fast-image">react-native-fast-image</a> from <a href="https://github.com/DylanVann">@DylanVann</a>) for more performant images. Every image in your list is a <code>new Image()</code> instance. The faster it reaches the <code>loaded</code> hook, the faster your Javascript thread will be free again.</p>
<h3><a class="anchor" aria-hidden="true" id="use-getitemlayout"></a><a href="#use-getitemlayout" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Use getItemLayout</h3>
<p>If all your list item components have the same height (or width, for a horizontal list), passing <a href="https://facebook.github.io/react-native/docs/flatlist#getitemlayout">getItemLayout</a> prop removes the need for your <code>FlatList</code> to dynamically calculate it every time. This is a very desirable optimization technique.</p>
<p>If all your list item components have the same height (or width, for a horizontal list), providing the <a href="https://facebook.github.io/react-native/docs/flatlist#getitemlayout">getItemLayout</a> prop removes the need for your <code>FlatList</code> to manage async layout calculations. This is a very desirable optimization technique.</p>
<p>If your components have dynamic size and you really need performance, consider asking your design team if they may think of a redesign in order to perform better.</p>
<h3><a class="anchor" aria-hidden="true" id="use-keyextractor-or-key"></a><a href="#use-keyextractor-or-key" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Use keyExtractor or key</h3>
<p>You can set the <a href="https://facebook.github.io/react-native/docs/flatlist#keyextractor"><code>keyExtractor</code></a> to your <code>FlatList</code> component. This prop is used for caching and as the React <code>key</code> to track item re-ordering.</p>