FlatList virtualization and windowing trade-offs

WHAT THIS TESTS Whether you genuinely understand how virtualization keeps a long list cheap, and can articulate the memory-versus-smoothness trade-off behind windowSize rather than reciting it.

A GOOD ANSWER COVERS FlatList is built on VirtualizedList. Instead of mounting every row, it maintains a window of rendered items around the current viewport. windowSize is expressed in units of visible length, where 1 equals one screen height; a windowSize of 21, roughly the default, means about ten screens of content above and below the viewport are kept rendered. Items outside the window are unmounted and replaced by blank spacer views of the correct height so the scroll position and scrollbar stay accurate. As the user scrolls, FlatList mounts items entering the window and unmounts those leaving it, often in batches governed by maxToRenderPerBatch. A larger windowSize renders more rows, so fast scrolling shows fewer blank cells, but it raises memory use and the amount of mounting work. A smaller windowSize uses less memory and does less work, but the user may briefly see blank space before rows fill in during quick scrolls.

COMMON WRONG ANSWERS Saying FlatList renders all items, confusing it with ScrollView. Believing windowSize is measured in pixels or item count rather than viewport multiples. Thinking a huge windowSize is strictly better, ignoring the memory cost. Conflating windowSize with maxToRenderPerBatch, which controls batch size per render pass, not the retained window.

LIKELY FOLLOW-UPS How do windowSize, maxToRenderPerBatch, and initialNumToRender interact? Why do off-window items get blank placeholders instead of being removed outright? When does the unmount-remount of complex rows itself become the bottleneck?

ONE CONCRETE EXAMPLE A list of 5000 rows uses windowSize 21, so only the visible screen plus about ten screens each way are mounted, keeping memory roughly constant. On a device that stutters, you lower windowSize to reduce memory and mount churn, but during fast flings you notice momentary blank cells; raising it back smooths scrolling at the cost of a larger heap, illustrating the direct trade-off you tune per device and row complexity.