打造出色的性能分析体验

（开发优秀的分析体验 通过自定义Instruments讲述你的故事）

下午好 欢迎参加我们的演讲 开发优秀的分析体验 我是Daniel Delwood 稍后同事 Kacper Harasim会加入我 今天我们在此要讲开发优秀的自定义 Instruments程序包

作为开发人员 我们都致力于创建卓越的、 可维护的、模块化的 并且可重复利用的代码 我们都使用其它人设计的框架 我们希望其它人也能使用 我们所创建的代码

良好的API设计和文档 对于用户使用你的框架的体验来说 至关重要 但我希望你们也考虑一下开发 Instruments程序包

要了解为什么 让我们以Metal为例 API设计是中枢 API的调用 围绕一组核心概念、 设备、命令缓冲区、纹理等等

但这并不是全部 API界面表达了什么是可能的 但文档和示例代码 是其他人了解如何用这些概念 构造一个优秀的app的方式

但这也不是全部 这两者结合可以帮助开发人员 使用你的类或框架编写代码 但如果出现错误怎么办？ 嗯 自定义Instruments 对于你作为作者来说是一种 教会其他人如何调试、优化 并真正充分利用你的APIs的方式 若你用过Instruments中 的Metal系统追踪模板 你肯定了解了其中一些可能的情况 创建可视化工具 并针对你所定义的概念和API 进行特别设计

Instruments程序包 是建立透明性的一种方式 在底层 你的框架可以对 Instruments程序包进行测试、 可理解并且支持良好 花时间来创建一个 自定义Instrument 可以帮助你建立自信和信任 坚信代码正在执行你所期待的操作

工具也是开发成本模型的一个好方式 你可以了解哪个调用消耗较大 哪个调用消耗很小 当出现性能问题时 它们是区分框架错误 或客户代码错误的最佳方式

最重要的是Instrument 可以让你讲述你的故事 Instruments程序包 可以让你有机会解释正在发生什么 从而帮助可视化重要的指标 并在用户遇到问题时 帮助他们快速查找问题 今天我们要讲 如何创建优秀的检测 从里到外 从核心开始讲 即在框架中开发跟踪点 然后在跟踪点上创建架构 最后在讲可视化和Instrument UI前 讲一下在Instruments内建模和构造 我们今天要按顺序讲追踪、建模 和可视化 让我们现在开始吧 讲一下OSSignpost

OSSignpost是2018年 引入的一个低消耗的追踪基元 路标分为两种：点事件和区间 现在它们支持在参数中 记录任意一种数据 通过像printf一样的 formatString 与printf不同 所有路标都以静态字符串命名

现在在Swift中 OSSignpost只是其中一个核心API 它有三种类型：开始、结束和事件 在C语言中 它们的界面 通过三个有用的宏命令表达

现在重点是要注意 OSSignpost建立在OSLog上 意思是许多追踪行为和可配置性 都由所提供的日志句柄决定 日志句柄实际上是用于 跟踪的命名空间 可以让你指定子系统和类别 以及每个路标的静态名称 这就给追踪点提供了逻辑结构和等级

自定义Instruments创建在 OSSignpost上主要有两个原因 第一 它们是暂时的

所有路标 无论是点事件或区间 都隐含地记录高精度的时间戳

在我们高度并行的世界中 拥有对重叠区间的良好支持 也非常重要 OSSignpost通过路标ID 来实现这个 这为匹配相关事件记录了足够的情境 甚至当开端或结束事件 发生在不同的线程上 或不同的分派队列上时也可以

OSSignpost的 第二个原因是它们消耗低 日志记录机制在设计时考虑到了效率 无论何时当你提交OSSignpost 它都记录最小量的数据 围绕静态字符串有一些优化 比如格式字符串和路标名称 实际上只是作为 二进制文本段的偏移量提交 事实上OSSignpost的 消耗足够低 在绝大多数情况下 你可以把它们留在生产代码中 这就是它们对创建工具有用的原因 这些工具除了帮助你解决问题之外 还可以帮助你调试优化的代码

当Instruments 记录路标数据时 你将获得所有明确的字段 包括那个格式字符串以及 你要提供的参数 但在Instruments中 你还会获得 所有隐含的字段 比如时间戳或调用线程 这些非常有用

