Android-Paging源码分析

·  阅读 889

Paging架构

  再回头看一眼Paging的架构图 可以看到Paing的核心是PagedList,这个PagedList携带着一个DataSource,也即产生数据的工厂,PagedList中还有分页的配置,例如每页多少个数据,距离底部多少个数据时开始自动加载下一页数据,以及设置加载与更新UI的线程等。
  从触发机制与数据流向角度看,构建PagedList是在页面初始化或者下拉刷新时,使用PagedList.Builder,传入PagedList.Config和DataSource.Factory两个对象。构造出来的PagedList对象调用Adapter.submitList方法传给Adapter,Adapter中持有传入的PagedList对象。submitList还会触发DataSource的loadInitial方法来初始化数据,其实这里初始化数据有两种形式,可以先把数据准备好再调用submitList,在loadInitial方法中直接将数据喂给callback即可,或者还可以在loadInitial方法中触发数据请求,在请求结果回调中调用callback将数据传给Adapter,这些就是触发数据加载的两种逻辑。
  从上图中即可看出数据流向的逻辑,数据从DataSource中生产出来,不管是loadInitial还是loadAfter又或者是loadBefore,都是使用callback调用onResult将数据回传。

构造PagedList

首先来看看PagedList的类结构,其内部有BoundaryCallback、Builder、Callback、Config四个内部类。一个一个来看具体定义
  首先是BoundaryCallback,

@MainThread
    public abstract static class BoundaryCallback<T> {

        public void onZeroItemsLoaded() {}

        public void onItemAtFrontLoaded(@NonNull T itemAtFront) {}

        public void onItemAtEndLoaded(@NonNull T itemAtEnd) {}
    }
复制代码

把注释都删掉只下定义了3个方法,看这个类的注释,意思大概是如果将本地缓存数据当作网络数据的缓存时,用本地数据构造了一个PagedList并更新到UI上时,这时还是需要通知一下触发一下网络请求的。也就是说我们可以在将数据传给Adapter更新UI的同时异步加载网络数据,并将网络数据储存到本地,而DataSource每次只需要从本地取数据即可,而这个BoundaryCallback就是用来通知触发异步加载网络数据的。
  根据调用堆栈,可发现这个onZeroItemsLoaded是在DataSource的callback.onResult中调用,且callback传回来的数据为空。下面两个方法onItemAtFrontLoaded和onItemAtEndLoaded则分别是在PagedList滑动到可自动加载下一页数据时触发。当DataSource中callback传回数据时,发现当前PagedList数据不为空,而请求传回的数据为空时,这也会被当作是可加载下一页数据。总结一下,BoundaryCallback的三个方法是在自动触发加载下一页数据时回调的,或者是当前PagedList数据不为空,也就是Adapter有内容,而新加载的数据为空时调用。从感性上来说,这个BoundaryCallback应该是一个数据加载监听的辅助接口,用于在加载数据时再异步辅助加载更多数据。
  再看看这个PagedList.Builder类,这纯粹就是个Build模式类,仅仅是为了传入一个参数从而构造出一个PagedList对象。查看其build方法,限制了NotifyExecutor和FetchExecutor不能为null,最后调用了PageList.create方法,将set的参数传入,返回一个PagedList对象。在PagedList.create方法中,有两个分支,分别创建的是ContiguousPagedList和TitledPagedList。判断是dataSource.isContiguous,这个返回值表示两页之间是不是承接式的,也即两页之间的关系是不是当前页和上一页下一页这样的有关系,这样返回的是ContiguousPagedList对象,否则返回TiledPagedList对象,tiled表示是不是平铺的,也即每个Item之间确定关系,是根据item的位置关系来加载更多数据的。
  再来看PagedList.Config类,这个类结构较为简单,只定义了几个字段外加一个Builder

public static class Config {
        @SuppressWarnings("WeakerAccess")
        public static final int MAX_SIZE_UNBOUNDED = Integer.MAX_VALUE;

        public final int pageSize;

