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，但是發現這個就破壞了視圖的原始狀態，後面選擇的是另一種方式實現plain的section懸浮。
3·UITableView的update相關
多路insert/delete/reload操作，以beginUpdates和endUpdates組成一起的時候。
(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是否提供了這個機制，我在實現tableview的過程中，新增了數個協議，可以滿足在對tableview進行insert/delete的時候進行自定動畫的需求。
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沒有發現這一點——實際上是我傻逼了。
在實際開發中，如果不是要銷燬了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的內存地址，我這邊選的是這個方法。
很重要的一點是，當cell上面的willRemoveSubview被觸發時，嘿嘿，如果當前cell呈被選中高亮狀態，他就會幫這個要被remove的子視圖回覆原有的背景色啦。
（4）UITableViewCell的layoutSubviews。說實話cell上面的那些默認元素，titleLabel和刪除按鈕左右滑動的，很多時候是沒有用的。而我們一旦在UITableViewCell子類的layoutSubviews裏面進行super layoutSubviews操作，也會照顧到這些默認視圖，實測中也會使cpu的佔用率下滑幾個%。
==============================分割線=================================
下面介紹一下博主的全新tableview，所能提供的，對UITableView的改進的功能點（好像這纔是寫這篇文章的真實目的：
·delegate和dataSource兩個協議以及各種public方法都同UITableView，然後我將header/footer和其高度的協議都放在了dataSource，也就是所有數據返回的協議都放在dataSource了。
·緩存所有的高度信息，在每次reload的時候記住。緩存cell高度這個問題網上有百度的sunny寫的非常棒的cell緩存工具FDxxxx來輔助UITableView。在我這邊則是默認就是存儲到數組裏面（因爲做成動態的很難...），這樣一來又怕有性能問題——比如你在tableview獲取到網絡數據之後，一口氣刷1000+的cell出來並且每個cell的高度計算都很麻煩，那麼我也提供了一個方法- (void)reloadDataAsyncWithCompletion:(void(^)(void))completion來進行異步的加載cell高度，我選擇了gcd的全局隊列去計算和緩存高度完了再主線程刷新tableview——在這個過程中，如果你的tableview先前還有內容顯示，那麼在這個異步計算過程中，你仍然可以滑動瀏覽原本的內容。
·更加流暢的update動畫，特別針對plain模式下，進行多路的insert/delete/reload操作之後，section的header/footer都會有很奇怪的運動軌跡。我也提供了自定義對insert/delete操作時候的動畫的協議。
·可以選擇強制在reload的時候，繼續重用之前產生的cell重用對象。UITableView的每次reload都會清除所有數據，可是我們很多時候，其實cell都是跟先前的一樣，這樣每次reload，無疑是多了刪除舊的cell和創建新的過程——而實際上我們可以使用舊的。
·還有一些邊邊角角的改動，總體都是跟UITableView一樣的。然後說到最重要的功能，就是同樣的cell配置下，cpu的佔用率一定會比UITableView來得低！！！再在同樣的update操作下面，cpu的佔用率也比UITableView來得低！！！