UITableView的原理——探究及重新實現代碼

轉自簡書，原文地址，本文主要探討一些特殊細節，像視圖重用這類最基本的原理可在源碼里查看。


先前重新實現了一個list容器視圖，由於Apple沒有開源，在此分享過程中探索到的UITableView一些細節。MPTableView: A list view like UITableView, more fast, more features.

1·捉摸不定的contentOffset

UISrollview在滑動的時候，要獲取其不斷變化的contentOffset值，可通過其協議來獲取也可以在其layoutSubviews裡面獲得，而後者所獲取到的offset值會來得頻繁很多——當快速滑動的時候，scrollView的協議回調次數遠遠低於layoutSubviews調用次數，也即contentOffset的獲取次數更少，那樣一旦需要根據contentOffset來做某些精確的工作的話，則效果會更差。

即使選擇最容易被調用的layoutSubviews，其調用次數也並非都是線性變化的，layoutSubviews被回調的次數是有限（n次1s）的，所以一旦急速滑動，並不會逐像素回調，而是總的滑動距離內調用一定次數，最後每次獲得的contentOffset也將呈跳躍狀。

2·關於UIView的視圖層次

發現在addSubview之後通過insertSubview: AtIndex:來設置子視圖的層級後，一旦重新修改子視圖的frame則這個index將失效。而後面發現了通過view.layer.zPosition的提升則可以令view在其父視圖中一直處於高層級或者低層級。

這個是在實現plain模式下tableview的section header/footer停浮時候，需要解決的問題。因為section視圖很多是比cell早加入顯示區域的(header)，那麼當滾動到需要header浮在cell的頭上時(遮住)，則會出現cell遮住header的情況。一開始選擇了zPosition，但是發現這個就破壞了視圖的原始狀態，後面直接bringToFront實現plain的section懸浮。

3·update相關

多路insert/delete/reload操作。

(1)最好把某種操作的IndexSet/Array全部整合成一個數組，這樣最多就只有3個數組了

(2)這3種操作中reload是優先進行的，至於insert和delete，UIKit是讓delete先進行，再進行insert，在這裡面，reload其實就是做了先delete後insert操作。

(3)經常可以看見某些app進行reload某個cell來進行擴張其內容(cell的height變大)的效果，如果這個cell底部有分割線或者是其他內容的話，那麼在這個擴張cell的過程中，動畫效果是這個cell下麵的cell往下移動，cell的高度被擴充，但是那個分割線卻沒有移動的效果而是直接出現在了最底部。這是由於我們通常選擇了None的動畫方式來進行reload，而None的動畫方式其實就是單純的視圖hidden.

(4)willInsertCell這個協議在insert動畫之前是會被回調的，如果在insert操作裡面選擇了None的動畫枚舉，那麼興許可以通過這個協議做點自定義效果動畫。這個不知道apple是否提供了這個機制。

4·UIScrollView的layoutSubviews調用時機

UIScrollView先進行setContentSize再進行addSubview操作，會執行layoutSubviews多次，而如果把setContentSize操作放到最後，那麼只會執行一次layoutSubviews

5·UITableView的cell重用限制

UITableView並未對重用cell的數量做限制，在測試過程中，被划出屏幕外的所有cell都沒被銷毀。這個測試過程中，將cell按順序用height遞增，即每個cell的高度越來越大，那麼將會導致一個情況，越是滑動到後面，顯示區域裡面的cell會越少（相比之前滑動經過的區域來說），導致了進入重用的cell數量遞增（因為前面一屏顯示的cell數量會更多），那麼這些等待重用的cell雖然數量很大也不會被釋放掉的。

6·實用的hidden。

UITableView對滑出屏幕的cell都是進行hidden的而非remove，在設計cell重用緩存的時候，發現一旦頻繁的進行cell的remove操作會比使用hidden的cpu使用率高上10%（在iPhone5上面），而UITableView好像早前版本是remove現在也改為hidden了。

在實際開發中，如果不是得銷毀UIView，那麼hidden是比直接remove來得快。另外設置hidden為YES會觸發一次其子視圖的removeFromSuperView操作。

