UITableView性能优化汇总

一. Cell重⽤用

1. 数据源⽅方法优化

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

在可⻅的⻚⾯会重复绘制⻚⾯，每次刷新显示都会去创建新的Cell，非常耗费性能。

解决⽅案:

⾸先创建⼀个静态变量reuseID(代理方法返回Cell会调⽤用很多次，防⽌重复创建，static保证只会被创建⼀次，提⾼性能)，然后，从缓存池中取相应 identifier的Cell并更新数据，如果没有，才开始alloc新的Cell，并用identifier标识 Cell。每个Cell都会注册⼀个identifier(重用标识符)放⼊入缓存池，当需要调⽤的时候就直接从缓存池里找对应的id，当不需要时就放入缓存池等待调⽤。(移出屏幕的 Cell才会放⼊入缓存池中，并不不会被release)所以在数据源⽅法中做出如下

优化:

staticNSString*reuseID = “reuseCellID”;// 缓存池中取已经创建的cellUITableViewCell*cell = [tableView dequeueReusableCellWithIdentifier:reuseID];

2. 缓存池的实现

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

3. 缓存池获取可重用Cell两个⽅法的区别

-(nullable__kindofUITableViewCell*)dequeueReusableCellWithIdentifier: (NSString*)identifier;这个⽅法会查询可重⽤用Cell，如果注册了原型Cell，能够查询到，否则，返回nil;⽽且需要判断if(cell ==nil)，才会创建Cell，不推荐-(__kindofUITableViewCell*)dequeueReusableCellWithIdentifier:(NSString*)identifier forIndexPath:(NSIndexPath*)indexPathNS_AVAILABLE_IOS(6_0);使⽤这个⽅法之前，必须通过xib(storyboard)或是Class(纯代码)注册可重⽤用 Cell，⽽而且这个方法⼀定会返回一个Cell//注册Cell- (void)registerNib:(nullableUINib*)nib forCellReuseIdentifier:(NSString*)identifierNS_AVAILABLE_IOS(5_0);- (void)registerClass:(nullableClass)cellClass forCellReuseIdentifier:(NSString*)identifierNS_AVAILABLE_IOS(6_0);

好处:

如果缓冲区 Cell 不存在，会使用原型 Cell 实例例化⼀个新的 Cell，不需要再判断，同时代码结构更清晰。

二. 定义⼀种(尽量少)类型的Cell及善⽤hidden隐藏(显示)subviews

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. 善用hidden隐藏(显示)subviews

只定义⼀种Cell，那该如何显示不同类型的内容呢?

答案就是，把所有不同类型的 view都定义好，放在cell⾥⾯，通过hidden显示、隐藏，来显示不同类型的内容。毕竟，在⽤户快速滑动中，只是单纯的显示、隐藏subview比实时创建要快得多。

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

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

解决⽅案:

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

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

遇到⽐较复杂的界⾯面的时候，如复杂点的图文混排，上⾯的那种优化行高的⽅式可

能就不能满⾜要求了，当然了，由于我的开发经验尚短，说实话，还没遇到要将⾃定义的Cell重新绘制

五.滑动时，按需加载

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

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

六.缓存View

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

七.避免⼤量的图片缩放、颜⾊渐变等，尽量显示“大⼩刚好合适的图片资源”

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

九.渲染

1. 减少subviews的个数和层级

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

2. 少⽤用subviews的透明图层

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

3. 避免CALayer特效(shadowPath) 给Cell中View加阴影会引起性能问题，如下面代码会导致滚动时有明显的卡顿:

view.layer.shadowColor = color.CGColor;

view.layer.shadowOffset = offset;

view.layer.shadowOpacity = 1;

view.layer.shadowRadius = radius;