高性能iOS开发--移动应用的性能

打算把《高性能iOS开发》这本书公开出来，供大家学习。这是第一章，感兴趣的可以订阅我的专题 高性能iOS应用开发。

本书假设你是 iOS 开发人员，有长期开发原生 iOS 应用的经验，并且希望能够从众人中脱 颖而出，跻身于顶尖开发人员之列。

参考以下统计数据。
• 应用首次工作出错以后， 79% 的用户只会再重试一两次。
• 当应用载入时间超过 3 秒时， 25% 的用户会放弃使用该应用。
• 31% 的用户会将糟糕的体验转告他人。

这些数据强调了性能对应用的重要性。应用能否被用户所认可不仅仅取决于其功能，还取 决于当与用户交互时，应用能否提供流畅的体验。

几乎完成任意特定任务的应用都能在 App Store 中找到大量的替代品。但用户只会坚持使 用其中的某一款。被选中的这一款要么无可取代，要么极少出现故障且性能格外出众。

性能会受许多重要因素所影响，这些因素包括内存消耗、网络带宽效率以及用户界面的响 应速度。我们先概述不同类型的性能特征，然后再对它们进行测量。

1.1 定义性能

从技术视角严格来说，性能是非常模糊的术语。当一个人说“这是个高性能的应用”时， 其实我们无从判断他说的是什么。他是说应用消耗的内存少？应用节约了网络流量？还是 说应用使用起来非常流畅？总而言之，高性能有着多重的含义和丰富的解释方式。

性能可以和我们后续讨论的多个要点关联起来。（需要测量和监控的）性能指标是其中的 一个关注点，（实际上收集数据的）测量是另一个关注点。

我们将在第 11 章深入探索测量的过程。提高工程参数的使用率是本书第二部分和第三部 分的重点难题。

1.2 性能指标

性能指标是面向用户的各种属性。每个属性可能是一个或多个可测量工程参数的一个要素。

1.2.1 内存

内存涉及运行应用所需的 RAM 最小值，以及应用消耗的内存平均值和峰值。最小内存值 会严重限制硬件，而更高的内存平均值和峰值意味着更多的后台应用会被强制关闭。

同时还要确保没有泄漏内存。随时间流逝而持续增长的内存消耗意味着，应用很可能会因 为内存不足的异常而崩溃。

我们会在第2章中对内存进行深入讨论。

1.2.2 电量消耗

在编写高性能代码时，电量消耗是一个需要重点处理的重要因素。就执行时间和 CPU 资 源的利用而言，我们不仅要实现高效的数据结构和算法，还需要考虑其他的因素。如果某 个应用是个电池黑洞，那么一定不会有人喜欢它。

电量消耗不仅仅与计算 CPU 周期有关，还包括高效地使用硬件。除了要实现电量消耗最 小化，还要确保不会影响用户体验。

我们将在第 3 章讨论这个问题。

1.2.3初始化时间

应用在启动时应执行刚好够用的任务以完成初始化，从而满足用户的使用需求。执行这些 任务消耗的时间就是应用的初始化时间。 刚好够用是一个开放式用语——正确的平衡点取 决于应用的需要。

在首次使用应用时创建对象并进行初始化是一个合理的选择，例如，直到需要使用对象时 才创建对象。这种方式被称为惰性初始化。这是一种很好的策略，但也要考虑不能让用户 总是在执行后续任务时等待。

下面列举了你可能想在应用初始化阶段执行的一些动作，排名不分先后。

• 检查应用是否为首次启动。
• 检查用户是否已经登录。
• 如果用户已经登录，尽可能地载入之前的状态。
• 连接服务器以拉取最新的变更。
• 检查应用是否由某个深层链接唤起。如果是，还需要载入深层链接相应的 UI 和状态。
• 检查是否存在应用上次启动时挂起的任务，需要时恢复它们。 • 初始化后续需要使用的对象和线程池。
• 初始化依赖项（如对象关系映射、崩溃报告系统和缓存）。

