iOS应用性能优化备忘录

UITableView

在

cellForRowAtIndexPath

中使用

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% 的性能优化都是不必要的，但是当你发现自己的应用存在明显性能问题的时候，逐条核对一下吧 :)