企业网站建设合同书,针织东莞网站建设技术支持,商城网站的模块设计,邢台当地网站建设文章目录 前言新闻和社区五天市值蒸发 2000 亿美元#xff0c;苹果公司怎么了#xff1f;在你的 App 中帮助顾客解决账单问题需要声明原因的 API 列表现已推出 提案通过的提案正在审查的提案 Swift论坛推荐博文话题讨论关于我们 前言
本期是 Swift 编辑组整理周报的第三十五… 文章目录 前言新闻和社区五天市值蒸发 2000 亿美元苹果公司怎么了在你的 App 中帮助顾客解决账单问题需要声明原因的 API 列表现已推出 提案通过的提案正在审查的提案 Swift论坛推荐博文话题讨论关于我们 前言
本期是 Swift 编辑组整理周报的第三十五期每个模块已初步成型。各位读者如果有好的提议欢迎在文末留言。
欢迎投稿或推荐内容。目前计划每两周周一发布欢迎志同道合的朋友一起加入周报整理。
是站在生命之巅嘲笑死神的无能还是跪在生活边缘寻求生存的可能Swift社区始于渺小行至辽阔 周报精选 新闻和社区五天市值蒸发 2000 亿美元苹果公司怎么了 提案具有编码验证的 String Initializers Swift 论坛Swift 分布式追踪 推荐博文iOS ReplayKit 与 屏幕录制 话题讨论 苹果公司正在考虑在今年秋季推出新款 iPhone Pro 时提高其高端手机的价格那么如果到时候新款 iPhone Pro 在国内的价格超过了一万元你还会买吗 新闻和社区
五天市值蒸发 2000 亿美元苹果公司怎么了
不久前的 6 月份苹果公司刚成为首家市值超过 3 万亿美元的企业但其最新一季的财报却引发了投资者对其手机与其他设备需求不振的担忧。
8 月 4 日苹果公司公布了三季度财报。财报显示苹果第三财季营收 817.97 亿美元不及上一财年同期的 829.59 亿美元较上一财季的 948.36 亿美元大幅下滑。在看到新一季财报数据后投资者惊讶地发现这家巨无霸上市公司的营业收入已经连续 3 个财季下滑且苹果在第四季展望中预测当季表现也不大会有差别。
公司股价接连下跌
苹果公司三季报发布日恰在其新产品 iPhone15 系列新机上市前但市场预期苹果手机这一新机型受追捧程度不如以往。在悲观情绪影响下苹果公司股价在 8 月 4 日财报公布日重挫 4.8% 创下今年以来最大单日跌幅市值一天之内蒸发逾 1600 亿美元。而后苹果股价并未能止住跌势截至本周一8 月 7 日苹果的股价已经遭遇“五连跌”股价暴跌近 10% 总市值蒸发超过 2000 亿美元约合人民币 1.44万 亿元。
美国银行的分析师在一份业绩报告中表示苹果正面临美国智能手机市场疲软的大环境。此外估值过高可能也是苹果此次下跌的又一重要原因。对于苹果销售额的“三连降”第一手机界研究院院长孙燕飙表示消费电子市场持续低迷削弱了对智能手机的需求叠加创新力不足难以拉动新机销量苹果手机的销售收入连续下滑。如果苹果在第四财季的销售额继续同比下降这将是该公司 20 年来销售额同比下降持续时间最长的一次。来源金融时报
在你的 App 中帮助顾客解决账单问题
正如我们在 4 月份宣布的那样很快你的顾客就能直接在你的 App 中解决付款问题以便更轻松地继续订阅你的内容、服务和高级功能。
自 2023 年 8 月 14 日起如果自动续期订阅因账单问题而无法续订你的 App 中会显示一个系统提供的表单提示顾客更新其 Apple ID 的付款方式。你可以在沙盒中先测试一下此表单还可以使用 StoreKit 中的 messages (英文) 和 display (英文) 来推迟或禁止显示此表单。这项功能在 iOS 16.4 和 iPadOS 16.4 或更高版本中提供无需采取任何操作即可采用。
需要声明原因的 API 列表现已推出
Apple 致力于保护我们平台上的用户隐私。我们知道有一小部分 API 可能会被滥用来通过信息指纹收集用户设备的相关数据这是我们的 Developer Program 许可协议禁止的一种做法。为了防止滥用这些 API我们在 WWDC23 (英文) 上宣布了开发者需要在 App 的隐私清单中声明使用这些 API 的原因。这将有助于确保 App 仅将这些 API 用于预期用途。在这个流程中你需要选择一个或多个能够准确反映你的 App 如何使用相应 API 的批准原因并且你的 App 只能出于你选择的原因使用相应 API。
从 2023 年秋季开始如果你上传到 App Store Connect 的新 App 或 App 更新使用了需要声明原因的 API (包括来自第三方 SDK 的内容)而你没有在 App 的隐私清单中提供批准的原因那么你会收到通知。从 2024 年春季开始若要将新 App 或 App 更新上传到 App Store Connect你需要在 App 的隐私清单中注明批准的原因以准确反映你的 App 如何使用相应 API。
如果目前批准原因的涵盖范围内并未包含某个需要声明原因的 API 的用例且你确信这个用例可让你的 App 用户直接受益请告诉我们。
提案
通过的提案
SE-0403 软件包管理器混合语言目标支持 提案通过审查。该提案已在 三十四期周报 正在审查的提案模块做了详细介绍。
正在审查的提案
SE-0405 具有编码验证的 String Initializers 提案正在审查。
我们建议添加新的 String 可失败 Initializers用于验证编码输入并在输入包含任何无效元素时返回 nil。
Swift论坛
讨论Swift 字符串比较不将连字等同于其组件
内容大概
我刚刚发现 Swift 字符串将 “office” 和 “office” 视为不相等这让我感到惊讶因为它将 “caña” 和 “caña” 视为相等即都是组合和分解形式。对于一般用户来说这些情况是等价的 - 它们只是以不同的方式表示相同的字形至少在某些字体中是如此。
我进行了一些调查似乎这是因为 Swift 承诺在 Unicode 术语中使用 “规范” 比较而不是 “兼容” 比较。文档提到了这一点但没有解释其含义。
我进一步查找并发现了有关 Unicode 中连字的一些争议和历史这可能会为此提供一些启示例如目前 Unicode 关于连字的观点似乎是不应该用于字距调整例如 “ffi”但它仍然包含一些不恰当 的连字 - 再次如 “ffi” - 这些连字是在这种心态转变之前添加的。
NSString 也类似除非你在使用 compare(_:options:) 时选择了 caseInsensitive 选项这时它会将连字视为其分解形式。这很奇怪因为这与字符大小写无关。
我猜这篇文章主要是向其他人提供信息和警告。但我很好奇为什么 Swift 选择执行 “规范” 比较而不是 “兼容” 比较此外似乎在 Swift 标准库中没有办法执行 “兼容” 比较 - 必须导入 Foundation 才能获取字符串重叠部分以便访问前面提到的 NSString 方法。
回答
兼容性分解是 Unicode 在需要与早期编码兼容作为超集的情况下所迫不得已的妥协。如果这些字符直接提议给 Unicode它们将永远不会被编码。通常情况下即使您在使用它们也可能是在做错误的事情因为它们所编码的内容例如连字不是文本的属性而是显示格式的属性。
在 Unicode 的观点中它们本身就不应该出现在原始字符串中。然而将它们折叠到规范形式会丢失有关格式的信息因此不能安全地应用于实际使用了它们的传统文本。以“ff”为例不是每一对“f”都要在显示中连接那些跨越复合词两半的“f”应该保持分开。不能通过简单查看上下文来恢复这种区别需要手动进行或通过字典查询来完成。这与类似“ñ”的规范分解根本不同后者在规范化过程中不会丢失信息。
如果想知道两个字符串是否在兼容性方面是等价的则可以使用 Foundation 的 decomposedStringWithCompatibilityMapping 方法。
提议Swift 分布式追踪
动机
虽然 Logging 和 Metrics 可以用于仪器化应用程序的特定部分但 Distributed Tracing 提供了对整个分布式系统的整体视图。与这两者一起分布式跟踪将完成“可观察性的三大支柱”。
与 Logging 和 Metrics 一样如果在库和框架中直接使用一个共同的 API 来实现分布式跟踪社区将从中受益最多。最终用户应该能够自由选择合适的后端实现而无需更改他们正在使用的库或框架。
建议的解决方案
Swift 分布式跟踪围绕着创建跨度span这些跨度共同形成一种树状结构。跟踪可以由在单个服务中记录的跨度组成也可以跨多个服务传播。Swift 分布式跟踪使用基于任务本地的 Swift Service Context 来实现透明的传播无需手动传递上下文。
我们提出的解决方案是一个针对三个“角色”的库
终端用户库和框架作者跟踪器后端实现
用户端
最终用户是从分布式跟踪中受益的人。他们选择适合自己需求的跟踪后端使用具有内置的 Swift 分布式跟踪支持的库并在自己的代码中进行手动仪器化。
库和框架作者
诸如 HTTP 服务器/客户端、数据库库等库/框架最了解如何仪器化其库的内部。他们使用 Swift 分布式跟踪 API 实现通用的跟踪支持而无需考虑特定的跟踪后端。
例子:
HummingbirdSoto
跟踪后端实现
最后一个难题是跟踪器后端实现。它们为导出跟踪 span 提供特定于供应商的支持。
例子
Swift OTel 公开了一个导出到 OpenTelemetry Collector 的跟踪器。这已经允许该跟踪库的采用者导出到与 OpenTelemetry 兼容的流行后端例如 Zipkin、Jaeger、Honeycomb 等。
到期理由
我们提议这个软件包处于“孵化”成熟度级别。 我们相信这个包是服务器生态系统的重要构建块就像许多服务器和客户端库采用 swift-log 和 swift-metrics 一样。
该项目已经成熟超过3年有多个活跃的维护人员并且在生产环境中满足了采用要求。
讨论AttributedString 索引获取导致 nil 值的内部解包
问题描述
我有一个富文本字符串其中一个子字符串正在被替换但是会引发 fatalError
var string AttributedString(café)
let replaceIndex string.index(beforeCharacter: string.endIndex)
let range replaceIndex..string.endIndex
string.replaceSubrange(range, with: AttributedString(e))
let next string.index(afterCharacter: replaceIndex)
// ^---- Unexpectedly found nil while unwrapping an Optional value
assert(next string.endIndex)这令人惊讶因为我认为在更改之前索引会保持稳定。更奇怪的是改变如何创建范围不会导致失败。以下代码可以正常工作
var string AttributedString(café)
let range range(of: é)!
string.replaceSubrange(range, with: AttributedString(e))
let next string.index(afterCharacter: replaceIndex)
assert(next string.endIndex)使用 ASCII 字符而不是重音符号 ‘é’ 不会导致两种范围技术中的任何一种失败。我仔细分析了开源实现试图揭示出现 nil 可选值的源头但我看不到任何问题我认为这与当前发布的代码不同。
对于我哪里的逻辑出了问题有什么建议吗
我使用的是 macOS 13.4.1 和 Xcode 15b5。
回答
明确一点RangeReplaceableCollection 的变异操作可能会使现有索引失效因为这些索引可能包含对于变异集合不再有效的信息例如在字符串的情况下计算的字节偏移不再有效。从 RangeReplaceableCollection.replaceSubrange(_:with:) 文档中可以看出 调用此方法可能会使任何现有索引在与此集合一起使用时失效。 并且这个方法几乎是 RangeReplaceableCollection 上所有其他操作的基础所以人们应该假设除非为特定类型另有说明任何可能改变索引相关信息的变异操作都会使现有索引失效。
提议导入语句的访问级别
这是一个关于在 Swift 中更好地控制依赖和导入的提案。通过这个特性可以将导入标记为公共的当前的常规导入方式对于模块的实现细节可以标记为内部对于源文件的实现细节可以标记为私有或文件私有。
另外更新后的包访问级别允许将依赖标记为仅对同一包中的模块可见。这会像源文件中的常规访问级别一样进行强制执行。将作为内部导入的声明只能从内部声明或更低的访问级别中引用而在公共或包声明中使用则会报错。
下面是一个典型的用例其中依赖项是我们不希望在模块 API 中暴露给客户端的实现细节以及预期的诊断信息
internal import DatabaseAdapterinternal func internalFunc() - DatabaseAdapter.Entry { ... } // Okpublic func publicFunc(entry: DatabaseAdapter.Entry) { ... }
// error: function cannot be declared public because its parameter uses an internal typepublic func useInBody() {DatabaseAdapter.foo() // Ok
}inlinable
public func useInInlinableBody() {DatabaseAdapter.foo()// error: global function foo() is internal and cannot be referenced from an inlinable function
}该提案还定义了一组条件其中可以从客户端隐藏依赖项。这提供了一种强大的方法来完全隐藏实现细节并可以加快客户端的构建时间。
这个提案旨在提供一个正式且更清晰的替代方案来取代 _implementationOnly。与此相反此版本提供了熟悉的诊断信息更多级别的控制以及与非弹性模块和 testable 客户端更好的兼容性。
根据社区对建议的 Swift 6 行为的反应我们可以将其纳入该提案。
讨论序列化文件访问的 Actor
问题描述
我想知道使用 Actor 是否是保护资源免受并发访问的好选择例如一个文件目录。在过去我曾使用 dispatch queues 实现这种情况。使用 Actor 作为阻塞文件访问 API 的通道点的优缺点是什么
回答 仅仅是在文件系统中进行典型的CRUD操作 在这里Actor并不能帮助你。即使在 Actor 可重入性的考虑之外从 Actor 外部调用的 Actor 方法的执行顺序也无法保证。
CRUD 操作已经是线程安全的如果它们不是那将是一个相当令人失望的文件系统。由于 Actor 不以执行方法的调用顺序“串行化”任何内容因此不需要 Actor。
可能需要的是一个 FIFO 队列这就是串行的DispatchQueue 解决方案为此提供的好处。
现在如果谈论的是将一系列操作有效地“原子化”例如在枚举目录时不允许同时对其进行变异那么需要保护的是一些可变状态Actor 可以保护它。在我看来这是比 CRUD 更高层次的抽象。在这方面我认为 tera 的问题在这里比想象的更相关。
讨论L-shaped 枚举
问题描述
用于缺乏更好的术语我有很多“L-shaped”枚举它们具有一些不同的有效载荷类型和一些共同的有效载荷类型。
以下是一个示例
extension ServerDelegate
{enum Request:Sendable{case get (Get, EventLoopPromiseServerResponse)case post (Post, EventLoopPromiseServerResponse)case delete (Delete, EventLoopPromiseServerResponse)}
}
extension ServerDelegate.Request
{enum Get { ... }enum Post { ... }enum Delete { ... }
}这种布局存在问题
很难访问共同的字段EventLoopPromiseServerResponse除非在枚举上进行 switch 操作。
很难在实际的变体有效载荷上进行 switch因为您必须使用 _ 忽略共同字段。
这里有一个明显的重构方法即将变体有效载荷提升到另一个嵌套类型
extension ServerDelegate
{struct Request:Sendable{let operation:Operationlet promise:EventLoopPromiseServerResponse}
}
extension ServerDelegate.Request
{enum Operation:Sendable{case get (Get)case post (Post)case delete (Delete)}
}
extension ServerDelegate.Request.Operation
{enum Get { ... }enum Post { ... }enum Delete { ... }
}但这感觉像是过多的嵌套和过多的类型结构与我尝试建模的复杂性成正比。而且 ServerDelegate.Request.Operation.Get、ServerDelegate.Request.Operation.Post 等枚举本身可能还有更多的嵌套结构。
我们有哪些替代方案呢”
回答
命名空间中的点是嵌套的结果这与这里的类型结构并不是真正的基本关系。提供便利的 API 来处理一些 .init 繁琐的情况似乎也是合理的例如
extension Request {static func get(url: URL, params: [String: String], mintPromise: () - EventLoopPromise) - Self { ... }
}推荐博文
iOS ReplayKit 与 屏幕录制
摘要 这篇文章主要介绍了使用 Apple 的 ReplayKit 框架来实现屏幕录制功能包括应用内录制和系统级录制。 ReplayKit 从 iOS 9中第一次提供已经发展并增强了许多特性。文章对创建和接入 ReplayKit Extension 系统级录制流程以及在 LOOK 直播中的实践例子等进行了详细介绍。然而屏幕录制开发面临着一些挑战如内存限制、开发和调试困难、内存控制等。文章强调在开发过程中要小心应对这些问题保持内存使用远离 50MB 的限制阈值以及充分利用日志来解决问题使能够优雅地完成屏幕录制功能。
TheRouter-iOS 轻量化路由中间件
摘要 TheRouter 是一款由货拉拉打造的轻量级路由中间件旨在支持 Android 和 iOS 平台。该中间件在 iOS 端吸取了其他语言的特性增加了注解功能强化了路由在 iOS 端的使用体验。 TheRouter 摒弃了传统 iOS 的 target-action 或 protocol 理念对齐了更广泛的后台或 Android 应用。主要功能包括依赖注入、硬编码消除、动态化能力和页面导航跳转能力。文章详细解释了 TheRouter 的实现原理如注解式依赖注入路径硬编码处理等并提供了详细的使用介绍和示例。
iOS App Store 上架被拒 case
摘要 这篇文章主要记录了 App Store 上架过程中遇到的一些被拒绝的案例以及对应的原因分析和解决策略。案例涵盖了从功能完整性、信息需要、隐私确认到软件需求和上传被拒等不同阶段的问题。文章还详细阐述了各种问题的产生原因如 APP 功能不全、集成未使用的库、隐私信息填写不全等并提出相应的解决方案。通过这些案例的分享开发者可以理解和学习如何避免类似的错误更顺利地完成 App Store 的上架过程。
话题讨论
报道称曾红极一时的少儿编程培训如今现爆雷隐患。你认为儿童是否有必要提早接触编程课
有必要编程课可以激发儿童创造力培养解决问题的能力。没必要缺乏基础和成熟度编程需要数学和逻辑思维能力导致理解困难和挫败感。因人而异有些儿童适合提早接触有天赋和热情发挥潜力其他儿童可以在稍后阶段考虑。
欢迎在文末留言参与讨论。
关于我们
Swift社区是由 Swift 爱好者共同维护的公益组织我们在国内以微信公众号的运营为主我们会分享以 Swift实战、SwiftUl、Swift基础为核心的技术内容也整理收集优秀的学习资料。
特别感谢 Swift社区 编辑部的每一位编辑感谢大家的辛苦付出为 Swift社区 提供优质内容为 Swift 语言的发展贡献自己的力量。
