谷歌發(fā)布ViewPager2正式版，Android開發(fā)如何用它實現(xiàn)懶加載？

作者：快樂丸
鏈接：https://blog.csdn.net/qq_36486247/article/details/103959356

前言
ViewPager2是官方推出的新控件，從名稱上也能看出是用于替代ViewPager的，它是基于RecyclerView實現(xiàn)的，因此可以實現(xiàn)一些ViewPager沒有的功能，最實用的一點就是支持豎直方向滾動了。
雖然很早就聽說過，但是從一些文章中也多少了解到ViewPager2使用的一些坑，也就一直沒有正式使用過。前不久ViewPager2發(fā)布了1.0.0正式版，心想是時候嘗試一下了。哈哈，可能是因為此前寫過兩篇懶加載相關(guān)的文章吧，我第一時間想到的不是ViewPager新功能的使用，而是在配合Fragment時如何實現(xiàn)懶加載。本文就來具體探究一下ViewPager2中的懶加載問題，關(guān)于ViewPager2的使用已經(jīng)有很多詳細(xì)的文章了，不是本文的研究重點，因此就不會具體介紹了。

在進(jìn)入正文之前要強(qiáng)調(diào)一下，本文的分析基于ViewPager2的1.0.0版本，是在androidx包下的，因此在使用ViewPager2之前需要做好androidx的適配工作。

利用ViewPager2加載多個Fragment

第一步、首先需要在build.gradle文件中添加ViewPager2的依賴

implementation 'androidx.viewpager2:viewpager2:1.0.0'

第二步、在布局文件中添加ViewPager2

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <androidx.viewpager2.widget.ViewPager2
        android:id="@+id/view_pager2"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />

</LinearLayout>

第三步、編寫Adapter
需要注意，ViewPager2中加載Fragment時的Adapter類需要繼承自FragmentStateAdapter，而不是ViewPager中的FragmentStatePagerAdapter。

public class MyFragmentPagerAdapter extends FragmentStateAdapter {

    private List<Fragment> mFragments;

    public MyFragmentPagerAdapter(@NonNull FragmentActivity fragmentActivity, List<Fragment> fragments) {
        super(fragmentActivity);
        this.mFragments = fragments;
    }

    @NonNull
    @Override
    public Fragment createFragment(int position) {
        return mFragments.get(position);
    }

    @Override
    public int getItemCount() {
        return mFragments.size();
    }
}

第四步、為ViewPager2設(shè)置Adapter

ViewPager2 mViewPager2 = findViewById(R.id.view_pager2);
List<Fragment> mFragments = new ArrayList<>();
mFragments .add(new FirstFragment());
mFragments .add(new SecondFragment());
mFragments .add(new ThirdFragment());
MyFragmentPagerAdapter mAdapter = new MyFragmentPagerAdapter(this, mFragments);
mViewPager2.setAdapter(mAdapter);

經(jīng)過以上幾步我們就實現(xiàn)了利用ViewPager2加載多個Fragment，當(dāng)然我這里是為了簡單演示，具體的Fragment類我就不展示了。

Fragment切換時的生命周期方法執(zhí)行情況

接下來我們具體來看一下Fragment切換時生命周期方法的執(zhí)行情況。我在測試用例中添加了6個Fragment，在Fragment的生命周期回調(diào)方法中打印執(zhí)行情況，具體執(zhí)行結(jié)果如下：

  • 初始情況顯示第一個Fragment

可以看出此時只創(chuàng)建出了第一個Fragment，生命周期方法執(zhí)行到了onResume()，其他的幾個Fragment并沒有創(chuàng)建。

  • 切換到第二個Fragment

此時創(chuàng)建出了第二個Fragment，生命周期方法同樣執(zhí)行到onResume()，同時，第一個Fragment執(zhí)行onPause()方法。

  • 切換到第三個Fragment

和上一種情況相同，創(chuàng)建出第三個Fragment，執(zhí)行到onResume()方法，同時第二個Fragment執(zhí)行onPause()方法。

  • 切換到第四個Fragment

