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。