这个列表可能会迅速变长，并且很难决定哪些条目一定要在启动时执行，哪些可以延后几 毫秒再执行。

我们将在第 5 章探讨这个问题。

1.2.4 执行速度

一旦启动应用，用户总是希望它可以尽可能快地工作。一切必要的处理都应该在尽可能短 的时间内完成。

例如，在照片应用中，用户通常希望看到调整亮度或对比度等简单效果的实时预览效果。 因此，相应的处理需要在几毫秒内完成。

这可能需要本地计算的并行处理技术或能够将复杂任务分发到服务器。我们将在第 第 6 章介绍这些主题，并在第 7 章和第 11 章介绍相关工具。

1.2.5 响应速度

每个应用都应该快速地响应用户交互。在应用中所做的一切优化和权衡最终都应该体现在 响应速度上。

App Store 中有许多应用可以完成相似或相关的任务。这为用户提供了很大的选择空间，而 用户基本都会选择响应最快的应用。

第 4 章介绍了用并行处理技术优化本地执行。第 5 章和第 6 章介绍了实现流畅交互的最佳 实践。第 10 章将探索如何对应用进行测试。

1.2.6 　本地存储

针对任何在服务器上存储数据或通过外部来源刷新数据的应用，开发人员应该对本地存储 的使用有所规划，以便应用具备离线浏览的能力。

例如，用户都希望邮件应用能够在无网络或设备离线的情况下浏览历史邮件。

同样，新闻应用也应该可以在离线模式下显示最近更新的新闻，并标记出每条新闻是否已读。

然而，从本地存储中载入和同步数据应该迅速、便捷。这不仅需要选择要在本地缓存的数 据和要优化的数据结构，还需要提供一系列的配置选项并确定数据同步的频率。

如果你的应用使用了本地存储，那么请提供一个清除数据的选项。遗憾的是，市场上的大 部分应用都没有提供此选项。更让人烦恼的是，一些应用竟然会消耗数百兆的存储空间。 用户会频繁地卸载这些应用来回收本地存储。这会导致糟糕的用户体验，从而威胁应用的 成功。

如图 1-1 所示，超过 12GB 的空间已经被使用了，留给用户的内存还有 950MB。 其实，大 部分的数据可以安全地从本地删除。这些应用应该提供清理缓存的选项。

一定要向终端用户提供清空本地缓存的选项。 如果用户开启了 iCloud 的备份功能，那么应用的数据将会消耗用户的存储限 额，请谨慎使用。

第7章、第8章和第9章会介绍本地存储相关的话题。

1.2.7 　互操作性

用户可能会使用多个应用来完成某个任务，这就需要这些应用直接提供互操作的能力。例 如，一个相册可能需要一个幻灯片应用来实现最佳的浏览体验，但需要另一个应用来编辑 照片。其中浏览照片的应用要能够将照片发送到编辑器，并接收编辑后的图片。

iOS 为实现应用间的互操作和数据共享提供了多种机制，其中包括 UIActivityViewController 、 深层链接、 MultipeerConnectivity 框架，等等。

为深层链接定义良好的 URL 结构与编写优异的代码来解析 URL 同样重要。类似地，使用 共享对话框共享数据时，精确识别用于分享的数据非常重要，同时，在处理不同数据源传 入的数据时还要注意安全隐患。

如果某个应用向附近设备共享数据时需要花费很长时间准备数据，那么用户体验就会非常 糟糕。

我们会在第 8 章中讨论这些内容。

1.2.8　网络环境

移动设备会在不同网络环境下使用。为了确保能够提供最好的用户体验，你的应用应当适 应各种网络条件：

• 高带宽稳定网络
• 低带宽稳定网络
• 高带宽不稳定网络
• 低带宽不稳定网络
• 无网络

为用户提供进度指示或错误信息是相对合理的方式，无尽的等待或崩溃则让人无法接受。信息流大小， 以此告诉终端用户还需要等待多久才可以播放音乐。 MoneyControl 和 Bank图 的屏幕截图展示了向终端用户传递信息的不同方式。 应用显示了已经缓冲的of America 等其他应用仅提供了不明确的进度条，这在非流式应用中是更为常见的样式。