和前兩種情況相同，同樣是創(chuàng)建出當(dāng)前Fragment，生命周期方法執(zhí)行到onResume()，并且上一個Fragment執(zhí)行onPause()方法。不同的是，此時會銷毀第一個Fragment，依次執(zhí)行onStop()、onDestroyView()、onDestroy()和onDetach()方法。

  • 切換到第五個Fragment

和上一種情況相同，創(chuàng)建出第五個Fragment，生命周期方法執(zhí)行到onResume()，第四個Fragment執(zhí)行onPause()方法，同時銷毀第二個Fragment。

  • 切換到第六個（最后一個）Fragment

可以看出此時創(chuàng)建出了第六個Fragment，生命周期方法執(zhí)行到onResume()，第五個Fragment執(zhí)行onPause()方法，如果按照上面兩種情況的執(zhí)行結(jié)果來看，此時應(yīng)該會銷毀第三個Fragment，但實際上并沒有。

從以上幾種情況下Fragment生命周期方法的執(zhí)行情況來看，不難看出ViewPager2默認(rèn)情況下不會預(yù)先創(chuàng)建出下一個Fragment。

但與此同時，F(xiàn)ragment的銷毀情況就令我有些不解了，如果不看切換到最后一個Fragment的情況，我們可以猜測是由于ViewPager2內(nèi)部RecyclerView的緩存機(jī)制導(dǎo)致最多可以存在三個Fragment，但是切換到最后一個Fragment的情況就違背了我們的猜測，很明顯此時并沒有銷毀前面的Fragment。

接下來我們就根據(jù)上述結(jié)果來分析一下ViewPager2加載Fragment的幾個問題。

ViewPager2中的setOffscreenPageLimit()方法

通過示例中的執(zhí)行結(jié)果我們可以發(fā)現(xiàn)ViewPager2默認(rèn)情況下不會像ViewPager那樣預(yù)先加載出兩側(cè)的Fragment，這是為什么呢，我們可能會想到ViewPager中預(yù)加載相關(guān)的一個方法：setOffscreenPageLimit()，ViewPager2中也定義了該方法，我們來看一下它們的區(qū)別。

首先來看ViewPager中的setOffscreenPageLimit()方法：

private static final int DEFAULT_OFFSCREEN_PAGES = 1;
private int mOffscreenPageLimit = DEFAULT_OFFSCREEN_PAGES;

public void setOffscreenPageLimit(int limit) {
    if (limit < DEFAULT_OFFSCREEN_PAGES) {
        Log.w(TAG, "Requested offscreen page limit " + limit + " too small; defaulting to "
                + DEFAULT_OFFSCREEN_PAGES);
        limit = DEFAULT_OFFSCREEN_PAGES;
    }
    if (limit != mOffscreenPageLimit) {
        mOffscreenPageLimit = limit;
        populate();
    }
}

方法傳入一個整型數(shù)值，表示當(dāng)前Fragment兩側(cè)的預(yù)加載數(shù)量，很多人可能都知道，ViewPager默認(rèn)的預(yù)加載數(shù)量為1，也就是會預(yù)先創(chuàng)建出當(dāng)前Fragment左右兩側(cè)的一個Fragment。

從代碼中我們可以看出，如果我們傳入的數(shù)值小于1，依然會將預(yù)加載數(shù)量設(shè)置為1，這也導(dǎo)致了ViewPager無法取消預(yù)加載，也因此才會需要Fragment的懶加載方案。

接下來我們來看ViewPager2中的setOffscreenPageLimit()方法：

public static final int OFFSCREEN_PAGE_LIMIT_DEFAULT = -1;
private int mOffscreenPageLimit = OFFSCREEN_PAGE_LIMIT_DEFAULT;

public void setOffscreenPageLimit(@OffscreenPageLimit int limit) {
    if (limit < 1 && limit != OFFSCREEN_PAGE_LIMIT_DEFAULT) {
        throw new IllegalArgumentException(
                "Offscreen page limit must be OFFSCREEN_PAGE_LIMIT_DEFAULT or a number > 0");
    }
    mOffscreenPageLimit = limit;
    // Trigger layout so prefetch happens through getExtraLayoutSize()
    mRecyclerView.requestLayout();
}

