Swift 周报第五十七期

最新推荐文章于 2024-08-09 17:42:40 发布

网罗开发

最新推荐文章于 2024-08-09 17:42:40 发布

阅读量811

点赞数 25

分类专栏： Swift周报文章标签： swift 开发语言 ios

本文链接：https://blog.csdn.net/qq_36478920/article/details/140408782

版权

Swift周报专栏收录该内容

32 篇文章 3 订阅

订阅专栏

在这里插入图片描述

文章目录

前言

本期是 Swift 编辑组自主整理周报的第五十七期，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。

Swift 周报在 GitHub 开源，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。

猛兽总是独行，牛羊始终结群。Swift社区，时刻不断前行，无关静谧喧闹，独行皆苦且常在，牛羊雕琢也化龙！👊👊👊

周报精选

新闻和社区：iPhone 16 或将配备可拆卸电池

提案：DebugDescription 宏提案正在审查

Swift 论坛：讨论 unless 关键字的优点

推荐博文：使用 Swift 6 语言模式构建 Swift 包

话题讨论：

了解当代年轻人的网络时代“新名词”

新闻和社区

消息称苹果又一高管跳槽汽车厂商这次是加入 Rivian

2024 年 7 月 4 日

据外媒报道，在苹果近几年跳槽的高管中，有多人是加入了汽车厂商，除了他们汽车项目团队的高管，还有工程副总裁 Mike Abbot，他在去年 4 月份加入了通用汽车，2022 年他们的全球电池开发主管 Soonho Ahn 是跳槽大众。

而从外媒最新的报道来看，苹果又有一名高管在近期跳槽到了汽车厂商。

近期跳槽汽车厂商的苹果高管，是硬件工程总监杰夫・阿尔维斯（Jeff Alves），他在 2013 年加入苹果，已工作超过 10 年。作为电池工程团队的一员，他在苹果期间参与了多个项目的工作，包括初代 Apple Watch 充电系统的开发，随后也曾参与汽车项目，他的名字也出现在了相关的苹果专利中。

在领英上，杰夫・阿尔维斯也确认了他从苹果离职的消息，也提到了他在苹果 11 年的工作经历，对苹果及在苹果的同事充满感激。

从苹果离职后，杰夫・阿尔维斯的下一站是电动汽车厂商 Rivian，他的新职位是高级电池工程总监，继续从事电池工程方面的工作。

值得注意的是，外媒在报道中提到，在加入 Rivian 之后，杰夫・阿尔维斯将同他在苹果的前同事 Jonas Reinke 和 DJ Novotney 并肩工作，他们在今年年初离开苹果，加入了 Rivian。(来源：TechWeb.com.cn)

iPhone 16或将配备可拆卸电池

2024 年 6 月 28 日

欧洲法规无疑对苹果的产品线产生了影响，它要求苹果公司在 iPhone 上采用 USB-C 接口，然后采用 RCS 接口，以便 Messages 能够更轻松地与全球 Android 用户通信。据 The Information 报道，苹果可能正在研发可拆卸的 iPhone 电池，以符合全球要求。我们可能会在今年秋季的 iPhone 16 上看到它。

去年，欧洲议会通过了一项规定，在欧盟境内销售和分销的智能手机电池必须遵守特定的设计和回收规则。对于智能手机来说，最重要的一点是可以轻松更换电池。该法律适用于不同产品类别的电池，包括电动踏板车和汽车。

到 2027 年，所有智能手机和可折叠手机都必须符合该标准，但苹果可能会更早。据参与 iPhone 制造的五位人士透露，iPhone 16 机型之一可能会推出一种新的易于更换的电池技术。

目前，iPhone 使用胶条将电池固定到位。这需要用镊子轻轻加热该区域以去除剩余的粘合剂，如果没有 Apple 为其 Genius Bars 提供的专用机器和托盘，这项工作很难完成。

为了遵守新法律，Apple 将改用“电感应粘合剂脱粘法”，即使用“小电流”取出电池的方法。自去年冬天以来，有关这种电池拆卸方法的谣言就一直流传。

