1.使用估计高度来进行不等高cell的优化
在理解这个优化的时候我们首先要明确一些事情
- 下面的代理方法是会在创建cell之前调用的
- 而且你有多少个cell就会调用多少次，一口气返回所有cell的高度
- 所以就会出现这个问题 ： 当cell里面显示内容比较复杂，而且不等高时候，我们一般是用FrameModel的方法来做，那么就需要在返回cell高度的代理方法中返回FrameModel中cell的高度，而一般来说，FrameModel里面的Cell高度属性都是懒加载的，但是现在是一口气全部计算完成，这时候是比较耗性能的：比如现在总共有10个cell，而现在TableView中只显示了3个cell，而你却把这个10个cell的高度全部计算了出来
-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath；
既然明确了上面的事情,那么我们的解决方式就是先创建cell，然后再从上面的代理方法中获取高度，而且显示几个就获取几个，这样就优化了性能，想要实现上面的性能优化我们需要重写另一个代理方法,或设置TableView的一个属性
-(CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath
self.tableView.estimatedRowHeight = 100;
- 代理方法和属性的字面意思就是设置预估高度，这个值可以随便给，最好不要太小，这个时候会首先调用这个代理方法，然后去创建cell，然后再去调用返回高度的代理方法，这个时候才会去计算cell的高度，而且显示几个计算几个，这样就优化了性能
2.添加 删除 修改单行数据的时候，最好不要用reloadData
- 当我们在添加和删除cell的时候，是先删除数据，然后再reloadData，那么在调用reloadData之后，tabelVeiw会重新调用数据源和代理方法，这时候是浪费性能的，因为我只操作了一条数据，但是却调用了多次数据源方法
解决办法：当在操作单条数据的时候调用以下方法，而且还有动画效果
[self.tableView insertRowsAtIndexPaths: withRowAnimation:]添加
[self.tableView deleteRowsAtIndexPaths: withRowAnimation:]删除
[self.tableView reloadRowsAtIndexPaths: withRowAnimation:]更新
- 注意：这两个方法是操作特定行的，所以我一般用于操作两条或一条数据的时候用
- 我们在操作cell的时候一定要记住一条原则：通过修改模型来修改cell的显示
3.设置cell上所有视图的opaque属性为YES，让它为不透明
绘图原理:
屏幕上的每个像素点都是通过RGBA值（Red、Green、Blue三原色再配上Alpha透明度）表示的，当纹理（UIView在绘图系统中对应的表示项）出现重叠时，GPU会按照下面的公式计算重叠部分的像素（这就是所谓的“合成”）：
Result = Source + Destination * (1 - SourceAlpha)优化原理：
Result是结果RGB值，Source为处在重叠顶部纹理的RGB值，Destination为处在重叠底部纹理的RGB值。通过公式发现：当SourceAlpha为1时，绘图系统认为下面的纹理全部被遮盖住了，Result等于Source，直接省去了计算！尤其在重叠的层数比较多的时候，完全不同考虑底下有多少层，直接用当前层的数据显示即可，这样大大节省了GPU的工作量，提高了效率。（多像现在一些“美化墙”，不管后面的环境多破烂，“美化墙”直接遮盖住了，什么都看不到，不用整治改进，省心省力）。更详细的可以读下objc.io中<绘制像素到屏幕上>这篇文章。
那什么时候SourceAlpha为1呢？这时候就是opaque上场的时候啦！当opaque为YES时，SourceAlpha为1。opaque就是绘图系统向UIView开放的一个性能开关，开发者根据当前UIView的情况（这些是绘图系统不知道的，所以绘图系统也无法优化），将opaque设置为YES，绘图系统会根据此值进行优化。所以，如果在开发时某UIView是不透明的，就将opaque设置为YES，能优化显示效率。
需要注意的是：
- 当UIView的opaque为YES时，其alpha必须为1.0，这样才符合opaque为YES的场景。如果alpha不为1.0，最终的结果将是不可预料的。
- opaque只对UIView及其subclass生效，对系统提供的类（像UIButton，UILabel）是没有效果的。
此内容摘自：传人的技术博客 《UIView中hidden、alpha、clear color与opaque的区别》
我对其理解：首先要知道计算重叠部分像素的公式
Result = Source + Destination * (1 - SourceAlpha)
那么当opaque为YES时候，SourceAlpha为1，那么结果址就等于上层view的RGB值，省去了运算，提升了性能
4.能不用或少用AutoLayout就少用(但我一般还是选Xib，因为项目紧啊)
为什么要少用或不用AutoLayout，而是通过计算frame呢？
是因为它要根据底层“Cassowary”的约束求解系统进行约束计算，从而得到一个唯一解，假如内部的子控件越多，它需要进行的线性或非线性计算量越大，需要求解的约束越多，相反的，假如我们进行手动布局，都是非常简单的线性计算，CPU就不用浪费那么时间，CPU的压力不会很大。如果依然想用xib，那该怎么优化呢？
答案是减少约束，这是句废话；而怎么减少约束这是我们要做的；如果cell里面狠复杂，这时候就咬把cell里面的分模块，模块分好后，这些模块想用代码还是xib那就根据你个人喜好了，然后再用计算Frame的方法将各个模块加入到cell当中，这样就减少了约束，而且各个模块中控件又比较少，那么AutoLayout的计算量将会减少，性能得到提升。
不过一般简单的cell我首选xib，因为不用写多少代码，省的时间要比提升那点性能划得来。
5.cell中的圆角图片自己在后台中绘制出来，然后反显
原理：对控件设置cornerRadius后对其进行clip或mask操作时，会导致offscreen rendering（离屏渲染），而这个是在GPU（图形处理器）中进行的，这时候是会消耗性能的
优化：用绘图，自己绘制一个圆角图片返回直接显示
