UITableView的性能优化,提升列表滚动的流畅性

原文:UITableView的性能优化,提升列表滚动的流畅性

本篇博客目的是:总结UITableView性能优化方向,有些优化方式是我在开发中使用到过的,有些是没有用到过的,当中也有参考、查看很多大神的总结,这才有了本篇博客,仅供大家参考!

1.Cell重用

1.1>数据源方法优化

-(UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath;

在可见的页面会重复绘制页面,每次刷新显示都会去创建新的Cell,非常耗费性能。

解决方案:首先创建一个静态变量reuseID(代理方法返回Cell会调用很多次,防止重复创建,static保证只会被创建一次,提高性能),然后,从缓存池中取相应identifier的Cell并更新数据,如果没有,才开始alloc新的Cell,并用identifier标识Cell。每个Cell都会注册一个identifier(重用标识符)放入缓存池,当需要调用的时候就直接从缓存池里找对应的id,当不需要时就放入缓存池等待调用。(移出屏幕的Cell才会放入缓存池中,并不会被release)所以在数据源方法中做出如下优化:

// 调用次数太多,static 保证只创建一次reuseID,提高性能

staticNSString*reuseID = “reuseCellID”;

// 缓存池中取已经创建的cell

UITableViewCell*cell = [tableView dequeueReusableCellWithIdentifier:reuseID];

1.2>缓存池的实现

当Cell要alloc时,UITableView会在堆中开辟一段内存以供Cell缓存之用。Cell的重用通过identifier标识不同类型的Cell,由此可以推断出,缓存池外层可能是一个可变字典,通过key来取出内部的Cell,而缓存池为存储不同高度、不同类型(包含图片、Label等)的Cell,可以推断出缓存池的字典内部可能是一个可变数组,用来存放不同类型的Cell,缓存池中只会保存已经被移出屏幕的不同类型的Cell。

1.3>缓存池获取可重用Cell两个方法的区别

-(nullable__kindofUITableViewCell*)dequeueReusableCellWithIdentifier:(NSString*)identifier;

这个方法会查询可重用Cell,如果注册了原型Cell,能够查询到,否则,返回nil;而且需要判断if(cell == nil),才会创建Cell,不推荐

-(__kindofUITableViewCell*)dequeueReusableCellWithIdentifier:(NSString*)identifier forIndexPath:(NSIndexPath*)indexPath NS_AVAILABLE_IOS(6_0);

使用这个方法之前,必须通过xib(storyboard)或是Class(纯代码)注册可重用Cell,而且这个方法一定会返回一个Cell

注册Cell

-(void)registerNib:(nullableUINib*)nib forCellReuseIdentifier:(NSString*)identifier NS_AVAILABLE_IOS(5_0);

-(void)registerClass:(nullableClass)cellClass forCellReuseIdentifier:(NSString*)identifier NS_AVAILABLE_IOS(6_0);

好处:如果缓冲区 Cell 不存在,会使用原型 Cell 实例化一个新的 Cell,不需要再判断,同时代码结构更清晰。

2. 定义一种(尽量少)类型的Cell及善用hidden隐藏(显示)subviews

2.1>一种类型的Cell

分析Cell结构,尽可能的将

相同内容的抽取到一种样式Cell中,前面已经提到了Cell的重用机制,这样就能保证UITbaleView要显示多少内容,真正创建出的Cell可能只比屏幕显示的Cell多一点。虽然Cell的’体积’可能会大点,但是因为Cell的数量不会很多,完全可以接受的。好处:

减少代码量,减少Nib文件的数量,统一一个Nib文件定义Cell,容易修改、维护

基于Cell的重用,真正运行时铺满屏幕所需的Cell数量大致是固定的,设为N个。所以如果如果只有一种Cell,那就是只有N个Cell的实例;但是如果有M种Cell,那么运行时最多可能会是M x N 个Cell的实例,虽然可能并不会占用太多内存,但是能少点不是更好吗。

2.2>善用hidden隐藏(显示)subviews

只定义一种Cell,那该如何显示不同类型的内容呢?答案就是,把所有不同类型的view都定义好,放在cell里面,通过hidden显示、隐藏,来显示不同类型的内容。毕竟,在用户快速滑动中,只是单纯的显示、隐藏subview比实时创建要快得多。

3. 提前计算并缓存Cell的高度

iOS中,不设UITableViewCell的预估行高的情况下,会优先调用”tableView:heightForRowAtIndexPath:”方法,获取每个Cell的即将显示的高度,从而确定UITableView的布局,实际就是要获取contentSize(UITableView继承自UIScrollView,只有获取滚动区域,才能实现滚动),然后才调用”tableView:cellForRowAtIndexPath”,获取每个Cell,进行赋值。如果项目中模块有10000个Cell需要显示,可想而知…

解决方案:我个人认为,可以创建一个frame模型,提前计算每个Cell的高度。参考其中一篇博客的时候,在解决这个问题的时候,可以将计算Cell的高度放入数据模型,但这与MVC设计模式可能稍微有点冲突,这个时候我就想到MVVM这种设计模式,这个时候才能稍微有点MVVM这种设计模式的优点(其实还是很不理解的),可以讲计算Cell高度放入ViewModel(视图模型)中,让Model(数据模型)只负责处理数据。

在上面的基础上,还可以继续进行优化,提前创建真正显示的、需要加工的数据并缓存。不过这方面优化我好像之前没有接触。大家可以去看看这篇博客,其实本篇性能优化也借鉴了好多这篇文章,这是土土大神的博客地址,大家可以进去看看,好多iOS开发的知识,当然也有我参照的这篇博客。http://tutuge.me

4.异步绘制(自定义Cell绘制)

遇到比较复杂的界面的时候,如复杂点的图文混排,上面的那种优化行高的方式可能就不能满足要求了,当然了,由于我的开发经验尚短,说实话,还没遇到要将自定义的Cell重新绘制。至于这方面,大家可以参考这篇博客,绝对是开发经验十足的大神,分享足够多的UITableView方面的性能优化,好多借鉴自这里,我都不好意思了。http://www.cocoachina.com/ios/20150602/11968.html

5.滑动时,按需加载

开发的过程中,自定义Cell的种类千奇百怪,但Cell本来就是用来显示数据的,不说100%带有图片,也差不多,这个时候就要考虑,下滑的过程中可能会有点卡顿,尤其网络不好的时候,异步加载图片是个程序员都会想到,但是如果给每个循环对象都加上异步加载,开启的线程太多,一样会卡顿,我记得好像线程条数一般3-5条,最多也就6条吧。这个时候利用UIScrollViewDelegate两个代理方法就能很好地解决这个问题。

-(void)scrollViewDidEndDragging:(UIScrollView*)scrollView willDecelerate:(BOOL)decelerate

-(void)scrollViewDidEndDecelerating:(UIScrollView*)scrollView

思想就是识别UITableView禁止或者减速滑动结束的时候,进行异步加载图片,快滑动过程中,只加载目标范围内的Cell,这样按需加载,极大的提高流畅度。而SDWebImage可以实现异步加载,与这条性能配合就完美了,尤其是大量图片展示的时候。而且也不用担心图片缓存会造成内存警告的问题。

//获取可见部分的Cell

NSArray*visiblePaths = [self.tableViewindexPathsForVisibleRows];

for(NSIndexPath*indexPath in visiblePaths)      

{

      //获取的dataSource里面的对象,并且判断加载完成的不需要再次异步加载       

}

记得在记得在“tableView:cellForRowAtIndexPath:”方法中加入判断:

// tableView 停止滑动的时候异步加载图片

- (UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath{

    if(self.tableView.dragging==NO&&self.tableView.decelerating==NO) {         

        //开始异步加载图片

    } 

}

6.缓存View

当Cell中的部分View是非常独立的,并且不便于重用的,而且“体积”非常小,在内存可控的前提下,我们完全可以将这些view缓存起来。当然也是缓存在模型中。

7.避免大量的图片缩放、颜色渐变等,尽量显示“大小刚好合适的图片资源”

8.避免同步的从网络、文件获取数据,Cell内实现的内容来自web,使用异步加载,缓存请求结果

9.渲染

9.1>减少subviews的个数和层级

子控件的层级越深,渲染到屏幕上所需要的计算量就越大;如多用drawRect绘制元素,替代用view显示

9.2>少用subviews的透明图层

对于不透明的View,设置opaque为YES,这样在绘制该View时,就不需要考虑被View覆盖的其他内容(尽量设置Cell的view为opaque,避免GPU对Cell下面的内容也进行绘制)

9.3>避免CALayer特效(shadowPath)

给Cell中View加阴影会引起性能问题,如下面代码会导致滚动时有明显的卡顿:

view.layer.shadowColor= color.CGColor;

view.layer.shadowOffset= offset;

view.layer.shadowOpacity=1;

view.layer.shadowRadius= radius;

总结:UITableView的优化主要从三个方面入手:

提前计算并缓存好高度(布局),因为heightForRowAtIndexPath:是调用最频繁的方法;(这个是开发中肯定会要优化的,不可能一个app就几个Cell吧)

滑动时按需加载,防止卡顿,这个我也认为是很有必要做的性能优化,配合SDWebImage

异步绘制,遇到复杂界面,遇到性能瓶颈时,可能就是突破口(如题,遇到复杂的界面,可以从这入手)

缓存一切可以缓存的,这个在开发的时候,往往是性能优化最多的方向

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,829评论 1 331
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,603评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,846评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,600评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,780评论 3 272
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,695评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,136评论 2 293
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,862评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,453评论 0 229
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,942评论 2 233
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,347评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,790评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,293评论 3 221
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,839评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,448评论 0 181
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,564评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,623评论 2 249

推荐阅读更多精彩内容