据 The Information 报道，你仍然需要自己“撬开” iPhone，这仍然不是一个简单的过程，因为所有部件都是通过螺丝连接起来的。当苹果展示这项技术时，它会附带一个警告，即在自行尝试维修之前，它坚持要求你寻求专业帮助。

如果苹果遵循一系列特定标准，它就可以获得欧盟新电池法的豁免，这些标准包括充电500次后至少保留 83% 的电池容量，充电 1，000 次后至少保留 80% 的电池容量。电池容量确保设备可重复使用，而强制要求减少废弃部件，这样人们就不会在手机无法充电时直接更换手机。(来源：Hi科技前线)

苹果头显国行版开售：预约火爆但销量难评

2024 年 6 月 28 日

备受期待的苹果头显 Vision Pro 国行版于 6 月 28 日正式发售，售价 29999 元起。苹果中国官网此次专门上线了 Vision Pro 发售倒计时，以秒为单位计算，而且已经开启了 Vision Pro 预约体验。未开售前，北京地区的预约体验已经排到了 7 月 3 日。国行版 Vision Pro 势必掀起讨论热潮，但从销售上说，高昂的售价难免令消费者三思而行，另外，是否有足够匹配国行版 Vision Pro 的生态内容是市场担忧之处。

北京商报记者登录苹果官网看到，想要预约体验 Vision Pro 的消费者需要有一个苹果账号，登录后选择想去的线下门店及时间，相关事宜要通过邮件通知、确认，预约后，消费者可以享受 30 分钟的 Vision Pro Demo 体验，若用户佩戴眼镜，苹果还提醒用户携带眼镜到店，以便选择 Vision Pro 上相应的镜片。

记者查询发现，北京地区的预约体验已经排到了 7 月 3 日。记者在走访中了解到，也有“果粉”不急于前往苹果门店，因为如今在望京、大望路的商场中已有商家提供 Vision Pro 体验服务，一小时约100元。

有体验过的用户对记者谈到，Vision Pro 带来的感觉前所未有，手势识别特别精准，操作自然流畅，尤其是独特的眼球追踪功能，几乎是让用户全方位、沉浸式地使用 iPhone。不过也有用户称 Vision Pro 重量大、感觉沉，不需一小时，即便是 30 分钟的使用也让脖子有负担，而且对一些鼻梁偏窄偏矮的用户来说，Vision Pro 也不能和面部完全贴合，有点漏光，这影响了沉浸体验。

在业内观点看来，Vision Pro 登陆内地后，无疑会成为消费电子新的热点，在出货上短期内也会形成一个高峰，不过这种热情能持续多久并不好说。

产业观察家丁少将对北京商报记者谈到，从美国方面近几个月的销售状况看，仍然是想体验 Vision Pro 的居多，真正入手的有限，买家还是以科技发烧友为主，一方面是因为产品售价较高，且相较于手机使用场景有限，让消费者不得不三思而行；另一方面，在需求不确定的情况下，苹果也不会贸然大面积铺货，毕竟产品形象是其必须考虑的问题。

数据也印证了专家观点，有公开消息披露，Vision Pro 的情况不如预期乐观，苹果预计 2024 年的销售量将仅为 40—45 万台，较之前预测的 70—80 万台大幅减少。知名分析师郭明錤指出，苹果在早期就削减了 Vision Pro 生产订单，这也可以看作苹果对市场接受度的初步评估。

另外，此前海外发售 Vision Pro 的情况也可作为参考。今年 1 月 Vision Pro 开启第一波预售时，不到 5 分钟买家就挤爆了服务器，半小时内实体店直接售罄。开订 2 小时后，发货日期已经排到了 3 月甚至 4 月。

但许多国外消费者在试戴后纷纷要求退货。重点关注苹果公司消息的网站 Cult of Mac 面向读者和社交平台发布了两份民意调查，得出的结果是分别有 76% 及 45% 的受访者表示将退回 Vision Pro。不过，许多寻求退款的早期用户觉得，如果苹果公司解决了设备问题（并降低价格），他们肯定会回归 Vision Pro 的第二代产品。

