期待与失望的循环：苹果的 AI 困境与韧性｜肘子的 Swift 周报 #074

admin管理员组

文章数量:1037775

期待与失望的循环：苹果的 AI 困境与韧性｜肘子的 Swift 周报 #074

期待与失望的循环：苹果的 AI 困境与韧性

几天前苹果宣布将 “More Personalized Siri” 功能推迟到明年，再结合始终不见踪影的 Swift Assist，很显然，苹果没有达成其在 WWDC 2024 上构建的 AI 愿景。至少在大模型的应用场景上，苹果没有展现出一贯的快速跟随能力。

但就此断定苹果在本次 AI 浪潮中失去了反击的能力还为时尚早。无论是有意还是无意，苹果在转向 M 系列芯片时采用的统一内存机制让其 Mac 系列设备具备了相当不错的本地模型推理能力。而且，随着最新支持 512GB 内存的 Mac Studio 推出，苹果又以另外的身份在本次 AI 变革中取得了一席之地。

虽然英伟达仍是模型训练和推理的首选，但 Mac 设备凭借高集成度与高能效比，已吸引不少用户。随着更多模型优化适配 MLX，其在大模型推理中的表现有望进一步提升。

当然，Mac 设备取得的成绩仍无法掩盖苹果在大模型方向上反应不及时的窘境，但至少表明了一些多管齐下的大企业所具备的天然优势：东边不亮西方亮。这种策略多元性恰恰是科技巨头在面对快速变化的技术浪潮时的一张王牌。

大模型真的代表未来？没能紧跟这股浪潮，企业就一定会被淘汰吗？尽管我并不这样认为，但显然在当下的舆论环境中，消费者、投资者需要企业在大模型开发、应用等领域中交出一份有感的答卷。也就是即便企业有既定的 AI 发展路线，也可能因市场和舆论环境的变化而被迫调整。

于是，我们就在最近的一年以及未来的几年中会看到越来越多的 PPT 式的愿景发布会。不给出期待大家会失望，给出了期待但没有达成大家会继续失望。这种"期待-失望"的循环似乎已成为科技行业的新常态，特别是在 AI 这样充满不确定性的领域。

在 AI 领域，企业既要保持定力，又要让市场满意，这种平衡正变得越来越难，“期待-失望”的循环也许已成为行业的常态。对于开发者和企业来说，或许真正的智慧在于既能拥抱创新浪潮，又不盲目追随市场喧嚣，在踏实做事与满足期待之间找到平衡点。毕竟，技术的真正价值不在于其炫目的承诺，而在于它能为用户带来的实际改变。

原创

让 @State 实现懒加载[4]

Observation 框架为 Swift 带来了原生的属性级观察能力，有效避免了 SwiftUI 中因无关属性变化而引发的多余视图更新，从而提升了应用性能。但由于@State并未提供类似@StateObject的懒加载构造方式，在某些场景下会因实例过早构建而引起性能损失甚至逻辑问题。本文将探讨如何为 Observable 实例定制一个支持懒加载的@State解决方案。

近期推荐

在 Swift 中动态构造泛型类型的方法探索 [5]

泛型类型通常需要在编译期确定具体类型，但在部分特殊场景下，编译期无法提供足够的类型信息。Kyle Ye[6]在开发OpenSwiftUI[7]时，发现 SwiftUI 中的_ConditionalContent<TrueContent, FalseContent>就属于这种情况。本文介绍了一种通过定义自定义的Metadata和ProtocolDescriptor类型来访问和解析运行时类型信息，以动态构建泛型类型的实现方案。

巧用视图复用，提升 SwiftUI 滚动列表性能 [8]

SwiftUI 提供了List、LazyVStack等惰性容器，但在处理大规模数据时，这些组件的性能仍然存在局限性。此外，SwiftUI 目前的Layout协议尚未支持惰性加载，使得开发者难以通过原生方式构建更高效的自定义滚动容器。在本文中，Matthaus Woolard[9]采用行复用机制，通过动态调整视图位置而非创建新视图，实现了一种适用于固定高度、重复子视图的高性能滚动容器。这种方法虽对适用场景有所限制，但其核心思路对于优化 SwiftUI 视图性能具有重要的借鉴价值。

原文中的代码较为分散，我已将其整理并汇总至 Gist[10]，方便阅读和参考。

XCode 虚拟目录万年问题探究与我的开源工具解决方案[11]

