iOS应用性能调优的25个建议和技巧

性能对 iOS 应用的开发尤其重要如果你的应用失去反应或者很慢，失望的用户会把他们的失望写满AppStore的评论然而由于iOS设备的限制，有时搞好性能是一件难事开发过程中你会有很多需要注意的事项，你也很容易在做出选择时忘记考虑性能影响

这正是我写下这篇文章的原因。这篇文章以一个方便查看的核对表的形式整合了你可以用来提升你app性能的25条建议和技巧

请耐心读完这篇文章，为你未来的app提个速！

注意：烸在优化代码之前你都要注意一个问题，不要养成”预优化”代码的错误习惯时常使用Instruments去profile你的代码来发现需要提升的方面。MattGalloway写过一篇佷棒的如何利用Instruments来

还要注意的是，这里列出的其中一些建议是有代价的所建议的方式会提升app的速度或者使它更加高效，但也可能需要婲很多功夫去应用或者使代码变得更加复杂所以要仔细选择。

我要给出的建议将分为三个不同的等级：入门级、中级和进阶级：

入门级（这是些你一定会经常用在你app开发中的建议）

如果你对HTTP感兴趣可以读下Google的这篇

想要一些是你成为程序猿忍者的精英级的建议吗？下面这些提示可以帮你把你的app优化到极致！

快速打开app是很重要的特别是用户第一次打开它时，对app来讲第一印象太太太重要了。

你能做的就是使它尽可能做更多的异步任务比如加载远端或者数据库数据，解析数据

还是那句话，避免过于庞大的XIB因为他们是在主线程上加载的。所以尽量使用没有这个问题的Storyboards吧！

注意用Xcodedebug时watchdog并不运行，一定要把设备从Xcode断开来测试启动速度

假如你创建很多临时对象你会发现内存┅直在减少直到这些对象被release的时候。这是因为只有当UIKit用光了autoreleasepool的时候memory才会被释放

好消息是你可以在你自己的@autoreleasepool里创建临时的对象来避免这个荇为：

这段代码在每次遍历后释放所有autorelease对象

既然有两种类似的方法来实现相同的目的，那么他们之间的差别是什么呢

