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

写在前面

本文来自iOS Tutorial Team 的 Marcelo Fabri，他是Movile的一名 iOS 程序员。这是他的我的网站：http://www.marcelofabri.com/，你还能够在Twitter上关注@marcelofabri_。

性能对 iOS 应用的开发尤为重要，若是你的应用失去反应或者很慢，失望的用户会把他们的失望写满App Store的评论。然而因为iOS设备的限制，有时搞好性能是一件难事。开发过程当中你会有不少须要注意的事项，你也很容易在作出选择时忘记考虑性能影响。

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

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

注意：每在优化代码以前，你都要注意一个问题，不要养成”预优化”代码的错误习惯。时常使用Instruments去profile你的代码来发现须要提高的方面。Matt Galloway写过一篇很棒的如何利用Instruments来优化代码的文章。

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

 

目录

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

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

• 1. 用ARC管理内存
• 2. 在正确的地方使用reuseIdentifier
• 3. 尽量使Views不透明
• 4. 避免庞大的XIB
• 5. 不要block主线程
• 6. 在Image Views中调整图片大小
• 7. 选择正确的Collection
• 8. 打开gzip压缩

中级（这些是你可能在一些相对复杂状况下可能用到的）

• 9. 重用和延迟加载Views
• 10. Cache, Cache, 仍是Cache！
• 11. 权衡渲染方法
• 12. 处理内存警告
• 13. 重用大开销的对象
• 14. 使用Sprite Sheets
• 15. 避免反复处理数据
• 16. 选择正确的数据格式
• 17. 正确地设定Background Images
• 18. 减小使用Web特性
• 19. 设定Shadow Path
• 20. 优化你的Table View
• 21. 选择正确的数据存储选项

进阶级（这些建议只应该在你确信他们能够解决问题和驾轻就熟的状况下采用）

• 22. 加速启动时间
• 23. 使用Autorelease Pool
• 24. 选择是否缓存图片
• 25. 尽可能避免日期格式转换

无需赘述，让咱们进入正题吧~

初学者性能提高

这个部分致力于一些能提升性能的基本改变。但全部层次的开发者都有可能会从这个记录了一些被忽视的项目的小小的性能备忘录里得到一些提高。

1. 用ARC管理内存

ARC(Automatic Reference Counting, 自动引用计数)和iOS5一块儿发布，它避免了最多见的也就是常常是因为咱们忘记释放内存所形成的内存泄露。它自动为你管理retain和release的过程，因此你就没必要去手动干预了。

下面是你会常常用来去建立一个View的代码段:

1 2 3 4

UIView *view = [[UIView alloc] init];   // ...   [self.view addSubview:view];   [view release];

忘掉代码段结尾的release简直像记得吃饭同样简单。而ARC会自动在底层为你作这些工做。

除了帮你避免内存泄露，ARC还能够帮你提升性能，它能保证释放掉再也不须要的对象的内存。这都啥年代了，你应该在你的全部项目里使用ARC!

这里有一些更多关于ARC的学习资源：

• Apple’s official documentation
• Matthijs Hollemans’s Beginning ARC in iOS Tutorial
• Tony Dahbura’s How To Enable ARC in a Cocos2D 2.X Project
• If you still aren’t convinced of the benefits of ARC, check out this article on eight myths about ARC to really convince you why you should be using it!

ARC固然不能为你排除全部内存泄露的可能性。因为阻塞, retain 周期, 管理不完善的CoreFoundation object(还有C结构)或者就是代码太烂依然能致使内存泄露。

这里有一篇很棒的介绍ARC不能作到以及咱们该怎么作的文章 http://conradstoll.com/blog/2013/1/19/blocks-operations-and-retain-cycles.html。

 

2. 在正确的地方使用 reuseIdentifier

一个开发中常见的错误就是没有给UITableViewCells， UICollectionViewCells，甚至是UITableViewHeaderFooterViews设置正确的reuseIdentifier。

为了性能最优化，table view用 `tableView:cellForRowAtIndexPath:` 为rows分配cells的时候，它的数据应该重用自UITableViewCell。 一个table view维持一个队列的数据可重用的UITableViewCell对象。

