iOS学习笔记-TableView性能优化篇1
TableView相信只要是做iOS开发的就不会陌生，目前大多数iOS的app都是采用TabBar+NavigationBar+TableViewController这一主流框架，既然用的这么频繁，肯定就会在开发过程中碰到一些问题--比如屏幕掉帧、卡顿等现象。这些现象大幅度的降低了用户的性能体验，并提高了crash的频率。因此如何能优化好tableView就非常考验程序猿们的功底了。
本猿~啊呸，本人就在开发公司项目的时候遇到这类问题，当快速滑动tableView并且cell中有大量图片和其他控件需要加载时，就会出现严重掉帧（我们公司的项目当时大量采用xib现在逐渐用手写代码代替），有时还会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:@"[email protected]"];
}
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，不要用AutoLayout，不要用AutoLayout（这里的情景是子视图较多的情况下），重要的事情说3遍。我们进行手动布局可能会没那么方便，但是通过简单的加减乘除就可以获取控件相对位置和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 *model in modelArray) {
HomeModelFrame *modelFrame = [[HomeModelFrame alloc] init];
modelFrame.model = model;
[frameModels addObject:modelFrame];
}
return frameModels;
}上面代码会将请求到的JSON数组转换为model数组，然后将model数组里的model转换为modelFrame（就是根据model的各个属性计算出frame）:
#import 提前计算后各个控件的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的负载。
原文链接：http://www.jianshu.com/p/8f3ed86e6480
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。