import React from 'react';
import { Text, View } from 'react-native';
import { FlashList } from '@shopify/flash-list';
interface Product { id: string; title: string; price: number; }
const ProductFeed = ({ products }: { products: Product[] }) => {
return (
<FlashList
data={products}
renderItem={({ item }) => (
<View style={{ height: 120, padding: 10 }}>
<Text>{item.title}</Text>
<Text>{item.price} RON</Text>
</View>
)}
// Valoare critică! Trebuie să fie media înălțimilor itemilor reali
estimatedItemSize={120}
keyExtractor={(item) => item.id}
/>
);
};Am testat FlashList de la Shopify pe un Samsung A12, un veritabil cartof de telefon din 2020, ca să văd dacă merită cu adevărat migrarea de la clasicul FlatList. Dacă ai liste lungi și vrei să scapi de drop-urile de FPS pe telefoane ieftine, experimentul meu s-ar putea să-ți salveze câteva zile de debugging.
De ce moare FlatList pe Android de buget
Pe scurt: managementul memoriei. FlatList-ul nativ din React Native funcționează prin montarea și demontarea componentelor pe măsură ce utilizatorul face scroll. Pe un iPhone de ultimă generație nu observi nimic, dar pe un procesor MediaTek low-end cu 3GB RAM, povestea e complet diferită.
La un proiect cu peste 8.000 de utilizatori activi, aveam un feed de produse cu imagini și descrieri. Când rulam Perf Monitor din Developer Menu în timp ce făceam scroll rapid, JS thread-ul scădea dramatic până la 22 FPS. Utilizatorul vedea ecrane albe (blank space) și o sacadare extrem de enervantă. Garbage Collector-ul din Android pur și simplu nu făcea față numărului uriaș de obiecte create și distruse în JS engine.
Cum a schimbat FlashList jocul (Numere concrete)
Spre deosebire de FlatList, FlashList reciclează celulele (views). În loc să distrugă o componentă care a ieșit din ecran, o păstrează în memorie și doar îi schimbă datele (props) pentru a o afișa în partea de jos a listei.
După ce am înlocuit FlatList cu FlashList, am refăcut măsurătorile pe același Samsung A12 chinuit:
- FPS pe JS Thread: A urcat de la o medie de 35 FPS la un stabil 58-60 FPS.
- Blank spaces: Timpul în care utilizatorul vedea un ecran gol până se randa conținutul a scăzut cu aproximativ 75%.
- Consum RAM: A rămas constant, fără spike-urile specifice pe care le genera FlatList când se acumulau componente nemontate.
Trade-off-ul sincer: estimatedItemSize
Nu există magie gratuită în programare. FlashList are nevoie de un prop obligatoriu numit estimatedItemSize. Dacă pui o valoare greșită acolo, performanța scade drastic sau te trezești cu layout shifts de-ți fuge ecranul de sub deget.
Dacă ai elemente cu înălțime fixă, e simplu. Dacă ai înălțimi foarte dinamice (cum e un feed unde un post are 2 rânduri de text și altul are 20 de rânduri plus o imagine), FlashList se chinuie și s-ar putea să vezi elemente care se suprapun pentru o fracțiune de secundă în timpul reciclării. De asemenea, dacă folosești o logică grea în renderItem, reciclarea va eșua silențios și vei reveni la performanța slabă de dinainte.
FlashList câștigă clar pe Android ieftin dacă ai liste lungi, dar cere atenție sporită la dimensiunile componentelor. Atât.