位置：首页-资讯-后端开发

Swift 周报第三十期

2023-08-17 10:48

短信预约 -IT技能 免费直播动态提醒

文章目录

前言

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

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

求人不如求己，你多一样本领，就少一点啊乞求；Swift社区让你多一样技能，少一些嘲讽！

周报精选

新闻和社区：码出新宇宙，WWDC23 就在眼前

提案：有 4 个提案通过，本期没有产生新的提案

Swift 论坛：PermutableCollection 协议

推荐博文：SwiftUI 中 LinearGradient的用法

话题讨论：

有博主在视频社交平台说，2023年已然迎来了经济危机，只是有些人不愿意相信而已，那么你认为国内2023年是否真的进入了经济危机？

上期话题结果

上期话题讨论结果表明，社交隔阂和个人选择标准的提高是导致男女群体互不干涉的主要原因，而社会观念的变化也起到了一定的影响。这些因素共同作用导致了男群体和女群体相互独立地寻找伴侣的现象。

新闻和社区

App、App 内购买项目和订阅即将实行税率调整

App Store 的交易和支付机制旨在帮助你在覆盖全球的 175 个国家和地区的商店中，以 44 种货币为你的产品和服务便捷地进行定价与销售。Apple 会为开发者管理其中 70 多个国家和地区的税收，而且你还能够为 App 和 App 内购买项目分配税务类别。我们会根据税务法规的变化，定期更新你在某些地区的收益。

从 5 月 31 日起，你从 App 和 App 内购买项目 (包括自动续期订阅) 销售中获得的收益将进行调整，以反映以下税率调整。请注意，相关内容的价格将保持不变。

加纳：增值税率从 12.5% 上调至 15%。
立陶宛：对于符合条件的电子书和有声书，增值税率从 21% 下调至 9%。
摩尔多瓦：对于符合条件的电子书和期刊，增值税率从 20% 下调至 0%。
西班牙：收取 3% 的数字服务税。
由于巴西税务法规的变化，在巴西开展的所有 App Store 销售现由 Apple 代扣税款。我们会按月代扣代缴应向相应税务机关缴纳的税款。自 2023 年 6 月开始，你可以在 5 月份的收入中查看从你的收益中扣除的税款金额。巴西境内的开发者不会受到这一变化的影响。

以上调整生效后，App Store Connect 中“我的 App”的“价格与销售范围”部分会随即更新。一如既往，你可以随时更改你的 App 和 App 内购买项目的价格 (包括自动续期订阅)。现在，你可以从 900 个价格点中选择，为任何店面更改定价。

码出新宇宙

WWDC23 就在眼前。太平洋夏令时间 6 月 5 日上午 10 点，Apple 主题演讲将在 apple.com 和 Apple Developer App 线上提供，为本次大会拉开序幕。你还可以通过同播共享，邀请朋友一起观看。

现在，符合条件的开发者可以开始报名参加活动了。相关活动包括 Q&A、“会见演讲者”以及社区暖场活动等线上聊天室活动，旨在促进你与开发者社区和 Apple 专家的沟通和交流。

Apple 公证服务更新

正如去年在 WWDC (简体中文字幕) 上宣布的那样，如果你目前使用 altool 命令行工具或者 Xcode 13 或更早版本通过 Apple 公证服务对 Mac 软件进行公证，则需要改为使用 notarytool 命令行工具，或者升级到 Xcode 14 或更高版本。自 2023 年 11 月 1 日起，Apple 公证服务将不再接受从 altool 或者 Xcode 13 或更早版本上传的内容。已经过公证的现有软件可以继续正常工作。

Apple 公证服务是一个自动化系统，它会扫描 Mac 软件中有没有恶意内容，检查有没有代码签名问题，并快速返回结果。对软件进行公证可向用户保证，Apple 已检查且未发现软件中包含恶意软件。

为改进 Apple 平台的安全性和隐私保护，用于验证 App 和关联 App 内购买项目销售的 App Store 收据签名媒介证书将更新为使用 SHA-256 加密算法。此更新将分多个阶段完成，新的 App 和 App 更新可能会受影响，具体取决于它们验证收据的方式。

Apple 设计大奖入围名单公布

Apple 设计大奖旨在表彰在多元包容、乐趣横生、出色互动、社会影响、视觉图像，以及创新思维等类别中表现出色的 App 和游戏。马上一睹今年的入围作品，我们将在太平洋夏令时间 6 月 5 日下午 6:30 揭晓获奖者，敬请关注。

提案

通过的提案

SE-0399 value 包展开的元组 提案通过审查。该提案已在 二十九期周报 正在审查的提案模块做了详细介绍。

SE-0397 独立声明 Macros 提案通过审查。该提案已在 二十八期周报 正在审查的提案模块做了详细介绍。

SE-0392 自定义 Actor 执行器 提案通过审查。该提案已在 二十五期周报 正在审查的提案模块做了详细介绍。

SE-0390 **引入 @noncopyable ** 提案通过审查。该提案已在 二十四期周报 正在审查的提案模块做了详细介绍。

Swift论坛

讨论从 Realm 数据库迁移提示？

提问

目前正在寻求迁移到更轻量级的解决方案（realm 目前对我的用例来说太过分了）并且想迁移到 grdb，但不必将 realm 作为依赖项持续一年或更长时间…

回答

