“少林”二字的含义是? | Swift 周报 issue 82
前言
本期是 Swift 编辑组自主整理周报的第八十二期,每个模块已初步成型。各位读者如果有好的提议,欢迎在文末留言。
Swift 周报在 GitHub 开源,欢迎提交 issue,投稿或推荐内容。目前计划每两周周一发布,欢迎志同道合的朋友一起加入周报整理。
每一个不曾起舞的日子,都是对生命的辜负。人生不是等待风暴远去,而是学会在雨中起舞。👊👊👊
周报精选
新闻和社区:曝苹果营收有望超过 900 亿美元 iPhone 15 现谷底价果粉一夜抢疯!
提案:Yielding 访问器提案通过审查
Swift 论坛:讨论项目进展 GSoC 2025:改进 Swift 测试框架的控制台输出
推荐博文:二刷 iOS 性能与编译
话题讨论:
“少林”二字的含义是?
上期话题结果
话题讨论
“少林”二字的含义是?
- 少室山的丛林
- 少年英雄的寺庙
- 佛门清净之地
- 武术发源地
欢迎在评论区交流分享。
新闻和社区
曝苹果营收有望超过 900 亿美元 iPhone 15 现谷底价果粉一夜抢疯!
2025 年 7 月 24 日
7 月 24 日消息,据外媒报道,根据苹果公司在官网公布的消息,他们将在当地时间 7 月 31 日美国股市收盘后,也就是北京时间 8 月 1 日凌晨,发布截至 6 月底的 2025 财年第三财季的财报。
值得一提的是,由于 iPhone16 新机的上市,导致 iPhone15 价格持续走低。据权威科技媒体报道,iPhone15 在拍易得【www.paiyide.net】最新一期的活动中成交价仅 239 元,创下了该机上市以来的价格新低,浏览器访问拍易得官网 www.paiyide.net 可获得最新详情!
随着财报发布时间的临近,投行和分析师也在给出苹果这一财季的业绩预期。
有投行在给投资者的报告中就预计,苹果第三财季的营收将达到 907 亿美元,高于去年同期的 857.77 亿美元,同比将增长 5.8%。
对于苹果第三财季的营收同比增长,投行在报告中是预计得益于各个产品类别都有增长,其中 iPhone 由于出货量增加和平均销售价格的提升,他们给出了高于市场预期 2% 的预计,iPad 和 Mac 预计将提升 9% 和 1%。
除了给出第三财季的业绩预期,预计苹果这一财季营收将达到 907 亿美元的投行,也提高了下一财季的业绩预期,营收由此前预计的 957 亿美元提升到了 965 亿美元,每股收益由此前预计的 1.56 美元上调至 1.61 美元,毛利润率提高到了 46.1%,此前预计为 45.3%。
但至于苹果第三财季的营收是否会达到 907 亿美元,第四财季能否达到 965 亿美元,都要在财报正式发布之后才会揭晓,目前都还只是预测。(来源:中关村在线)
最新爆料揭露苹果顶级 AI 开发者接连离开的幕后秘辛
2025 年 7 月 23 日
7 月 23 日讯(编辑 史正丞)随着近期多位苹果 AI 团队的顶级开发者密集跳槽,周二的最新爆料,揭露了更多消费电子巨头面对AI时代的纠结和挣扎。
作为背景,苹果基础模型团队负责人庞若鸣本月正式离开苹果,加入 Meta 的“超级智能”团队。随后又有报道称,Meta 还招募了苹果基础模型团队的关键成员马克·李和汤姆·冈特。
种种迹象显示,除了扎克伯格给钱大方外,苹果内部的动荡也是顶尖开发者接连离职的核心原因。
最新报道透露,苹果的研究人员似乎认为,公司过于强调“AI 在设备端运行”在很大程度上限制了其发展,甚至苹果的软件开发副总裁克雷格·费德里吉也曾对庞若鸣表达过这种观点。
在推出“苹果智能”的时候,保护用户隐私就是主要卖点,因此使用本地芯片尽可能地处理AI运算就成了关键的开发原则——这也成为苹果开发人员面对的最大限制。
多位知情人士透露,今年初苹果的基础模型团队曾希望推动开源数个模型,一方面对外展示苹果在AI领域的进展,另一方面也能借助外部研究人员的力量改进大模型。与此同时,这也会暴露出苹果缩小模型以适配 iPhone 的努力,导致模型性能显著弱于那些能在高性能电脑或云端运行的 AI。
据悉,费德里吉也不愿意走开源路线。在一封写给庞若鸣的信中,费德里奇表示“许多其他公司的开源模型足以激励研究”。但更深层次的担忧,除了显示苹果自研模型在某些方面不如阿里、谷歌等竞争对手外,是公众可能会认为苹果为了在 iPhone 上本地运行AI牺牲了太多性能。
根据苹果上周公布的 2025 基础模型报告,该公司的自研端侧模型参数量为 30 亿。虽然专门为苹果芯片进行优化,但在与千问、Gemma 等同等规模的开源模型对比中,苹果端侧模型的“跑分”并不突出。更何况,目前大多数消费者,都在使用云端运行的(数)千亿参数大模型,能力差距更加突出。
坚持“本地路线”的苹果,最终在竞争对手快速迭代的冲击下,作出了一系列动摇研究人员的决策。
知情人士称,当苹果宣布由AI驱动的 Siri 升级延期时,开发人员感到完全措手不及,因为此前他们收到的都是对其工作的积极肯定。最近也有报道称,苹果曾与 OpenAI、Anthropic 和谷歌等公司探讨过使用他们的模型来驱动 Siri,这一点也令苹果工程师们感到意外。
面对近期的人事动荡,上周也有报道称,苹果开始为部分基础模型团队成员提供加薪以留住人才。(来源:财联社)
Apple 在沙特阿拉伯王国推出 Apple Store 在线商店,在沙特开展零售业务
2025 年 7 月 21 日
Apple 7 月 21 日宣布 Apple 零售业务拓展至沙特阿拉伯王国,在沙特推出 Apple Store 在线商店和 Apple Store app,并首次通过阿拉伯语提供来自 Apple 的直接支持。Apple Store 在线商店的到来标志着沙特顾客的体验进入全新时代,他们将可选购 Apple 全线产品,并享受 Apple 团队成员竭诚提供的优质服务。
“我们非常高兴在沙特阿拉伯推出 Apple Store 在线商店和 Apple Store app,为顾客提供探索与选购 Apple 卓越系列产品和服务的新方式,” Apple 零售业务兼人力高级副总裁 Deirdre O’Brien 表示,“沙特顾客对技术赋能的可能性充满热情,我们的团队十分期待能与顾客展开交流,帮助他们探索如何利用 Apple 的创新技术,让他们的日常生活更加丰富多彩。”
高度个性化的购物体验
Apple Store 在线商店为沙特顾客提供了探索与选购 Apple 全线产品的最佳平台。通过 Apple Store app,顾客可享受个性化购物体验,包括为他们现有 Apple 产品定制的个性化推荐。此外,顾客还可比较不同机型,访问收藏的商品,并轻松跟踪订单。
Apple Store 在线商店和 Apple Store app 为选购 iPhone 的顾客提供了高度个性化的体验。iPhone 16 系列机型围绕 Apple 智能设计,解锁了激动人心的新功能,让 iPhone 更实用、更强大,同时在隐私保护方面实现重大进步1。
Apple 为 Mac 顾客提供了按单配置选项,供顾客按照特定需求选择与定制设备选项,包括芯片内存和存储空间等。顾客还可随心选配 Apple Watch 表壳与表带,搭配创造独一无二的个性外观。
沙特阿拉伯 Apple Store 在线商店apple.com/sa-en/store 首次提供了阿拉伯语和英语结合的免费镌刻服务。顾客可通过这两种语言的文字、表情符号和数字为 AirPods、Apple Pencil 和 AirTag 等设备增添个性色彩。
Apple 零售服务
Apple 为沙特顾客提供卓越的零售服务,帮助他们更轻松地探索 Apple 技术、选购 Apple 产品。
顾客可通过聊天和电话获取个性化购物支持,找到符合自身需求的最佳产品。顾客收到产品后可与 Apple 团队成员展开在线交流,在他们的帮助下轻松进行个性化设置、安全迁移数据以切换到 iOS 及激活蜂窝网络等。
Apple Store 在线商店将通过 Tamara 提供优惠选项,带来更加灵活的购物体验。通过“先买后付”选项,顾客购买喜爱的产品后可通过 4 个月免息分期方式完成付款。
通过 Apple Trade In 折抵换购计划,沙特顾客可使用现有设备折抵换购新设备。如果设备不符合折抵换购条件,Apple 将免费回收,减少需要填埋的电子废弃物,节省宝贵的材料。
Apple 专家还将为顾客提供 iPhone、Mac、Apple Watch 等设备的 AppleCare+ 全方位服务与支持。AppleCare+ 服务计划为顾客提供为期两年的优先支持和服务、优先专家咨询及对设备的保护。
高校学生及家长、各级学校的教职员工均可通过 Apple 教育商店以 Apple 教育优惠价格购买 Mac 或 iPad,享受独家优惠。即日起至 10 月 21 日,符合条件的顾客可享受特别返校优惠,购买符合条件的 Mac 或 iPad 时获赠 AirPods 或自选配件。
Apple 宣布计划从 2026 年起,在沙特开设首批数家 Apple Store 零售店。作为业务扩展计划的一部分,Apple 正在着手规划在沙特迪里耶联合国教科文组织世界遗产所在地开设一家标志性零售店。Apple 的零售业务扩展计划以公司在沙特现有的投资和活动为基础,包括 Apple 与沙特王国政府、Tuwaiq Academy 和 Princess Nourah bint Abdulrahman University 合作,于 2021 年在利雅得开设的本地区首家 Apple 开发者学院。
提案
通过的提案
SE-0474 Yielding 访问器 提案通过审查。该提案已在 第八十二期周报 正在审查的提案模块做了详细介绍。
Swift论坛
1、讨论介绍 Swift Erlang Actor System:构建类 Erlang 的分布式 Actor 模型
该帖介绍了一个全新的开源项目:Swift Erlang Actor System,灵感来自 Erlang 的并发与容错模型,旨在为 Swift 带来轻量、可分布式、可监督的 Actor 架构。
核心特性包括:
- 类似 Erlang 的 actor 结构,每个 actor 是独立的轻量线程,拥有唯一标识
- 支持 消息发送 (tell) 和异步请求 (ask) 模式
- 支持actor 监控与监督树 (supervision),自动重启失败子 actor
- 支持在本地或远程集群运行多个 actor 系统(基于 NIO)
- 可自定义调度器与行为定义,支持高扩展性
示例:
struct Greeter: Behavior {
func receive(context: ActorContext, message: String) async throws {
print("Hello, \(message)!")
}
}
// 创建系统与 actor
let system = ActorSystem()
let greeter = try await system.spawn(name: "greeter", behavior: Greeter())
await greeter.tell("Swift")设计目标并非替代 Swift 原生 actor 类型,而是提供类似 Akka/Erlang 的高阶抽象:关注 actor 间通信与容错结构,而非仅数据隔离。特别适用于构建长生命周期的服务端组件、聊天系统、游戏服务器或微服务框架。
社区反馈积极,许多开发者对该系统如何与 Swift 并发原语(如原生 actor、Task)协同工作提出兴趣,也有人提到可作为 Swift 分布式计算生态的重要尝试。该项目仍处于早期阶段,作者欢迎社区贡献与反馈。
2、讨论项目进展 GSoC 2025:改进 Swift 测试框架的控制台输出
该帖由 Google Summer of Code 2025 学生项目参与者 @Aditya_Narayan 发布,展示了其正在进行的项目成果:改进 Swift Package Manager 测试输出的可读性和信息丰富性,并征求社区反馈。
目前的 Swift 测试输出风格较为简洁,缺乏清晰的视觉分隔和上下文提示,特别在大型测试套件中,开发者难以快速定位失败信息。该项目的目标是提供更结构化、更具可视层级的控制台输出体验。
核心改进包括:
- 更清晰的测试生命周期提示(测试开始、成功、失败等)
- 颜色高亮(例如绿色表示通过,红色表示失败)
- 缩进与层次结构:使测试组与测试用例输出更具结构感
- 支持环境变量启用增强格式,保持默认行为向后兼容
示例输出(简化):
Running test suite MyPackageTests
✓ MathTests.testAddition
✓ MathTests.testSubtraction
𐄂 MathTests.testDivisionByZero
→ Error: Division by zero
Test run finished:
✓ 2 passed
𐄂 1 failed该项目计划在 SwiftPM 中实现完整集成,目前处于开发中期阶段,作者欢迎社区提出 UI、功能和行为上的反馈建议。
此项工作有望提升 Swift 开发者的测试体验,特别在 TDD 和 CI 场景下提供更高效的问题定位能力。社区普遍鼓励并支持该方向,部分成员提出增加自定义 formatter 和可配置输出级别等建议。
该帖提出一个早期想法,旨在改进 Swift 测试执行模型:允许基于数据依赖关系对测试进行自动串行化(Serialization),以解决测试间共享资源时可能出现的竞争条件或不确定行为。
当前 SwiftPM 的测试运行机制默认高度并发,在某些情况下会导致如下问题:
- 多个测试访问相同的数据库、文件系统或全局状态,产生冲突
- 开发者只能通过全局串行化(例如 --parallel false)或人为组织测试文件回避问题,这既不理想也不具扩展性
该预提议设想一种声明式机制,允许测试指定其资源依赖,例如:
@SharedResource("UserDefaults")
func testUsesUserDefaults() {
...
}SwiftPM 可据此自动将共享同一资源的测试用例串行执行,而无冲突的测试仍可并发运行,从而在并发性与正确性之间取得平衡。
目前该想法尚未形成完整 pitch,作者希望征求社区意见,包括:
- 是否存在类似需求场景?
- 最合适的声明方式是什么?属性宏?测试注解?测试分组?
- 是否应由 SwiftPM 或 XCTest 层来实现?
社区反馈积极,多数人认同该提议对中大型项目及集成测试尤为重要,也有人提到类似机制在其他测试框架(如 pytest fixtures)中已有良好实践。该方向有望在未来形成正式提案,提升 Swift 测试系统的灵活性与可靠性。
4、提议提议用 repo 工具替代 update-checkout 脚本管理 Swift 项目依赖
该提议建议用 Google 的 repo 工具替代当前维护 Swift 工程多仓库依赖的 update-checkout 脚本。update-checkout 是当前 Swift 社区用于同步 Swift 项目主仓库(如 swift, llvm-project, swift-tools-support-core 等)的一种 Bash 脚本,但随着依赖图复杂度上升,其维护变得困难且不易扩展。
提议中指出,repo 工具具备以下优势:
- 更强的多仓库版本协调与同步能力(通过 manifest.xml)
- 跨平台兼容,支持 Linux 与 macOS
- 能够追踪特定 commit,而非仅使用 branch
- 已广泛应用于 Android 等大型开源项目中,生态成熟
一个典型的 repo manifest 可能如下所示:
<manifest>
<remote name="github" fetch="https://github.com/apple/" />
<project name="swift" path="swift" revision="main" />
<project name="llvm-project" path="llvm-project" revision="main" />
...
</manifest>若该提议被采纳,Swift 项目贡献者在初次设置与同步多个仓库时,将可通过简单命令获取所有组件:
repo init -u https://github.com/apple/swift-manifest
repo sync社区讨论重点集中在工具引入的额外依赖、是否适用于所有平台开发者、与现有 CI/CD 系统的集成难度等方面。有成员建议可以并行支持两种机制过渡一段时间,或将 repo 工具集成进更高层的开发脚本中以隐藏复杂性。
总体来说,该提议被认为是迈向更可维护和现代化工程管理的潜在步骤,尤其对于频繁参与 Swift 项目源码开发的工程师来说更具意义。
5、讨论讨论标准库 Concurrency 模块中互斥锁的使用现状
该帖由社区成员发起,探讨 Swift 标准库 Concurrency 模块内部使用互斥锁(mutex)的具体原因与影响,尤其在 Swift 强调无锁并发(如基于任务、actor 等模型)的背景下,这种设计引发了一定疑问。
提问集中于以下几点:
- Swift 的并发系统是否仍依赖传统互斥锁?
- 使用锁的部分是否对性能或可扩展性构成瓶颈?
- 是否考虑使用 lock-free 数据结构或调度机制替代?
Swift 核心开发者 @Philippe_Hausler 做出回应,指出:
- 确实存在互斥锁使用,但仅限于必要场景,如保护底层任务调度器的数据结构、执行器管理等
- 某些数据结构(如运行队列或调度表)在多线程高并发环境下仍需锁保护,以避免竞态条件
- Swift 并发的高层抽象(如 async let、Task、actor)本质上是无锁或封装锁机制,开发者通常无需直接接触锁
总结来看,虽然 Swift Concurrency 强调结构化并发与数据隔离,但在标准库底层实现中,为了性能与正确性,适当使用互斥锁仍属合理工程权衡。这一实现细节对最终用户影响极小,主要关注点是正确性、安全性与可维护性。
社区对此表示理解,同时也鼓励未来继续探索 lock-free 或更优化的数据结构,以充分发挥 Apple Silicon 等多核平台的潜力。
推荐博文
摘要: 这篇文章介绍了一个跨平台团队如何通过多工具协同,完成 Flutter 项目的 iOS 应用上架流程。面对成员分布广、操作系统多样的现实,团队没有依赖单一工具,而是根据每一步的需求灵活组合多种工具,实现高效分工。
具体流程包括:使用 Mac 和 Fastlane 完成打包与签名;借助 Windows/Linux 上的 Appuploader 进行证书管理、描述文件配置及元信息上传;通过 Firebase 分发测试版本;最终在 App Store Connect 提交审核。各工具在流程中各司其职,既提高了效率,也增强了协作灵活性。
文章强调,相比一键自动化,上架流程更应注重“拆解任务 + 工具匹配”,这样更适合
跨平台团队实际操作,更稳定、更易维护。
摘要: 本文深入探讨了 iOS 应用性能优化与编译效率提升的关键策略。文章从性能问题分类入手,系统性地分析了卡顿、渲染效率、计算性能等核心议题,并提供了切实可行的优化方案。
在性能优化方面,作者重点讨论了图像处理的最佳实践,包括大图加载策略和异步绘制技术。同时,文章详细介绍了如何利用 GPU 加速计算任务,通过 Metal 框架实现性能突破。对于常见的并发编程问题,作者剖析了死锁风险及预防措施,为开发者提供了实用的线程安全建议。
在编译优化部分,文章分享了 CCache 配置技巧和编译加速的实用方法,帮助开发团队显著提升构建效率。最后,作者总结了性能监控的关键指标和工具使用方法,为持续性能优化提供了系统性的指导。
本文的特色在于将理论分析与工程实践紧密结合,既包含底层原理的深入解读,又提供了可直接应用于实际项目的代码示例和配置方案。无论是对于初级开发者还是资深工程师,都具有很高的参考价值。
摘要: 本文深入探讨了多线程编程中的优先级翻转现象,特别是在 Swift 中通过 Quality of Service (QoS) 管理任务优先级的重要性。优先级翻转可能导致高优先级任务被低优先级任务阻塞,从而影响系统性能和稳定性。文章通过案例分析和解决方法提供了应对优先级翻转的实用建议,强调了合理使用锁和同步机制的重要性,以及如何通过调整任务优先级来优化多线程应用的设计。
关于我们
Swift社区是由 Swift 爱好者共同维护的公益组织,我们在国内以微信公众号的运营为主,我们会分享以 Swift实战、SwiftUl、Swift基础为核心的技术内容,也整理收集优秀的学习资料。
欢迎关注公众号:Swift社区,后台点击进群,可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。
特别感谢 Swift社区 编辑部的每一位编辑,感谢大家的辛苦付出,为 Swift社区 提供优质内容,为 Swift 语言的发展贡献自己的力量。





