iOS 性能优化点

用 ARC 管理内存
在正确的地方使用 reuseIdentifier
尽量把 views 设置为完全不透明

如果你有透明的 Views 你应该设置它们的 opaque(不透明)属性为 YES。例如一个黑色半透明的可以设置为一个灰色不透明的 View 替代。原因是这会使系统用一个最优的方式渲染这些 views。这个简单的属性在 IB 或者代码里都可以设定。

Apple的文档对于为图片设置透明属性的描述是：

(opaque)这个属性给渲染系统提供了一个如何处理这个 view 的提示。如果设为YES，渲染系统就认为这个 view 是完全不透明的，这使得渲染系统优化一些渲染过程和提高性能；如果设置为 NO，渲染系统正常地和其它内容组成这个 View。默认值是 YES。

在相对比较静止的画面中，设置这个属性不会有太大影响。然而当这个 view 嵌在 scroll view 里边，或者是一个复杂动画的一部分，不设置这个属性的话会在很大程度上影响 app 的性能。

换种说法，大家可能更好理解：

只要一个视图的不透明度小于 1，就会导致 blending。blending 操作在 iOS 的图形处理器（GPU）中完成的，blending 主要指的是混合像素颜色的计算。举个例子，我们把两个图层叠加在一起,如果第一个图层的有透明效果，则最终像素的颜色计算需要将第二个图层也考虑进来。这一过程即为Blending。

为什么 Blending 会导致性能的损失？

原因是很直观的，如果一个图层是完全不透明的，则系统直接显示该图层的颜色即可。而如果图层是带透明效果的，则会引入更多的计算，因为需要把下面的图层也包括进来，进行混合后颜色的计算。
避免过于庞大的 xib

iOS5 中加入的 Storyboards(分镜)正在快速取代 XIB。然而 XIB 在一些场景中仍然很有用。比如你的 app 需要适应 iOS5 之前的设备，或者你有一个自定义的可重用的 view,你就不可避免地要用到他们。

如果你不得不 xib 的话，使他们尽量简单。尝试为每个 Controller 配置一个单独的 xib，尽可能把一个 View Controller 的 view 层次结构分散到单独的 xib 中去。

需要注意的是，当你加载一个 xib 的时候所有内容都被放在了内存里，包括任何图片。如果有一个不会即刻用到的 view，你这就是在浪费宝贵的内存资源了。Storyboards 就是另一码事儿了，storyboard 仅在需要时实例化一个 view controller。

当你加载一个引用了图片或者声音资源的 nib 时，nib 加载代码会把图片和声音文件写进内存。在 OS X 中，图片和声音资源被缓存在 named cache 中以便将来用到时获取。在 iOS 中，仅图片资源会被存进 named caches。取决于你所在的平台，使用 NSImage 或 UIImage 的 imageNamed: 方法来获取图片资源。
不要阻塞主线程

永远不要使主线程承担过多。因为 UIKit 在主线程上做所有工作，渲染，管理触摸反应，回应输入等都需要在它上面完成。一直使用主线程的风险就是如果你的代码真的 block 了主线程，你的 app 会失去反应。

大部分阻碍主进程的情形是你的 app 在做一些牵涉到读写外部资源的 I/O 操作，比如存储或者网络。或者使用像 AFNetworking 这样的框架来异步地做这些操作。

如果你需要做其它类型的需要耗费巨大资源的操作(比如时间敏感的计算或者存储读写)那就用 Grand Central Dispatch，或者 NSOperation 和 NSOperationQueues.

你可以使用 NSURLConnection 异步地做网络操作:
```
+ (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue *)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler
```
在 Image Views 中调整图片大小

如果要在 UIImageView 中显示一个来自 bundle 的图片，你应保证图片的大小和 UIImageView 的大小相同。在运行中缩放图片是很耗费资源的，特别是 UIImageView 嵌套在 UIScrollView 中的情况下。

如果图片是从远端服务加载的你不能控制图片大小，比如在下载前调整到合适大小的话，你可以在下载完成后，最好是用 background thread，缩放一次，然后在 UIImageView 中使用缩放后的图片。
选择正确的 Collection

学会选择对业务场景最合适的类或者对象是写出能效高的代码的基础。当处理 collections 时这句话尤其正确。