如果你使用启用了回溯的日志句柄 那么还会记录调用栈 并在Instruments中显示

当向代码找那个添加追踪时 重要的是要注意 OSLog和OSSignpost 有三种不同的行为模式 默认情况下OSLog是… 每个OSLog句柄都启用路标 因此它们仍然是低消耗 并且只记录到一个环形缓冲区

当Instruments或 另一个客户请求显示这个数据时

OSLog系统会立即进入流模式 那将会增加一些消耗

然而今年有两个新的动态类别 只有当Instruments 记录时才能启用

这些动态类别 用于记录第二个栈追踪 这增加了少许额外的消耗 考虑到这点 OSSignpost 的实际消耗是多少？

嗯 许多因素都会影响真实的性能 比如设备类型、硬件型号、 OS版本号、系统加载、热处理等等 因此很难给出一个具体的数字 但我想给出一些对数尺度的 数量级近似值 因为我认为理解相对消耗很有用 如果我们在发布版本中看一下路标 所有路标都以不到一微妙的速度记录 新的默认关闭的动态类别实际上处于 很低的纳秒范围内

当Instruments在延迟 或最后几秒模式记录时 这些动态类别将会开启 以匹配默认为开的类别的行为 并且它们的消耗相同 除动态堆栈类别外 由于动态堆栈记录调用栈 所以它消耗稍微大一些 处于毫秒范围内

然而当请求流模式时 所有这些的消耗将明显增加 并进入几十微妙的范围

考虑到这一点

你可以采取什么措施来最小化 OSSignpost在记录时的消耗？ 如果你担心那个运行时间消耗 或它们开始在配置文件中显示的话

嗯 你可以采取两个很容易的措施 首先你使用Instruments 的延迟或最后几秒模式 替换立即模式 这可以避免OSSignpost 进入流模式 并减少消耗 配置模板 当你打开模板时 以其中一种模式进行记录 是一件很容易的事

同时如果你使用新的动态追踪类别 这是一种在不记录时 最小化消耗的好方法 因为路标默认为关闭 只有自定义Instruments 才可以启用它们 因此这个数据也不会在内置的 OSSignpost工具中与追踪挤在一起

那么作为框架或子系统的作者 当你分析时到底提交多少路标 才是合理的？ 嗯 你可以提交许多 但让我们假定一个非常保守的目标 当你分析时 即使单核的CPU也低于1% 然后让我们假定 路标的大概消耗是 每启用一个路标需要大约半微妙

那等同于每秒启用20000个路标 即使是在iPad Pro上的 显示链接情境中 以每秒120帧的速度运行 这仍然足够使帧之间有83个区间

再一次 真实性能会发生改变 这些只是估算 重点是要记住路标是一个共享资源

你用得越多 对日志记录系统的影响越大 那就是说它们可以执行这种 高速率追踪 并且有时候非常有用 有时候它们对于查找你代码中的 管道停滞 或排序问题非常关键

然而请记住 你可能想根据不同用户 把路标分离到不同类别中 很可能你框架的客户 不像框架的贡献者那样 需要那么多细节 客户可能需要追踪更多的实施细节

如果你把追踪点分到 不同的日志句柄中 这将使你的工具只能启用必要的子集

因为追踪是检测的基础 我想快速讲四个最佳实践

第一个也是最重要的一个 总是终止你开始的任意区间 这对于正确性来说至关重要 永久开启的区间 真会降低Instruments的 分析速度 在这个例子中 我们有OSSignpost调用 包装了一段消耗大 并且有潜在报错风险的代码 问题是如果出现报错 控制流将跳到捕捉范围 并完全跳过终止路标

现在Swift的延迟状态 确实是处理这个问题的好方法 确保无论提前返回或出现报错

当我们提交当前范围时 仍会调用那个 OSSignpost终止调用

第二 为了效率 请避免在开始和结束追踪点中 记录相同的数据 当数据可用时 只在第一个追踪点中记录它 这就避免了重复工作 并尽快给 Instruments提供值 在这个例子中 我们不需要重复 请求编号或原生尺寸

我们不使用请求编号来匹配 重叠情况下的区间 这些追踪点实际上可以用来 给每个区间对的日志句柄 生成唯一的路标ID

