调用mViewPager.setAdapter时App卡顿无响应，GC日志频繁输出求助

你遇到的这个问题很典型——调用mViewPager.setAdapter时App卡住，还伴随频繁的GC日志，说明这一过程中内存开销过大，导致系统不断回收内存，拖慢了主线程。先梳理下你遇到的细节：

Logcat频繁输出：
"Background sticky concurrent mark sweep GC freed 253980(5MB) AllocSpace objects, 16(256KB) LOS objects, 8% free, 44MB/48MB, paused 5.693ms total 37.544ms"

你的实现代码：

@Override 
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { 
    View inflatedView = inflater.inflate(R.layout.fragment_options, container, false); 
    mViewPager = (ViewPager) inflatedView.findViewById(R.id.viewpager_options); 
    mViewPager.setAdapter(new Adapter(getChildFragmentManager())); 
    return inflatedView; 
} 

private class Adapter extends FragmentPagerAdapter { 
    private static final int TABS = 3; 

    public Adapter(FragmentManager fm) { 
        super(fm); 
    } 

    @Override 
    public Fragment getItem(int position) { 
        switch (position){ 
            case 0: 
                return new OptionsFragment(); 
            default: 
                return new OptionsFragment(); 
        } 
    } 

    @Override 
    public int getCount() { 
        return TABS; 
    } 
}

接下来给你几个针对性的解决思路：

1. 避免重复创建Fragment实例，减少内存分配 #

你的getItem方法里，三个Tab都返回新的OptionsFragment实例，如果这个Fragment的初始化（比如布局加载、数据初始化）比较重，三次重复创建会瞬间产生大量内存对象，直接触发GC。

可以提前缓存Fragment实例，减少重复创建的开销：

private class Adapter extends FragmentPagerAdapter {
    private static final int TABS = 3;
    private final Fragment[] mFragments = new Fragment[TABS];

    public Adapter(FragmentManager fm) {
        super(fm);
        // 提前初始化所有Fragment实例，避免重复创建
        for (int i = 0; i < TABS; i++) {
            mFragments[i] = new OptionsFragment();
        }
    }

    @Override
    public Fragment getItem(int position) {
        return mFragments[position];
    }

    // 如果三个Tab需要不同的Fragment逻辑，这里可以根据position创建对应实例，而不是复用同一个类
}

2. 排查OptionsFragment的内存开销 #

GC频繁触发的核心是短时间内产生了大量可回收对象，你需要重点检查OptionsFragment的初始化逻辑：

• 有没有加载嵌套过深的布局？可以用Android Studio的Layout Inspector查看布局层级，尽量扁平化，减少View对象数量。
• 有没有在主线程做耗时操作？比如加载未压缩的大图片、解析大JSON文件、本地IO操作，这些会阻塞主线程，同时产生大量临时对象。
• 有没有创建不必要的重复对象？比如在循环里反复创建集合、字符串，尽量复用已有对象。

举个例子，如果Fragment里加载了大图，一定要做压缩处理，避免一次性把高清大图加载到内存中。

3. 考虑改用FragmentStatePagerAdapter #

FragmentPagerAdapter会把所有Fragment实例永久保留在内存中，当Tab数量多或者Fragment内存占用高时，很容易导致内存紧张。如果你的三个Fragment可以重新初始化，换成FragmentStatePagerAdapter会更合适——它会在Fragment不可见时销毁视图，只保留必要的状态，大幅降低内存占用。

替换起来非常简单，只需要修改Adapter的父类：

private class Adapter extends FragmentStatePagerAdapter {
    // 其余代码和之前一致
}

4. 优化ViewPager的预加载行为 #

ViewPager默认会预加载左右各一个页面，也就是初始化时会一次性创建3个Fragment（当前页+左右各一个）。如果你的Fragment初始化成本很高，可以通过setOffscreenPageLimit减少预加载数量：

mViewPager.setOffscreenPageLimit(0); // 只预加载当前页，注意部分系统版本可能存在兼容性问题

不过这个操作要谨慎，因为滑动时会重新创建Fragment，可能导致滑动卡顿，需要在内存占用和滑动流畅度之间做权衡。

最后，你可以用Android Studio的Memory Profiler工具具体分析内存分配情况，看看是哪些对象在频繁创建和回收，这样能更精准地定位问题。

内容的提问来源于stack exchange，提问作者Elias Dolinsek