Instruments 自 2010 年发布之后，一直不温不火，去年也没有任何更新值得去关注。但在一年的沉淀后，Instruments 团队在今年终于有了个可以令人期待的发布。本文是针对 Session 410：Creating Custom Instruments 的解读。
Instruments 10
Instruments 是一款强大且灵活的性能分析工具，集成在 Xcode 的开发者工具集中。我们能够用不同的 Instrument 来分析测试各种各样的性能问题，比如 Leaks 来查内存泄漏问题，Time Profiler 来分析 App 的页面卡顿问题等等。那么今年苹果对 Instruments 做了哪些更新呢？从官方的 Xcode 10 Release Notes 里我们可以看到有这几点：
- 开发者能够根据不同需求，灵活快速地基于 os_signpost 创建和发布属于自己的 Instrument；
- Instruments 能够自动展示你代码里通过 OSLog signposts 标记的数据；
- System Trace 里为线程分析新增了一个图像模式；
- 由于 Instrument 10 中所有的自定义工具都会基于 os_signpost 来完成，原本基于 dtrace 的自定义 Instrument 将不被继续支持。
其中最重要的一点便是自定义自己的 Instrument 了，虽然以往的版本中也可以根据自己的需要去创建，但步骤麻烦且图形化支持简陋，并且因为数据采集是基于 DTrace 的，导致真机上并不能够使用，苹果自身也并不鼓励大家去做这个自定义。但 Instruments 10 针对这点这次可谓下了苦功——全新基于 os signpost 的架构能够支持所有平台，『标准界面（Standard UI）』 和 『分析核心（Analysis Core）』 使得自定义 Instruments 变得更加灵活而且便利。这个 Session 围绕如何创建一个自定义的组件，分为以下四个大部分展开：
- 为什么要创建自定义的工具
- Instruments 10 的架构体系
- Instruments 自定义工具的初级、中级以及高级应用
- 自定义工具的最佳实践
其中将会涉及到一些关于专家系统（Expert System）和 CLIPS 语言的知识，如果有兴趣的话，可以先了解下。本文相对于 App 端开发者，可能会更适合一些测试人员，尤其是对性能测试方面比较感兴趣的同学。
为什么要创建自定义的工具
我们都知道 Instruments 中已经内置很多方便好用的工具了，这些工具苹果已经通过文档模板创建好并集成在 Instruments 的启动选择界面里。比如上文中提到的 Leaks 和 Time Profiler 相信很多人都有使用过，下图的就是 Instruments 10 的启动界面，与以前版本差别不大。
Instruments 10 的架构体系
架构的演变
介绍 Instrument 10 的架构之前，我们先回顾下以往苹果是怎么维护 Instruments 组件的。
界面介绍
Instruments 自定义工具的初级、中级以及高级应用
初级应用
有了足够的理论知识后，我们可以尝试下简单的自定义工具创建了。
.instrpkg 的 XML 文件，所有的配置都会在这个 XML 文件中完成，其中默认已经帮我生成了包含一些基础信息。接着我们要做的就是按照我们的需要去写这个配置文档了。
1、导入需要使用的 Schema
<!-- MARK: 导入你需要使用的 schema -->
<import-schema>tick</import-schema>
复制代码2、完成 Instrument 的『标准界面』和『分析核心』配置
<!-- MARK: 导入你需要使用的 schema -->
<import-schema>tick</import-schema>
<instrument>
<!-- MARK: 这个 Instrument 的基本信息 -->
<id>com.Parsifal.TicksDemo</id>
<title>Ticks</title>
<category>Behavior</category>
<purpose>Instrument drawing ticks every 100ms</purpose>
<icon>Generic</icon>
<!-- MARK: 描述的表数据，将会由 分析核心 最终完成存储和解析提供给 标准界面 模块 -->
<create-table>
<id>tick-table</id>
<!-- 定义了每列的数据 -->
<schema-ref>tick</schema-ref>
</create-table>
<!-- MARK: 图形视图上面展示（可选） -->
<graph>
<title>Ticks</title>
<lane>
<title>Lane</title>
<!-- 这里就是上面你定义的 table id-->
<table-ref>tick-table</table-ref>
<plot>
<value-from>time</value-from>
</plot>
</lane>
</graph>
<!-- MARK: 这里描述你需要展示在详情视图的数据 -->
<list>
<title>Ticks</title>
<!-- 这里就是上面你定义的 table id-->
<table-ref>tick-table</table-ref>
<column>time</column>
</list>
</instrument>
复制代码至此我们便已经完成了所有的编码工作了，在编写过程中，我们还会发现苹果为我们准备了很多代码片段，来帮助完成这些配置，并且编译期间还会对代码进行检查，报出的错误信息也很方便我们对其进行调试。编译运行后，在弹出的 Instruments 选择窗口里选择 Blank 就可以在测试界面的 Library 中发现我们自己定义的工具了，直接拖入 Instruments 里就能够像使用其他内置工具一样运行。
中级应用
这一部分我们会介绍一些『标准界面』和『分析中心』里更详细的内容。
标准界面
『标准界面』模块里为我们提供了很多简单又好用的元素，使用这些元素能够让我们创建出非常酷炫又实用的 Instruments 工具。接下来列举一些常用的元素进行介绍，更多的元素还待苹果正式发布 Instruments 10 后大家一起探索。
图形通道面板
- <plot>：为图形视图上面划出一个单独的数据通道，需要提供一个值来定位纵列，如我们 Ticks 例子中的 time；
- <plot-template>：这个和 plot 差不多，区别在于它会自动为每个 instance-by 值创建一个数据通道；
- <histogram>：为给定的时间片段生成柱状图，如 System Trace 组件中使用的那样；
详情面板
- <list>：创建一个列表，常见的各种内置工具都会有的；
- <aggregation>：创建一个总计视图，统计总和和平均数等，使用这个元素的时候，纵列就是各种函数了，如
sum、average和count等，另外这个元素还有个hierarchy属性，能够为不同的纵列设置外轮廓，非常适合于大量数据的展示； - <calltree>：这个就顾名思义了，调用栈的视图；
- <narrative>：展示一个描述工程类型（engineering type）的视图；
分析核心
这一部分我们首先会重点谈谈『分析核心』是如何收集数据和处理数据的，这一过程主要包含以下三个步骤。然后会介绍一些『分析核心』中的相关概念以助于我们在配置表中使用它们。
1、简化
2、搜索
接着每个 store 将会开始尝试寻找数据的提供者。
3、优化
当我们从各个 store 中获取到数据源后，在『分析核心』中就开始了一项称为『Binding Solution』的工作，第三步就是优化这个工作流。
一些重要的概念：
Binding Solution：Instruments 里是通过 Thread Narrative 实现的，它有以下两个有点
- trace-wide；
- Instruments 会在我们将工具拖入测试界面的时候，开始计算寻找最佳可能的记录方案来最小化在目标上的影响；
Schemas：我们创建表的时候就必须要指定一个 Schema，比如我们第一个 Demo 中的 tick
- 目前 Instruments 里已经定义有超过 100 个 Schema 供我们导入使用了；
- 包含在 Instruments 包中；
- 可以通过编译设置链接其他的 Instruments 包，在编译期会进行类型校验；
- 提供了不同的构建模块；
Modelers：前面提到过，Modeler 可以帮助我们合成不同的数据，关于它的有以下几个常用的元素可在 XML 配置文件中使用。
- <modeler>：创建一个 Modeler，帮助我们做数据类型转换的工作；
- <point-schema>：定义一个可以用来存储点（无时间片段，即某个时间点的数据）的 schema；
- <interval-schema>：定义一个可以用来存储定距数据（有时间片段，一段时间内的数据）的 schema；
PS：Modelers 其实是一个由 CLIPS 编写，非常强大而且高级的小型专家系统（Expert System）。它可以指定自己需要哪些输入信号来告知 Binding Solution 怎么完成剩下数据图形的填充工作。关于这一部分我们将会在“高级应用”里详细说明。
最后，具备定义一个 schema 的能力是很重要的。今年新发布的 OS signpost API 赋予了我们一个很棒的把数据导入到 Instruments 中的方式，而且苹果为我们创建了一些快捷方式来使用它，比如在 XML 配置表中敲下 <os-signpost-interval-schema> 元素，就会自动生成如下代码片段。
<os-signpost-interval-schema>：定义了一个存储定距数据的 schema，而且数据由 os_signpost API 提供。这就意味着我们可以代码的任意地方使用 os_signpost API 来将我们需要被测试的数据直接导入到 Instruments 中。在创建这个元素的时候， Xcode 会自动生成相关的代码片段以帮助我们来完成 Modeler 的创建。 这个 API 和 os_signpost 结合使用起来就如下：
//使用这个 os_signpost 可以再我们代码的任意地方将你的数据传递给 Instruments，但必须记得 begin 和 end 成对使用
os_signpost(.begin, log: parsingLog, name: "Parsing", "Parsing started SIZE:%ld", data.count)
// Decode the JSON we just downloaded
let result = try jsonDecoder.decode(Trail.self, from: data)
os_signpost(.end, log: parsingLog, name: "Parsing", "Parsing finished")
复制代码<!-- MARK: 使用这个元素就能创建从 os_signpost 获取数据的 schema -->
<os-signpost-interval-schema>
<id>json-parse</id>
<title>Image Download</title>
<subsystem>"com.apple.trailblazer"</subsystem>
<category>"Networking"</category>
<name>”Parsing"</name>
<start-pattern>
<!-- MARK: 这里根据我们设置好的条件输出信息 -->
<message>"Parsing started SIZE:" ?data-size</message>
</start-pattern>
<column>
<!-- MARK: Engineering Type 对应的助记词 -->
<mnemonic>data-size</mnemonic>
<title>JSON Data Size</title>
<!-- MARK: 填写的是 Engineering Type 里定义的数据类型，比如这边看的是内存相关的，就会有 size-in-bytes -->
<type>size-in-bytes</type>
<!-- MARK: 由 CLIPS 语言编写的表达式作为这个列的值 -->
<expression>?data-size</expression>
</column>
</os-signpost-interval-schema>
复制代码在中级这一部分，苹果还为我们演示了一个 os_signpost API 使用示例。该示例中对一个展示图片的列表页做了图片测试，监控了每一个 cell 图片的下载情况。由于涉及到的知识点上面都已经描述过了，具体示例的完成过程这边就不再赘述，相信通过视频大家能看得更直观。其中演示过程中有提到几点比较值得注意的，这里重点抽出来说明下。
高级应用
这一部分将会着重介绍我们怎么去创建和定义 Modelers，并且简单介绍下怎么用 CLIPS 搭建基本的专家系统。
探秘 Modeler 的内部世界
我们通过一个简单的例子来探秘 Modeler 世界。我们模拟这样一种情况，我的代码里有部分危险的操作容易触发程序问题，我们的目标就是在程序出现问题的时候，找到是哪个操作导致的。那么我们可以定义下图中的三个 schema，前两个作为输入项，最后一个是输出项。
将这个流程，我们已一个更加形象直观的时序图来展示，其中虚线代表着 Modeler 自己的时钟：
其中，图上我按照时间顺序，标注除了 4 个值得注意的节点：
（1）这时的 App 出于正常运行状态，没有任何数据传输给 Modeler 的工作内存中，Modeler 的时钟并没有开始走；
（2）此时虚线到达我们的第一个 input schema 触发的节点（开始有危险操作的节点），在这里 Modeler 的工作内存中正式开始接收到数据，Modeler 的时钟从这个点开始计时。
（3）这是第二个 input schema 的触发节点（我们 App 出现问题的节点）。这里值得一提的是，Modeler 是很机智的，它有自己的逻辑，它能区分出在这个时间节点之前的危险操作数据意义不大，而这个节点开始到 app-on-fire 这个节点结束前的数据才是我们所需要的。
（4）到这最后一个节点，所有的输入数据都已经传输完毕了，Modeler 的时钟与这些输入数据没有交集， 它推断出这些输入数据已经不再被需要了，因而把它们从工作内存里移除并且产生最终的输出数据。
可以回顾整个过程，可以总结出两点：
- Modeler 的时钟起始时间总是第一个输入数据触发的时间
- 只有与 Modeler 当前时钟有交集的输入数据才会被 Modeler 保留在工作内存
这样一种机制能够帮助我们更清晰地定位到问题的所在，而不被那些无意义的旧数据干扰。这样一种机制是怎么实现的呢？答案就是我们接下来要说明的 『生产系统（Production System）』。
生产系统
Modeler 中对『工作内存（Working Memory）』的逻辑支持是来自我们定义的 『生产系统』。『生产系统』可以由一系列的 『规则（Rules）』 来生成，它在『工作内存』中为 facts（CLIPS 语言中的专业术语，可以理解为字面意思事实，推理得到的事实） 服务。『规则』由三部分组成—— LHS => RHS ，左边部分 + 操作符（=>）+ 右边部分。左边部分是一个在『工作内存』中激活规则的条件，右边部分则是激活后要执行的行为。右边的行为包含为输出的数据表创建新的一行，也可以是在建模时推断出一个新的『fact』到『工作内存（Working Memory）』里。结合之前上面的时序图，我们可以想到『facts』 来源于两个地方。一个是我们看到的数据输入表，这些是根据『规则』自动推理出的。另一个可以是来自于右边部分的行为，这些是通过 CLIPS 中 assert 命令主动推理的。如果我们打算创建我们自己的『facts』，CLIPS 提供了 fact 模板，模板允许为『fact』提供数据结构和做一些基础类型的检查。接下来就是介绍怎么来定义规则了。
规则和 CLIPS
我们可以使用 CLIPS 语言定义一些规则。先回顾下上面那个例子的时序我们是怎么通过 CLIPS 设置规则实现的：
(defrule MODELER::found-cause//规则名
//LHS，左边部分指定规则激活的条件
(playing-with-matches (start-time ?t1) (who ?object))
(app-on-fire (start-time ?t2))
(test (< ?t1 ?t2))
=>
//RHS，右边部分为推理产生一个 fact
(assert (cause-of-fire (who ?object)))
)
(defrule RECORDER::record-cause//规则名
//LHS，左边部分未设定激活的条件
(app-on-fire (start-time ?start))
(cause-of-fire (who ?object))
(table (table-id ?t) (side append))
(table-attribute (table-id ?t) (has schema started-a-fire))
=>
//RHS，右边部分为产生输出数据
(create-row ?t)
(set-column time ?start)
(set-column who ?object)
)
复制代码其中，record-cause 这条规则定义了，如果满足以下三个条件，则这次生产会推理出一个 『fact』并被压入『工作内存（Working Memory）』里。
- 一个对象 t1 这个时间在
playing-with-matches中产生； app-on-fire在 t2 这个时间被触发了；- t1 的发生时间早于 t2；
而 record-cause 这条规则定义了，如果满足了以下四个条件：
- App 在一些起始时间“着火”；
- 知道“着火”的原因和相关的对象（规则 1 里可以拿到）；
- 有一张绑定了 Modeler 输出侧的数据表；
- 这张数据表关联着我们之前定义的
start-a-fireschema；
则在输出数据表中创建一行数据，并且设置时间和设置『左边部分』捕获到的中引起“着火”的值。
通过以上两个简单的规则，我们便基本上创建了最早的『专家系统（Expert System）』。使用定义好的两条规则，就可以用来寻找我们 App 内存在的一些问题。或许你也已经注意到，这些规则要么是为 Modeler 预先设置的，要么是为 Recorder。CLIPS 里把他们叫做『模块』，并且支持把规则分组和控制规则的执行顺序。比如说，如果你所有的规则都定义在了记录模块里生产输出数据表，那么你将不会在 Modeler 模块推断的时候写入任何的输出数据。因为在 Modeler 模块 里的规则必须在记录模块里的规则之前执行。
逻辑支持
在前面探秘 Modeler 内部世界的时候，我们提到过逻辑支持。逻辑支持一般与纯推理规则关联在一起。比如说，如果 a 和 b，那么 c。通过我们的『生产系统』中说，就是如果 a 和 b 不存于『工作内存』了，那么 c 就要被自动地被回收。这样我们就可以说 c 是被 a 和 b 在逻辑上支持了。这样的一种能力对于『专家系统』将『工作内存』维持在较低的水平很重要，因为它能很好地控制资源开销。同时，把无效的 facts 从『工作内存』里及时移除也是很重要的。如果 a 和 b 失效了，那么 c 也应该被移除。这样的需求在 CLIPS 里实现会很简单，只要通过 logical 命令就可以，如下面的代码。
(defrule MODELER::found-cause
//通过 logical 命令实现逻辑支持
(logical (playing-with-matches (start-time ?t1) (who ?object))
(app-on-fire (start-time ?t2))
)
(test (< ?t1 ?t2))
=>
(assert (cause-of-fire (who ?object)))
)
复制代码最佳实践
前面洋洋洒洒说了那么多，最后这一部分我们主要谈一下在开发自定义 Instruments 工具时有哪些最佳实践。
多写一个 Instrument
这句话不是建议我们去不断练习写自定义的 Instrument 工具，它说的是我们应该把 Instrument 功能做得细粒度化。举个例子，我们已经有了一个自定义的 Instrument 工具，但这个工具的功能并不能满足现在的需求，我们需要在它的基础上去增删一些详情或者图形的数据展示。这样一种场景，我们会有两个方式去做，第一个在原有的基础上继续迭代，第二个是重新再写一个满足我们当前需求的 Instrument。如果选择了第一种方案，这会导致这个 Instrument 组件变得不再纯粹，虽然功能是更多了，但相应的 Instruments 也变得更加复杂。所以苹果会更推荐我们用第二种方案，重新写一个符合我们当前需求的 Instrument。如果我们需要组合使用不同的 Instrument，在 Instrument 组件库中拖拽对应的 Instrument 到我们的文档中即可。如果这类组合使用场景很多，我们也可以用 “File -> Save As Template” 保存为模板以供接下来使用。保存模板的将会展示在我们 Instruments 的启动页面，比如内置的 Leaks、Activity Monitor 和 Time Profiler 等一样。另外这些模板，也能够很方便的在我们的包中复用，使用 <template> 元素即可。
实时模式很困难
实时模式指的是数据的获取、分析、到最终通过 Instruments 的界面能够实时地被展示出来。苹果现在很难完成这种实时交互主要有两个原因。第一个原因是，实时模式的完成需要一些额外的支持，但现在苹果并没有足够充裕的时间去做；第二个更重要的原因便是定距型数据（Interval Data，统计学上的概念，具有间距特征的数据，可作加减计算）。定距变量只有起始和结束这个阶段完成时，才能被加到数据表中和被『分析核心』所获取。在启动测试记录后，Instruments 将会收到一群定距型变量的开区间，当定距变量没完成闭区间时，Modeler 的时钟并不会往前走（Modeler 里的数据是按时间排序的）。这样的机制就会导致了一个问题，如果某个定距变量的开闭区间拉的很长，那么 Modeler 就会一直停滞在那儿等待。但如果这个时候用户点击了停止记录按钮，所有的开区间定距变量就会关闭，一切都会恢复正常，数据将会被填充到 Modeler 里。应该能感觉到，这是一个很不好的用户体验。一旦我们遇到这种情况时，我们有两个选择。第一个选择是配置我们的 Instrument 使它不支持这种实时模式，这个可以通过 <limitations> 元素实现。第二个选择避免数据出现这种长时间的开区间，例如使用 <os-signpost-interval-schema> 替代 <interval-schema>。
使用『最后 5 秒记录模式』
当创建一个用来测试含有大量输入数据的 Instrument 时，使用『最后 5 秒记录模式』则是我们目前最好的选择。这一选项我们可以在 “File -> Recording Options” 里找到。如下图：
总结
Instruments 10 提供了太多创建自定义 Instrument 的可能性了，不过这同样需要我们花点时间来学习掌握新一套的编写方式。对于大多数客户端开发者来说，或许并不会用到上面谈的这部分技能，但对于测试团队来说，这无疑为 iOS App 的性能测试又打开了一扇窗。相信在未来的一年里，圈子内会陆陆续续地有高质量自定义 Instrument 的产出，让我们一起期待。
查看更多 WWDC 18 相关文章请前往 老司机x知识小集xSwiftGG WWDC 18 专题目录