我们将在第7章中深入探讨此话题。

1.2.9 　带宽

人们会在不同的网络条件下使用自己的移动设备，网速从每秒数千字节到每秒数十兆字节。

因此，带宽的优化使用是定义应用质量的另一个关键参数。此外，在高带宽网络下运行一 个基于低带宽网络开发的应用可能会产生完全不同的结果。

2010 年左右，我和我的团队正在印度开发一款应用。由于处于低带宽网络，应用的本地初 始化速度要比从服务器端载入资源快得多，于是我们针对这种情况进行了优化。

然而，当这款应用投入韩国市场时，我们对它进行了测试，结果却让人大跌眼镜。之前所 进行的所有优化几乎毫无意义，我们不得不重写了大部分可能导致资源和数据冲突的相关 代码。

为提高性能所做的设计并非每次都能如愿，也可能会导致相反的效果。

第 7 章包含了优化使用带宽的最佳实践。

1.2.10 数据刷新

即使没有提供离线浏览能力，你仍然可以从服务器端周期性地刷新数据。刷新的频率和每 次传输的数据量将决定数据传输的总量。如果传输的字节数过大，那用户必然会快速耗尽 自己的流量计划。当流量消耗大到一定程度时，你的应用很可能会流失用户。

在 iOS 6.x 或更低版本中，在后台运行的应用不能刷新数据。从 iOS 7 开始，应用可以在后 台周期性地刷新数据。对于在线聊天类应用，持久的 HTTP 连接或原生 TCP 连接可能会非 常有用。

第5章和第7章会介绍这部分内容。

1.2.11多用户支持

家庭成员间可能会共享移动设备，或者一个用户可能会拥有同一应用的多个账号。例如， 兄弟姐妹间可能会共享一个 iPad 来玩游戏。再比如，家庭成员可能会在旅游时配置一个设 备来查收全家人的电子邮件，以减少漫游费用，尤其是在境外旅游时。类似地，一个人也 可能会配置多个电子邮件账号。

是否支持多个并发用户取决于产品的需要。一旦决定提供此类功能，请参考以下准则。

• 添加新用户应尽可能高效。
• 在不同用户之间更新应尽可能高效。
• 在不同用户之间切换应尽可能高效。
• 用户数据的界限应该简洁且没有 bug。

图 展示了两个提供了多用户支持的应用。 左边和右边分别展示了 Google 和 Yahoo 应1-3 用的账号选择功能。

第9章将介绍如何在应用支持多用户的同时保障安全以及其他内容。

1.2.12 　单点登录

如果你已经创建了多个允许或需要登录的应用，那么支持单点登录（single sign-on，SSO） 是非常棒的选择。 如果用户登录了一个应用， 只需要点击一次， 就可以登录到其他的应 用中。

这个过程不仅需要支持跨应用的数据共享，还需要分享状态、跨应用同步等。例如，如果 用户注销了其中某个应用，则通过 SSO 登录的所有其他应用也应能注销掉。

此外，应用之间的同步应该是安全的。

第 9 章将会介绍这部分内容。

1.2.13 安全

安全对移动应用来说是最重要的，因为敏感信息可能会在应用间共享。因此，对所有通信 以及本地数据和共享数据进行加密就显得尤为重要了。

实现安全需要更多的计算、内存和存储，但这与最大化运行速度、最小化内存和存储使用 的目标相冲突。

因此，你需要在安全和其他因素之间进行权衡。

引入多个安全层会影响性能，并对用户体验造成可感知的负面影响。如何设定安全的基线 需要参考对用户群体的统计分析。此外，硬件在其中扮演了重要的角色：选择会因为不同 设备的计算能力而有所不同。

第 9 章将会深入介绍安全。

1.2.14崩溃

应用可能会而且确实会崩溃。过度优化会导致崩溃。同样，使用原始 C 代码也可能会导致 崩溃。

