Feed流應(yīng)該是每個App和游戲開發(fā)者都避免不了的話題。特別是App開發(fā)汁掠，絕大多數(shù)App的內(nèi)容呈現(xiàn)都是以Feed流來實現(xiàn)的略吨。其實講Feed流性能優(yōu)化的文章已經(jīng)有很多了，而且很大文章都給出了具體的代碼實現(xiàn)考阱。所以我沒必要再寫一篇很詳細(xì)的文章翠忠，只是當(dāng)自己做的總結(jié)了。
1.優(yōu)化feed高度計算乞榨。
我覺得這是一個最簡單卻又收效很明顯的一個方法秽之。具體做法如下：
a.使用推測（預(yù)估）高度方法
- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath NS_AVAILABLE_IOS(7_0);
我們都知道，tableView在初次加載的時候吃既，如果有100個cell那么就會調(diào)用100次heightForRowAtIndexPath方法考榨，蘋果在iOS7上新增了estimatedHeightForRowAtIndexPath方法后，如果實現(xiàn)了這個方法鹦倚，初次加載的時候就會調(diào)用100次estimatedHeightForRowAtIndexPath來替代heightForRowAtIndexPath方法河质。
重點是estimatedHeightForRowAtIndexPath方法可以給一個預(yù)估值，而不是具體值。也就是說你可以給一個接近于平均cell高度的值掀鹅。比如直接return 80.0f;
這樣以來就大大節(jié)省了初次加載的高度計算時間散休。當(dāng)然，當(dāng)你滑動以顯示更多cell的時候還是會調(diào)用heightForRowAtIndexPath方法淫半。
b.緩存cell高度
這是一個優(yōu)化滑動卡頓很好的方法溃槐，因為每次滑動的時候，需要繪制新的cell或者重用舊的cell科吭，就會調(diào)用對應(yīng)cell的heightForRowAtIndexPath方法昏滴。如果能做到根據(jù)數(shù)據(jù)就能計算cell顯示高度的話最好不過了。這樣就可以在拿到數(shù)據(jù)的時候計算一次高度对人，然后緩存起來谣殊，一勞永逸。
具體做法是牺弄，比如根據(jù)后端下發(fā)的數(shù)據(jù)姻几，計算高度放一個數(shù)組里。然后在heightForRowAtIndexPath取出對應(yīng)的高度值势告。這樣不用每次計算蛇捌，但是會引出一個問題，就是需要維護(hù)這個數(shù)組咱台。當(dāng)數(shù)據(jù)發(fā)生改變的時候络拌，數(shù)組必須作出對應(yīng)的改變。
2.異步加載／繪制回溺，甚至不繪制春贸。
其實異步加載都不用說了，現(xiàn)在大多數(shù)項目中都使用SDWebImage之類的庫遗遵，實現(xiàn)了網(wǎng)絡(luò)圖片的異步加載了萍恕。在滑動的時候，圖片的加載并不會影響滑動流暢度车要。
這里要重點說的是“不繪制”允粤，監(jiān)測tableview的滑動速度，如果速度快到一定程度翼岁，那么這時候需要顯示的cell就延時繪制维哈，用戶看到的可能只是一些和真實cell等高的，但是內(nèi)容是空白或者默認(rèn)圖案／文案的cell登澜。微博客戶端就有一套這種機(jī)制阔挠。這個實現(xiàn)起來稍微復(fù)雜，而且依賴于高度緩存脑蠕。如果有機(jī)會我會寫一個Demo來說明购撼。
