苹果希望在中国推出 AI 功能 | ｜ Swift 周报 issue 68-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_36478920/article/details/146778462

在这里插入图片描述

文章目录

前言

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

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

间歇性的努力和蒙混过日子，都是对之前努力的清零。时间永不停歇，社会时刻发展，Swift社区也在华丽蜕变！👊👊👊

周报精选

新闻和社区：消息称苹果与腾讯、字节跳动谈判，希望在中国推出 AI 功能

提案：Package 特征提案通过审查

Swift 论坛：讨论 LSP 与 CMake 和 nightly 工具链集成

推荐博文：SwiftUI 中 UIGestureRecognizerRepresentable 协议使用

话题讨论：

冬天你多久洗一次澡？

上期话题结果

超越一定程度之后，停止或者慢速发展是不是依旧是超越态势？

新闻和社区

消息称苹果已成全球VR/MR头显市场第三大玩家但Vision Pro销量不及预期

2024 年 12 月 20 日

据外媒报道，苹果公司在去年 6 月 5 日的全球开发者大会上推出的头显产品 Vision Pro，已在太平洋时间今年 1 月 19 日凌晨 5 点，开始在美国市场接受预订，并在 2 月 2 日正式上市，苹果也就此正式切入了 VR/MR 头显市场，在 6 月份开始推向国际市场，开始在更多国家销售。

不过，对于苹果寄予厚望的 Vision Pro，本月早些时候有报道称销量并不乐观，自 2 月份开始上市以来还不到 50 万台，也有外媒提到在前三季度销售了约 37 万台，预计在四季度将再销售 5 万台，全年的销量距 50 万台也会有差距。

虽然苹果 Vision Pro 今年的销量看起来并不乐观，但从市场研究机构最新发布的报告来看，苹果还是凭借这一款全新的产品，成为了全球 VR/MR 头显市场第三大玩家。

市场研究机构在报告中表示，今年全球 VR/MR 头显的出货量预计将接近 960 万台，同比增长 8.8%。

具体到厂商，市场研究机构的报告是显示 Meta 将是销量最高的厂商，在出货量中所占的比例将达到 73%，远高于其他厂商；索尼则是出货量第 2 高的厂商，所占的份额为 9%；苹果 Vision Pro 以 5% 的份额排在第 3。

市场研究机构在报告中也提到，Vision Pro 销量要低于苹果的预期，这主要是因为高昂的售价和目前有限的应用资源。（来源：TechWeb）

iPhone 16印尼销售禁令有望解除消息称印尼高层已认可苹果投资承诺

2024 年 12 月 20 日

据外媒报道，在苹果公司两度提高投资承诺，由最初的 1000 万美元增至 10 亿美元后，iPhone 16 系列在印尼的销售禁令，终于迎来了将解除的曙光，有消息称他们的投资承诺已经得到了印尼方面的认可。

外媒援引知情人士的透露报道称，印尼高层在周末已经得到了相关的简报，支持批准苹果的提议，不过目前还不清楚印尼方面会在何时解除 iPhone 16 的销售禁令。

此外，外媒在报道中还提到，虽然印尼高层已经认可了苹果 10 亿美元的投资承诺，但他们也在寻求苹果公司未来更多的投资。

就外媒的报道来看，苹果方面承诺的 10 亿美元投资，主要用在三个方面，其一是在巴淡岛建设一座 AirTag 工厂，其二是在万隆建设一座为其他产品生产零部件的工厂，第三是开发者学院。

由于苹果目前的硬件产品，无论是关键零部件还是最终的成品组装，都是外包代工商，因而他们计划在印尼建设的两座工厂，是由供应商建设。

对于计划建设的 AirTag 工厂，外媒在报道中提到初期就将有约 1000 名员工，最终的产量，将占到 AirTag 全球产量的 20%。

苹果 iPhone 16 在印尼被禁售，与零部件 40% 的本土化率及投资承诺未实现有关，苹果此前承诺投资 1.096 亿美元，只完成了 9453 万美元，印尼方面在 10 月 11 日就向苹果发出了警告，在 10 月 28 日发出了针对 iPhone 16 的销售禁令，禁止在当地销售。

但由于印尼是全球重要的智能手机市场之一，有报道称人口 2.8 亿的印尼，目前在使用的智能手机约有 3.54 亿部，有可观的用户群体，对苹果来说也是重要的市场，秋季新推出的 iPhone 16 不能销售，势必就会影响到整体的销量，并影响他们的业绩，因而苹果也在尝试通过投资承诺，来解除 iPhone 16 在印尼的销售禁令。

