2022 年老司机技术参与组织的 WWDC22.playground Day 3 聚焦当时的 Beta 与技术探索。演示结果和嘉宾对框架实现的研究，应与 Apple 公开承诺的接口范围区分。
新框架发布时，最吸引人的往往是一段很短的演示代码。但真正把它用进产品，需要继续回答几个问题：它替开发者做掉了什么工作，代价转移到了哪里，遇到性能或兼容问题时又能看见多少？
WWDC22.playground Day 3 用两场实践和一轮圆桌回答这些问题。思华把 Swift Charts 与手工绘制图表放在一起比较；子琪从 ARKit 的基本概念出发，演示如何识别墙面并放上一幅图片。随后，EF、穆穆等嘉宾继续讨论锁屏组件、开发者模式、专注模式以及开发工具的更新。新能力不是一个名词列表，而是嵌入现有工程后的具体选择。
第一场实践：同一张折线图，两种实现方式
约 10:00 起，思华先说明比较方式：用同一份数据和相近的展示尺寸，分别实现新旧两种图表。目标是观察表达方式、代码工作量和呈现效果，而不是证明某个框架在所有场景中都更快。
使用 Swift Charts 时，他围绕数据构造图表，为每个数据点提供横纵坐标，再用 LineMark 表达折线。随后调整线宽、颜色、圆角等样式。为了让对比集中在绘制本身，演示还隐藏了部分坐标轴，并通过辅助容器统一尺寸。
这个过程把两种责任分开了：数据和图形之间的关系由图表框架表达，具体视觉样式则通过修饰继续调整。开发者仍然能决定线条怎样显示，但不必为每一张图都从路径、坐标换算开始搭建基础设施。
切换到原来的手工实现时，表面上的调用代码也不长，因为复杂逻辑已经封装进一个自定义组件。展开组件后，差别才出现：它需要把数据转换成绘制路径，处理局部坐标系和布局，再调整坐标方向，让最终画面符合预期。封装可以让使用处整洁，却不会消除内部实现与维护的工作。
思华继续替换不同的图形标记，展示框架提供多种表达的便利。这里的收益并不是“少写几行”这么简单，而是当图表需要增加样式或类型时，不必让每一种变化都扩展为自己维护的一套绘图基础代码。
他还分享了对图表底层渲染的观察。由于现场没有提供跨设备的性能基准，本文不将其归纳为“用了 Metal 就一定比自己画更快”。更稳妥的工程结论来自演示本身：对于框架已经覆盖的表达方式，Swift Charts 可以减少自行组织绘图逻辑的负担；具体性能仍要回到实际数据量、交互和目标设备中测量。
SwiftUI 进入已有项目，可以从局部开始
第一场演示之后，主持人没有立即转入下一项新功能，而是继续问：SwiftUI 到底怎样把上层描述变成屏幕内容，已有 UIKit 项目又如何采用？
约 32:11 起，讨论提到 UIHostingConfiguration，即在现有列表单元格中使用 SwiftUI 内容的方式。Apple 的WWDC22 课程《Use SwiftUI with UIKit》确实演示了这条路径，包括在单元格中放入图表。
这个变化的意义在于，采用新框架可以从一块具体内容开始，而不必把整个应用一次性重写。对已经有大量 UIKit 页面和业务逻辑的团队，局部验证更容易回答“这项技术是否适合当前问题”，也更容易把用户体验与维护成本放在同一张表上比较。
思华介绍了自己团队的一次重构经验：在产品关键表现不下降的前提下，业务代码明显减少，并观察到声明式表达对迭代和新人理解页面有所帮助。这是特定团队、特定页面的经验；它不能直接转换为所有项目都会节省相同比例代码或开发时间的承诺。
预览也在讨论中占了位置。对于结构清晰的小组件，修改后尽快看见效果，能缩短理解和验证的循环。但大型项目仍会受到存量依赖、编译耗时和环境复杂度影响。演示项目的即时反馈，不会自动成为复杂工程的整体体验。
写得更少之后，更需要看清数据如何影响界面
约 37:13 起，EF 提出了更接近生产使用的问题：代码少了，运行和调试会不会变得更难？有哪些坑需要提前知道？
思华的回答没有否认代价。声明式框架替业务层承担了大量工作，因此有些复杂度会从显式代码转移到框架执行中。开发者仍然需要把数据的来源、依赖关系和变化范围设计清楚，否则一次状态变化可能影响到原本不想更新的其他视图。
他举的典型问题是，某个属性本来只应改变 A 视图，却因为数据组织或依赖关系，使 B、C、D 也重新参与计算。这类问题不一定能从最后一张截图看出来，却可能在频繁更新时影响体验。
判断更新范围时，节目建议先使用可观察的工具信号，例如检查 body 被求值的频率，再结合实际渲染与耗时分析。需要保留其中的区别：body 被重新计算，并不等于每一次都会发生同等范围的屏幕重绘。把二者混为一谈，会让性能分析失去准确性。
为了进一步解释，思华展示了自己研究 SwiftUI 内部依赖关系的图，把计算节点、数据流和最终显示描述联系起来。即使是简单的文本，也涉及布局、环境、无障碍与动画等许多处理。本文把这部分保留为嘉宾理解框架的研究视角，不把私有节点名称当成开发者应依赖的稳定 API。
从这些观察中，他提炼出的实用原则比较明确：尽量让无关的数据变化不传播到不需要更新的内容；对确实不需要动画的部分，避免让它无谓地跟随动画时间变化；出现异常计算时，先确认依赖关系，而不是只在最终绘制处加优化。
节目也谈到把复杂绘制组合交给不同渲染方式处理。这里适合保留为需要实测的选项，而不是统一建议所有视图都加一个修饰符。一个页面少写了绘制调用，不一定意味着它减少了内存、离屏合成或其他成本。
锁屏与组件：一个更近的入口，也是一种更严格的产品约束
约 49:55 起，EF 把讨论从应用内部带到 WidgetKit。桌面和锁屏上的内容与普通页面不同：更新由系统安排，开发者不能把它简单当作一个一直运行、随时刷新的小应用。
嘉宾对新公布的 Live Activities 很感兴趣，希望持续变化的信息能集中在一个位置，减少用户反复打开应用或接收频繁推送的负担。但发言时，相关详细资料还没有完全到位，讨论者也明确表示不确定它与现有组件、通知机制的具体关系。回顾因此保留这种早期探索状态，不把后来稳定的实现方式补写成他们当时已经掌握的答案。
社区还提出了与当时生活有关的点子，例如把有时效的信息放到锁屏，减少查找步骤。随后有人提醒，这类内容可能涉及隐私，必须考虑锁屏可见范围与他人读取的风险。这段讨论的重点并不是某个点子现在是否仍适用，而是一个新的显示入口出现后，便利和信息暴露需要一起设计。
对于常亮显示等当时尚未确认的方向，节目只表达了期待与推测。它们不应与已经公开的 WidgetKit 更新合并成一份“当年已经支持”的功能表。
第二场实践：AR 会话、锚点与渲染，各自负责什么
约 57:50 起，子琪开始 ARKit 实践。他没有直接从一段庞大的代码进入，而是先拆开四个概念。
ARSession 管理与现实环境交互的会话；配置决定这次使用哪类跟踪能力；锚点为需要放置的内容提供空间参照；渲染技术负责把虚拟内容显示出来。识别现实环境和把模型画到屏幕上相互协作，但并不是同一件事。
他用相机输入、运动信息以及其他感知能力，解释应用怎样形成对空间的理解，再由 SceneKit、RealityKit 等选择完成可见的内容。这样拆解之后，开发者更容易知道问题属于哪一层：没有正确识别平面、内容放错位置和材质显示异常，需要检查的对象不同。
本场选择 Objective-C、ARKit 与 SceneKit，目标是识别一个竖直平面，并在上面放置图片。这个选型也照顾到当时仍以 UIKit 和 Objective-C 为主的开发者，让新能力可以从熟悉的视图结构进入。
实践的第一步是创建 ARSCNView，设置视图与代理，并在开发中打开调试信息，观察特征点与跟踪过程。随后检查目标配置是否受支持，启用需要的平面检测，再启动 session。
这里反复强调了能力检查。ARKit 虽然提供统一的软件接口，不同设备与系统仍可能支持不同能力。开始运行前就检查条件，比等待一个始终不出现的效果更容易定位问题。
墙不是一次识别完成的：处理新增、更新与移除
约 65:20 起，演示进入代理回调。子琪把它分为新增、更新与移除三个阶段。
刚开始扫描时，系统可能只确认了一小片表面；随着手机移动和信息增加，对平面的认识会扩展或修正。因此，应用不能在第一次发现锚点后就假设位置与范围永远不变。新增回调用来建立内容，更新回调用来跟进变化，移除则可能与重新组织或合并已经识别的平面有关。
如果应用自己记录了锚点和节点之间的关系，还需要保证这些记录跟随变化保持一致。所谓“识别出一面墙”，在代码里实际是一段持续维护的过程。
子琪展示了不同手机上的演示效果，讨论识别速度、特征点和硬件能力的差异。这里必须区分“这段演示没有成功”与“这台设备永远不支持”。Apple 在2018 年 ARKit 1.5 的公告中已经公布了垂直表面检测；因此，本文不沿用录播中把特定旧设备未检出平面直接归因于单摄、进而判定完全不支持的推断。具体能力应看所用配置的支持检查，具体失败还需要结合环境与代码确认。
完成空间定位后，交互仍从熟悉的触摸和手势开始。但屏幕上的点是二维的，场景里的对象处于三维空间，演示因此把触摸位置投射到场景中，找到对应对象或表面，再附加图片节点。
内容附着上去之后还要处理坐标方向。图片本身的平面与识别到的空间平面可能方向不同，需要根据所选节点与几何结构调整。节目还处理了图片闪烁，说明视觉问题可能来自深度和材质设置，而不是环境跟踪。这里保留的是定位问题的思路；某项深度设置只适用于该演示的对象关系，不应不加判断地复制到所有 AR 场景。
RoomPlan 与 ARKit 6：先理解现有设备，再等待新的设备
两场实践之间，嘉宾多次提到自己期待中的头戴设备并未在本届大会出现。但子琪在约 74:53 的延伸讨论中强调，现有设备上的 AR 能力仍在继续进步。
他关注 RoomPlan，是因为更容易使用的房间扫描能力可以降低应用尝试空间体验的门槛；他关注 ARKit 6，则是因为相机控制、图像获取等环节的进步，可能让 AR 与已有拍摄流程结合得更好。这是从具体工具出发的观察，不需要先假设某款未来设备何时出现。
问答末尾，有观众追问 LiDAR 如何应用到 ARKit 中。子琪说明，自己没有掌握所有底层参数细节；对于许多常规用法，开发者首先需要选择合适配置并检查支持条件，由框架整合可用的设备能力。这一回答没有把“框架帮助整合”扩大成“任何设备能力都完全无需配置”，也没有假装已经解释了全部传感器实现。
圆桌把新能力放回开发和使用流程
最后约 20 分钟并非两场演示的重复总结，而是继续提出了多项独立的观察。
开发者模式。 EF 介绍自己在 iOS 16 Beta 与新版 Xcode 上的体验，认为显式开启开发能力让设备使用者更清楚自己启用了什么。Apple 的当年课程把它限定在开发签名应用、调试与相关测试流程；App Store、TestFlight 和企业内部正式分发并不都要求这个模式。因此，不能把录播概括成“凡非 App Store 应用都必须开启”。
专注模式。 穆穆关注 Focus Filters：系统状态的变化可以影响应用内部呈现的内容，而不仅仅是允许哪些应用发通知。他从开发者角度谈应用如何声明可调整的行为，再从用户角度期待通信或效率应用配合不同情境显示合适的内容。技术入口最终要解决的是用户每次进入工作或生活场景时，需要反复手动调整什么。
自定义布局。 思华关注网格与开发者定义布局算法的能力。相比只能在已有容器中组合视图，新的布局工具使更特别的排列成为可表达的对象。Apple 的WWDC22 布局课程介绍了 Grid、Layout 等工具。节目中的潜在应用仍是设想，实际采用时要结合自己的布局与缓存需求。
构建和内存工具。 主持人谈到构建时间线，关注编译、模块构建、链接及前后置脚本究竟谁占了时间；也关注内存图中对象关系与关联内存信息的改进。这里共同的价值是把“感觉慢”或“怀疑泄漏”变成更可定位的问题。线程运行、Run Loop 与临时对象积累的讨论，也是在寻找可观察的证据，不应概括为每个后台线程都必须以同一种方式运行。
Bitcode 与后台资源。 EF 谈到过去为了开启 Bitcode，需要协调依赖库支持的困难，以及看到其变化后的疑问。Apple 的Xcode 14 发布说明明确记录了当年的弃用变化；至于最终包体积会怎样，节目没有给出测量，本文不补成必然结论。子琪最后提到 Background Assets，希望系统提供更多后台资源准备的时机，但也说明自己还没有深入阅读，因而本场只把它列作值得继续研究的方向。
这场实践留下的，是如何验证一个新能力
Day 3 从一张折线图开始，到在墙面上放一幅图，再延伸到锁屏、开发设备和构建工具。它的共同问题始终很具体：框架负责哪些工作，开发者仍需要负责哪些决定，出现意外时又怎样把问题拆开？
思华的实践提醒人们，不要被调用处很短的封装迷惑，要看整个实现和维护范围；子琪的实践则提醒人们，不要把一次视觉结果当成稳定的世界模型，要处理能力条件和持续更新。后面的圆桌把这两种态度带回产品：新入口能带来便利，也可能带来约束；工具更加自动化，并不意味着可以停止观察和验证。