UITableView
- 使用 tableView 的
dequeueReusableCellWithIdentifier来重用 Cell，而不是使用UITableViewCell来新建 Cell - 当你的 Cell 里需加载网络图片的话，采用异步方式（如直接使用 SDWebImage ），而不是同步方式，且先放置默认图片，取得网络数据后更新，是比较好的方式
- 如果你的单个 Cell 所需网络数据的请求时间过长，可以选择在 tableView 停止滑动之后再加载网络数据，可以利用
UIScrollViewDelegate中的scrollViewDidEndDragging判定decelerate为fasle，以及scrollViewDidEndDecelerating方法，来获知 tableView 已停止滑动，你还可以在scrollViewWillBeginDragging函数中，添加代码来停止正在进行的数据加载 - 尽量使用
rowHeight，sectionFooterHeight，sectionHeaderHeight来设置固定的高，而不请求 delegate 方法，即便需要请求，也不要在代理方法内计算行高，提前缓存好 - 减少
Subviews的数量 - 减少放置在
CellForRowAtIndexPath方法内的操作
UIView
- 尽量将不透明 View 的
Opaque属性设置为true，尤其是它们出现在了复杂动画或是 ScrollView 中的时候，我们通常可以对 tableView 中的 Cell 做如此设置
CALayer
- 采用
cornerRadius设置圆角时，如果数量过多，会大幅降低你应用的帧数，所需圆角比较多的情况下，预先生成圆角图片并缓存，使用时直接取出，是比较好的手段，但如果你一定要作死，作如下设置能在一定程度上起到挽救作用
self.layer.shouldRasterize = true
self.layer.rasterizationScale = UIScreen.mainScreen.scale
Queue
- 所有 UIKit 相关操作都必须放在主线程中执行
- 不要将耗时的操作（如获取网络数据）放在主线程，这会导致你的应用失去响应
CollectionType
- Arrays 依据 index 进行查找时性能比较优秀，但如果需要依据 value 进行查找，以及需进行大量插入删除操作时，Sets 的性能要更好
Network
- 当传输的网络数据过大时，采用 gzip 压缩方式可以在一定程度降低传输数据的大小，如果你不太了解 gzip，你可以读下 这篇文章
- 尽量在服务器端与客户端使用相同的数据结构，在内存中操作数据使它们满足你的数据结构开销很大
- JSON 相比较于 XML，优点在于解析快，更小更易于传输，但当你传输较大数据的时候，使用 SAX 解析 XML 时，可以做到边下载边解析，可极大的降低内存消耗
BackgroundImage
- 如果你要使用小图平铺来创建背景图的话，采用
UIColor的colorWithPatternImage的渲染速度会更快
self.view.backgroundColor = UIColor(patternImage: (UIImage(named: "background")!))
Data
- 小规模的数据使用
NSUserDefults存储是比较好的方式 - 在性能上 SQLite 和 CoreData 相差不大，一般情况下建议使用 CoreData，但如果有特殊需求的话，SQLite 也是不错的选择
Launch
- 在
didFinishLaunching里开始尽可能多的异步任务来使你的应用尽早得到展示数据 - 如果你需要加载一个大图片而且只供一次性使用，采用
imageWithContentsOfFile来加载它比较好的选择，但如果图片需要多次重用，imageNamed会将图片缓存，多次重用速度会快很多
Segue
- 尽量不要在
viewWillAppear中放置太多操作
End
虽然 80% 的性能优化都是不必要的，但是当你发现自己的应用存在明显性能问题的时候，逐条核对一下吧 :)
