25条关于提高app性能的技巧

编程技术

当我们开发iOS应用时，好的性能对我们的App来说是很重要的。你的用户也希望如此，但是如果你的app表现的反应迟钝或者很慢也会伤害到你的审核。

然而，由于iOS设备的限制有时很难工作得很正确。我们开发时有很多需要我们记住这些容易忘记的决定对性能的影响。

这是为什么我写这篇文章的原因。这篇文章用备忘录的形式集合了25个技巧和诀窍可以用来提高你的app性能。所以保持阅读来给你未来的App一个很不错的提高。

Note:在优化代码之前，必须保证有个需要解决的问题！不要陷入”pre-optimizing(预优化)”你的代码。勤用Instruments分析你的代码，发现任何一个需要提高的地方。

以下这些技巧分为三个不同那个的级别—基础，中级，高级。

1.基础——这些技巧你要总是想着实现在你开发的App中。

2.中级——这些技巧是当你遇到更复杂的情况的时候使用。

3.高级——这些技巧你应该只在你很积极认为它们能解决这个问题，而且你觉得用它们很舒适的时候使用。

没有其他的，一起去看看这些技巧吧！

基础的性能提升

1）用ARC去管理内存
ARC是伴随iOS5 一起发布的，它用来消除常见的的内存泄漏。 ARC是”Automatic Reference Counting”的缩写。它自动管理你代码中的retain/release循环，这样你就不必手动做这事儿了。

下面这段代码展示了创建一个view的常用代码

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

这里极其容易忘记在代码结束的地方调用release，ARC将会自动的，底层的为你做这些工作。 除了帮助你你避免内存泄漏，ARC还能保证对象不再使用时立马被回收来提高你的性能。你应该在你的工程里多用ARC。 这里是一些学习更多关于ARC的非常棒的资源

苹果的官方文档。
Matthijs Hollemans’s
Tony Dahbura’s How To Enable ARC in a Cocos2D 2.X Project
如果你还是不确信ARC的好处，看看这篇文章 eight myths about ARC 说服你为什么用ARC。

值得注意的是ARC不能消除所有的内存泄漏。你依然有可能内存泄漏，这主要可能是由于blocks(块)，引用循环，CoreFoundation对象管理不善（通常是C结构体，或者是确实很糟糕的代码）。

2）适当的地方使用reuseIdentifier
在app开发中的一个常见的为UITableViewCells，UICollectionViewCells，UITableViewHeaderFooterViews设置一个正确的reuseIdentifier(重用标识)。

为了最大化性能，一个tableView的数据源一般应该重用UITableViewCell对象，当它在tableView:cellForRowAtIndexPath:中分配数据给cells的时候。一个表视图维护了一个UITableViewCell对象的队列或者列表，这些对象已被数据源标记为重用。

如果你不用reuseIdentifier 会怎么样呢？ 如果你用，你的tableview每显示一行将会配置一个全新的cell。这是非常费事的操作而且绝对会影响你app滚动的性能。

自从引进了iOS6，你应该为header and footer 视图设置reuseIdentifiers，就像在 UICollectionView’s cells 和 supplementary views（补充视图）一样。

使用reuseIdentifiers，当你的数据源要求提供一个新的cell给tableview的时候调用这个方法

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

3）可能的时候设置视图为不透明
如果你有不透明视图（opaque views）–也就是说，没有透明度定义的视图，你应该设置他们的opaque属性为YES。

为什么？ 这会允许系统以最优的方式绘制你的views。这是一个简单的属性可以在Interface Builder 和代码中设置。

苹果的文档 中有对这个属性的描述

这个属性提供了一个提示给图系统如何对待这个视图。如果设置为YES，绘制系统将会把这个视图视为完全不透明。这样允许系统优化一些绘制操作和提高性能。如果设置为NO，绘图系统会复合这个视图和其他的内容，这个属性的默认值是YES

在相对静态的屏幕上，设置opaque属性不会有什么大问题。尽管如此，如果你的视图是嵌入在一个scrollView，或者是一个复杂的动画的一部分，不设置这个属性绝对会影响你的程序的性能。

你也可以使用Debug/Color olor Blended Layers选项 在你的模拟器中形象化的看见没有设置为不透明（opaque）的视图.你的目标应该是尽可能多的设置视图为透明。

4）避免臃肿的XIB文件
故事板，由iOS5引进，很快的替代XIBs。尽管如此，XIBs在一下情况下依然是很有用的。如果你需要在iOS5之前版本的设备上运行或者你想自定义重用的视图，那么你确实不能避免使用它们。

如果你专注使用XIBs，那么让它们尽量的简单。尝试为一个试图控制器创建一个XIB，如果可能的话，把一个视图控制器的视图分层管理在单独的XIBs中。

注意当你加载一个XIB到内存的时候，它所有的内容都会载入内存，包括所有的图片。如果你有视图但不是要立即使用，那你就浪费了珍贵的内存。值得注意的是这不会发生在故事板中，因为故事版只会在需要的时候实例化一个视图控制器。

当你载入一个xib，所有的图像文件会被缓存，如果是开发OSX，那么音频文件也会被缓存。

如是说：

当你载入一个包含了图和声音资源引用的nib文件时，nib加载代码读取实际的图片文件和音频文件到内存中并缓存它。在OS X中，图片和音频资源被存储在已命名的缓存 中这样你可以在之后需要的时候访问它们。在iOS中，只有图片资源被缓存，访问图片，你使用NSImage或者UIImage的imageNamed:方法来访问，具体使用取决于你的平台。

显然这也发生在使用故事板的时候。尽管如此，我还不能找到这种说法的证据。如果你知道，请给我留言。

想学习更多关于故事板的更多内容吗?看看Matthijs Hollemans的 and Part 2.

5）不要阻塞主进程
你永远不应该在主线程中做任何繁重的工作。这是因为UIKIt的所有工作都在主线程中进行，比如绘画，管理触摸，和响应输出。

你的app的所有工作都在主线程上进行就会有阻塞主线程的风险，你的app会表现的反应迟钝。这是在App Store里获一星评论的快速途径!（作者卖萌..）

阻塞主线程最多的情况就是发生在你的app进行I/O操作,包括牵扯到任何需要读写外部资源的任务，比如读取磁盘或者网络。