        @SuppressWarnings("WeakerAccess")
        public final int prefetchDistance;

        @SuppressWarnings("WeakerAccess")
        public final boolean enablePlaceholders;

        public final int maxSize;
复制代码

pageSize表示每页的item数量,prefetchDistance表示距离底部或顶部还差多少个item就开始触发loadAfter和loadBefore,enablePlaceHolder表示是否支持展示null placeholders,maxSize表示这个pageList的最大容量。
  PagedList还有一个Callback的内部类

public abstract static class Callback {
        public abstract void onChanged(int position, int count);

        public abstract void onInserted(int position, int count);

        @SuppressWarnings("unused")
        public abstract void onRemoved(int position, int count);
    }
复制代码

只有三个方法,分别表示PagedList中的数据发生了变化、插入了数据,移除了数据。这个Callback接口只是为了监听PagedList的数据变化,AsyncPagedListDiffer对其的实现是mPagedListCallback对象,在相应的实现方法中直接调用了mUpdateCallback的相应方法,这个mUpdateCallback是AdapterListUpdateCallback类型的。在AdapterListUpdateCallback中的相应方法中,就调用了RecyclerView.Adapter的相应局部刷新api。

public final class AdapterListUpdateCallback implements ListUpdateCallback {
    @NonNull
    private final RecyclerView.Adapter mAdapter;

    public AdapterListUpdateCallback(@NonNull RecyclerView.Adapter adapter) {
        mAdapter = adapter;
    }

    @Override
    public void onInserted(int position, int count) {
        mAdapter.notifyItemRangeInserted(position, count);
    }

    @Override
    public void onRemoved(int position, int count) {
        mAdapter.notifyItemRangeRemoved(position, count);
    }

    @Override
    public void onMoved(int fromPosition, int toPosition) {
        mAdapter.notifyItemMoved(fromPosition, toPosition);
    }

    @Override
    public void onChanged(int position, int count, Object payload) {
        mAdapter.notifyItemRangeChanged(position, count, payload);
    }
}
复制代码

这样就明白了为什么PagedList的数据变化可以触发Adapter的刷新,从而导致RecyclerView的布局变化了。
  再来看看PagedList的一些成员属性和成员方法。重要的成员属性有两个Executor,分别表示加载数据和刷新UI所在的线程。这里又出来一个新的类PagedStorage,看这名字应该是真正用来储存Page的List,查看其源码,发现其内部有个mPages的ArrayList<List>的变量,而每次对page的变量,都最终会作用到这个mPages的变量来。因此得出结论,PagedList真正用来储存item数据的是这个PagedStorage,虽然PagedList继承自AbstractList,但它对AbstractList的实现都是用的PagedStorage。

submitList执行的操作

