優(yōu)化緣由
此次優(yōu)化的契機是App內(nèi)瀑布流頁面大數(shù)據(jù)量時進入/滑動異?？D，F(xiàn)PS 在7P上30-40，6P上10，5C上僅僅只有5。
前期準備
集成GDPerformanceView以方便查看FPS
優(yōu)化過程
1.排除干擾項
排除以下可能影響加載速度的干擾項：
1）去除加載/緩存/繪制圖片過程；
2）所有scrollView相關(guān)的delegate代碼去除；
3）跟滑動有關(guān)的KVO，主要是contensize相關(guān)去除；
4）檢查是否hook了類里的一些方法（如果有隊友這么做了，拿著刀找他去就行了）；
去除以上干擾的狀態(tài)，我稱之為“白板狀態(tài)”，先優(yōu)化好此狀態(tài)的幀率，再加回這些進行進一步優(yōu)化，不幸的是，白板狀態(tài)下，F(xiàn)PS并沒有顯著提升。
2.優(yōu)化開始
使用instrument的Time Profiler調(diào)試
1）collectionView的willDisplayCell方法耗時較多，檢查代碼發(fā)現(xiàn)是同事為了嘗試解決首次進入時cell寬高會執(zhí)行從0到其實際寬度動畫的bug，調(diào)用了layoutIfNeeded，去除后并未復(fù)現(xiàn)該bug。此時，7P表現(xiàn)良好FPS達到了55+，6P仍然處于20+，此時思路應(yīng)該是由于大量調(diào)用CPU，故6P的FPS仍然表現(xiàn)不佳；
.
2）經(jīng)檢查，瀑布流滑動時，CollectionViewLayout的prepareLayout調(diào)用了過多次數(shù)（對瀑布流原理不清楚的同學可以先看我這一篇UICollectionView的靈活布局 --從一個需求談起），而prepareLayout意味著重新計算布局，圖片量越大，計算越耗時（我們的瀑布流使用了循環(huán)嵌套循環(huán)）。根據(jù)collectionView的生命周期，當contentSize變化的時候才會調(diào)用prepareLayout，或者在Layout里重寫了方法：
- (BOOL)shouldInvalidateLayoutForBoundsChange:(CGRect)newBounds;
經(jīng)檢查發(fā)現(xiàn)隨著滑動，newBounds的y一直變化，導(dǎo)致持續(xù)重新布局。之所以重寫shouldInvalidateLayoutForBoundsChange方法，是因為我們使用的DZNEmptyDataSet在有contentOffset的情況下，刪除collectionView所有數(shù)據(jù)源之后的布局出現(xiàn)問題。因此我們要針對shouldInvalidate方法的調(diào)用進行優(yōu)化，添加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;
}
此時白板狀態(tài)7P的FPS已達60。6p正?；瑒右呀?jīng)50+，快速滑動時仍會降至20-30；
.
3）下一步的優(yōu)化思路就是處理快速滑動，參照VVeboTableViewDemo中的方法進行優(yōu)化。
需要注意和這個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參數(shù)在別處改動了會很麻煩。
下面貼上代碼來說明這四點：
@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一樣根據(jù)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參數(shù)
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加載次數(shù)，但效果并不理想；
5）沉浸式體驗下， tabbar的多次出現(xiàn)隱藏對FPS并無顯著影響；
6）對scrollView 的contentSize 的 KVO，設(shè)置了底部圖片frame，對FPS影響不大，仍然優(yōu)化為到頂部/底部 才改變frame；
7）scollView的didScroll代理調(diào)用了NSDateFormatter，調(diào)用次數(shù)密集， 根據(jù)以往經(jīng)驗，NSDateFormatter在autorelease下往往不能及時釋放，故加如autoreleasepool 以保證及時釋放；
進入速度優(yōu)化
進入瀑布流之時，所有的cell都會加載一遍，導(dǎo)致卡頓。起初我以為是collectionViewLayout的某個方法調(diào)用錯了。后來經(jīng)過debug發(fā)現(xiàn)，collectionView的數(shù)據(jù)源傳入的是mutableArr的count，數(shù)據(jù)在變化，只要deepCopy出來一份，就解決了這個問題。
總結(jié)
多人協(xié)作開發(fā)時，往往就會因為各種原因?qū)е律厦娴膯栴}出現(xiàn)，若深入理解相關(guān)知識的生命周期和一些基礎(chǔ)知識，可以減少上面至少一半的問題。
.
另外優(yōu)化也是個持續(xù)的過程，平時測試也很少可以發(fā)現(xiàn)，當積累到一定量級之后才會顯現(xiàn)，也許下次某位同事修復(fù)某個bug，又會帶出性能問題，整個優(yōu)化過程，其實是十分有趣的，而且優(yōu)化成功后，成就感十足，讓我們痛并快樂著吧。
簡書已經(jīng)棄用，歡迎移步我的小專欄：
https://xiaozhuanlan.com/dahuihuiiOS