第三 当没启用路标时避免做 不必要的工作 如果你的日志句柄需要使用其中一个 动态追踪类别 那么路标启用属性将表明 无论Instruments 当时是否正在记录 意思是 把消耗大的数据的计算放在那个 OSSignpost检查之后是个不错的方式

第四 其实对于你的工具而言 你需要的只是追踪数据 思考一下你的Guard 语句和预处理 因为有时你想追踪这些 以包含短区间 比如 如果你有一个方法 你想了解缓存命中和缓存缺失 之间的区别 但其它时候 这些提早的返回可能意义不大 对于这些情况而言 请考虑把路标移到预处理之后 从而减少 你要发送给路标系统的数据量

现在了解了这些技巧 重要的是要记住 追踪点确实是你在追踪点上 创建的所有工具的基础 并且绝大多数时候 它们将出现在你的生产代码中 因此这也是为什么考虑追踪点的 性能和可维护性 非常重要的原因 因为它们处于核心中 路标调用的变更 可能会导致需要修改 你在追踪点上所创建的工具

因此请保持追踪点的稳定 避免追踪实施细节 如果可能 请尽可能接近API层 添加OSSignpost调用

现在在代码基中四处移动追踪点 已经不成问题了 你不必担心诸如内联之类的 编译器优化 那可能会替你进行此类优化

你需要确保不要修改 静态字符串 我的意思是特别是子系统、类别、 路标名称或格式字符串 如果你修改了其中任意一个 你要记得更新 Instruments程序包

接下来让我们讲一下建模 以及向Instruments内的 数据中添加结构

Instruments的架构基于 表中所存储的一切 模式决定那些表的结构 这些都是由Instruments 分析内核管理的 要更深入地了解 Instruments架构的信息 我推荐你参看2018年的创建 自定义Instruments演讲 然而现在让我们看一下 建模在哪里创建分析体验

在左侧我们有OSSignpost 它是Instruments记录的 主要数据源之一 表中所填充的数据 有预定义的模式可以在自定义 Instruments中使用

建模在中间 是下一个阶段 建模器从一个或多个输入表中 观察数据 对数据进行推理 然后把数据提交给 你指定的一个或多个输出表

建模器是特定域逻辑所在的地方 输出表的模式 用于指定在数据中应用哪种 类型和格式

右侧是最后一步即可视化 可视化用于在XML中描述 Instruments中标准UI 你可以在这里指定 如何在建模器的输出表中 显示数据和如何用图表显示数据 比如给哪一栏绘图并用作值 或哪一栏用作彩色标签

因为所有的自定义 Instruments的可视化 都基于你的模式 以及你的建模器的输出 因此下边这个过程非常重要 检查OSSignpost 追踪点是否良好 然后了解如何把这个数据 放到自定义的模式中

因此自定义Instrument中 的所有数据必须存储在表中 表以一种或两种方式处理数据 点模式有一个时间戳栏 而区间模式既有时间戳栏 又有持续时间栏 这意味着你需要定义至少一个 点或区间模式 然后把命名和类型提供给其余的栏

现在通过建模规则填充数据 建模规则操纵的是输入数据 这些规则在CLIPS 语言中进行表达 好消息是Instruments 提供一些模式 可以自动生成建模器 因此你不需要编写CLIPS代码 除非你希望这么做

事实上 如果你刚开始编写 并且你想确保数据的准确性 Instruments在库中提供一个内置 OSSignpost工具 对于记录和检查 OSSignpost区间看起来 是否合理非常有效 检查器可以帮助你验证原生数据 是否就是你所预期的数据

一旦你检查了数据 一个新的 Instruments目标 是开始创建你自己的工具的好方法 通过Xcode针对自定义 Instruments的内置XML片段 你距离在库中拥有 自动建模器和Instrument 只差几个元素了 要了解这一切的最佳方式是通过演示 为此 我要邀请我同事 Kacper上台来

谢谢Daniel 大家好

我们在Mac上的 Solar System app 用于处理大量关于星球、 图片、视频和二进制的数据 为了优化它的磁盘使用情况 我创建了一个框架叫做 Solar Compression 使用路标的压缩库 有效地从磁盘中编码和解码数据 现在我想给我的框架创建检查 给未来用户提供一些数据

