iOS 和 Android：UITableView与RecycleView的重用机制比较

引言：iOS和Android各有自己的列表组件。众所周知，列表组件一直都是移动端各个端中，组件重用、内存优化的重点。今天就来分析下iOS和Android各自的重用机制。

Android：RecyclerView的缓存机制

先来熟悉下ViewHolder的几个状态

isInvalid：表示当前ViewHolder是否已经失效。通常来说，在3种情况下会出现这种情况：1.调用了Adapter的notifyDataSetChanged方法；2. 手动调用RecyclerView的invalidateItemDecorations方法；3. 调用RecyclerView的setAdapter方法或者swapAdapter方法。

isRemoved：表示当前的ViewHolder是否被移除。通常来说，数据源被移除了部分数据，然后调用Adapter的notifyItemRemoved方法。

isBound：表示当前ViewHolder是否已经调用了onBindViewHolder。

isTmpDetached：表示当前的ItemView是否从RecyclerView(即父View)detach掉。通常来说有两种情况下会出现这种情况：1.手动了RecyclerView的detachView相关方法；2. 在从mHideViews里面获取ViewHolder,会先detach掉这个ViewHolder关联的ItemView。

isScrap：表示是否在mAttachedScrap或者mChangedScrap数组里面，进而表示当前ViewHolder是否被废弃。

isUpdated：表示当前ViewHolder是否已经更新。通常来说，在3种情况下会出现情况：1.isInvalid方法存在的三种情况；2.调用了Adapter的onBindViewHolder方法；3. 调用了Adapter的notifyItemChanged方法

mAttachedScrap、mChangedScrap

mAttachedScrap存储的是当前还在屏幕中的ViewHolder，用不是人话来描述，就是是从屏幕上分离出来，但是又即将添加到屏幕上去的ViewHolder（什么鬼？）。打个比方，RecyclerView上下滑动，此时会重新调用LayoutManager的onLayoutChildren方法，屏幕上所有的ViewHolder先scrap掉，添加到mAttachedScrap里面去，然后在重新布局每个ItemView时，会从优先mAttachedScrap里面获取。而mChangedScrap存储的是数据被更新的ViewHolder，比如说调用了Adapter的notifyItemChanged方法。个人理解，这两个缓存个虽然也算是缓存重用，但和我们平时接触的有区别（这话讲的有点扭捏），它并不是传统的删除对象后缓存起来待到需要新建对象时复用的机制。

我们通过RecyclerView的源码来了解一下这两个缓存机制的区别

void scrapView(View view) {final ViewHolder holder = getChildViewHolderInt(view);if (holder.hasAnyOfTheFlags(ViewHolder.FLAG_REMOVED | ViewHolder.FLAG_INVALID)|| !holder.isUpdated() || canReuseUpdatedViewHolder(holder)) {if (holder.isInvalid() && !holder.isRemoved() && !mAdapter.hasStableIds()) {throw new IllegalArgumentException("Called scrap view with an invalid view."+ " Invalid views cannot be reused from scrap, they should rebound from"+ " recycler pool." + exceptionLabel());}holder.setScrapContainer(this, false);mAttachedScrap.add(holder);} else {if (mChangedScrap == null) {mChangedScrap = new ArrayList<ViewHolder>();}holder.setScrapContainer(this, true);mChangedScrap.add(holder);}}

这个方法简单来说就是通过holder的tag来区分应该放入mAttachedScrap还是mChangedScrap。

当holder满足以下几个条件之一，会被放入mAttachedScrap

被同时标记为remove和invalid
完全没有被改变
canReuseUpdatedViewHolder方法的返回值为true 。canReuseUpdatedViewHolder方法嵌套了好几层函数调用，这里不展开，简单来说holder的mItemAnimator为空，或者mItemAnimator的canReuseUpdatedViewHolder方法为true

