iOS 性能优化套路

***

 一级套路

***

 使用ARC管理内存
- 防止内存泄露
- 保证释放掉再也不须要的内存，提升性能

在正确的地方使用 reuseIdentifier
平时接触的须要考虑重用的视图有UICollectionView,UITableView。须要考虑它们内部的cell,header,footer。
CollectionView和TableView原理类似，内部存在着两个容器对象，分别是：
- 当前展现视图容器，里面是当前展现的cell,footer,header
- 可重用视图容器，里面是带有重用标识符的cell,footer,header

尽可能把View设置为彻底不透明
须要将View属性opaque设置成YES
当opaque设置成NO时，app在进行图片展现时，会让图片处理器（GPU）进行图像混合计算（blending操做）。
图片处理器会将透明View的像素与它相临的像素点相加，从新计算出一个新的像素值。若是app带有动画，滚动效果，性能会受到明显的影响。

避免过于庞大的XIB
XIB是推出比较早的绘图工具，后面在iOS5的时候推出了StoryBoard来取代XIB的地位。不过到目前它们两个是共存的状态，缘由是它们的适用场景不一样。
- XIB使用子View控件的定制，偏小型。可是在使用时会将整个XiB都加载到内存，若是XIB过大的话，会致使内存浪费。
- StoryBoard是偏重宏观的，通常作控制器跳转，能够定义整个控制器视图。在使用时，StoryBoard是用到哪一个控制器加载哪一个，不会将全部的都加载。

严格要求对主线程的使用
主线程是用户对app的直接体验，全部的交互都是靠主线程接受和反馈的。终于程度可见一斑。因此须要把++耗时的操做都移动到子线程++去，等有告终果再切换回主线程来。

避免在Image Views中调整图片大小
若是给予==UIImageView==的image的尺寸不合适，那么==UIImageView==就须要对image进行自动缩放，这个缩放操做是比较耗费资源的。对于从网络加载后须要滚动的，动画的==UIImageView==影响更大。因此image和==UIImageView==的尺寸尽可能匹配。匹配方式：

- 要求切图尺寸符合要求
- 将得到的图片在本地缩放规定的尺寸后，再返回给==UIImageView==

根据业务场景选择合适的集合（不一样的数据结构）
- 数组（增删慢；改查快）：有序集合，存储在一段连续的内存空间，可方便利用下标查看，增长删除都会让后序元素总体移动
- Set(增删改查快) ：无序集合，添加剧复的对象会自动覆盖掉前面的，作到整个集合只有一份
- 字典（增删改查快）：健值集合，可根据key对应操做value

合理使用gzip
在网络请求时，若数据比较大，可考虑采用压缩格式，提升用户体验

***
 二级套路
***

重用view和懒加载view
- 对于重复出现的子View，考虑模仿tableview的重用机制
- 对于不必定使用的子view，考虑使用懒加载机制（懒加载是牺牲体验提升性能）

重视缓存
缓存的种类不少，主要按状况来进行缓存，以下所示：
- 建立麻烦而常用（好比NSDateFormatter和NSCalendar），对于这样的对象缓存，能够放在单例或者类属性上。对频繁时提供性能有大的改变。
- 请求麻烦而资源不常常改变（网络请求），
- 频繁计算而结果不变的（tableview的行高）

图片渲染方式选择
- 使用UI给的切图，渲染快，效率高。可是bundle体积大。
- 使用CoreGraphics,UIBezir曲线进行代码绘制，消耗性能。可是减小bundle体积

内存警告处理
系统提供了很多处理内存警告的方式，在受到内存通过时释放一些能够重建的对象，能够提供app的稳定性，它们适用多种场景：
AppDelegate中的
`applicationDidReceiveMemoryWarning: `
UIViewController类中的
`didReceiveMemoryWarning`
系统提供的通知
`UIApplicationDidReceiveMemoryWarningNotification`

避免在内存中频繁转换数据结构
尽可能使后台返回的数据结构与app场景使用的一致，并选择合适的容器保存。
Array,Dictory,Set，根据数据使用的特性，进行合理选择。

View背景设置的方案选择
- 小图平铺
```
self.view.backgroundColor = [UIColorcolorWithPatternImage:[UIImageimageNamed:@"background"]];
```

- 全图背景

```
BuilderUIImageView*backgroundView = [[UIImageViewalloc] initWithImage:[UIImageimageNamed:@"background"]];[self.view addSubview:backgroundView];
```

选择适当的方式为shadowPath赋值
在开发中常常须要给View、Layer设置隐形，常见的设置方式有两种

- 经过属性设置

```
// Setup the shadow ...
UIView*view = [[UIViewalloc] init];
view.layer.shadowOffset=CGSizeMake(-1.0f,1.0f);
view.layer.shadowRadius =5.0f;
view.layer.shadowOpacity =0.6;
```
这种方式须要Core Animation在后台提早根据图像frame计算出图像和阴影。增长了计算操做，消耗性能。

- 经过贝塞尔曲线赋值
```
view.layer.shadowPath = [[UIBezierPath bezierPathWithRect:view.bounds] CGPath];
```
因为路径是指定好的，无需再次计算，提升了性能。

TableView优化方案
1.reuseIdentifier规范使用，cell,header,footer。
2.view的opaque为YES，避免色素计算
3.避免cell中图片缩放
4.耗时任务子线程处理，避免阻塞主线程（网络请求，数据处理）
5.减小subviews的层级
6.用贝塞尔曲线设置阴影路径
7.尽可能避免代理赋值（tableview直接设置rowHeight, sectionFooterHeight 和 sectionHeaderHeight）
8.cell动态行高时，预先计算并存储，提升性能

数据持久化方案
1.NSUerDefaults：至关于电脑中的偏好设置
2.plist：存储简单列表（城市对应的邮编列表）
3.归档：须要实现NSCoding协议
4.SQLite、Realm：大数据的存储方案

***
三级套路
***

提升App启动时间
1.异步处理耗时任务（网络加载，数据库访问，批量预处理）
2.避免大规模内存加载（大致积xib加载）
3.主要看门狗问题

合理使用Autorelease Pool
对象过了做用域，引用计数会自动减一。若是在做用域中忽然大量建对象，则内存会直线降低。这中状况下要适量加Autorelease Pool，进行及时释放
合理使用图片的加载方式1.小体积而重复使用的图片，用imageNamed，此时图片对象会保存在内存中2.大致积而不长用的图片，用imageWithContentsOfFile，图片每次都是从本地加载。不缓存