25个增强iOS应用程序性能的提示和技巧

初级

在开发过程中，下面这些初级技巧需要时刻注意：

 

1.使用ARC进行内存管理
2.在适当的情况下使用reuseIdentifier
3.尽可能将View设置为不透明（Opaque）
4.避免臃肿的XIBs
5.不要阻塞主线程

6.让图片的大小跟UIImageView一样
7.选择正确的集合
8.使用GZIP压缩

 

1) 使用ARC进行内存管理

ARC是在iOS 5中发布的，它解决了最常见的内存泄露问题——也是开发者最容易健忘的。ARC的全称是“Automatic Reference Counting”——自动引用计数，它会自动的在代码中做retain/release工作，开发者不用再手动处理。

 

下面是创建一个View通用的一些代码块：

1. UIView *view = [[UIView alloc] init];  
2. // ...  
3. [self.view addSubview:view];  
4. [view release]; 

在上面代码结束的地方很容易会忘记调用release。不过当使用ARC时，ARC会在后台自动的帮你调用release。

 

ARC除了能避免内存泄露外，还有助于程序性能的提升：当程序中的对象不再需要的时候，ARC会自动销毁对象。所以，你应该在工程中使用ARC。

 

下面是学习ARC的一些资源：

苹果的官方文档

Matthijs Hollemans的初级ARC

Tony Dahbura的如何在Cocos2D 2.X工程中使用ARC

如果你仍然不确定ARC带来的好处，那么看一些这篇文章：8个关于ARC的神话——这能够让你相信你应该在工程中使用ARC！

值得注意的是，ARC并不能避免所有的内存泄露。使用ARC之后，工程中可能还会有内存泄露，不过引起这些内存泄露的主要原因是：block，retain循环，对CoreFoundation对象（通常是C结构）管理不善，以及真的是代码没写好。

这里有一篇文章是介绍哪些问题是ARC不能解决的 — 以及如何处理这些问题。

 

2) 在适当的情况下使用reuseIdentifier

在适当的情况使用reuseIdentifier

在iOS程序开发中一个普遍性的错误就是没有正确的为UITableViewCells、UICollectionViewCells和UITableViewHeaderFooterV iews设置reuseIdentifier。

 

为了获得最佳性能，当在tableView:cellForRowAtIndexPath:方法中返回cell时，table view的数据源一般会重用UITableViewCell对象。table view维护着UITableViewCell对象的一个队列或者列表，这些数据源已经被标记为重用了。

 

如果没有使用reuseIdentifier会发生什么？如果你在程序中没有使用reuseIdentifier，table view每次显示一个row时，都会配置一个全新的cell。这其实是一个非常消耗资源的操作，并且会影响程序中table view滚动的效率。

 

自iOS 6以来，你可能还希望header和footer views，以及UICollectionView的cell和supplementary views。

 

为了使用reuseIdentifiers，在table view请求一个新的cell时，在数据源中调用下面的方法：

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

如果table view维护的UITableViewCell队列或列表中有可用的cell，则从队列从移除一个已经存在的cell，如果没有的话，就从之前注册的nib文件或类中创建一个新的cell。如果没有可以重用的cell，并且没有注册nib文件或类，tableview的dequeueReusableCellWithIdentifier:方法会返回一个nil。

3) 尽可能将View设置为不透明（Opaque）

尽量将view设置为Opaque
 

如果view是不透明的，那么应该将其opaque属性设置为YES。为什么要这样做呢？这样设置可以让系统以最优的方式来绘制view。opaque属性可以在Interface Builder或代码中设置。

 

苹果的官方文档对opaque属性有如下解释：

This property provides a hint to the drawing system as to how it should treat the view. If set to YES, the drawing system treats the view as fully opaque, which allows the drawing system to optimize some drawing operations and improve performance. If set to NO, the drawing system composites the view normally with other content. The default value of this property is YES.

（opaque属性提示绘制系统如何处理view。如果opaque设置为YES，绘图系统会将view看为完全不透明，这样绘图系统就可以优化一些绘制操作以提升性能。如果设置为NO，那么绘图系统结合其它内容来处理view。默认情况下，这个属性是YES。）

 