我们有两个概念值得追踪 和进行可视化呈现 首先CompressionManager 是个用于协调压缩任务的对象 可以通过许多通道创建它 指定可以同时执行多少任务

第二 我想通过捕捉压缩速率 衡量对特定文件类型和算法的 压缩性能 通过检查这些 用户可以决定是否值得压缩数据

我编写了区间 在OSSignpost API中 表达框架的这个概念 让我们进入CompressionManager Swift文件看一下

首先让我们看一下日志句柄 我的日志句柄把我框架的 捆绑包标识符指定为子系统 并把我的类名称指定为类别

压缩和解压 是压缩管理器的公共界面的一部分

它们一开始都创建压缩工作项实例 压缩有关特定压缩任务的信息 接下来它们调用私有的 SubmitWorkItemMethod

因为压缩通道可能非常繁忙 在通道上创建压缩项 和执行压缩项之间 可能有很长的时间间隔 这是开始测量这种延迟的完美场所 我们要通过调用 以CompressionItemWait 名称开始命名的路标类型

接下来我们在这里使用 Guard条件语句 在我们继续进一步之前 要确保源文件存在 根据Daniel的建议 我要把它移到函数顶部 从而确保我的区间总是处于关闭状态

接下来我们有 ExecuteWorkItemMethod 当压缩任务已经准备好在通道上 执行时调用它

起初 我们需要给那个项指出 等待结束的时间 通过调用以与之前名称相同的名称 为命名结尾的路标类型实现

接下来我们用 CompressionExecution路标 表明压缩的开端 在元数据中 我们有诸如此类的东西 比如算法、 某种操作、关于源目的地的信息、 通道和调用线程

正如我们之前所了解的 OSSignpost隐含记录参数 包括线程 因此你现在移除线程 没有任何问题

接下来我们创建目的地文件 并同步执行压缩操作 完成后 我们把它记录下来 并附加目的地文件尺寸 这是我可以改善路标调用的 另一个地方 这里的StartCompressionMethod 是一个会产生报错的方法 如果它确实产生了报错 将不会调用这里的路标调用 为了防止这种情况发生 我可以在这里引入延迟代码块

并移动我的代码 从而确保区间总是处于关闭状态

让我们使用Xcode的Profile动作 来看一下Instruments中的路标

让我们从一个空的模板开始

给它添加我们的 路标工具

并只做几秒钟的记录

我们现在可以检验数据 我展开路标instrument查看 所有记录下来的子系统

这是我们的那个 Solar Compression 我可以进一步展开它 查看压缩管理器类别

我可用Control-Z重新调整 追踪的尺寸以适应全部所包含的图表

让我们捏合以放大 更具体地检验数据

顶部有全部的压缩执行路标 底部有等待执行的任务的 全部区间 在这里我们可以注意到一些模式

比如一次最多执行两个任务 因此很可能app代码使用了两个 压缩通道

同时我们可以看到一些尖峰 那表明有许多任务等待被压缩

OSSignpost是用于分析 你自己的路标的好工具 但通常不能给框架的用户 提供足够的分析情境 为了改善这个功能 我创建了另一个… 我创建了使用自定义Instruments的 Solar Compression工具 通过把这两个路标放到 两个独立的表中 并调整符合工具标准的UI 我努力改善我们的可视化功能 现在让我们打开包含这个 工具的追踪文档

在底部我们看到全部等待执行的任务 它们的呈现方式与OSSignpost 工具中的呈现方式一样

在顶部我们看到全部执行区间 现在由通道分离开 因此我们确实可以看到 有两个可用的通道

在这底部 我看到全部的压缩任务 附带区间信息、源路径、 文件尺寸、压缩速率等等 有一个任务引起了我的注意 这个任务很长 并且以红色显示 那意味着这个任务的压缩速率很慢

为了方便地了解它是哪种任务 我可以切换到活跃的任务详情 它只用于显示与我的检查头 相交叉的区间 我可以移动我的检查头 并分析一个任务

看起来我们正在尝试压缩zip存档 文件尺寸缩减了百分之一点多 这并没有缩减很多 也许你根本不应该压缩它

接下来让我们看一下任务概要详情 这里汇总了全部压缩任务 它提供三种汇总等级 压缩、源扩展和算法

