uitableview 优化

1. http://www.cocoachina.com/ios/20150602/11968.html

最近在微博上看到一个很好的开源项目VVeboTableViewDemo，是关于如何优化UITableView的。加上正好最近也在优化项目中的类似朋友圈功能这块，思考了很多关于UITableView的优化技巧，相信这块是难点也是痛点，所以决定详细的整理下我对优化UITableView的理解。

UITableView作为iOS开发中最重要的控件之一，其中的实现原理很是考究。Apple在这块的优化水平直接决定了iOS的体验能甩安卓几条街，哈哈，扯淡扯多了。。。好了，废话不多说，直接进入主题。首先来谈谈我对UITableView的认识：

UITableView的简单认识

UITableView最核心的思想就是UITableViewCell的重用机制。简单的理解就是：UITableView只会创建一屏幕（或一屏幕多一点）的UITableViewCell，其他都是从中取出来重用的。每当Cell滑出屏幕时，就会放入到一个集合（或数组）中（这里就相当于一个重用池），当要显示某一位置的Cell时，会先去集合（或数组）中取，如果有，就直接拿来显示；如果没有，才会创建。这样做的好处可想而知，极大的减少了内存的开销。

知道UITableViewCell的重用原理后，我们来看看UITableView的回调方法。UITableView最主要的两个回调方法是tableView:cellForRowAtIndexPath:和tableView:heightForRowAtIndexPath:。理想上我们是会认为UITableView会先调用前者，再调用后者，因为这和我们创建控件的思路是一样的，先创建它，再设置它的布局。但实际上却并非如此，我们都知道，UITableView是继承自UIScrollView的，需要先确定它的contentSize及每个Cell的位置，然后才会把重用的Cell放置到对应的位置。所以事实上，UITableView的回调顺序是先多次调用tableView:heightForRowAtIndexPath:以确定contentSize及Cell的位置，然后才会调用tableView:cellForRowAtIndexPath:，从而来显示在当前屏幕的Cell。

举个例子来说：如果现在要显示100个Cell，当前屏幕显示5个。那么刷新（reload）UITableView时，UITableView会先调用100次tableView:heightForRowAtIndexPath:方法，然后调用5次tableView:cellForRowAtIndexPath:方法；滚动屏幕时，每当Cell滚入屏幕，都会调用一次tableView:heightForRowAtIndexPath:、tableView:cellForRowAtIndexPath:方法。

看到这里，想必大伙也都能隐约察觉到，UITableView优化的首要任务是要优化上面两个回调方法。事实也确实如此，下面按照我探讨进阶的过程，来研究如何优化：

优化探索，项目拿到手时代码是这样：

1 2 3 4 5 6 7 8 9 10 11 12 13

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {     ContacterTableCell *cell = [tableView dequeueReusableCellWithIdentifier:@"ContacterTableCell"];     if (!cell) {         cell = (ContacterTableCell *)[[[NSBundle mainBundle] loadNibNamed:@"ContacterTableCell" owner:self options:nil] lastObject];     }     NSDictionary *dict = self.dataList[indexPath.row];     [cell setContentInfo:dict];     return cell; } - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {     UITableViewCell *cell = [tableView cellForRowAtIndexPath:indexPath];     return cell.frame.size.height; }

看到这段代码，对于刚毕业的我来说，觉得还是蛮巧妙的，但巧归巧，当Cell非常复杂的时候，直接卡出翔了。。。特别是在我的Touch4上，这我能忍？！好吧，依据上面UITableView原理的分析，我们先来分析它为什么卡？

这样写，在Cell赋值内容的时候，会根据内容设置布局，当然也就可以知道Cell的高度，想想如果1000行，那就会调用1000+页面Cell个数次tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath方法，而我们对Cell的处理操作，都是在这个方法里的！什么赋值、布局等等。开销自然很大，这种方案Pass。。。改进代码。

改进代码后：

1 2 3 4

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {     NSDictionary *dict = self.dataList[indexPath.row];     return [ContacterTableCell cellHeightOfInfo:dict]; }

思路是把赋值和计算布局分离。这样让tableView:cellForRowAtIndexPath:方法只负责赋值，tableView:heightForRowAtIndexPath:方法只负责计算高度。注意：两个方法尽可能的各司其职，不要重叠代码！两者都需要尽可能的简单易算。Run一下，会发现UITableView滚动流畅了很多。。。

基于上面的实现思路，我们可以在获得数据后，直接先根据数据源计算出对应的布局，并缓存到数据源中，这样在tableView:heightForRowAtIndexPath:方法中就直接返回高度，而不需要每次都计算了。

