iOS的一些滑动优化

优化过程

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调用了过多次数（而prepareLayout意味着重新计算布局，图片量越大，计算越耗时（我们的瀑布流使用了循环嵌套循环）。根据collectionView的生命周期，当contentSize变化的时候才会调用prepareLayout，或者在Layout里重写了方法：

1

- (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)) {

returnNO;

}

self.newBoundsSize = newBounds.size;

returnYES;

}

此时白板状态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 = [NSMutableArraynew];

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) {

for(NSUInteger i = 1; i 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;

returncell;

}

此时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，又会带出性能问题，整个优化过程，其实是十分有趣的，而且优化成功后，成就感十足，让我们痛并快乐着吧。

原文来自cocoachina：http://www.cocoachina.com/ios/20170317/18911.html