前言

写作记录：5月27日晚上写下初版，30日下午补充一些内容…结束

前几天发布了错误终结者：Fragment在ViewPager中的正确应用，关于分析FragmentPagerAdapter的…没想到引起了各路英雄豪杰的激烈讨论。这其中有两个很有意义的点：

• 1、错误的第一种用法引发内存泄漏（不准确）。
• 2、FragmentStatePagerAdapter在FragmentPagerAdapter基础上做了什么。

今天这篇文章，咱们就来聊一聊上面两个话题。

以下源码基于：implementation "androidx.fragment:fragment:1.2.0"

正文

错误的用法引起内存泄漏。

说实话，我其实的确没有留意过这个点。当评论中的同学提到这一点的时候，我想了想似乎可以“说得通”：Activity相对较Fragment，应该生命周期会更长，如果在Activity直接强引用所有的Fragment的实例。按理说的确会有泄漏问题。

不过这个结论的前提是基于：Activity比Fragment生命周期更长，如果不是这样的话，也谈不上存在内存泄漏。所以为了求证这个结论咱们还是从源码中一探究竟。

一、内存泄漏？

首先能够确定的是，无论正误用法都不会存在内存泄漏问题。

但是会有可能存在内存溢出，并且错误的写法更容易出现。而其实我们线上场景也遇到过这类问题，当时我们是有30+个Fragment，然后在低端手机上爆出了很多这样的crash：

java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 3117432 bytes这个crash出现的原因，下文会展开。

1.1、FragmentManager怎么初始化的

接下来咱们聊一下为什么不会出现内存泄漏。

首先咱们都知道Fragment是由FragmentManager管理的，那咱们就基于这个共识一起来看一看源码：

通常咱们这样从一个Activity中拿到FragmentManager：activity.supportFragmentManager。那咱们就顺着这个调用，看一看FM是如何初始化的。

final FragmentController mFragments = FragmentController.createController(new HostCallbacks());@NonNullpublic FragmentManager getSupportFragmentManager() {    return mFragments.getSupportFragmentManager();}

可以看出对外提供FragmentManager的FragmentController类是在Activity里直接被new出来的，而FragmentController中提供FM是这样的：

private final FragmentHostCallback<?> mHost;@NonNullpublic FragmentManager getSupportFragmentManager() {    return mHost.mFragmentManager;}

mHost就是咱们new FragmentController时候传进来的new HostCallbacks()。而HostCallbacks中的FM又是怎么来的呢？

final FragmentManager mFragmentManager = new FragmentManagerImpl();

可以看到直接是new出来的。因此这里我们就能明确了，其实Activity是强引用了FM。只要Activity不被回收，那么FM就不会被回收，那么FM中的Fragment也就不会被回收。那么也就有了上面的结论：大家生命周期一样长，其实谈不上什么内存泄漏。

1.2、Google如何帮我们缓存Fragment

但是，咱们上边提到过，虽然没有内存泄漏，但是存在内存溢出！那么这又是谁的锅呢？这次咱们可以放心，这个锅还真不是咱们开发者的问题 ！没错，这口锅必须得稳稳的扣在Google头上！来咱们看源码：

咱们日常获取Fragment实例都是基于FragmentManager的find()系列方法，咱们就从这个方法来看一看FM如果保存咱们的Fragment实例：

@Nullableprivate final FragmentStore mFragmentStore = new FragmentStore();public Fragment findFragmentById(@IdRes int id) {    return mFragmentStore.findFragmentById(id);}

真正的实现是代理到FragmentStore中，没直白的名字。FragmentStore这样去find：

