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
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
……