1 2 3 4 5

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {     NSDictionary *dict = self.dataList[indexPath.row]; CGRect rect = [dict[@"frame"] CGRectValue];     return rect.frame.height; }

其实上面的改进方法并不是最佳方案，但基本能满足简单的界面！记得开头我的任务吗？像朋友圈那样的图文混排，这种方案还是扛不住的！我们需要进入更深层次的探究：自定义Cell的绘制。

我们在Cell上添加系统控件的时候，实质上系统都需要调用底层的接口进行绘制，当我们大量添加控件时，对资源的开销也会很大，所以我们可以索性直接绘制，提高效率。是不是说的很抽象？废话不多说，直接上代码：

首先需要给自定义的Cell添加draw方法，（当然也可以重写drawRect）然后在方法体中实现：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

//异步绘制 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{         CGRect rect = [_data[@"frame"] CGRectValue];         UIGraphicsBeginImageContextWithOptions(rect.size, YES, 0);         CGContextRef context = UIGraphicsGetCurrentContext(); //整个内容的背景         [[UIColor colorWithRed:250/255.0 green:250/255.0 blue:250/255.0 alpha:1] set];         CGContextFillRect(context, rect); //转发内容的背景         if ([_data valueForKey:@"subData"]) {             [[UIColor colorWithRed:243/255.0 green:243/255.0 blue:243/255.0 alpha:1] set];             CGRect subFrame = [_data[@"subData"][@"frame"] CGRectValue];             CGContextFillRect(context, subFrame);             [[UIColor colorWithRed:200/255.0 green:200/255.0 blue:200/255.0 alpha:1] set];             CGContextFillRect(context, CGRectMake(0, subFrame.origin.y, rect.size.width, .5));         }                   {     //名字             float leftX = SIZE_GAP_LEFT+SIZE_AVATAR+SIZE_GAP_BIG;             float x = leftX;             float y = (SIZE_AVATAR-(SIZE_FONT_NAME+SIZE_FONT_SUBTITLE+6))/2-2+SIZE_GAP_TOP+SIZE_GAP_SMALL-5;             [_data[@"name"] drawInContext:context withPosition:CGPointMake(x, y) andFont:FontWithSize(SIZE_FONT_NAME)                              andTextColor:[UIColor colorWithRed:106/255.0 green:140/255.0 blue:181/255.0 alpha:1]                                 andHeight:rect.size.height];     //时间+设备             y += SIZE_FONT_NAME+5;             float fromX = leftX;             float size = [UIScreen screenWidth]-leftX;             NSString *from = [NSString stringWithFormat:@"%@  %@", _data[@"time"], _data[@"from"]];             [from drawInContext:context withPosition:CGPointMake(fromX, y) andFont:FontWithSize(SIZE_FONT_SUBTITLE)                    andTextColor:[UIColor colorWithRed:178/255.0 green:178/255.0 blue:178/255.0 alpha:1]                       andHeight:rect.size.height andWidth:size];         } //将绘制的内容以图片的形式返回，并调主线程显示 UIImage *temp = UIGraphicsGetImageFromCurrentImageContext();         UIGraphicsEndImageContext();         dispatch_async(dispatch_get_main_queue(), ^{             if (flag==drawColorFlag) {                 postBGView.frame = rect;                 postBGView.image = nil;                 postBGView.image = temp;             } } //内容如果是图文混排，就添加View，用CoreText绘制 [self drawText]; }}

上述代码只贴出来部分功能，但大体的思路都是一样的，各个信息都是根据之前算好的布局进行绘制的。这里是需要异步绘制，但如果在重写drawRect方法就不需要用GCD异步线程了，因为drawRect本来就是异步绘制的。对于图文混排的绘制，可以移步Google，研究下CoreText，这块内容太多了，不便展开。

好了，至此，我们又让UITableView的效率提高了一个等级！但我们的步伐还远远不止这些，下面我们还可以从UIScrollView的角度出发，再次找到突破口。

滑动UITableView时，按需加载对应的内容

直接上代码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

