UITableView優化筆記（一）

推薦：http://code4app.com/ios/VVeboTableView/565d75a3594b90bf268b49ff

 

1: heightForRowAtIndexPath方法小作文章

 

緣由：tableview繼承自scrollview，當tableview加載時須要將contentSize計算出來。因此第一次加載時會頻繁調用此方法，如：table有100行，則此方法調用100次，將每次得出的結果相加獲得contentSize。就像每次使用scrollview滾動時都要設置contentSize這個屬性同樣。

 

小作文章1:若是table每個cell的高度固定，使用_tableView.rowHeight ＝ 200；

 

小作文章2:若是cell高度可變，不要在heightForRowAtIndexPath中調用cellForRowAtIndexPath來計算。取而代之的是，cell的工廠方法。如：

 

 

小作文章3:在獲取數據的時候就將高度計算好並存儲到數據中，heightForRowAtIndexPath方法則直接使用該數據。如：

 

 

總結：儘量使用第三種方法，分析以下

第二種方法時間分析以下：

 

 

第三種方法時間分析以下：

 

 

兩種方法本質上都是遍歷數據獲取相應高度，計算高度的代碼徹底相同。可是第二種方法中heightForRowAtIndexPath的運行時間佔比很大，而且隨着table滾動而不斷增長，證實每次用戶滾動table時，計算高度的方法都執行一次，若是計算高度的方法用時比較多，如我當前用的

 

每次計算的時間都在330個單位上下，那麼若是數據量大，滾動很快時，這簡直就是災難。

第三種方法計算高度的代碼則是在獲取數據後，table加載以前執行，而且只執行一次。210ms的時間不隨着table的滾動兒增長。而咱們的heightForRowAtIndexPath的方法，執行時間已經降到了1ms，幾乎能夠忽略不計了。

固然，在一個只有table的demo中，這點優化基本看不出有什麼做用。 

 

 

 

2:添加不如畫：cellForRowAtIndexPath方法大費周折

 

平時使用cellForRowAtIndexPath時最經常使用的方法就是在cell的init方法中addSubview如

 

 

這個是添加子視圖的方法將數據灌在cell中。

 

畫的方法則是在最開始推薦的demo中的方法，感謝做者。

 

像這樣：

 

 

畫的代碼不少，基本屬於CoreGraphics框架的東東，說大費周折，基本都在這了。

 

添加子視圖的方法時間分析以下：

 

畫的方法時間分析以下：

 

 

實話實說呀，這畫的方法代碼執行的時間真心是嚇了我一跳了，畫cell的線程真心是-_-#

可是呢，用戶滾動table是感受不到地，由於全部畫的線程都是子線程，而主線程佔比只有區區的2%，就是setimage的方法。

反過來，添加子視圖的方法cellForRowAtIndexPath則幾乎所有都在主線程執行，子線程只有查找緩存圖片的方法。這個辦法真心卡卡卡的呀。

真機跑一下，明顯感受畫的方法要比添加子視圖的方法順暢的多。

 

ps:只分析代碼執行時間，不分析內存佔用量。