在没有 Realm 库的情况下，您是否能够读取 Realm 数据库文件的内容？否则，您必须将 Realm 作为依赖项保留，直到您的用户迁移完毕。

您可以通过发布能够要求用户升级的应用程序版本来缩短时间跨度。这将允许您使用 “Realm-only”、“Realm-to-GRDB” 和最终的 “GRDB-only” 版本进行过渡。

提议允许 protocol 嵌套在非通用上下文中

介绍

允许协议嵌套在非通用 struct/class/enum/actors 和函数中。

动机

将标称类型嵌套在其他标称类型中允许开发人员表达内部类型的自然范围——例如，String.UTF8View 是嵌套在 struct String 中的 struct UTF8View，它的名称清楚地传达了它作为 UTF-8 代码接口的用途 - 字符串值的单位。

但是，嵌套目前仅限于在其他 struct/class/enum/actors 中的 struct/class/enum/actors；协议根本不能嵌套，因此必须始终是模块中的顶级类型。这很不幸，我们应该放宽此限制，以便开发人员可以表达自然作用于某些外部类型的协议。

建议的解决方案

我们将允许在非泛型 struct/class/enum/actors 中以及在不属于泛型上下文的函数中嵌套协议。

例如，TableView.Delegate 自然是与表视图相关的委托协议。开发人员应该这样声明它——嵌套在他们的 TableView 类中：

class TableView {  protocol Delegate: AnyObject {    func tableView(_: TableView, didSelectRowAtIndex: Int)  }}class DelegateConformer: TableView.Delegate {  func tableView(_: TableView, didSelectRowAtIndex: Int) {    // ...  }}

目前，开发人员采用复合名称（例如 TableViewDelegate）来表达可以通过嵌套表达的相同自然范围。

作为一个额外的好处，在 TableView 的上下文中，可以使用更短的名称来引用嵌套协议委托（与所有其他嵌套类型一样）：

class TableView {  weak var delegate: Delegate?    protocol Delegate {  }}

协议也可以嵌套在非泛型函数和闭包中。不可否认，这在某种程度上是有限的实用性，因为对此类协议的所有一致性也必须在同一功能内。但是，也没有理由人为地限制开发人员在函数中创建的模型的复杂性。一些代码库（值得注意的是，Swift 编译器本身）使用带有嵌套类型的大型闭包，并且它们受益于使用协议的抽象。

func doSomething() {   protocol Abstraction {     associatedtype ResultType     func requirement() -> ResultType   }   struct SomeConformance: Abstraction {     func requirement() -> Int { ... }   }   struct AnotherConformance: Abstraction {     func requirement() -> String { ... }   }      func impl(_ input: T) -> T.ResultType {     // ...   }      let _: Int = impl(SomeConformance())   let _: String = impl(AnotherConformance())}

提议PermutableCollection 协议

简介

该提案旨在添加一个 PermutableCollection 协议，该协议将位于集合协议层次结构中的 Collection 和 MutableCollection 之间。

动机

在某些情况下，人们希望能够移动和排序元素，同时不允许（或限制）元素的突变。鉴于大量不太重要的收集协议，这是一个值得注意的遗漏。创建自定义集合类型时，PermutableCollection 协议在任何强制元素唯一性和/或身份的有序集合中都是首选。用例将包括即将推出的 OrderedDictionary 和 OrderedSet。对于不可变和可变集合，它还可以提供对 Swift 使用的底层（并且可能是高度优化的）排序算法的统一访问。

设计

协议设计简单，只需一个 swapAt 要求

/// A collection that supports sorting.protocol PermutableCollection : Collection where Self.SubSequence : PermutableCollection {  mutable func swapAt(_ i: Index, _ j: Index)  }

通过 swapAt 函数，通过扩展添加额外的排序函数实现。

extension PermutableCollection {  mutating func move(fromOffsets source: IndexSet, toOffset destination: Int) {    // move algorithm enacts changes via swapAt()  }      mutating func partition(by belongsInSecondPartition: (Element) throws -> Bool) rethrows -> Index {    // partition algorithm enacts changes via swapAt()  }    mutating func sort() where Self: RandomAccessCollection, Self.Element: Comparable {    // partition algorithm enacts changes via swapAt()  }    // ... more permutation operations that mimic those available for MutableCollection  }

提问

我有一个文件的 FileDescriptor：

let fd = try FileDescriptor.open(<#filepath#>, .readOnly) 我可以使用 fd.read(into:) 将文件内容加载到 UnsafeMutableRawBufferPointer，但这是将文件内容加载到字符串中的正确第一步吗？如果是这样，

在将它传递给 fd.read(into:) 之前，

我需要使用 .allocate(byteCount:alignment:) 分配 UnsafeMutableRawBufferPointer。正确的 byteCount 取决于文件的大小。那么如何使用 Swift System 获取文件的大小呢？
如何从 UnsafeMutableRawBufferPointer 获取字符串？

回答

可以参考这个Git库：https://github.com/tayloraswift/swift-unidoc/blob/master/Sources/System/FileDescriptor.swift

提问

我想对比一下swift-foundation 和 Xcode 自带的 JSONDecoder 解码的速度。

我在一个新项目中使用单元测试和 measureBlock 以及在 swift-foundation 中使用 JSONEncoderTests 对其进行了测试。

swift-foundation 中的 JSONDecoder 看起来太慢了，我认为这是因为 swift-foundation 还没有作为一个库被引入。