UITableView性能优化以及常见问题汇总

tableView卡顿的原因,从硬件上来说无非就两个,一个是CPU原因,一个是GPU原因.如果CPU核数较多,并发处理问题的能力也就越强,处理大量计算也不在话下;如果GPU显存够大,渲染能力足够强,处理复杂图形界面也就得心应手。但是,硬件的配置是有限度的,我们的目标是在有限度的硬件上,让其发挥最大限度的作用。
1.老生常谈cell重用时引发的问题😜
UITableView中的cell可以有很多，一般会通过重用cell来达到节省内存的目的:通过为每个cell指定一个重用标识符(reuseIdentifier),即指定了单元格的种类,当cell滚出屏幕时,会将滚出屏幕的单元格放入重用的queue中，当某个未在屏幕上的单元格要显示的时候，就从这个queue中取出单元格进行重用。
但对于多变的自定义cell，有时这种重用机制会出错。比如，当一个cell分割线UI无法系统原生无法满足采用自定义方案时，这时如果还有同类cell不需要展示或者UI要求不同的分割线时就会出错。3种老方案网上也有很多，还有一种用使用prepareForReuse也不错。

方案一：

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { 
    //以indexPath来唯一确定cell
    NSString *CellIdentifier = [NSString stringWithFormat:@"Identifier%d%d", [indexPath section], [indexPath row]]; 
    //出列可重用的cell
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];  
    if (cell == nil) { 
        cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier]; 
    } 
    //xxxxxxx 
}

通过为每个cell指定不同的重用标识符(reuseIdentifier)来解决。重用机制是根据相同的标识符来重用cell的，标识符不同的cell不能彼此重用。于是我们将每个cell的标识符都设置为不同，就可以避免不同cell重用的问题了。
方案二：

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { 
    static NSString *CellIdentifier = @"Cell"; 
    //根据indexPath准确地取出一行，而不是从cell重用队列中取出 
    UITableViewCell *cell = [tableView cellForRowAtIndexPath:indexPath]; 
    if (cell == nil) { 
        cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier]; 
    } 
     //...其他代码                               
 }

.
重用机制调用的就是dequeueReusableCellWithIdentifier这个方法，方法的意思就是“出列可重用的cell”，因而只要将它换为cellForRowAtIndexPath（只从要更新的cell的那一行取出cell），就可以不使用重用机制，因而问题就可以得到解决，但是这个方法会有很多的cell创建，浪费了一些空间。
方案三：

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { 
    static NSString *CellIdentifier = @"Cell"; 
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) { 
        cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier]; 
    } else { 
        //删除cell的所有子视图 
        while ([cell.contentView.subviews lastObject] != nil) { 
            [(UIView*)[cell.contentView.subviews lastObject] removeFromSuperview]; 
        } 
    } 
    //...其他代码 
}

.
删除重用cell的所有子视图；这个方法是通过删除重用的cell的所有子视图，从而得到一个没有特殊格式的cell，供其他cell重用。考虑到内存问题,cell少得时候可以每个都添加标识符,当cell重用较多时,考虑内存问题,建议用删除cell的所有子视图方法。
方案四：
当前已经被分配的cell如果被重用了(通常是滚动出屏幕外了),会调用cell的prepareForReuse通知cell。注意这里重写方法的时候,注意一定要调用父类方法[super prepareForReuse] 。

- (void)prepareForReuse {
   [super prepareForReuse];
   //...其他代码 
   }

2.cell高度问题
这里涉及的主要是减轻CPU负荷的问题。CPU的主要负责快速调度任务,大量计算工作,所以在tableView快速滚动的过程中让CPU的计算量降低是优化应该考虑的方向。
这个问题有两种情况：定高的cell和动态高度的cell。（这里不讨论storyboard,xib的情况，通过Interface知道xib或者storyboard本身就是一个xml文件,添加删除控件必然中间多了一个encode/decode过程,增加了cpu的计算量。并且还要避免臃肿的 XIB 文件,因为XIB文件在主线程中进行加载布局。当用到一些自定义View或者XIB文件时,XIB的加载会把所有内容加载进来,如果XIB里面的一些控件并不会用到,这就可能造成一些资源的消耗浪费。storyboard好一些，但也不推荐使用。）
（1）定高的cell
这没什么好说的，在tableView初始化方法里直接写死cell高度，例如：

   self.tableView.rowHeight = 120;

.
这个方法指定tableView涉及范围内所有的cell高度都是120，rowHeight默认的值是44。对于定高cell，直接采用上面方式给定高度，不需要实现tableView:heightForRowAtIndexPath:方法，这样可以节省不必要的计算和开销。
（2）动态高度的cell
这里面又有两种处理方案
<1>提前计算出cell高度，存在对应的model或者其他相应模块中，实现代理，来给出高度：

   -(CGFloat)tableView:(UITableView*)tableViewheightForRowAtIndexPath:(NSIndexPath*)indexPath {                
   // return height;        
   }

