轉自簡書，原文地址，本文主要探討一些特殊細節，像檢視重用這類最基本的原理可在原始碼裡檢視。
先前重新實現了一個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。