我們可以看出ViewPager2中默認(rèn)的預(yù)加載數(shù)量mOffscreenPageLimit為OFFSCREEN_PAGE_LIMIT_DEFAULT也就是-1，我們可以通過傳入該默認(rèn)值或者大于1的整數(shù)來設(shè)置預(yù)加載數(shù)量。

接下我們來看一下哪里用到了mOffscreenPageLimit，通過全局搜索，我們可以發(fā)現(xiàn)在ViewPager2的內(nèi)部類LinearLayoutManagerImpl中的calculateExtraLayoutSpace()方法中通過getOffscreenPageLimit()方法獲取了mOffscreenPageLimit。

@Override
protected void calculateExtraLayoutSpace(@NonNull RecyclerView.State state,
                                         @NonNull int[] extraLayoutSpace) {
    int pageLimit = getOffscreenPageLimit();
    if (pageLimit == OFFSCREEN_PAGE_LIMIT_DEFAULT) {
        // Only do custom prefetching of offscreen pages if requested
        super.calculateExtraLayoutSpace(state, extraLayoutSpace);
        return;
    }
    final int offscreenSpace = getPageSize() * pageLimit;
    extraLayoutSpace[0] = offscreenSpace;
    extraLayoutSpace[1] = offscreenSpace;
}

calculateExtraLayoutSpace()方法定義在LinearLayoutManager中，用于計算LinearLayoutManager布局的額外空間，也就是RecyclerView顯示范圍之外的空間，計算結(jié)果在保存參數(shù)extraLayoutSpace中，它是一個長度為2的整型數(shù)組，extraLayoutSpace[0]表示頂部/左側(cè)的額外空間，extraLayoutSpace[1]表示底部/右側(cè)的額外空間（取決于方向）。

LinearLayoutManagerImpl重寫了該方法，方法內(nèi)部首先判斷了mOffscreenPageLimit的值，如果等于默認(rèn)值OFFSCREEN_PAGE_LIMIT_DEFAULT，則直接調(diào)用父類方法，不設(shè)置額外的布局空間；

如果mOffscreenPageLimit的值大于1，則設(shè)置左右（或上下）兩邊的額外空間為getPageSize() * pageLimit，相當(dāng)于預(yù)加載出了兩邊的Fragment。

看到這里我們就清楚了為什么默認(rèn)情況下ViewPager2不會預(yù)加載出兩側(cè)的Fragment，就是因為默認(rèn)的預(yù)加載數(shù)量為-1。和ViewPager一樣，我們可以通過調(diào)用setOffscreenPageLimit()方法，傳入大于1的值來設(shè)置預(yù)加載數(shù)量。

在此前的示例中，我們添加下面的代碼：

mViewPager2.setOffscreenPageLimit(1);

首次顯示第一個Fragment時打印的結(jié)果如下：


可以看出此時ViewPager2就會預(yù)先創(chuàng)建出下一個Fragment，和ViewPager默認(rèn)的情況相同。

RecyclerView中的緩存和預(yù)取機(jī)制

接下來我們來看一下Fragment的銷毀情況，探究一下為什么在上面的示例中ViewPager2切換到最后一個Fragment時沒有銷毀前面的Fragment。

在此之前，我們先要了解一下RecyclerView的緩存機(jī)制和預(yù)取機(jī)制。

RecyclerView的緩存機(jī)制算是老生常談的問題了，核心在它的一個內(nèi)部類Recycler中，Item的回收和復(fù)用相關(guān)工作都是Recycler來進(jìn)行的，RecyclerView的緩存可以分為多級，由于我了解得非常淺顯，這里就不詳細(xì)介紹了，大家可以自行查看相關(guān)文章。

