iOS优化（二）滑动优化的一些经验

优化缘由

此次优化的契机是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