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