PdfPageCacheStrategy
Controls how many rasterised page bitmaps the viewer keeps in memory while scrolling, and how aggressively it prefetches pages around the viewport.
The viewer always caps total bitmap memory against a per-platform budget (Android — 25 % of Runtime.maxMemory(), iOS — 200 MB) and evicts the least-recently-used pages first when the budget is exceeded. The strategy controls only the prefetch window — how far ahead and behind the visible page the renderer tries to keep pages warm. The hard memory cap means you can never crash the process by asking for too large a window: the cache will simply stop holding more pages than fit.
Typical choice:
Auto — sensible defaults for most apps. The viewer prefetches a small window (a handful of pages above and below) and lets the memory budget take it from there. Pages already rendered stay warm in cache, so scrolling back to a page you visited recently is instant. Recommended default. The window is adaptive: for large documents (over LARGE_DOCUMENT_THRESHOLD pages) it tightens to a small forward-biased window so the prefetch loop never tries to budget the whole document, while small documents keep the symmetric default.
Window — explicit knob for hosts that know their documents and want a wider warm window for fluency, or a narrower one to keep memory pressure low.
All — try to keep every page warm. Useful for short documents (presentations, multi-page forms). The memory cap still applies, so big documents silently degrade to LRU behaviour.
Inheritors
Types
Keep every page warm if it fits in the memory budget. Useful for short documents the user is likely to flip through repeatedly. For long documents this degrades naturally to LRU eviction.
Default strategy. Prefetch is conservative and adaptive to document size:
Explicit warm window. The viewer tries to keep pagesBefore pages above the visible one and pagesAfter below pre- rasterised; the memory budget evicts the oldest entry when that would overflow.