首页 >iOS开发

iOS优化(二)滑动优化的一些经验

2017-03-17 11:22 编辑: suiling 分类:iOS开发 来源:大灰灰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) {
                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;
      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,又会带出性能问题,整个优化过程,其实是十分有趣的,而且优化成功后,成就感十足,让我们痛并快乐着吧。

搜索CocoaChina微信公众号:CocoaChina
微信扫一扫
订阅每日移动开发及APP推广热点资讯
公众号:
CocoaChina
我要投稿   收藏文章
上一篇:【收藏党】我的2017 iOS开发工具集
下一篇:养一只”无限猴子”帮你测试
我来说两句
发表评论
您还没有登录!请登录注册
所有评论(0

综合评论

相关帖子

sina weixin mail 回到顶部