性能优化
所谓的性能优化一般都是在运行和内存之间切换，平衡两者的负荷。具体的性能到底好不好，一定要通过实际测试才来决定到底用不用采取下面的几种优化方案之一。试想，如果表格刷新帧率已经非常接近60了，但是还想进一步采取缓存行高来优化项目。很肯定的说，这种做法是不明智的，因为刷新帧率已经非常接近60了，即使再怎么优化也不可能突破60这个数值，反而采取缓存行高的方式会消耗内存，对整个项目的优化百害而无一利。
CPU、GPU概念
关于绘图和动画有两种处理方式CPU(中央处理器)和GPU(图形处理器)，CPU的工作都在软件层面，而GPU的在硬件层面。
总的来说，可以使用CPU做任何事情，但是对于图像的处理，通常GPU会更快，所以，我们想尽可能的把屏幕渲染的工作交给硬件去处理，而问题在于GPU并没有无限制处理的性能，一旦资源用尽，即使CPU并没有完全占用，GPU性能还是会下降。所以，目前大多的性能优化都是关于智能利用GPU和CPU，平衡它们之间工作负载。
离屏渲染
Core Animation可以用来检测应用内的FPS，当FPS 低于45的时候，用户就会察觉到到滑动有卡顿。理论上60最佳，实际过程中59就可以了。
- 离屏渲染：
是指在屏幕外部不可见部分或异步操作，准备好图片。
优点：提前画好图片。
缺点：会在CPU和GPU之间频繁切换，一会计算坐标，一会画图。会导致CPU消耗高些，但显示性能稍微好些。一般会用shadowPath和shouldRasterise（栅格化）来优化。
针对混合图层和图片拉升效果引起的性能问题,一般可以通过绘制指定尺寸大小、不透明的图片来优化性能。如下是两个代码片段分别针对这一点绘制指定尺寸和圆角图片
- 绘制圆角图片
- (UIImage *)imageWithSize:(CGSize )size backColor:(UIColor *)backColor{
CGRect rect = CGRectMake(0, 0, size.width, size.height);
//1.上下文 ->在内存中开辟一个地址，这和屏幕显示无关
/*
参数:
1.绘图尺寸
2.是否不透明：false(透明)/true（不透明）,
第二个参数，一般设置为true更好些，会避免图层重叠导致的混合渲染
3.屏幕的分辨率，
默认如果不指定，默认的图像显示1.0的分辨率，图像质量不好，
可以指定为0，会选择当前屏幕的分辨率
*/
UIGraphicsBeginImageContextWithOptions(size, YES, 0);
//2.绘图 drawInRect就是在指定区域内拉伸屏幕 核心绘图的重点：路径
//设置背景颜色
[backColor setFill];
UIRectFill(rect);
[self drawInRect:rect];
//3.取得结果
UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
//4.关闭上下文
UIGraphicsEndImageContext();
return image;
}
- 绘制指定尺寸大小的图片
- (UIImage *)circleImageWithSize:(CGSize )size
backColor:(UIColor *)backColor
lineColor:(UIColor *)lineColor
lineWidth:(CGFloat)linewidth
{
CGRect rect = CGRectMake(0, 0, size.width, size.height);
//1.上下文 ->在内存中开辟一个地址，这和屏幕显示无关
/*
参数:
1.绘图尺寸
2.是否不透明：false(透明)/true（不透明）,
第二个参数，一般设置为true更好些，会避免图层重叠导致的混合渲染
3.屏幕的分辨率，
默认如果不指定，默认的图像显示1.0的分辨率，图像质量不好，
可以指定为0，会选择当前屏幕的分辨率
*/
UIGraphicsBeginImageContextWithOptions(size, YES, 0);
//2.绘图 drawInRect就是在指定区域内拉伸屏幕 核心绘图的重点：路径
//a.背景填充颜色
[backColor setFill];
UIRectFill(rect);
//b.实例化一个圆形的路径
UIBezierPath *path = [UIBezierPath bezierPathWithOvalInRect:rect];
//c.进行路径裁剪 --后续的绘图，都会在圆形路径内部，外部的全部干掉
[path addClip];
//d.绘图
[self drawInRect:rect];
//f.绘制边线
[lineColor setStroke];
path.lineWidth = linewidth;
[path stroke];
//3.取得结果
UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
//4.关闭上下文
UIGraphicsEndImageContext();
return image;
}
TableViewCell的优化
- tableViewCell复用机制
- 缓存行高
- 设计统一规格的cell，擅用hidden来显示/隐藏subviews，而不是动态的通过addsubview去控制。
- UITableViewCell上的子View的opaque属性设为yes
- 使用局部刷新
- 减少subviews的数量
- 使用rowHeight, sectionFooterHeight 和 sectionHeaderHeight来设定固定的高，不要请求delegate
- 使用正确的数据结构来存储数据
- 所有的子视图都要制定背景颜色（如UIViewController中不设置背景颜色，会出现卡顿现象）。
- 所有的颜色都不要使用alpha，一旦涉及alpha就会涉及多个图层渲染的计算，运算量会很大，对资源的消耗会非常巨大。
- 栅格化：将cell中的所有内容，生成一张独立的图像。只要在自定义cell类中的初始化发放中写下如下两行代码：
self.layer.shadowPath = YES;
self.layer.rasterizationScale = [UIScreen mainScreen].scale;
- 异步绘制。如果cell布局比较复杂建议使用异步绘制，其他情况下不建议使用。同样也是在自定义cell类中的初始化中完成，只要写上一句代码即可。
self.layer.drawsAsynchronously = YES;
图片加载
- 本地图片加载方式：
1、[UIImage imageNamed:@""]优点：当加载时会缓存图片，该方法用一个指定的名字在系统缓存中查找并返回一个图片对象如果它存在的话。如果缓存中没有找到相应的图片，这个方法从指定的文档中加载然后缓存并返回这个对象。
2、[[UIImage alloc] initWithContentsOfFile:@""]仅加载图片。
3、该如何选择：
如果你要加载一个大图片而且是一次性使用，那么就没必要缓存这个图片，用imageWithContentsOfFile足矣，这样不会浪费内存来缓存它。
然而，在图片反复重用的情况下imageNamed是一个好得多的选择。
编码过程
- 延迟加载Views
更多的view意味着更多的渲染，即更多的CPU和内存消耗。想象一下一个用户点击一个按钮的时候需要呈现一个view的场景。有两种实现方法：
1、创建并隐藏这个view当这个screen加载的时候，当需要时显示它；
2、当需要时才创建并展示。
每个方案都有其优缺点：
用第一种方案的话因为你需要一开始就创建一个view并保持它直到不再使用，这就会更加消耗内存。然而这也会使你的app操作更敏感因为当用户点击按钮的时候它只需要改变一下这个view的可见性。
第二种方案则相反-消耗更少内存，但是会在点击按钮的时候比第一种稍显卡顿。
- 重用大开销对象
一些objects的初始化很慢，比如NSDateFormatter和NSCalendar。可以通过添加属性到你的class里或者创建静态变量（对象会在你的app运行时一直存在于内存中，和单例(singleton)很相似）来实现。
- 选择正确的数据格式，避免反复处理数据
- 选择正确的数据存储选项
数据存储大致分plist、对象归档、sqlite。NSUserDefault适合存储小量数据,私密信息使用Keychain, sqlite适合大量数据，归档性能较低,尽量避免使用。
处理内存警告
UIKit提供了几种收集低内存警告的方法:
1、在app delegate中使用applicationDidReceiveMemoryWarning: 的方法
2、在你的自定义UIViewController的子类(subclass)中覆盖didReceiveMemoryWarning
3、注册并接收 UIApplicationDidReceiveMemoryWarningNotification 的通知
代码优化
- 良好的编码习惯，遵循代码规范、mvc架构、利用第三方AFN时，做一层网络隔离，减少对第三方的依赖
