iOS高性能编程 之性能指标
一、定义性能
从技术视角严格来说，性能是非常模糊的术语。当一个人说“这是个高性能的应用”时，其实我们无从判断他说的是什么。他是说应用消耗的内存少?应用节约了网络流量?还是说应用使用起来非常流畅?总而言之，高性能有着多重的含义和丰富的解释方式。
性能可以和我们实际开发中的多个要点关联起来。(需要测量和监控的)性能指标是其中的一个关注点，(实际上收集数据的)测量是另一个关注点。
二、性能指标
性能指标是面向用户的各种属性。每个属性可能是一个或多个可测量工程参数的一个要素。
1 内存
内存涉及运行应用所需的 RAM最小值，以及应用消耗的内存平均值和峰值。最小内存值
会严重限制硬件，而更高的内存平均值和峰值意味着更多的后台应用会被强制关闭。
同时还要确保没有泄漏内存。随时间流逝而持续增长的内存消耗意味着，应用很可能会因为内存不足的异常而崩溃。
2 电量消耗
在编写高性能代码时，电量消耗是一个需要重点处理的重要因素。就执行时间和 CPU资源的利用而言，我们不仅要实现高效的数据结构和算法，
还需要考虑其他的因素。如果某个应用是个电池黑洞，那么一定不会有人喜欢它。
电量消耗不仅仅与计算 CPU周期有关，还包括高效地使用硬件。除了要实现电量消耗最小化，还要确保不会影响用户体验。
3 初始化时间
应用在启动时应执行刚好够用的任务以完成初始化，从而满足用户的使用需求。执行这些任务消耗的时间就是应用的初始化时间。
刚好够用是一个开放式用语——正确的平衡点取决于应用的需要。
在首次使用应用时创建对象并进行初始化是一个合理的选择，例如，直到需要使用对象时才创建对象。这种方式被称为惰性初始化。
这是一种很好的策略，但也要考虑不能让用户总是在执行后续任务时等待。
下面列举了你可能想在应用初始化阶段执行的一些动作，排名不分先后。
• 检查应用是否为首次启动。• 检查用户是否已经登录。
• 如果用户已经登录，尽可能地载入之前的状态。
• 连接服务器以拉取最新的变更。
• 检查应用是否由某个深层链接唤起。如果是，还需要载入深层链接相应的UI和状态。
• 检查是否存在应用上次启动时挂起的任务，需要时恢复它们。
• 初始化后续需要使用的对象和线程池。
• 初始化依赖项(如对象关系映射、崩溃报告系统和缓存)。
这个列表可能会迅速变长，并且很难决定哪些条目一定要在启动时执行，哪些可以延后几毫秒再执行。
4 执行速度
一旦启动应用，用户总是希望它可以尽可能快地工作。一切必要的处理都应该在尽可能短的时间内完成。
例如，在照片应用中，用户通常希望看到调整亮度或对比度等简单效果的实时预览效果。因此，相应的处理需要在几毫秒内完成。
这可能需要本地计算的并行处理技术或能够将复杂任务分发到服务器。
5 响应速度
每个应用都应该快速地响应用户交互。在应用中所做的一切优化和权衡最终都应该体现在响应速度上。
App Store 中有许多应用可以完成相似或相关的任务。这为用户提供了很大的选择空间，而用户基本都会选择响应最快的应用。
6 本地存储
针对任何在服务器上存储数据或通过外部来源刷新数据的应用，开发人员应该对本地存储的使用有所规划，以便应用具备离线浏览的能力。
例如，用户都希望邮件应用能够在无网络或设备离线的情况下浏览历史邮件。
同样，新闻应用也应该可以在离线模式下显示最近更新的新闻，并标记出每条新闻是否已读。
然而，从本地存储中载入和同步数据应该迅速、便捷。这不仅需要选择要在本地缓存的数据和要优化的数据结构，还需要提供一系列的配置选项并确定数据同步的频率。
如果你的应用使用了本地存储，那么请提供一个清除数据的选项。遗憾的是，市场上的大部分应用都没有提供此选项。更让人烦恼的是，一些应用竟然会消耗数百兆的存 储空间。
用户会频繁地卸载这些应用来回收本地存储。这会导致糟糕的用户体验，从而威胁应用的成功。
一定要向终端用户提供清空本地缓存的选项。如果用户开启了 iCloud的备份功能，那么应用的数据将会消耗用户的存储限额，请谨慎使用。
7 互操作性
用户可能会使用多个应用来完成某个任务，这就需要这些应用直接提供互操作的能力。
例如，一个相册可能需要一个幻灯片应用来实现最佳的浏览体验，但需要另一个应用来编辑照片。
其中浏览照片的应用要能够将照片发送到编辑器，并接收编辑后的图片。
iOS 为实现应用间的互操作和数据共享提供了多种机制，其中包括UIActivityViewController、深层链接、MultipeerConnectivity框架，等等。
为深层链接定义良好的URL结构与编写优异的代码来解析 URL同样重要。
类似地，使用共享对话框共享数据时，精确识别用于分享的数据非常重要，同时，在处理不同数据源传入的数据时还要注意安全隐患。
如果某个应用向附近设备共享数据时需要花费很长时间准备数据，那么用户体验就会非常糟糕。
8 网络环境
移动设备会在不同网络环境下使用。为了确保能够提供最好的用户体验，你的应用应当适应各种网络条件:
• 高带宽稳定网络
• 低带宽稳定网络
• 高带宽不稳定网络
• 低带宽不稳定网络
• 无网络为用户提供进度指示或错误信息是相对合理的方式，无尽的等待或崩溃则让人无法接受。
应用会采取向终端用户传递信息的不同方式：比如音频收听应用有的应用显示了已经缓冲的信息流大小，以此告诉终端用户还需要等待多久才可以播放音乐。
有的应用仅提供了不明确的进度条，这在非流式应用中是更为常见的样式。
9 带宽
人们会在不同的网络条件下使用自己的移动设备，网速从每秒数千字节到每秒数十兆字节。
因此，带宽的优化使用是定义应用质量的另一个关键参数。此外，在高带宽网络下运行一个基于低带宽网络开发的应用可能会产生完全不同的结果。
为提高性能所做的设计并非每次都能如愿，也可能会导致相反的效果。
10 数据刷新
即使没有提供离线浏览能力，你仍然可以从服务器端周期性地刷新数据。
刷新的频率和每次传输的数据量将决定数据传输的总量。如果传输的字节数过大，那用户必然会快速耗尽自己的流量计划。
当流量消耗大到一定程度时，你的应用很可能会流失用户。
在 iOS 6.x或更低版本中，在后台运行的应用不能刷新数据。
从 iOS 7开始，应用可以在后台周期性地刷新数据。对于在线聊天类应用，持久的 HTTP连接或原生 TCP 连接可能会非常有用。
11 多用户支持
家庭成员间可能会共享移动设备，或者一个用户可能会拥有同一应用的多个账号。
例如，兄弟姐妹间可能会共享一个 iPad来玩游戏。
再比如，家庭成员可能会在旅游时配置一个设备来查收全家人的电子邮件，以减少漫游费用，尤其是在*旅游时。类似地，一个人也可能会配置多个电子邮件账号。
是否支持多个并发用户取决于产品的需要。一旦决定提供此类功能，请参考以下准则。
• 添加新用户应尽可能高效。
• 在不同用户之间更新应尽可能高效。
• 在不同用户之间切换应尽可能高效。
• 用户数据的界限应该简洁且没有bug。
12 单点登录
如果你已经创建了多个允许或需要登录的应用，那么支持单点登录(single sign-on，SSO)是非常棒的选择。
如果用户登录了一个应用，只需要点击一次，就可以登录到其他的应用中。
这个过程不仅需要支持跨应用的数据共享，还需要分享状态、跨应用同步等。例如，如果用户注销了其中某个应用，则通过 SSO登录的所有其他应用也应能注销掉。
此外，应用之间的同步应该是安全的 13 安全
安全对移动应用来说是最重要的，因为敏感信息可能会在应用间共享。因此，对所有通信以及本地数据和共享数据进行加密就显得尤为重要了。
实现安全需要更多的计算、内存和存储，但这与最大化运行速度、最小化内存和存储使用的目标相冲突。
因此，你需要在安全和其他因素之间进行权衡。
引入多个安全层会影响性能，并对用户体验造成可感知的负面影响。如何设定安全的基线需要参考对用户群体的统计分析。
此外，硬件在其中扮演了重要的角色:选择会因为不同设备的计算能力而有所不同。
14 崩溃
应用可能会而且确实会崩溃。过度优化会导致崩溃。同样，使用原始 C代码也可能会导致崩溃。
高性能的应用不仅应尽可能地避免崩溃，还应该在崩溃发生时优雅地恢复，尤其是在进行某个操作的过程中发生崩溃时。
三、应用性能分析
1 采样
顾名思义，采样(或基于探测点的性能分析)是指以一定的周期间隔采集状态，这通常需要借助工具。“iOS高性能编程之埋点与分析” 将介绍这些工具。
由于不会干扰应用的执行，因此采样可以很好地提供应用的全景图。采样的不足之处在于它不能返回 100%精确的细节。
如果采样的频率是 10毫秒，那么你就无法得知在探测点之间的 9.999毫秒内发生了什么。
采样可以作为初始的性能调研手段，并可用于跟踪 CPU和内存的使用情况。
2 埋点
通过修改代码，记录细节信息的埋点能够提供比采样更加精确的结果。
你既可以在关键部分主动埋点，也可以在性能分析或处理用户反馈时有针对性地埋点，以便解决问题。“iOS高性能编程之埋点与分析”中将深入讨论这一过程。
因为埋点需要注入额外代码，所以它一定会影响应用的性能，对内存或速度(或同时对二者)造成损害。