我們直接來看和ViewPager2中Fragment回收相關(guān)的緩存——mCachedViews，它的類型是ArrayList，移出屏幕的Item對應(yīng)的ViewHolder都會被優(yōu)先緩存到該容器中。

Recycler類中有一個成員變量mViewCacheMax，表示mCachedViews最大的緩存數(shù)量，默認(rèn)值為2，我們可以通過調(diào)用RecyclerView的setItemViewCacheSize()方法來設(shè)置緩存大小。

回到我們的具體場景中，通過查看FragmentStateAdapter類的源碼，我們可以看到，此時mCachedViews中保存的ViewHolder類型為FragmentViewHolder，它的視圖根布局是一個FrameLayout，F(xiàn)ragment會被添加到對應(yīng)的FrameLayout中，因此緩存ViewHolder其實就相當(dāng)于緩存了Fragment，為了簡明，我后面就都說成緩存Fragment了，大家清楚這樣說是不準(zhǔn)確的就好了。

在上面的示例中，我們使用ViewPager2加載了6個Fragment，當(dāng)切換到第四個Fragment時，由于最多只能緩存兩個Fragment，此時mCachedViews中緩存的是第二個Fragment和第三個Fragment，因此第一個Fragment就要被銷毀，之后切換到第五個Fragment的情況同理，此時會緩存第三個和第四個Fragment，因此第二個Fragment被銷毀。

接下來問題就來了，如果按照這樣的解釋，當(dāng)切換到第六個Fragment時應(yīng)該銷毀第三個Fragment，上面的示例中很明顯沒有啊，這又是為什么呢？

這就涉及到RecyclerView的預(yù)?。?strong>Prefetch）機(jī)制了，它是官方在support v25版本包中引入的功能，具體表現(xiàn)為在RecyclerView滑動時會預(yù)先加載出下一個Item，準(zhǔn)確地說是預(yù)先創(chuàng)建出下一個Item對應(yīng)的ViewHolder。默認(rèn)情況下預(yù)取功能是開啟的，我們可以調(diào)用下面的代碼來關(guān)閉：

mRecyclerView.getLayoutManager().setItemPrefetchEnabled(false);

那么預(yù)取機(jī)制會對ViewPager2中Fragment的銷毀產(chǎn)生什么影響呢，我們從源碼角度來簡單分析一下。首先來看RecyclerView的onTouchEvent()方法：

RecyclerView的onTouchEvent()方法

@Override
public boolean onTouchEvent(MotionEvent e) {
    // ...
    switch (action) {
        // ...
        case MotionEvent.ACTION_MOVE: {
            // ...
            if (mGapWorker != null && (dx != 0 || dy != 0)) {
                mGapWorker.postFromTraversal(this, dx, dy);
            }
        }
        break;
        // ...
    }
    // ...
    return true;
}

可以看到在RecyclerView滑動時會調(diào)用到mGapWorker的postFromTraversal()方法，將水平和豎直方向上的位移通過參數(shù)傳入，用于后面計算預(yù)取的Item位置。mGapWorker類型為GapWorker，我們來看它的postFromTraversal()方法：
GapWorker的postFromTraversal()方法

/**
 * Schedule a prefetch immediately after the current traversal.
 */
void postFromTraversal(RecyclerView recyclerView, int prefetchDx, int prefetchDy) {
    // ...
    recyclerView.post(this);
    // ...
}

從方法的注釋上我們也能看出它和RecyclerView的預(yù)取有關(guān)，方法內(nèi)部會調(diào)用RecyclerView的post()方法，參數(shù)傳入了this，也就是當(dāng)前GapWorker對象，通過查看GapWorker類的定義可以看到它實現(xiàn)了Runnable，因此這里就是提交一個任務(wù)到主線程的消息隊列中。接下來我們來看GapWorker實現(xiàn)的run()方法：

@Override
public void run() {
    // ...
    long nextFrameNs = TimeUnit.MILLISECONDS.toNanos(latestFrameVsyncMs) + mFrameIntervalNs;
    prefetch(nextFrameNs);
    // ...
}

