先前重新實現了一個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·c++類里面的NSObject成員會在類析構時自動dealloc掉，適用于STL容器。
5·UIScrollView的layoutSubviews調用時機
UIScrollView先進行setContentSize再進行addSubview操作，會執行layoutSubviews多次，而如果把setContentSize操作放到最后，那么只會執行一次layoutSubviews
6·UITableView的cell重用限制
UITableView并未對重用cell的數量做限制，在測試過程中，被劃出屏幕外的所有cell都沒被銷毀。這個測試過程中，將cell按順序用height遞增，即每個cell的高度越來越大，那么將會導致一個情況，越是滑動到后面，顯示區域里面的cell會越少（相比之前滑動經過的區域來說），導致了進入重用的cell數量遞增（因為前面一屏顯示的cell數量會更多），那么這些等待重用的cell雖然數量很大也不會被釋放掉的。
7·實用的hidden。
UITableView對滑出屏幕的cell都是進行hidden的而非remove，在設計cell重用緩存的時候，發現一旦頻繁的進行cell的remove操作會比使用hidden的cpu使用率高上10%（在iPhone5上面），而UITableView好像早前版本是remove現在也改為hidden了。
在實際開發中，如果不是得銷毀UIView，那么hidden是比直接remove來得快。另外設置hidden為YES會觸發一次其子視圖的removeFromSuperView操作。
8·xib和純frame設置的問題
xib加載的視圖再用frame進行設置，接著如果改變父視圖的frame會導致其height變為0，那么就是因為xib加載的這個視圖的默認autoresizingMask有height相關的，置為none即可。這個問題之前很困擾，一直沒有發現這個貓膩，當然，只有在前面提到的這個特定條件下(手動改變視圖frame，而其上面的子視圖又是通過xib加載的)才會出現的。
9·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。
