Introduction

FragmentPagerAdapter and FragmentStatePagerAdapter solve the same high-level problem in the classic ViewPager API: they provide fragments for swipeable pages. The key difference is lifecycle strategy: one keeps fragment instances in memory, while the other destroys off-screen fragments and keeps only their saved state.

FragmentPagerAdapter Keeps Fragments Around

FragmentPagerAdapter is designed for a small, mostly fixed number of pages such as top-level tabs. Once a fragment is created, the adapter tends to retain it in memory, which makes switching back to it fast.

That behavior is useful when the pages are few and relatively lightweight.

1public class MainPagerAdapter extends FragmentPagerAdapter {
2
3    public MainPagerAdapter(@NonNull FragmentManager fm) {
4        super(fm, BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT);
5    }
6
7    @NonNull
8    @Override
9    public Fragment getItem(int position) {
10        switch (position) {
11            case 0:
12                return new HomeFragment();
13            case 1:
14                return new SearchFragment();
15            default:
16                return new ProfileFragment();
17        }
18    }
19
20    @Override
21    public int getCount() {
22        return 3;
23    }
24}

If the app has three stable tabs, keeping those fragments alive is often acceptable and can make the UI feel very responsive.

FragmentStatePagerAdapter Saves State and Frees Memory

FragmentStatePagerAdapter is meant for larger or more dynamic page sets. When a page moves far enough off screen, the adapter destroys the fragment instance and keeps only its saved state. If the user navigates back later, the fragment is recreated from that state.

1public class PhotoPagerAdapter extends FragmentStatePagerAdapter {
2
3    private final List<String> photoUrls;
4
5    public PhotoPagerAdapter(@NonNull FragmentManager fm, List<String> photoUrls) {
6        super(fm, BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT);
7        this.photoUrls = photoUrls;
8    }
9
10    @NonNull
11    @Override
12    public Fragment getItem(int position) {
13        return PhotoFragment.newInstance(photoUrls.get(position));
14    }
15
16    @Override
17    public int getCount() {
18        return photoUrls.size();
19    }
20}

This is the better choice for image galleries, onboarding flows with many screens, or data-driven pagers where holding every fragment instance would waste memory.

Memory Tradeoff Versus Recreation Cost

That is the real design tradeoff:

• 'FragmentPagerAdapter spends more memory to avoid recreation'
• 'FragmentStatePagerAdapter spends more lifecycle work to reduce memory usage'

If each page contains heavy views, large images, or non-trivial fragment state, FragmentStatePagerAdapter is usually safer. If there are only a few stable fragments and you want instant switching, FragmentPagerAdapter is often simpler.

Neither adapter makes all pages visible at once. ViewPager still preloads only a limited number of neighboring pages. The difference is what happens to older fragment instances over time.

How This Affects State

With FragmentStatePagerAdapter, you must assume fragments may be destroyed and recreated. That means important UI state should be stored properly through arguments, ViewModel, saved instance state, or another durable mechanism.

With FragmentPagerAdapter, the fragment object tends to survive longer, so careless state handling may appear to work during testing. That can hide design issues which later show up under process death or configuration change.

What to Use in Newer Code

For classic ViewPager, the choice above still explains the old API. In newer Android code, however, ViewPager2 is the preferred pager widget, and it uses FragmentStateAdapter rather than either of these older adapter classes.

So if you are maintaining an existing ViewPager, the comparison matters directly. If you are starting fresh, it is usually better to build on ViewPager2 and learn the newer adapter model instead of choosing between two legacy options.

Common Pitfalls

The biggest pitfall is choosing FragmentPagerAdapter for a very large or unbounded set of pages. The app may seem fine with test data and then become memory-heavy in production.

Another issue is using FragmentStatePagerAdapter without storing fragment state properly. Because fragments can be recreated, any state that lives only in fields is fragile.

Developers also sometimes assume one adapter is universally better. It is not. The page count, fragment weight, and navigation pattern decide which tradeoff is correct.

Finally, be aware of the API generation you are working in. Advice for ViewPager does not map one-for-one onto ViewPager2, which uses a different adapter class.

Summary

• 'FragmentPagerAdapter keeps fragment instances in memory and suits a small fixed page set.'
• 'FragmentStatePagerAdapter destroys off-screen fragments and keeps saved state to reduce memory use.'
• Use the former for a few stable tabs and the latter for larger or dynamic page collections.
• Proper state handling matters more with FragmentStatePagerAdapter because fragments are recreated.
• In new Android code, prefer ViewPager2 with FragmentStateAdapter over the older ViewPager adapters.