FlashList v2 vs FlatList: React Native lista teljesítmény 2026

Frissítve: 2026. augusztus 4.

A FlashList v2 ma a legjobb választás minden olyan React Native listához, amelyben legalább pár száz elem van, és a projekt már az Új Architektúrán fut. A FlatList csak akkor marad ésszerű, ha még régi architektúrán vagy, vagy csak 10–30 statikus soron dolgozol. Ebben a cikkben lebontom, mit hoz a Shopify FlashList v2 kiadása, hol veri meg mérhetően a beépített FlatList-et, és mikor van az, hogy mégis a FlatList-nél maradnék. Hat leszállított appból tanultam meg (a legkínosabb módon), hogy a listaválasztás dönti el a felhasználói élményről.

• A FlashList v2 újraírt recycling motorral érkezik, és az Új Architektúra (Fabric) meglétét feltételezi. Régi architektúrán a v1.x-et kell használnod.
• A v2-ben már nincs szükség estimatedItemSize-ra, estimatedListSize-ra vagy overrideItemLayout-ra a legtöbb esetben.
• Hosszú, heterogén listáknál (feed, chat, katalógus) 2–5× kisebb memóriahasználat és lényegesen magasabb FPS scrolláskor.
• Kis, statikus vagy nem-scrollolható listáknál (10–30 elem) a FlatList vagy sima map() gyorsabban implementálható, és nem nehezebb futásra.
• A migráció legtöbbször 30 percen belül elvégezhető, de van pár gyakori buktató: numColumns, keyExtractor, dinamikus magasságú elemek és sticky header viselkedés.
• A FlashList v2 natív masonry, DOM-független sticky header és auto-sizing támogatással érkezik. Ezek a FlatList-ben soha nem lesznek.

Mi a FlashList v2 és miben más?

A FlashList a Shopify nyílt forráskódú listakomponense, amely a beépített FlatList-et hivatott lecserélni gyorsabb, memóriabarátabb megoldással. Az első verzió (2022) még a régi architektúrához igazodott, és a ScrollView köré épült recycler-szerű logikával. A v2 (első stabil 2025-ben) egy teljesen újraírt motor, ami kizárólag az Új Architektúrán (Fabric renderer + JSI) működik.

A gyakorlati különbség onnan látszik, hogy a v2 elhagyja az egész "becslés" munkafolyamatot. A v1-ben az estimatedItemSize értéke határozta meg a scroll pozíció és a virtualizált ablak számításait; ha rosszul saccoltad, ugráló scroll és üres területek voltak a jutalmad. A v2-ben ezt a méretezést a motor runtime-ban méri, ezért heterogén listáknál is stabilan viselkedik.

Fontos: a Shopify a v2-t úgy pozicionálja, hogy nem is drop-in replacement. Több API letisztult, néhány prop eltűnt (pl. estimatedItemSize, overrideItemLayout), a numColumns viselkedése is módosult a masonry natív támogatásának köszönhetően. A migrációt tehát tervezni kell, de a legtöbb projekt esetében fél napnál nem tart tovább.

FlashList v2 vs FlatList: összehasonlító táblázat

Az alábbi tábla azokat a dimenziókat foglalja össze, amelyek 2026-ban ténylegesen számítanak a döntésnél. A számokat saját projektjeimből és a hivatalos benchmarkokból vettem.

Szempont	FlashList v2	FlatList
Karbantartó	Shopify (aktív)	React Native core team
Architektúra követelmény	Új Architektúra (Fabric) kötelező	Régi és új is
Recycling	View pool alapú, típus szerint	Windowing (viewport-alapú)
Item méret becslése	Nem kell (runtime mérés)	Kell (getItemLayout opcionális)
Memóriahasználat (10 000 sor)	~40–80 MB	~150–300 MB
Scroll FPS iOS-en (release build)	60 fps stabil	45–60 fps ingadozó
Masonry támogatás	Beépített	Nincs (harmadik fél)
Sticky headers	Igen, natív	Igen, natív
Bundle méret hozzáadás	~35 KB (gzip)	0 (beépített)
Tanulási görbe	Enyhén meredek (típusok, keyExtractor)	Alacsony

Mikor válaszd a FlashList v2-t?

Röviden: majdnem mindig, ha az app már az Új Architektúrán fut. A FlashList v2 igazi értéke azokban a lista-mintákban mutatkozik meg, amelyekben a FlatList mérhetően megszenved:

• Végtelen scroll feed (közösségi app, hírolvasó, marketplace): 200+ sor után a FlatList a memória-csúszkát nyitogatja, a FlashList v2 stabilan tartja a 60 fps-t.
• Chat listák változó magasságú buborékokkal: a FlashList v2 auto-sizing miatt itt már nem kell onLayout hackekkel bíbelődni.
• Kép-nehéz galériák és masonry elrendezések: a v2 beépített masonry propja natívan kezel változó magasságú oszlopokat.
• Táblázatos katalógus képek nélkül: itt is nyer, mert a recycling típus szerint pool-ozza a sorokat.

