Question

UITableView的原理

Answer 1

先前重新实现了一个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。