FlatList ist SELBST bereits ein Virtualisierungs-Werkzeug (siehe "React für Profis" Kapitel 32 für das Grundprinzip: nur sichtbare Einträge plus Puffer rendern) – aber die Standardeinstellungen sind ein Kompromiss, kein Optimum. Dieses Kapitel zeigt, wie man ProductListScreens FlatList gezielt für unseren Anwendungsfall abstimmt.

React.memo auf ProductCard anwenden

Genau wie in "React für Profis" Kapitel 31 – der erste, wichtigste Schritt:

// In components/ProductCard.js, ganz am Ende:
import { memo } from 'react';
// ... Komponente wie gehabt ...
export default memo(ProductCard);

getItemLayout: Layout-Berechnung überspringen

Standardmäßig muss FlatList jedes Element erst RENDERN, um seine Höhe zu kennen, bevor es die Scroll-Position korrekt berechnen kann – bei FESTER Elementhöhe (unsere ProductCard hat immer 60px Bildhöhe plus festes Padding, also eine bekannte Gesamthöhe) kann man das umgehen:

// In screens/ProductListScreen.js:
const ITEM_HEIGHT = 84; // 60px Bild + 2×12px Padding

<FlatList
  data={filteredProducts}
  keyExtractor={(item) => item.sku}
  getItemLayout={(data, index) => ({
    length: ITEM_HEIGHT,
    offset: ITEM_HEIGHT * index,
    index,
  })}
  renderItem={/* ... wie gehabt ... */}
/>

getItemLayout teilt FlatList die Position/Höhe JEDES Elements IM VORAUS mit, per einfacher Rechnung statt echtem Rendern – ermöglicht sofortiges Springen zu einer beliebigen Scroll-Position (z. B. programmgesteuertes scrollToIndex) und beschleunigt die initiale Layout-Berechnung spürbar.

Weitere Stellschrauben: windowSize, maxToRenderPerBatch, removeClippedSubviews

<FlatList
  /* ... bisherige Props ... */
  windowSize={5}              // Standard: 21 (10 Bildschirme vor/hinter dem sichtbaren Bereich)
  maxToRenderPerBatch={10}    // wie viele Elemente pro Render-Batch verarbeitet werden
  updateCellsBatchingPeriod={50} // Millisekunden zwischen Batches
  removeClippedSubviews={true}   // entfernt außerhalb sichtbare native Views komplett
/>

• windowSize: Vielfaches der Bildschirmhöhe, das VOR und NACH dem sichtbaren Bereich vorgerendert wird – kleinere Werte sparen Speicher/Rechenzeit, riskieren aber sichtbares "Nachladen" bei sehr schnellem Scrollen.
• maxToRenderPerBatch + updateCellsBatchingPeriod steuern zusammen, wie "häppchenweise" gerendert wird – kleinere Batches halten die App reaktionsfähiger, verlängern aber die Zeit bis alle sichtbaren Elemente fertig gerendert sind.
• removeClippedSubviews: entfernt aus dem sichtbaren Bereich gescrollte Elemente auf ANDROID auf native Ebene komplett aus dem View-Baum (nicht nur "unsichtbar" gemacht) – auf iOS historisch weniger zuverlässig, VOR dem Einsatz auf beiden Plattformen testen.

Bonus: FlashList als Drop-in-Ersatz

Shopify's @shopify/flash-list ist eine performance-optimierte FlatList-Alternative mit fast identischer API (oft reicht ein simpler Import-Tausch) – nutzt intern Zell-Recycling (bestehende native Views werden wiederverwendet statt neu erstellt/zerstört) statt Neu-Mount bei jedem gescrollten Element. Für sehr lange Listen (hunderte/tausende Einträge, siehe die "Bestellhistorie"-Virtualisierung aus "React für Profis" Kapitel 32) oft die bessere Wahl als reines FlatList-Tuning.

npx expo install @shopify/flash-list