TableView性能优化

TableView相信只要是做iOS开发的就不会陌生，目前大多数iOS的app都是采用TabBar+NavigationBar+TableViewController这一主流框架，既然用的这么频繁，肯定就会在开发过程中碰到一些问题--比如屏幕掉帧、卡顿等现象。这些现象大幅度的降低了用户的性能体验，并提高了crash的频率。因此如何能优化好tableView就非常考验程序猿们的功底了。

当快速滑动tableView并且cell中有大量图片和其他控件需要加载时，就会出现严重掉帧，有时还会crash。接下来我会根据tableView的delegate以及dataSource方法的执行顺序进行一步一步的讲解。
首先当一个tableView需要显示内容的时候，首先会发送网络请求，向服务器请求数据，然后将数据转为我们可以使用的model后进行reload操作，接下来会向delegate和dataSource请求数据。这时候会先调用- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section 这个方法（假设section为1）。根据model获取cell的行数然后调用-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath，根据model计算出cell的高度。由于tableView是继承自scrollView，所以tableView也会有contentSize属性。它的contentSize取决于所有cell的高度和。和scrollView有一点不同，tableView只会管理可视的cell高度，这样做的目的是避免不必要的性能开销。
大多数情况下我们是将model直接传给cell然后在cell里进行计算各控件的相对位置（利用aotulayout和xib）比如：

-(void)setModel:(ImageCellModel *)model{
_model = model;
self.detailsLabel.text = model.news;
self.priceLabel.text = [NSString stringWithFormat:@"￥%@",model.money];
NSString *iconStr = model.User.headIcon;
// self.portraitImgView.layer.cornerRadius = 15;
// self.portraitImgView.layer.masksToBounds = YES;
if (![iconStr isEqualToString:@""]) {
[self.portraitImgView sd_setImageWithURL:[NSURL URLWithString:iconStr]];
}else{
self.portraitImgView.image = [UIImage imageNamed:@"defaultPortrait@2x.png"];
}
self.nicknameLabel.text = model.User.nickName;
if ([model.User.rank isEqualToString:@"0"]) {
self.rankImgView.image = [UIImage imageNamed:@""];
}
}


但是这样做假如滑动比较快，且内部控件比较复杂会导致CPU的计算量过大，从而导致掉帧。肯定会有人疑惑为什么会掉帧，这是因为GPU 一个机制叫做垂直同步（简写也是 V-Sync），当开启垂直同步后，GPU 会等待显示器的 VSync 信号发出后，才进行新的一帧渲染和缓冲区更新。这样能解决画面撕裂现象，也增加了画面流畅度，但需要消费更多的计算资源，也会带来部分延迟。当GPU发出垂直同步即VSync信号后，CPU开始进行内部控件的创建、布局、解码和控件的相对位置计算。然后将计算好的内容交给GPU进行变换、合成、渲染。然后等待下一个VSync信号。（这段理论部分来自于YY大神）假如在VSync信号发出后，CPU进行计算的时间过长，或者GPU进行渲染的时间过长导致两段时间加起来超过了1个VSync周期，就会将这一帧动画丢弃，并维持上一帧的画面从而导致掉帧。

那么我们如何进行优化呢？
最终目的：平衡CPU和GPU的压力。正确地利用了CPU和GPU资源，使它们均匀地负载，这样子做FPS会保持在60帧。避免出现CPU满载GPU低负载或者GPU满载CPU低负载的情况。