当这些条件都不满足时，或者说holder的isUpdated方法返回为true时（即调用Adapter的notifyItemChanged方法时），会放入到mChangedScrap里面去

mCachedViews

可以理解为RecyclerView的一级缓存，默认大小为2，也就是缓存2个ViewHolder。

有两点需要注意：

mCachedViews只能复用同一位置的ViewHolder，什么概念呢？比如屏幕上有3个ViewHolder，此时向下滑动，出现了第4个ViewHolder，而第1个ViewHolder被移出了屏幕。然后再向上滑动，第1个ViewHolder重新回到屏幕内，第1个ViewHolder会被mCachedViews中取出并复用。而如果你在第1个ViewHolder被移除屏幕后，继续向下滑动，出现第5个ViewHolder，新出现的ViewHolder并不会从mCachedViews中复用，因为位置不同。
mCachedViews中复用的ViewHolder中的数据不会被清除，复用时不会重新跑onBindViewHolder方法（因为位置相同，可以理解为是同一个，所以也不需要刷新数据）。

来看下源码：

void recycleViewHolderInternal(ViewHolder holder) {
//方法有点长，前面的掠过，看核心部分
if (forceRecycle || holder.isRecyclable()) {if (mViewCacheMax > 0&& !holder.hasAnyOfTheFlags(ViewHolder.FLAG_INVALID| ViewHolder.FLAG_REMOVED| ViewHolder.FLAG_UPDATE| ViewHolder.FLAG_ADAPTER_POSITION_UNKNOWN)) {// Retire oldest cached viewint cachedViewSize = mCachedViews.size();if (cachedViewSize >= mViewCacheMax && cachedViewSize > 0) {recycleCachedViewAt(0);cachedViewSize--;}int targetCacheIndex = cachedViewSize;if (ALLOW_THREAD_GAP_WORK&& cachedViewSize > 0&& !mPrefetchRegistry.lastPrefetchIncludedPosition(holder.mPosition)) {// when adding the view, skip past most recently prefetched viewsint cacheIndex = cachedViewSize - 1;while (cacheIndex >= 0) {int cachedPos = mCachedViews.get(cacheIndex).mPosition;if (!mPrefetchRegistry.lastPrefetchIncludedPosition(cachedPos)) {break;}cacheIndex--;}targetCacheIndex = cacheIndex + 1;}mCachedViews.add(targetCacheIndex, holder);cached = true;}if (!cached) {addViewHolderToRecycledViewPool(holder, true);recycled = true;}
}

注意第二行的判断条件，前面一段分析了holder在什么tag情况下会被加入到mAttachedScrap、mChangedScrap。很明显，这里明确定义了holder的tag不符合加入mAttachedScrap、mChangedScrap的条件的情况下，才会被加入到mCachedViews

mRecyclerPool

RecyclerView的二级缓存，根据不同的 item type 创建不同的 List，每个 List 默认大小为5个（也就是复用5个ViewHolder）。不同于mCachedViews，mRecyclerPool没有位置要求，只有type要求。但是复用的ViewHolder中的数据会被清除，因此复用时，会重跑onBindViewHolder方法。

注意刚才贴出的源码中，有这么一段：

if (!cached) {addViewHolderToRecycledViewPool(holder, true);recycled = true;}

可以理解为，如果不满足加入mAttachedScrap、mChangedScrap的条件，而又没有加入到mCachedViews的情况下，holder启动加入到mRecyclerPool的流程。

再来看一下addViewHolderToRecycledViewPool的内容

void addViewHolderToRecycledViewPool(@NonNull ViewHolder holder, boolean dispatchRecycled) {clearNestedRecyclerViewIfNotNested(holder);if (holder.hasAnyOfTheFlags(ViewHolder.FLAG_SET_A11Y_ITEM_DELEGATE)) {holder.setFlags(0, ViewHolder.FLAG_SET_A11Y_ITEM_DELEGATE);ViewCompat.setAccessibilityDelegate(holder.itemView, null);}if (dispatchRecycled) {dispatchViewRecycled(holder);}holder.mOwnerRecyclerView = null;getRecycledViewPool().putRecycledView(holder);}public void putRecycledView(ViewHolder scrap) {final int viewType = scrap.getItemViewType();final ArrayList<ViewHolder> scrapHeap = getScrapDataForType(viewType).mScrapHeap;if (mScrap.get(viewType).mMaxScrap <= scrapHeap.size()) {return;}if (DEBUG && scrapHeap.contains(scrap)) {throw new IllegalArgumentException("this scrap item already exists");}scrap.resetInternal();scrapHeap.add(scrap);}

注意getScrapDataForType这个方法，证明了之前的说法，mRecyclerPool是基于type运作的

mViewCacheExtension

自定义缓存,通常用不到

来看复用

RecyclerView复用的核心方法是

ViewHolder tryGetViewHolderForPositionByDeadline(int position,boolean dryRun, long deadlineNs)

这个方法比较长，我们只贴部分代码出来。

首先，是关于mChangedScrap的：

ViewHolder tryGetViewHolderForPositionByDeadline(int position,boolean dryRun, long deadlineNs) {
...
if (mState.isPreLayout()) {holder = getChangedScrapViewForPosition(position);fromScrapOrHiddenOrCache = holder != null;}
...
}

其次是mAttachedScrap和mCachedViews

if (holder == null) {holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun);...}if (mAdapter.hasStableIds()) {holder = getScrapOrCachedViewForId(mAdapter.getItemId(offsetPosition),type, dryRun);

这两个方法从源码分析，都是先从其次是mAttachedScrap，然后再从mCachedViews里复用holder。从方法名可以看出，一个是基于位置复用，另一个是基于id复用

再者是mRecyclerPool

 if (holder == null) { // fallback to poolif (DEBUG) {Log.d(TAG, "tryGetViewHolderForPositionByDeadline("+ position + ") fetching from shared pool");}holder = getRecycledViewPool().getRecycledView(type);if (holder != null) {holder.resetInternal();if (FORCE_INVALIDATE_DISPLAY_LIST) {invalidateDisplayListInt(holder);}}}

最后，如果完全没有holder可以复用，会调用mAdapter.createViewHolder来创建holder

if (holder == null) {long start = getNanoTime();if (deadlineNs != FOREVER_NS&& !mRecyclerPool.willCreateInTime(type, start, deadlineNs)) {// abort - we have a deadline we can't meetreturn null;}holder = mAdapter.createViewHolder(RecyclerView.this, type);

iOS：UITableView

iOS的UITableView相对而言逻辑就简单了很多，创建屏幕可显示最大个数+1的cell，当一个cell被移动出屏幕，自动进入到缓存池。

用网上的一张图片来描述：

机制相当简单，就不描述了

和RecyclerView相比，UITableView有两个最大的不同：

RecyclerView的复用机制是自动的，而UITableView是需要手动启动的：

看代码：

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{// 0.重用标识// 被static修饰的局部变量：只会初始化一次，在整个程序运行过程中，只有一份内存static NSString *ID = @"cell";// 1.先根据cell的标识去缓存池中查找可循环利用的cellUITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:ID];// 2.如果cell为nil（缓存池找不到对应的cell）if (cell == nil) {cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:ID];}// 3.覆盖数据cell.textLabel.text = [NSString stringWithFormat:@"testdata - %zd", indexPath.row];return cell;
}

注意dequeueReusableCellWithIdentifier:ID这个方法，从字面意思就能理解是从缓存池中获取一个cell来复用。如果你在创建cell时不是调用这个方法，而是直接新建一个cell，那么UITableView的缓存机制就没有用了。

数据清零

UITableView无视位置，cell只要回收就会清除数据，这一点其实从代码里就能一目了然，每个cell，都需要当成新建的cell来重新赋值。