Én az utolsó három appomban minden nem-triviális listát FlashList-tel írtam. A legjelentősebb nyereség egy 12 000 rekordos rendelés-listán volt: a FlatList-verzió a memóriaprofilban 280 MB-ot fogyasztott iPhone 12-n, ugyanaz a képernyő FlashList v2-vel 62 MB-ra esett. A scroll drop-frame-ek is eltűntek. Ez pontosan az a különbség, ami eldönti, hogy a felhasználó "gyorsnak" vagy "akadozónak" érzi az appot.

Ha az állapotkezelés is optimalizálva van (lásd Zustand és TanStack Query React Native-ban), akkor a FlashList mellé megkapod a teljes gyors listaélményt: virtualizáció plusz minimális re-render.

Mikor elég még mindig a FlatList?

Nem minden képernyőnek kell FlashList. Vannak esetek, amikor a FlatList (vagy a sima map() egy ScrollView-ban) a helyes választás:

• Kis, fix listák (10–30 elem, például beállítások képernyő): a FlashList extra bundle-je és típus-konfigurációja nem éri meg.
• Nem scrollolható listák egy nagyobb ScrollView-n belül: a FlashList nem szereti a nested scroll konfigurációt.
• Prototípus vagy demo kód, ahol a fejlesztési sebesség számít, nem az FPS.
• Régi architektúrás projektek, ahol a Fabric még nincs engedélyezve. Itt maradj FlatList-en, vagy használd a FlashList v1.x-et.

A pragmatikus megközelítés az én tapasztalatom szerint az, hogy a < 50 elemű listáknál nem érdemes agonizálni. A CPU-t úgysem viszi el, és a beépített komponensek dokumentációja jobban ismert a csapatban. Az áttörés 100–200 elemtől jön.

Migráció FlatList-ről FlashList v2-re lépésről lépésre

A folyamat egyszerűbb, mint amilyennek hangzik. Őszintén, én az első alkalommal háromszor annyi időre készültem, mint amennyi valójában kellett. Itt egy 5 perces recept, ami az esetek 90%-ában elég.

1. Telepítés

# Expo projekt (SDK 55+)
npx expo install @shopify/flash-list

# Bare React Native (0.76+)
npm install @shopify/flash-list
cd ios && pod install

2. Import csere

A FlatList props többsége (data, renderItem, ListHeaderComponent, ListFooterComponent, onEndReached, refreshControl) 1:1 megmarad. A minimum diff így néz ki:

// Előtte
import { FlatList } from 'react-native';

<FlatList
  data={items}
  keyExtractor={(item) => item.id}
  renderItem={({ item }) => <OrderRow order={item} />}
  onEndReached={loadMore}
/>

// Utána
import { FlashList } from '@shopify/flash-list';

<FlashList
  data={items}
  keyExtractor={(item) => item.id}
  renderItem={({ item }) => <OrderRow order={item} />}
  onEndReached={loadMore}
/>

3. Típusok bejelölése heterogén listánál

Ha a lista több különböző típusú sort jelenít meg (pl. hirdetés minden 10. elem között, vagy szekció-fejlécek), add meg a getItemType-ot. Ez segít a motornak a helyes view pool-t választani:

<FlashList
  data={feedItems}
  keyExtractor={(item) => item.id}
  getItemType={(item) => item.type} // 'post' | 'ad' | 'header'
  renderItem={({ item }) => {
    switch (item.type) {
      case 'post': return <PostCard post={item} />;
      case 'ad':   return <AdSlot ad={item} />;
      case 'header': return <SectionHeader title={item.title} />;
    }
  }}
/>

4. Ellenőrzés dev buildben

A FlashList figyelmeztet a konzolon, ha nem optimális a konfigurációd (pl. mindegyik itemet ugyanolyannak lát, holott heterogén). Fussasd le release módban is a valódi teljesítmény méréséhez, mert dev buildben a JavaScript és a Hermes debugger torzítja a képet.

FlashList v2 teljesítmény benchmarkok

A Shopify hivatalos benchmark repositoryja és saját méréseim alapján a v2 mérhető nyeresége három tengelyen látszik. A számokat mindig release buildben nézd, a React Native New Architecture engedélyezve.

1. Blank space arány scrollnál: a FlashList v2 iPhone 12-n gyors scrollnál 1–3% üres területet mutat, a FlatList 15–40%-ot. Ez az, amit a felhasználó "villódzásként" érzékel.
2. JS thread frame drop: 1 000 elemes feednél FlatList-tel 12–18 drop/1000 frame, FlashList v2-vel 0–2. Ez a Hermes engine mellett is számottevő.
3. Memória plateau: 10 000 elemes lista végigscrollolása után a FlashList v2 platója 60–90 MB-nál stabilizálódik, a FlatList tovább nő, mert a windowing nem takarítja azonnal a régi ablakokat.

Fontos árnyalás: a legjobb eredményekhez a renderItem-ben lévő komponensednek is memoizáltnak kell lennie (React.memo), és a keyExtractor-nak stabil értéket kell adnia. Ha minden re-renderre új objektumot vagy funkciót adsz át propként, a virtualizáció önmagában nem ment meg. Ezt a hibát én egy hosszú délutánon át kerestem, amíg rájöttem, hogy egy inline arrow function volt a bajok forrása.