方法內(nèi)部會調(diào)用prefetch()方法，看到方法名大概可以推測出接下來就要進(jìn)行預(yù)取相關(guān)邏輯了，我們接著來看。

void prefetch(long deadlineNs) {
    // 構(gòu)建預(yù)取任務(wù)
    buildTaskList();
    // 開始執(zhí)行預(yù)取任務(wù)
    flushTasksWithDeadline(deadlineNs);
}

prefetch()方法中首先會調(diào)用buildTaskList()方法來構(gòu)建預(yù)取任務(wù)，主要是通過此前傳過來的水平和豎直方向位移確定出預(yù)取的位置，接下來會調(diào)用flushTasksWithDeadline()方法來執(zhí)行預(yù)取任務(wù)，我們這里只看buildTaskList()方法就好。

private void buildTaskList() {
    final int viewCount = mRecyclerViews.size();
    int totalTaskCount = 0;
    for (int i = 0; i < viewCount; i++) {
        RecyclerView view = mRecyclerViews.get(i);
        if (view.getWindowVisibility() == View.VISIBLE) {
            // 關(guān)鍵代碼
            view.mPrefetchRegistry.collectPrefetchPositionsFromView(view, false);
            totalTaskCount += view.mPrefetchRegistry.mCount;
        }
    }
    // ...
}

接下來又會調(diào)用RecyclerView中mPrefetchRegistry的collectPrefetchPositionsFromView()方法，mPrefetchRegistry的類型為LayoutPrefetchRegistryImpl，它是GapWorker中的一個內(nèi)部類，我們接著來看它的collectPrefetchPositionsFromView()方法。

void collectPrefetchPositionsFromView(RecyclerView view, boolean nested) {
    mCount = 0;
    // ...
    final RecyclerView.LayoutManager layout = view.mLayout;
    if (view.mAdapter != null
            && layout != null
            && layout.isItemPrefetchEnabled()) {
        // ...
        // momentum based prefetch, only if we trust current child/adapter state
        if (!view.hasPendingAdapterUpdates()) {
            layout.collectAdjacentPrefetchPositions(mPrefetchDx, mPrefetchDy,
                    view.mState, this);
        }

        if (mCount > layout.mPrefetchMaxCountObserved) {
            layout.mPrefetchMaxCountObserved = mCount;
            layout.mPrefetchMaxObservedInInitialPrefetch = nested;
            view.mRecycler.updateViewCacheSize();
        }
    }
}

方法內(nèi)部首先會將LayoutPrefetchRegistryImpl中的成員變量mCount置為0，接著通過isItemPrefetchEnabled()方法判斷RecyclerView是否開啟了預(yù)取，默認(rèn)是開啟的，接下來會執(zhí)行l(wèi)ayout的collectAdjacentPrefetchPositions()方法，這里的layout是RecyclerView設(shè)置的LayoutManager，我們以LinearLayoutManager為例，看一下它的collectAdjacentPrefetchPositions()方法。

LinearLayoutManager的collectAdjacentPrefetchPositions()方法

@Override
public void collectAdjacentPrefetchPositions(int dx, int dy, RecyclerView.State state,
                                             LayoutPrefetchRegistry layoutPrefetchRegistry) {
    // ...
    collectPrefetchPositionsForLayoutState(state, mLayoutState, layoutPrefetchRegistry);
}

void collectPrefetchPositionsForLayoutState(RecyclerView.State state, LayoutState layoutState,
                                            LayoutPrefetchRegistry layoutPrefetchRegistry) {
    // ...
    layoutPrefetchRegistry.addPosition(pos, Math.max(0, layoutState.mScrollingOffset));
}

方法內(nèi)部又會調(diào)用collectPrefetchPositionsForLayoutState()方法，接著調(diào)用layoutPrefetchRegistry的addPosition()方法，這里的layoutPrefetchRegistry是從上面的collectPrefetchPositionsFromView()方法中傳過來的，可以看到參數(shù)傳的是this，也就是LayoutPrefetchRegistryImpl對象。我們接著來看LayoutPrefetchRegistryImpl的addPosition()方法：
LayoutPrefetchRegistryImpl的addPosition()方法

