我们假设你是一个iOS开发者并且已经开发了原生应用程序，而且愿意改进自己的代码水平。本章节我们主要来阐述应用性能主要包括哪些方面。
性能的定义
从技术层面严格说来，性能是一个模糊而不确定的概念。当有人说“这是一个高性能的应用”的时候，我们并不清楚他指的是哪方面。是说这个app占用内存较少呢还是说省流量，又或者说这个app运行较为流畅——性能可以指好多方面。
对于我而言，当谈到性能的时候，我认为是我后面所要阐述的其中一个或者几个方面。其中一部分是性能维度—————也就是我们评价性能的标准，评价指标——实际上就是搜集数据。
在该章节中，我们来看性能维度的其中一个方面——用户可视角度。我们寻找另一个部分——应用评估维度，并在第二章节中涉及到。
性能维度
内存——memory
说到内存，我指的是应用运行的时候所需要的最小运行内存RAM，以及所需的平均和最大内存。最小内存受到硬件的约束，更高的内存意味着更多的后台应用需要被杀死而最大内存则需要清理更多的后台应用。
要确保没有内存泄露。
耗电量
这是写高性能代码所需要考虑的一个重要问题，不仅需要保证数据结构和算法是高效的，还需要考虑许多其他的因素。如果你的应用耗电较快，那么没有人会欣赏它。
耗电量不仅仅是计算CPU生命周期而且关系到硬件的整体性能。
所以，在着手最小化耗电量的时候应该确保不会牺牲用户体验。
启动时间
有多少次是你对于刚刚下载安装的app并没有兴趣看第二眼的？
懒加载是一个很好的办法，但是用户并不能每次都等待初始化。
下面是在启动的时候可能会执行的操作（并没有按照顺序）：
- 检查app是否是第一次启动
- 检测用户是否登陆
- 如果用户已经登陆的话，加载之前的状态
- 向服务器请求最新的数据
- 检测app是否通过深层链接加载，如果有，那么通过深层链接来加载UI和状态
- 检测是否有上次启动的时候未处理的事情，如果有的话，处理它
- 启动
- 初始化依赖，例如ORM、崩溃报告以及缓存机制
这个列表会很快增长并且很难去决定什么应该在启动的时候操作什么应该在启动之后执行。
运行速度
一旦用户打开一个应用，肯定希望应用运行的越快越好。任何进程都应该耗费尽量少的时间。
例如，对于一个照片类app来说，我希望在编辑之后很快（几秒内）能够看到编辑的最终效果。注意：我所说的是几秒内而不是几分钟内。
响应速度
应用应该快速响应用户的交互操作。响应速度是你的应用做出的优化和权衡。
因为有众多的额app竞争者，你仅有短短的几分钟时间来吸引用户来成为用户乐于使用的app。而当其他应用与你的应用的功能相近并且切换和学习成本较低的时候，这个时间将会更加短暂和严格。
例如，当我在iTunes Store搜索2048这个游戏的时候，会有好多个APP出现。我并不确定去使用哪个APP。我下载并安装所有的，然后再删除到仅仅留下一个。在这个过程中我会考虑好多因素——加载时间、用户体验、和其他应用相比的动画的流畅性。每个应用仅有15s的时间来吸引我。
本地存储
任何应用都需要在服务器和/或者是本地存储和刷新数据来保证离线浏览。
我希望我的邮件APP能够在无网络的情况下浏览我的以前的邮件。
相似的，新闻类APP应该可以在无网络的状态下展示之前更新的新闻，也作为一个指标来区分哪些是旧的新闻哪些是已经阅读过的新闻。并且如果不是在订购的状态下，我不想去登陆。
但是，从本地异步加载这些数据应该是比较快的。
任何一直在本地存储而不清理之前数据的应用对我来说都不是好的应用。而不幸的是，市场上的大多数应用都是这种模式。更可气的是，有些应用会占用多达百兆的内存，所以当内存不够用的时候，我就会删除这些应用并且在很长的时间内都不会再次安装。
如果你仔细看上图，你会发现内存已经被用了12G，而用户可用内存只有950M。而Facebook应用则占用了超过250M的内存，并且没有可以清楚内存的选项，唯一可以清理的方法就是删除应用。另一方面，Google+只用了大约5M的本地内存，已经相当不错了。但是，它仍然没有提供清理内存大可选项。
因为这个原因，如果我已经安装了WhatsApp或者Viber之类的社交应用，我不会允许它访问相册，因为它会存储一切但是却不会清理。如果它占用较多的空间的话，其情愿不去安装它。
协同性
iOS提供了多种可供应用间协同和分享数据。UIActivityViewController、深层链接、MultipeerConnectivity框架是iOS中一些可选操作。
定义一个好的URL结构和写出好的代码一样重要。如果你的应用要花费较长的时间来准备分享给临近设备的数据的话，就会造成不好的用户体验。
网络状况
APP所有的网络状态：
- 高带宽以及持续的网络
- 低带宽但是持续的网络
- 高带宽但是不稳定的网络
- 低带宽并且不稳定网络
- 没有网络
在网络加载的时候给用户一个进度指示或者是一个错误提示，而不是让用户无穷无尽的等待或者是应用的闪退。
上图展示了不同的给用户传递信息的方式。
数据刷新
即使不能提供离线浏览功能，也需要周期性的从服务器更新数据。
在iOS6之前，后台应用是不能更新数据的。iOS7之后，后台应用是可以周期性的更新数据的。对于聊天类应用来说，持续的HTTP或者是原始的TCP链接会更有效。
安全
安全是一个应用的首要考虑因素，需要保证么有其它的app绑定安装——确保所有通信、确保数据的本地存储以及与其它app之间的数据分享。
编码是一个很好的选项，但是这样会增加数据的处理时间更不用说是内存消耗了。
所以，你需要在编码和速度之间做决策。但是决定牺牲多少的用户体验可以决定如何在这之间做决策。
必须要主要到硬件发挥着重要作用——在iPhone 4上的优化操作要比在iPhone 5C或者是iPhone 5S上的优化要困难的多。
崩溃
应用可能会崩溃。极致的优化会导致应用的崩溃。完全使用原生的C 语言也会导致应用的崩溃。
一个高性能的APP不仅会保证自身不会发生崩溃而且会在崩溃发生的时候很好地恢复——特别是在操作中发生的崩溃。
本章小结
本章我们主要讨论了高性能的含义，并且阐述了一些关键的形成和影响APP性能的属性。
剩余的章节将专注于性能的某一个单独部分。每一个章节都大体上划分为两个部分——属性的定义以及在实际的代码过程中可能会遇到的问题。
