1-1. Cell重用
在可见页面每次刷新显示都会去创建新的Cell？
答：不是，这样非常耗费性能。
解决方案：
- static NSString *reuseID = “reuseCellID”; //代理方法返回Cell会调用很多次，防止重复创建，static保证只会被创建一次，提高性能
- UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:reuseID];//从缓存池中取相应identifier的Cell并更新数据，如果没有，才开始alloc新的Cell，并用identifier标识Cell。每个Cell都会注册一个identifier（重用标识符）放入缓存池，当需要调用的时候就直接从缓存池里找对应的id，当不需要时就放入缓存池等待调用。
备注：移出屏幕的Cell不会被release，会放入缓存池中。
1-2. 缓存池
UITableView什么时候开辟内存给Cell?
答：当Cell执行alloc时，UITableView会在堆中开辟一段内存以供Cell缓存之用。
缓存池会缓存所有Cell吗？
答：缓存池中只会保存已经被移出屏幕的不同类型的Cell。
Cell的重用通过identifier标识，缓存池是否一可变字典？
答：可能是，因为原理与字典相似，字典用key, cell重用以identifier。
Cell的类型多种多样，缓存池字典内部是什么呢？
答：可能是可变数组，也可能是可变的Set集合，因为只有数组，Set都可以存放不同高度、不同类型（包含图片、Label等）的Cell。Set还有存放数据的唯一性。
1-3. 缓存池获取可重用Cell两个方法的区别
第一种方式：
-(nullable __kindof UITableViewCell *)dequeueReusableCellWithIdentifier:(NSString *)identifier;
附上示例：
cell = [self.tableView dequeueReusableCellWithIdentifier:kDisplayCell_ID];
if(cell == nil)
{
cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:kDisplayCell_ID]];
}
这个方法会查询可重用Cell，如果注册了原型Cell，能够查询到，否则，返回nil；而且需要判断if（cell == nil），才会创建Cell，不推荐
第二种方式：
-(__kindof UITableViewCell *)dequeueReusableCellWithIdentifier:(NSString *)identifier forIndexPath:(NSIndexPath *)indexPath NS_AVAILABLE_IOS(6_0);
这种方法，必须注册Cell;
方法: 通过xib（storyboard）或是Class（纯代码）注册可重用Cell(这个方法一定会返回一个Cell)
共2种注册Cell的方式：
-
registerNib---> - (void)registerNib:(nullable UINib *)nib forCellReuseIdentifier:(NSString *)identifier NS_AVAILABLE_IOS(5_0);
-
registerClass---> - (void)registerClass:(nullable Class)cellClass forCellReuseIdentifier:(NSString *)identifier NS_AVAILABLE_IOS(6_0);
相比于第一种方式，第二种的优势在于：如果缓冲区 Cell 不存在，会使用原型 Cell 实例化一个新的 Cell，不需要再判断，同时代码结构更清晰。 -
定义一种(尽量少)类型的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比实时创建要快得多。
- 提前计算并缓存Cell的高度
在不设UITableViewCell的预估行高的情况下，会优先调用”tableView:heightForRowAtIndexPath:”方法，获取每个Cell的即将显示的高度，从而确定UITableView的布局，实际就是要获取contentSize（UITableView继承自UIScrollView,只有获取滚动区域，才能实现滚动）,然后才调用”tableView:cellForRowAtIndexPath”,获取每个Cell，进行赋值。如果项目中模块有10000个Cell需要显示，可想而知…
解决方案：使用MVVM，将计算Cell高度放入ViewModel（视图模型）中，让Model（数据模型）只负责处理数据。
ViewModel:
image.png
TableView:
image.png
运行结果：
image.png
4.异步绘制（自定义Cell绘制）
参考这篇文章：
http://www.cocoachina.com/articles/11968
5.滑动时，按需加载
现在很多自定义的Cell都会附有图片，在列表下滑加载更多过程中，如果每个Cell都在加载图片，那么会很卡顿！
可能有人会说谁那么傻，用异步线程即可，可是每个都加线程，开启的线程太多，一样会卡顿，线程条数一般3-5条，最多也就6条。
这时候UIScrollViewDelegate两个代理方法就能很好地解决这个问题。
- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate
- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView
思路：识别UITableView禁止或者减速滑动结束的时候，进行异步加载图片，快滑动过程中，只加载目标范围内的Cell，这样按需加载，极大的提高流畅度。而SDWebImage可以实现异步加载，与这条性能配合就完美了，尤其是大量图片展示的时候。而且也不用担心图片缓存会造成内存警告的问题。
//获取可见部分的Cell
NSArray *visiblePaths = [self.tableView indexPathsForVisibleRows];
for (NSIndexPath *indexPath in visiblePaths)
{
//获取的dataSource里面的对象，并且判断加载完成的不需要再次异步加载
<code>
}
在“tableView:cellForRowAtIndexPath:”方法中加入判断：
// tableView 停止滑动的时候异步加载图片
-
(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
if (self.tableView.dragging == NO && self.tableView.decelerating == NO) { //开始异步加载图片 <code> }
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加阴影会引起性能问题，如下面代码会导致滚动时有明显的卡顿：
image.png
总结：UITableView的优化主要从三个方面入手:
提前计算并缓存好高度（布局），因为heightForRowAtIndexPath:是调用最频繁的方法；(这个是开发中肯定会要优化的，不可能一个app就几个Cell吧)
滑动时按需加载，防止卡顿，这个我也认为是很有必要做的性能优化，配合SDWebImage
异步绘制，遇到复杂界面，遇到性能瓶颈时，可能就是突破口（如题，遇到复杂的界面，可以从这入手）
缓存一切可以缓存的，这个在开发的时候，往往是性能优化最多的方向
此文部分引用：https://blog.csdn.net/u011452278/article/details/60961350
网友评论