UITabelView 优化巧技

TableView优化

这篇可以说的阅读博客的笔记吧，主要是记录一些UITabelView的优化方法,对自己一些不知道的知识盲点 进行记录。

Delegate

tableView:cellForRowAtIndexPath:

在tableView:cellForRowAtIndexPath:中我们经常做如下的事情

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    NSString *identifier = @"CellIdentifier";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:identifier];
    if(cell == nil)
    {
        cell = [[UITableViewCell alloc]init........]
    }
    //然后进行一些Cell数据的绑定
    cell.Data = .......;
    cell.Data2 = ........;

    return cell;
}

其实这样做是一种比较低效的行为。
因为tableView:cellForRowAtIndexPath:这个方法需要为每个cell调用一次，它应该快速的执行。所以你需要尽快的返回重用的cell的实例。

不要在这里去执行数据绑定，因为目前在屏幕上还没有cell。为了执行数据绑定，可以在UITableView的delegate方法tableView:willDisplayCell:forRowAtIndexPath:中进行。这个方法在显示cell之前会被调用。
应该如下：

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    NSString *identifier = @"CellIdentifier";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:identifier];
    if(cell == nil)
    {
        cell = [[UITableViewCell alloc]init........];
    }

    return cell;
}

- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath{
    cell.Data = .....;
    cell.Data2 = ......;
}

tableView:heightForRowAtIndexPath:

尽量少调用高度方法
很多人都把优化的重点放到了 cell for row at indexpath 那个方法里了，在这里尽可能的少计算，但是却忽略了另一个很轻松就能提升加载时间的方法 ：

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath

Table View 在每次 reload data 时都会要所有 cell 的高度！这就是说你有一百行 cell，就像代理要100次每个cell 的高度，而不是当前屏幕显示的cell 的数量的高度！虽然在 iOS 7 下多了计算 cell 高度的方法，但是减少 计算高度时的时间，对于提升加载 Table View 的速度有非常明显的提高！

- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath
（**iOS 7专用**）

但是有人说了，我早听别人说了，reloadData 方法尽量不要调用，我插入新行都用 insertRowsAtIndexPaths:withRowAnimation: 删除也用 delete 那个，这个总行了吧？！

这样也不能忽略 height For Row At Index Path 这个回调的重要性。因为在每次插入或者删除一行后同样需要调用一遍 所有行 的这个回调方法！是所有行！你没看错，所有只是简单的减少一个代理方法的计算量，就可以明显的提升加载速度。

高度计算
很多人会犯一个错误，他们会在布局初始化cell实例并绑定数据后去获取它们的高度(就是等TableViewCell 所有的子view都布置好了之后再去获取高度)。但是这个很耗时。
因为这个方法也是每次都调用的，等布置好了子控件之后 要花费大量的时间。
应该尽量让这个方法的计算复杂度在O(1)。

传统的方法就是写一个计算高度的方法，把Data传进入然后计算高度。

更多优化

做到以上几点基本可以完成性能要求，当然如果你很追求完美还有其他优化方法。

使用不透明视图

不透明的视图可以极大地提高渲染的速度。因此如非必要，可以将table cell及其子视图的opaque属性设为YES（默认值）。
其中的特例包括背景色，它的alpha值应该为1（例如不要使用clearColor）；图像的alpha值也应该为1，或者在画图时设为不透明。

Misaligned images

对于 Misaligned images 会有两种颜色：一种是洋红色，另一种是黄色。

image.png

1. 洋红色是因为像素没对齐，比如上面的 label，一般情况下因为像素没对齐，需要抗锯齿，图像会出现模糊的现象。
   解决办法：在设置 view 的 frame 时，在高分屏避免出现 21.3，6.7这样的小数，尤其是 x，y坐标，用 ceil 或 floor 或 round 取整。每 0.5 个点对应一个 pixel，0.3,0.7这样的就难为 iPhone 了，低分屏不要出现小数。

2. 黄色是因为显示的图片实际大小与显示大小不同，对图片进行了拉伸，测试显示使用 image view 显示实际大小的图也会变黄。

减少洋红色和黄色可以提升滚动的流畅性

预渲染图像

你会发现即使做到了上述几点，当新的图像出现时，仍然会有短暂的停顿现象。解决的办法就是在bitmap context里先将其画一遍，导出成UIImage对象，然后再绘制到屏幕，详细做法可见《利用预渲染加速iOS设备的图像显示》

不要阻塞主线程

出现这种现象的原因就是主线程执行了耗时很长的函数或方法，在其执行完毕前，无法绘制屏幕和响应用户请求。其中最常见的就是网络请求了，它通常都需要花费数秒的时间，而你不应该让用户等待那么久。
解决办法就是使用多线程，让子线程去执行这些函数或方法。这里面还有一个学问，当下载线程数超过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

更多

我总结了一些简单的初步解决方案，这里还有一些高端的。
(http://www.cocoachina.com/ios/20160115/15001.html
http://www.cocoachina.com/industry/20140210/7792.html
http://www.cnblogs.com/pengyingh/articles/2354714.html