自做网站好做吗,门户网站做吗,626969com域名信息查询,做网站收会员费文章目录 前言新闻和社区苹果 CEO 库克透露接班计划#xff0c;希望继任者来自公司内部消息称苹果自研 5G 调制解调器开发再“难产”#xff0c;将推迟到 2026 年 提案正在审查的提案 Swift论坛推荐博文话题讨论关于我们 前言
本期是 Swift 编辑组整理周报的第四十二期… 文章目录 前言新闻和社区苹果 CEO 库克透露接班计划希望继任者来自公司内部消息称苹果自研 5G 调制解调器开发再“难产”将推迟到 2026 年 提案正在审查的提案 Swift论坛推荐博文话题讨论关于我们 前言
本期是 Swift 编辑组整理周报的第四十二期每个模块已初步成型。各位读者如果有好的提议欢迎在文末留言。
Swift 周报在 GitHub 开源欢迎提交 issue投稿或推荐内容。目前计划每两周周一发布欢迎志同道合的朋友一起加入周报整理。
最热烈的火焰封锁在最沉默的火山深处。最朴实纯真的智慧就浅藏在Swift社区里 周报精选 新闻和社区苹果 CEO 库克透露接班计划希望继任者来自公司内部 提案Typed throws 提案正在审查 Swift 论坛讨论 MainActor 上的上下文切换和线程数 推荐博文SwiftUI 中的作用域动画 话题讨论 那个活在记忆中的帅气少年已慢慢变成了大叔模样。岁月无情呀那么各位程序猿和攻城狮们你们心中最担心的容貌变化是哪一个呢 上期话题结果 这个结果反映了员工在工作和生活平衡方面的个体差异。一些人更注重通勤时间的利用效率而另一些人则更注重在自己的房子中获得更大的舒适感和生活空间。这对公司提供灵活的工作安排和住房福利可能有一定的启示。
新闻和社区
苹果 CEO 库克透露接班计划希望继任者来自公司内部
11 月 21 日消息63 岁的苹果公司首席执行官蒂姆库克近日透露苹果已经为他的继任者做好了 非常详细 的接班计划但他也表示他目前还没有离开苹果的打算。 在 BBC Sounds 播客《Dua Lipa: At Your Service》的一次 45 分钟的采访中库克向歌手 Dua Lipa 坦承他不知道自己还会在苹果待多久。 我爱这里 他说回顾了自己在苹果的 25 年 我无法想象没有苹果的生活所以我还会在这里一段时间。 但是当被问及苹果是否有任何 CEO 接班计划时库克称 我们是一家相信制定接班计划的公司所以我们有非常详细的接班计划。因为总会发生一些不可预测的事情。我明天可能会走错路边希望不会发生这种事我祈祷不会。
Dua Lipa 问道 你能说出谁是接班人吗 库克回答称 我不能说但我想说的是我的工作是找到几个有能力接班的人我真的希望下一任首席执行官是来自苹果内部的人。所以这是我的角色让董事会有几个人可以选择。
在这次采访中库克讲述了自己作为苹果 CEO 的一天分享了他在阿拉巴马州一个蓝领家庭长大的经历以及最终成为苹果 CEO。(文章来源IT 之家)
消息称苹果自研 5G 调制解调器开发再“难产”将推迟到 2026 年
IT之家 11 月 17 日消息彭博社的马克・古尔曼Mark Gurman发布最新一期 Power On 时事通讯表示苹果的自研 5G 调制解调器计划遇到麻烦。
IT之家注苹果公司于 2019 年收购了英特尔大部分智能手机业务并开始认真开发自己的调制解调器硬件但开发过程并不顺利。 苹果公司原本计划 2024 年推出自研 5G 调制解调器芯片并率先装备在 iPhone SE 机型上但随后有消息称延后到 2025 年。
古尔曼在最新时事通讯中表示苹果计划再次延后推出自研 5G 调制解调器芯片时间目前已经推迟到 2025 年年底或者 2026 年年初。
古尔曼在文章中透露苹果的自研 5G 调制解调器芯片目前还处于早期阶段可能落后竞争对手“数年”时间。
消息称苹果目前自研的 5G 调制解调器芯片并不支持 mmWave 技术目前主要存在 2 个难题第一是英特尔遗留代码需要苹果重写而添加新功能可能会中断现有功能第二是开发芯片过程中要小心绕过不侵犯高通的专利。
一位苹果员工表示“我们接手了英特尔的一个失败项目我们盲目自信地认为可以成功”。据说苹果的硬件技术部门在众多项目中“捉襟见肘”各项资源没有向其倾斜导致难以解决错误。
提案
正在审查的提案
SE-0413 Typed throws 提案正在审查。
Swift 的错误处理模型允许标记为 throws 的函数和闭包指示它们可以通过引发错误来退出。错误值本身始终被类型擦除为 any Error。这种方法鼓励以通用方式处理错误并且对于大多数代码来说仍然是一个很好的默认选项。然而有一些情况下类型擦除是不幸的因为它不允许在可能且有必要处理所有错误的狭窄位置进行更精确的错误类型化或者在类型擦除的成本很高的情况下。
该提案引入了指定函数和闭包只能引发特定具体类型错误的能力。
Swift论坛
提议多语句 if/switch/do 表达式
内容概括
该提案基于 SE-0380引入了“then”关键字来处理 if 或 switch 表达式中的多个语句从而促进更清晰的语法并提高可读性。 “then”关键字允许这些表达式每个分支有多个语句从而简化了以前需要立即执行闭包或显式键入的场景。 此外它还引入了“do”表达式使代码结构更加清晰并处理 API 需要价值创建和后续突变的情况。
该提案概述了详细设计引入“then”作为上下文关键字指定其在 if、switch 和 do 表达式中的用法。 它强调了解析歧义和可能的替代方案探索诸如在 Swift 中使用最后一个表达式或受 Rust 启发的分号终止等变体同时讨论它们对代码可读性和语言设计的影响。
总体而言该提案旨在增强 Swift 的表达能力而不影响 ABI 稳定性并邀请讨论引入的“then”关键字的替代方案和潜在的解析复杂性。
介绍
该提案引入了 then 关键字用于确定单个分支中包含多个语句的 if 或 switch 表达式的值。 它还介绍了 do 表达式。
动机
SE-0380 引入了使用 if 和 switch 语句作为表达式的功能。 正如该提案所述这可以大大改进语法例如在初始化变量时
let width switch scalar.value {case 0..0x80: 1case 0x80..0x0800: 2case 0x0800..0x1_0000: 3default: 4
}否则需要诸如立即执行闭包或显式类型确定初始化之类的技术。 然而该提案将让 switch 分支包含多个语句的能力作为未来的方向
let width switch scalar.value {case 0..0x80: 1case 0x80..0x0800: 2case 0x0800..0x1_0000: 3default: log(this is unexpected, investigate this)4 // error: Non-expression branch of switch expression may only end with a throw
}当需要这样的分支时当前用户必须退回到旧技术。 该提案引入了一个新的上下文关键字它允许 switch 保留为表达式
let width switch scalar.value {case 0..0x80: 1case 0x80..0x0800: 2case 0x0800..0x1_0000: 3default: log(this is unexpected, investigate this)then 4
}then 可以类似地用于允许 if 表达式中的多语句分支。 该关键字的引入还使得独立的 do 表达式更加可行。 它们有两个用例
要从 do/catch 块的成功路径和失败路径生成值
let foo: String do {try bar()
} catch {Error \(error)
}当使用单个表达式无法轻松完成变量初始化时能够初始化变量
let icon: IconImage do {let image NSImage(systemSymbolName: something, accessibilityDescription: nil)!let preferredColor NSColor(named: AccentColor)!then IconImage(image, isSymbol: true, isBackgroundSupressed: true, preferredColor: preferredColor.cgColor)
}虽然上面的内容可以组成一个表达式但声明单独的变量然后使用它们会更清晰。
在其他情况下这是无法完成的因为 API 的结构要求您首先创建一个值然后更改其中的一部分
let motionManager: CMMotionManager {let manager CMMotionManager()manager.deviceMotionUpdateInterval 0.05return manager
}()这种立即执行的闭包模式在 Swift 代码中很常见。 以至于在某些情况下用户认为即使是单个表达式也必须包含在闭包中。 do 表达式将提供更清晰的习惯用法来对这些进行分组。
讨论借用和输入输出模式匹配的设计问题
内容概括
讨论围绕着通过启用借用和输入输出模式匹配来增强 Swift 的模式匹配、允许在不复制或消耗值的情况下进行值匹配以及在模式匹配期间启用枚举的就地突变来增强 Swift 的模式匹配。 主要设计问题包括
新的绑定模式引入“借用 x”和“inout x”分别作为借用和变异模式绑定的语法。 这些将允许借用或改变部分匹配值而不消耗它。模式的所有权行为分析 Swift 中的各种模式类型以了解其所有权含义。 诸如绑定、通配符、元组、枚举、可选展开、布尔值、动态转换和表达式模式之类的模式将根据其所有权行为进行评估。确定模式匹配所有权探索确定模式匹配的所有权行为的方法。 聚合模式元组和枚举遵循其组件之间最严格的所有权行为借用、变异或消费。确定开关的效果讨论如何通过句法标记或从应用模式推断所有权来确定开关对其主题的总体效果。 有人建议使用“”标记来改变模式匹配。条件中的所有权控制考虑“if let”和“if case”构造中借用和 inout 模式绑定的含义。 这些新的绑定形式可用于可选展开并且其行为类似于根据其所有权要求切换主题。
总体而言我们的目标是在 Swift 中引入更细致的模式匹配允许在不消耗值的情况下进行借用和变异并探索这些增强功能在各种语言结构如 switch 语句和条件中的含义。
讨论如何依赖 SwiftPM 作为一个库
问题
理论上SPM 是一个普通的 swift 包您可以将其使用工具链附带的 SPM构建为普通的 swift 包。但 swift-package-manager 存储库没有最新的 semver 标签它使用“工具链”标记方案swift-5.9.1-RELEASE。 如何依赖 SPM 作为library
回答
截至目前libSwiftPM 尚未维护可以遵循语义版本控制的稳定 API。 您使用自己的 libSwiftPM 构建的软件包将从当前的 Swift 安装中提取 PackageDescription 模块这可能与您使用的 libSwiftPM 版本不兼容。 这种不兼容性将表现为用于传递包清单和插件信息的不同序列化格式本身是私有 API这将导致模糊且难以诊断的错误。
作为以前维护过基于 libSwiftPM 构建的 CLI 工具现在维护 SwiftPM 本身的人我建议不要将其添加为依赖项。 它不适合在一起版本化并随 Swift 工具链分发的工具集之外使用。
如果您需要一个可以在包上操作的 CLI 界面请改用 SwiftPM 命令插件它们确实提供了稳定的 API。
讨论MainActor 上的上下文切换和线程数
提问
我正在观看 Swift 并发幕后我了解到作为使用 Swift 并发的开发人员我们不应该违反不阻塞线程的运行时契约。 看来 Swift 的目标是运行与设备中 CPU 核心数量一样多的线程。 然而会议结束时提出的一个观点引起了一些混乱。 演讲者提到当我们调用 MainActor 的方法时会发生上下文切换因为主线程与协作池中的线程是分开的。 这引发了几个问题
1、协作池中有多少个线程
2、如果不包括主线程这是否意味着实际的协作线程数是 numberOfCoresInDevice - 1
3、为什么主线程不是协作池的一部分
我的假设是这可能是出于优化目的允许主线程专注于 UI 任务 否则任何线程的任何继续都可以在挂起后在主线程上恢复。
4、这里是否违反了运行时契约当我们将上下文切换到主线程时我们当前的线程应该被阻塞
5、或者这个合约只针对我们开发者系统可以随意违反吗
无论如何看起来在这种情况下我们有一个线程被阻塞。
也许这个问题将作为前三个问题的答案得到回答但无论如何为什么主线程不能像协作池中的线程一样工作 只是接收必须在主线程上执行的延续 这将解决上下文切换问题。
回答
主线程主要通过 NSRunLoop 进行管理因为它的存在时间比 Swift 存在的时间要长得多更不用说 Swift 并发了。 当在默认模式下不可重入运行时主调度队列由主运行循环提供服务。 在 Swift Concurrency 中主要参与者的执行者负责将工作分派到该队列上就像常规参与者的执行者默认执行者将工作分派到协作队列上一样如您链接的文章中所述
但并非所有进程都有主线程 它主要是一个与 UI 相关的概念像守护进程这样的非 UI 进程不需要它。
讨论枚举案例关键路径更新
内容概述
讨论围绕使用 Swift 宏增强对枚举的关键路径支持特别是引入“案例关键路径”以更好地处理枚举案例。
CasePathable 宏该宏为枚举案例生成实际的关键路径称为“案例关键路径”。 这些关键路径提供动态案例查找功能并且可以与常规关键路径类似地使用。使用示例CasePathable 宏允许实现各种功能
通过下标访问枚举案例。使用 callAsFunction 嵌入新的有效负载。简化枚举案例检查和有效负载提取。利用 SwiftUI 绑定的大小写键路径启用基于枚举大小写的导航和表单控件使用。使用大小写键路径组合应用程序功能在构建和组合不同的应用程序功能时特别有用。
对库的影响SwiftUINavigation 和 Composable Architecture 等库已更新以合并案例键路径使用 Swift 键路径语法增强其功能、结构和可组合性。
提供的示例和案例研究旨在展示案例关键路径的多功能性和实用性强调它们在简化代码、增强 SwiftUI 绑定、组合应用程序功能等方面的潜力。 希望展示这些用例将鼓励将案例关键路径纳入语言中并激发进一步的创新应用程序。
案例研究SwiftUI Bindings
大小写键路径使从枚举而不是一堆独立选项驱动 SwiftUI 导航成为可能。 例如如果一个视图可以导航到两个不同的、互斥的功能那么最好像这样建模
struct FeatureView: View {State var destination: Destination?enum Destination {case activity(ActivityModel)case settings(SettingsModel)}…
}但构建对 Destination 枚举的每种情况的绑定可能很困难以便您可以使用 sheet(item:)、popover(item:)以及更多视图修饰符。 但是如果你的枚举用 CasePathable 注释
CasePathable
enum Destination {// ...
}然后我们可以利用绑定上的“动态大小写查找”允许它们通过点链语法转换为 SwiftUI 现有视图修饰符所期望的形状
.sheet(item: self.$destination.activity) { model in ActivityView(model: model)
}
.popover(item: self.$destination.settings) { model in SettingsView(model: model)
}还可以使用 String 或 Bool 来驱动表单控件例如 TextFields 和 Toggles否则这些控件将被困在枚举案例中
CasePathable
enum Status {case inStock(quantity: Int)case outOfStock(isOnBackOrder: Bool)
}Binding var status: Statusswitch self.item.status {
case .inStock:$status.inStock.map { $quantity inSection {Stepper(Quantity: \(quantity), value: $quantity)Button(Mark as sold out) {status .outOfStock(isOnBackOrder: false)}} header: { Text(In stock) }}
case .outOfStock:$status.outOfStock.map { $isOnBackOrder inSection {Toggle(Is on back order?, isOn: $isOnBackOrder)Button(Is back in stock!) {status .inStock(quantity: 1)}} header: { Text(Out of stock) }}
}如果您想尝试其中任何一个我们的 SwiftUINavigation 库已更新可以在使用 CaseKeyPath 进行绑定时定义动态成员查找。
案例研究Composing App Features
近 4 年前我们开发案例路径的主要推动力是我们的可组合架构库它提供了一种定义功能并将它们组合在一起的结构化方法。 功能使用枚举来枚举应用程序中所有可能的用户操作并且这些枚举嵌套在父/子域层中并且需要案例路径来编写可以将这些功能抽象地粘合在一起的代码。
我们还更新了该库以使用案例键路径这允许人们通过使用简单且熟悉的键路径语法隔离子状态和操作来将功能组合在一起
Reduce { state, action in // ...}
-.ifLet(\.child, action: /Action.child) {
.ifLet(\.child, action: \.child) {ChildFeature()}这使我们能够利用本机键路径给我们带来的所有好处例如 Xcode 自动完成和类型推断。
推荐博文
基于 UI 交互意图理解的异常检测方法
摘要 本文介绍了利用页面多模态信息在UI测试领域的探索与实践经验。针对意图信息识别问题我们利用图像文本渲染布局属性信息探索出了一种交互意图簇识别模型验证了基于自注意力的多模态方向可行性。
此模型可以识别出渲染树元素多维度的意图属性信息同时利用聚类算法将节点聚成交互意图簇可以为后续的任务提供结构化决策信息。在标注数据较少的情况下仍体现了较好的准确率以及泛化能力。后续计划通过扩大数据集、加强预训练等方式继续提升模型识别的精度。
SwiftUI 中的作用域动画
摘要 文章介绍了在 SwiftUI 中使用作用域动画的新方法。首先我们回顾了以前在 SwiftUI 中处理动画的方式并指出了其中的一些缺点。随后我们展示了如何使用带有 value 参数的 animation 视图修饰符来限定动画范围以及如何处理多个可动画属性的情况。
接着我们介绍了 SwiftUI 中引入的 animation 视图修饰符的新变体允许我们使用 ViewBuilder 闭包来限定动画范围。最后我们还提到了在视图层次结构中维护作用域事务的方法。这些新方法为我们在 SwiftUI 中创建精确且有限范围的动画提供了更灵活的选择。
线程调度和 Actors 的执行方式
摘要 本文讨论了在 Swift 中使用线程调度和 Actors 时的执行机制。Actors 可以确保代码在特定线程上执行如主线程或后台线程并帮助同步访问可变状态以防止数据竞争。
然而开发人员常常误解 Actors 在非异步上下文中的线程调度这是为了避免意外崩溃而至关重要的。作者建议在深入研究调度的具体细节之前先阅读他的两篇文章《Actors in Swift: how to use and prevent data races》和《MainActor usage in Swift explained to dispatch to the main thread》因为它们会向您介绍 Actors 的概念。在本文中探讨了调用带有任何 actor 属性标记的方法的影响。
在异步上下文中文章讨论了使用 Actors 时的线程调度。通常情况下您可能会在异步环境中使用 Actors 。如果您的调用代码访问带有 actor 属性的方法您必须使用任务task或采用相同的全局 actor 。文章提供了相关的示例代码并说明了编译器如何防止在非异步上下文中调度到 actor 线程。
话题讨论
那个活在记忆中的帅气少年已慢慢变成了大叔模样。岁月无情呀那么各位程序猿和攻城狮们你们心中最担心的容貌变化是哪一个呢
最担心越吃越肥胖横向发展。最担心逐渐变厚的高度镜片。最担心青丝若雪白发横生。最担心秀发稀疏日渐秃然。
欢迎在文末留言参与讨论。
关于我们
Swift社区是由 Swift 爱好者共同维护的公益组织我们在国内以微信公众号的运营为主我们会分享以 Swift实战、SwiftUl、Swift基础为核心的技术内容也整理收集优秀的学习资料。
特别感谢 Swift社区 编辑部的每一位编辑感谢大家的辛苦付出为 Swift社区 提供优质内容为 Swift 语言的发展贡献自己的力量。