另有业内观点指出，不能简单地用硬件出货的逻辑考量 Vision Pro，近年来苹果的发展策略已然改变，硬件之外，苹果生态、内容服务成为新的增长点，角色愈发重要，可以说 iPhone、iPad 等硬件都是苹果生态的“入口”，而 Vision Pro 的使命是继续为苹果生态开疆拓土。

这一点在数据上也有所反映，根据苹果最新财报显示，服务收入成了公司最大亮点，该项目利润率最高，且占总收入比重已达两成，服务业务板块在第二财季同比增长 14.2%，约 238.7 亿美元，高于市场预期的 232.8 亿美元，已连续 5 个季度创下新高。苹果服务类业务包括 Apple Music、TV+ 流媒体平台和 iCloud 订阅，主要收入来自 App 商店，与此同时，iPhone、iPad 的收入均有所下滑。

为完善内容生态，与 Vision Pro 一起推出的还有应用商店，苹果方面表示，Vision Pro 应用商店将包含超过 100 万款应用程序，其中专门为 Vision Pro 开发的应用已超 600 款，除了影音、游戏之外， Keynote、Microsoft Office、Zoom 等生产力工具也根据 Vision Pro 进行了调整。

但 Vision Pro 国行版面世后，市场则担心内容生态跟不上。丁少将认为，如今包括苹果在内的各大厂商都着眼于用户黏性，关键就是把用户纳入并固定在自己的“生态圈”中，然而第三方应用也在不停争夺用户。在北美市场，苹果可以与微软及各家流媒体合作，共享用户资源，但这种策略在中国大陆恐怕难以复制，用户习惯的不同是重要隔阂，这或许也是国行版 Vision Pro 要面临的阻力。

专家观点认为，虽然目前也有不少国内企业投身于 Vision Pro 适配内容开发，但离真正成熟的生态尚有距离，这也是 VR、XR 领域普遍的困境。

事实上，Vision Pro 所面临的技术实现与商业上的瓶颈并非孤例。根据洛图科技发布的新一期《中国消费级XR市场调研报告》，2023 年中国消费级XR市场暴跌 34%，相关设备全渠道销量为 61.3 万台。同样地，美国市场也大幅下滑，2023 年 VR、AR 硬件的市场规模下跌了 40%，仅有 6.6 亿美元。(来源：北京商报)

提案

通过的提案

SE-0432 不可复制类型的借阅和消费模式匹配 提案通过审查。该提案已在 第五十一期周报 正在审查的提案模块做了详细介绍。

SE-0434 global-actor-isolated 类型的可用性 提案通过审查。该提案已在 第五十一期周报 正在审查的提案模块做了详细介绍。

正在审查的提案

SE-0439 允许在逗号分隔的列表中使用尾随逗号 提案正在审查。

该提案旨在允许在逗号分隔的列表中使用尾随逗号，这些逗号目前仅限于数组和字典文字，只要有终止符可以实现明确的解析。在 Swift论坛章节第一小节也有详细介绍。

SE-0440 DebugDescription 宏 提案正在审查。

该提案引入了一个新的调试宏 @DebugDescription 到标准库中，该宏允许数据类型指定一个自定义摘要，由调试器呈现。此宏改善了调试体验，并简化了调试器类型摘要的维护和交付。它可以代替 CustomDebugStringConvertible 的遵从，或者在自定义用例中与之一起使用。

Swift论坛

提议SE-0439：允许在逗号分隔的列表中使用尾随逗号

内容大概

这项提案旨在允许在逗号分隔的列表中使用尾随逗号，只要有明确的终止符可以进行无歧义解析。主要动机包括:

提高开发质量:使添加、删除、重新排序或注释最后一个元素变得容易。
语言的演进:Swift 语言和编码风格的发展使得这一特性变得更加必要。

提案的主要内容:

在元组、函数参数列表、初始化器、枚举关联值、宏参数、属性、可用性说明等多种场景中允许尾随逗号。
在下标、条件语句(if/guard/while)、switch case 标签、闭包捕获列表、继承子句、泛型参数、where 子句和字符串插值中也支持尾随逗号。