Gyakori buktatók és hogyan kerüld el őket

Hat éves React Native tapasztalattal is voltak buktatóim FlashList-tel. Íme a leggyakoribbak.

Nested scroll: FlashList ScrollView-n belül

Ha egy ScrollView-n belülre teszed a FlashList-et, a virtualizáció megszűnik, mert nincs korlátozott viewport. Vagy tedd fő scroll konténerré a FlashList-et (ListHeaderComponent-tel), vagy adj neki fix magasságot. A ListHeaderComponent utat javaslom, ez az, amit a Shopify is használ minden nagy screenjén.

Nem stabil keyExtractor

Ha a keyExtractor-od Math.random()-ot vagy indexet ad vissza, a recycling összeomlik, és minden re-renderkor újra kell festenie mindent. Használj mindig stabil, üzletileg értelmes ID-t (pl. item.id). Egy juniornak írt code review során ez volt a leggyakoribb hiba, amit visszaküldtem.

numColumns változtatása runtime-ban

A FlashList belső view pool-ja a numColumns-ra épül. Ha runtime-ban átváltogatod (pl. list/grid váltó), teljesen új komponenspéldányt kell renderelned (key prop változtatásával), különben inkonzisztens elrendezést kapsz.

Dinamikus képméret Image-ekben

Ha a renderItem-ben olyan Image van, aminek magassága a válaszból derül ki (pl. onLoad-ban setState), akkor a v1-ben ez akadozást okozott. A v2 auto-sizing motorja jól kezeli, de akkor is érdemes a képmagasságot előre tudni a szerverről.

Haladó funkciók: masonry, sticky headers, auto-sizing

A FlashList v2 három olyan funkciót hozott, ami a FlatList-ből egyszerűen hiányzik.

Masonry elrendezés

<FlashList
  data={photos}
  numColumns={2}
  masonry
  renderItem={({ item }) => (
    <Image
      source={{ uri: item.url }}
      style={{ aspectRatio: item.aspect, width: '100%' }}
    />
  )}
/>

Ez felváltja azt a fájdalmat, amit korábban react-native-masonry-list vagy egyedi implementációval kellett megoldani. Pinterest-stílusú képgaléria most 10 sor.

Sticky headers dinamikus adatokkal

A FlashList v2 pontosan úgy adja át a stickyHeaderIndices-t, mint a FlatList, de a rendering annyival gyorsabb, hogy a sticky header szinte azonnal frissül scroll közben, nem lag utána.

Auto-sizing (nincs több estimatedItemSize)

A legnagyobb DX-nyereség számomra ez: nem kell többé "eltalálnom" a sor magasságát. A motor méri a tényleges layoutot, és a scroll pozíciót ennek alapján számolja. Heterogén listáknál (chat, feed) ez konkrétan órákat spórol.

Ha a témában mélyebbre mennél, érdemes a lista-teljesítményt más 2026-os React Native fejlesztésekkel is összeolvasni. Például az Expo SDK 55 és az Új Architektúra útmutatóval, mert a Fabric renderer dolgozik a FlashList v2 alatt. Animációk esetén pedig a Reanimated 4 útmutató ad hasznos hátteret arra, hogyan tartsd meg a 60 fps-t swipe-gesture-ökkel kombinált soroknál.

Gyakran ismételt kérdések

Le lehet cserélni közvetlenül a FlatList-et FlashList v2-re?

Az esetek többségében igen, a props többsége (data, renderItem, keyExtractor, onEndReached) 1:1 megmarad. Néhány prop viszont eltűnt (estimatedItemSize) vagy módosult (numColumns masonry mellett), ezért érdemes a hivatalos migrációs útmutatót átfutni.

Miért lassabb a FlatList nagy listákon?

Mert a FlatList windowing algoritmust használ, ami a viewport körüli sorokat tartja renderelve, de nem újrahasznosítja a view-kat. Nagy listánál minden új sor új nézet-példány, ami memóriát fogyaszt és GC-t vált ki. A FlashList v2 recycling pool-ozza a view-kat típus szerint.

Működik a FlashList v2 Expo Go-ban?

Igen, Expo SDK 55-től kezdve az Expo Go tartalmazza az Új Architektúrát, így a FlashList v2 futni fog. Régebbi SDK-n custom development build kell.

Kell-e még estimatedItemSize a FlashList v2-ben?

Nem. A v2 motorja runtime-ban méri a sorok tényleges méretét, így a becslési propok (estimatedItemSize, estimatedListSize, overrideItemLayout) el lettek távolítva, vagy már nincsenek hatással.

Melyik listakomponenst használjam beállítások képernyőn?

10–30 elemig maradj FlatList-nél, vagy tegyél egy sima ScrollView-t map()-pel. A FlashList extra függősége és típus-konfigurációja ekkora listánál nem éri meg, a felhasználó nem érez különbséget.