在右侧我们看到不同的统计信息 比如平均压缩速率、持续时间 或节约的空间总量 这些详情对于比较不同的算法 或查看不同文件类型的压缩速率 有什么不同非常有用 比如我们可以看到我们的JPEG 文件尺寸 平均缩减了34% 这对于已经严重压缩的文件来说 很不错

现在让我们看一下 Instrument Inspector怎么样

我们在这边有 OSSignpost表是点模式 它查看…所有的开始和结束事件

我们还有两个路标的表

这是我们的执行表 它包含我们所记录的与任务有关的 所有数据 但现在它是根据我们所分配的 编程类型进行格式化的

在右侧我们可以看到 这个表由UI直接使用

目前我对我的工具非常满意 我要改善一件事 即等待执行的任务的呈现方式 我不想查看特定区间 我想通过某种方式把它们汇总起来 清晰地指出负载较高的区域 我认为Daniel 可能有办法能实现 Daniel？

谢谢Kacper 正如Kacper所展示的那样 库中的OSSignpost工具 和Inspector 是用于可视化原生数据 检查Instrument确实 看到了你所预期的数据的不错的方式

甚至不需要编写自定义 CLIPS建模器 Kacper就能创建一个工具 从而以更有意义的方式呈现他的数据 通过使用他的框架的压缩概念实现 只使用了四个追踪点和两个 OSSignpost区间模式 意思是那并不完全是 他想要创建的分析体验

现在自定义建模器 是调整那个体验的不错的工具 它们可以让你融合 多个日志句柄的数据 甚至可以使用来自内嵌表的数据 它们可以让你嵌入更复杂的逻辑 以维持状态 并对事件顺序进行推理 编写你自己的自定义建模器 对于某些自定义程度较高的绘图 和详情使用模式也很有用 点模式、区间模式和建模器标签 是开始自定义建模器的好方式 但这是一个很深的话题 我们在这场演讲中没有时间细讲 要获取更多关于自定义建模的信息 请参看2019年的建模和 自定义Instruments演讲 更深入地讲了具体信息 并附带示例代码

让我们继续讲分析体验的UI部分 可视化

可视化是关于你作为作者 向使用你代码的开发人员 讲述自己的故事的机会 最重要的准则是要记住 数据与故事不一样 如Kacper所展示的 通过查看 内嵌OSSignpost图表 原生区间只擅长向它们的作者 传达意义 使用你的工具的用户不会直观地了解 时间线中的某个空缺是好还是坏 或下一个处理阶段是什么 但不应该这样 作为Instruments 程序包的开发人员 你应该不只是 创建显示发生了什么的可视化信息 你要教学和诊断 你要帮助用户查找问题 即使你不在那儿

并且可视化也不只是与图表有关 有时候沟通问题的最好方式是 使用正确的统计数据集 或使用精心编写的文本叙述 准确描述出问题所在

然而图表如此重要的原因是 绝大部分情况下 图表是用户的起点 这是你的故事书的第一页

可视化应该帮助其他人学习、 了解和调试 而自私的动机是 优秀的工具也会加速分诊 这是可视化的目标 让问题变得明显 图表是你将看到的第一个汇总 它们应该把你的目光吸引到 重要的区域 一旦你开始深入了解 你的代码应该围绕 详情视图和指标那些核心概念 因为Instruments 处理两种类型的时序数据 点和区间 我想讲一下 这两者的显示方式

汇总点事件有助于评估它们的重要性 如果它们全都相对相等 那么在时间线上 显示事件密度的一个不错的方式是 通过柱形图 快速扫一眼就能立即看到较高的柱子 你就知道从哪里开始看 以及要放大哪里 对于自定义Instruments 自定义图表行为非常容易 柱形图元素可以让你指定 每个时间桶的宽度 有一个最适合分辨率元素 可以让你在用户缩小时使用柱形图 然后当用户放大时 交换单一事件的细节

当点事件的重要性发生变化时 有时候对为重大事件开辟一条道路 很有帮助

多个图表和详情视图 可以从同一个表中引用数据 从而指定最顶级的 意思就是给 Instruments描述 如何从表中选择要显示哪些值 现在这两个功能都能完全 在XML中实现 而不需要自定义建模器

