WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Meet CloudKit Console

Meet CloudKit Console

System ServicesCloudKit
观看原视频

Highlight

Apple 推出 CloudKit Console，让开发者在浏览器中管理 CloudKit Schema、查询记录、部署生产变更、查看 Telemetry 和 Logs，降低调试同步数据与排查线上问题的成本。

核心内容

开发者把数据放进 CloudKit（iCloud 数据库服务）以后，真正麻烦的工作常常发生在上线前后。

开发阶段，你需要确认新的记录类型已经写入开发环境，字段类型没有填错，索引能支撑查询。上线前，你还要把开发环境的 Schema 推到生产环境，并确认这次部署不会破坏旧客户端。上线后，用户反馈同步失败，你需要知道请求有没有到达 CloudKit，错误数有没有在新版本发布后上升。

过去这些动作分散在不同视图里。定位一个问题时，开发者要先找容器，再切环境，再查记录，最后还要去看日志或指标。CloudKit Console 把这些动作放进一个统一界面：Database 负责 Schema 和记录，Telemetry 负责聚合指标，Logs 负责请求级别排查。

Apple 这次的改变没有引入新的客户端框架。它改的是 CloudKit 的开发者工作台。对使用 CloudKit 的 App 来说，这能直接缩短“写入数据—验证数据—部署 Schema—观察线上行为”的循环。

详细内容

管理 Schema：Record Type、字段和索引

（01:24）CloudKit 数据库位于 Container（容器）内。每个容器有 Development（开发环境）和 Production（生产环境）两个环境。开发者可以在开发环境使用 just-in-time schema creation（即时 Schema 创建），也可以在 Console 中定义数据模型。

（02:21）Record Type（记录类型）定义 CloudKit 数据结构。Console 的 Schema 页面可以查看记录类型、字段和索引。演讲示例中，开发者为 author 字段添加 sortable index（可排序索引），用于按字母顺序排序。

这场 session 没有 Code tab。下面的脚本把 Console 中的配置整理成可运行的数据结构，便于核对每一步。Console 本身通过网页完成这些操作。

const bookRecordType = {
  name: "Book",
  fields: [
    { name: "title", type: "String" },
    { name: "author", type: "String" }
  ],
  indexes: [
    { field: "author", type: "sortable" }
  ]
};

const sortableFields = bookRecordType.indexes
  .filter((index) => index.type === "sortable")
  .map((index) => index.field);

console.log(`${bookRecordType.name} can sort by: ${sortableFields.join(", ")}`);

关键点：

  • name: "Book" 对应 Console 中的 Record Type。
  • fields 列出记录类型包含的字段；演讲中添加字段时需要输入字段名并选择类型。
  • author 是演讲里用于 sortable index 的字段。
  • indexes 表示 Console 中创建的索引；演讲提到创建索引时要选择字段和三种索引类型之一。
  • filter((index) => index.type === "sortable") 模拟上线前检查：哪些字段支持排序。

用 Query Builder 验证开发环境记录

（03:35）Database app 的记录浏览采用从左到右的流程：先选择 Database（数据库），再选择 Zone（区域），最后选择 Record Type。选好上下文后，左侧显示记录列表，中间显示记录详情。

（04:02）Query Builder（查询构建器）可以添加过滤条件，找到目标记录。查询可以保存，之后继续开发时直接复用。Console 的 URL 也能指向具体功能，开发者可以把记录视图加入 Safari 书签。

const savedQuery = {
  environment: "Development",
  database: "Public",
  zone: "_defaultZone",
  recordType: "Book",
  filters: [
    { field: "author", operator: "equals", value: "Octavia Butler" }
  ]
};

function describeQuery(query) {
  const filterText = query.filters
    .map((filter) => `${filter.field} ${filter.operator} ${filter.value}`)
    .join(" AND ");

  return `${query.environment}/${query.database}/${query.zone}/${query.recordType}: ${filterText}`;
}

console.log(describeQuery(savedQuery));

关键点：

  • environment: "Development" 对应演讲中先在开发环境验证数据的流程。
  • database、zone、recordType 对应 Console 从左到右的三层选择。
  • filters 对应 Query Builder 里的过滤条件。
  • describeQuery 把一次查询变成可读文本，模拟保存查询前的人工核对。
  • 真实查询在 CloudKit Console 网页中执行，这段脚本用于记录团队约定的查询条件。

部署 Schema：先看 diff，再进生产环境

（05:08）开发环境中的 Schema 准备好后，点击 Deploy Schema Changes 会进入变更视图。这个视图展示生产环境当前 Schema 与开发环境待部署变更之间的差异。