高性能的应用不仅应尽可能地避免崩溃，还应该在崩溃发生时优雅地恢复，尤其是在进行 某个操作的过程中发生崩溃时。

第12章会深入讨论崩溃报告、检测和分析。

1.3 应用性能分析

我们在前面讨论过一些参数，通过测量它们来分析应用的方式有两种：采样和埋点。接下 来我们将逐一介绍。

1.3.1 采样

顾名思义，采样（或基于探测点的性能分析）是指以一定的周期间隔采集状态，这通常需 要借助工具。我们将在 11.2 节中介绍这些工具。由于不会干扰应用的执行，因此采样可以 很好地提供应用的全景图。采样的不足之处在于它不能返回 100% 精确的细节。如果采样 的频率是 10 毫秒，那么你就无法得知在探测点之间的 9.999 毫秒内发生了什么。

采样可以作为初始的性能调研手段，并可用于跟踪 CPU 和内存的使用情况。

1.3.2 埋点

通过修改代码，记录细节信息的埋点能够提供比采样更加精确的结果。你既可以在关键部 分主动埋点，也可以在性能分析或处理用户反馈时有针对性地埋点，以便解决问题。 1.4.3 节将深入讨论这一过程。

因为埋点需要注入额外代码，所以它一定会影响应用的性能，对内存或速度 （或同时对二者）造成损害。

1.4 　测量

现在，我们已经确定了需要测量的参数，并且研究了测量所需要的不同类型的分析。我们 先简单了解一下如何实现测量。

通过测量性能并找出真正存在问题的地方，你可以避免掉入过早优化的陷阱。高德纳曾经 这样描述过早优化：

真正的问题在于，程序开发人员为提升程序效率在错误的方向和时间点浪费了太 多时间；过早优化是编程领域的万恶（至少是绝大多数的恶）之源。 2

1.4.1 设置工程与代码

接下来，我们将建立一个工程，以便在开发和生产阶段测量已经定义好的参数。针对工程 配置、安装和代码实现共有三类任务。

•构建与发布
确保能够轻松地构建和发布应用。

•可测试性
确保你的代码能够同时在模拟数据和真实数据之上工作，其中包括能够模拟真实场景的 隔离环境。

•可跟踪性
确保你能够通过明确问题发生的位置和代码行为来处理错误。

接下来将逐一讨论这些设置项。

1. 构建与发布

构建和发布是直到最近才出现的话题。好在由于对灵活和敏捷的强烈需求，系统和工具得 到了改进。改进后的系统和工具现在可以加速拉取依赖信息，加速构建和发布用于测试或 企业分发的产品，也可以为公众发布而提高提交文件到 iTunes Connect 的速度。

2000 年， Joel Spolsky 在其发表的一篇博文（http://www.joelonsoftware.com/articles/fog0000000043. html）中提出了一个问题： “你能（从源码）一键构建自己的应用吗？”这个问题现在依 然成立， 且问题的答案很可能会决定你在发现缺陷或瓶颈后改进质量和解决性能问题的 速度。

基于 Ruby 语言实现的 CocoaPods（https://cocoapods.org）实际上是 Objective-C 和 程的依赖管理器。 3 CocoaPods 与 Xcode 命令行工具相集成，可用于构建与发布。

2. 可测试性

每个应用都包含多个协同工作的组件。一个设计良好的系统应该遵循低耦合和高内聚，并允许替换任意或全部组件的依赖。

可以通过模拟依赖项目对每个组件进行隔离测试。一般来说，测试有两种类型。

• 单元测试
验证每个代码单元在隔离环境下的操作。常见的做法是，在特定的环境中用不同的输入 数据反复地调用一些方法，以评估代码的表现。

•功能测试
验证组件在最终集成的安装包中的操作。可以在软件的最终发布版本中验证，也可以在 某个为测试而构建的参考应用中验证。

我们将在第 10 章中深入讨论测试。

3. 可跟踪性

