IOS 很是流暢的滑動tableView

爲何要寫這篇文章呢？以前寫過一篇，由於手機打字不是很方便，還有以前同事用6splus 定下午茶時候，我滑動列表時候居然誤覺得是安卓系統的手機。

 

tableview 流暢度能夠用fps來測試，到60幀說明你優化tableView 已經頗有經驗了。

以下圖怎麼測試

接下來從哪方面入手來優化呢？

優化tableView主要有兩個思路。緩存操做和異步操做。

 

問題一：

新人寫tableView ，在下面方法中

頻繁的建立cell 上的子控件而且添加到cell 上，這是一個要注意的地方，由於這樣頻繁的建立控件和添加會增長CPU的消耗，間接掉幀。

解決方法呢：在cell 裏面以下方法

 

 

把全部的控件都建立好。經過隱藏來控制不一樣類型的cell顯示。以下圖示意：

 

我再解釋下。我先按照上圖把控件都建立好了。若是沒有評論就隱藏掉如上圖是隱藏的效果。這樣就不會把評論的高度計算到cell高度裏。若是圖片們沒有，那麼就不會把圖片算裏面，視頻分享連接就從朋友圈內容開始計算佈局。以此類推。

 

 

 

問題二：

tableView 高度問題。tableView 會頻繁的調用以下方法

 

來 先肯定它的contentSize及每一個Cell的位置，而後再調用cellForRowAtIndexPath 來顯示。

解決方案：在後臺計算好高度以及佈局，並緩存到內存重複使用。

後臺計算cell 的高度而後放到集合裏面下次繼續使用。

問題三：有一些顯示的內容有富文本，特別是從HTML 轉化爲屬性字符串時候。

解決方案，後臺提早轉化須要的屬性字符串，而後緩存起來避免重複轉化帶來的CPU性能消耗。能夠參考DTCoreText從HTML轉化屬性字符串的思路，他就是GCD後臺轉化的。

問題四：圖片圓角，陰影等操做，會引發離屏渲染。對CPU性能消耗。

解決方案：用一個圖片蓋上，或者後臺就把圖片繪製成圓角圖片顯示。

問題五：一些顯示不少圖片的地方，服務器的圖片很大，不是你控件的大小。

解決方案：服務器返回控件寬高的圖片，好比七牛能夠在圖片路徑拼接參數來獲取指定寬高。

問題六：視圖層次複雜狀況下，CPU把它們混合會很消耗資源

解決方案：若是不能避免，能夠把你的視圖繪製成一張圖片來顯示，固然渲染的過程在後臺。能夠參考 VVeboTableViewDemo的思路。

還有一些其餘的技巧，好比不用SB 和Xib 來建立cell 用純代碼來建立，拋棄自動佈局用座標來計算佈局。雖然會犧牲不少時間

總之：把一些影響CPU的操做放到後臺來操做，而後緩存一切能夠緩存的東西。