  从结构上看了PagedList之后,已经得知数据是如何储存,数据更新是如何调用Adapter去更新UI的,再从数据流角度来看。

public void submitList(@Nullable final PagedList<T> pagedList,
            @Nullable final Runnable commitCallback) {
        if (pagedList != null) {
            if (mPagedList == null && mSnapshot == null) {
                mIsContiguous = pagedList.isContiguous();
            } else {
                if (pagedList.isContiguous() != mIsContiguous) {
                    throw new IllegalArgumentException("AsyncPagedListDiffer cannot handle both"
                            + " contiguous and non-contiguous lists.");
                }
            }
        }

        // incrementing generation means any currently-running diffs are discarded when they finish
        final int runGeneration = ++mMaxScheduledGeneration;

        if (pagedList == mPagedList) {
            // nothing to do (Note - still had to inc generation, since may have ongoing work)
            if (commitCallback != null) {
                commitCallback.run();
            }
            return;
        }

        final PagedList<T> previous = (mSnapshot != null) ? mSnapshot : mPagedList;

        if (pagedList == null) {
            int removedCount = getItemCount();
            if (mPagedList != null) {
                mPagedList.removeWeakCallback(mPagedListCallback);
                mPagedList = null;
            } else if (mSnapshot != null) {
                mSnapshot = null;
            }
            // dispatch update callback after updating mPagedList/mSnapshot
            mUpdateCallback.onRemoved(0, removedCount);
            onCurrentListChanged(previous, null, commitCallback);
            return;
        }

        if (mPagedList == null && mSnapshot == null) {
            // fast simple first insert
            mPagedList = pagedList;
            pagedList.addWeakCallback(null, mPagedListCallback);

            // dispatch update callback after updating mPagedList/mSnapshot
            mUpdateCallback.onInserted(0, pagedList.size());

            onCurrentListChanged(null, pagedList, commitCallback);
            return;
        }

        if (mPagedList != null) {
            // first update scheduled on this list, so capture mPages as a snapshot, removing
            // callbacks so we don't have resolve updates against a moving target
            mPagedList.removeWeakCallback(mPagedListCallback);
            mSnapshot = (PagedList<T>) mPagedList.snapshot();
            mPagedList = null;
        }

        if (mSnapshot == null || mPagedList != null) {
            throw new IllegalStateException("must be in snapshot state to diff");
        }

        final PagedList<T> oldSnapshot = mSnapshot;
        final PagedList<T> newSnapshot = (PagedList<T>) pagedList.snapshot();
        mConfig.getBackgroundThreadExecutor().execute(new Runnable() {
            @Override
            public void run() {
                final DiffUtil.DiffResult result;
                result = PagedStorageDiffHelper.computeDiff(
                        oldSnapshot.mStorage,
                        newSnapshot.mStorage,
                        mConfig.getDiffCallback());

                mMainThreadExecutor.execute(new Runnable() {
                    @Override
                    public void run() {
                        if (mMaxScheduledGeneration == runGeneration) {
                            latchPagedList(pagedList, newSnapshot, result,
                                    oldSnapshot.mLastLoad, commitCallback);
                        }
                    }
                });
            }
        });
    }
复制代码

首先是PagedListAdapter的submitList方法,这个方法是将生产出来的PagedList直接交由Differ处理。AsyncPagedListDiffer的submitList方法实现是先判断传入的pagedList是否和当前Adapter中的PagedList为同一对象,如果是的话,就直接返回了。再判断传入的PagedList是否为null,如果为null就将Adapter中的当前PagedList也置为null,同时移除对PagedList数据的监听,通知PagedList.Callback的onRemove方法。如果传入的PagedList不为null但Adapter中的当前PagedList为null,则当成是新插入进来的数据 。如果Adapter的当前PagedList也不为null,则从当前PagedList中取出一个Snapshot,也就是一个快照,这里的快照的概念也不复杂,就是如果未detach UI,就新创建一个SnapshotPagedList对象,这个对象的属性全copy自这个PagedList,如果已经detach UI了,则直接返回PagedList自身即可。这是为什么要使用快照而不是使用本身的数据呢?这是因为Paging的Differ过程在异步线程,在diff的过程中,可能数据已经发生了变化。最后从Config中取出后台线程执行Diff操作,Diff的结果再用Main线程执行latchPagedList,将结果更新到Adapter去。这里看一下真正的diff过程,在PagedStorageDiffHelper的computeDiff方法中,computeDiff方法调用了DiffUtil的calculateDiff方法,这里使用了DiffUtil.Callback接口来定义diff。分为三层diff,第一层是areItemsTheSame,表示item对象是否为同一个,第二层是areContentsTheSame,表示item的内容是否相同,第三层是getChangePayload,表示是否有其他的更改。这里的diff过程还使用了Config.getDiffCallback来为DiffUtil的Callback默认实现识别不了的确认最终结果,这个Config.getDiffCallback是我们在创建PagedListAdapter时构造器传入的DiffUtil.ItemCallback对象。

public abstract static class ItemCallback<T> {