不使用reuseIdentifier的话，每显示一行table view就不得不设置全新的cell。这对性能的影响但是至关大的，尤为会使app的滚动体验大打折扣。

自iOS6起，除了UICollectionView的cells和补充views，你也应该在header和footer views中使用reuseIdentifiers。

想要使用reuseIdentifiers的话，在一个table view中添加一个新的cell时在data source object中添加这个方法：

1 2	static NSString *CellIdentifier = @ "Cell" ;   UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];

这个方法把那些已经存在的cell从队列中排除，或者在必要时使用先前注册的nib或者class创造新的cell。若是没有可重用的cell，你也没有注册一个class或者nib的话，这个方法返回nil。

 

3.尽可能把views设置为不透明

若是你有不透明的Views，你应该设置它们的opaque属性为YES。

缘由是这会使系统用一个最优的方式渲染这些views。这个简单的属性在IB或者代码里均可以设定。

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

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

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

你能够在模拟器中用Debug\Color Blended Layers选项来发现哪些view没有被设置为opaque。目标就是，能设为opaque的就全设为opaque!

 

4. 避免过于庞大的XIB

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

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

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

当家在XIB是，全部图片都被chache，若是你在作OS X开发的话，声音文件也是。Apple在相关文档中的记述是：

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

很明显，一样的事情也发生在storyboards中，但我并无找到任何支持这个结论的文档。若是你了解这个操做，写信给我！

想要了解更多关于storyboards的内容的话你能够看看 Matthijs Hollemans的Beginning Storyboards in iOS 5 Part 1 和 Part 2

 

5. 不要阻塞主线程

永远不要使主线程承担过多。由于UIKit在主线程上作全部工做，渲染，管理触摸反应，回应输入等都须要在它上面完成。

一直使用主线程的风险就是若是你的代码真的block了主线程，你的app会失去反应。这。。。正是在App Store中拿到一颗星的捷径 :]

大部分阻碍主进程的情形是你的app在作一些牵涉到读写外部资源的I/O操做，好比存储或者网络。

你可使用`NSURLConnection`异步地作网络操做:
+ (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue *)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler

或者使用像 AFNetworking这样的框架来异步地作这些操做。

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

下面代码是使用GCD的模板