.
这个代理方法实现后，上面的rowHeight的设置将会变成无效。在这个方法中，我们需要提高cell高度的计算效率，提前计算并缓存cell的高度，来节省时间。这种方案对比自动布局肯定对比CPU的损耗肯定是更小的，自动布局就是给控件添加约束,约束最终还是转换成frame。在满足业务需求情况下,如果图层层次较为复杂,要尽量减少自动布局约束,转为手动计算布局,大量的约束重叠也会增加cpu的计算量，但也不是说自动布局就没有优点。
<2>iOS8之后苹果为UITableView引入SelfSizing Cell，配合constraints的使用省去了动态计算Cell高度麻烦，而且有时还存在着计算不准确的尴尬。想要利用这个特性，cell布局是必须使用AutoLayout,无论是使用Interface Builder方式还是使用Coding方式，前提是必须能理解AutoLayout的布局思路和熟练使用Constraints。使用Masonry的代码会更简单、简洁。当然tableView的属性配置也必不可少：

   self.tableView.estimatedRowHeight = 44.0
   self.tableView.rowHeight = UITableViewAutomaticDimension

.
estimatedRowHeight：默认值UITableViewAutomaticDimension。设置一个非负的值可以提高TableView的加载效率，提升体验性，而设置值为零则禁掉了预估高度的功能。如果要使用SelfSizing Cell是需要设置estimatedRowHeight属性的。
rowHeight：默认值UITableViewAutomaticDimension。如果是Coding的话，其实是不需要显示设置这个属性，只有用Interface Builder创建的Cell需要显示设置tableView.rowHeight = UITableViewAutomaticDimension。

3.高级一点的优化：图片加载，避免快速滑动情况下开过多线程😁
说到图片里面的水太深了，图片的解压缩（位图数据到二进制数据转换的过程）是一个非常耗时的 CPU 操作，并且它默认是在主线程中执行的。那么当需要加载的图片比较多时，就会对我们应用的响应性造成严重的影响，尤其是在快速滑动的列表上，这个问题会表现得更加突出。既然一定要解压，耗时，不能卡在主线程，那就拿到子线程解压，把解压完的图片返回之后，再次渲染的时候，捕捉到已经解压了，就不需要在主线程解压了，直接显示。这也是所有第三方图片框架下载的核心。也就是我们关心性能优化。另外多BB的是，图片的一般加载方式有两种:imageNamed 和imageWithContentsOfFile;它们的不同在于前者会对图片进行缓存,而后者只是简单的从文件加载文件。如果你加载的是大图,并且只会用到一次,比如欢迎引导图,那么就没必要缓存这个图片,可以使用[UIImage imageWithContentsOfFile:],用完就释放了。如果会多次使用到一张图时,用[UIImage imageNamed:] 就会高效很多,因为这种加载图片方式有一个缓存机制。
回到正题：cell中的图片会开异步线程加载（比如常用的第三方：SDWebImage，YYWebImage等），线程开过多了会造成资源浪费，内存开销过大。cellForRow方法中我们可以做手脚滚动过程中不加载图片（通过tableview的dragging和declearating两个状态判断或者使用runloop），可以在scrollview的代理方法中做限制，当滚动开始减速的时候才加载显示在当前屏幕上的cell。
cellForRow限制方案：
方案一：

    - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
        UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"cell"];
    if (!cell) {
        cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"cell"];
    }
    
    /*** 装配cell其他基础数据 ***/
    
    /// 处理图片
    if (iconImage) {// 有缓存
        cell.imageView.image = iconImage;
    } else {
        if (!tableView.dragging && !tableView.decelerating) {
            /*
            loadImageWithIndexPath：这里要做的事：
            1.下载图片并缓存
            2.切到主线程展示cell图片 (UITableViewCell *cell = [self.tableView cellForRowAtIndexPath:indexPath];定位cell)
            */
            [self loadImageWithIndexPath:indexPath];
         }
    }
    
}

.
方案二：
方案一中的语句：

    if (!tableView.dragging && !tableView.decelerating) {
            /*
            loadImageWithIndexPath：这里要做的事：
            1.下载图片并缓存
            2.切到主线程展示cell图片 (UITableViewCell *cell = [self.tableView cellForRowAtIndexPath:indexPath];定位cell)
            */
            [self loadImageWithIndexPath:indexPath];
         }

.
替换为：

    /**
         runloop - 滚动时候 - trackingMode，
         - 默认情况 - defaultRunLoopMode
         ==> 滚动的时候，进入`trackingMode`，defaultMode下的任务会暂停
         停止滚动的时候 - 进入`defaultMode` - 继续执行`trackingMode`下的任务 - 例如这里的loadImage
    */
    [self performSelector:@selector(loadImageWithIndexPath:)
                   withObject:indexPath afterDelay:0.0
                      inModes:@[NSDefaultRunLoopMode]];

.
接下来是必写的scrollView方法：

//手放开了 - 停止拖动
- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate{

    if(!decelerate){
        //直接停止-无动画
        [self loadVisibleCellImage];
    }
}

//是否有动画效果
- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView {
    [self loadVisibleCellImage];
}

.
这里面loadVisibleCellImage方法核心语句为：

    //拿到界面内-所有的cell的indexpath
    NSArray *visableCellIndexPaths = self.tableView.indexPathsForVisibleRows;
    for (NSIndexPath *indexPath in visableCellIndexPaths) {
        [self loadImageWithIndexPath:indexPath];
    }

4.Instruments界面的流畅度检验这个网上太多了，可以参考这篇：https://www.jianshu.com/p/5182234b2e1c
这里提一嘴Color Hits Green and Misses Red等检测早就移到Xcode里了，路径如下，看见网上很多云文章还是在Instruments找感觉奇怪。

15535697613915.jpg

5.离屏渲染等问题日后整理...

参考文章：
https://www.jianshu.com/p/04457377b48d
https://www.jianshu.com/p/5182234b2e1c