前言

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

前几天发布了第一篇文章
，关于分析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());

@NonNull
public FragmentManager getSupportFragmentManager() {
    return mFragments.getSupportFragmentManager();
}

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

private final FragmentHostCallback mHost;

@NonNull
public 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实例：

@Nullable
private final FragmentStore mFragmentStore = new FragmentStore();

public Fragment findFragmentById(@IdRes int id) {
    return mFragmentStore.findFragmentById(id);
}

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

@Nullable
Fragment 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 mAdded = new ArrayList<>();
private final HashMap 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的数量。比如这样：

image.png

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

image.png

因此常规情况下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一下内存：

image.png

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

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

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

1.5、额外聊聊android.os.TransactionTooLargeException

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

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

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

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

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

@Override
protected 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

image.png

二、小总结

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

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

尾声

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

整起来，我还能学！

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

我是一个应届生，最近和朋友们维护了一个公众号，内容是我们在从应届生过渡到开发这一路所踩过的坑，以及我们一步步学习的记录，如果感兴趣的朋友可以关注一下，一同加油~

个人公众号：咸鱼正翻身

你的ViewPager八成用错了（2）内存泄漏？内存溢出？

前言

正文

一、内存泄漏？

1.1、FragmentManager怎么初始化的

1.2、Google如何帮我们缓存Fragment

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

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

1.5、额外聊聊android.os.TransactionTooLargeException

二、小总结

尾声

我是一个应届生，最近和朋友们维护了一个公众号，内容是我们在从应届生过渡到开发这一路所踩过的坑，以及我们一步步学习的记录，如果感兴趣的朋友可以关注一下，一同加油~

你可能感兴趣的:(你的ViewPager八成用错了（2）内存泄漏？内存溢出？)