TableView滑动时候出现的卡顿现象

分析

UITableView是UIScrollView的子类,因此它可以自动响应滚动事件(一般为上下滚动)。

它内部包含0到多个UITableViewCell对象,每个table
cell展示各自的内容。当新cell需要被显示时,就会调用tableView:cellForRowAtIndexPath:方法来获取或创建一个cell;而不可视时,它又会被释放。由此可见,同一时间其实只需要存在一屏幕的cell对象即可,不需要为每一行创建一个cell。

此外,UITableView还可以分为多个sections,每个区段都可以有自己的head、foot和cells。而在定位一个cell时,就需要2 个字段了:在哪个section,以及在这个section的第几行。这在iOS
SDK中是用NSIndexPath来表述的,UIKit为其添加了indexPathForRow:inSection:这个创建方法。

其他诸如编辑之类的就不提了,因为和本文无关。

介绍完原理,接下来就开始优化吧。

1.    使用不透明视图。

不透明的视图可以极大地提高渲染的速度。因此如非必要,可以将table cell及其子视图的opaque属性设为YES(默认值)。

其中的特例包括背景色,它的alpha值应该为1(例如不要使用clearColor);图像的alpha值也应该为1,或者在画图时设为不透明。

2.    不要重复创建不必要的table cell。

前面说了,UITableView只需要一屏幕的UITableViewCell对象即可。因此在cell不可见时,可以将其缓存起来,而在需要时继续使用它即可。

而UITableView也提供了这种机制,只需要简单地设置一个identifier即可:

static NSString *CellIdentifier [email protected]"xxx";
UITableViewCell *cell = [tableView
dequeueReusableCellWithIdentifier:CellIdentifier];if(cell == nil) { cell
= [[[UITableViewCell alloc]initWithStyle:UITableViewCellStyleDefault
reuseIdentifier:CellIdentifier]autorelease];
}

值得一提的是,cell被重用时,它内部绘制的内容并不会被自动清除,因此你可能需要调用setNeedsDisplayInRect:或setNeedsDisplay方法。

此外,在添加table cell的时候,如果不需要动画效果,最好不要使用insertRowsAtIndexPaths:withRowAnimation:方法,而是直接调用reloadData方法。因为前者会对所有indexPaths调用tableView:cellForRowAtIndexPath:方法,即便该
cell并不需要显示(不知道是不是bug),这就可能创建大量多余的cell。勘误:只是在模拟器上测试如此,真机调试时没有这种bug。

3.    减少视图的数目。

UITableViewCell包含了textLabel、detailTextLabel和imageView等view,而你还可以自定义一些视图放在它的contentView里。然而view是很大的对象,创建它会消耗较多资源,并且也影响渲染的性能。

如果你的table cell包含图片,且数目较多,使用默认的UITableViewCell会非常影响性能。奇怪的是,使用自定义的view,而非预定义的view,明显会快些。

当然,最佳的解决办法还是继承UITableViewCell,并在其drawRect:中自行绘制:

- (void)drawRect:(CGRect)rect { if(image)
{ [image drawAtPoint:imagePoint]; self.image = nil; } else
{[placeHolder drawAtPoint:imagePoint]; } [text drawInRect:textRect
withFont:fontlineBreakMode:UILineBreakModeTailTruncation];
}

不过这样一来,你会发现选中一行后,这个cell就变蓝了,其中的内容就被挡住了。最简单的方法就是将cell的selectionStyle属性设为UITableViewCellSelectionStyleNone,这样就不会被高亮了。

此外还可以创建CALayer,将内容绘制到layer上,然后对cell的contentView.layer调用addSublayer:方法。这个例子中,layer并不会显著影响性能,但如果layer透明,或者有圆角、变形等效果,就会影响到绘制速度了。解决办法可参见后面的预渲染图像。

4.    不要做多余的绘制工作。

在实现drawRect:的时候,它的rect参数就是需要绘制的区域,这个区域之外的不需要进行绘制。

例如上例中,就可以用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判断是否需要绘制image和text,然后再调用绘制方法。

5.    预渲染图像。

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

6.    不要阻塞主线程。

做到前几点后,你的table view滚动时应该足够流畅了,不过你仍可能让用户感到不爽。常见的现象就是在更新数据时,整个界面卡住不动,完全不响应用户请求。

出现这种现象的原因就是主线程执行了耗时很长的函数或方法,在其执行完毕前,无法绘制屏幕和响应用户请求。其中最常见的就是网络请求了,它通常都需要花费数秒的时间,而你不应该让用户等待那么久。

解决办法就是使用多线程,让子线程去执行这些函数或方法。这里面还有一个学问,当下载线程数超过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 *)cellforRowAtIndexPath:(NSIndexPath
*)indexPath { if (count - indexPath.row < 10&& !updating) {
updating = YES; [self update]; } }// update方法获取到结果后,设置updating为NO

还有一点要注意的就是当图片下载完成后,如果cell是可见的,还需要更新图像:

NSArray *indexPaths =
[self.tableViewindexPathsForVisibleRows];for (NSIndexPath
*visibleIndexPath in indexPaths) {if (indexPath == visibleIndexPath) {
MyTableViewCell *cell = (MyTableViewCell*)[self.tableView
cellForRowAtIndexPath:indexPath];
cell.image = image; [cellsetNeedsDisplayInRect:imageRect]; break; } }//
也可不遍历,直接与头尾相比较,看是否在中间即可。