        public abstract boolean areItemsTheSame(@NonNull T oldItem, @NonNull T newItem);

       
        public abstract boolean areContentsTheSame(@NonNull T oldItem, @NonNull T newItem);

  
        @SuppressWarnings({"WeakerAccess", "unused"})
        @Nullable
        public Object getChangePayload(@NonNull T oldItem, @NonNull T newItem) {
            return null;
        }
    }
复制代码

这里取出对比的oldItem和newItem也是有说法的,虽说是分别从oldList和newList中取出的,但确实是跳过了PagedList中作为PlaceHolder的item。这里具体的diff逻辑是复用了RecyclerView的diff,这里其实使用差量算法,具体算法原理可见差量算法
  最后在Main线程中调用latchPagedList,在这之前还有一个mMaxScheduledGeneration == runGeneration判断,这个判断是干啥用的呢?可以看到在submitList开始的时候,有个final int runGeneration = ++mMaxScheduledGeneration的操作,这其实是为了防止在diff至更新UI之间的时间内有另一个submitList调用过来,如果有另一个过程,则前一个在进入主线程时,mMaxScheduledGeneration == runGeneration将为false,latchPagedList将不能执行,也即丢弃前一次的diff结果。latchPagedList方法中最主要的操作是调用了PagedStorageDiffHelper的dispatchDiff方法,这个方法将diff结果回调给传入的ListUpdateCallback对象。这个ListUpdateCallback对象也即AdapterListUpdateCallback,也就是前面说过的,相应的方法会调用RecyclerView的局部刷新api。这样submitList的数据从传入pagedList到更新到Adapter进而刷新到RecyclerView的流程也确定了。

自动loadmore原理

  在上一篇文章中介绍如何用Paging实现一个典型的Feed中说到过,自动触发loadmore其实是调用getItem触发的。看下PagedListAdapter的getItem的实现,其实是调用了mDiffer的getItem方法。

public T getItem(int index) {
        if (mPagedList == null) {
            if (mSnapshot == null) {
                throw new IndexOutOfBoundsException(
                        "Item count is zero, getItem() call is invalid");
            } else {
                return mSnapshot.get(index);
            }
        }

        mPagedList.loadAround(index);
        return mPagedList.get(index);
    }
复制代码

在AsyncPagedListDiffer的getItem方法中,首先判断mPagedList是否为null,如果为null,则从mSnapshot中取,当mSnapshot也为null时,则直接抛个IndexOutOfBoundsException异常。什么时候mPagedList为null,而mSnapshot不为null呢?在AsyncPagedListDiffer的submitList中如果要更新pagedList,则

if (mPagedList != null) {
            // first update scheduled on this list, so capture mPages as a snapshot, removing
            // callbacks so we don't have resolve updates against a moving target
            mPagedList.removeWeakCallback(mPagedListCallback);
            mSnapshot = (PagedList<T>) mPagedList.snapshot();
            mPagedList = null;
        }
复制代码

这里就是让mPagedList为null而mSnapshot不为null的地方。当mPagedList为null而mSnapshot不为null,也说明正在submit,在刷新列表,这里就不应该触发自动loadmore了,因此就直接return了。否则就调用mPagedList.loadAround方法, PagedList的loadAround中主要是调用了其内部方法loadAroundInternal方法,loadAroundInternal在PagedList中是个抽象方法,在ContiguousPagedList中的实现如下

@MainThread
    @Override
    protected void loadAroundInternal(int index) {
        int prependItems = getPrependItemsRequested(mConfig.prefetchDistance, index,
                mStorage.getLeadingNullCount());
        int appendItems = getAppendItemsRequested(mConfig.prefetchDistance, index,
                mStorage.getLeadingNullCount() + mStorage.getStorageCount());

        mPrependItemsRequested = Math.max(prependItems, mPrependItemsRequested);
        if (mPrependItemsRequested > 0) {
            schedulePrepend();
        }

        mAppendItemsRequested = Math.max(appendItems, mAppendItemsRequested);
        if (mAppendItemsRequested > 0) {
            scheduleAppend();
        }
    }
复制代码

getPrependItemsRequested是计算当前位置上还剩多少个就要开加载顶部了,而getAppendItemsRequested是计算当前位置上还剩多个少就要加载底部了,具体计算逻辑如下

static int getPrependItemsRequested(int prefetchDistance, int index, int leadingNulls) {
        return prefetchDistance - (index - leadingNulls);
    }

