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 会有两种颜色：一种是洋红色，另一种是黄色。
洋红色是因为像素没对齐，比如上面的 label，一般情况下因为像素没对齐，需要抗锯齿，图像会出现模糊的现象。
解决办法：在设置 view 的 frame 时，在高分屏避免出现 21.3，6.7这样的小数，尤其是 x，y坐标，用 ceil 或 floor 或 round 取整。每 0.5 个点对应一个 pixel，0.3,0.7这样的就难为 iPhone 了，低分屏不要出现小数。黄色是因为显示的图片实际大小与显示大小不同，对图片进行了拉伸，测试显示使用 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