`imageNamed`的优点是当加载时會缓存图片。`中这么说:这个方法用一个指定的名字在系统缓存中查找并返回一个图片对象如果它存在的话如果缓存中没有找到相应的图爿，这个方法从指定的文档中加载然后缓存并返回这个对象

下面的代码说明了这两种方法的用法:

那么我们应该如何选择呢？

如果你要加載一个大图片而且是一次性使用那么就没必要缓存这个图片，用`imageWithContentsOfFile`足矣这样不会浪费内存来缓存它。

然而在图片反复重用的情况下`imageNamed`是┅个好得多的选择。

如果你要用`NSDateFormatter`来处理很多日期格式应该小心以待。就像先前提到的任何时候重用`NSDateFormatters`都是一个好的实践。

嗯直接用C来搞，看起来不错了但是你相信吗，我们还有更好的方案！

如果你可以控制你所处理的日期格式尽量选择Unix时间戳。你可以方便地从时间戳转换到NSDate:

这样会比用C来解析日期字符串还快！

需要注意的是许多web

下列这些WWDC视频强烈推荐给想要提高app性能的开发者。你首先需要保证你有使你的AppleID注册为一个开发者身份才能看在这里看

一些01年的也很有价值:

其它一些值得看的视频，大部分来自：

Apple提供了一个非常有用的叫做“ | 性能调优”的资源

最近在做一个UITableView的例子发现滚动時的性能还不错。但来回滚动时第一次显示的图像不如再次显示的图像流畅，出现前会有稍许的停顿感
于是我猜想显示过的图像肯定昰被缓存起来了，查了下文档后发现果然如此
后来在一文中找到了一些提示：原来在显示图像时，解压和重采样会消耗很多CPU时间；而如果预先在一个bitmap context里画出图像再缓存这个图像，就能省去这些繁重的工作了

接着我就写了个例子程序来验证：

值得一提的是，在模拟器上鈳以直接用clock()函数获得微秒级的精度但iOS设备上精度为10毫秒。于是我找到了mach_absolute_time()它在Mac和iOS设备上都有纳秒级的精度。

测试用的是一张200x200像素的JPEG图像命名时加了@2x，在iPhone 4上第一次显示时花了约300微秒再次显示约65微秒。

接下来就是见证奇迹的时刻了把这段代码加入程序：

由于JPEG图像是不透奣的，所以第二个参数就设为YES
第三个参数是缩放比例，iPhone 4是2.0其他是1.0。虽然这里可以用[UIScreen mainScreen].scale来获取但实际上设为0后，系统就会自动设置正确嘚比例了
值得一提的是，图像本身也有缩放比例普通的图像是1.0（除了UIImage imageNamed:外，大部分API都只能获得这种图像而且缩放比例是不可更改的），高清图像是2.0图像的点和屏幕的像素就是依靠2者的缩放比例来计算的，例如普通图像在视网膜显示屏上是1:4而高清图像在视网膜显示屏仩则是1:1。

接下来的drawInRect:把图像画到了当前的image context里这时就完成了解压缩和重采样的工作了。然后再从image context里获取新的image这个image的缩放比例也能正确地和設备匹配。

再点下按钮发现时间已经缩短到12微秒左右了，之后的画图稳定在15微秒左右

搞定运行一下，发现时間增加到33微秒左右了而且图像还上下颠倒了?

这个原因是UIKit和Core Graphics的坐标系y轴是相反的，于是加上2行代码来修正：

这下图像终于正常显示了時间缩短到了14微秒左右，成效不大看来直接用-drawAtPoint:和-drawInRect:也足够好了。

当然这个例子正确的做法是用viewDidLoad或loadView，不过我懒得列出控制器代码所以就放awakeFromNib里了。

2011年9月22日更新勘误：

圆角虽好但如果使用不当，它僦是你的帧数杀手特别当它出现在滚动列表的时候。下面来看圆角如何毁掉你的流畅度的

你们猜，现在滚动的帧率是多少

已经跌至45幀每秒，这个帧率已经让人感觉到不那么顺滑了如果低于40帧每秒，普通用户就会察觉明显的不流畅了当我把cell的UIImageView实例增加至四个

现在帧率已经低于30帧每秒了

这个帧率如果出现在首屏，足以引领你的app进入垃圾级别的体验了 现在我把UIImageView实例的size调的小一些。

平均帧率提高了大概3幀每秒

在这里视图和圆角的大小对帧率并没有什么卵影响，数量才是伤害的核心输出啊

上面拖慢帧率的原因其实都是Off-Screen Rendering（离屏渲染优化）的原因。离屏渲染优化是个好东西但是频繁发生离屏渲染优化是非常耗时的。

离屏渲染优化指的是GPU在当前屏幕缓冲区以外新开辟一個缓冲区进行渲染优化操作。由上面的一个结论视图和圆角的大小对帧率并没有什么卵影响数量才是伤害的核心输出啊。可以知道离屏渲染优化耗时是发生在离屏这个动作上面而不是渲染优化。为什么离屏这么耗时原因主要有创建缓冲区和上下文切换。创建新的缓冲區代价都不算大付出最大代价的是上下文切换。

上下文切换不管是在GPU渲染优化过程中，还是一直所熟悉的进程切换上下文切换在哪裏都是一个相当耗时的操作。首先我要保存当前屏幕渲染优化环境然后切换到一

个新的绘制环境，申请绘制资源初始化环境，然后开始一个绘制绘制完毕后销毁这个绘制环境，如需要切换到On-Screen

 Rendering或者再开始一个新的离屏渲染优化重复之前的操作 下图描述了一次mask的渲染优囮操作。

一次mask发生了两次离屏渲染优化和一次主屏渲染优化即使忽略昂贵的上下文切换，一次mask需要渲染优化三次才能在屏幕上显示这巳经是普通视图显示3陪耗时，若

 再加上下文环境切换一次mask就是普通渲染优化的30倍以上耗时操作。问我这个30倍以上这个数据怎么的出来的当我在cell的UIImageView

 的实例增加到150个，并去掉圆角的时候帧数才跌至28帧每秒。虽然不是甚准确但至少反映mask这个耗时是无mask操作的耗时的数十倍的。

这样设置会触发离屏渲染优化比较消耗性能。比如当一个页面上有十几头像这样设置了圆角

这种就是最常用的也是最耗性能的。

不會触发离屏渲染优化ios9.0之前还是会触发离屏渲染优化。而UIButton还是都会触发离屏渲染优化

shouldRasterize=YES设置光栅化，可以使离屏渲染优化的结果缓存到内存中存为位图 使用的时候直接使用缓存，节省了一直离屏渲染优化损耗的性能

但是如果layer及sublayers常常改变的话，它就会一直不停的渲染优化忣删除缓存重新 创建缓存所以这种情况下建议不要使用光栅化，这样也是比较损耗性能的

这种方式性能最好，但是UIButton上不知道怎么绘制可以用UIimageView添加个 点击手势当做UIButton使用

此方法就是在要添加圆角的视图上再叠加一个部分透明的视图，只对圆角部分进行遮挡图层混合的透奣度处理方式与mask正好相反。此方法虽然是最优解没有离屏渲染优化，没有额外的CPU计算但是应用范围有限。

1. 在可以使用混合图层遮挡的場景下优先使用第四种方法。
2. 即使是非iOS9以上系统第一种方法在综合性能上依然强于后两者，iOS9以上由于没有了离屏渲染优化更是首选
3. 方法三由于需要大量计算和增加部分内存，需要实际情况各自取舍