@Override
public void addPosition(int layoutPosition, int pixelDistance) {
    // ...
    mCount++;
}

可以看到方法最后會將mCount加1，此時mCount的值變?yōu)?。接下來我們回到collectPrefetchPositionsFromView()方法，來看方法最后執(zhí)行的一個判斷。

if (mCount > layout.mPrefetchMaxCountObserved) {
    layout.mPrefetchMaxCountObserved = mCount;
    layout.mPrefetchMaxObservedInInitialPrefetch = nested;
    view.mRecycler.updateViewCacheSize();
}

這里判斷了mCount和mPrefetchMaxCountObserved的大小關(guān)系，mPrefetchMaxCountObserved是LayoutManager中定義的一個整型變量，初始值為0，因此這里會進(jìn)入到if判斷中。

接著會將mCount賦值給mPrefetchMaxCountObserved，此時mPrefetchMaxCountObserved的值變?yōu)?，最后會調(diào)用Recycler的updateViewCacheSize()方法，我們來看一下這個方法。
Recycler的updateViewCacheSize()方法

void updateViewCacheSize() {
    int extraCache = mLayout != null ? mLayout.mPrefetchMaxCountObserved : 0;
    mViewCacheMax = mRequestedCacheMax + extraCache;

    // first, try the views that can be recycled
    for (int i = mCachedViews.size() - 1;
         i >= 0 && mCachedViews.size() > mViewCacheMax; i--) {
        recycleCachedViewAt(i);
    }
}

方法內(nèi)部首先定義了一個整型變量extraCache，字面上看就是額外的緩存，它的值就是上一步中的mPrefetchMaxCountObserved，也就是1。

接下來這一步就重要了，將mRequestedCacheMax + extraCache賦值給mViewCacheMax，我們前面在介紹RecyclerView緩存的時候提到過mViewCacheMax表示mCachedViews的最大緩存數(shù)量，mRequestedCacheMax就是我們設(shè)置的mCachedViews緩存數(shù)量，默認(rèn)值為2，因此此時mViewCacheMax的值被設(shè)置為3，也就是說mCachedViews最多可以保存3個ViewHolder（對于我們的場景來說就是Fragment）。

看到這里我們就大致清楚了示例中Fragment銷毀情況產(chǎn)生的原因，當(dāng)從第一個Fragment切換到第二個Fragment時會執(zhí)行我們上面分析的預(yù)取邏輯，將mCachedViews的最大緩存數(shù)量由默認(rèn)的2置為3。

對于切換到第三、第四和第五個Fragment的情況，由于預(yù)取的Fragment占據(jù)了mCachedViews中的一個位置，因此還是表現(xiàn)為最多緩存2個Fragment。

當(dāng)切換到第六個也就是最后一個Fragment時，不需要再預(yù)取下一個Fragment了，但是此時mCachedViews的最大緩存數(shù)量依然為3，所以第三個Fragment也可以被添加到緩存中，不會被銷毀。

為了驗證得出的結(jié)論，我們首先通過代碼取消ViewPager2內(nèi)部RecyclerView的預(yù)取機(jī)制：

((RecyclerView) mViewPager2.getChildAt(0)).getLayoutManager().setItemPrefetchEnabled(false);

然后再來運行一下此前的示例程序，直接來看切換到最后一個Fragment的情況。


可以看出當(dāng)切換到最后一個Fragment時會銷毀掉第三個Fragment，此時緩存的Fragment為第四和第五個，這是由于我們關(guān)閉了預(yù)取機(jī)制，在執(zhí)行LayoutPrefetchRegistryImpl中的collectPrefetchPositionsFromView()方法時不滿足layout.isItemPrefetchEnabled()為true的條件，不會執(zhí)行后面的邏輯，因此mCachedViews的最大緩存數(shù)量始終為2，這就驗證了我們的結(jié)論是沒錯的。

ViewPager2中的懶加載方案

