欢迎访问 weekly.fatbobman.com[1] 订阅本周报的中英文电子邮件版本。你也可以直接访问我的网站 肘子的 Swift 记事本[2] 更多的周报内容。
肘子的话
苹果用 M4 来展现拥抱 AI 的决心
在 5 月 7 日，苹果终于在时隔一年半后更新了 iPad 系列，其中最引人注目的是，新款 iPad Pro 直接搭载了最新的 M4 芯片。据网络上流出的跑分数据显示，M4 在性能上大幅超越了 M2 甚至 M3 芯片。
苹果宣称，M4 芯片在机器学习性能上有显著提升，特别大幅增强了神经处理单元（NPU）的性能。具体的 AI 性能表现如何，可能还需与 WWDC 2024 中发布的新系统和新 API 配合才能完全展现。在 iPad Pro 上首发 M 系列最新芯片，苹果此举打破传统，充分显示了其在 AI 时代赶超其他厂商的决心。
随着 M4 芯片的引入，我对苹果今年可能发布的 Mac 产品线充满期待。所有迹象都指向，苹果将在 WWDC 2024 上推出若干与 AI 有关的更新和新功能、新服务。作为一名苹果生态系统的开发者，我不仅期望在开发过程中体验到 AI 带来的便捷，也希望苹果能推出更多安全、易用的 API，帮助开发者在应用中为用户提供出色的 AI 服务。
鉴于苹果对隐私的一贯重视，预计大多数 AI 功能都将基于设备本地运行。这不仅对设备的 AI 性行能提出了更高要求，同时也对能耗是一大挑战。毕竟，用户不希望在更新新系统后，设备的电池续航时间大幅缩短。我迫切希望了解苹果如何在 AI 的性能、能耗、隐私、开发便利性和使用体验等方面找到平衡。
尽管生成式 AI 目前正处于热潮之中，且苹果与一些顶尖的生成式 AI 服务商之间的合作消息不断，但我始终认为，日常的 AI 功能主要应该基于本地设备，使用较小的模型，以对用户几乎无感的方式默默服务。在 AI 时代，高效节能的硬件设备显得尤为关键。 搭载 M4 芯片的 iPad Pro 将更加专注于能够突显其 “Pro” 级别定位的场景。对大多数用户来说，具备了一定 AI 能力且性价比更高的基于 M2 芯片的新 iPad Air 或许是更合适的选择。
不论你是否关注 AI，无可否认的是，AI 将引发新一轮的设备更新潮及应用体验革新（至少在营销层面如此）。作为开发者，我们必须为此做好准备，即便目前可能不立即提供或应用 AI 服务，也应对 AI 开发的基本操作和应用场景有所掌握。
前一期内容｜全部周报列表
原创
精通 SwiftUI 的 containerRelativeFrame 修饰器[3]
Fatbobman( 东坡肘子 )[4]
containerRelativeFrame 修饰器从其所作用的视图开始，沿视图层次结构向上寻找最近的符合容器列表中的容器。根据开发者设置的变换规则，对该容器提供的尺寸进行计算后，以此作为视图的建议尺寸。从某种意义上讲，它可以视为一个允许自定义变换规则的特殊版本 frame 修饰器。这个修饰器使得一些以往难以通过常规方法实现的布局操作变得十分简单。
本文将深入探讨 containerRelativeFrame 修饰器，内容涵盖定义、布局规则、使用场景以及相关注意事项。在文章的最后，我们还将创建一个兼容旧版本 SwiftUI 的 containerRelativeFrame 复刻版，通过这一实践加深对其功能的理解。
近期推荐
Swift’s native Clocks are very inefficient（ Swift 的原生时钟效率极低 ）[5]
Wade Tregaskis[6]
在 Swift 并发编程中，ContinuousClock 和 SuspendingClock 被用于管理时间和延迟任务。ContinuousClock 是一个持续运行的时钟，不会因为系统睡眠或其他因素而停止。而 SuspendingClock 在系统挂起（如进入休眠状态）时会停止。本文作者 Wade Tregaskis 通过测试发现，尽管这两种时钟的绝对运行开销很小（大多数情况下为亚微秒级），频繁使用它们处理时间和计时问题时，它们的效率不足可能成为严重的性能瓶颈。
本文的观点在开发者社区中引发了广泛讨论，许多开发者在 HackerNews[7] 上分享了自己的看法和建议。
How to train your first machine learning model and run it inside your iOS app via CoreML（ 如何通过 CoreML 在你的 iOS 应用中训练并运行你的第一个机器学习模型 ）[8]
Felix Krause[9]
在这篇文章中，Felix Krause 细致地解释了如何利用 CoreML 在 iOS 应用内部实现您的第一个机器学习模型。全文详细介绍了整个过程的关键阶段：数据收集、数据准备与模型训练、模型导出、模型集成、以及模型的设备内执行。除了阐述如何在应用中部署机器学习模型的具体技术步骤外，本文还深入探讨了相关的最佳实践和可能遇到的挑战。
Turning AirPods into a Fitness Tracker to Fight Cancer（ 将 AirPods 变为健身追踪器以助力抗癌 ）[10]
Richard Das[11]
在这篇文章中，Richard Das 介绍了如何利用 AirPods 的运动传感器功能，通过结合 Core Motion、SwiftUI 和一点人工智能技术，开发出一个能够统计俯卧撑数量的应用。这个项目不仅展现了技术解决实际问题的潜力，也体现了创造有意义事物时的个人成就感和乐趣。
本文是作者响应 Cancer Research UK 在 2024 年 4 月发起的 100 Push-Ups a Day Challenge[12] 活动，该活动旨在提高公众对癌症的意识。
New Tutorial of TCA - Building SyncUps（ TCA 的新教程 ）[13]
Point-Free[14]
Composable Architecture (TCA) 是一个功能强大的框架，其最新的 1.10 版本引入了高效的状态共享工具。这些工具使得在应用的多个功能模块之间无缝共享状态成为可能，同时支持状态的持久化存储，如用户默认设置和文件系统，保证了功能的 100%可测试性。本教程详细介绍了如何从零开始构建一个名为 “SyncUps” 的复杂 SwiftUI 应用，涵盖了如使用值类型模型化领域、从状态驱动导航、简化领域模型、控制依赖关系以及深入测试应用逻辑等多个核心原则。
Migrating from CocoaPods to Tuist at Playtomic（ 从 CocoaPods 到 Tuist 的迁移：Playtomic 的案例研究 ）[15]
Mohammadreza Koohkan
随着 Playtomic 项目规模的扩大，原有的 CocoaPods 依赖管理工具开始显得力不从心。团队面临的主要问题包括：与 SwiftUI 和现代 Swift 包的兼容性问题、Xcode SwiftUI 预览功能中断、storyboards 加载缓慢、以及 Podfile 复杂性增加和依赖维护困难等。为解决这些问题，Playtomic 决定迁移到 Tuist，这是一款能够优化项目结构和提升构建效率的工具。
在本文中，Mohammadreza Koohkan 详细介绍了迁移过程中遇到的挑战和实施的解决策略。迁移结果表明，Tuist 不仅解决了与 CocoaPods 相关的问题，还显著改善了 app 的启动时间和减小了二进制文件的大小。此外，与 CocoaPods 相比，Tuist 的编译时间更短。
Tuist[16] 是一个开源工具，旨在帮助开发者管理 Xcode 项目和工作空间的配置和依赖关系。它通过简化项目配置和自动化重复任务来改善大型项目和团队的开发体验。