如果屏幕是静止的，那么这个opaque属性的设置与否不是一个大问题。但是，如果view是嵌入到scroll view中的，或者是复杂动画的一部分，不将设置这个属性的话肯定会影响程序的性能！可以通过模拟器的Debug\Color Blended Layers选项来查看哪些view没有设置为不透明。为了程序的性能，尽可能的将view设置为不透明！

 

4) 避免臃肿的XIBs

避免臃肿的XIBs
 

在iOS 5中开始使用Storyboards，并且将替代XIBs。不过在有些情况下XIBs仍然有用。如果你的程序需要运行在装有iOS 5之前版本的设备上，或者要自定义可重用的view，那么是避免不了要使用XIBs的。

 

如果必须要使用XIBs的话，尽量让XIBs文件简单。并且每个view controller对于一个XIB文件，如果可以的话，把一个view controller的view不同的层次单独分到一个XIBs文件中。

 

（注意：当把一个XIB文件加载到内存时，XIB文件中的所有内容都将被加载到内存中，包括图片。如果有一个view还不立即使用的话，就会造成内存的浪费。而这在storyboard中是不会发生的，因为storyboard还在需要的时候才实例化一个view controller。）

 

当加载XIB时，所有涉及到的图片都将被缓存，并且如果是开发的程序是针对OS X的话，声音文件也会被加载。苹果的官方文档这样说：

When you load a nib file that contains references to image or sound resources, the nib-loading code reads the actual image or sound file into memory and and caches it. In OS X, image and sound resources are stored in named caches so that you can access them later if needed. In iOS, only image resources are stored in named caches. To access images, you use the imageNamed: method of NSImage or UIImage, depending on your platform.

（当加载一个nib文件时，也会将nib文件涉及到的图片或声音资源加载到内存中，nib-loading代码会将实际的图片或声音文件读取到内存中，并一直缓存着。在OS X中，图片和声音资源都存储在命名缓存中，这样之后如果需要的话，可以对其进行访问。在iOS中，只有图片资源被存储到命名缓存中。要访问图片的话，使用NSImage或UIImage（根据不同的系统）的imageNamed:方法即可。）

 

显然，在使用storyboard时也会发生类似的缓存操作；不过我没有找到相关内容的任何资料。想要学习storyboard的更多知识吗？可以看看Matthijs Hollemans写的iOS 5中：初级Storyboard Part 1和Part2。

 

5) 不要阻塞主线程

永远都不要在主线程做繁重的任务。因为UIKit的左右任务都在主线程中进行，例如绘制、触摸管理和输入响应。

 

在主线程做所有任务的风险是：如果你的代码阻塞了主线程，那么程序将出现反应迟钝。这回招致用户在App Store上对程序的差评！

 

在执行I/O操作中，大多数情况下都会祖塞主线程，这些操作需要从读写外部资源，例如磁盘或者网络。

 

关于网络操作可以使用NSURLConnection的如下方法，以异步的方式来执行：

1. + (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue *)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler 

或者使用第三方框架，例如AFNetworking。

 

如果你需要做一些其它类型开销很大的操作（例如执行一个时间密集型的计算或者对磁盘进行读写），那么就使用GCD（Grand Central Dispatch），或NSOperations 和 NSOperationQueues。

 

下面的代码是使用GCD的一个模板：

1. dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{  
2.     // switch to a background thread and perform your expensive operation  
3.    
4.     dispatch_async(dispatch_get_main_queue(), ^{  
5.         // switch back to the main thread to update your UI  
6.    
7.     });  
8. }); 

如上代码，为什么在第一个dispatch_async里面还嵌套了一个dispatch_async呢？这是因为关于UIKit相关的代码需要在主线程里面执行。

可以看看Ray Wenderlich中的教程：iOS中多线程和GCD—初级，以及Soheil Azarpour的如何使用NSOperations和NSOperationQueues教程。

 

6) 让图片的大小跟UIImageView一样

确保图片和UIImageView大小一致

如果需要将程序bundle中的图片显示到UIImageView中，请确保图片和UIImageView的大小是一样的。因为图片的缩放非常耗费资源，特别是将UIImageView嵌入到UIScrollView中。

如果是从远程服务中下载图片，有时候你控制不了图片的尺寸，或者在下载之前无法在服务器上进行图片的缩放。这种情况，当图片下载完之后，你可以手动进行图片的缩放——做好是在后台线程中！——然后再在UIImageView中使用缩放过的图片。
 

 
7) 选择正确的集合