Apple 有一个 Collections Programming Topics 的文档详尽介绍了可用的 classes 间的差别和你该在哪些场景中使用它们。这对于任何使用 collections 的人来说是一个必读的文档。
- Arrays：有序的一组值。使用 index 来 lookup 很快，使用 value lookup 很慢，插入/删除很慢。
- Dictionaries：存储键值对。用键来查找比较快。
- Sets：无序的一组值。用值来查找很快，插入/删除很快。
打开 gzip 压缩

大量 app 依赖于远端资源和第三方 API，你可能会开发一个需要从远端下载 XML、JSON、HTML 或者其它格式的 app。

问题是我们的目标是移动设备，因此你就不能指望网络状况有多好。一个用户现在还在 edge 网络，下一分钟可能就切换到了 3G。不论什么场景，你肯定不想让你的用户等太长时间。

减小文档的一个方式就是在服务端和你的 app 中打开 gzip。这对于文字这种能有更高压缩率的数据来说会有更显著的效用。好消息是，iOS 已经在 NSURLConnection 中默认支持了 gzip 压缩，当然 AFNetworking 这些基于它的框架亦然。像 Google App Engine 这些云服务提供者也已经支持了压缩输出。
重用和延迟加载(lazy load) Views

更多的 view 意味着更多的渲染，也就是更多的 CPU 和内存消耗，对于那种嵌套了很多 view 在UIScrollView 里边的 app 更是如此。

这里我们用到的技巧就是模仿 UITableView 和 UICollectionView 的操作：不要一次创建所有的 subview，而是当需要时才创建，当它们完成了使命，把他们放进一个可重用的队列中。

这样的话你就只需要在滚动发生时创建你的 views，避免了不划算的内存分配。

创建 views 的能效问题也适用于你 app 的其它方面。想象一下一个用户点击一个按钮的时候需要呈现一个 view 的场景。有两种实现方法：
- 创建并隐藏这个 view 当这个 screen 加载的时候，当需要时显示它；
- 当需要时才创建并展示。
每个方案都有其优缺点。

用第一种方案的话因为你需要一开始就创建一个 view 并保持它直到不再使用，这就会更加消耗内存。然而这也会使你的 app 操作更敏感因为当用户点击按钮的时候它只需要改变一下这个 view 的可见性。

第二种方案则相反-消耗更少内存，但是会在点击按钮的时候比第一种稍显卡顿。
Cache

一个极好的原则就是，缓存所需要的，也就是那些不大可能改变但是需要经常读取的东西。

我们能缓存些什么呢？一些选项是：远端服务器的响应、图片，甚至计算结果，比如 UITableView 的行高。

NSURLConnection 默认会缓存资源在内存或者存储中根据它所加载的 HTTP Headers。你甚至可以手动创建一个 NSURLRequest 然后使它只加载缓存的值。

下面是一个可用的代码段，你可以用它去为一个基本不会改变的图片创建一个 NSURLRequest 并缓存它：
```
+ (NSMutableURLRequest *)imageRequestWithURL:(NSURL *)url 
{

    NSMutableURLRequest * request = [NSMutableURLRequest requestWithURL:url];

    request.cachePolicy = NSURLRequestReturnCacheDataElseLoad;// this will make sure the request always returns the cached image

    request.HTTPShouldHandleCookies = NO;

    request.HTTPShouldUsePipelining = YES;

    [request addValue:@"image/*" forHTTPHeaderField:@"Accept"];

    return request;

}
```
注意你可以通过 NSURLConnection 获取一个 URL request，AFNetworking 也一样的。这样你就不必为采用这条 tip 而改变所有的 Networking 代码了。

如果你需要缓存其它不是 HTTP Request 的东西，你可以用 NSCache。

NSCache 和 NSDictionary 类似，不同的是系统回收内存的时候它会自动删掉它的内容。
权衡渲染方法

在 iOS 中可以有很多方法做出漂亮的按钮。你可以用整幅的图片，可调大小的图片，uozhe 可以用CALayer， CoreGraphics甚至OpenGL来画它们。

当然每个不同的解决方法都有不同的复杂程度和相应的性能。有一篇 Apple UIKit team中的一员Andy Matuschak推荐过的很棒的关于graphic性能的帖子很值得一读。