如何避免出现CPU满载GPU低负载呢？
1.不要用AutoLayout。我们进行手动布局可能会没那么方便，但是通过简单的加减乘除就可以获取控件相对位置和cell的高度。尽管苹果推荐使用AutoLayout。但是对于那些比较古老的设备比如我的5S，CPU通过AutoLayout计算布局会比较吃力，尤其是cell内部的控件数量较多的时候。使用的子视图越多，AutoLayout的效率越低，这是事实。那么为什么AutoLayout相对低效呢。是因为它要根据底层“Cassowary”的约束求解系统进行约束计算，从而得到一个唯一解，这时AutoLayout才不会报警告或错误（相信拖控件的同学肯定遇到过各种黄色警告和红包约束冲突吧）。假如内部的子控件越多，它需要进行的线性或非线性计算量越大，需要求解的约束越多，CPU计算耗费大量时间从而导致超过了一个VSync周期。相反的，假如我们进行手动布局，都是非常简单的线性计算，CPU就不用浪费那么时间，CPU的压力不会很大，从而平衡了CPU的负载。
tips ：我们可以在tableView进行网络请求成功后立刻进行后台的布局计算。比如是我，利用AFN请求数据成功后会在success 的block里面进行后台的计算：

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), ^{
NSMutableArray *modelAry = [ImageCellModel mj_objectArrayWithKeyValuesArray:responseObject[@"data"]];
NSMutableArray *modelFrameAry = [self modelFramesWithModelAry:modelAry];
dispatch_async(dispatch_get_main_queue(), ^{
//这里面把计算好的frameModel返回给主线程并执行正常的操作
});
- (NSMutableArray *)modelFramesWithModelAry:(NSArray *)modelArray
{
NSMutableArray *frameModels = [NSMutableArray array];
for (ImageCellModel *modelin modelArray) {
HomeModelFrame *modelFrame = [[HomeModelFrame alloc] init];
modelFrame.model = model;
[frameModels addObject:modelFrame];
}
return frameModels;
}


上面代码会将请求到的JSON数组转换为model数组，然后将model数组里的model转换为modelFrame（就是根据model的各个属性计算出frame）:
#import <Foundation/Foundation.h>
@classImageCellModel;
@interfaceHomeModelFrame :NSObject
@property (nonatomic,strong)ImageCellModel *model;
@property(nonatomic,assign)CGRect avatarFrame;
@property(nonatomic,assign)CGRect nameFrame;
@property(nonatomic,assign)CGRect priceFrame;
@property(nonatomic,assign)CGRect photosFrame;
@property(nonatomic,assign)CGRect labelFrame;
@property(nonatomic,assign)CGRect descriptionFrame;
@property(nonatomic,assign)CGRect timeAndDisFrame;
@property(nonatomic,assign)CGFloat cellHeight;
@property(nonatomic,assign)CGRect dateAndOurLabelFrame;
@end
//在.m中
-(void)setModel:(ImageCellModel *)model{
_model = model;
CGFloat cellW = [UIScreen mainScreen].bounds.size.width;
if (model.PicList.count) {
_photosFrame = CGRectMake(0,0, cellW , (cellW ) /2);
}else{
_photosFrame = CGRectMake(0,0, cellW,50);
}
_priceFrame = CGRectMake(cellW -60,CGRectGetMaxY(_photosFrame) -28,60,20);
_avatarFrame = CGRectMake(15,CGRectGetMaxY(_photosFrame) -19,38, 38);
_labelFrame = CGRectMake(CGRectGetMaxX(_avatarFrame) +10,CGRectGetMaxY(_photosFrame) -9,18,18);
_descriptionFrame = CGRectMake(CGRectGetMaxX(_avatarFrame),CGRectGetMaxY(_labelFrame) +11, cellW - CGRectGetMaxX(_avatarFrame) -17,13);
_dateAndOurLabelFrame = CGRectMake(CGRectGetMaxX(_avatarFrame),CGRectGetMaxY(_descriptionFrame) +14,180 ,11);
_timeAndDisFrame = CGRectMake(cellW -150,CGRectGetMaxY(_descriptionFrame) +14,150,11);
_cellHeight = CGRectGetMaxY(_timeAndDisFrame) +9;
}


提前计算后各个控件的frame并把cell的高度提前缓存起来等到调用-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath时直接return _cellHeight，没有任何计算量，从而减轻CPU的负载。
假如想进一步优化，可以尝试调用控件的view.layer.displaysAsynchronously属性为YES。
之前我们调用了dataSource和delegate的两个关于row和height的方法，接下来tableView会调用- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath 这个返回创建并返回特定row的cell。在这个方法内部，我们对cell里的每个控件进行赋值并计算各个控件的布局。只需要把各个控件的frame指向之前已经计算好的各个modelFrame就可以了，不需要进行多余的布局计算，然后对每个控件的内容进行一一赋值，这样子就能在调用cellForRowAtIndexPath这个方法的时候迅速的返回一个cell。

如何避免出现GPU满载CPU低负载呢？
1.当多个视图重叠时，GPU会对其进行合成渲染，而渲染最慢的操作之一是混合，因此当视图结构太复杂就会消耗大量GPU资源，所以当一个控件本身是不透明的，注意设定opaque = YES，这样子可以避免无用的alpha通道合成，降低GPU负载。
2.对控件设置cornerRadius后对其进行clip或mask操作时，会导致offscreen rendering，而这个是在GPU中进行的，所以快速滑动tableView时，假如圆角对象较多，会导致GPU负载大增。这时候我们可以设置layer的shouldRasterize属性为YES，可以将负载转移给CPU。更为彻底的做法是直接在后台绘制圆角图片然后输出到主线程显示，避免使用圆角、阴影、遮罩等属性。（这种最彻底的做法我没试过）
3.将GPU的部分渲染转接给CPU，那么如何转接呢？我们可以在单个控件中重载drawRect:方法,直接将文字和图片绘制然后输出到主线程上。
-(void)drawRect:(CGRect)rect{
UIImage *image = [UIImage imageNamed:@"logo"];
[image drawInRect:CGRectMake(0,0,100,100)];
NSString *str =@"123 1234 12345 123456";
CGContextRef ctx =UIGraphicsGetCurrentContext();
CGContextAddRect(ctx,CGRectMake(0,0,100,100));
CGContextStrokePath(ctx);
[str drawInRect:CGRectMake(0,0,100,100) withAttributes:nil];
}

当然你也可以设置Dictionary给Attributes赋值达到自己想要的文字效果。这段代码禁用了一些混合操作，减轻了GPU的负担，从而使UITableView滑动更加流畅。
总之，性能优化要注意平衡CPU和GPU的负载。

1. 使用不透明视图。

1. 不透明的视图可以极大地提高渲染的速度。因此如非必要，可以将table cell及其子视图的opaque属性设为YES（默认值）。

1. 其中的特例包括背景色，它的alpha值应该为1（例如不要使用clearColor）；图像的alpha值也应该为1，或者在画图时设为不透明。

1. 不要重复创建不必要的table cell。

1. 前面说了，UITableView只需要一屏幕的UITableViewCell对象即可。因此在cell不可见时，可以将其缓存起来，而在需要时继续使用它即可。

1. 而UITableView也提供了这种机制，只需要简单地设置一个identifier即可：

static NSString *CellIdentifier = @"xxx"; UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];if (cell == nil) { cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease]; }