7·xib和純frame設置的問題

xib載入的視圖再用frame進行設置，接著如果改變父視圖的frame會導致其height變為0，那麼就是因為xib載入的這個視圖的預設autoresizingMask有height相關的，置為none即可。這個問題之前很困擾，一直沒有發現這個貓膩，當然，只有在前面提到的這個特定條件下(手動改變視圖frame，而其上面的子視圖又是通過xib載入的)才會出現的。

8·cell相關。

（1）dequeueReusableCellWithIdentifier:identifier這個函數不調用並不能幫助你實現cell的不重用，僅需要在進行初始化的時候把reuseIdentifier賦值為nil即可，在這裡initWithFrame創建的cell應該就是預設reuseIdentifier為nil了，因為UITableViewCell的NS_DESIGNATED_INITIALIZER不在initWithFrame。

（2）UITableViewCell被點選的觸發操作，其實並非在cell內部實現手勢點擊，而是通過在UITableView裡面通過獲得當前點擊的位置，來判斷點擊的是哪一個cell，接著調用cell的setSelected:animated函數的。這樣做應該也是為了避免耦合吧。

（3）UITableViewCell的選中高亮。當選中cell的時候，你會發現cell上面的所有視圖，都變成了clearColor來讓cell的高亮背景色顯示出來，而當取消cell高亮的時候又會變回去，那麼這個問題出現了。這些子視圖的背景色被動了！那麼原本的背景色又被記錄在哪裡呢，需要複原的時候又能跑出來。

在這裡有2個思路：

·繼承UIColor來寫一個類，提供一個屬性，受記錄的顏色，當setBackgroundColor的時候碰到的是這個class，就用他記錄的顏色來設置顏色。每次要將所有子視圖都設置為clearColor的時候，就將這些子視圖的背景色都用這個類記錄下來。

·用一個容器存儲這些視圖對應的背景色，按鍵值對應，這裡的key則選用每個UIView的記憶體地址。

·UITableView使用了一個UIView的私有api來解決這個問題：-[UIView _descendent:willMoveFromSuperview:toSuperview:]。

很重要的一點是，當cell上面的willRemoveSubview被觸發時，如果當前cell呈被選中高亮狀態，他就會幫這個要被remove的子視圖回覆原有的背景色。

（4）UITableViewCell的layoutSubviews。一般來講cell上面的那些預設元素，titleLabel和刪除按鈕左右滑動的，很多時候是沒有用的。而一旦在UITableViewCell子類的layoutSubviews裡面有super layoutSubviews，也會照顧到這些預設視圖，實測中也會使cpu的占用率下滑幾個%。


MPTableView對UITableView的改進：

·提供了方法- (void)reloadDataAsyncWithCompletion:(void(^)(void))completion來進行非同步的載入cell高度，選擇了gcd的全局隊列去計算和緩存高度完了再主線程刷新tableview——在這個過程中，如果tableview先前還有內容顯示，那麼在這個非同步計算過程中，仍然可以滑動瀏覽原本的內容。

·修複了update動畫，特別針對UITableView的plain模式下，進行多路的insert/delete/reload操作之後，section的header/footer都會有很奇怪的運動軌跡（這個情況也發生在Mac OX下的NSTable組件）。同時提供了insert/delete等的自定義動畫方法。

·可以選擇強制在reload的時候，繼續重用之前產生的cell重用對象。UITableView的每次reload都會清除所有數據，可是很多時候，其實cell都是跟先前的一樣，這樣每次reload，無疑是多了刪除舊的cell和創建新的過程——而實際上可以使用舊的。

·多路的update操作支持，可以同時/延遲開啟多個update事務，並且設定不同時間、動畫狀態。

·同樣的子視圖樣式下，cpu的占用率一定會比UITableView來得低。在同樣的update操作下麵，cpu的占用率也更低。還有cell拖動模式下也是。

·以及其他的一些改進和新增api，可以在更低系統版本下使用新的api。