//按需加载 - 如果目标行与当前行相差超过指定行数，只在目标滚动范围的前后指定3行加载。 - (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset{     NSIndexPath *ip = [self indexPathForRowAtPoint:CGPointMake(0, targetContentOffset->y)];     NSIndexPath *cip = [[self indexPathsForVisibleRows] firstObject];     NSInteger skipCount = 8;     if (labs(cip.row-ip.row)>skipCount) {         NSArray *temp = [self indexPathsForRowsInRect:CGRectMake(0, targetContentOffset->y, self.width, self.height)];         NSMutableArray *arr = [NSMutableArray arrayWithArray:temp];         if (velocity.y<0) {             NSIndexPath *indexPath = [temp lastObject];             if (indexPath.row+33) {                 [arr addObject:[NSIndexPath indexPathForRow:indexPath.row-3 inSection:0]];                 [arr addObject:[NSIndexPath indexPathForRow:indexPath.row-2 inSection:0]];                 [arr addObject:[NSIndexPath indexPathForRow:indexPath.row-1 inSection:0]];             }         }         [needLoadArr addObjectsFromArray:arr];     } }

记得在tableView:cellForRowAtIndexPath:方法中加入判断：

1 2 3 4

if (needLoadArr.count>0&&[needLoadArr indexOfObject:indexPath]==NSNotFound) {     [cell clear];     return; }

滚动很快时，只加载目标范围内的Cell，这样按需加载，极大的提高流畅度。

写了这么多，也差不多该来个总结了！UITableView的优化主要从三个方面入手：

• 提前计算并缓存好高度（布局），因为heightForRowAtIndexPath:是调用最频繁的方法；

• 异步绘制，遇到复杂界面，遇到性能瓶颈时，可能就是突破口；

• 滑动时按需加载，这个在大量图片展示，网络加载的时候很管用！（SDWebImage已经实现异步加载，配合这条性能杠杠的）。

除了上面最主要的三个方面外，还有很多几乎大伙都很熟知的优化点：

• 正确使用reuseIdentifier来重用Cells

• 尽量使所有的view opaque，包括Cell自身

• 尽量少用或不用透明图层

• 如果Cell内现实的内容来自web，使用异步加载，缓存请求结果

• 减少subviews的数量

• 在heightForRowAtIndexPath:中尽量不使用cellForRowAtIndexPath:，如果你需要用到它，只用一次然后缓存结果

• 尽量少用addView给Cell动态添加View，可以初始化时就添加，然后通过hide来控制是否显示

尾巴

肯定很多人会非常好奇，为什么我都是手动用代码创建Cell的？现在主流不都是Xib、Storyboard什么的嘛？我的回答是：要想提高效率，还是手动写有用！抛开Xib、Storyboard需要系统自动转码，给系统多加了一层负担不谈，自定义Cell的绘制更是无从下手，所以，在我看来，复杂的需要高效的界面，还是手动写代码吧！！！

最后如果你们的项目都是用的Xib、Storyboard，并需要优化UITableView的话，sunnyxx大神提出了好的方案：http://blog.sunnyxx.com/2015/05/17/cell-height-calculation/ 大伙可以自行研究研究。

知识是需要不断学习的，作为刚上路的我，如果有什么理解不到位的，欢迎大伙留言指正，如果你有什么更牛逼的想法，希望一起交流交流。

注明：本篇的分析源码来源于开源项目VVeboTableViewDemo

参考：https://github.com/johnil/VVeboTableViewDemo

2.

优化UITableViewCell高度计算的那些事

https://github.com/johnil/VVeboTableViewDemo

http://blog.sunnyxx.com/2015/05/17/cell-height-calculation/

我是前言

这篇文章是我和我们团队最近对 UITableViewCell 利用 AutoLayout 自动高度计算和 UITableView 滑动优化的一个总结。
我们也在维护一个开源的扩展，UITableView+FDTemplateLayoutCell，让高度计算这个事情变的前所未有的简单，也受到了很多星星的支持，github链接请戳我

这篇总结你可以读到：

• UITableView高度计算和估算的机制
• 不同iOS系统在高度计算上的差异
• iOS8 self-sizing cell
• UITableView+FDTemplateLayoutCell如何用一句话解决高度问题
• UITableView+FDTemplateLayoutCell中对RunLoop的使用技巧

---

UITableViewCell高度计算

rowHeight

UITableView是我们再熟悉不过的视图了，它的 delegate 和 data source 回调不知写了多少次，也不免遇到 UITableViewCell 高度计算的事。UITableView 询问 cell 高度有两种方式。
一种是针对所有 Cell 具有固定高度的情况，通过：

1	self.tableView.rowHeight = 88;

上面的代码指定了一个所有 cell 都是 88 高度的 UITableView，对于定高需求的表格，强烈建议使用这种（而非下面的）方式保证不必要的高度计算和调用。rowHeight属性的默认值是 44，所以一个空的 UITableView 显示成那个样子。

