了解 Core Location Monitor

♪ ♪

Nivash：大家好 我是 Nivash Raaja Karukankaatur Murugasamy 是 Core Location Frameworks 团队的工程师 欢迎观看关于 Core Location Monitor 的讲座 非常高兴能向你介绍 我们新的 CLMonitor API 它可让你只用几行 Swift 代码 就能编写简单而强大的监测逻辑 你只需创建一个监测器、 添加条件，和等待事件 然后就完成了 你好 CLMonitor！ 让我们深入了解 CLMonitor API 的细节 我会先整体介绍 CLMonitor API 这是我们简单而强大的 监测用户位置或信标的新方式 然后 我将介绍你 可以监测的条件类型 以及如何创建和添加这些条件 接着 我将介绍监测记录 记录包含的内容以及你如何 在 App 生命周期中访问这些内容 然后 我将介绍 当任何被监测条件遇到事件时 你的 App 需要采取的步骤 最后 我将总结 有关使用 CLMonitor 时 一些对你有帮助的要求和建议 我们先来了解一下监测器是什么 以及如何创建用于监测的监测器

CLMonitor 是一个 顶层的 Swift Actor 每个 CLMonitor 实例 都充当一个监测的入口 它是一个 actor 可减轻你在线程 和任务同步方面的负担 因此 在任何时候访问 CLMonitor 的内容、添加或删除条件 都只需要等待 为创建一个监测器 可以调用监测器的初始化方法 并提供一个包含 字母和数字的字符串作为名称 如果之前不存在具有该名称的监测器 系统将会创建一个新的监测器 如果存在 系统将打开现有的监测器 无论哪种情况 系统都会返回监测器实例 请注意 每次只能同时 打开一个具有给定名称的实例 被监测的实体称为条件 你可以将条件添加到 CLMonitor 实例中进行监测 并使用 add 方法 与标识符进行关联 标识符是一个字母数字字符串 比如 在这个示例中 “Work”唯一标识了 一个条件记录 当用户在工作时会满足这个条件 通过此标识符 你可以访问记录对象及其内容 并且在移除前 条件都将被监测 你可以通过使用相同的标识符 来调用 remove 方法 从监测中移除条件 移除条件还将删除相应的记录 现在你已了解如何创建监测器实例 以及它与条件的关系 接下来 我们了解一下可用的条件类型 以及如何创建和添加条件进行监测 iOS 支持两种类型的条件 第一种是 CircularGeographicCondition 圆形地理条件由中心点和半径定义 中心点定义了条件的地理位置 半径定义了满足条件的 区域范围 在该区域范围之外的任何地方 我们将条件报告为不满足 这类似于 iOS 16 及 之前版本的 CLCircularRegion 你可以通过构建 CLLocationCoordinate2D 并指定感兴趣的 纬度和经度来定义中心点 然后 使用该中心点 和感兴趣的半径来创建 CircularGeographicCondition iOS 支持的另一种条件类型是 BeaconIdentityCondition BeaconIdentityCondition 类似于你可能在 iOS 16 及之前版本中使用过的 CLBeacon IdentityConstraint 或 CLBeaconRegion 如果贵公司在不同位置有多个场所 可以部署信标 以便在 App 中检测 用户是否位于 任何一个场所或特定场所 甚至特定场所的特定区域

