為什么要寫這篇文章呢？之前寫過一篇，因為手機打字不是很方便，還有之前同事用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的操作放到后台來操作，然后緩存一切可以緩存的東西。