表格式汇总点数据或区间数据 你可以定义哪些指标是重要指标 通过汇总的详情视图 有用于结合值的函数 如Min、Max、Average 和Standard Deviation 新用户可以查看你所提供的汇总 从而了解哪些重要 以及要对哪些进行优化 即使是显示属性也很重要 比如栏的标题是什么 或它们的显示顺序

现在当用户深入查看详情时 叙述类型是用于解释正在发生什么的 一种很棒的方式 它可以让你使用自然语言 和其它类型的格式 以一种易理解的方式解释 运行时间行为 这些视图可以很好地告诉用户 预期应该发生什么但却没有发生 或当某些有意思的事情发生时 他们可能想进一步调查

因此绘制区间数据可能有点棘手

跟点不一样 区间因为重叠的原因 并不总是位于单一垂直空间内 如果你可以规划固定的或有限制的 重复的区间的数量 有两种方式可以将一条垂直的栏 分为多个可视区域 限制绘制用于把栏分成 使用一个标题的多个空间 而实例绘制用于给每个空间 定义自己的标题 现在OSSignpost工具 结合使用这些技术 但只有当要显示的重叠区间的数量 为有限数量时才能用 当有许多等级时 你可能要采用Instruments 11 中的一个新功能 把追踪数据分离到嵌套的追踪中 使其易于过滤、查找 甚至是易于pin你正在查找的东西 特别是当图表情境的数量特别多时 但无论你是否提供追踪等级 规划汇总区间数据都很重要 要么是在每一个等级上都进行汇总 要么是作为你的 Instruments的主图表

对于简单的区间数据 可以尝试应用与点相同的方案 即使用柱形图元素

然而只有当你拥有短区间时 才能很好地发挥作用 因为柱形图元素按开始时间进行汇总 对于较长的区间 这可能会导致向左倾斜 并且它会产生非常大的值

更重要的是 当绘制拥有持续时间的 元素的图表时 请不要在Y轴绘制时间 因为X轴已经代表时间了 诸如利用率百分比这样的指标 对于显示这种数据较好

在更实际的使用中 区间总是发生更多的重叠 因此我想演示三个例子 关于汇总图表 以及在你的框架中所呈现的概念 和你想要的使用模式 如何影响你的表模式 以及如何帮助你确定呈现样式

对于某些情境 持续的重叠表明资源利用率高 对于这种数据 使用限定平均载荷 是可视化这种数据的好办法 甚至会突显某些极端值

CLIPS建模器 和Instruments 擅长维护状态注入数据 因此结合那个 OSSignpost事件流 通过来自区间计时器标签的输入 当计时器信号到达时 建模器可以计算并提交 平均限制利率用 建模器的输出表看起来可能像这样 只表达了四栏数据 并绘制了你所看到的图表 包括一个决定图表的值的利用率栏 以及决定显示颜色的严重性栏

对于其它情境 许多快速运行的区间可能更重要 因为它们可以表达 你的框架使用率低下的情况 查看与上一个示例中同样的数据 好的图表可能基于建模器计数 在特定时段内所看到的 唯一区间的数量

建模器的输出表与上一个 看起来非常类似 但用户的注意力立即就被吸引到 时间线上一个非常与众不同的区域上 有助于放大 并调查导致这些区间短的原因

前两个示例 都以10毫秒分组汇总数据 但如果某个重叠时段 对于区分一个、两个或更多并存区间 来说非常重要该怎么办呢？

嗯 我们不根据时间量化 按重叠度进行分类的图表会更有帮助 并显示具体的持续时间

建模器只追踪 OSSignpost事件 可以输出一个额外的表 包含自定义区间模式

这一次 可以通过可变的持续时间 来填写模式 还有一个描述栏作为标签使用

这三个只是示例 但它们可以帮助你了解 当呈现数据时 当你设计图标模式时 概念很重要

对于许多情况来说 自动生成的建模器 就可以满足你创建合适的体验 所需要的功能和灵活性 但一定在某些时候 你想拥有一个输入或输出 对于那些情况 在我所展示的某些示例表中 自定义建模器可以提供 额外控制和灵活性 从而可视化地表达它们的概念 或富文本的叙述、图表和详情视图

现在我要把舞台交给Kacper 看看他有什么样的可视化操作