由于ViewPager2默認(rèn)情況下不會預(yù)加載出兩邊的Fragment，相當(dāng)于默認(rèn)就是懶加載的，因此如果我們?nèi)绻麤]有通過setOffscreenPageLimit()方法設(shè)置預(yù)加載數(shù)量，完全可以不做任何額外處理。但是對于Fragment很多的情況，由于ViewPager2中的RecyclerView可以緩存Fragment的數(shù)量是有限的，因此會造成Fragment的多次銷毀和創(chuàng)建，如何解決這個問題呢？下面就介紹一下我的解決方案。

首先設(shè)置ViewPager2的預(yù)加載數(shù)量，讓ViewPager2預(yù)先創(chuàng)建出所有的Fragment，防止切換造成的頻繁銷毀和創(chuàng)建。

mViewPager2.setOffscreenPageLimit(mFragments.size());

通過此前示例中Fragment切換時生命周期方法的執(zhí)行情況我們不難發(fā)現(xiàn)不管Fragment是否會被預(yù)先創(chuàng)建，只有可見時才會執(zhí)行到onResume()方法，我們正好可以利用這一規(guī)律來實現(xiàn)懶加載，具體實現(xiàn)方式和我此前介紹過的androidx中的Fragment懶加載方案相同，這里我再簡單說一下。

  • 將Fragment加載數(shù)據(jù)的邏輯放到onResume()方法中，這樣就保證了Fragment可見時才會加載數(shù)據(jù)。
  • 聲明一個變量標(biāo)記是否是首次執(zhí)行onResume()方法，因為每次Fragment由不可見變?yōu)榭梢姸紩?zhí)行onResume()方法，需要防止數(shù)據(jù)的重復(fù)加載。
    按照以上兩點就可以封裝我們的懶加載Fragment了，完整代碼如下：
public abstract class LazyFragment extends Fragment {

    private Context mContext;
    private boolean isFirstLoad = true; // 是否第一次加載

    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mContext = getActivity();
    }

    @Nullable
    @Override
    public View onCreateView(@NonNull LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
        View view = LayoutInflater.from(mContext).inflate(getContentViewId(), null);
        initView(view);
        return view;
    }

    @Override
    public void onResume() {
        super.onResume();
        if (isFirstLoad) {
            // 將數(shù)據(jù)加載邏輯放到onResume()方法中
            initData();
            initEvent();
            isFirstLoad = false;
        }
    }

    /**
     * 設(shè)置布局資源id
     *
     * @return
     */
    protected abstract int getContentViewId();

    /**
     * 初始化視圖
     *
     * @param view
     */
    protected void initView(View view) {

    }

    /**
     * 初始化數(shù)據(jù)
     */
    protected void initData() {

    }

    /**
     * 初始化事件
     */
    protected void initEvent() {

    }
}

當(dāng)然這只是我認(rèn)為比較好的一種方案，如果有什么地方考慮得有問題或是大家有自己的見解都?xì)g迎提出。

總結(jié)

本文探究了利用ViewPager2加載Fragment時生命周期方法的執(zhí)行情況，進(jìn)而得出ViewPager2懶加載的實現(xiàn)方式：

簡單來說完全可以不做任何處理，ViewPager2默認(rèn)就實現(xiàn)了懶加載。但是如果想避免Fragment頻繁銷毀和創(chuàng)建造成的開銷，可以通過setOffscreenPageLimit()方法設(shè)置預(yù)加載數(shù)量，將數(shù)據(jù)加載邏輯放到Fragment的onResume()方法中。

雖說本文的研究對象是ViewPager2，但是文章大部分篇幅都是在分析RecyclerView，不得不感嘆RecyclerView確實是一個很重要的控件，如何使用大家基本都已經(jīng)爛熟于心了，但是涉及到原理上的東西就不一樣了，我對RecyclerView的了解也是甚淺，有時間的話還是有必要深入學(xué)習(xí)一下的。

點關(guān)注，獲得更多Android開發(fā)技能~~

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

友情鏈接更多精彩內(nèi)容