选择正确的集合

学习使用最适合的类或对象是编写高效代码的基础。特别是在处理集合数据时，尤为重要。

苹果的官网上有一篇文章：集合编程主题( Collections Programming Topics)——详细的介绍了在集合数据中可以使用的类，以及什么情况下使用哪个类。在使用集合时，每个开发者都应该阅读一下这个文档。

太长，不想阅读(TLDR)？下面是常见集合类型的一个简介：
•数组：是一个值按顺序排列的一个列表。根据索引可以快速查找，不过根据值进行查找就比较慢，另外插入和删除也比较慢。
•字典:   存储键/值对。根据键可以快速查找。
•Sets:   是一个值无序排列的列表，根据值可以快速查找，另外插入和删除也比较快。

 

8) 使用GZIP压缩

使用GZIP压缩

越来越多的程序依赖于外部数据，这些数据一般来自远程服务器或者其它的外部APIs。有时候你需要开发一个程序来下载一些数据，这些数据可以是XML，JSON，HTML或者其它一些文本格式。

 

问题是在移动设备上的网络是不确定的。用户的设备可能在EDGE网络一分钟，然后接着又在3G网络中。不管在什么情况下，都不要让用户等待。

 

有一个可以优化的选择：使用GZIP对网络传输中的数据进行压缩，这样可以减小文件的大小，并加快下载的速度。压缩对于文本数据特别有用，因为文本具有很高的压缩比。

 

iOS中，如果使用NSURLConnection，那么默认情况下已经支持GZIP压缩了，并且基于NSURLConnection的框架页支持GZIP压缩，如AFNetworking。甚至有些云服务提供商已经提供发送经压缩过的响应内容，例如Google App Engine。

 

这里有一篇关于GZIP压缩很好的文章，介绍了如何在Apache活IIS服务器中开启支持GZIP压缩。

 

中级性能提升
现在，在进行代码优化时，你已经能够完成一些初级性能优化了。但是下面还有另外一些优化方案，虽然可能不太明显（取决于程序的架构和相关代码），但是，如果能够正确的利用好这些方案，那么它们对性能的优化将非常明显！

9) 重用和延迟加载View

程序界面中包含更多的view，意味着界面在显示的时候，需要进行更多的绘制任务；也就意味着需要消耗更多的CPU和内存资源。特别是在一个UIScrollView里面加入了许多view。

 

这种情况的管理技巧可以参考UITableView和UICollectionView的行为：不要一次性创建所有的subview，而是在需要的时候在创建view，并且当view使用完毕时候将它们添加到重用队列中。

 

这样就可以仅在UIScrollView滚动的时候才配置view，以此可以避免分配创建view的带来的成本——这可能是非常耗资源的。

 

现在有这样的一个问题：在程序中需要显示的view在什么时机创建（比如说，当用户点击某个按钮，需要显示某个view）。这里有两种可选方法：

在屏幕第一次加载以及隐藏的时候，创建view；然后在需要的时候，再把view显示出来。
直到需要显示view的时候，才创建并显示view。

每种方法都有各自的优点和缺点。第一种方法需要消耗更多的内容，因为创建出来的view一直占据着内存，直到view被release掉。不过，使用这种方法，当用户点击按钮时，程序会很快的显示出view，因为只需要修改一下view的可见性即可。而第二种方法则产生相反的效果；当需要的时候猜创建view，这会消耗更少的内存；不过，当用户点击按钮的时候，不会立即显示出view。

10) 缓存、缓存、缓存

在开发程序时，一个重要的规则就是“缓存重要的内容”——这些内容一般不会改变，并且访问的频率比较高。

 

可以缓存写什么内容呢？比如远程服务器的响应内容，图片，甚至是计算结果，比如UITableView的行高。

 

NSURLConnection根据HTTP头的处理过程，已经把一些资源缓存到磁盘和内存中了。你甚至可以手动创建一个NSURLRequest ，让其只加载缓存的值。

下面的代码片段一般用在为图片创建一个NSURLRequest：

