先前重新實現(xiàn)了一個list容器視圖席吴，由于Apple沒有開源，在此分享過程中探索到的UITableView一些細節(jié)存炮。MPTableView: A list view like UITableView, more fast, more features.

1·捉摸不定的contentOffset

UISrollview在滑動的時候隶校，要獲取其不斷變化的contentOffset值，可通過其協(xié)議來獲取也可以在其layoutSubviews里面獲得忍坷，而后者所獲取到的offset值會來得頻繁很多——當快速滑動的時候粘舟，scrollView的協(xié)議回調(diào)次數(shù)遠遠低于layoutSubviews調(diào)用次數(shù)，也即contentOffset的獲取次數(shù)更少佩研，那樣一旦需要根據(jù)contentOffset來做某些精確的工作的話柑肴，則效果會更差。

即使選擇最容易被調(diào)用的layoutSubviews旬薯，其調(diào)用次數(shù)也并非都是線性變化的晰骑，layoutSubviews被回調(diào)的次數(shù)是有限（n次1s）的，所以一旦急速滑動绊序，并不會逐像素回調(diào)硕舆，而是總的滑動距離內(nèi)調(diào)用一定次數(shù)，最后每次獲得的contentOffset也將呈跳躍狀骤公。

2·關于UIView的視圖層次

發(fā)現(xiàn)在addSubview之后通過insertSubview: AtIndex:來設置子視圖的層級后抚官，一旦重新修改子視圖的frame則這個index將失效。而后面發(fā)現(xiàn)了通過view.layer.zPosition的提升則可以令view在其父視圖中一直處于高層級或者低層級阶捆。

這個是在實現(xiàn)plain模式下tableview的section header/footer停浮時候凌节，需要解決的問題钦听。因為section視圖很多是比cell早加入顯示區(qū)域的(header)，那么當滾動到需要header浮在cell的頭上時(遮住)倍奢，則會出現(xiàn)cell遮住header的情況朴上。一開始選擇了zPosition，但是發(fā)現(xiàn)這個就破壞了視圖的原始狀態(tài)娱挨，后面直接bringToFront實現(xiàn)plain的section懸浮余指。

3·update相關

多路insert/delete/reload操作。

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

(2)這3種操作中reload是優(yōu)先進行的酵镜，至于insert和delete，UIKit是讓delete先進行柴钻，再進行insert淮韭，在這里面，reload其實就是做了先delete后insert操作贴届。

(3)經(jīng)晨糠啵可以看見某些app進行reload某個cell來進行擴張其內(nèi)容(cell的height變大)的效果，如果這個cell底部有分割線或者是其他內(nèi)容的話毫蚓，那么在這個擴張cell的過程中占键，動畫效果是這個cell下面的cell往下移動，cell的高度被擴充元潘，但是那個分割線卻沒有移動的效果而是直接出現(xiàn)在了最底部畔乙。這是由于我們通常選擇了None的動畫方式來進行reload，而None的動畫方式其實就是單純的視圖hidden.

(4)willInsertCell這個協(xié)議在insert動畫之前是會被回調(diào)的翩概，如果在insert操作里面選擇了None的動畫枚舉牲距，那么興許可以通過這個協(xié)議做點自定義效果動畫。這個不知道apple是否提供了這個機制钥庇。

4·c++類里面的NSObject成員會在類析構時自動dealloc掉牍鞠，適用于STL容器。

5·UIScrollView的layoutSubviews調(diào)用時機

UIScrollView先進行setContentSize再進行addSubview操作评姨，會執(zhí)行l(wèi)ayoutSubviews多次难述，而如果把setContentSize操作放到最后，那么只會執(zhí)行一次layoutSubviews

6·UITableView的cell重用限制

UITableView并未對重用cell的數(shù)量做限制参咙，在測試過程中龄广，被劃出屏幕外的所有cell都沒被銷毀。這個測試過程中蕴侧，將cell按順序用height遞增择同，即每個cell的高度越來越大，那么將會導致一個情況净宵，越是滑動到后面敲才，顯示區(qū)域里面的cell會越少（相比之前滑動經(jīng)過的區(qū)域來說）裹纳，導致了進入重用的cell數(shù)量遞增（因為前面一屏顯示的cell數(shù)量會更多），那么這些等待重用的cell雖然數(shù)量很大也不會被釋放掉的紧武。