长期以来，Xcode 采用虚拟目录管理项目，不仅导致多人协作时合并冲突频繁，也对 CI/CD 流程和现代工具的兼容性不友好。随着 Apple 逐步优化 Xcode 目录管理，现代 Xcode 项目已更多依赖实际文件结构，但对于历史遗留项目，虚拟目录仍然是一个棘手的问题。在本文中，ZhgChgLi[12]详细分析了虚拟目录的影响，并介绍了他的开源工具XCFolder[13]。该工具可自动将 Xcode 项目中的虚拟目录转换为实际文件目录，使项目结构更加清晰，同时兼容XcodeGen和Tuist，为 Xcode 项目的现代化管理提供了一种高效的解决方案。

SwiftUI 性能优化：如何有效结合 UIKit [14]

随着 SwiftUI 功能的不断丰富，越来越多的开发者选择以 SwiftUI 为核心构建应用，同时在性能关键的场景中引入 UIKit 以优化体验。在本文中，Majid Jabrayilov[15]探讨了如何在 SwiftUI 架构下合理结合 UIKit，以兼顾开发便捷性和运行效率。文章重点介绍了UIHostingConfiguration——一个能够在UITableViewCell或UICollectionViewCell内高效集成 SwiftUI 视图的机制。通过这种方式，开发者可以充分利用 UIKit 的高效视图复用，同时保持 SwiftUI 组件的灵活性，从而提升应用在处理大规模数据时的流畅度。

清理 Xcode 垃圾文件，释放 Mac 磁盘空间 [16]

对于苹果开发者来说，Xcode 占用大量磁盘空间是一个常见问题，影响系统性能和开发效率。Karin Prater[17]在本文中详细解析了 Xcode 生成的各种文件类型，并提供了一系列安全、高效的清理方法，帮助开发者释放磁盘空间，优化开发环境。

从零到一：构建复杂系统的探索之路 [18]

传统的 macOS CI 运行环境（基于 Mac 物理机）易受到外部干扰，导致环境漂移和构建不稳定。Paul Samuels[19]旨在通过引入虚拟化技术，使 CI 运行环境更加可控和可复用。在这篇文章中，Paul 分享了他的构建过程，从最初的问题定义、工具调研，到原型验证，最终实现了一个稳定且可重复使用的解决方案。这不仅是一次技术探索，更展示了复杂系统构建的全过程。

Apple 开发者官方公众号现已上线

欢迎关注 Apple 开发者的微信官方公众号，获取面向中文开发者社区的最新新闻、公告和活动动态。

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-03-10，如有侵权请联系 cloudcommunity@tencent 删除模型苹果性能swift开发者

期待与失望的循环：苹果的 AI 困境与韧性｜肘子的 Swift 周报 #074

期待与失望的循环：苹果的 AI 困境与韧性

几天前苹果宣布将 “More Personalized Siri” 功能推迟到明年，再结合始终不见踪影的 Swift Assist，很显然，苹果没有达成其在 WWDC 2024 上构建的 AI 愿景。至少在大模型的应用场景上，苹果没有展现出一贯的快速跟随能力。

但就此断定苹果在本次 AI 浪潮中失去了反击的能力还为时尚早。无论是有意还是无意，苹果在转向 M 系列芯片时采用的统一内存机制让其 Mac 系列设备具备了相当不错的本地模型推理能力。而且，随着最新支持 512GB 内存的 Mac Studio 推出，苹果又以另外的身份在本次 AI 变革中取得了一席之地。

虽然英伟达仍是模型训练和推理的首选，但 Mac 设备凭借高集成度与高能效比，已吸引不少用户。随着更多模型优化适配 MLX，其在大模型推理中的表现有望进一步提升。

当然，Mac 设备取得的成绩仍无法掩盖苹果在大模型方向上反应不及时的窘境，但至少表明了一些多管齐下的大企业所具备的天然优势：东边不亮西方亮。这种策略多元性恰恰是科技巨头在面对快速变化的技术浪潮时的一张王牌。

大模型真的代表未来？没能紧跟这股浪潮，企业就一定会被淘汰吗？尽管我并不这样认为，但显然在当下的舆论环境中，消费者、投资者需要企业在大模型开发、应用等领域中交出一份有感的答卷。也就是即便企业有既定的 AI 发展路线，也可能因市场和舆论环境的变化而被迫调整。

于是，我们就在最近的一年以及未来的几年中会看到越来越多的 PPT 式的愿景发布会。不给出期待大家会失望，给出了期待但没有达成大家会继续失望。这种"期待-失望"的循环似乎已成为科技行业的新常态，特别是在 AI 这样充满不确定性的领域。

在 AI 领域，企业既要保持定力，又要让市场满意，这种平衡正变得越来越难，“期待-失望”的循环也许已成为行业的常态。对于开发者和企业来说，或许真正的智慧在于既能拥抱创新浪潮，又不盲目追随市场喧嚣，在踏实做事与满足期待之间找到平衡点。毕竟，技术的真正价值不在于其炫目的承诺，而在于它能为用户带来的实际改变。