简单来说，就是用事先渲染好的图片更快一些，因为如此一来iOS就免去了创建一个图片再画东西上去然后显示在屏幕上的程序。问题是你需要把所有你需要用到的图片放到app的bundle里面，这样就增加了体积 – 这就是使用可变大小的图片更好的地方了: 你可以省去一些不必要的空间，也不需要再为不同的元素(比如按钮)来做不同的图。
然而，使用图片也意味着你失去了使用代码调整图片的机动性，你需要一遍又一遍不断地重做他们，这样就很浪费时间了，而且你如果要做一个动画效果，虽然每幅图只是一些细节的变化你就需要很多的图片造成bundle大小的不断增大。
总得来说，你需要权衡一下利弊，到底是要性能能还是要bundle保持合适的大小。
处理内存警告

一旦系统内存过低，iOS 会通知所有运行中 app。在官方文档中是这样记述:

如果你的app收到了内存警告，它就需要尽可能释放更多的内存。最佳方式是移除对缓存，图片object和其他一些可以重创建的objects的strong references.

幸运的是，UIKit 提供了几种收集低内存警告的方法:
- 在app delegate中使用applicationDidReceiveMemoryWarning: 的方法
- 在你的自定义UIViewController的子类(subclass)中覆盖didReceiveMemoryWarning
- 注册并接收 UIApplicationDidReceiveMemoryWarningNotification 的通知
一旦收到这类通知，你就需要释放任何不必要的内存使用。

例如，UIViewController 的默认行为是移除一些不可见的 view，它的一些子类则可以补充这个方法，删掉一些额外的数据结构。一个有图片缓存的app可以移除不在屏幕上显示的图片。

这样对内存警报的处理是很必要的，若不重视，你的app就可能被系统杀掉。

然而，当你一定要确认你所选择的object是可以被重现创建的来释放内存。一定要在开发中用模拟器中的内存提醒模拟去测试一下。
重用大开销对象

一些objects的初始化很慢，比如NSDateFormatter和NSCalendar。然而，你又不可避免地需要使用它们，比如从JSON或者XML中解析数据。

想要避免使用这个对象的瓶颈你就需要重用他们，可以通过添加属性到你的class里或者创建静态变量来实现。

注意如果你要选择第二种方法，对象会在你的app运行时一直存在于内存中，和单例(singleton)很相似。

下面的代码说明了使用一个属性来延迟加载一个date formatter. 第一次调用时它会创建一个新的实例，以后的调用则将返回已经创建的实例：
```
// in your .h or inside a class extension
@property (nonatomic, strong) NSDateFormatter * formatter;

// inside the implementation (.m)

// When you need, just use self.formatter

- (NSDateFormatter *)formatter 

{

    if(! _formatter) {

        _formatter = [[NSDateFormatter alloc] init];

        _formatter.dateFormat = @"EEE MMM dd HH:mm:ss Z yyyy";// twitter date format

    }

    return _formatter;

}
```
还需要注意的是，其实设置一个 NSDateFormatter 的速度差不多是和创建新的一样慢的！所以如果你的 app 需要经常进行日期格式处理的话，你会从这个方法中得到不小的性能提升。
使用 Sprite Sheets

你是一个游戏开发者吗，那么Sprite sheets一定是一个你的最好的朋友了。Sprite sheet可以让渲染速度加快，甚至比标准的屏幕渲染方法节省内存。

我们有两个很好的关于Sprite的教程：
1. How To Use Animations and Sprite Sheets in Cocos2D
2. How to Create and Optimize Sprite Sheets in Cocos2D with Texture Packer and Pixel Formats
第二个教程涵盖了可能在很大程度上影响你游戏性能的pixel格式的细节。

如果你对于spirte sheet还不是很熟悉，可以看下这两个(youtube)视频SpriteSheets – The Movie, Part 1 和Part 2。视频的作者是创建Sprite sheet很流行的工具之一Texture Packer的作者Andreas Löw。

除了使用Sprite sheets，其它写在这里的建议当然也可以用于游戏开发中。比如你需要很多的Sprite sheets，像敌人，导弹之类的动作类必备元素，你可以重用这些sprites而不用每次都要重新创建。
避免反复处理数据