以 Apple 的自助餐厅 为简单示例 其可在多个场所的办公室提供 我们来看看如何有效地部署信标 从而在关联的 App 中 实现基于位置的行为 随着我们的讨论 我将介绍 App 如何在不同情况下 使用不同类型的 BeaconIdentityCondition 来监测这些信标 我们简要了解一下定义信标的内容 它包含一个 UUID 字符串、 一个 Major 号码和一个 Minor 号码 使用 BeaconIdentityCondition 你就可以通过指定这三个属性： UUID、Major 和 Minor 来监测特定的信标 或者 你也可以使用 通配符来匹配一组信标中的 任何一个 只需指定 UUID 和 Major 或只指定 UUID 若未指定 Minor 或 Major 和 Minor 任何值的信标都可能会匹配 来看看如何在我们的示例中使用它 我们可以在这些餐厅位置部署信标 所有信标都具有相同的 UUID 在 App 中 可以创建 一个 BeaconIdentityCondition 来监测该 UUID 然后 如果用户接近其中一个信标 该条件将变为满足 否则 条件将被确定为不满足 在代码中 你可以通过 调用只指定 UUID 的 init 函数方法来实现这一点 现在我们已经 在所需位置部署了信标 你可能有兴趣 检测用户是否在特定的位置 在这种情况下 我们来看看 如何监测用户是否位于 Apple Park 为实现这一点 在每个位置部署的信标 将必须共享一个 唯一的 major 值 然后 在你的 App 中 可以监测 一个 BeaconIdentityCondition 其中包含 major 和整体 UUID 只有当设备位于信标的 UUID 和 major 值都匹配的位置时 条件的状态才会被确定为满足 在其他位置 它将保持为不满足状态 在代码中 你可以通过调用 只指定 UUID 和 major 的 init 方法 来创建 BeaconIdentityCondition

现在你已了解 如何监测所有位置或特定位置 你也可以监测 特定位置内的特定区域 这可以通过 在不同位置 (例如 餐饮区) 部署信标来实现 每个位置都有相应的 minor 值 在你的 App 中 可以监测 一个 BeaconIdentityCondition 来指定特定的 minor 值 同时包含 UUID 和 major 这样的条件只有在检测到 具有该 minor、 整体 UUID 和 major 的信标时 才会变为满足状态 在代码中 这表示通过传入 UUID、major 和 minor 来创建一个 BeaconIdentityCondition 创建 BeaconIdentityCondition 时 可使用适合你需求的 init 方法 好了 现在你已了解如何创建 不同类型和不同情况的条件 接下来 我们来看看 如何添加用于监测的条件

你可以通过在 CLMonitor 实例上调用 add 方法 并传入一个称为标识符的字母数字 字符串来添加一个监测条件 条件将与该标识符相关联 如果已经使用 给定的标识符来监测某个条件 该条件将被传入的新条件替换 添加条件时 其初始状态将为未知 直到被 Core Location 确定为止 有时 你可能在 添加条件之前已了解到其当前状态 在此情况下 你可以在添加监测时 通过传递状态 来覆盖默认的初始状态 在这个示例中 假设你的 App 推断出 你不在 Apple Park 并因此期望条件为不满足 你可以在调用中 添加“assuming: .unsatisfied” 然后 监测将以 不满足的状态开始 但不用担心 如果你对状态的假设是错误的 Core Location 将在 确定后提供正确的状态 要将条件从监测中移除 可以调用 remove 方法 并传入添加条件时的标识符 现在 你了解了 什么是条件、支持哪些类型、 如何从监测中添加或移除条件 接下来 我们来详细了解记录的内容 以及如何随时获取监测中的记录 或所有记录 如果你还记得之前的幻灯片 当你添加监测条件时 Core Location 会创建 一条记录并将条件添加到该记录中 除了条件 记录还包含 另一个对象 即事件

