1. Cell重用
- 数据源方法优化
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;
在可见的页面会重复绘制页面，每次刷新显示都会去创建新的 Cell，非常耗费性能。
解决方案：首先创建一个静态变量 reuseID（代理方法返回 Cell 会调用很多次，防止重复创建，static 保证只会被创建一次，提高性能），然后，从缓存池中取相应 identifier 的Cell并更新数据，如果没有，才开始 alloc 新的 Cell，并用 identifier 标识 Cell。每个 Cell 都会注册一个 identifier（重用标识符）放入缓存池，当需要调用的时候就直接从缓存池里找对应的 id，当不需要时就放入缓存池等待调用。（移出屏幕的 Cell 才会放入缓存池中，并不会被 release）所以在数据源方法中做出如下优化：
// 调用次数太多，static 保证只创建一次 reuseID，提高性能
static NSString *reuseID = “reuseCellID”;
// 缓存池中取已经创建的 cell
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:reuseID];
-
缓存池的实现
当 Cel l要 alloc 时，UITableView 会在堆中开辟一段内存以供 Cell 缓存之用。Cell 的重用通过 identifier 标识不同类型的 Cell ，由此可以推断出，缓存池外层可能是一个可变字典，通过key来取出内部的 Cell，而缓存池为存储不同高度、不同类型（包含图片、Label 等）的 Cell，可以推断出缓存池的字典内部可能是一个可变数组，用来存放不同类型的 Cell，缓存池中只会保存已经被移出屏幕的不同类型的 Cell。 -
缓存池获取可重用Cell两个方法的区别
-(nullable __kindof UITableViewCell *)dequeueReusableCellWithIdentifier:(NSString *)identifier;
这个方法会查询可重用Cell，如果注册了原型Cell，能够查询到，否则，返回nil；而且需要判断if（cell == nil），才会创建Cell，不推荐
-(__kindof UITableViewCell *)dequeueReusableCellWithIdentifier:(NSString *)identifier forIndexPath:(NSIndexPath *)indexPath NS_AVAILABLE_IOS(6_0);
使用这个方法之前，必须通过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);
好处：如果缓冲区 Cell 不存在，会使用原型 Cell 实例化一个新的 Cell，不需要再判断，同时代码结构更清晰。
2. 定义一种(尽量少)类型的 Cell 及善用 hidden 隐藏(显示) subviews
-
一种类型的 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 的实例，虽然可能并不会占用太多内存，但是能少点不是更好吗。
-
善用 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（数据模型）只负责处理数据。
4 异步绘制（自定义 Cell 绘制）
遇到比较复杂的界面的时候，如复杂点的图文混排，上面的那种优化行高的方式可能就不能满足要求了，当然了，由于我的开发经验尚短，说实话，还没遇到要将自定义的 Cell 重新绘制
5 滑动时，按需加载
开发的过程中，自定义 Cell 的种类千奇百怪，但 Cell 本来就是用来显示数据的，不说 100%带有图片，也差不多，这个时候就要考虑，下滑的过程中可能会有点卡顿，尤其网络不好的时候，异步加载图片是个程序员都会想到，但是如果给每个循环对象都加上异步加载，开启的线程太多，一样会卡顿，我记得好像线程条数一般 3-5 条，最多也就 6 条吧。这个时候利用 UIScrollViewDelegate 两个代理方法就能很好地解决这个问题。
- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate
- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView
6.缓存View
当 Cell 中的部分 View 是非常独立的，并且不便于重用的，而且 体积 非常小，在内存可控的前提下，我们完全可以将这些view缓存起来。当然也是缓存在模型中。
7.避免大量的图片缩放、颜色渐变等，尽量显示“大小刚好合适的图片资源”
8.避免同步的从网络、文件获取数据，Cell 内实现的内容来自 web，使用异步加载，缓存请求结果
9.渲染
- 减少 subviews 的个数和层级子控件的层级越深，渲染到屏幕上所需要的计算量就越大；如多用 drawRect 绘制元素，替代用 view 显示
- 少用 subviews 的透明图层对于不透明的 View，设置 opaque 为 YES，这样在绘制该 View时，就不需要考虑被View覆盖的其他内容（尽量设置 Cell 的 view 为 opaque，避免 GPU 对 Cell下面的内容也进行绘制）
- 避免CALayer特效（shadowPath）给Cell中View加阴影会引起性能问题，如下面代码会导致滚动时有明显的卡顿：
view.layer.shadowColor = color.CGColor;
view.layer.shadowOffset = offset;
view.layer.shadowOpacity = 1;
view.layer.shadowRadius = radius;
网友评论