避免臃肿的XIB文件
故事板，由iOS5引进，很快的替代XIBs。
如果你专注使用XIBs，那么让它们尽量的简单。尝试为一个试图控制器创建一个XIB，如果可能的话，把一个视图控制器的视图分层管理在单独的XIBs中。
注意当你加载一个XIB到内存的时候，它所有的内容都会载入内存，包括所有的图片。如果你有视图但不是要立即使用，那你就浪费了珍贵的内存。值得注意的是这不会发生在故事板中，因为故事版只会在需要的时候实例化一个视图控制器。
当你载入一个xib，所有的图像文件会被缓存，如果是开发OSX，那么音频文件也会被缓存。
调整图像视图中的图像尺寸（缩放图片会非常的耗时）
如果你用UIImageView呈现app束中的图片时，确认图片和UIImageView的尺寸相同。缩放图片会非常的耗时，特别是当你的UIImageView被嵌入UIScrollView。
如果图片是从远程服务器上下载的，有时你没法控制图片尺寸，或者你不能在服务器上在下载之前缩放它。在这些情况下你可以在图片下载完成后手动缩放一次，最好是在后台进程中。然在UIImageView中使用调整尺寸之后的图片。
重用大开销对象
有的对象的初始化非常慢--NSDateFormatter和NSCalendar是两个例子，但是你不能避免使用它们，当你从JSON/XML响应中解析日期时。
避免使用这些对象时的性能瓶颈，试着尽可能的重用这些对象。你可以加入你的类中成为一个属性，也可以创建为静态变量。
注意如果你选择了第二种方式，这个对象在app运行的时候会一直保持在内存里，像单例一样。
同样要记住设置一个NSDateFormatter的日期格式几乎跟创建一个新的一样慢。因此，如果在你的应用中你频繁需要处理多个日期格式，你的代码应该获利于初始化创建，重用，多个NSDateFormatter对象。
选择正确的数据存储方式
当要存储和读取大数据的时候你的选择是什么？
你有一些选项，包括：
使用NSUserDefaults存储它们。
存储在结构化文件中，XML，JSON，Plist格式中。
是用NSCoding打包？
存储在本地数据库,如SQLite
使用NSData
NSUserDefaults有什么问题呢？虽然说NSUserDefaults是好而且简单，它确实很好只有当你有很少的数据要存(像你的等级，或者音量是开还是关)。一旦你接触大数据，会有更好的其他选择。
保存在结构化文件中也可能有问题。一般的，在解析之前，你需要加载整个文件到内存中，这是非常耗时的操作。你可以使用SAX去处理XML文件，但是那是一个复杂的作法。同时你加载了全部的对象进内存，其中有你想要的也有不想要的。
那么NSCoding怎么样呢?不幸的是，它也同样要读写文件,跟上面说的方法有同样的问题。
你最好的解决方法是使用SQLite或者Core Data.通过这些技术，你可以执行特定的查询只加载需要的对象,避免强力搜索方法来检索数据。
重用和延迟加载视图
越多的视图就有越多的绘图操作，最终意味着更多的CPU和内存开销。这说得特别对如果你的app嵌入很多视图在UIScrollView时。
管理这个的技巧是去模拟UITableView和UICollectionView的行为:不要一次创建所有的子视图，而是在需要的时候创建，然后把他们假如重用队列中。
这样，你只需要在视图浮动时配置你的视图，避免昂贵的资源分配开销。
视图创建的时机问题也同样适用于你app的其他地方。试想当你点击一个button时呈现一个视图的情景。至少有两种方法:
1.屏幕第一次载入时创建视图并隐藏它。当你需要的时候，显示出来。
2.需要呈现的时候一次创建视图并显示它。
每种方法都有各自的优缺点
使用第一种方法，你消耗了更多内存因为从创建开始到它释放前你都保持了它的内存，然而，当你点击button的时候，你的app会表现得响应快速因为它只需要更改视图的可视化属性。
使用第二种方法会有相反的效果，在需要的时候创建视图，消耗更少的内存，但当button被点击时应用会表现得不那么响应快速。
启用Gzip压缩
大量和持续增长的app依赖从远端服务器或者外部APIs获取的外部数据。某些时候你可能会开发一些需要下载XML，JSON，HTML或者其他文本格式的应用。
问题是移动设备不能保证网络环境，用户可能一分钟在边缘网络，下一分钟又是3G网络，无论什么情况下，你不想你的用户一直等待。
一个减少文件大小并加速下载的网络资源的方法是同时在你的服务器和客户端上使用GZIP压缩，对于文本数据这种有高比率压缩的数据来说非常有用。
好消息是iOS早已默认支持GZIP压缩，如果你是使用NSURLConnection或者建立在这之上的框架比如AFNetworking。更好的消息是一切云服务提供商像Google App Engine早已发送压缩之后的响应数据。
适当的设置背景图片
像iOS编码的其他工作一样，至少有两种不同方式去替换你视图的背景图片。
你可以设置你的视图的背景颜色为UIColor的colorWithPatternImage创建的颜色。
你可以添加一个UIImageView子试图给View
如果你有全尺寸的背景图片，你绝对要用UIImageView，因为UIColor的colorWithPatternImage是重复的创建小的模式图片，在这种情况下用UIImageView方式会节约很多内存。
尽管如此，如果你计划用模式图片背景，你应该是用UIColor的colorWithPatternImage。它更快一些，而且这种情况不会使用很多内存。
优化你的表格视图
表格视图需要快速的滚动，如果不能，用户能确切注意到很滞后。
为了让你的表格视图流畅的滚动，保证你实现了下列的建议。
通过正确的reuseIdentifier重用cells
尽量多的设置views为不透明，包括cell本身。
避免渐变，图像缩放，屏幕以外的绘制。
如果行高不总是一样，缓存它们。
如果cell显示的内容来自网络，确保异步和缓存。
使用shadowPath来建立阴影。
减少子视图的数目。
cellForRowAtIndexPath:中做尽量少的工作，如果需要做相同的工作，那么只做一次并缓存结果。
使用适当的数据结构存储你要的信息，不同的结构有对于不同的操作有不同的代价。
使用rowHeight，sectionFooterHeight，sectionHeaderHeight为常数，而不是询问代理。
减少你的网络占用
UIWebView是非常有用的.它非常容易用来显示web内容，甚至创建你app的视窗。这些都是标准UIKit空间很难做到的。
尽管如此，你可能注意你可以用在你的app中的UIWebView组件并没有Apple的Safari app快。这是Webkit’s的Nitro引擎的限制使用。
所以为了获得最佳的性能，你需要调整你的HTML。第一件事是尽可能多的避免Javascript，包括避免大的框架比如jQuery。有时使用vanilla Javascript取代依赖的框架会快很多。
随时随地遵循异步加载Javascript文件的实践。特别当它们不直接影响到页面表现的时候，比如分析脚本。
最后，总是要意识到你在用的图片，保持图片的正确尺寸。正如这个教程前面所提到的，利用精灵表的优势来节约内存和提高速度。
加速启动时间
App的启动时间非常重要，特别是第一次启动的时候。第一影响意味着太多了！
最大的事情是保证你的App开始尽量的快，尽量的多的执行异步任务，不如网络请求，数据库访问，或者数据解析。
尽量避免臃肿的XIBs，因为你在主线程中加载。但是在故事板中不会有这个问题，所以尽量用它们。
Note:监察人不会运行你的app在Xcode调试中,所以确保测试启动性能时断开与Xcode的连接。