事件包含状态 用于表示条件当前观察到的状态 包括满足、不满足和未知 以及条件遇到该状态的日期和时间 现在你可能想知道 为什么事件中还有另一个条件实例 我们称之为细化 它有什么作用呢？ 如果你还记得 BeaconIdentityCondition 你的 App 可以仅监测 UUID 或 UUID 和 major 或同时监测 UUID、major 和 minor 如果一个带有通配符的 major 和 minor 的条件获满足 事件将会附带细化信息 这个细化条件将携带观察到的信标的 UUID、major 和 minor 信息 一旦条件变为不满足 细化条件将被清空 可能会存在多个记录实例 每个记录通过 在添加条件时传递的标识符 进行唯一标识 所有监测器的记录 会存储在你的 App 中 同时会将条件与最后的事件 和标识符关联起来 这让你可以随时查询 条件及其对应的状态 作为最后一次观察到的状态 我们来看看代码中的实际效果 要检索与条件关联的记录 可以使用其标识符 来调用 record 方法 如果没有使用传递的 标识符进行监测的条件 系统将返回零 然后 你可以通过访问条件属性 来获取底层的监测条件 通过访问 lastEvent 属性 你可以获取 传递给 App 的最后一个事件 然后 从事件中 你可以获取最近观察到的状态、 日期和细化条件 现在 你已了解如何检索一个记录 那该如何获取所有的监测记录呢？ 是否需要跟踪所有的标识符？ 实际上并不需要 在你的监测器上 我们为你 维护着一个标识符列表属性 你可以轻松遍历它 检索每个记录及其内容 现在 你已了解 如何访问记录的内容 接下来 让我们看看 如何在发生变化时使用事件 接收事件的代码可以通过 包装在任务中的简单循环来实现 当 Core Location 观察到监测条件的状态 与最后的事件报告的状态不同时 Core Location 将通过监测器上的 events 异步序列属性 来传递新的事件 这会恢复等待循环 传递的事件对象将为你提供新的状态 和受影响条件的标识符 或者 在处理新事件时 你还可以使用标识符 来获取记录和该条件的最后事件 我们可以利用这些信息 来更深入地了解发生的情况 请看！ 我们的简单问候程序已经完成了 现在你了解了 CLMonitor 的工作原理 我有一些建议 帮助你更好地使用它 先从三个关键要求开始说起 首先 你可以使用 不同的名称来创建多个监测器 以分隔处理不同的条件 但是 对于给定的名称 你一次只能实例化一个 因为 CLMonitor 维护着 它正在监测的条件的状态 若尝试使用相同的名称 初始化另一个监测器 可能会导致意外行为 其次 由于事件可能 以不可预测的方式到达 最好始终在监测器的 事件序列上等待任务 只有在你处理完事件之后 事件才能成为某个记录的最后事件 因此 若在你不等待事件的情况下 条件发生了状态变化 你的监测器将无法反映 新的状态 直到你进行等待为止 最后 如果系统终止了你的 App 当任何监测条件遇到事件时 只要它被授权接收用户位置信息 Core Location 将在后台启动你的 App 这表示 如果你的 App 希望 在条件状态发生变化时得到通知 那么 每次 App 启动时 都需要重新初始化监测器 并等待相关事件的发生 其中一种方法是通过监听 didFinishLaunchingWithOptions App 委托回调来实现

由于新的 API 导致了启动行为 我强烈建议只从你的 App 中 使用 CLMonitor 若在小组件或插件中 使用它 你的 App 将会启动 这可能会导致同一名称的监测器 存在多个实例 增加了管理的复杂性 最后 我之前也提到过： 条件及其状态是持久的 当 CLMonitor 观察到 所监测的条件之一的状态 发生变化时 就会生成事件 因此 我强烈建议查看 CLMonitor 所表示的这些状态 而不是在你自己的表格中维护它们 以免与到达的事件不同步 话虽如此 但某些 App (例如 SwiftUI 可视化) 可能需要保留单独的表示 如果需要这样做 请将该表示保留给 SwiftUI 且不要用它来推断预期事件 这就是 CLMonitor！ 我对我们的新 API 充满期待 快试试看吧！ 我们希望它能 极大地改善你的监测体验 我们非常乐意倾听你的反馈意见 我们还提供了一个示例 App 其中展示了 CLMonitor 的功能 可以在本视频的资源部分 下载并尝试使用 最后 记得观看我的同事 Siraj 关于位置更新的课程 感谢你的观看！