最后还是前面所说过的insertRowsAtIndexPaths:withRowAnimation:方法,插入新行需要在主线程执行,而一次插入很多行的话(例如50行),会长时间阻塞主线程。而换成reloadData方法的话,瞬间就处理完了。

时间: 2024-10-08 00:30:00

TableView滑动时候出现的卡顿现象的相关文章

优化tableview的卡顿现象

1.复用单元格 2.使用不透明的视图,单元格中尽量少使用动画 3.图片加载使用异步加载,并且设置图片加载的并发数 4.滑动时不加载图片,停止滑动开始加载 5.文字图片可以直接drawInRect绘制 6.如非必要,减少reloadData全部cell,只reloadRowsAtIndexPaths 7.如果cell是动态行高,计算出高度后缓存 8.cell高度固定的话直接用cell.rowHeight设置高度

iOS之tableView性能优化/tableView滑动卡顿?

本文围绕以下几点展开tableView性能优化的论述? 1.UITableViewCell重用机制? 2.tableView滑动为什么会卡顿? 3.优化方法? 4.总结 1.UITableViewCell重用机制? UITableView只会创建一屏幕(或者一屏幕多一点)的cell,其他都是取出来重用的.每当cell滑出屏幕的时候,就会放到一个集合中,当要显示某一位置的cell时,会先去集合中取,有的话,就直接拿出来显示,没有在创建. 2.tableView滑动为什么会卡顿? cell赋值内容时

优化tableView性能(针对滑动时出现卡的现象)

优化tableView性能(针对滑动时出现卡的现象) 在iOS应用中,UITableView应该是使用率最高的视图之一了.iPod.时钟.日历.备忘录.Mail.天气.照片.电话.短信. Safari.App Store.iTunes.Game Center?几乎所有自带的应用中都能看到它的身影,可见它的重要性. 然而在使用第三方应用时,却经常遇到性能上的问题,普遍表现在滚动时比较卡,特别是table cell中包含图片的情况时. 实际上只要针对性地优化一下,这种问题就不会有了.有兴趣的可以看看

关于android textview,edittext,导致界面的卡顿

我们在平时使用textview和edittextview的时候总是很随意的编写它相应的xml,但是当你的界面中存在滑动之类的效果的时候如果你不注意,你可能会发现你的界面居然有时候会有很卡的感觉,具体为什么卡,卡在哪里我们往往摸不着头脑,明明一点耗时的操作都没有,界面就多了一句,textview的settex函数,怎么就卡的不成样了,我们有时候会去怀疑android 的机制没苹果的好.其实具体原因还在于我们对控件不够了解. 当一个界面里面存着类似scrollview或者listview这种控件的时

头部显示提示,如tableview滑动提示滑回顶部

头部显示提示,如tableview滑动提示滑回顶部 by 伍雪颖 就是在[[[UIApplication sharedApplication] delegate] window]添加要的内容: #import "TipsBar.h" @implementation TipsBar UILabel *tipsLabel; int width; + (void)showInView:(UIView *)view { width = view.frame.size.width; if (ti

iOS 如何解决UITableView刷新卡顿现象

对之前的项目总结一下: 事情是这样的,我需要在定制Cell完成新闻类app的展示 虽然说SDWebImage提供了一个方法,异步加载图片到UIImageView上 但是,有些时候.需要的图片并不是需要铺满UIImageView 于是就抛弃了,后来想想还是挺二逼的.我可以在下面在铺一层边框UIImageView也能达到这个效果 于是乎,故作高大上,非要自己写. 后来看别人的方法,找到点感觉,还是写出来了,不过还是建立在网络良好的情况下 解决办法 主要要做到一下几个方面: 1.除了UI部分,所有的加

ios tableview 滑动到底部

tableview滑动到底部,根据页面不同 可以有两种方法 第一种: 一般样式的tableview 没有头和尾的 #pragma mark - 滑到最底部 - (void)scrollTableToFoot:(BOOL)animated { NSInteger s = [self.tableView numberOfSections]; //有多少组 if (s<1) return; //无数据时不执行 要不会crash NSInteger r = [self.tableView numberO

[转] 设置div的overflow:scroll,但是在手机上滑动的时候有点卡顿

设置div的overflow:scroll,但是在手机上滑动的时候有点卡顿,所以在这个div上加一个css: -webkit-overflow-scrolling : touch; 在苹果手机上使用-webkit-overflow-scrolling:touch会导致使用固定定位的元素,随着页面一起滚动,只有滚动停止时才会恢复原位.如果不用这个属性的话,使用overflow-y:属性的盒子滑动非常不流畅, 解决方法: 使用overflow-y属性的元素不应该和固定元素在一个层级,使用overfl

是什么造成了数据库的卡顿

目录 一.背景 二.问题定界 三.找出元凶 四.解决思路 声明:本文同步发表于 MongoDB 中文社区,传送门: http://www.mongoing.com/archives/26201 一.背景 MongoDB 提供了非常强大的性能分析及监控的命令,诸如 mongostat.mongotop 可以让我们对数据库的运行态性能了如指掌. 然而,这次我们在性能环境上就遇到一个非常棘手的问题: 某服务接口在 1-5分钟内偶现超时导致业务失败! 在接口调用上返回超时属于前端的判断,通常是设置的一个