整理整合一些关于tableview优化

1.cell的重用

2.dequeueReusableCellWithIdentifier:forIndexPath:(会调用heightForRowAtIndexPath)和dequeueReusableCellWithIdentifier (后面这个不会再次调用heightForRowAtIndexPath)

2.1 tableView在cell显示之前会调用heightForRowAtIndexPath,有多少个cell就会调用多少次,算contentSize

2.2使用了预估行高,并不会在显示之前去计算获取所有的行高(预估行高,等cell要显示的时候才回去计算真实的高度),根据预估行高和实际行高来获取cell的行高,先根据预估行高计算好要先获取几个cell,如果计算的这几个cell高度确实够(高度能超出屏幕的高度就不计算了.如果不够还会计算),目的也是让contentSize大于屏幕,就能滚动,后面要显示,才来计算行高,所以会发现滚动条会跳

3.cell的高度是根据内容变化的时候,只计算一次,将高度缓存起来

overridefunctableView(tableView:UITableView, heightForRowAtIndexPath indexPath:NSIndexPath) ->CGFloat{

//获取模型

letstatus =self.statuses![indexPath.row]

//判断模型里面之前有没有缓存过行高

ifstatus.rowHeight!=nil

{

//之前保存过行高,直接返回行高

returnstatus.rowHeight!

}

//自己计算行高:AutoLayout自动约束

//让cell设置对应内容,可以直接直接获取,这个cell不参与显示

letcell = tableView.dequeueReusableCellWithIdentifier(ReuseIndentifier)as!HMStatusCell

cell.status= status

letheight = cell.systemLayoutSizeFittingSize(UILayoutFittingCompressedSize).height

status.rowHeight= height

returnheight

}

4.下载图片使用SDWebImage(异步操作)

5.cellForRowAtIndexPath不要做耗时操作

1.读取文件,写入文件,最好是放到子线程,或先读取好,在让tableView去显示

2.尽量不要再这个方法里解压资源

3.尽量少得计算计算,最好是先计算好,cellForRowAtIndexPath只做显示

4.尽量不要去添加和移除view,现将会用到的控件懒加载,要就显示,不要就隐藏

6.tableView滚动的时候,不要去做动画(微信的聊天界面做的就很好,在滚动的时候,动态图就不让他动,滚动停止的时候才动,不然可能会有点影响流畅度)

7.cell里面的控件,约束最好不要使用remake,动态添加约束是比较耗性能的

8.cell里面的控件,背景最好是不透明的(图层混合靠GPU去渲染,会影响性能,绿色的好,红色的性能差), view的背景颜色clearColor尽量少

9.图片圆角不要使用layer.cornerRadius,因为通过图层去渲染的话都会影响性能

10.图层最好不要使用阴影,阴影会导致离屏渲染(在进入屏幕渲染之前,还看不到的时候会再渲染一次,尽量不要产生离屏渲染)

11.异步绘制

12.栅格化

13.借助工具来测试性能

14.AsyncDisplayKit ->不使用UIKit (UIView) ->  (Node)

总结:

设置统一规格的Cell, 其子控件的显示隐藏可以根据模型中不同的数据在代码里面动态控制就好;在iOS中,系统是先调用“tableView:heightForRowAtIndexPath:”获取每个Cell即将显示的高度,确定整个UITableView的布局。然后才调用“tableView:cellForRowAtIndexPath”获取Cell。因此,使用了ViewModel来保存UI信息,Cell高度的计算和使用的时机需要特别留意。

提前处理Cell需要显示的数据资源;在Cell显示之前,将从服务器加载获取到的原始数据在ViewModel中进行提前处理,一般包括图片的加载和压缩、富文本的多样化显示(NSString->NSAttributeString)。

另外还有些更为极致的一些方式和操作细节也就不深入展开了,大致整合一下。

Cell中的view尽可能不要使用透明

减少子视图的层级关系

图片载入在后台进程进行,滚出可视范围的载入进程cancel掉

图片资源尽可能使用PNG

2.图片异步下载,异步解码,缓存解码结果。

6.不要绘制圆角、阴影,尽量用图片来替换。总之一句话,能异步不要同步,能用gpu不要用cpu。

用 “空间换时间”