就外媒此前的报道来看，在印尼发出销售禁令之后不久，苹果就在尝试通过投资解除销售禁令，在 11 月初承诺投资 1000 万美元，11 月下旬提升至 1 亿美元，但仍未得到认可，印尼方面希望更大的投资，随后就出现了苹果承诺投资 10 亿美元的消息。（来源：TechWeb）

消息称苹果与腾讯、字节跳动谈判，希望在中国推出 AI 功能

2024 年 12 月 19 日

据路透社报道，三位知情人士称，苹果公司正在与腾讯、字节跳动谈判，希望将这两家公司的人工智能 (AI) 模型整合到在中国市场销售的 iPhone 中。

作为 AI 系统 Apple Intelligence 的一部分，苹果从本月开始在其 iPhone 中整合 ChatGPT 聊天机器人。但是在中国市场，苹果的 AI 功能需要与本土公司合作。

知情人士称，苹果与腾讯、字节跳动的谈判涉及使用后两家公司的 AI 模型，这一讨论尚处于非常早期的阶段。科技网站 The Information 在本月报道称，苹果也曾与百度进行谈判，希望在 iPhone 中整合百度的 AI 模型，但是谈判遇到了挫折，原因是技术问题，其中包括双方在使用 iPhone 用户数据训练 AI 模型方面的争执。

截至发稿，字节跳动不予置评。苹果和腾讯尚未回复置评请求。（来源：IT之家）

提案

通过的提案

SE-0450 Package 特征 提案通过审查。该提案已在 第六十四期周报 正在审查的提案模块做了详细介绍。

Swift论坛

讨论建议：解决边界安全问题

在 Swift 论坛中关于界限安全的讨论中，作者强调界限安全问题的解决应更多依赖开发者优化代码逻辑，而非语言提供额外的安全保障，同时也指出通过合理的优化策略，可以在保证内存安全的同时减少性能开销。

作者承认由于索引越界或范围不正确造成的生产环境崩溃问题，但认为这种问题更多源于开发者的代码习惯，而非语言本身的问题。通过经验积累，作者学会了避免直接操作未知值的索引或范围，从而减少此类问题的发生。
针对在每次下标操作时都检查索引的提议，作者认为这是过于极端的做法。代码中通常存在“入口点”对索引进行验证，一旦索引通过验证，重复检查显得多余。
当前行业推动的“内存安全”语言主要是因为传统的方法难以扩展。然而，这种方法无法完全避免因“远程”操作（如更改底层存储）导致索引失效的漏洞，这可能导致更难调试的崩溃或代码安全问题。
优化界限检查仍有可能。在 WebURL 中，作者自行实现了一种高效的界限检查方法，专注于速度，并尽量让编译器优化掉不必要的检查。
作者计划未来在引入 Span（生命周期保证）后，将这一界限检查策略集成到新包中发布。

讨论[第二次审查] SF-0007：Subprocess

在 SF-0007 提案的第二次审查中，总体来看，SF-0007 提案为 Swift 引入了一个潜力巨大的子进程 API，但在细节上还需要进一步优化和澄清，尤其是在跨平台一致性、闭包隔离、性能优化等方面。、

第一次审查总结：

该提案得到了很多积极的评论，认为这是现有 Process API 的良好替代方案。然而，也有一些需要作者进一步澄清的问题，包括如何管理存活时间长于父进程的子进程，如何在进程间传递输出，以及一些平台特定 API 的处理问题。

开发者反馈：

闭包发送：一些方法要求闭包是发送类型（sending），这使得它们在与其他代码组合时变得不那么容易。希望能探讨是否可以重构实现，使其不需要这一要求。
闭包隔离：提案中的方法似乎缺少对“隔离”（isolated）的参数，这在使用 actor 隔离的上下文中会导致数据竞争问题。
AsyncSequence 的性能问题：讨论了使用 AsyncSequence 可能导致的性能问题，并希望能进一步基准测试。
平台特定类型：提案中使用了像 pid_t 和 DWORD 这样的平台特定类型，是否可以考虑直接使用 Int 来代替？
ProcessIdentifier 类型：关于 ProcessIdentifier 的命名和不同平台的属性存在一定的疑问，是否可以在所有平台上统一为 .value？
未管理的子进程：有观点认为，未管理的子进程应与文件描述符的直接传递解耦，避免混合不同的概念。
使用 FileDescriptor 和 FilePath：目前 swift-system 并不包含在工具链中，因此提案中如何在公有 Foundation API 中使用这两个类型仍需进一步讨论。
拆解顺序：提案中的拆解方法需要更明确的文档说明，以避免使用者产生混淆。
ExecutionResult 的 Sendable 类型：提案中 ExecutionResult 需要一个 Sendable 类型，但为何必须是 Sendable 类型仍不清晰。
小修改建议：建议使用更长的泛型参数名称，提供更常见的信号类型，调整 sendSignal 的参数标签等。

