更多精彩内容，欢迎关注作者微信公众号：码工笔记
最近遇到一个需要对UICollectionView自定义layout的情况，之前对这块不太熟悉，研究了一下，在此记录一下结论。
一、背景
考虑以下场景：
- 每个cell自己根据内部状态决定布局高度
- 每个cell的算高比较耗时，DataSource中数据较多时，为保证用户体验，希望能按需算高（即只算屏幕内显示的，而不是从第一条数据开始算）
- 有设置DataSource以后从中间某个cell开始显示的需求
二、问题
经过一番调研，发现UITableView、UICollectionViewFlowLayout等的预估高度都是只预估尾部未展示cell的高度，而顶部不论是否显示都必须计算真实高度。
也就是说，如果DataSource中有100条数据，而我们希望从第50条开始显示的话，前 0~49个cell即便并不展示，也需要计算真实高度。
在每个cell算高开销较大的情况下，这无疑极大地拖慢了显示和滚动时间。
也就是说现有预估高度机制不能满足顶部插入数据的情况，无法细粒度控制算高范围。
三、方案
UICollectionView支持自定义Layout，只需要继承 UICollectionViewLayout并实现相关方法即可。UIKit提供了很多回调时机和更新机制，我们能不能定制一下布局流程，实现一个按需算高的自定义layout呢？
3.1 UICollectionViewLayout 子类重载点
下面先来看一下一个自定义 UICollectionViewLayout 都有哪些关键方法可以实现：
@interface UICollectionViewLayout (UISubclassingHooks)
- (void)prepareLayout;
- (nullable NSArray<__kindof UICollectionViewLayoutAttributes *> *)layoutAttributesForElementsInRect:(CGRect)rect;
- (BOOL)shouldInvalidateLayoutForBoundsChange:(CGRect)newBounds;
- (UICollectionViewLayoutInvalidationContext *)invalidationContextForBoundsChange:(CGRect)newBounds;
- (void)invalidateLayoutWithContext:(UICollectionViewLayoutInvalidationContext *)context;
@property(nonatomic, readonly) CGSize collectionViewContentSize;
@end
网上参考了很多自定义布局的例子，自己也做了一些试验，看起来的“最佳实践”是：
-
prepareLayout是布局更新的第一个回调，最好在这个方法里计算出下次布局更新前所有可能会用到的布局信息 -
collectionViewContentSize用于返回总体内容大小，一般prepareLayout之后就会调用了，其内容应由prepareLayout中所有的元素高度决定 -
layoutAttributesForElementsInRect在滚动过程中会不断被调用，它的实现应该是只查询prepareLayout中缓存下来的落在参数rect中的cell的布局属性（而不是根据rect做实时计算） -
shouldInvalidateLayoutForBoundsChange会在bounds属性发生更新的时候被调用（如顶部下拉），可以根据实际需求场景，决定此次bounds更新是否要触发重新布局。如果返回YES，则后面UIKit会依次调用invalidationContextForBoundsChange生成一个invalidationContext实例（重载此方法可定制生成的实例）, 然后调用invalidateLayoutWithContext（参数为刚才生成的invalidationContext实例），然后在下一次布局时（runloop结束前）触发prepareLayout。
bounds更新有两种情况：origin更新和size更新：
- size更新就是宽高发生了变化，这时一般都需要重新布局；
- bounds.origin一般情况下是(0, 0)，但在其滚动超出边界的时候，这个bounds会连续多次被设置（这部分不太熟悉的可以查一下frame和bounds的区别）。
-
invalidationContextForBoundsChange这个回调中可以返回自定义的invalidationContext的实例，并设置相关属性，以供后面invalidateLayoutWithContext使用 -
ininvalidateLayoutWithContext的参数可能是系统构造的context实例，也可能是上面自己构造的自定义context实例，在此方法中要根据不同实例和属性做布局缓存清除操作
3.2 按需算高具体机制
先考虑下拉的情况，我们举一个具体的例子。
假设DataSource中一共有100条数据，默认从第50条数据开始显示，到第55条为止。也即首屏应该只计算[50, 55]的高度。
由上一节描述的各重载点的回调时机可知，应该在 prepareLayout 方法中计算第50~55条数据的高度，为了记录当前需要显示的 indexPath 起点和终点，我们需要给 layout 对象增加两个属性：
@interface CustomLayout : UICollectionViewLayout
@property (nonatomic, strong) NSIndexPath *firstVisibleIndexPath;
@property (nonatomic, strong) NSIndexPath *lastVisibleIndexPath;
...
@property (nonatomic, weak) id<CustomLayoutDelegate> delegate;
@end
那么在 preapreLayout 方法中，就可以对这两个indexPath之间的所有数据进行算高：
- (void)preapareLayout {
...
//有缓存则使用缓存，直接返回
if (_cachedAttributes.count) {
return;
}
...
//创建布局属性缓存，供后面查询
_cachedAttributes = [NSMutableArray array];
//累计高度，用于设置各cell布局属性中的y和总体的collectionViewContentSize
double cumulatedHeight = 0;
//遍历 firstVisibleIndexPath 和 lastVisibleIndexPath 之间所有indexPath
for (NSIndexPath *indexPath in ...) {
//计算高度，需由delegate实现
CGSize itemSize = [self.delegate itemSizeAtIndexPath:indexPath];
cumulatedHeight += itemSize.height;
UICollectionViewLayoutAttributes *attr = [UICollectionViewLayoutAttributes layoutAttributesForCellWithIndexPath:indexPath];
attr.frame = CGRectMake(0, cumulatedHeight, itemSize.width, itemSize.height);
//缓存结果
[_cachedAttributes addObject:attr];
}
//记录总高度
_totalHeight = cumulatedHeight;
}
在 collectionContentViewSize 中直接返回刚才记录的 _totalHeight 属性即可：
- (CGSize)collectionContentViewSize
{
return CGSizeMake(CGRectGetWidth(self.collectionView.bounds), _totalHeight);
}
下一步，系统就会回调 layoutAttributesForElementsInRect 了。这是个非常重要的方法，它直接决定了各个cell在屏幕上的位置。此方法回调时传入的 rect 参数是UIKit决定的，其考虑了预取、滚动方向等多种因素，目测其宽高是一个跟屏幕大小相关的值（倍数），触顶下拉时rect.orign.y会是一个负值。
这个方法里应该可以做一些tricky的事，但考虑到其调用频次、参数、时机的复杂性，参考上一节的“最佳实践”，在这里不做什么复杂的事，只查询prepareLayout生成的缓存数据：
- (NSArray<__kindof UICollectionViewLayoutAttributes *> *)layoutAttributesForElementsInRect:(CGRect)rect
{
NSMutableArray *result = [NSMutableArray array];
for ( attr in _cachedAttributes) {
//有交集则添加到结果中
if (CGRectIntersects(attr.frame, rect)) {
[result addObject:attr];
}
}
return result;
}
如果其他相关部分已经都连好了，这样一运行，就能在屏幕上看到布局好的第 50~55 条数据了。
但是如何处理下拉时动态展示第 49 条呢？注意，这里的动态展示包含了几点基本需求：
- 界面不能跳，第49条数据所在的cell要逐渐拉出来
- 滚动惯性要保持，如果用户做了个惯性下滚，前面的49、48、47等要依次出来，不能中间卡住
这里就要用到 shouldInvalidateLayoutForBoundsChange 了。
当collectionView已经触顶，用户继续下拉时，系统就会回调 shouldInvalidateLayoutForBoundsChange，并传入一个 origin.y < 0 的 newBounds，这里我们只需要判断这种拉到边界的情况，并返回YES通知系统更新布局即可：
- (BOOL)shouldInvalidateLayoutForBoundsChange:(CGRect)newBounds
{
if (newBounds.origin.y < 0) {
return YES;
}
return [super shouldInvalidateLayoutForBoundsChange:newBounds];
}
如前所述，此方法返回 YES 后，UIKit紧接着就会回调 invalidationContextForBoundsChange 用于生成一个定制化的invalidationContext。
这里，我们需要根据newBounds中给出的偏移算出布局更新后新的firstVisibleIndexPath，也就是说要往前加载几个indexPath才能填满newBounds.origin.y，在我们的例子中，这个targetIndexPath将是 49。
注意，这里有两个关键点，一个是要找到新的起始indexPath 49并存到invalidationContext中，另一个是要设置invalidationContext的contentOffsetAdjustment属性以保证新布局下的展示位置与现在完全一致，这样才能看起来是比较顺畅的滚动。
具体一点说，假设当前boundsChange的时候 newBounds.origin.y = -20（也就是用户下拉了20个point），而 cell 49 的高度为 200。那么布局更新后（也就是下次 prepareLayout 调用完成后），contentOffset必须是是180，才能保证布局更新前后cell 50的位置是不变的。
- (UICollectionViewLayoutInvalidationContext *)invalidationContextForBoundsChange:(CGRect)newBounds
{
if (newBounds.origin.y < 0) {
CustomInvalidationContext *invalidationContext = [[CustomINvalidationContext alloc] init];
//下拉出来的空白区域高度
double gap = -newBounds.origin.y;
//往前遍历一直找到targetIndexPath，使得targetIndexPath与firstVisibleIndexPath之间的高度 >= gap
NSIndexPath *indexPath = self.firstVisibleIndexPath;
double cumulatedLength = 0;
while (cumulatedLength < gap) {
//找indexPath的上一个indexPath，需要由delegate实现
NSIndexPath *nextIndexPath = [self.delegate previousIndexPathForIndexPath:indexPath];
if (nextIndexPath) {
//计算高度，需由delegate实现
CGSize itemSize = [self.delegate itemSizeAtIndexPath:nextIndexPath];
cumulatedLength += itemSize.height;
indexPath = nextIndexPath;
} else {
//前面已无其他indexPath，跳出
break;
}
}
//记录目标indexPath
invalidationContext.targetStartIndexPath = indexPath;
//需要在这里设置contentOffsetAdjustment，以在新一轮布局更新（prepareLayout）前设置新布局下的contentOffset，保证视觉上不会看到跳跃
invalidationContext.contentOffsetAdjustment = CGPointMake(0, cumulatedHeight);
}
return [super ...];
}
紧接着，UIKit会回调 invalidateLayoutWithContext 方法，这里传入的context就是刚才生成的CustomInvalidationContext实例。需要在这里更新self.firstVisibleIndexPath，并清除 _cachedAttributes：
- (void)invalidateLayoutWithContext:(UICollectionViewLayoutInvalidationContext *)context
{
[super invalidateLayoutWithContext:context];
if (context.invalidateEverything || context.invalidateDataSourceCounts) {
[_cache removeAllObjects];
return;
}
if ([context isKindOfClass:[CustomInvalidationContext class]]) {
if (context.targetFirstIndexPath) {
self.firstVisibleIndexPath = context.targetFirstIndexPath;
}
[_cachedAttributes removeAllObjects];
}
}
这样就完成了，运行起来就能正常下拉了。下拉多少firstVisibleIndexPath就向前移动多少，每次只计算必须的部分。
当然，取决于具体情况和测试结果，也可以动态调整预计预计算的范围（即并不是只填满gap就算，而是找一个与屏幕大小相关的高度），不过，单次计算的越多，越可能超过16ms导致掉帧，一共要显示的cell就那么多，计算总量是确定的，需要tradeoff的是重新布局的次数和单次的计算量。
上面讨论了下拉的情况，上拉流程基本类似，读者可自行补充。另外，lastVisibleIndexPath 也不是必须的，实践中应该由firstVisibleIndexPath加上屏幕高度或collectionView高度得到一个合适的lastVisibleIndexPath，在此不再细化。
最后，总结一下 CustomLayout delegate 的接口，还比较简洁，按需相关的只需要新增两个往前和往后遍历indexPath的方法即可：
@protocol CustomLayoutDelegate <NSObject>
- (CGSize)itemSizeAtIndexPath:(NSIndexPath *)indexPath;
- (NSIndexPath *)nextIndexPathForIndexPath:(NSIndexPath *)indexPath;
- (NSIndexPath *)previousIndexPathForIndexPath:(NSIndexPath *)indexPath;
@end
