阅读 844

错误的ViewPager用法(续),会产生内存泄漏?内存溢出?

前言

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

前几天发布了一篇文章:你的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());

@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<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()

@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

二、小总结

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

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

尾声

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

整起来,我还能学!

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

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

个人公众号:咸鱼正翻身

关注下面的标签,发现更多相似文章
评论