FlatList crashes on low-end Android when windowSize is increased for large dataset pagination

When paginating a dataset of more than 1,000 items through FlatList, the goal is to maintain smooth scrolling and responsive onEndReached fetches without triggering memory-related crashes on low-end Android hardware. The windowSize prop expands the render buffer beyond the viewport, but raising it to reduce blank areas during fast scrolling also increases the number of mounted item components. Because memory usage scales with the complexity of the renderItem callback rather than the total length of the data array, even a virtualized list can exhaust available heap if each row contains images or nested layouts.

There is uncertainty around how to bound the query and tune the windowing parameters safely. Values such as 5 and 41 are commonly compared to evaluate scroll smoothness, yet the interaction between windowSize, initialNumToRender, and a heavy renderItem function is not obvious from the documentation alone. Additionally, an incorrectly set onEndReachedThreshold may fire multiple redundant network requests before the previous page resolves, compounding memory and CPU pressure.

What practical upper bound for windowSize is safe when renderItem is moderately complex? Should initialNumToRender be reduced to offset a larger windowSize, or does that trade-off only affect perceived load time? How can onEndReached be guarded so that pagination fetches remain exactly one per page without introducing stale closures?