将计算行高的时间提前到从服务器搂回数据的时候,计算完了高度一并写回数据库,别告诉我你在主线程里阻塞式的处理网络请求。。。。面壁思过去吧,别浪费了 GCD,NSOperationQueue的青春。最先想到的还是 NSThread 的同学,证明你已经老了。。。现在几乎大部分的多线程操作都不需要用到 NSThread 和 runloop了。

调试应用性能一定要用真机,Mac 的性能完爆 iPhone,所有不要说我的应用在模拟器上调试时不卡啊!模拟器只能模拟 iOS 软件的运行环境,不能模拟硬件性能!

UITableView性能优化-一次面试后的反思总结


面试的时候遇到这个问题,竟一时没有全答上来,于是Google了一下,常见的一些譬如Cell重用、设计统一Cell、缓存Cell高度,Cell数据资源缓存,这些其实平时都在用,但因为平时还是缺乏总结,回答这么个问题的时候却只想到说“==重用==”、“==缓存==”,道理你都懂,但这样极度概括的答案在面试过程中并不是什么好答案,深有体会~

另外,也有自己平时很少用而想不起来的,就是性能要求更高一些的话Cell中用到的视图控件可以尽可能自行drawRect。

面试结果也未可知,便先吃一堑长一智,趁热将其总结总结。

Cell重用机制

这是TableView的基本使用,仅作简单归纳。

[tableView dequeueReusableCellWithIdentifier:(NSString)identifier forIndexPath:(NSIndexPath)indexPath];

使用这个方法需要提前注册Cell到对应的tableView:

1、Stroyboard: 定义Cell的Prototype,并设置其Reusable Identifier

这里值得一提的是:Cell的Prototype最好高度抽象统一,越少越好,因为每个不同的Prototype都有其对应的Cell重用池,创建的Cell就越多,重用效率也就越低。(详见以下设计统一规格的Cell)

2、Xib自定义:

[registerNib:(nullable UINib)nib forCellReuseIdentifier:(NSString)identifier];

3、代码自定义:

[registerClass:(nullable Class)cellClass forCellReuseIdentifier:(NSString *)identifier];

设计统一规格的Cell

统一Cell的规格,不仅能减少设计不同Cell所需要代码量和nib文件,更重要的是能提高Cell的重用率,提升TableView整体性能。

等高的Cell好设计,显示不同数据就可以了,无须多费篇幅。

动态计算高度的Cell也应该统一设计,比如下面这个赤兔的例子


创建ViewModel,计算并储存Cell的UI尺寸信息

@interface BYTweetViewModel : NSObject

@property(strong, nonatomic) BYTweetModel *dataModel; //原始数据模型

@property(assign, nonatomic) CGFloat cellHeight; //Cell 高度

(void)calculateCellHeight; //计算高度

@end

这里有个坑需要注意:

在iOS中,系统是先调用“tableView:heightForRowAtIndexPath:”获取每个Cell即将显示的高度,确定整个UITableView的布局。然后才调用“tableView:cellForRowAtIndexPath”获取Cell。因此,使用了ViewModel来保存UI信息,Cell高度的计算和使用的时机需要特别留意。

提前处理Cell需要显示的数据资源

在Cell显示之前,将从服务器加载获取到的原始数据在ViewModel中进行提前处理,一般包括图片的加载和压缩、富文本的多样化显示(NSString->NSAttributeString)。

这时ViewModel可能会是这样

@interface BYTweetViewModel : NSObject

@property(strong, nonatomic) BYTweetModel *dataModel; //原始数据模型

@property(assign, nonatomic) CGFloat cellHeight; //Cell 高度

//需要显示的数据内容

@property(strong, nonatomic) NSAttributeString *titleToShow;

@property(strong, nonatomic) NSAttributeString *contentToShow;

(void)calculateCellHeight; //计算高度

(void)handleSourceDataModel;

@end

其它

我了解的,也是常用的方案基本是以上几种了,总之呢,还是可以回到我面试时候的高度概括,尽可能“重用”、“缓存”,用空间换取时间。

另外还有些更为极致的一些方式和操作细节也就不深入展开了,大致整合一下。

Cell中的view尽可能不要使用透明

减少子视图的层级关系

图片载入在后台进程进行,滚出可视范围的载入进程cancel掉

图片资源尽可能使用PNG

……

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

推荐阅读更多精彩内容