详细设计:

只有在有明确终止符的情况下才支持尾随逗号。
单元素列表允许尾随逗号，但零元素列表不允许。

该提案不会影响现有有效代码的源代码兼容性，但会改变某些无效代码的解析方式。

总的来说，这项提案通过允许更灵活的语法来提高代码的可读性和可维护性。

提议集合文字

内容大概

该提案旨在将集合(Set)提升为 Swift 中的一等公民。主要观点包括:

集合类型的重要性被低估，应该得到更多关注。
开发者经常使用数组而非更适合的集合，可能是因为数组声明和使用更简单。

提案的主要内容:

集合类型语法: 使用 :[Type] 表示集合类型，例如 :[Int] 表示整数集合。
集合字面量语法: 使用 :[element1， element2， ...] 创建集合。
可选的集合操作符:
- * 表示交集
- * 或 ~ 表示成员测试
- + 表示并集
- - 表示差集

讨论要点:

对于小型数据集，数组和集合的性能差异可能不显著。
集合的使用应基于对数据结构的理解，而不是盲目选择。
简单类型(如Int、String、枚举等)更适合用作集合元素。
在并发编程中，可发送性(Sendable)是一个考虑因素，但不应成为唯一决定因素。

总的来说，这个提案旨在通过引入更简洁的语法来促进集合的使用，但也引发了关于何时使用集合以及性能考虑的讨论。

讨论unless 关键字的优点

内容大概

讨论关于引入 “unless” 关键字的讨论，作者提出重新考虑引入 “unless” 关键字的想法，作为 “if” 的补充对立词。主要观点如下:

“unless” 的可读性较好，但在 “unless…else” 结构中可能不太直观。
仅仅为了交换 if…else 块的顺序并不是一个足够有说服力的理由。
作者常常希望有一个类似 “guard” 但不要求退出的结构。
引入新关键字会增加 Swift 的复杂性，需要权衡利弊。
作为替代方案，作者建议考虑引入类似 Python 的 “not” 关键字。
总体而言，作者认为 “unless” 的好处相对较小，但仍值得讨论。

作者还提到，尽管使用 Swift 多年，有时仍会习惯性地写出 “if not …” 这样的语法，并对 Swift 不支持这种优雅的表达方式感到遗憾。

讨论为什么 Swift 采用逗号？

内容大概

我之所以问这个问题，是因为我关注目前正在审核的允许尾随逗号的提案 7。

Swift 一开始为什么要使用逗号？

如果没有逗号，解析 Swift 程序会有多难？

有逗号：

// Declare function
func foo (arg: Int， arg2: Int)

// Invoke it
foo (arg1: 2， arg2: 2)

// Tuple
var u = (1， 2， 3)

// Array
var v = [1， 2， 3]

// Declare generic functiom
func foo <U， V> (u:U， v: V) -> (U， V)

没有逗号：

// Declare function
func foo (arg: Int arg2: Int)

// Invoke it
foo (arg:1 arg: 2)

// Tuple
var u = (1 2 3)

// Array
var v = [1 2 3]

// Declare generic function
func foo <U V> (u: U v: V) -> (U V)

可以将其视为校验和和纠错码。冗余是关键。即使有效的程序可以在没有逗号的情况下被明确解析，但逗号的存在使得从部分无效的语法中推断含义变得更加容易，甚至使人类能够更快地浏览代码，这也可能导致眼睛和大脑之间的“数据丢失”，而冗余使你能够更轻松地在头脑中重建数据。

讨论如何知道值类型是否包含堆分配和引用计数

内容大概

讨论围绕着如何知道值类型是否包含堆分配和引用计数

Swift性能特征理解：

堆分配比栈分配更昂贵，并产生引用计数成本。
引用类型（如类）总是使用堆分配。
写时复制(COW)值类型（如Array）也使用堆分配。

问题：

Swift没有提供方法来知道值类型是否隐藏了私有引用类型。
难以确定大型结构体的堆分配和引用计数情况。
无法确定Foundation的结构体有多少是NS类的包装器。

建议：

