MetricKit 是苹果 iOS13 推出的框架，他会在一天结束后，将过去 24 小时内收集的性能数据归集在一起，并在下一次 App 启动时，通过 delegate 方法回调给我们。

一个  对象就是一个周期（24 小时）内收集到的所有性能指标的集合。如果有 24 小时以前未被收集过的数据，也会在这里一并返回给我们。所以 delegate 方法这里给到我们的是一个数组。想了解关于 MetricKit 指标的更详细的信息，可阅读 WWDC 2019 Session - 417 Improving Battery Life and Performance[1].

MetricKit 将系统收集的数据交给开发者，让我们自己去决定如何利用这些数据去打造一个更省电、性能更好的 App。

MetricKit 的接入基本属于无侵入，并且步骤十分简单。

1. 获取  单例

2. 添加订阅者

3. 实现 delegate 回调

That's it ! 注意如果接入到app中,但是打印没有数据,需要查看下手机的设置 - 隐私 - 分析与改进 - 与App开发者共享, 这个有没有打开, 这个打开了才能获取到数据.

但是一天只能获取一次, 根本无法调试, 可以通过xcode模拟一次获取MetricKit payloads. 

 虽然接入很简单, 但是没有什么必要, 苹果已经帮我们收集好并统计了数据,可以在xcode -> window -> organizer 看到统计后的数据,  如果想要具体的定制数据那就需要把这些数据上传并统计了.

系统还非常贴心的提供了MXMetricPayload转成字典和json的方法, 可以使用方便的查看信息, 数据格式示例.

• - (NSData *)JSONRepresentation;
• - (NSDictionary *)dictionaryRepresentation

系统会在一天你使用 App 的时候被动地获取、汇总 App 的性能数据。而且为了保护用户的隐私，这些数据都是匿名存放的。最终一天结束的时候，系统会将一天内收集到的这些数据打包成一个 MetricKit 的数据包，也就是前面提到的 。

 包含了许多性能指标，如下：

系统会将打包的这些数据转化成可读性更高的格式输出给我们，如下图所示：

数据分为三种聚合类型：累积的总和、平均数和分组数据。系统这样处理后，对于我们后续要针对某指标进行的一系列性能优化具备一定的指导意义。例如我们需要把某某指标的总耗时、平均耗时要下降到多少毫秒等等。

在某些性能指标方面，光有这些还不足以让我们去定位问题，找到解决问题的方案。

例如 App 的冷启动和热启动的时长数据，我们可以看到数据中冷启的次数远远比热启的次数要多。为了提高用户体验，我们当然是希望热启的次数更多。但是这种情况我们没办法根据这些数据去帮助我们定位和解决问题。

另一个典型的指标是 CPU 时间。我们可以看到 App 在前台的时间要远多于 CPU 时间。单纯根据这份报表我们没办法知道这是否是我们预期内的结果。

不用着急，MetricKit 2.0 给了我们新的指标和 API 帮助我们深入地研究这类问题，进一步明确 App 的工作负荷、性能和稳定性。

新的性能指标

MetricKit 2.0 新增了三种指标：CPU 指令、滚动卡顿和应用程序退出。

CPU 指令是  新增的一个属性  表示一个周期内 CPU 执行的指令总数。这个指标是衡量 App 在 CPU 工作负荷的绝对指标，与硬件和频率都没有关系。他能帮助我们更准确地量化 App 的总负荷。

滚动卡顿是 MetricKit 在 iOS 14 上新增的一个指标  。他指的是渲染的帧在滚动过程中的预期时间未出现在屏幕上，也就是我们俗称的掉帧。MetricKit 会为我们提供 App 中滚动卡顿的时间与滚动的时间之比来帮我们了解 App 的滚动性能。

如果想要了解怎么用 XCTest 对这个指标进行衡量，可以观看 WWDC 2020 - 10077 Eliminate animation hitches with XCTest[2].

应用程序退出是 MetricKit 在 iOS 14 上新增的一个指标 。他统计的是每天应用程序在前台、后台运行的时候退出或被杀的原因概述。

如果想要了解怎么利用这指标，可以观看 WWDC 2020 - 10078 Why is my app getting killed?[3]

新特性 - 诊断

回到数据包这张图的应用程序挂起持续时间的直方图中，我们知道应用程序挂起是用户体验极其差的一种情况，在 MetricKit 1.0 的时候我们没办法去确认根本原因，但在 MetricKit 2.0 中，我们有了新的特性 - 诊断。

诊断功能相关 API

MetricKit 2.0 为我们提供了 4 种诊断类型：应用程序挂起、崩溃、磁盘写入异常和 CPU 异常。

挂起是指应用程序长时间不响应用户输入的情况，可能是主线程繁忙或被阻塞。MetricKit 为我们提供应用程序无响应的持续时间以及主线程的调用栈。

CPU 异常诊断可以在 Xcode Organizer 中查看，诊断信息包含消耗的 CPU 时间、CPU 高使用率期间的总时长和消耗 CPU 时间的线程调用栈。与性能数据（Metric Payload）结合起来对于找出不易复现的回归非常有用。

磁盘写入异常诊断跟 CPU 异常诊断很相似，每个诊断会包含造成异常的写入总数，以及导致过多写入的线程调用栈。并且这些诊断当应用程序超过了每天 1GB 的阈值时就会生成。

崩溃诊断会把每次 App 崩溃的时候将异常信息、崩溃原因、错误访问情况下的虚拟内存信息以及崩溃调用栈给到我们。

如何使用诊断功能

MetricKit 2.0 为我们提供了新的 delegate 回调，让我们可以方便地查看诊断信息。

集成步骤也非常简单，实现 delegate 协议的方法即可。

MetricKit 会在用户使用 App 的时候同步收集诊断信息，然后每天结束的时候将他们打包成  给到我们。这样我们就拥有了同一个时间段的性能数据和诊断数据。

由于他们是一一对应的，所以我们在对性能数据产生疑问的时候就可以掏出对应的诊断数据来进行排查。由于有了这些一一的对应关系，所以 MetricKit 2.0 也随之来了一些新的基类：

•  ：所有诊断类集成的基类

•  ：诊断包，包含一天结束时的所有诊断

•  ：新数据类，用于封装当前环境的调用栈

 封装的调用栈并没有经过符号化，旨在用于设备外处理，非 debug 用。转换成 JSON 后如下所示：

如果想要了解怎么利用这些调用栈数据，可以观看 WWDC 2020 - 10057 Identify trends with the Power and Performance API[4].

Xcode Metrics Organizer

什么是 Xcode Metrics Organizer？

• 开箱即用的电量和性能分析工具
• 无须改动 App
• 数据收集满足用户隐私

Xcode Metrics Organizer 如何运作

当使用 App 时候，iOS 会记录各项指标，然后发送到苹果服务端上，并自动生成相关的可视化报告。

 可以通过xcode -> Window -> Organizer -> Metrics 查看，可以查看各项指标，并且和历史版本进行对比。

后台平均被杀次数和各项占比

 内存提供了峰值和平均内存

 电量有前后台占用情况，CPU 、定位和网络的比重等。

 历史版本启动耗时

 主线程卡顿情况

 写磁盘数据量

总的来说，MetricKit 2.0 填了 1.0 版本的一些坑，为我们提供了更多强大的 API 以及配套的工具，帮助我们去分析和解决一些疑难杂症。只要把 Metric Payload 与 Diagnostic Payload 结合起来，双剑合璧，对我们去定位线上的一些难以复现、毫无头绪的问题有很大的帮助。

参考文章: 

iOS 性能优化：使用 MetricKit 2.0 收集数据