    static int getAppendItemsRequested(
            int prefetchDistance, int index, int itemsBeforeTrailingNulls) {
        return index + prefetchDistance + 1 - itemsBeforeTrailingNulls;
    }
复制代码

如果要加载顶部就调用schedulePrepend,加载底部就调用scheduleAppend,schedulePrepend和scheduleAppend中分别调用了dataSource的loadBefore和loadAfter。以scheduleAppend为例,scheduleAppend中先计算出要加载的position,然后使用BackgroundThradExecutor执行DataSource的dispatchLoadAfter方法。ItemKeyedDataSource对dispatchLoadAfter的实现是调用其loadAfter方法,这里就到了我们对DataSource实现的loadAfter方法了。而我们使用callback.onResult传回值的callback实现是LoadCallbackImpl类,其onResult方法是调用了LoadCallbackHelper方法的dispatchResultToReceiver。这个dispatchResultToReceiver方法中也是在传入的MainThreadExecutor中执行传入的Receiver的onPageResult方法,这个Receiver是从ContiguousPagedList中传到DataSource中去的,ContiguousPagedList中对这个Receiver的实现如下

PageResult.Receiver<V> mReceiver = new PageResult.Receiver<V>() {
        // Creation thread for initial synchronous load, otherwise main thread
        // Safe to access main thread only state - no other thread has reference during construction
        @AnyThread
        @Override
        public void onPageResult(@PageResult.ResultType int resultType,
                @NonNull PageResult<V> pageResult) {
            if (pageResult.isInvalid()) {
                detach();
                return;
            }

            if (isDetached()) {
                // No op, have detached
                return;
            }

            List<V> page = pageResult.page;
            if (resultType == PageResult.INIT) {
                mStorage.init(pageResult.leadingNulls, page, pageResult.trailingNulls,
                        pageResult.positionOffset, ContiguousPagedList.this);
                if (mLastLoad == LAST_LOAD_UNSPECIFIED) {
                    // Because the ContiguousPagedList wasn't initialized with a last load position,
                    // initialize it to the middle of the initial load
                    mLastLoad =
                            pageResult.leadingNulls + pageResult.positionOffset + page.size() / 2;
                }
            } else {
                // if we end up trimming, we trim from side that's furthest from most recent access
                boolean trimFromFront = mLastLoad > mStorage.getMiddleOfLoadedRange();

                // is the new page big enough to warrant pre-trimming (i.e. dropping) it?
                boolean skipNewPage = mShouldTrim
                        && mStorage.shouldPreTrimNewPage(
                                mConfig.maxSize, mRequiredRemainder, page.size());

                if (resultType == PageResult.APPEND) {
                    if (skipNewPage && !trimFromFront) {
                        // don't append this data, drop it
                        mAppendItemsRequested = 0;
                        mAppendWorkerState = READY_TO_FETCH;
                    } else {
                        mStorage.appendPage(page, ContiguousPagedList.this);
                    }
                } else if (resultType == PageResult.PREPEND) {
                    if (skipNewPage && trimFromFront) {
                        // don't append this data, drop it
                        mPrependItemsRequested = 0;
                        mPrependWorkerState = READY_TO_FETCH;
                    } else {
                        mStorage.prependPage(page, ContiguousPagedList.this);
                    }
                } else {
                    throw new IllegalArgumentException("unexpected resultType " + resultType);
                }

                if (mShouldTrim) {
                    if (trimFromFront) {
                        if (mPrependWorkerState != FETCHING) {
                            if (mStorage.trimFromFront(
                                    mReplacePagesWithNulls,
                                    mConfig.maxSize,
                                    mRequiredRemainder,
                                    ContiguousPagedList.this)) {
                                // trimmed from front, ensure we can fetch in that dir
                                mPrependWorkerState = READY_TO_FETCH;
                            }
                        }
                    } else {
                        if (mAppendWorkerState != FETCHING) {
                            if (mStorage.trimFromEnd(
                                    mReplacePagesWithNulls,
                                    mConfig.maxSize,
                                    mRequiredRemainder,
                                    ContiguousPagedList.this)) {
                                mAppendWorkerState = READY_TO_FETCH;
                            }
                        }
                    }
                }
            }

            if (mBoundaryCallback != null) {
                boolean deferEmpty = mStorage.size() == 0;
                boolean deferBegin = !deferEmpty
                        && resultType == PageResult.PREPEND
                        && pageResult.page.size() == 0;
                boolean deferEnd = !deferEmpty
                        && resultType == PageResult.APPEND
                        && pageResult.page.size() == 0;
                deferBoundaryCallbacks(deferEmpty, deferBegin, deferEnd);
            }
        }
    };
复制代码

代码虽然有点多,但逻辑其实挺简单的,有个if-else分别,分别表示是否是INIT,这个INIT就是loadInitial方法的onResult,如果是INIT就调用PagedStorage的init方法进行初始化,否则就要在else分支中判断是添加到顶部还是底部,判断依据仍然是resultType,也就是说这个resultType有INIT、PREPEND和APPEND三种取值。最后都会将callback.onResult传回来的Item的list会被添加到PagedStorage中去,分别是PagedStorage的prependPage方法和appendPage方法,在添加的过程中,PagedStorage中回调了传入的callback,回调的实现类就是ContiguousPagedList本身,这个回调的实现就是调用了ContiguousPagedList的notify相关方法。而前面也讲过了,这些notify相关方法中是调用了PagedList.Callback的相关回调方法,而AsyncPagedListDiffer中对PagedList.Callback的实现是调用了ListUpdateCallback的相关回调方法。ListUpdateCallback的实现类是AdapterListUpdateCallback,里面的相关回调方法中直接调用了RecyclerView.Adapter的局部刷新api。

总结