原创

让 @State 实现懒加载[4]

Observation 框架为 Swift 带来了原生的属性级观察能力，有效避免了 SwiftUI 中因无关属性变化而引发的多余视图更新，从而提升了应用性能。但由于@State并未提供类似@StateObject的懒加载构造方式，在某些场景下会因实例过早构建而引起性能损失甚至逻辑问题。本文将探讨如何为 Observable 实例定制一个支持懒加载的@State解决方案。

近期推荐

在 Swift 中动态构造泛型类型的方法探索 [5]

泛型类型通常需要在编译期确定具体类型，但在部分特殊场景下，编译期无法提供足够的类型信息。Kyle Ye[6]在开发OpenSwiftUI[7]时，发现 SwiftUI 中的_ConditionalContent<TrueContent, FalseContent>就属于这种情况。本文介绍了一种通过定义自定义的Metadata和ProtocolDescriptor类型来访问和解析运行时类型信息，以动态构建泛型类型的实现方案。

巧用视图复用，提升 SwiftUI 滚动列表性能 [8]

SwiftUI 提供了List、LazyVStack等惰性容器，但在处理大规模数据时，这些组件的性能仍然存在局限性。此外，SwiftUI 目前的Layout协议尚未支持惰性加载，使得开发者难以通过原生方式构建更高效的自定义滚动容器。在本文中，Matthaus Woolard[9]采用行复用机制，通过动态调整视图位置而非创建新视图，实现了一种适用于固定高度、重复子视图的高性能滚动容器。这种方法虽对适用场景有所限制，但其核心思路对于优化 SwiftUI 视图性能具有重要的借鉴价值。

原文中的代码较为分散，我已将其整理并汇总至 Gist[10]，方便阅读和参考。

XCode 虚拟目录万年问题探究与我的开源工具解决方案[11]

长期以来，Xcode 采用虚拟目录管理项目，不仅导致多人协作时合并冲突频繁，也对 CI/CD 流程和现代工具的兼容性不友好。随着 Apple 逐步优化 Xcode 目录管理，现代 Xcode 项目已更多依赖实际文件结构，但对于历史遗留项目，虚拟目录仍然是一个棘手的问题。在本文中，ZhgChgLi[12]详细分析了虚拟目录的影响，并介绍了他的开源工具XCFolder[13]。该工具可自动将 Xcode 项目中的虚拟目录转换为实际文件目录，使项目结构更加清晰，同时兼容XcodeGen和Tuist，为 Xcode 项目的现代化管理提供了一种高效的解决方案。

SwiftUI 性能优化：如何有效结合 UIKit [14]

随着 SwiftUI 功能的不断丰富，越来越多的开发者选择以 SwiftUI 为核心构建应用，同时在性能关键的场景中引入 UIKit 以优化体验。在本文中，Majid Jabrayilov[15]探讨了如何在 SwiftUI 架构下合理结合 UIKit，以兼顾开发便捷性和运行效率。文章重点介绍了UIHostingConfiguration——一个能够在UITableViewCell或UICollectionViewCell内高效集成 SwiftUI 视图的机制。通过这种方式，开发者可以充分利用 UIKit 的高效视图复用，同时保持 SwiftUI 组件的灵活性，从而提升应用在处理大规模数据时的流畅度。

清理 Xcode 垃圾文件，释放 Mac 磁盘空间 [16]

对于苹果开发者来说，Xcode 占用大量磁盘空间是一个常见问题，影响系统性能和开发效率。Karin Prater[17]在本文中详细解析了 Xcode 生成的各种文件类型，并提供了一系列安全、高效的清理方法，帮助开发者释放磁盘空间，优化开发环境。

从零到一：构建复杂系统的探索之路 [18]

传统的 macOS CI 运行环境（基于 Mac 物理机）易受到外部干扰，导致环境漂移和构建不稳定。Paul Samuels[19]旨在通过引入虚拟化技术，使 CI 运行环境更加可控和可复用。在这篇文章中，Paul 分享了他的构建过程，从最初的问题定义、工具调研，到原型验证，最终实现了一个稳定且可重复使用的解决方案。这不仅是一次技术探索，更展示了复杂系统构建的全过程。

Apple 开发者官方公众号现已上线

欢迎关注 Apple 开发者的微信官方公众号，获取面向中文开发者社区的最新新闻、公告和活动动态。

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-03-10，如有侵权请联系 cloudcommunity@tencent 删除模型苹果性能swift开发者

本文标签： 期待与失望的循环苹果的 AI 困境与韧性｜肘子的 Swift 周报 074