（05:33）生产环境变更无法反向撤销。diff 视图的作用是让开发者确认只有预期改动会进入生产环境。CloudKit 也会验证更新完整性，避免破坏旧客户端。

const productionSchema = {
  recordTypes: {
    Book: {
      fields: ["title"],
      indexes: []
    }
  }
};

const developmentSchema = {
  recordTypes: {
    Book: {
      fields: ["title", "author"],
      indexes: ["author:sortable"]
    }
  }
};

const changes = {
  addedFields: developmentSchema.recordTypes.Book.fields
    .filter((field) => !productionSchema.recordTypes.Book.fields.includes(field)),
  addedIndexes: developmentSchema.recordTypes.Book.indexes
    .filter((index) => !productionSchema.recordTypes.Book.indexes.includes(index))
};

console.log(JSON.stringify(changes, null, 2));

关键点：

  • productionSchema 表示当前生产环境状态。
  • developmentSchema 表示开发环境中准备部署的状态。
  • addedFields 找出将被加入生产环境的字段。
  • addedIndexes 找出将被加入生产环境的索引。
  • JSON.stringify(changes, null, 2) 输出类似 diff 的结果，提醒开发者在点击部署前逐项确认。

用 Telemetry 和 Logs 排查线上行为

（05:46）Schema 部署后，Telemetry app（遥测工具）展示 App 与 CloudKit 数据库交互的关键指标。演讲列出的指标包括 Request Rate（请求速率）、Server Latency（服务器延迟）、Error Count（错误数量）和 Average Request Size（平均请求大小）。这些图表支持过滤，用来观察 App 行为随时间的变化。

（06:20）Logs app（日志工具）提供更细的请求处理输出。开发阶段可以用它验证请求，生产环境可以用它调查问题。

const telemetry = [
  { version: "1.0", requestRate: 120, serverLatencyMs: 80, errorCount: 2, averageRequestSizeKb: 14 },
  { version: "1.1", requestRate: 160, serverLatencyMs: 95, errorCount: 18, averageRequestSizeKb: 15 }
];

const previous = telemetry[0];
const current = telemetry[1];

const errorIncrease = current.errorCount - previous.errorCount;
const needsLogReview = errorIncrease > 10;

console.log({
  version: current.version,
  errorIncrease,
  needsLogReview
});

关键点：

  • telemetry 使用演讲中列出的四个指标：请求速率、服务器延迟、错误数量、平均请求大小。
  • version 对应演讲中“新版本行为是否异常”的观察场景。
  • errorIncrease 用来判断错误数量是否在新版本后上升。
  • needsLogReview 表示下一步应进入 Logs app 查看请求级别细节。
  • Telemetry 给出趋势，Logs 用于查看请求实际如何被 CloudKit 处理。

核心启发

  1. 做什么：给团队做一份 CloudKit 上线检查单。 为什么值得做：Console 的 diff 视图能展示开发环境到生产环境的 Schema 改动，生产变更无法反向撤销。 怎么开始：把每次要部署的 Record Type、字段和索引列成清单，在点击 Deploy Schema Changes 前对照 diff 逐项确认。

  2. 做什么：为常用调试场景保存 Query Builder 查询。 为什么值得做：演讲中展示了保存查询并在后续开发中复用的流程，适合反复验证同一类测试记录。 怎么开始：按 Database、Zone、Record Type 设置上下文，再为关键字段添加过滤条件，把结果页面或功能 URL 加入书签。

  3. 做什么：给新版本发布建立 CloudKit Telemetry 观察窗口。 为什么值得做：Telemetry 能展示请求速率、服务器延迟、错误数量和平均请求大小，适合检查新版本是否改变了数据库交互行为。 怎么开始：发布后固定查看 Error Count 和 Server Latency；如果指标升高，再进入 Logs app 查看同一时间段的请求处理细节。

  4. 做什么：把开发环境写入验证加入功能开发流程。 为什么值得做：Console 可以直接查看开发环境里的记录详情，能确认 App 实际写入 CloudKit 的内容。 怎么开始：每新增一个 Record Type，先在 Development 环境写入测试数据，再用 Query Builder 过滤目标记录并检查字段值。

  5. 做什么：为 Public Database 的安全角色做上线前复核。 为什么值得做：演讲提到 Public Database 的 security roles（安全角色）有新的 UI，用于管理公共数据库记录访问权限。 怎么开始：在 Schema 管理阶段打开 security roles 页面，检查读写权限是否符合产品预期，再部署到 Production。

关联 Session

评论

GitHub Issues · utterances