在开发阶段，埋点可以帮助我们确定性能优化的优先级、提高对问题现场的还原能力，并 提供更多的调试信息。崩溃报告专注于从软件的产品版本中收集调试信息。

1.4.2 设置崩溃报告

崩溃报告系统收集用于分析应用的调试日志。市面上有数十种崩溃报告系统。本书选用了 Flurry（http://www.furry.com） ，但这并不代表我对其他系统有任何偏见。选用 Flurry 的主要 原因是，只用一个 SDK 就可以同时实现崩溃报告和埋点。我们将在第 12 章深入介绍埋点。

要想使用 Flurry， 需要在 www.furry.com 中建立一个账户，得到一个 API 密钥，然后下载 并设置 Flurry SDK。 例 1-1 展示了初始化 Flurry 的代码。

例 1-1　 在应用委托中配置崩溃报告

#import "Flurry.h" 
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { 
[Flurry setCrashReportingEnabled:YES];
[Flurry startSession:@"API_KEY"];//用账户关联的API密钥（可以在Flurry的Dashboard中找到）替换 API_KEY 。
}

崩溃报告系统会用 NSSetUncaughtExceptionHandler 方法设置全局的异常处 理器。使用自定义的处理器则会失效。

如果希望继续使用自己的处理器，那么你需要在崩溃报告系统初始化之后再 进行设置。此外，还可以通过 NSGetUncaughtExceptionHandler 方法得到崩 溃报告系统所设置的处理器。

1.4.3　对应用埋点

对应用进行埋点是了解用户行为的一个重要步骤， 但更重要的目的是识别应用的关键路 径。注入特定的代码以记录关键指标是提升应用性能的重要步骤。

对依赖进行抽象化和封装是个好主意。这样就可以在最后再进行切换，甚至 可以在作出最终决定之前同时使用 多个系统 。这在项目处于评估阶段且存在 多个备选方案时尤为有用。

如例1-2 所示， 我们将增加一个名为 HPInstrumentation 的类来封装埋点。 现在， 我们用 NSLog 登录控制台，并向服务器发送细节。

例1-2 HPInstrumentation 类封装了埋点 SDK

//HPInstrumentation.h 
@interface HPInstrumentation: NSObject

+(void)logEvent:(NSString *)name; +(void)logEvent:(NSString *)name withParameters:(NSDictionary *)parameters;

@end

//HPInstrumentation.m 
@implementation HPInstrumentation

+(void)logEvent:(NSString *)name { NSLog(@"%@", name); [Flurry logEvent:name]; }

+(void)logEvent:(NSString *)name withParameters:(NSDictionary *)parameters { NSLog(@"%@ -> %@", name, params); [Flurry logEvent:name withParameters:parameters]; }

@end

先在应用生命周期的三个关键阶段进行埋点（见例1-3） ：

• 每当应用进入前台， applicationDidBecomeActive: 方法会被调用
• 每当应用进入后台， applicationDidEnterBackground: 方法会被调用
• 如果应用收到低内存警告， applicationDidReceiveMemoryWarning: 方法会被调用

出于娱乐的目的，我们在HPFirstViewController 中添加一个按钮，点击该按钮将导致应用崩溃。

例1-3　在应用委托中的基础埋点

- (void)applicationDidBecomeActive:(UIApplication *)application 
{
[HPInstrumentation logEvent:@"App Activated"];

}

- (void)applicationDidEnterBackground:(UIApplication *)application 
{

[HPInstrumentation logEvent:@"App Backgrounded"]; } - (void)applicationDidReceiveMemoryWarning:(UIApplication *)application {

[HPInstrumentation logEvent:@"App Memory Warning"];
}

我们将这些事件分别命名为 App Activated 、 App Backgrounded 和 App Memory Warning 。你 可以选择自己喜欢的任意名称，也可以使用数字。

埋点不应该取代日志。日志可以非常详细。但因为向服务器报告时会消耗网 络资源，所以你应该尽可能少地埋点。