讨论LSP 与 CMake 和 nightly 工具链集成

在关于 LSP 集成与 CMake 和夜间工具链的讨论中，作者提出在集成 LSP 与 CMake 的过程中，开发者应灵活选择合适的工具链，并关注生成文件的正确配置，特别是在处理项目构建和编译标志时。VSCode 提供了更好的自定义工具链支持，而 Xcode 的兼容性可能有限。

Xcode 与工具链支持：

Xcode 的工具链支持存在不稳定性，开发者可能会遇到兼容性问题。相比之下，VSCode 的 Swift 插件提供了更好的工具链设置功能，允许用户自定义工具链，并应用于所有功能。但 Xcode 会使用其内部版本的工具链，且在处理苹果平台时，可能无法满足工具链的要求。

构建问题与建议：

有些用户在尝试构建项目时遇到问题。特别是，对于使用 CMake 的项目，可能需要尝试不同的生成器（如 CMake generate 或 Ninja generate），以确定哪个适合自己的项目。用户也应该检查生成的文件，确保所有文件都列在其中。

使用 compile_flags.txt：

对于有库的项目，建议使用 compile_flags.txt 风格的配置，而不仅仅是默认的 CMake 配置。这可以帮助更好地管理编译标志。
4. 配置文件与生成问题：

一些配置（如 generatedFilesPath 或 index）可能可以简化生成过程，避免需要单独的 compile_commands.json 文件。虽然目前尚不明确如何完全实现这一点，但仍建议通过配置文件进一步探索解决方案。

讨论在 @Sendable 中捕获 self……请停止它！

在关于 @Sendable 的讨论中，作者指出 @Sendable 和 @unchecked Sendable 机制的设计目的是为了帮助开发者捕捉并发问题，并避免潜在的并发错误。虽然开发者可以选择关闭这些警告，但需要承担起确保线程安全的责任，否则可能会导致数据损坏和崩溃。

编译器的警告作用：

编译器发出的警告并非针对开发者，而是为了提醒潜在的并发问题，尤其是可能发生的不安全访问。编译器认为，当模型（通常是引用类型）被并发访问时，可能会引发并发问题，建议开发者审查代码。

@unchecked Sendable 使用：

如果开发者确定自己能安全地管理同步问题，可以通过标记类型为 @unchecked Sendable 来告诉编译器“我能确保这是安全的”，即使编译器无法进行进一步的检查。这是开发者对编译器的一种承诺，表明他们将负责确保并发安全。

崩溃的有效性：

如果开发者违反了这种承诺并进行了不安全的访问，崩溃是合理的。处理并发问题时，编译器会倾向于立即崩溃，而不是让潜在的错误悄悄存在，避免数据损坏。

编译器与开发者的关系：

尽管开发者可能感到编译器过于严格或烦人，但从编译器的角度，严格的并发检查有助于避免错误，确保代码的安全性。这类似于 C/C++ 等语言中的指针操作，虽然它们提供了更多自由，但也容易导致空指针访问等错误。

@unchecked Sendable 是否关闭警告：

@unchecked Sendable 不会影响运行时，而是作为一个标记协议，告诉编译器在并发访问时可以放心地传递类型，但开发者需要对并发安全负责。如果不小心使用了类型，可能会导致并发错误。

提议Expose attosecond representation of Duration

在关于 Duration 类型 attosecond 表示的提案中，作者通过引入对 Int128 类型的支持，使 Duration 类型更易于使用，特别是在需要高精度时间计算的场景中，减少了冗余代码，提高了性能和可读性。

提案介绍：

该提案的目的是通过引入新的 Int128 类型，允许开发者更方便地访问 Duration 类型的飞秒（attosecond）表示，并简化从飞秒创建 Duration 值的过程。

当前 Duration 类型的局限性：

当前的 Duration 类型有两种方式来构造和分解：一种是低位和高位的属性 _low 和 _high，另一种是通过 components 属性将其分解为秒和飞秒。虽然这些方式有效，但在处理 Duration 的总飞秒表示时存在一些局限性。例如，要生成一个随机 Duration，开发者目前需要编写冗长且低效的代码。