许多应用需要从服务器加载功能所需的常为 JSON 或者 XML 格式的数据。在服务器端和客户端使用相同的数据结构很重要。在内存中操作数据使它们满足你的数据结构是开销很大的。

比如你需要数据来展示一个 table view，最好直接从服务器取 array 结构的数据以避免额外的中间数据结构改变。

类似的，如果需要从特定 key 中取数据，那么就使用键值对的 dictionary。
选择正确的数据格式

从 app 和网络服务间传输数据有很多方案，最常见的就是 JSON 和 XML。你需要选择对你的 app 来说最合适的一个。

解析 JSON 会比 XML 更快一些，JSON 也通常更小更便于传输。从 iOS5 起有了官方内建的 JSON deserialization 就更加方便使用了。

但是 XML 也有 XML 的好处，比如使用 SAX 来解析 XML 就像解析本地文件一样，你不需像解析 json 一样等到整个文档下载完成才开始解析。当你处理很大的数据的时候就会极大地减低内存消耗和增加性能。
正确设定背景图片

在 View 里放背景图片就像很多其它 iOS 编程一样有很多方法:
- 使用UIColor的 colorWithPatternImage 来设置背景色；
- 在 view 中添加一个UIImageView 作为一个子 View。
如果你使用全画幅的背景图，你就必须使用 UIImageView，因为 UIColor 的colorWithPatternImage 是用来创建小的重复的图片作为背景的。这种情形下使用 UIImageView 可以节约不少的内存：
```
// You could also achieve the same result in Interface Builder
UIImageView *backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"background"]];

[self.view addSubview:backgroundView];
```
如果你用小图平铺来创建背景，你就需要用 UIColor 的 colorWithPatternImage 来做了，它会更快地渲染也不会花费很多内存：
```
self.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"background"]];
 ```
```
减少使用Web特性

UIWebView 很有用，用它来展示网页内容或者创建 UIKit 很难做到的动画效果是很简单的一件事。

但是你可能有注意到 UIWebView 并不像驱动 Safari 的那么快。这是由于以 JIT compilation 为特色的 Webkit 的 Nitro Engine 的限制。

所以想要更高的性能你就要调整下你的 HTML 了。第一件要做的事就是尽可能移除不必要的 javascript，避免使用过大的框架。能只用原生 js 就更好了。

另外，尽可能异步加载例如用户行为统计 script 这种不影响页面表达的 javascript。

最后，永远要注意你使用的图片，保证图片的符合你使用的大小。使用 Sprite sheet 提高加载速度和节约内存。

更多相关信息可以看下 WWDC 2012 session #601 – Optimizing Web Content in UIWebViews and Websites on iOS
设定 Shadow Path

如何在一个View或者一个layer上加一个shadow呢，QuartzCore框架是很多开发者的选择：
```
#import <QuartzCore/QuartzCore.h>
// Somewhere later ...

UIView *view = [[UIView alloc] init];

// Setup the shadow ...

view.layer.shadowOffset = CGSizeMake(-1.0f, 1.0f);

view.layer.shadowRadius = 5.0f;