1. 值得一提的是，cell被重用时，它内部绘制的内容并不会被自动清除，因此你可能需要调用setNeedsDisplayInRect:或setNeedsDisplay方法。
   此 外，在添加table cell的时候，如果不需要动画效果，最好不要使用insertRowsAtIndexPaths:withRowAnimation:方法，而是直接调 用reloadData方法。因为前者会对所有indexPaths调用tableView:cellForRowAtIndexPath:方法，即便该 cell并不需要显示（不知道是不是bug），这就可能创建大量多余的cell。勘误：只是在模拟器上测试如此，真机调试时没有这种bug。
   
2. 减少视图的数目。
   UITableViewCell包含了textLabel、detailTextLabel和imageView等view，而你还可以自定义一些视图放在它的contentView里。然而view是很大的对象，创建它会消耗较多资源，并且也影响渲染的性能。
   如果你的table cell包含图片，且数目较多，使用默认的UITableViewCell会非常影响性能。奇怪的是，使用自定义的view，而非预定义的view，明显会快些。
   当然，最佳的解决办法还是继承UITableViewCell，并在其drawRect:中自行绘制：
   

   - (void)drawRect:(CGRect)rect { if (image) { [image drawAtPoint:imagePoint]; self.image = nil; } else { [placeHolder drawAtPoint:imagePoint]; } [text drawInRect:textRect withFont:font lineBreakMode:UILineBreakModeTailTruncation]; }

   不过这样一来，你会发现选中一行后，这个cell就变蓝了，其中的内容就被挡住了。最简单的方法就是将cell的selectionStyle属性设为UITableViewCellSelectionStyleNone，这样就不会被高亮了。
   此 外还可以创建CALayer，将内容绘制到layer上，然后对cell的contentView.layer调用addSublayer:方法。这个例 子中，layer并不会显著影响性能，但如果layer透明，或者有圆角、变形等效果，就会影响到绘制速度了。解决办法可参见后面的预渲染图像。
   