另一种方式就是实现 UITableViewDelegate 中的：

1 2 3

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { // return xxx }

需要注意的是，实现了这个方法后，rowHeight 的设置将无效。所以，这个方法适用于具有多种 cell 高度的 UITableView。

estimatedRowHeight

这个属性 iOS7 就出现了， 文档是这么描述它的作用的：

If the table contains variable height rows, it might be expensive to calculate all their heights when the table loads. Using estimation allows you to defer some of the cost of geometry calculation from load time to scrolling time.

恩，听上去蛮靠谱的。我们知道，UITableView 是个 UIScrollView，就像平时使用 UIScrollView 一样，加载时指定 contentSize 后它才能根据自己的 bounds、contentInset、contentOffset 等属性共同决定是否可以滑动以及滚动条的长度。而 UITableView 在一开始并不知道自己会被填充多少内容，于是询问 data source 个数和创建 cell，同时询问 delegate 这些 cell 应该显示的高度，这就造成它在加载的时候浪费了多余的计算在屏幕外边的 cell 上。和上面的 rowHeight 很类似，设置这个估算高度有两种方法：

1 2 3 4 5

self.tableView.estimatedRowHeight = 88; // or - (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath { // return xxx }

有所不同的是，即使面对种类不同的 cell，我们依然可以使用简单的 estimatedRowHeight 属性赋值，只要整体估算值接近就可以，比如大概有一半 cell 高度是 44， 一半 cell 高度是 88， 那就可以估算一个 66，基本符合预期。

说完了估算高度的基本使用，可以开始吐槽了：

1. 设置估算高度后，contentSize.height 根据“cell估算值 x cell个数”计算，这就导致滚动条的大小处于不稳定的状态，contentSize 会随着滚动从估算高度慢慢替换成真实高度，肉眼可见滚动条突然变化甚至“跳跃”。
2. 若是有设计不好的下拉刷新或上拉加载控件，或是 KVO 了 contentSize 或 contentOffset 属性，有可能使表格滑动时跳动。
3. 估算高度设计初衷是好的，让加载速度更快，那凭啥要去侵害滑动的流畅性呢，用户可能对进入页面时多零点几秒加载时间感觉不大，但是滑动时实时计算高度带来的卡顿是明显能体验到的，个人觉得还不如一开始都算好了呢（iOS8更过分，即使都算好了也会边划边计算）

---

iOS8 self-sizing cell

具有动态高度内容的 cell 一直是个头疼的问题，比如聊天气泡的 cell， frame 布局时代通常是用数据内容反算高度：

1	CGFloat height = textHeightWithFont() + imageHeight + topMargin + bottomMargin + ...;

供 UITableViewDelegate 调用时很可能是个 cell 的类方法：

1 2 3

@interface BubbleCell : UITableViewCell + (CGFloat)heightWithEntity:(id)entity; @end

各种魔法 margin 加上耦合了屏幕宽度。

AutoLayout 时代好了不少，提供了-systemLayoutSizeFittingSize:的 API，在 contentView 中设置约束后，就能计算出准确的值；缺点是计算速度肯定没有手算快，而且这是个实例方法，需要维护专门为计算高度而生的 template layout cell，它还要求使用者对约束设置的比较熟练，要保证 contentView 内部上下左右所有方向都有约束支撑，设置不合理的话计算的高度就成了0。

这里还不得不提到一个 UILabel 的蛋疼问题，当 UILabel 行数大于0时，需要指定 preferredMaxLayoutWidth 后它才知道自己什么时候该折行。这是个“鸡生蛋蛋生鸡”的问题，因为 UILabel 需要知道 superview 的宽度才能折行，而 superview 的宽度还依仗着子 view 宽度的累加才能确定。这个问题好像到 iOS8 才能够自动解决（不过我们找到了解决方案）

回到正题，iOS8 WWDC 中推出了 self-sizing cell 的概念，旨在让 cell 自己负责自己的高度计算，使用 frame layout 和 auto layout 都可以享受到：

这个特性首先要求是 iOS8，要是最低支持的系统版本小于8的话，还得针对老版本单写套老式的算高（囧），不过用的 API 到不是新面孔：

1 2	self.tableView.estimatedRowHeight = 213; self.tableView.rowHeight = UITableViewAutomaticDimension;

这里又不得不吐槽了，自动计算 rowHeight 跟 estimatedRowHeight 到底是有什么仇，如果不加上估算高度的设置，自动算高就失效了- -
PS：iOS8 系统中 rowHeight 的默认值已经设置成了 UITableViewAutomaticDimension，所以第二行代码可以省略。

问题：

1. 这个自动算高在 push 到下一个页面或者转屏时会出现高度特别诡异的情况，不过现在的版本修复了。
2. 求一个能让最低支持 iOS8 的公司- -

---

iOS8抽风的算高机制

相同的代码在 iOS7 和 iOS8 上滑动顺畅程度完全不同，iOS8 莫名奇妙的卡。很大一部分原因是 iOS8 上的算高机制大不相同，这是我做的小测试：

研究后发现这么多次额外计算有下面的原因：

1. 不开启高度估算时，UITableView 上来就要对所有 cell 调用算高来确定 contentSize
2. dequeueReusableCellWithIdentifier:forIndexPath: 相比不带 “forIndexPath” 的版本会多调用一次高度计算
3. iOS7 计算高度后有”缓存“机制，不会重复计算；而 iOS8 不论何时都会重新计算 cell 高度

iOS8 把高度计算搞成这个样子，从 WWDC 也倒是能找到点解释，cell 被认为随时都可能改变高度（如从设置中调整动态字体大小），所以每次滑动出来后都要重新计算高度。

说了这么多，究竟有没有既能省去算高烦恼，又能保证顺畅的滑动，还能支持 iOS6+ 的一站式解决方案呢？

---

UITableView+FDTemplateLayoutCell

使用 UITableView+FDTemplateLayoutCell 无疑是解决算高问题的最佳实践之一，既有 iOS8 self-sizing 功能简单的 API，又可以达到 iOS7 流畅的滑动效果，还保持了最低支持 iOS6。
使用起来大概是这样：

1 2 3 4 5 6 7

#import <UITableView+FDTemplateLayoutCell.h> - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { return [tableView fd_heightForCellWithIdentifier:@"identifer" cacheByIndexPath:indexPath configuration:^(id cell) { // 配置 cell 的数据源，和 "cellForRow" 干的事一致，比如： cell.entity = self.feedEntities[indexPath.row]; }]; }

写完上面的代码后，你就已经使用到了：

• 和每个 UITableViewCell ReuseID 一一对应的 template layout cell
  这个 cell 只为了参加高度计算，不会真的显示到屏幕上；它通过 UITableView 的 -dequeueCellForReuseIdentifier: 方法 lazy 创建并保存，所以要求这个 ReuseID 必须已经被注册到了 UITableView 中，也就是说，要么是 Storyboard 中的原型 cell，要么就是使用了 UITableView 的-registerClass:forCellReuseIdentifier: 或 -registerNib:forCellReuseIdentifier:其中之一的注册方法。
• 根据 autolayout 约束自动计算高度
  使用了系统在 iOS6 就提供的 API：-systemLayoutSizeFittingSize:
• 根据 index path 的一套高度缓存机制
  计算出的高度会自动进行缓存，所以滑动时每个 cell 真正的高度计算只会发生一次，后面的高度询问都会命中缓存，减少了非常可观的多余计算。
• 自动的缓存失效机制
  无须担心你数据源的变化引起的缓存失效，当调用如-reloadData，-deleteRowsAtIndexPaths:withRowAnimation:等任何一个触发 UITableView 刷新机制的方法时，已有的高度缓存将以最小的代价执行失效。如删除一个 indexPath 为 [0:5] 的 cell 时，[0:0] ~ [0:4] 的高度缓存不受影响，而 [0:5] 后面所有的缓存值都向前移动一个位置。自动缓存失效机制对 UITableView 的 9 个公有 API 都进行了分别的处理，以保证没有一次多余的高度计算。
• 预缓存机制
  预缓存机制将在 UITableView 没有滑动的空闲时刻执行，计算和缓存那些还没有显示到屏幕中的 cell，整个缓存过程完全没有感知，这使得完整列表的高度计算既没有发生在加载时，又没有发生在滑动时，同时保证了加载速度和滑动流畅性，下文会着重讲下这块的实现原理。

我们在设计这个工具的 API 时斟酌了非常长的时间，既要保证功能的强大，也要保证接口的精简，一行调用背后隐藏着很多功能。

这一套缓存机制能对滑动起多大影响呢？除了肉眼能明显的感知到外，我还做了个小测试：
一个有 54 个内容和高度不同 cell 的 table view，从头滑动到尾，再从尾滑动到头，iOS8 系统下，iPhone6，使用 Time Profiler 监测算高函数所花费的时间：

未使用缓存API、未使用估算，共花费 877 ms：

使用缓存API、开启估算，共花费 77 ms：

测试数据的精度先不管，从量级上就差了一个数量级，说实话自己也没想到差距有这么大- -

同时，工具也顺手解决了-preferredMaxLayoutWidth的问题，在计算高度前向 contentView 加了一条和 table view 宽度相同的宽度约束，强行让 contentView 内部的控件知道了自己父 view 的宽度，再反算自己被外界约束的宽度，破除“鸡生蛋蛋生鸡”的问题，这里比较 tricky，就不展开说了。下面说说利用 RunLoop 预缓存的实现。

---

利用RunLoop空闲时间执行预缓存任务

FDTemplateLayoutCell 的高度预缓存是一个优化功能，它要求页面处于空闲状态时才执行计算，当用户正在滑动列表时显然不应该执行计算任务影响滑动体验。
一般来说，这个功能要耦合 UITableView 的滑动状态才行，但这种实现十分不优雅且可能破坏外部的 delegate 结构，但好在我们还有RunLoop这个工具，了解它的运行机制后，可以用很简单的代码实现上面的功能。

空闲RunLoopMode

在曾经的 RunLoop 线下分享会（视频可戳）中介绍了 RunLoopMode 的概念。
当用户正在滑动 UIScrollView 时，RunLoop 将切换到 UITrackingRunLoopMode 接受滑动手势和处理滑动事件（包括减速和弹簧效果），此时，其他 Mode （除 NSRunLoopCommonModes 这个组合 Mode）下的事件将全部暂停执行，来保证滑动事件的优先处理，这也是 iOS 滑动顺畅的重要原因。
当 UI 没在滑动时，默认的 Mode 是 NSDefaultRunLoopMode（同 CF 中的 kCFRunLoopDefaultMode），同时也是 CF 中定义的 “空闲状态 Mode”。当用户啥也不点，此时也没有什么网络 IO 时，就是在这个 Mode 下。

用RunLoopObserver找准时机

注册 RunLoopObserver 可以观测当前 RunLoop 的运行状态，并在状态机切换时收到通知：

1. RunLoop开始
2. RunLoop即将处理Timer
3. RunLoop即将处理Source
4. RunLoop即将进入休眠状态
5. RunLoop即将从休眠状态被事件唤醒
6. RunLoop退出

因为“预缓存高度”的任务需要在最无感知的时刻进行，所以应该同时满足：

1. RunLoop 处于“空闲”状态 Mode
2. 当这一次 RunLoop 迭代处理完成了所有事件，马上要休眠时

使用 CF 的带 block 版本的注册函数可以让代码更简洁：

1 2 3 4 5 6 7

CFRunLoopRef runLoop = CFRunLoopGetCurrent(); CFStringRef runLoopMode = kCFRunLoopDefaultMode; CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler (kCFAllocatorDefault, kCFRunLoopBeforeWaiting, true, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity _) { // TODO here }); CFRunLoopAddObserver(runLoop, observer, runLoopMode);

在其中的 TODO 位置，就可以开始任务的收集和分发了，当然，不能忘记适时的移除这个 observer

分解成多个RunLoop Source任务

假设列表有 20 个 cell，加载后展示了前 5 个，那么开启估算后 table view 只计算了这 5 个的高度，此时剩下 15 个就是“预缓存”的任务，而我们并不希望这 15 个计算任务在同一个 RunLoop 迭代中同步执行，这样会卡顿 UI，所以应该把它们分别分解到 15 个 RunLoop 迭代中执行，这时就需要手动向 RunLoop 中添加 Source 任务（由应用发起和处理的是 Source 0 任务）
Foundation 层没对 RunLoopSource 提供直接构建的 API，但是提供了一个间接的、既熟悉又陌生的 API：

1 2 3 4 5

- (void)performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(id)arg waitUntilDone:(BOOL)wait modes:(NSArray *)array;

这个方法将创建一个 Source 0 任务，分发到指定线程的 RunLoop 中，在给定的 Mode 下执行，若指定的 RunLoop 处于休眠状态，则唤醒它处理事件，简单来说就是“睡你xx，起来嗨！”
于是，我们用一个可变数组装载当前所有需要“预缓存”的 index path，每个 RunLoopObserver 回调时都把第一个任务拿出来分发：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

NSMutableArray *mutableIndexPathsToBePrecached = self.fd_allIndexPathsToBePrecached.mutableCopy; CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler (kCFAllocatorDefault, kCFRunLoopBeforeWaiting, true, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity _) { if (mutableIndexPathsToBePrecached.count == 0) { CFRunLoopRemoveObserver(runLoop, observer, runLoopMode); CFRelease(observer); // 注意释放，否则会造成内存泄露 return; } NSIndexPath *indexPath = mutableIndexPathsToBePrecached.firstObject; [mutableIndexPathsToBePrecached removeObject:indexPath]; [self performSelector:@selector(fd_precacheIndexPathIfNeeded:) onThread:[NSThread mainThread] withObject:indexPath waitUntilDone:NO modes:@[NSDefaultRunLoopMode]]; });

这样，每个任务都被分配到下个“空闲” RunLoop 迭代中执行，其间但凡有滑动事件开始，Mode 切换成 UITrackingRunLoopMode，所有的“预缓存”任务的分发和执行都会自动暂定，最大程度保证滑动流畅。

---

开始使用UITableView+FDTemplateLayoutCell

如果你觉得这个工具能帮得到你，整合到工程也十分简单。
使用 cocoapods：

1	pod search UITableView+FDTemplateLayoutCell

写这篇文章时的最新版本为 1.2，去除了前一个版本的黑魔法，增加了预缓存功能。
欢迎使用和支持这个工具，有 bug 请随时反馈哦~
再复习下 github 地址： https://github.com/forkingdog/UITableView-FDTemplateLayoutCell

3. http://segmentfault.com/a/1190000000393179

iOS 列表 UITableView 提速指南

JeOam 5.6k 2014年01月21日 发布

• 推荐 0 推荐
• 收藏 2 收藏，4.3k 浏览

UITableview

从08年到现在开发过的iOS应用不计其数了，但是面试很多人的时候，发现依然很多同学在最基本的列表控件上懂得不够深，下面就结合各方面的资料进行再一次讲解。

我们都知道纯代码是效率最高的，但是在开发成本上已经越来越不如使用Storyboard性价比高，速度快，所以本文试图结合UIStoryboard来描述一整套方案。

简单配置

在Storyboard中拖入UITableViewController，并且修改涂涂画画。

在代码区new File生成一个基于UITableviewController的自定义类，我这里暂时取名为Home。因为主页就是一个复杂的列表的不在少数吧？呵呵。

然后在Identity insepctor里修改对应的Class name，使得代码与Storyboard产生关联。

想要做下拉刷新嘛？系统自带了一个给你，并且可以自定义换标题哦。很多人真的不知道在哪儿选中，请看下图，先选中UITableviewController，然后在选项卡中enable这个refresh选项，就自动完成了。 对应的代码还是复制进去，就会自动触发。

然后你需要对UITableView做一些简单的配置，首先要选中UITableView，很多人看不到选项，是因为默认关闭了……

下图是对UITableview的简单配置。

Content是动态列表/静态列表，如果是静态的，那你基本不用写代码就能所见即所得，譬如“设置”页面就可以套用。但是诸如微博啦，朋友圈，还是老实的用动态列表，用代码控制。

Prototype Cells指会出现的cell有几种类型。这个后面再讲。

Style效果现场试一下就看出来了。Separator指的分隔行样式。

然后你就需要代码中做一些简单的配置了,我只列重要的，这里不是基础教程，基础的还是老实的看教科书

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView //几组
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section//每一组分别几行
-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath//每一行多高
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath//每一行分别长啥样
-(void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath//即将显示某行

Load More加载更多

加载更多的UITableview扩展控件非常多，尝试过各种第三方完美扩展后，我觉得这点小把戏也不至于需要扩展UITableview类吧？

那就是在列表追加一个Section，放在最后面，这个Section只有一个Cell,这个自定义的cell有3种状态，这些都可以*发挥。
每当willDisplayCell的时候，你就设置他正在loading状态，给用户造成正在加载的假象，同时触发网络请求。

当有网络数据返回后，自然会insert好多内容，也轮不到这个加载更多的cell显示的地方了，自然就释放了。当然了，如果没有更多内容，也可以轻松的cellForRowAtIndexPath找到唯一的cell，设置为无更多数据等状态。

typedef enum{
    JWLoadMoreNormal = 0,//点击再加载
    JWLoadMoreLoading,//加载中
    JWLoadMoreDone,//无更多数据
} JWLoadMoreState;

@interface LoadMoreCell : UITableViewCell

@property (strong, nonatomic)  UIView *baseWhiteView;
@property (strong, nonatomic)  UIActivityIndicatorView *activity;
@property (strong, nonatomic)  UILabel *tipsLabel;
@property (strong, nonatomic)  UIButton *loadMoreButton;
@property (nonatomic,unsafe_unretained) id <LoadMoreCellDelegate>                   delegate;
-(void)setupUI;
- (void)loadMore:(id)sender;
-(void)setLoadMoreStatus:(JWLoadMoreState)status;

Autolayout

做完这些，基本配置就完成了，下面需要根据设计师的要求进行自定义开发，譬如自定义cell

如上图，密密麻麻的

autolayout的拖拽不会？你太老土了吧。xcode5的拖拽，可谓是异常简单，只需要点快捷菜单的pin，设置好上下左右相对关系就可以了。
创建custom的uitableviewcell基本差不多，拖出来，画画涂涂，创建代码，改类名对应关系，按着“Control”拖拽关联，等等。

我这里只讲一个特殊的，就是图上“图片”“摘要”属于并排区域，可能没有图片的帖子，“摘要”就需要顶格排版。这样的情况该怎么设置呢？

这就得用NSLayoutConstraint的拽出来的关联了。把”摘要“的相对距离，锁定在一个固定的位置上，譬如”左边栏“，通过少量的代码计算，即可动态的修改NSLayoutConstraint.constant的距离。

NSString *url=data.img;
[self.previewImageView setClipsToBounds:YES];
if ( url!=nil && ![url isEqualToString:@""]) {  //这里是判断有图没图
    [self.previewImageView setImageWithURL:[NSURL URLWithString:url] placeholderImage:[UIImage imageNamed:@"pic_default"]];
    self.previewImageHeight.constant=HomeCellImageHeight;
    self.previewImageWidth.constant=HomeCellImageWidth;
    self.abstractLeftMargin.constant=10;  //若有图，摘要与图的左边距变为10
    self.summaryDistanceBetweenTitle.constant=80;
}
else
{
    [self.previewImageView setImage:nil];
    self.previewImageHeight.constant=0;  //图片大小全清空为0
    self.previewImageWidth.constant=0;
    self.abstractLeftMargin.constant=0;  //若无图，摘要与图的左边距变为10
}
[self setNeedsUpdateConstraints];   //记得强制刷新，要不然系统懒懒的
[self.contentView layoutIfNeeded];
[self.contentView setNeedsLayout];

动态计算高度

做到这里，恐怕大部分人都遇到一个门槛了。那就是如何动态计算cell的高度。最简单的，就是网易新闻类，固定高度。return 44;

若是动态的，无非是创建一个cell，并且初始化构造好，然后输出cell的最后一行控件的位置，最终给出位置。

但是这就导致了函数运行的低效。你想，autolayout本来就够效率低了（因为程序猿省事儿了），再为每一行计算2次，这效率能高？

我亲测发现，动态排版效率是非常低的，不足以信任。

最好办的，还是土方法。获取对应的数据，根据自己设定的排版规则，动态的计算。土归土，效率高啊！

        TopicID *data=[threadList objectAtIndex:indexPath.row];
//        NSLog(@"计算行数为%d",indexPath.row);
        int height=0;
        height+=17; //用户名与顶部空间
        height+=17; //用户名高度
        height+=8; //用户名与标题之间距离

        NSString *titleContent=data.title;
        UIFont *titleFont = [UIFont boldSystemFontOfSize:16.0];
        CGSize titleRealSize=[titleContent sizeWithFont:titleFont constrainedToSize:CGSizeMake(280, 150) lineBreakMode:NSLineBreakByTruncatingTail];
        height+=titleRealSize.height;//动态计算标题高度

        if (data.img!=nil && ![data.img isEqualToString:@""]) {
            height+=HomeCellImageHeight;//统计图的起始点
            height+=20;
//            NSLog(@"有图");
        }
        else
        {
            NSString *abstract=data.abstract;
            UIFont *abstractFont = [UIFont boldSystemFontOfSize:14.0];
            CGSize abstractRealSize=[abstract sizeWithFont:abstractFont constrainedToSize:CGSizeMake(280, 300) lineBreakMode:NSLineBreakByTruncatingTail];

            height+=abstractRealSize.height;
            height+=20;
//            NSLog(@"无图");
        }
        height+=56; //统计图的高度
        height+=3;//下边框的高度

最后别忘了Profile，计算时间，每一个细节的时间优化，最终都会体现在列表的流畅度表现上。 通过以上几点呢，再结合现成好用的SDWebImageCache，相信大家一定可以做出真正美观、高效的列表哦！