谢谢Daniel

我讲了自定义建模器 并努力改善我们现有的检查 让我们看一下 我要从我创建的那个 Solar Compression模板开始看

它现在包含一个 文件系统行动工具 当使用压缩库时 用于提供关于I/O操作的消耗的 额外信息

让我们记录一下

现在我在窗口模式中记录 从而减少记录所带来的消耗

Instrument会从主机传输 所有数据并运行建模器

现在让我们检验一下数据

我可以立即看到 在文件系统行动 和我的执行路标之间有一些相关性

我们主要看较长的zip压缩任务 我们之间曾分析过 把它显示为红色 可以很好地吸引用户的注意 但如果能使用叙述 来提供一些额外信息更好

我编写了建模器 用于检测压缩率低的情况 并呈现一些可能的方案

让我们具体看一下建议详情 看一下这个建模器的输出

这个建模器…我们得到了一个建议 建议说存档zip文件的尺寸 缩减了百分之一点多 可能没有必要压缩这个文件 它还暗示如果速度不是问题 我应该尝试使用LZMA算法 可能会提供较快的压缩速率 看起来很有用 我现在要尝试修改算法 再次记录 并重新验证结果

让我们看一下等待执行的任务 是如何进行汇总的 我计算了正在等待执行的任务的 平均载荷 这样 用户可以清晰地指出 载荷较高的区域 让我们看一下这个红色区域

看起来有许多任务正在等待执行 但随着任务在这个通道上的执行 数量正在减少 用户可以对那样的区域做出分析 如果有必要 可以增加压缩通道的数量 从而实现更高级别的并发性

实际上这个结论可以作为 对详情视图的另一个建议

现在让我们看一下它在 Instrument Inspector中表现如何 让我们搜索我们的 Solar Compression执行表 并看一下捆绑方案

OSSignpost 自动生成的建模器 把OSSignpost 点模式数据传输到 Solar Compression 执行表中 就在这里 正如我们之前所看到的 它由UI使用 我们这里还有这个新实体 即我们的建议建模器 它把压缩执行表中的区间 传输到点模式中的建议中 稍后用于驱动叙述详情

我对这个Instruments 传达我的库的概念的方式很满意 我感觉我们已经准备好 把它交给用户了 让我们返回到幻灯片中

创建优秀的分析体验 是要给用户提供一个探索路径 应该从一个有用的模板开始 这个模板用于提供 查看问题的必要的 Instruments 请记住 如果你的代码 对由其它检查所暴露的信息敏感 比如采样、系统追踪或优先级行动 你应该在你的模板中包含这些

当分析记录时 优秀的图表应该可以把用户的注意力 迅速吸引到 执行时间线中可能存在问题的地方 详情应该把他们带到 导致问题的主要原因上 并且通常还要提供有意义的暗示

为了帮助你开发更好的分析体验 今年在Instruments中 引入了两个新功能 第一个是分等级追踪的概念 其中一个例子是这里可见的 OSSignpost工具 通过等级 暴露了底层的子系统和类别名称空间

等级时自定义 Instruments的一部分 你今天看到的所有等级都可在自己 的Instrument中创建

我们还有一种自定义你的分析流程的 新方式 即通过创建自定义追踪范围

这些允许你从不同角度查看 在你的追踪文档中所收集的数据 通过应用追踪过滤器 或为每个范围选择不同的追踪分支 来实现

如果我只对查看系统调用 和压缩库的路标感兴趣 或只对分析虚拟内存对app的影响 感兴趣 我可以创建过滤掉其它追踪的范围 并一直给它们返回值

稍后我可以把它们保存在我的模板中 并与团队或Instruments 用户一起共享

检查形式的工具 会把用户与你的框架的交互体验 从良好变成优秀 从不了解变成信任 你可以通过它们来描述你框架中 所存在的概念

它们应该教育人们 并帮助他们捕捉容易犯的错误

无论何时当客户出现性能调试问题时 他们都可以返回到工具中寻找答案 这种交互 将增加他们对你的库的信心和信任

要获取更多关于自定义Instruments的 信息请访问Instruments开发人员帮助 我们还推荐你们观看这些演讲 谢谢 祝你们愉快地度过 余下的会议时光