优化缘由
此次优化的契机是App内瀑布流页面大数据量时进入/滑动异常卡顿，FPS 在7P上30-40，6P上10，5C上仅仅只有5。
前期准备
集成GDPerformanceView以方便查看FPS
优化过程
1.排除干扰项
排除以下可能影响加载速度的干扰项：
1）去除加载/缓存/绘制图片过程；
2）所有scrollView相关的delegate代码去除；
3）跟滑动有关的KVO，主要是contensize相关去除；
4）检查是否hook了类里的一些方法（如果有队友这么做了，拿着刀找他去就行了）；
去除以上干扰的状态，我称之为“白板状态”，先优化好此状态的帧率，再加回这些进行进一步优化，不幸的是，白板状态下，FPS并没有显著提升。
2.优化开始
使用instrument的Time Profiler调试
1）collectionView的willDisplayCell方法耗时较多，检查代码发现是同事为了尝试解决首次进入时cell宽高会执行从0到其实际宽度动画的bug，调用了layoutIfNeeded，去除后并未复现该bug。此时，7P表现良好FPS达到了55+，6P仍然处于20+，此时思路应该是由于大量调用CPU，故6P的FPS仍然表现不佳；
.
2）经检查，瀑布流滑动时，CollectionViewLayout的prepareLayout调用了过多次数（对瀑布流原理不清楚的同学可以先看我这一篇UICollectionView的灵活布局 --从一个需求谈起），而prepareLayout意味着重新计算布局，图片量越大，计算越耗时（我们的瀑布流使用了循环嵌套循环）。根据collectionView的生命周期，当contentSize变化的时候才会调用prepareLayout，或者在Layout里重写了方法：
- (BOOL)shouldInvalidateLayoutForBoundsChange:(CGRect)newBounds;
经检查发现随着滑动，newBounds的y一直变化，导致持续重新布局。之所以重写shouldInvalidateLayoutForBoundsChange方法，是因为我们使用的DZNEmptyDataSet在有contentOffset的情况下，删除collectionView所有数据源之后的布局出现问题。因此我们要针对shouldInvalidate方法的调用进行优化，添加magic number，判断仅当size变化时，再重新绘制瀑布流：
@property (assign, nonatomic) CGSize newBoundsSize;
- (BOOL)shouldInvalidateLayoutForBoundsChange:(CGRect)newBounds {
if (CGSizeEqualToSize(self.newBoundsSize, newBounds.size)) {
return NO;
}
self.newBoundsSize = newBounds.size;
return YES;
}
此时白板状态7P的FPS已达60。6p正常滑动已经50+，快速滑动时仍会降至20-30；
.
3）下一步的优化思路就是处理快速滑动，参照VVeboTableViewDemo中的方法进行优化。
需要注意和这个demo不同的是：
（1）collectionView无法通过CGRect取到即将显示的所有indexPath；
（2）collectionView通过point取indexPath的时候point不能是右下角边缘值，不然会返回item为0的indexPath；
（3）因为demo里是写了个tableView的子类，而我直接在controller里处理了，所以hitTest 这里我取了一个折中的处理,但是效果并不是100%完美，在decelerating的过程中用手指停住，手指只要不松开就不会加载当前的cell；
（4）targetContentOffset:(inout CGPoint *)targetContentOffset 最好不要直接赋值，inout参数在别处改动了会很麻烦。
下面贴上代码来说明这四点：
@property (nonatomic, strong) NSMutableArray *needLoadArr;
//为了处理（3）中的hitTest
@property (nonatomic, assign) CGPoint targetOffset;
- (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset {
//conference : https://github.com/johnil/VVeboTableViewDemo/blob/master/VVeboTableViewDemo/VVeboTableView.m
//FPS optimition part 3-1 : loadCell if needed
NSIndexPath *indexPath = [self.collectionView indexPathForItemAtPoint:*targetContentOffset];
NSIndexPath *firstVisibleIndexPath = [[self.collectionView indexPathsForVisibleItems] firstObject];
//判断快速滑动超过20个item后不加载中间的cell
NSInteger skipCount = 20;
if (labs(firstVisibleIndexPath.item - indexPath.item) > skipCount) {
//处理（1）中无法跟tableView一样根据CGRect取到indexPath
NSIndexPath *firstIndexPath = [self.collectionView indexPathForItemAtPoint:CGPointMake(0, targetContentOffset->y)];
NSIndexPath *lastIndexPath = [self.collectionView indexPathForItemAtPoint:CGPointMake(self.collectionView.frame.size.width - 10.f,
targetContentOffset->y + self.collectionView.frame.size.height - 10.f)];
// - 10.f 是为了处理（2）中的point准确性
NSMutableArray *arr = [NSMutableArray new];
for (NSUInteger i = firstIndexPath.item; i <= lastIndexPath.item; i++) {
[arr addObject:[NSIndexPath indexPathForItem:i inSection:0]];
}
NSUInteger loadSum = 6;
if (velocity.y < 0) {
//scroll up
if ((lastIndexPath.item + loadSum) < self.viewModel.numberOfItems) {
for (NSUInteger i = 1; i <= loadSum; i++ ) {
[arr addObject:[NSIndexPath indexPathForItem:lastIndexPath.item + i inSection:0]];
}
}
} else {
//scroll down
if (firstIndexPath.item > loadSum) {
for (NSUInteger i = 1; i <= loadSum; i++ ) {
[arr addObject:[NSIndexPath indexPathForItem:firstIndexPath.item - i inSection:0]];
}
}
}
[self.needLoadArr addObjectsFromArray:arr];
//（4）中处理inout参数
self.targetOffset = CGPointMake(targetContentOffset->x, targetContentOffset->y);
}
}
- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView
{
//FPS optimition part 3-2 : loadCell if needed (when you touch and end decelerating)
//if use collectionView as subView override - (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event instead
if (!CGPointEqualToPoint(self.targetOffset, CGPointZero) &&
fabs(self.targetOffset.y - scrollView.contentOffset.y) > 10.f &&
scrollView.contentOffset.y > scrollView.frame.size.height &&
scrollView.contentOffset.y < (scrollView.contentSize.height - scrollView.frame.size.height)) {
[self.needLoadArr removeAllObjects];
self.targetOffset = CGPointZero;
[self.collectionView reloadData];
} else {
[self.needLoadArr removeAllObjects];
}
}
最后在cell绘制的时候判断，比VVebo多的是还判断了一步是否在当前缓存中。为了让瀑布流滑动体验更好，在进入瀑布流的页面，我将缓存上限提高到70M，按我们一张图片在200k-900k的大小来看，可以满足大部分情况下的需求。
//FPS optimition part 3-3 : loadCell if needed
if (self.needLoadArr.count > 0 &&
[self.needLoadArr indexOfObject:indexPath] == NSNotFound &&
//判断是否在缓存中
![rawPhoto imageExistInMemoryWithType:type]) {
[cell.imageView loadingState];
cell.imageView.image = nil;
return cell;
}
此时6p帧率升至55+；
4）这里我也尝试将collectionView的滑动速率降至0.5，以减少cell加载次数，但效果并不理想；
5）沉浸式体验下， tabbar的多次出现隐藏对FPS并无显著影响；
6）对scrollView 的contentSize 的 KVO，设置了底部图片frame，对FPS影响不大，仍然优化为到顶部/底部 才改变frame；
7）scollView的didScroll代理调用了NSDateFormatter，调用次数密集， 根据以往经验，NSDateFormatter在autorelease下往往不能及时释放，故加如autoreleasepool 以保证及时释放；
进入速度优化
进入瀑布流之时，所有的cell都会加载一遍，导致卡顿。起初我以为是collectionViewLayout的某个方法调用错了。后来经过debug发现，collectionView的数据源传入的是mutableArr的count，数据在变化，只要deepCopy出来一份，就解决了这个问题。
总结
多人协作开发时，往往就会因为各种原因导致上面的问题出现，若深入理解相关知识的生命周期和一些基础知识，可以减少上面至少一半的问题。
.
另外优化也是个持续的过程，平时测试也很少可以发现，当积累到一定量级之后才会显现，也许下次某位同事修复某个bug，又会带出性能问题，整个优化过程，其实是十分有趣的，而且优化成功后，成就感十足，让我们痛并快乐着吧。
简书已经弃用，欢迎移步我的小专栏：
https://xiaozhuanlan.com/dahuihuiiOS