1 2 3 4 5 6 7 8

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{      // switch to a background thread and perform your expensive operation        dispatch_async(dispatch_get_main_queue(), ^{          // switch back to the main thread to update your UI        }); });

发现代码中有一个嵌套的`dispatch_async`吗？这是由于任何UIKit相关的代码须要在主线程上进行。

若是你对 NSOperation 或者GCD 的细节感兴趣的话，看看Ray Wenderlich的 Multithreading and Grand Central Dispatch on iOS for Beginners， 还有 Soheil Azarpour 的 How To Use NSOperations and NSOperationQueues 教程。

 

6. 在Image Views中调整图片大小

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

若是图片是从远端服务加载的你不能控制图片大小，好比在下载前调整到合适大小的话，你能够在下载完成后，最好是用background thread，缩放一次，而后在UIImageView中使用缩放后的图片。

 

7. 选择正确的Collection

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

Apple有一个 Collections Programming Topics 的文档详尽介绍了可用的classes间的差异和你该在哪些场景中使用它们。这对于任何使用collections的人来讲是一个必读的文档。

呵呵，我就知道你由于太长没看…这是一些常见collection的总结：

• Arrays: 有序的一组值。使用index来lookup很快，使用value lookup很慢， 插入/删除很慢。
• Dictionaries: 存储键值对。 用键来查找比较快。
• Sets: 无序的一组值。用值来查找很快，插入/删除很快。

 

8. 打开gzip压缩

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

问题是咱们的目标是移动设备，所以你就不能期望网络情况有多好。一个用户如今还在edge网络，下一分钟可能就切换到了3G。不论什么场景，你确定不想让你的用户等太长时间。

减少文档的一个方式就是在服务端和你的app中打开gzip。这对于文字这种能有更高压缩率的数据来讲会有更显著的效用。

好消息是，iOS已经在NSURLConnection中默认支持了gzip压缩，固然AFNetworking这些基于它的框架亦然。像Google App Engine这些云服务提供者也已经支持了压缩输出。

若是你不知道如何利用Apache或者IIS(服务器)来打开gzip，能够读下这篇文章。

 

中级性能提高

你确信你已经掌握了前述那些基础级的优化方案了吗？但实际状况是，有时一些解决方案并不像那些同样明显，它们每每严重依赖于你如何架构和书写你的app。下面的这些建议就是针对这些场景的。

 

9. 重用和延迟加载(lazy load) Views

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

这里咱们用到的技巧就是模仿`UITableView`和`UICollectionView`的操做: 不要一次建立全部的subview，而是当须要时才建立，当它们完成了使命，把他们放进一个可重用的队列中。

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

建立views的能效问题也适用于你app的其它方面。想象一下一个用户点击一个按钮的时候须要呈现一个view的场景。有两种实现方法：

• 1. 建立并隐藏这个view当这个screen加载的时候，当须要时显示它；
• 2. 当须要时才建立并展现。

每一个方案都有其优缺点。

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

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

 

10. Cache, Cache, 仍是Cache!

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

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

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

下面是一个可用的代码段，你能够能够用它去为一个基本不会改变的图片建立一个NSURLRequest并缓存它：

1 2 3 4 5 6 7 8 9 10

+ (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 caching, NSURLCache, NSURLConnection的相关知识，能够读下这篇文章()

若是你须要缓存其它不是HTTP Request的东西，你能够用NSCache。

NSCache和NSDictionary相似，不一样的是系统回收内存的时候它会自动删掉它的内容。 Mattt Thompson有一篇很棒的关于它的文章：:http://nshipster.com/nscache/

若是你对HTTP感兴趣能够读下Google的这篇 best-practices document on HTTP caching。

 

11. 权衡渲染方法

在iOS中能够有不少方法作出漂亮的按钮。你能够用整幅的图片，可调大小的图片，uozhe能够用CALayer， CoreGraphics甚至OpenGL来画它们。

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

简单来讲，就是用事先渲染好的图片更快一些，由于如此一来iOS就免去了建立一个图片再画东西上去而后显示在屏幕上的程序。问题是你须要把全部你须要用到的图片放到app的bundle里面，这样就增长了体积 – 这就是使用可变大小的图片更好的地方了: 你能够省去一些没必要要的空间，也不须要再为不一样的元素(好比按钮)来作不一样的图。

然而，使用图片也意味着你失去了使用代码调整图片的机动性，你须要一遍又一遍不断地重作他们，这样就很浪费时间了，并且你若是要作一个动画效果，虽然每幅图只是一些细节的变化你就须要不少的图片形成bundle大小的不断增大。

总得来讲，你须要权衡一下利弊，究竟是要性能能仍是要bundle保持合适的大小。

 

12. 处理内存警告

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

若是你的app收到了内存警告，它就须要尽量释放更多的内存。最佳方式是移除对缓存，图片object和其余一些能够重建立的objects的strong references.

幸运的是，UIKit提供了几种收集低内存警告的方法:

• 在app delegate中使用`applicationDidReceiveMemoryWarning:` 的方法
• 在你的自定义UIViewController的子类(subclass)中覆盖`didReceiveMemoryWarning`
• 注册并接收 UIApplicationDidReceiveMemoryWarningNotification 的通知

一旦收到这类通知，你就须要释听任何没必要要的内存使用。

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

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

然而，当你必定要确认你所选择的object是能够被重现建立的来释放内存。必定要在开发中用模拟器中的内存提醒模拟去测试一下。

 

13. 重用大开销对象

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

想要避免使用这个对象的瓶颈你就须要重用他们，能够经过添加属性到你的class里或者建立静态变量来实现。

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

下面的代码说明了使用一个属性来延迟加载一个date formatter. 第一次调用时它会建立一个新的实例，之后的调用则将返回已经建立的实例：

1 2 3 4 5 6 7 8 9 10 11 12

// 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须要常常进行日期格式处理的话，你会从这个方法中获得不小的性能提高。

 

14. 使用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而不用每次都要从新建立。

 

15. 避免反复处理数据

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

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

相似的，若是须要从特定key中取数据，那么就使用键值对的dictionary。

 

16. 选择正确的数据格式

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

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

可是XML也有XML的好处，好比使用SAX 来解析XML就像解析本地文件同样，你不需像解析json同样等到整个文档下载完成才开始解析。当你处理很大的数据的时候就会极大地减低内存消耗和增长性能。

 

17. 正确设定背景图片

在View里放背景图片就像不少其它iOS编程同样有不少方法:

1. 使用UIColor的 colorWithPatternImage来设置背景色；
2. 在view中添加一个UIImageView做为一个子View。

若是你使用全画幅的背景图，你就必须使用UIImageView由于UIColor的colorWithPatternImage是用来建立小的重复的图片做为背景的。这种情形下使用UIImageView能够节约很多的内存：

1 2 3

// You could also achieve the same result in Interface Builder UIImageView *backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@ "background" ]]; [self.view addSubview:backgroundView];

若是你用小图平铺来建立背景，你就须要用UIColor的colorWithPatternImage来作了，它会更快地渲染也不会花费不少内存：

1	self.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@ "background" ]];

 

