错误的ViewPager用法（续），会产生内存泄漏？内存溢出？

时间  2020-06-02
标签 错误 viewpager 用法 产生 内存 泄漏 溢出 栏目 Android 繁體版
原文   原文链接

前言

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

前几天发布了一篇文章：你的ViewPager八成用错了。关于分析FragmentPagerAdapter的...没想到引发个各路英雄豪杰的激烈讨论。这其中有两个颇有意义的点：android

  • 一、错误的第一种用法引起内存泄漏（不许确）。
  • 二、FragmentStatePagerAdapter在FragmentPagerAdapter基础上作了什么。

今天这篇文章，我们就来聊一聊上面俩个话题。缓存

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

正文

错误的用法引发内存泄漏。布局

说实话，我其实的确没有留意过这个点。当评论中的同窗提到这一点的时候，我想了想彷佛能够“说得通”：Activity相对较Fragment，应该生命周期会更长，若是在Activity直接强引用全部的Fragment的实例。按理说的确会有泄漏问题。post

不过这个结论的前提是基于：Activity比Fragment生命周期更长，若是不是这样的话，也谈不上存在内存泄漏。因此为了求证这个结论我们仍是从源码中一探究竟。学习

1、内存泄漏？

首先可以肯定的是，不管正误用法都不会存在内存泄漏问题。spa

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

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

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.二、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<Fragment> mAdded = new ArrayList<>();
private final HashMap<String, FragmentStateManager> mActive = new HashMap<>();
复制代码

1.三、什么样的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.四、什么样的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中留下大量成员变量，好比：

  • 一、为了减小布局inflate的时间，咱们去缓存View。
  • 二、为了缓存一些数据，咱们在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.五、额外聊聊android.os.TransactionTooLargeException

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

可是我们上述聊的内容，很容易形成这个Exception。你们有兴趣能够作一下这个操做：

  • 一、把ViewPager的个数弄的很大，而后滑到最后。
  • 二、开发者选项里打开 不保留活动
  • 三、按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

2、小总结

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

固然正是由于这种种的缘由，也就有了后续的FragmentStatePagerAdapter甚至ViewPager2。

尾声

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

整起来，我还能学！

仍是那个原则：我会力求把文章写到我认为正确为止，所以因为我的水平有限，不免出现纰漏，欢迎你们一块儿讨论，一块儿共建标准答案！

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

我的公众号：咸鱼正翻身
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程