Swift文档中应该提供类型的ARC成本和堆分配成本信息。
目前没有很好的方法来确定这些信息。
可以尝试查看类型是否递归包含引用计数字段。
确定类型是否进行手动堆分配的方法是阅读源代码或查找文档。

总结：了解值类型的内存分配和引用计数特征对于优化Swift代码很重要，但目前缺乏有效的工具和文档来获取这些信息。

讨论如何告诉编译器非隔离对象可以安全地传递到参与者的域中？

内容大概

问题概述：

作者遇到了一个编译器相关的问题，涉及如何在 Swift 中安全地在 actor 和非隔离对象之间传递数据。具体来说，作者想要告诉编译器，一个旧的 Objective-C 委托和一个 actor 使用相同的底层串行队列，因此在它们之间传递非隔离对象是安全的。

代码示例：

作者提供了一段伪代码，展示了 Delegate 类和 Actor 类的实现。问题出现在 Actor 类的 usesObject() 方法中，编译器报错说非可发送类型 OtherObjCObject 不能跨越 actor 边界。

当前解决方案：

作者目前的解决方法是为整个包含 OtherObjCObject 的库关闭并发检查，但这并不理想，因为该库还包含其他内容。

期望的解决方案：

作者希望能够更精确地告诉编译器，在特定情况下 OtherObjCObject 是安全可发送的。例如，能够声明 var stream: AsyncStream<OtherObjCObject & @unchecked Sendable> 将会很有帮助，但目前这种语法不起作用。

其他注释：

作者还提到，另一种有用的处理方法是将非 Sendable 对象包装在 @unchecked Sendable 结构中，但在这种情况下，由于需要在 API 调用中进行映射和过滤，这种方法需要将这些细节暴露给公共 API。

总结：

作者正在寻求一种更精确和灵活的方法来处理 Swift 并发中的隔离域和数据传递问题，特别是在处理遗留 Objective-C 代码时。

讨论为什么当保留计数非零时会调用“deinit”？

内容大概

这个讨论主要涉及 Swift 类实例在仍被多个对象保留时意外被释放的问题。主要观点如下：

预期行为：类实例只有在不再被强引用（引用计数为零）时才会被释放。
观察到的异常：即使引用计数非零，deinit 方法仍被调用。
可能原因：这似乎是编译器或库在处理 copy 和存储属性时的一个bug。
问题详情：
- 在 copy 的默认实现中，强引用的存储属性仅通过赋值复制，没有增加引用计数。
- 这可能是因为 Objective-C 运行时不理解 Swift 存储属性。
- 即使显式实现 copy 并手动赋值存储属性，仍无法增加必要的引用计数。
临时解决方案：使用 Unmanaged.passRetained(...) 强制增加引用计数。
潜在风险：如果将来编译器行为改变，这种解决方案可能导致内存泄漏。
疑问：为什么在调用 deinit 时引用计数仍为2，原因不明。

总结：这个问题揭示了 Swift 在处理存储属性和 copy 操作时的一个潜在 bug，特别是在涉及 Objective-C 运行时交互时。这个问题可能导致对象过早释放，需要开发者注意并采取适当的临时解决方案。

话题讨论

了解当代年轻人的网络时代“新名词”

你还知道有哪些？欢迎在评论区留言

关于我们

Swift社区是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 Swift实战、SwiftUl、Swift基础为核心的技术内容，也整理收集优秀的学习资料。

特别感谢 Swift社区编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区提供优质内容，为 Swift 语言的发展贡献自己的力量。

网罗开发

关注

25
点赞
踩
13

收藏

觉得还不错? 一键收藏
打赏
0
评论
Swift 周报第五十七期

本期是 Swift 编辑组自主整理周报的第五十七期，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。Swift 周报在GitHub 开源，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。猛兽总是独行，牛羊始终结群。Swift社区，时刻不断前行，无关静谧喧闹，独行皆苦且常在，牛羊雕琢也化龙！👊👊👊周报精选新闻和社区：iPhone 16 或将配备可拆卸电池宏提案正在审查Swift 论坛：讨论unless关键字的优点。
复制链接

扫一扫