iOS - 使用tableView的性能优化总结.

前提假定使用的是情况比较复杂的动态行高的列表.非动态的也同理. 这里都是概括一些提供思路,解决方案其它博客很多了.

尽量少计算,所有需要的素材/数据提前计算好.

因为tableView的数据源方法在滑动过程中一直在调用,所以有关 *** 数据计算/控件调整/布局计算/文本计算 *** 等CPU消耗的都尽量不要在返回cell的代理方法中出现.yibu

控件调整: 例如朋友圈中有的cell是9个图片有的是一两个图片.正确的做法是每个cell都提前创建好9个UIImageView,根据图片数量设置hidden. 而不是有的创建一个,有的创建9个.而且还要设置frame.这样滑动起来布局计算和控件调整都很多
布局计算: 例如根据文本多少不同高度的Label,图片..要提前计算好布局，在需要时一次性调整好对应属性，而不要多次、频繁的计算和调整这些属性。
Autolayout: 虽然会提高开发的效率.但是因为要计算布局,尤其是在控件比较多的情况下CPU的消耗呈指数级上升.不过除非某个界面对性能特别敏感,Autolayout也是可选的.
开启子线程..Core graphics 可以在异步中绘制..一些复杂的计算等,开启线程是一种让界面流畅的方式.

cell中图像的圆角,渲染方式.

iOS 9.0 系统前不要使用maskbounds切圆
图片的misaligned和透明等,参照上一篇图片的性能优化.

cell中控件层次越少越好,数量越少越好.

比方说layer与UIView的选择. 高性能Label与UILabel
栅格化也是降低层级的方法
用Storyboard创建的控件比代码创建的资源消耗要高
比方说朋友圈里的九张图片,用UIImageView就比UICollectionView节省很多的资源消耗

缓存行高

这是对列表性能优化可以说最有效的一种方法

// 此方法在调用的时候会调用代理方法,如果没有的话就会找到cell,按照自动布局的规则自上而下计算,找到向下的约束,从而动态计算行高,降低性能. 
let cell = tableView.dequeueReusableCell(withIdentifier: "cellID")

所以实现
func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat是很有必要的,并且这个行高要从已经赋值好的视图模型里取,而不是每次取每次计算.
并且还要去掉self.tableView.rowHeight = UITableViewAutomaticDimension`

 override func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
        let xxViewModel = xxViewModel[indexPath.row]
        return xxViewModel.rowHeight
 }

viewModel中的rowHeight在获取到网络数据之后计算一次即保存到了内存当中..不会重复计算

离屏渲染与栅格化.(高级优化,流畅了不需要用)

在多数情况下,离屏渲染会在GPU于CPU之前来回切换会造成大量的消耗.增加耗电量..触发和避免离屏渲染的地方已经众所周知了..但是离屏渲染这个机制本身是一个优化设计,如何正确的用上它一次呢? -> shouldRasterize = true (栅格化)
栅格化: 开启之后GPU会对离屏渲染的部分进行缓存复用(如果图像内容没有动态变化),可以理解为把内容画成了一个图像保存在内存中供下次出现的时候再用这个图像..并且因为滑动时候使用的是一张图像,图层的结构层次会相当于只有一层.会明显的提升帧率.
所以 ,对于发生离屏渲染的cell,并且会因为滑动重复出现的情况,使用栅格化可以有效的优化性能提高帧率..前提 ,** 视图的内容不是动态变化的** ,否则因为栅格化生成的图像除了耗费性能毫无意义.
*** 还需要设置 layer.rasterizationScale ***为屏幕的分辨率,不然会出现模糊的情况.

  layer.shouldRasterize = true
  layer.rasterizationScale = UIScreen.main.scale