文章目录
前言
本期是 Swift 编辑组自主整理周报的第五十二期，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
Swift 周报在 GitHub 开源，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。
努力很难，但不努力，就会一直很难。若想得到这世间最好的东西，那么来Swift社区吧，先让世界看到最好的你！👊👊👊
周报精选
新闻和社区：中国销量狂降 19%：苹果在美国遭殃 iPhone 激活量跌至六年来新低
提案：
BitwiseCopyable提案重新恢复审查Swift 论坛：提议修复成员导入可见性
推荐博文：SwiftUI 中的内容边距
话题讨论：
能不能接受五一放一天不调休？
上期话题结果
通过投票结果可以看出，大家还是对 AI 电脑抱有很大的期望。期待新品能为我们的生活和工作带来更大的帮助。
新闻和社区
中国销量狂降19%：苹果在美国遭殃 iPhone激活量跌至六年来新低
2024 年 4 月 25 日
4 月 25 日消息，根据最新的市场研究机构 Counterpoint 数据显示，iPhone 在中国市场的销量在第一季度下降了 19％ ，从而在激烈的中国市场中跌至第三位。
这一下跌被认为是自 2020 年新冠疫情暴发以来 iPhone 在中国市场的最差季度表现。
一些业内人士指出，销量下降的部分原因是苹果在 2023 年初的出货量异常增加，同时也受到了本土品牌如华为等竞争的加剧。
不仅如此，在美国市场，苹果的表现也同样不尽如人意，iPhone 的激活比例下降至近年来的新低。
据最新数据显示，iPhone 目前在美国所有新激活智能手机中仅占三分之一，大幅低于去年的 40％。
苹果曾经在智能手机市场上占据主导地位，但现在面临来自 Android 设备的激烈竞争，Android 设备目前占据了新激活市场三分之二的份额。
这种市场格局的变化反映了六年前的情况，当时 iOS 和 Android 将黑莓和 Windows 等竞争对手挤出了市场。
iPhone 销量下降的原因有几个方面。随着智能手机价格的不断攀升，其耐用性也相应下降，这导致用户更长时间地使用旧设备。
智能手机生命周期的延长主要影响了苹果公司，因为该公司一直依赖频繁的升级来推动销量增长。目前，激活率的下降是智能手机市场消费者行为变化的一个重要指标。
人们越来越不愿意像以前那样快速升级设备，而更倾向于等待更实质性的更新或技术转变。（来源：快科技）
当苹果开始拼性价比
2024 年 4 月 24 日
4 月 24 日，iPhone 16 相关话题登上热搜，LeaksApplePro 在 X，即 Twitter 上的粉丝数约为 3.62 万人，其爆料称，苹果今年 iPhone 16 Pro 起步存储为 256GB，且售价可能维持 999 美元，国内起售价为 7999 元不变。
在内存涨价已成定局之时，苹果 " 加量不加价 " 看似违背行业规律，但在业内观点看来，这只是苹果回归市场现实的表现，1TB 手机普及的当下，iPhone 如果再在内存上做文章，维持高溢价，势必会进一步降低性价比，造成潜在用户流失，如今出货下滑的苹果也不得不作出理性的选择。
据市场爆料，iPad 2024 款也有了新的动向，不同于 iPhone 16，新款 iPad 可能在性能提升的同时价格也水涨船高，据悉新款 iPad Air 会有一个 12.9 英寸版本，是系列历史最大尺寸。价格方面，12.9 英寸版 iPad Air 将会贵 200 美元，起步价是 799 美元，约合人民币 5750 元，同样是 Air 系列的历史最高。
对于 iPhone 16 来说，如果消息属实，那么苹果可谓逆势而动，因为存储芯片价格自去年下半年开始便缓慢回升，至今仍在爬坡中，iPhone 16 如果在存储上加量不加价，势必增加公司的成本压力。
纵观近几年市场行情，存储芯片在 2022 年时降至谷底，包括三星在内的各大厂商亏损惊人，为此存储厂商纷纷调低产能，联合起来提升产品价格，三星计划在今年二季度将企业级固态存储价格在前一季度基础上上调 20% — 25%，此外集邦咨询发布报告指出，预计二季度 NADA Flash 合约价格将上涨 13% — 18%。
不过在专家看来，市场也不必为苹果担心，因为长期以来，苹果在内存容量上都挣着超额利润。从 iPhone 的定价策略看，，也就是说，在 iPhone 上每增加 128GB 容量就要增加 100 美元，这已经远远超过了存储芯片成本价。
资深产业经济观察家梁振鹏对北京商报记者分析称，那部分超出的价格，是苹果高利润的重要来源，也是其品牌溢价的一种体现，不过随着内存市场变得价格透明，手机企业在内存上做文章的空间也越来越小。另外，对于苹果而言，iPhone 的销量不佳也促使其放弃部分品牌溢价。
愈发激烈的竞争，也让 iPhone 在存储定价上向同行看齐，观察国内手机市场不难看出，1TB 手机愈发普及，如果苹果再不作出改变，或许难让消费者买单。
举例来说，早在 2023 年初，以一加 Ace Pro 为首的中端手机带头带来了 24GB+1TB 的超大存储版本，后续 Redmi、真我、OPPO、iQOO 等厂商也纷纷推出了性价比极高的超大存储手机。例如 Redmi 在 2023 年下半年发布的 Note 12 Turbo 的 16G+1TB 版本，在降价后的价格已经到了 1999 元，算是目前最便宜的 1TB 手机之一，甚至跟 12G+512G 相比也只差了 200 元。
反观 iPhone，相比起售价，用户购买 1T 版本要加 5000 元，这样的定价策略恐怕不符合国内市场的基调。
或许也正是因为超高的溢价，让苹果手机在国内的处境愈发艰难，一季度被同行反超，Counterpoint Research 数据显示，2024 年一季度，苹果公司中国区 iPhone 的销量下滑了 19%，为该设备 2020 年以来在华表现最差。苹果在中国智能手机市场的市占率由去年同期第一的位置滑落至第三位，相反，vivo 以 17.4% 的市占率排名第一；荣耀以 16.1% 的市占率排名第二；华为排名第四，份额为 15.5%。
在专家观点看来，若市场消息属实，尽管 iPhone 16 放弃了在内存上的高溢价，但究竟能挽回多少消费者仍不甚明朗，毕竟对于 iPhone 而言，迫在眉睫的问题是其在 AI 浪潮之下已经落后，即将发布的 iOS 18 或许才是苹果的关键一战。(来源：北京商报)
苹果公布最新供应链名单：新增8家中国大陆企业，剔除4家
2024 年 4 月 24 日
近期，苹果发布了 2023 会计年度供应链名单（ Apple Supplier List ）。苹果表示，供应商名单占其 2023 财年全球范围内产品材料、制造和组装直接支出的 98%，
值得注意的是，今年的名单中新增了 8 家中国大陆企业（包括宝钛股份、三安光电、博硕科技、东尼电子等），而剔除了 4 家（江苏精研科技、美盈森集团、深圳市得润电子及盈利时）；同时，新增两家中国台湾企业，剔除了 4 家。
其中，宝钛股份是中国最大的钛及钛合金生产商；三安光电则是 LED 芯片龙头；博硕科技为电子产品功能性器件的头部企业；东尼电子致力于碳化硅衬底的国产替代，都是各细分领域的领军企业。
从名单中的工厂分布来看，中国大陆工厂为 155 座，位居第一；第二位是中国台湾工厂 49 座，第三是日本 41 座；东南亚国家方面，越南 32 座，泰国和新加坡各 23 座，马来西亚 18 座，菲律宾 16 座；此外，美国和印度分别为 25 座和 13 座。
由此可见，目前苹果的供应链仍然主要位于东亚、东南亚，以及印度和美国。东亚仍然占有绝对的优势，其次是东南亚国家。
近年来，苹果的供应链迁移一直是热议话题。据悉，从中国向东南亚以及印度转移，甚至回流美国本土，是苹果供应链外迁的主要方向。目前，苹果在东南亚，尤其在越南，已经拥有了 32 座工厂，而美国为 25 座，印度为 13 座。
值得注意的是，名单显示，包括比亚迪、立讯精密、蓝思科技、领益智造等国内消费电子代工和零部件龙头企业都在已在东南亚建厂，以应对苹果供应链风向变化。
今年3月底，蒂姆·库克（ Tim Cook ）现身位于上海，为静安寺苹果专卖店揭幕。4 月中旬，他又先后到访越南、印度尼西亚及新加坡3个东南亚国家。随之而来的是，一系列投资计划和潜在意向的被曝光。
例如，库克抵达河内的同时，苹果在越南官网发表声明，宣布将增加越南供应链的投资。根据公告中提供的数据，从 2019 年开始算起，苹果公司通过供应链伙伴在越南的累计投资超过 400 万亿越南盾。（折合超过 1120 亿人民币）
近日，市场调研机构 IDC 发布了一季度全球智能手机销量预测，苹果出货量在今年第一季度出现了 9.6% 的下滑，市场份额为 17.3%，被三星超越，位居第二位。
事实上，市场普遍认为，苹果全球销量下滑的原因之一，就是源自中国市场的销量疲软。Counterpoint Research 在 3 月初发布的报告中预估，今年前六周，iPhone 在中国的销量下降了 24%。
一方面是对中国销量的担忧，另一方面是大力推动供应链向东南亚迁移。而从此次的名单来看，中国供应链并非能够被轻易取而代之，苹果供应链依旧呈现多元化和全球化的特征。而对于名单中的企业来看，仍需时刻把握苹果的战略方向和市场的脉搏，不可掉以轻心。（来源：福布斯中国）
提案
通过的提案
SE-0433 同步互斥锁 提案通过审查。该提案已在 五十一期周报 正在审查的提案模块做了详细介绍。
正在审查的提案
SE-0426 BitwiseCopyable 该提案已在 四十九期周报 正在审查的提案模块做了详细介绍。在第五十期周报被拒绝，本期重新恢复审查。
拒绝的提案
SE-0430 transferring 参数和结果值的隔离区域 提案被拒绝。该提案已在 五十期周报 正在审查的提案模块做了详细介绍。
Swift论坛
内容概括
在 Swift 中，目前成员导入可见性存在不一致性。即使只导入模块引入该模块而不导入该模块，也可以找到成员声明。这种不一致可能可以理解为一个微妙的错误而不是一个故意设计的决策。
本提案旨在修正这个错误，通过统一名称查找规则来改变行为，使得顶级声明和成员都必须直接导入模块才能被引用。这样做可以避免之前提到的令人惊讶的歧义，因为开发者对顶级声明和成员可见性的预期与现实存在冲突。
编译器会报错，因为成员引用以前可以成功解析为在传递导入模块中声明的声明，但是它还会识别你可能想要使用的声明并建议导入模块定义它的模块。IDE 也可能会提供一个修复此缺失模块导入的功能。
这种改变的行为将会破坏源代码兼容性，因为它增加了更严格的命名查找要求。有很多现有的 Swift 代码需要更新以遵守这些新规则，要么是在某些源文件中增加额外的导入语句，要么是将代码整理到不同的文件中。因此，这种改变应该是可选的，这就是为什么它应该限定在未来语言模式中的一个即将推出的特性标识之下才能被允许。
该变化不会影响 ABI 兼容性。由于编译器可以识别缺失的模块导入并指导开发者添加明确的导入来解决错误，因此采用该特性应该很容易。
开发者有选择在该文件中管理导入来解决歧义，但是在某些情况下，可能需要对代码进行重构来避免导入模块引入冲突的模块，这些情况下可能会很尴尬。因此，有一个能够明确标识扩展成员的语法将非常有用。
内容概括
加速度在 Swift比 NumPy 慢，由 Gavin Wiggins 撰写，引发了关于 Swift 的 Accelerate 框架与 Python 的 NumPy 包的性能对比的讨论。Wiggins 将 Swift/Accelerate 结果与 Python 使用 NumPy 包进行比较，并且发现 Swift 与 Python 结果相同，但是 Swift/Accelerate 代码在对 8000 x 8000 矩阵进行乘法时要比 Python/NumPy 代码慢约一秒钟。
即使排除生成随机矩阵的时间，Swift/Accelerate 代码仍然比 Python/NumPy 代码慢约一秒钟。Wiggins 感到惊讶，因为他预计 Accelerate 被优化为苹果硬件，所以他希望它比 NumPy 更好。他还建议将右矩阵预 transpose 以获得更好的缓存局部性，并且禁用 NumPy 使用多线程。
Jeff Biggus 运行了相同的基准测试，并发现 Swift 代码使用的资源比Python代码少。Steve Canon 看了一下跟踪记录并发现所有时间都花在了 Accelerate 上，所以他认为讨论并没有必要。Canon 还建议将右矩阵预 transpose 以获得更好的缓存局部性，并且使用 GPU 而不是 CPU以获得更快的速度。Canon 还建议使用 Instruments 来调试任何东西，无论是从 Xcode 还是其他程序来源的，并且使用 spindump 或者 sample 进行调试。Canon 还建议使用 AArch64 而不是 x86-64 以获得更好的性能。
内容概括
论坛社区正在考虑创建一个官方的 Swift Community Discord 服务器。该服务器将作为一个空间，用于连接 Swift 开发者，聊天，并寻求帮助彼此。
阿里阿尔萨曼，一位 Swift 开发者，首先提出了这个想法。他注意到虽然有几个非官方的 Swift Discord 服务器，但它们并不完善，与 Rust Language Community Discord 服务器相比较不如。
创建 Swift Community Discord 服务器的好处包括了与其他 Swift 开发者交流，获得社区迅速帮助，轻松进行广泛讨论和交流，以及炫耀酷炫项目。
一些社区成员担心该服务器会影响论坛的运作。有些成员喜欢在论坛上提问并搜索，而另外一些则更喜欢 Discord 或 Slack 短暂讨论。
一些成员还不知道有专门设置的 Slack 工作空间专门为 Swift 开源。然而，其他人则认为这不够，并认为专门的 Discord 服务器更方便。
总体而言，社区对这个想法持开放态度，许多人表示愿意加入 Swift Discord 服务器。然而，有些人谨慎地担心潜在的深入、思考性讨论的减少。
内容概括
“Errno.current” 讨论系统包缺乏公开接口，使得处理裸系统调用的错误变得困难。讨论建议，将 Errno.current 作为公开接口。
迈克尔・伊尔森建议，为 Errno.current 设置发布屏障以防止析构函数覆盖它。约翰斯・维斯特提到，在 Swift 中读取 errno 安全有 BUG，而特拉则建议，可以在 C 层修复此问题。
特拉提出了一种新的导入器技巧来处理特别注明的调用，约翰斯・维斯特建议，使得 errno 设置函数更易于使用从 Swift。特拉还提到，其他地方的 QUINN 曾提出了一个很好的想法值得探索。
乔·戈夫建议，ARC 仍然可能破坏 errno，特拉问，在 Objective-C 中，ARC 仍然可能破坏 errno 呢?约翰斯・维斯特建议，在 Objective-C 中，ARC 仍然可能破坏 errno，即使 ARC 启用。
特拉建议，从 Errno.current 返回一个结构体并从 Swift 调用它，但约翰斯・维斯特建议，在所有情况下都可能不起作用。乔·戈夫建议，在 Objective-C 中，ARC 仍然可能破坏 errno，即使 ARC 启用。
特拉建议，在 Objective-C 中，ARC 仍然可能破坏 errno，约翰斯・维斯特也同意这一观点。
内容概括
Swift 论坛上的讨论围绕着在 Swift 中使用互斥体和 actor 来同步并发代码之间的选择展开。 Actor，本质上是异步互斥体，利用 Swift 的任务系统来减少上下文切换的潜在优势。 建议在日常代码中使用 Actor，因为它们能够耦合状态和逻辑，提供干净的隔离域并防止许多并发错误。 然而，对于需要高性能的低级原语和数据结构，互斥体或无锁算法是首选。互斥体和参与者之间的决定取决于关键部分的长度以及逻辑和状态是否需要封装在一个地方等因素。 一般来说，除非有特殊原因，否则默认使用参与者，例如构建并发数据结构。
内容概括
Swift 论坛上的讨论探讨了函数式协议的概念及其对 Swift 发展的潜在影响。 与 Java 的函数式接口（允许 lambda 无缝集成到类型系统中）类似，社区的目标是在 Swift 中的闭包和协议之间实现类似水平的内聚力。
Java 的方法（以 Runnable 等接口为例）允许在整个 JDK 中使用 lambda 文本来代替单一方法接口。 这允许简洁且富有表现力的代码，而不需要额外的 API 来接受 lambda。
虽然 Swift 已经拥有像 ExpressibleBy…Literal 协议这样的机制，但明显缺乏与函数文字等效的协议。 尽管 Swift 现有对函数类型的支持，但讨论探讨了引入 ExpressibleByFunctionLiteral 协议以增强 API 文档和可读性的想法。
对话还涉及利用协议来解决与闭包相关的挑战的想法，例如安全捕获可变变量和减少闭包分配。 协议可以提供一种结构化的方式来确保对闭包内可变状态的独占访问，从而有可能提高性能。
此外，还探索通过将闭包转换为可复制的结构来为闭包注入值语义。 这种方法可以促进有状态和“可重新启动”操作的实现，尽管它可能需要特殊的语法来区分具有值或引用语义的闭包。
还考虑了功能协议的替代方案，包括使闭包更充分地参与泛型或将类型视为闭包。 这些方法旨在简化代码组织和文档，同时使闭包和协议更紧密地结合在一起。
总的来说，讨论反映了增强 Swift 表达能力并弥合闭包和协议之间差距的愿望。 通过探索各种概念和替代方案，社区寻求以有利于开发人员并提高语言功能的方式发展 Swift。
内容概括
作者分享了他们在 Swift 中构建命令行实用程序的经验，并强调了他们在发现文档以有效控制流程时面临的挑战。 虽然他们发现教程很有帮助，但他们很难找到有关优化可执行文件和导航非 UI 项目的 Swift 生态系统的综合资源。 他们想知道这种困难是否源于 Swift 对 UI 工作的关注或其年轻的生态系统。
受访者否认了 Swift 故意挑战学习的观点，并强调其教育资源的去中心化性质。 他们建议探索社区创建的资源，例如“服务器上的 Swift”，以获取服务器端 Swift 开发指南。 此外，像 Swiftinit 这样的工具还为流行的 Linux 软件包提供 API 文档，补充了 Apple 的 API 文档。
总的来说，讨论强调需要改进针对非 UI Swift 开发的文档和资源，旨在促进尝试命令行工具和服务器端 Swift 的开发人员的学习过程。
内容概括
Swift 论坛上的讨论围绕 SE-0433 展开，SE-0433 提议在 Swift 中引入同步互斥锁。 虽然一些参与者承认形式化通用并发模式的好处，但其他参与者根据过去使用互斥体等低级并发结构的经验表示保留。 人们的担忧包括潜在的死锁和其他并发问题，以及对 async/await 和 actor 等更高级别抽象的偏好。
参与者提出了替代解决方案，例如将类似互斥锁的功能直接合并到 Swift 的 actor 模型中，以解决重入和交错问题。 然而，人们担心引入复杂性和死锁的可能性。 一些人建议重点应该放在使安全并发构造直观且易于使用，而不是依赖手动锁管理。
一个提议的想法是增强 Swift 的编译器以自动处理同步，例如自动将突变包装在锁中。 这种方法旨在简化初学者的并发编程，同时防止常见的陷阱。 参与者强调了明确的编译器反馈对于指导开发人员进行安全并发实践的重要性。
总体而言，讨论强调了提供强大的并发工具与确保开发人员安全且易于访问之间的紧张关系，并强调了对直观且编译器支持的解决方案的需求。
推荐博文
摘要： 这篇博客介绍了 SwiftUI 中的新功能——内容边距（contentMargins）概念。文章首先解释了在 iPad 上处理大量文本时的布局问题，并指出在 SwiftUI 中无法直接使用 UIKit 中的 readableContentGuide。作者展示了如何通过增加安全区域来调整布局，但这种方法也会移动滚动条指示器，影响用户体验。最后，作者介绍了 contentMargins 视图修饰符的用法，可以将可滚动内容移动到安全区域外，同时保持滚动条在原位。这项功能填补了 SwiftUI 中安全区域管理的一项重要缺失，使得应用程序在不同屏幕尺寸下能够更加灵活和适应性强。
摘要： 这篇文章探讨了 Swift 中类型推断的重要性以及如何在编写代码时利用类型推断来简化语法。作者首先介绍了 Swift 是一种静态类型语言的特性，但又指出 Swift 支持类型推断，可以自动推断出变量、常量和属性的类型，从而使代码编写更加轻量化。
文章通过示例说明了在 Swift 中如何使用类型推断，包括变量声明、枚举、静态属性和方法等情况。此外，作者还提及了一些情况下需要手动指定类型的情况，例如处理数值类型和调用具有泛型返回类型的函数时。最后，作者总结了 Swift 的类型推断机制的计算成本以及如何在需要时手动指定类型。整体而言，本文强调了 Swift 中类型推断的重要性和灵活性，以及在代码编写过程中如何有效地利用它来提高开发效率。
摘要： 这篇 Swift 博客讨论了在 Swift 中检查集合是否为空的两种主要方法：使用 count 属性和使用专用的 isEmpty 属性。首先文章介绍了这两种方法在行为上的差异，并探讨了标准库中 isEmpty 的实现方式。作者指出，尽管对于某些具体的集合类型，如 Set，使用 count 和 isEmpty 可能会得到相同的结果，但在其他情况下，特别是对于 String 这样的集合，直接使用 count 可能会导致性能损失。最后，作者建议在判断集合是否为空时始终使用 isEmpty，因为它更易读、更直观，并且性能始终较高。
话题讨论
能不能接受五一放一天不调休？
- 能
- 不能
我建议五一放 5 天不调休，欢迎在文末留言参与讨论。
关于我们
Swift社区是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 Swift实战、SwiftUl、Swift基础为核心的技术内容，也整理收集优秀的学习资料。
特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
