原文
优化缘由
此次优化的契机是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; iloadSum) {
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,又会带出性能问题,整个优化过程,其实是十分有趣的,而且优化成功后,成就感十足,让我们痛并快乐着吧。