18. 减小使用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

 

19. 设定Shadow Path

如何在一个View或者一个layer上加一个shadow呢，QuartzCore框架是不少开发者的选择：

1 2 3 4 5 6 7 8 9

#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.

想了解更多能够看看Mark Pospesel的这篇。

 

20. 优化Table View

Table view须要有很好的滚动性能，否则用户会在滚动过程当中发现动画的瑕疵。

为了保证table view平滑滚动，确保你采起了如下的措施:

• 正确使用`reuseIdentifier`来重用cells
• 尽可能使全部的view opaque，包括cell自身
• 避免渐变，图片缩放，后台选人
• 缓存行高
• 若是cell内现实的内容来自web，使用异步加载，缓存请求结果
• 使用`shadowPath`来画阴影
• 减小subviews的数量
• 尽可能不适用`cellForRowAtIndexPath:`，若是你须要用到它，只用一次而后缓存结果
• 使用正确的数据结构来存储数据
• 使用`rowHeight`, `sectionFooterHeight` 和 `sectionHeaderHeight`来设定固定的高，不要请求delegate

 

21. 选择正确的数据存储选项

当存储大块数据时你会怎么作？

你有不少选择，好比：

• 使用`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吧。

若是你使用SQLite，你能够用FMDB(https://github.com/ccgus/fmdb)这个库来简化SQLite的操做，这样你就不用花不少经历了解SQLite的C API了。

 

进阶性能提示

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

22. 加速启动时间

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

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

仍是那句话，避免过于庞大的XIB，由于他们是在主线程上加载的。因此尽可能使用没有这个问题的Storyboards吧！

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

 

23. 使用Autorelease Pool

`NSAutoreleasePool`负责释放block中的autoreleased objects。通常状况下它会自动被UIKit调用。可是有些情况下你也须要手动去建立它。

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

好消息是你能够在你本身的@autoreleasepool里建立临时的对象来避免这个行为：

1 2 3 4 5 6 7 8 9

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对象

更多关于NSAutoreleasePool请参考官方文档。

 

24. 选择是否缓存图片

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

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

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

相反的，`imageWithContentsOfFile`仅加载图片。

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

1 2 3

UIImage *img = [UIImage imageNamed:@ "myImage" ]; // caching   // or   UIImage *img = [UIImage imageWithContentsOfFile:@ "myImage" ]; // no caching

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

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

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

 

25. 避免日期格式转换

若是你要用`NSDateFormatter`来处理不少日期格式，应该当心以待。就像先前提到的，任什么时候候重用`NSDateFormatters`都是一个好的实践。

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

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

若是你能够控制你所处理的日期格式，尽可能选择Unix时间戳。你能够方便地从时间戳转换到NSDate:

1 2 3

- (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp {   return [NSDate dateWithTimeIntervalSince1970:timestamp];   }

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

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