view.layer.shadowOpacity = 0.6;
```
看起来很简单，对吧。

可是，坏消息是使用这个方法也有它的问题… Core Animation 不得不先在后台得出你的图形并加好阴影然后才渲染，这开销是很大的。

使用 shadowPath 的话就避免了这个问题：
```
view.layer.shadowPath = [[UIBezierPath bezierPathWithRect:view.bounds] CGPath];
```
使用 shadow path 的话 iOS 就不必每次都计算如何渲染，它使用一个预先计算好的路径。但问题是自己计算 path 的话可能在某些 View 中比较困难，且每当 view 的 frame 变化的时候你都需要去 update shadow path.
优化 Table View

Table view 需要有很好的滚动性能，不然用户会在滚动过程中发现动画的瑕疵。

为了保证 table view 平滑滚动，确保你采取了以下的措施:
- 正确使用 reuseIdentifier 来重用 cells
- 尽量使所有的 view opaque = YES，包括 cell 自身
- 避免渐变，图片缩放，后台渲染
- 缓存行高
- 如果 cell 内显示的内容来自 web，使用异步加载，缓存请求结果
- 使用 shadowPath 来画阴影
- 减少 subviews 的数量
- 尽量不使用 cellForRowAtIndexPath:，如果你需要用到它，只用一次然后缓存结果
- 使用正确的数据结构来存储数据
- 尽量使用 rowHeight，sectionFooterHeight 和 sectionHeaderHeight 来设定固定的高，不要请求 delegate
选择正确的数据存储选项

当做本地数据存储时你会怎么做？

你有很多选择，比如：
- 使用 NSUerDefaults
- 使用 XML，JSON 或者 plist
- 使用 NSCoding 存档
- 使用类似 SQLite 的本地 SQL 数据库
- 使用 Core Data
NSUserDefaults 的问题是什么？虽然它很 nice 也很便捷，但是它只适用于小数据，比如一些简单的布尔型的设置选项，再大点你就要考虑其它方式了

XML 这种结构化档案呢？总体来说，你需要读取整个文件到内存里去解析，这样是很不经济的。使用 SAX 又是一个很麻烦的事情。

NSCoding？不幸的是，它也需要读写文件，所以也有以上问题。

当存储大块数据时，以上的方法都不适用. 在这种应用场景下，使用 SQLite 或者 Core Data 比较好。使用这些技术你用特定的查询语句就能只加载你需要的对象。

在性能层面来讲，SQLite 和 Core Data 是很相似的。他们的不同在于具体使用方法。Core Data 代表一个对象的 graph model，但 SQLite 就是一个 DBMS。Apple 在一般情况下建议使用 Core Data，但是如果你有理由不使用它，那么就去使用更加底层的 SQLite 吧。
加速启动时间

快速打开 app 是很重要的，特别是用户第一次打开它时。

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

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

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

NSAutoreleasePool 负责释放 block 中的 autoreleased objects。一般情况下它会自动被 UIKit 调用。但是有些状况下你也需要手动去创建它。

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

好消息是你可以在你自己的 @autoreleasepool 里创建临时的对象来避免这个行为：
```
NSArray * urls = <# An array of file URLs #>;
for(NSURL *url in urls) {

    @autoreleasepool {

        NSError * error;

        NSString * fileContents = [NSString stringWithContentsOfURL:url

                                     encoding:NSUTF8StringEncoding error:&error];

        /* Process the string, creating and autoreleasing more objects. */

    }

}
```
这段代码在每次遍历后释放所有 autorelease 对象。
选择是否缓存图片

常见的从 bundle 中加载图片的方式有两种，一个是用 imageNamed，二是用 imageWithContentsOfFile，第一种比较常见一点。

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

imageNamed 的优点是当加载时会缓存图片。imageNamed 的文档中这么说:

这个方法用一个指定的名字在系统缓存中查找并返回一个图片对象如果它存在的话。如果缓存中没有找到相应的图片，这个方法从指定的文档中加载然后缓存并返回这个对象。

相反的，imageWithContentsOfFile 仅加载图片。

下面的代码说明了这两种方法的用法:
```
UIImage *img = [UIImage imageNamed:@"myImage"];// caching
// or

UIImage *img = [UIImage imageWithContentsOfFile:@"myImage"];// no caching
```
那么我们应该如何选择呢？

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

然而，在图片反复重用的情况下 imageNamed 是一个好得多的选择。
避免日期格式转换

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

然而，如果你需要更多速度，那么直接用 C 是一个好的方案。Sam Soffes 有一个不错的帖子(http://soff.es/how-to-drastically-improve-your-app-with-an-afternoon-and-instruments)里面有一些可以用来解析 ISO-8601 日期字符串的代码，简单重写一下就可以拿来用了。

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

如果你可以控制你所处理的日期格式，尽量选择 Unix 时间戳。你可以方便地从时间戳转换到 NSDate:
```
- (NSDate *)dateFromUnixTimestamp:(NSTimeInterval)timestamp
{

    return [NSDate dateWithTimeIntervalSince1970:timestamp];

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

需要注意的是，许多 web API 会以微秒的形式返回时间戳，因为这种格式在 javascript 中更方便使用。记住用 dateFromUnixTimestamp 之前除以 1000 就好了。

文章

iOS最全性能优化(上)
iOS最全性能优化(中)
iOS最全性能优化(下)