UITableView性能优化,超实用

1. Cell重用

   1.1>数据源方法优化

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

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

// 调用次数太多,static 保证只创建一次reuseID,提高性能
static NSString *reuseID = “reuseCellID”;
 
 
  • 1
  • 2
  • 1
  • 2
// 缓存池中取已经创建的cell
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:reuseID];
 
 
  • 1
  • 2
  • 1
  • 2

   1.2>缓存池的实现

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

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

-(nullable __kindof UITableViewCell *)dequeueReusableCellWithIdentifier:(NSString *)identifier; 
 
 
  • 1
  • 1

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

-(__kindof UITableViewCell *)dequeueReusableCellWithIdentifier:(NSString *)identifier forIndexPath:(NSIndexPath *)indexPath NS_AVAILABLE_IOS(6_0);
 
 
  • 1
  • 1

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

注册Cell

- (void)registerNib:(nullable UINib *)nib forCellReuseIdentifier:(NSString *)identifier NS_AVAILABLE_IOS(5_0);
- (void)registerClass:(nullable Class)cellClass forCellReuseIdentifier:(NSString *)identifier NS_AVAILABLE_IOS(6_0);
 
 
  • 1
  • 2
  • 1
  • 2

好处:如果缓冲区 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 = MN”个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
 
 
  • 1
  • 2
  • 1
  • 2

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

//获取可见部分的Cell
NSArray *visiblePaths = [self.tableView indexPathsForVisibleRows];
        for (NSIndexPath *indexPath in visiblePaths)
        {
        //获取的dataSource里面的对象,并且判断加载完成的不需要再次异步加载
             <code>
        }
 
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

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

// tableView 停止滑动的时候异步加载图片
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

         if (self.tableView.dragging == NO && self.tableView.decelerating == NO)
            {
               //开始异步加载图片
                <code>
            }
 
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

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;
 
 
  • 1
  • 2
  • 3
  • 4
  • 1
  • 2
  • 3
  • 4

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

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

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

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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值