3. 不要做多余的绘制工作。
   在实现drawRect:的时候，它的rect参数就是需要绘制的区域，这个区域之外的不需要进行绘制。
   例如上例中，就可以用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判断是否需要绘制image和text，然后再调用绘制方法。
   
4. 预渲染图像。
   你会发现即使做到了上述几点，当新的图像出现时，仍然会有短暂的停顿现象。解决的办法就是在bitmap context里先将其画一遍，导出成UIImage对象，然后再绘制到屏幕，详细做法可见《利用预渲染加速iOS设备的图像显示》。
   
5. 不要阻塞主线程。
   做到前几点后，你的table view滚动时应该足够流畅了，不过你仍可能让用户感到不爽。常见的现象就是在更新数据时，整个界面卡住不动，完全不响应用户请求。
   出现这种现象的原因就是主线程执行了耗时很长的函数或方法，在其执行完毕前，无法绘制屏幕和响应用户请求。其中最常见的就是网络请求了，它通常都需要花费数秒的时间，而你不应该让用户等待那么久。
   解 决办法就是使用多线程，让子线程去执行这些函数或方法。这里面还有一个学问，当下载线程数超过2时，会显著影响主线程的性能。因此在使用 ASIHTTPRequest时，可以用一个NSOperationQueue来维护下载请求，并将其 maxConcurrentOperationCount设为2。而NSURLRequest则可以配合GCD来实现，或者使用NSURLConnection的setDelegateQueue:方法。
   当然，在不需要响应用户请求时，也可以增加下载线程数，以加快下载速度：
   

   - (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate { if (!decelerate) { queue.maxConcurrentOperationCount = 5; } } - (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView { queue.maxConcurrentOperationCount = 5; } - (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView { queue.maxConcurrentOperationCount = 2; }

   此外，自动载入更新数据对用户来说也很友好，这减少了用户等待下载的时间。例如每次载入50条信息，那就可以在滚动到倒数第10条以内时，加载更多信息：
   

   - (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath { if (count - indexPath.row < 10 && !updating) { updating = YES; [self update]; } }// update方法获取到结果后，设置updating为NO

   还有一点要注意的就是当图片下载完成后，如果cell是可见的，还需要更新图像：
   

   NSArray *indexPaths = [self.tableView indexPathsForVisibleRows];for (NSIndexPath *visibleIndexPath in indexPaths) { if (indexPath == visibleIndexPath) { MyTableViewCell *cell = (MyTableViewCell *)[self.tableView cellForRowAtIndexPath:indexPath]; cell.image = image; [cell setNeedsDisplayInRect:imageRect]; break; } }// 也可不遍历，直接与头尾相比较，看是否在中间即可。

   最后还是前面所说过的insertRowsAtIndexPaths:withRowAnimation:方法，插入新行需要在主线程执行，而一次插入很多行的话（例如50行），会长时间阻塞主线程。而换成reloadData方法的话，瞬间就处理完了。

转载地址：http://www.jianshu.com/p/8f3ed86e6480

转载地址：http://blog.sina.com.cn/s/blog_b638dc890101ep3x.html