7·實用的hidden剃氧。

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

在實際開發(fā)中妥箕，如果不是得銷毀UIView滥酥，那么hidden是比直接remove來得快。另外設置hidden為YES會觸發(fā)一次其子視圖的removeFromSuperView操作畦幢。

8·xib和純frame設置的問題

xib加載的視圖再用frame進行設置坎吻，接著如果改變父視圖的frame會導致其height變?yōu)?，那么就是因為xib加載的這個視圖的默認autoresizingMask有height相關的宇葱，置為none即可瘦真。這個問題之前很困擾，一直沒有發(fā)現(xiàn)這個貓膩黍瞧，當然诸尽，只有在前面提到的這個特定條件下(手動改變視圖frame，而其上面的子視圖又是通過xib加載的)才會出現(xiàn)的印颤。

9·cell相關弦讽。

（1）dequeueReusableCellWithIdentifier:identifier這個函數(shù)不調(diào)用并不能幫助你實現(xiàn)cell的不重用，僅需要在進行初始化的時候把reuseIdentifier賦值為nil即可膀哲，在這里initWithFrame創(chuàng)建的cell應該就是默認reuseIdentifier為nil了，因為UITableViewCell的NS_DESIGNATED_INITIALIZER不在initWithFrame被碗。

（2）UITableViewCell被點選的觸發(fā)操作某宪，其實并非在cell內(nèi)部實現(xiàn)手勢點擊，而是通過在UITableView里面通過獲得當前點擊的位置锐朴，來判斷點擊的是哪一個cell兴喂，接著調(diào)用cell的setSelected:animated函數(shù)的。這樣做應該也是為了避免耦合吧焚志。

（3）UITableViewCell的選中高亮衣迷。當選中cell的時候，你會發(fā)現(xiàn)cell上面的所有視圖酱酬，都變成了clearColor來讓cell的高亮背景色顯示出來壶谒，而當取消cell高亮的時候又會變回去，那么這個問題出現(xiàn)了膳沽。這些子視圖的背景色被動了汗菜！那么原本的背景色又被記錄在哪里呢让禀，需要復原的時候又能跑出來。

在這里有2個思路：

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

·用一個容器存儲這些視圖對應的背景色糜工，按鍵值對應，這里的key則選用每個UIView的內(nèi)存地址动猬。

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

很重要的一點是，當cell上面的willRemoveSubview被觸發(fā)時赁咙，如果當前cell呈被選中高亮狀態(tài)钮莲，他就會幫這個要被remove的子視圖回復原有的背景色。

（4）UITableViewCell的layoutSubviews彼水。一般來講cell上面的那些默認元素崔拥，titleLabel和刪除按鈕左右滑動的，很多時候是沒有用的凤覆。而一旦在UITableViewCell子類的layoutSubviews里面有super layoutSubviews链瓦，也會照顧到這些默認視圖，實測中也會使cpu的占用率下滑幾個%盯桦。

MPTableView對UITableView的改進：

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

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

·可以選擇強制在reload的時候，繼續(xù)重用之前產(chǎn)生的cell重用對象羽利。UITableView的每次reload都會清除所有數(shù)據(jù)宫患，可是很多時候，其實cell都是跟先前的一樣铐伴，這樣每次reload撮奏，無疑是多了刪除舊的cell和創(chuàng)建新的過程——而實際上可以使用舊的俏讹。

·多路的update操作支持，可以同時/延遲開啟多個update事務畜吊，并且設定不同時間泽疆、動畫狀態(tài)。

·同樣的子視圖樣式下玲献，cpu的占用率一定會比UITableView來得低殉疼。在同樣的update操作下面，cpu的占用率也更低捌年。還有cell拖動模式下也是瓢娜。

·以及其他的一些改進和新增api，可以在更低系統(tǒng)版本下使用新的api礼预。