原文? http://blog.vars.me/blog/2015/04/26/UICollectionView-Optimizing/
主題 iOS開發(fā) C語言
當App中使用了 UICollectionView 以瀑布流的形式來呈現(xiàn)數(shù)據(jù)時，站在用戶的角度，用戶在自上至下一頁一頁瀏覽這些內(nèi)容的過程中，當用戶感到滑動很流暢自然，每頁內(nèi)容從無到有需要用戶等待的時間很短甚至幾乎感覺不到，那么 UICollectionView 才會帶給用戶一個很好的體驗。本文介紹了為了達到這兩個目的所作出的一些客戶端的優(yōu)化。
數(shù)據(jù)的預(yù)加載
數(shù)據(jù)預(yù)加載的目的是不必等到用戶某一時刻瀏覽到CollectionView的末尾了，也即本地已經(jīng)沒有更多數(shù)據(jù)展示了才去發(fā)請求拿下一頁數(shù)據(jù)，而是有一個預(yù)判，用戶就快要看完本地的數(shù)據(jù)了，可以向Server要下一頁數(shù)據(jù)了！
為了實現(xiàn)預(yù)加載，最開始的方案是在UI層面的預(yù)判。根據(jù) UICollectionView 的基類是 UIScrollView ，大致思路是對于沿豎直方向滾動的CollectionView，考察它的 contentOffset.y 和 conetntSize.height ，結(jié)合CollectionView的 frame.size.height ，可以計算CollectionView全部內(nèi)容底下還有多高沒展示出來，如果高度小于我們預(yù)先設(shè)定的閾值（用戶快滑到底了），那么就觸發(fā)加載下一頁的請求。
這樣做似乎沒什么問題，但是仔細想想，其實并不優(yōu)雅。一方面，一旦有UI調(diào)整的需求，CollectionView每行的高度有調(diào)整時，我們也要去調(diào)整閾值，來決定是否去請求下一頁數(shù)據(jù)；另一方面，App中不同場景下的CollectionView每行高度不同，需要根據(jù)不同場景去Tuning，找出合適的閾值。
后來很自然想到在邏輯上進行預(yù)判，也就是我們現(xiàn)在使用的方案。
UICollectionView 每個Cell都需要一個數(shù)據(jù)模型對象（Data Transfer Object，下稱DTO）來支持它的顯示，通常客戶端拿到的服務(wù)端返回的數(shù)據(jù)后，做一系列的解析，得到一個一個DTO，用以支持CollectionView的展示。到代碼層面DTO們被保存在一個數(shù)組里，任意時刻在正確的狀態(tài)下 UICollectionView 的總Cell數(shù)量應(yīng)該跟當前本地DTO的個數(shù)相等，Cell跟DTO是一一對應(yīng)的關(guān)系， 數(shù)據(jù)的預(yù)加載本質(zhì)上就是DTO的預(yù)加載 。
用戶在滾動 UICollectionView 時，當 UICollectionView 根據(jù)預(yù)定的配置覺得它該展示某行某列的Cell時，會向它的DataSource[2]發(fā)送 collectionView:cellForItemAtIndexPath: 消息[3]，詢問那行那列該展示什么，這個方法返回一個Cell對象， UICollectionView 拿到這個Cell后就把它展示在相應(yīng)位置。通常這個方法中要做的重要事情就是去上文提到的保存DTO的數(shù)組中根據(jù)Cell的行列索引找到這個Cell對應(yīng)的DTO，根據(jù)DTO對Cell配置一番，返回給 UICollectionView 。
順著這個思路，在這個方法中可以知道當前 UICollectionView 需要展示的Cell的索引，由于Cell跟DTO是一一對應(yīng)的關(guān)系，那我們也知道了當前需要的DTO在總數(shù)據(jù)模型對象中的索引，當剩下的數(shù)據(jù)模型對象不夠支持一頁的顯示時，就去請求下一頁。
表達的可能有點抽象，假設(shè)請求一次Server返回20個DTO，過程可以更形象化一點：
- CollectionView: 數(shù)據(jù)源數(shù)據(jù)源，用戶滑到第181個Cell要露出來了，快給我！
- DataSource: 好的，我首先要去拿第181個Cell對應(yīng)的DTO，根據(jù)這個配置好一個Cell給你去展示！
等等，你都已經(jīng)展示到第181個Cell了??！我發(fā)現(xiàn)DTO目前本地總共只有200個，200 - 181 = 19 < 20不夠支持你展示下一頁所需要的20個Cell了，我先發(fā)起一個異步請求，去拿新一頁的DTO！
關(guān)鍵代碼，很簡單：
NSUInteger countOfDataModel = dataModel.count; // 目前本地有的DTO數(shù)量
NSUInteger currentRequestIndex = indexPath.row; // 當前需要的Cell索引，也即當前需要的數(shù)據(jù)模型索引
if (countOfDataModel - currentRequestIndex < 19) {
[self fetchNextPageAsync];
}
要注意的問題是要做好防止重復(fù)發(fā)送請求的保護工作。
圖片加載邏輯優(yōu)化
當 UICollectionView 的每個Cell都需要展示一個（或多個）圖片時，在上文提到的根據(jù)DTO配置Cell過程中，會根據(jù)DTO中指定的圖片的URL，發(fā)送一個異步的圖片請求，等到圖片請求完畢了，再把圖片展示到對應(yīng)的Cell上（當然，可以把這一切交給 SDWebImage : ）。
或許你會問，加載圖片已經(jīng)是異步了啊，我還要優(yōu)化什么？不，這遠遠不夠。在實際的測試中，這種樸素的做法依然會帶來明顯的滑動過程的卡頓。使用Instruments進行profile發(fā)現(xiàn)，在滑動過程中始終會丟那么15幀左右，不能忍！
再回到 UICollectionView 繼承自 UIScrollView 上來。通過 UIScrollView 的Delegate，我們能感知到滑動過程中CollectionView的各種關(guān)鍵狀態(tài)，包括用戶的手是否正在拖拽，以及CollectionView是否正在滑動、減速等等，這就是我們優(yōu)化的秘密武器！
那么，本著不該做的事情不要做，或者等到不得不做的時候再做的原則，讓我們分析用戶在滑動CollectionView的過程中有哪些地方可以細摳。
用戶在滑動（拖拽）CollectionView時（手與屏幕正在接觸），很有可能是用戶在認真逐個瀏覽每個Cell，要去加載當前可見Cell的圖片
用戶滑動CollectionView結(jié)束后，手離開了屏幕，并引發(fā)了CollectionView減速時， 預(yù)判 CollectionView減速結(jié)束后靜止時的狀態(tài)，對于那些將來靜止時用戶可見的Cell，提前去加載它們的圖片；對于那些只是“曇花一現(xiàn)”的Cell，即它們只是在減速的過程中出現(xiàn)那么一剎那，就被“頂”上去了，只加載這些Cell中圖片在本地有緩存的圖片（從內(nèi)存中加載，不值得去發(fā)網(wǎng)絡(luò)請求，即使是異步的也不值得）
減速結(jié)束后，CollectionView處于靜止狀態(tài)，加載當前全部可見Cell的圖片
OK，那么來看我們怎么實現(xiàn)它。
對于CollectionView的每個Cell，我們給它添加一個異步加載圖片的方法 loadImage 。直接上關(guān)鍵代碼，看了便知。
// CollectionView將來靜止時可見的區(qū)域，同時也是標識CollectionView當前是正在被用戶拖拽還是已經(jīng)被拖拽完畢并正在減速
@property (nonatomic, strong) CGRect *targetRect;
#pragma mark - UICollectionView DataSource
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath {
// ....
[self loadImageForCell:cell atIndexPath:indexPath];
// ....
}
#pragma mark - UIScrollView Delegate
- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView {
self.targetRect = nil;
[self loadImageForVisibleCells];
}
- (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset {
self.targetRect = CGRectMake(targetContentOffset->x, targetContentOffset->y, scrollView.frame.size.width, scrollView.frame.size.height);
}
- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView {
self.targetRect = nil;
[self loadImageForVisibleCells];
}
#pragma mark - Decide to Load Image For Cells
- (void)loadImageForCell:(AESmartCollectionFlowViewCell *)cell
atIndexPath:(NSIndexPath *)indexPath {
// Cell的targetURLString是指派給Cell的新的圖片URL，在根據(jù)Cell的DTO配置Cell時為其賦值
if (!cell.targetURLString) {
return;
}
// Cell的imageURLString是Cell的當前正在顯示的圖片URL
if (![cell.targetURLString isEqualToString:cell.imageURLString] || cell.isDisplayingPlaceholderNow) {
SDWebImageManager *manager = [SDWebImageManager sharedManager];
UICollectionViewLayoutAttributes *attr = [self.collectionView layoutAttributesForItemAtIndexPath:indexPath];
CGRect cellFrame = attr.frame;
BOOL shouldLoadImageForCurrentCell = YES;
// 如果正在減速而且當前Cell的frame不在將來滑動停止后的可見區(qū)域
if (self.targetRect && !CGRectIntersectsRect(self.targetRect.CGRectValue, cellFrame)) {
// 那么只有Cell的targetURL在內(nèi)存的緩存中，才去加載它
SDImageCache *imageCache = [SDImageCache sharedImageCache];
NSString *key = [manager cacheKeyForURL:[NSURL URLWithString:cell.targetURLString]];
if (![imageCache imageFromMemoryCacheForKey:key]) {
shouldLoadImageForCurrentCell = NO;
}
}
if (shouldLoadImageForCurrentCell) {
[cell loadImage];
}
}
}
- (void)loadImageForVisibleCells {
NSArray *visibleCells = [self.collectionView visibleCells];
for (UICollectionViewCell *cell in visibleCells) {
NSIndexPath *indexPath = [self.collectionView indexPathForCell:cell];
[self loadImageForCell:cell atIndexPath:indexPath];
}
}
做了這些努力后，再去profile一下，發(fā)現(xiàn)網(wǎng)速良好情況下滑動時幀率只丟了那么1、2幀，而且滑動起來無明顯卡頓！
要么不做，要么做絕
哈哈，這個有點狠啊，頗有朱元璋的風(fēng)格。
做了這么多后，我們發(fā)現(xiàn)，數(shù)據(jù)預(yù)加載完畢后，向CollectionView發(fā)送 reloadData 消息通知它數(shù)據(jù)模型變化時，就在這一瞬間，還是會導(dǎo)致CollectionView卡頓那么一下下。
好吧不能忍，封裝一個我們自己的 reloadData 方法，在這里簡單的hold住reload，根據(jù)上文中的 targetRect 屬性的標記作用，當且僅當在CollectionView減速停止后，再去真正向它發(fā)送 reloadData 消息。在這里僅提供思路，不做贅述了。
此外，在開發(fā)中，我們把這一系列的方法以 NSObject 類的Category形式做一個封裝，這樣不管誰是CollectionView的Delegate或者DataSource都可以從容應(yīng)對。