因此，只对你和其他工程或产品团队的成员感兴趣的事件进行埋点是非常重 要的。（这些事件要包含足够多的数据以满足重要报告的需要。） 埋点和过度埋点之间并没有清晰的分界线。 一开始应仅对少量报告进行埋 点，然后随着时间的推进逐步增加埋点的覆盖率。

接下来添加一个UI控件，让它能够触发一个崩溃，这样我们就可以看到崩溃报告。

图 1-4 展示了崩溃按钮的 UI。 例 1-4 展示了连接 Touch Up Inside 事件和 crashButtonWasClicked: 方法的代码。

例 1-4　 抛出异常使得应用崩溃

- (IBAction)crashButtonWasClicked:(id)sender 
{
[NSException raise:@"Crash Button Was Clicked" format:@""];
}

让我们与应用进行交互，从而产生一些事件。

(1) 安装并运行应用。
(2) 将应用切换到后台。
(3) 将应用切换到前台。
(4) 多次重复第 2 步和第 3 步。
(5) 点击 Generate Crash 按钮，导致应用崩溃。
(6) 再次运行应用。直到此时崩溃报告才会实际发送到服务器。

第一批埋点事件和崩溃报告会在稍后上报到服务器并得到处理。报告可能在一段时间后才 能在Flurry 的 Dashboard中出现。 然后你可以进入 Dashboard 查看这些事件和崩溃报告。你应该会看到与下面截图类似的内容，以下截图是为我的应用从 Dashboard 中截取的。

图1-5展示了用户会话，用户会话指的是有多少用户在一天中至少启动了应用一次。多次运行可能被认定是同一个会话，也可能不会被认定是同一个会话，这主要取决于多次运行 之间的时间间隔。

图 展示了每个埋点事件的详细崩溃情况。这份报告更加有用，因为它可以让我们深入了解应用的使用率。比如，它精确地指出了应用中的哪些部分比其他部分使用频度更高。

如果查看图 1-7 中的崩溃报告，你会注意到其中的download链接，这个链接可以下载崩溃日志。点击链接，下载日志。看着很熟悉是吗？

在iTunes Connect中查看崩溃报告

Apple 提供了下载崩溃报告的服务。你可以利用该服务下载 TestFlight 或 App Store 所 发布的应用的最近版本，也可以构建相应的崩溃报告。理论上来说，有了这个服务就 不再需要第三方的崩溃报告工具了。

但有一个棘手的问题。除非用户同意与开发人员分享崩溃数据，否则崩溃日志不会发 送至 Apple。TestFlight 用户自动同意了分享崩溃数据。但产品应用（通过 App Store 分发的应用）必须由用户开启分享。

要想实现这一点， 用户需要进入设置应用， 打开“隐私→诊断与用量”（Privacy → Diagnostics & Usage） ，然后选择“自动发送”（Automatically Send）选项（见图 1-8） 。

这里存在两个问题。首先，用户不能在你的应用内设置这个选项，他们需要进入设置 应用并进入特定的设置项。第二点更为重要，这项设置会对所有的应用生效：用户无 法只为特定的应用发送崩溃报告。

使用第三方的崩溃报告工具可以确保你能够控制整体体验和用户设置，以便向服务器 发送崩溃报告。

1.4.4 　日志

日志是无价之宝，可以用于了解应用发生了什么事。

日志和埋点之间存在着细微的差别。埋点可以看作日志的子集。被埋点的任何数据都应该 记录在日志中。

埋点承担了为聚合分析发布关键性能数据的职责，日志则提供了用于在不同级别跟踪应用 的细节信息，比如 debug 、 Verbose 、 info 、 warning 和 Error 。日志的记录会贯穿应用的整 个生命周期，而埋点只应该用在开发的特定阶段。

埋点数据会发送到服务器，日志是记录在设备本地。

就日志而言，我们可以通过 CocoaPods 引入 CocoaLumberjack 来使用。

例 1-5 展示了添加到 Podfile 的一行代码，以便引入库。完成相关改动后，运行 pod update 以更新 Xode 的工作空间。

例 1-5　 为 CocoaLumberjack 配置 Podfile