@NullableFragment findFragmentById(@IdRes int id) {    // First look through added fragments.    for (int i = mAdded.size() - 1; i >= 0; i--) {        Fragment f = mAdded.get(i);        if (f != null && f.mFragmentId == id) {            return f;        }    }    // Now for any known fragment.    for (FragmentStateManager fragmentStateManager : mActive.values()) {        if (fragmentStateManager != null) {            Fragment f = fragmentStateManager.getFragment();            if (f.mFragmentId == id) {                return f;            }        }    }    return null;}

可以看出这里是通过两个集合去find，分别是mAdded、mActive。

private final ArrayList<Fragment> mAdded = new ArrayList<>();private final HashMap<String, FragmentStateManager> mActive = new HashMap<>();

1.3、什么样的Fragment进到mAdded集合

mAdded这个List会存储attach上的Fragment，因此它不会有很多（如果我们的mOffscreenPageLimit=1），那么这个集合的size最大是3，为啥？咱们看源码。

void addFragment(@NonNull Fragment fragment) {    if (mAdded.contains(fragment)) {        throw new IllegalStateException("Fragment already added: " + fragment);    }    synchronized (mAdded) {        mAdded.add(fragment);    }    fragment.mAdded = true;}void removeFragment(@NonNull Fragment fragment) {    synchronized (mAdded) {        mAdded.remove(fragment);    }    fragment.mAdded = false;}

mAdded的add和remove又在FM中有四种可能调用，对于addFragment()来说，FM会在OP_ADD、OP_ATTACH时调用，源码分别如下：

case OP_ADD:    f.setNextAnim(op.mEnterAnim);    mManager.setExitAnimationOrder(f, false);    mManager.addFragment(f);    break;case OP_ATTACH:    f.setNextAnim(op.mEnterAnim);    mManager.setExitAnimationOrder(f, false);    mManager.attachFragment(f);    break;

有了第一篇文章的基础，咱们明白对于FragmentPageradapter来说find不到Fragment，就会调用getItem()去new Fragment然后add，也就是走到OP_ADD。否则直接attach走OP_ATTACH，这里种状态都会走到mAdded的add。既然咱们看到了add，那么同样对这两种状态相对的就是remove：

case OP_DETACH:    f.setNextAnim(op.mExitAnim);    mManager.detachFragment(f);    break;case OP_REMOVE:    f.setNextAnim(op.mExitAnim);    mManager.removeFragment(f);    break;

很明显的成对出现，因此这个集合问题不大，只要用法无误这个集合就是恒等的。

1.4、什么样的Fragment进到mActive集合

接下来，咱们把目光移到mActive上。扫遍整个FragmentStore会发现，mActive只有一个场景会将集合特定位置置为null：

void makeInactive(@NonNull FragmentStateManager newlyInactive) {    // 省略部分代码    mActive.put(f.mWho, null);    // 省略部分代码}

这是唯一一个可以回收mActive的机会。不过这个方法只会在当前Fragment处于removing才会调用：

boolean beingRemoved = f.mRemoving && !f.isInBackStack();if (beingRemoved || mNonConfig.shouldDestroy(f)) {    makeInactive(fragmentStateManager);}

而我们的FragmentPagerAdapter中destory的逻辑并没有remove：

public void destroyItem(@NonNull ViewGroup container, int position, @NonNull Object object) {    // 省略部分代码    mCurTransaction.detach(fragment);    // 省略部分代码}

这就意味了除了最终的清理（clear）以外，在使用的过程中mActive是始终增加的！

实际也是如此，当我们滑光所有的Fragmet，会发现mActive的数量之和就是所有Fragment的数量。比如这样：

当然，这样可怕么？只能说不一定，因为这里仅仅是持有了Fragment的实例，并不会包含View。（只要不属于add状态的Fragment的View是为null的）：

因此常规情况下Fragment实例并不怎么占内存，毕竟此View上的内存是会被回收掉的。因此如果我们不在Fragment中强引用一些其他大内存对象，问题也不大…但是事实却与之相反，我们很容易在Fragment中留下大量成员变量，比如：

• 1、为了减少布局inflate的时间，我们去缓存View。
• 2、为了缓存一些数据，我们在Fragment中保留大量成员变量。

但是，我们话说回来，这样的操作有毛病么？个人觉得没毛病。但是在Google的这种设计下，那就很容易出问题。下面咱们模拟一个这种case下出现OOM的场景：在Fragment上开辟一些大内存对象：

val array = IntArray(1024 * 1024 * 10)

当我滑动到第6个的Fragment时，崩了…java.lang.OutOfMemoryError: Failed to allocate a 41943052 byte allocation with 6959760 free bytes and 6MB until OOM

我们dump一下内存：

并且无论我们如何强制GC，都无法回收这个内存。因此这也就是验证了我们上边的问题，出问题的本身在于Google的机制，而压死这个机制的最后一根稻草在于Fragment中的“滥用”。

其实我们也不用太担心，这毕竟是极端情况。不过当我们的场景需要大量的Fragment时，是需要认真考虑这部分聊的问题。

那么问题来了，这个坑点Google知道吗？答案是知道，所以才有了FragmentStatePagerAdapter，以及后来的ViewPager2。

1.5、额外聊聊android.os.TransactionTooLargeException

android.os.TransactionTooLargeException，这个异常我在开篇提到过，官网也有单独的介绍。有经验的老司机应该都遇到过，这个异常本身似乎和咱们今天聊的话题没有直接关系。

但是咱们上述聊的内容，很容易造成这个Exception。大家有兴趣可以做一下这个操作：

• 1、把ViewPager的个数弄的很大，然后滑到最后。
• 2、开发者选项里打开 不保留活动
• 3、按home键

八成会出现这个异常…如果遇不到，继续加大ViewPager的个数！

咱们这种场景出现这个问题：本质的原因在于onSaveInstanceState()：

@Overrideprotected void onSaveInstanceState(@NonNull Bundle outState) {    super.onSaveInstanceState(outState);    markFragmentsCreated();    mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP);    Parcelable p = mFragments.saveAllState();    if (p != null) {        outState.putParcelable(FRAGMENTS_TAG, p);    }    // 省略部分代码}

FM的在saveState()的时候是会保存mAdded集合和mActive集合的…咱们刚才也已经分析过去，mActive集合是一个全量数据集。所以Fragment足够多，这里的Parcel在传递的过程中就爆炸了。

这里咱们引申一下，Binder在通信的过程中最大的数据量是多少呢？官网给出的答案是：1M

二、小总结

咱们第二部分聊的内容，其实只有在极端情况下出现。日常开发时，我们八成遇不到这种场景。但是当我们了解了这些内容，就可以在遇到这类问题时准确的预防或者根治。

当然正是因为这种种的原因，也就有了后续的FragmentStatePagerAdapter甚至ViewPager2。

尾声

本是这篇文章开始是想把FragmentStatePagerAdapter一并聊了…但是写完这一部分的时候发现篇幅已经足够长了，为了避免大家“消化不良”。后续的内容咱们下一篇文章再聊。

整起来，我还能学！

还是那个原则：我会力求把文章写到我认为正确为止，因此由于个人水平有限，难免出现纰漏，欢迎大家一起讨论，一起共建标准答案！