  从整个结构和数据流程上来讲,Paging框架并没有实现什么高科技的操作,都是复用的RecyclerView.Adapter的局部刷新api,理论来说如果要求对性能更高,直接用RecyclerView.Adapter的局部刷新api,性能可能会更好一些。个人感觉Paging是为实现一个典型的Feed流提供了一个通用框架,让开发者不用基于滑动手势监听来触发loadmore了,也不用自己维护一个Item的list,处理各种局部刷新的场景,因为Paging只提供了一个刷新的api——submitList方法。
  但Paging唯一可被吐槽的劣势也很明显,那就是它和RecyclerView.Adapter一样,需要通过继承才能使用Paging的能力。如果已有业务方想要接入Paging,但不想替换掉已有的Adapter,那可能就很难接入Paging了,例如我在公司的直播中台和小说业务方,他们的Adapter是个RecyclerView.Adapter,而且还经过了他们的深度定制,要他们因为接入我们的app而改变Adapter的继承结构,很显示是不现实的,他们这种中台类业务方,是同一套sdk接入多个app,因此只能让我们适配他们。
  对于Adapter无法打断继承结构,我的做法是参考HeaderAndFooterRecyclerViewAdapter的做法,用 RecyclerView.AdapterDataObserver监听原生的RecyclerView.Adapter的数据变化,也就是原生RecyclerView.Adapter调用了notify相关方法时,会触发AdapterDataObserver的相关方法回调,在这些刷新方法中调用PagedListAdapter的submitList方法,这样就能以Wapper的方式用PagedListAdapter将RecyclerView.Adapter给包一层了。RecyclerView真正使用的是PagedListAdapter,而中台业务方却还以为使用自己的Adapter,以此来达到对业务方使用透明的目的,只要不乱用RecyclerView.getAdapter instanceOf CustomAdapter这种操作。

分类:
Android
标签:
分类:
Android
标签:
收藏成功!
已添加到「」, 点击更改