1. + (NSMutableURLRequest *)imageRequestWithURL:(NSURL *)url {  
2.     NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];  
3.    
4.     request.cachePolicy = NSURLRequestReturnCacheDataElseLoad; // this will make sure the request always returns the cached image  
5.     request.HTTPShouldHandleCookies = NO;  
6.     request.HTTPShouldUsePipelining = YES;  
7.     [request addValue:@"image 
8.     }  
9. } 

当每次迭代完之后，都会释放所有的autorelease对象。

 

关于NSAutoreleasePool的更多内容可以阅读苹果的官方文档。

24) 缓存图片--或者不缓存

iOS中从程序bundle中加载UIImage一般有两种方法。

第一种比较常见：imageNamed。

第二种方法很少使用：imageWithContentsOfFile

 

为什么有两种方法完成同样的事情呢？imageNamed的优点在于可以缓存已经加载的图片。苹果的文档中有如下说法：

This method looks in the system caches for an image object with the specified name and returns that object if it exists. If a matching image object is not already in the cache, this method loads the image data from the specified file, caches it, and then returns the resulting object.

 

这种方法会在系统缓存中根据指定的名字寻找图片，如果找到了就返回。如果没有在缓存中找到图片，该方法会从指定的文件中加载图片数据，并将其缓存起来，然后再把结果返回。

 

而imageWithContentsOfFile方法只是简单的加载图片，并不会将图片缓存起来。这两个方法的使用方法如下：

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

 那么该如何选择呢？

 

如果加载一张很大的图片，并且只使用一次，那么就不需要缓存这个图片。这种情况imageWithContentsOfFile比较合适——系统不会浪费内存来缓存图片。

 

然而，如果在程序中经常需要重用的图片，那么最好是选择imageNamed方法。这种方法可以节省出每次都从磁盘加载图片的时间。

25) 尽量避免Date格式化
如果有许多日期需要使用NSDateFormatter，那么需要小心对待了。如之前（重用花销很大的对象）所提到的，无论什么时候，都应该尽量重用NSDateFormatters。

 

然而，如果你需要更快的速度，那么应该使用C来直接解析日期，而不是NSDateFormatter。Sam Soffes写了一篇文章，其中提供了一些解析ISO-8601格式日期字符的串代码。你只需要简单的调整一下其中的代码就可以满足自己特殊的需求了。

 

这听起来不错把——不过，你相信这还有更好的一个办法吗？

 

如果你自己能控制处理日期的格式，那么可以选择 Unix timestamps（http://en.wikipedia.org/wiki/Unix_time）。Unix timestamps是一个简单的整数，代表了从新纪元时间（epoch）开始到现在已经过了多少秒，通常这个新纪元参考时间是00:00:00 UTC on 1 January 1970。

 

你可以很容易的见这个时间戳转换为NSDate，如下所示：

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

上面这个方法比C函数还要快！

 

注意：许多网络APIs返回的时间戳都是毫秒，因此需要注意的是在将这个时间戳传递给dateFromUnixTimestamp之前需要除以1000。

 

何去何从？
强烈建议对程序性能优化感兴趣的读者看看下面列出来的WWDC视频。在看视频之前，你需要注册一个Apple ID（注册后就可以观看所有WWDC2012的视频）：

#406: Adopting Automatic Reference Counting
#238: iOS App Performance: Graphics and Animations
#242: iOS App Performance: Memory
#235: iOS App Performance: Responsiveness
#409: Learning Instruments
#706: Networking Best Practices
#514: OpenGL ES Tools and Techniques
#506: Optimizing 2D Graphics and Animation Performance
#601: Optimizing Web Content in UIWebViews and Websites on iOS
#225: Up and Running: Making a Great Impression with Every Launch

下面这些视频来自WWDC 2011 ，也非常有用：

#308: Blocks and Grand Central Dispatch in Practice
#323: Introducing Automatic Reference Counting
#312: iOS Performance and Power Optimization with Instruments
#105: Polishing Your App: Tips and tricks to improve the responsiveness and performance
#121: Understanding UIKit Rendering

 

这里还有更多相关视频，大多数来自iOS 5技术讲座：

Optimizing App Performance with Instruments
Understanding iOS View Compositing

基于 “Your iOS App Performance Hitlist” 视频，Ole Begemann写了一篇文章。苹果还提供了一篇非常好的文章：性能优化。其中提供的技巧和提示对程序性能提升很有帮助