pod 'CocoaLumberjack', '~> 2.0'

CocoaLumberjack 是一个扩展性很强的框架，捆绑了一系列内置的日志记录器，这些记录器 可以向不同的目标发送信息。 例如， 使用 DDASLLogger 可以向 Apple System Log（ASL， NSLog 方法的默认位置）记录日志。类似地，使用 DDFileLogger 可以向文件记录日志。可 以在应用运行期间配置记录器。

DDLog 宏指令可以用于记录某个特定层级的日志。层级越高，信息越重要。最高级 别是 Error ，最低级别是 Verbose 。实际记录消息的最低层级可以配置在每个文件层级、每 个 配置层级、每个日志器层级或全局。

以下的宏指令可供使用。

• DDLogError
表示不可恢复的错误。

• DDLogWarn
表示可恢复的错误。

• DDLogInfo
表示非错误的信息。

• DDLogDebug
表示数据主要用于调试。

• DDLogVerbose
几乎提供了所有的细节，主要用于跟踪执行过程中的控制流。

这些宏指令有着与 NSLog 相同的签名。这意味着你可以直接用适合的 DDLog 调用来 取代 NSLog 。

例 1-6 展示了配置和使用这个库的代表性代码。

例 1-6　配置和使用 CocoaLumberjack

//设置 
-(void)setupLogger {//最有可能在 application:didFinishLaunchingWithOptions: 调用这个方法。

#if _DEBUG

[DDLog addLogger:[DDASLLogger sharedInstance]]; //当连接到 Xcode 时，只在调试模式下将日志记录到 ASL。 你不会希望这类日志在产品 环境的设备中记录下来。
#endif

DDFileLogger fileLogger = [[DDFileLogger alloc] init]; //文件日志记录器， 配置为每 24 小时（ rollingFrequence ）创建一个新文件， 同时最多 允许创建 个文件（ maximumNumberOfLogFiles ）。
fileLogger.rollingFrequency = 60 * 60 * 24;

fileLogger.logFileManager.maximumNumberOfLogFiles = 7; 
[DDLog addLogger:fileLogger]; //注册日志记录器。

} //在一些文件中使用记录器 
#if _DEBUG //将日志的级别（ ddLogLevel ）设置为合适的值。这里我们可以这样设置：开发阶段输出 最多的细节；内部测试阶段（ MY_INTERNAL_RELEASE 是一个自定义的标记）输出少量细 节信息（ debug level ）；面向终端用户的分发包只输出错误信息。
static const  DDLogLevel ddLogLevel = DDLogLevelVerbose;

 #elsif MY_INTERNAL_RELEASE

static const DDLogLevel ddLogLevel = DDLogLevelDebug; #else

static const DDLogLevel ddLogLevel = DDLogLevelWarn; 
#end -(void)someMethod {
 DDVerbose(@"someMethod has started execution");//记录一些信息。在 DDLogLevelVerbose 级别中，所有信息都会被记录；在 DDLogLevelWarn 级别中，只有错误信息会被记录。
 //... 
DDError(@"Ouch! Error state. Don't know what to do"); 
//... 
DDVerbose(@"someMethod has reached its end state"); 
}

建议在应用委托的 application:didFinishLaunchingWithOptions: 回调中 调用此方法。

1.5 小结

我们在本章了解了影响应用性能的因素。性能不仅涉及用户体验，更关系到应用能否高效 运行。

我们查看了一些影响应用性能的关键属性。在包含测量和追踪的各项指标中，这些属性成 为了性能的关键指示器。

我们讨论了性能分析的概念，并宽泛地介绍了两类分析技术：采样与埋点。还介绍了一些 代码改动，以便对应用进行埋点。然后我们通过使用被埋点的应用来触发事件。

最后，我们在类中添加一些样板代码以帮助进行埋点和记录日志。

第二部分的章节主要关注定义性能的每个属性。每章都从定义和评审属性开始，然后讨论 一些潜在的问题，并用实际的代码来解决这些问题。