iOS 10 中的prefetchingEnabled属性,挺有意思的

iOS10中UICollectionView和UITableView的变化

在iOS 10中，UIKit的两个容器控件得到新的特性，apple在会上强调了这些新特性所带来的性能提升，现总结如下：

1.cell生命周期的变化

只有UICollectionView支持这项更新，且貌似开启prefetchingEnabled才行，具体表现为，与当前区域较为临近的离屏cell将不会立即进入reuse队列，而是仍然驻留在那个位置，等待用户往上滑动去再现它，这样一来，cellForItemAtIndexPath将不会被反复调用——这些没有被立即recovery的cell们再重见天日之后只会往delegate发送willDisplayCell进行一下通知而已。那么联系到大多数情况我们都在cellForItemAtIndexPath函数内部做model的填充，那么当用户的确在某个cell区间之内反复滑动，可以明显缓解由于反复的图片加载、文字绘制等操作带来的瞬时cpu压力。但是对于某些情况下，例如cell每次被显示出来都可能处于不一样的状态，那么就需要将这些状态改变移步到willDisplayCell了。

对于iOS 10之前的UIKit，其实我们也可以定制一种机制来避免，当被reuse的cell被重新使用并且它上面的内容与当前需要填充的内容一致，被重新填充一遍的浪费。（比如self.model == model）

2.prefetchDataSource

这个新的协议属性是UICollectionView和UITableView都支持的。这个协议其实是用来通知我们，当前滑动到某个区域后，根据这次滑动的方向接下去可能还会滑向哪些indexPaths。好让我们做一些数据上的预备或者销毁。

分为2个函数：

required: prefetchRowsAtIndexPaths

这个协议方法提供一个数组，这个数组提示了按着本次滑动方向，再接下去要碰到哪些indexPaths了，以UITableView为例，回调过来的这个数组为当前屏幕边缘的indexPath的接下去（上或者下）第10个开始算的indexPath，大概一次5个这样。

optional: cancelPrefetchingForRowsAtIndexPaths

这个协议返回的数组用于在，当我们快速滑动到某个区域后又立刻按着反方向滑动，那么原本被预估要出现的几个indexPath会被取消掉这样，这个数组就是存储被取消预估的indexPath。

3.prefetchingEnabled

仍然是UICollectionView独占，提供了cell的预读取功能。具体表现在，当我们滑动至某个区域的时候，例如section:1  item:5到section:1 item:10这个区间，那么UICollectionView就会去读取cellForItemAtIndexPath来预先加载大概section:1 item:3到section:1 item:12这样的区间，这个预读操作apple是说为异步的，但是本着UIView必须在主线程下操作的规矩，应该指的是 当前的滚动结束之后layoutSubviews被调用完了在下一次runloop中去访问cellForItemAtIndexPath 这样，利用用户屏幕静止的时间去读取。

预读取了cell并存储在reuse队列中之后，当这些cell真的需要被显示了，那么就可以willDisplayCell通知一下直接刷出来，这样一来，用户感觉不到诸如图片的下载这样的读取过程。

当开启这个功能时，prefetchDataSource会受到影响，预估算indexPath的策略会和关闭这个功能的时候不一样。也就是关闭的时候prefetchDataSource同UITableView一样的机制。

同样由于某些需求，这个功能可以随时被关闭。

原文地址:www.qingpingshan.com/rjbc/ios/145008.html