我在手表上点了上床按钮，手表突然让我手动输入起床时间。我一开始还觉得奇怪，仔细一看，原来手机同步给手表的起床日期已经用完了。SleepTap 会提前生成七天的起床时间，只要后台任务正常执行，这七天就会不断向后延长。现在日期彻底用完了，也就是说，至少有一个星期没有一次成功的后台刷新走到生成日期这一步。
这件事刚好发生在我把 iPhone 升级到 iOS 26.6 之后。升级之后，我也一直没有手动打开过 SleepTap。所以我的第一反应是，系统升级后没有启动过应用，后台任务是不是就不工作了？按 API 的设计，不应该这样。已经注册和提交的后台任务由 iOS 调度，又不是靠用户每天给应用上香才能继续运行。
可我手动打开一次 SleepTap，起床日期立刻同步到了手表，一直排到 8 月 10 日。这至少证明了三件事：日期生成逻辑没坏，手机和手表的同步没坏，前台刷新也没坏。坏掉的只剩后台执行这条路。
我没有马上改代码，而是先等了一天。结果日期还是停在 8 月 10 日。接着我重启 iPhone，又等了一天，还是不执行。后来我修改了一部分代码，重新安装并运行，结果依旧没有后台记录。
这时候很容易开始怀疑玄学。比如 iOS 会根据应用过去的执行情况分配后台额度，SleepTap 会不会因为以前注册了两个 App Refresh 任务，被系统悄悄惩罚了？以前系统睁一只眼闭一只眼，现在 iOS 26.6 不提示错误，直接一个都不给执行？这听起来有些像奇谈怪论，但后台调度本来就是黑盒，不做实验，谁也不能说它一定不可能。
SleepTap 当时有两个后台刷新任务，一个更新起床日期，一个更新天气和晒太阳通知。我先把天气任务停掉，只留下日期任务，又把应用版本升了。结果还是不执行。也就是说，就算所谓的惩罚存在，至少也不是简单地删掉一个任务就会恢复。
我还担心过另一个问题：测试时 iPhone 是通过 Xcode 安装的，如果从 Mac 断开，应用会不会也跟着“断开”？其实不会。任务提交给的是 iPhone 上的 BGTaskScheduler，Mac 和数据线只负责安装、调试和读取日志。拔掉数据线会断开调试器，不会删除手机系统保存的请求。
既然 SleepTap 身上的历史包袱太多，我干脆新建了一个测试应用。它只做一件事：注册一个 BGAppRefreshTaskRequest，后台处理器被调用之后立刻发一条本地通知，并把 handler.entered、通知添加和完成状态写进本地记录。
这已经简单到不能再简单了。没有天气，没有手表，没有 SwiftData，也没有复杂的网络请求。如果它能执行，说明 SleepTap 可能真的被系统区别对待。如果它也不能执行，那就不是 SleepTap 自己的问题。
结果，这个新应用也一直没有执行。
我手动打开过一次，通知权限是 true，提交 API 也明确返回成功。请求早就超过了 earliestBeginDate，但记录里一次 handler.entered 都没有。不是通知被系统隐藏了，而是处理器根本没有被调用。
到这里，我原以为已经证明了 iOS 26.6 的后台调度整体坏了。可我又想了想，这个所谓的“独立测试应用”，其实并不独立。它和 SleepTap 使用的是同一种注册方式：
.backgroundTask(.appRefresh(identifier)) {
await handleAppRefresh()
}
如果坏掉的是 SwiftUI 的 .backgroundTask，那么两个应用当然会一起失败。这不叫对照实验，这叫把同一份可疑代码抄了两遍。
我接着看了苹果的官方示例 Refreshing and Maintaining Your App Using Background Tasks。这个示例是 WWDC 2019 的，使用的是古法 AppDelegate：在 application(_:didFinishLaunchingWithOptions:) 中调用 BGTaskScheduler.shared.register，任务到期时取消操作，完成时显式调用 setTaskCompleted(success:)。
我原本以为这只是 UIKit 和 SwiftUI 的写法差异。SwiftUI 的 .backgroundTask 本来就是官方 API，凭什么旧写法可以，新写法不行？可苹果开发者论坛里早已有一串相关讨论。在 BGTaskScheduler crashes on iOS 18.4 这个帖子里，苹果 DTS 工程师确认 SwiftUI 的后台任务集成存在注册时序问题，并建议用 UIApplicationDelegateAdaptor 回到 AppDelegate，在 didFinishLaunchingWithOptions 中尽早注册。帖子讨论的是 iOS 18.4 上的崩溃，而我遇到的是 iOS 26.6 上悄悄不执行，表现并不完全一样。但它们指向的是同一个危险点：SwiftUI 可能太晚才替应用注册处理器，而任务没有正确注册，就不可能被执行。
还有一个很容易误判的地方。earliestBeginDate 不是预约时间，只是“不早于这个时间”。苹果的文档写得很清楚，系统不保证在指定时间启动。所以等一小时没执行，不能立刻说有 bug。可连续多天不执行、七天日期全部耗尽，再加上测试应用完全没有 handler.entered，这就不能只用“系统会择机调度”来搪塞了。
我把测试应用改成 AppDelegate 注册，保留原来的 identifier、通知和事件记录，只替换注册路径。为了不用再傻等一天，我把第一次请求的最早时间改成五分钟后。任务真正执行之后，再续订到一小时后。五分钟并不是要求系统五分钟准时执行，只是让它尽快进入可执行状态。
手机里的记录很清楚：14:00:53 提交请求，14:05:53 开始具备执行资格，14:09:09 系统调用 handler。同一秒，应用提交了下一次请求，加入本地通知，最后记录 handler.completed。整个链条走完，没有过期，也没有失败。
macOS 随后通过 iPhone Mirroring 显示了这条来自 iPhone 的通知：后台任务已执行，时间 14:09:09。当时 iPhone 并不依赖 Xcode 的调试连接。这也顺手排除了我之前关于“断开 Mac 会不会导致应用断开”的担心。
严格地说，这还不是完美的单变量实验，因为我同时改变了注册方式和第一次的等待时间。但原来的 SwiftUI 请求已经超过最早时间几个小时，甚至几天，也从未进入处理器；AppDelegate 版本第一次自然调度就完整执行。对于工程判断来说，证据已经足够了。继续等，不会让问题变得更正确。
我把 SleepTap 也改成了 AppDelegate 早期注册，版本升到 1.6.3。现在应用只保留一个系统后台任务，最早时间仍然按照用户的起床时间加一小时计算。处理器进入之后先续订下一次任务，再更新睡眠通知和手表上的起床日期，最后尝试刷新天气和晒太阳通知。
天气原来有自己的 App Refresh 任务，现在不再单独注册。它仍保留原来的业务逻辑：只在 6:00 到 18:00 之间处理，检查六小时缓存和位置变化，确实需要时才请求天气。用户手动打开 SleepTap 时也会检查天气，缓存过期就刷新，缓存有效就直接重新计算晒太阳计划。
这样做不是因为两个后台任务在 API 上一定不允许，而是我已经没有理由继续让两个不确定因素同时存在。一个任务负责唤醒，里面顺序执行日期和天气逻辑，出了问题也更容易看日志。这叫减少变量，不叫架构升级。
回头看，这个问题的时间线其实很完整。不是某一天突然灵光一现找到了答案，而是每天排除一点，最后才发现，最值得怀疑的恰恰是看起来最不值得怀疑的那一层。
7 月 27 日：升级 iOS 26.6。 苹果在这一天发布了 iOS 26.6，官方安全更新页面也记录了这个日期。我当天升级了系统，之后一直没有手动打开 SleepTap。当时当然没觉得有什么问题，后台任务本来就应该由系统调度，我没有理由每天打开一次应用检查它还活着没有。
7 月 28 日到 8 月 2 日：一切看起来都很正常。 这几天我没有收到晒太阳通知，但也没有立刻把它和后台任务联系起来。手表里的起床时间是提前生成七天的，所以即使后台任务从升级之后一次都没成功，前几天仍然不会露馅。这个七天缓存原本是保护用户的，结果也把故障藏了七天。
8 月 3 日：七天用完，问题出现。 我在 Apple Watch 上点击上床按钮，手表突然要求我手动输入起床时间。检查后发现，提前同步的起床日期已经全部耗尽。我手动打开一次 SleepTap，日期马上补齐到 8 月 10 日。于是我们先确认了日期生成、前台刷新和 Watch 同步都正常，把问题缩小到后台执行。同时也提出了第一个怀疑：会不会是升级系统之后没有再手动启动过应用，导致后台注册失效？这和 API 应有的行为不符，但和实际现象很像，所以先不急着下结论。
8 月 4 日：继续等，不重启。 手表上的日期仍然只到 8 月 10 日，没有刷新出 11 日。此时有两个选择，要么重启手机，要么再保留一天自然观察。我选择先等，因为一旦重启，系统调度状态就变了。假如第二天任务自己恢复，我们还能证明它只是延迟；马上重启反而会把这个证据毁掉。
8 月 5 日：等待无效，开始重启实验。 又等了一天，后台任务还是没有执行。自然恢复这条路基本可以排除了，我于是重启 iPhone，再给系统一天时间。这里仍然没有立刻改代码，因为重启和改代码一起做，即使恢复了，也不知道是谁起的作用。古法排错虽然慢，但至少不会自己骗自己。
8 月 6 日：重启也没用，开始减少变量。 重启后又观察了一天，日期仍然没有向后延长。我修改代码、重新安装并运行，还升级了应用版本，避免系统如果真的针对旧版本保留了某种调度判断，新代码仍然继承旧状态。同时暂停天气后台任务，只注册起床日期这一个任务。可它还是没有执行。检查天气后又发现，晒太阳通知也已经多天没出现，这说明不是单独一条日期逻辑坏了，两个后台处理器都没有留下成功执行的迹象。也正是在这一天，我决定另建一个只有后台任务和本地通知的测试应用，和 SleepTap 并行观察。
8 月 7 日：最小测试应用也沉默。 新应用没有天气、手表和数据库，处理器只要被调用，就写一条记录并发送通知。我手动打开过，也手动提交过请求，等了几个小时仍然没有通知。我一度担心从 Mac 断开 iPhone 会不会让应用也跟着断开，后来排除了：断开的只是 Xcode 调试连接，手机上的应用和已经提交给系统的请求都还在。新应用也失败，本来很像是 iOS 26.6 把整个后台调度弄坏了。可问题是，新应用照抄了 SleepTap 的 SwiftUI .backgroundTask 注册方式。两个使用同一种可疑写法的应用一起失败，根本不能证明系统不调度，只能证明这条注册路径值得怀疑。
8 月 8 日：对照苹果 Demo，问题解决。 我把苹果官方示例和我们的代码逐项比较，终于注意到官方 Demo 并没有使用 SwiftUI .backgroundTask，而是在 AppDelegate 的 didFinishLaunchingWithOptions 中直接调用 BGTaskScheduler.register。再结合苹果 DTS 对 SwiftUI 注册时序问题的说明，我把测试应用改成和官方 Demo 一样的注册方式。14:00:53 提交请求，14:05:53 开始具备执行资格，14:09:09 处理器真正进入，通知也通过 iPhone Mirroring 显示在 Mac 上。证据已经足够，我随后用同样方式修改 SleepTap，把天气合并进起床日期任务，并保留用户手动打开应用时的天气刷新。
从升级到发现问题，刚好七天。从发现问题到真正解决，又用了五天。期间等待过、重启过、重装过、升级过版本、减少过任务，也怀疑过系统惩罚和 Xcode 连接。结果真正的答案不在这些地方，而在苹果自己的 Demo 里：SwiftUI 提供了更漂亮的注册方式，但至少在我的 iOS 26.6 设备上，真正可靠的仍然是 AppDelegate 里的古法注册。
我现在能确认的是：在我的 iPhone SE 3、iOS 26.6 上，两个使用 SwiftUI .backgroundTask(.appRefresh(...)) 注册的应用都没有自然进入处理器；换成 AppDelegate 中直接调用 BGTaskScheduler.register 后，测试应用第一次就成功执行。
我不能据此宣布所有 iOS 26.6 设备都会中招，也不能证明它和 iOS 18.4 的论坛问题是同一个 bug。但如果你的后台任务在升级之后突然消失，提交又不报错，别只盯着 earliestBeginDate，也别急着怪系统在“惩罚”应用。先记录 handler.entered，再写一个最小测试应用，最后把 SwiftUI 注册换成 AppDelegate 注册做对照。
结论：iOS 26.6 之后，SwiftUI 注册的 App Refresh 后台任务不值得信任。至少在苹果修复并解释这个问题之前，我会使用 AppDelegate 的古法注册。
]]>WKWebView 预览 Markdown，Mermaid 也是通过本地 JavaScript 渲染的。既然应用里能显示，那么把同一套渲染代码放进 Quick Look，不就行了吗？
我一开始也是这么想的。
Writer 原来的 Quick Look 使用 data-based preview。扩展读取 Markdown，生成完整的 HTML，然后通过 QLPreviewReply 把 HTML 交给 Finder。标题、列表、表格、代码块这些静态内容都没问题，但 Mermaid 不一样。Mermaid 代码块不是一张现成的图片，需要 JavaScript 解析代码，再生成 SVG。
问题就是，Finder 拿到 HTML，不等于它会像 Safari 或 WKWebView 那样执行里面的 JavaScript。
所以我决定把 Quick Look 改成 view-based extension。也就是不再把一份 HTML 数据交给 Finder，而是由扩展自己提供一个 NSViewController，里面放一个 WKWebView。
这下总该和 Writer 应用内的预览一样了吧？
我修改了 Quick Look 扩展以后，在 Finder 中预览 Mermaid 文档，看到的仍然是一个普通代码块。Mermaid 源码还在，流程图没有生成。
这很像是 JavaScript 没有执行。但继续检查之前，必须先确认一件更基础的事：Finder 调用的到底是不是我刚刚修改的扩展？
因为 /Applications 里还安装着旧版 Writer。旧版扩展本来就能把 Markdown 转成 HTML，只是会把 Mermaid 当作普通代码块。所以当时看到的结果并不能证明新代码失败了，只能证明 Finder 找到了某个 Writer Quick Look 扩展。
我删除了 /Applications 里的 Writer。删除之后，Finder 一度退回了系统的纯文本预览。这证明刚才把 Mermaid 显示成代码块的，的确是旧版 Writer。
之后我安装了包含新版 view-based Quick Look 扩展的测试版。Finder 不再显示纯文本，右上角也出现了“Open with Writer”。这说明新版扩展终于被调用了。
可这一次，预览窗口变成了一片空白。
所以这里其实有两个完全不同的问题。Mermaid 显示成代码块，是 Finder 调用了旧版 Writer。真正调用新版扩展之后，遇到的问题才是 WKWebView 白屏。
如果不先排除旧版扩展，我很可能会继续在 Mermaid 初始化代码里找问题。可实际上，前一个结果根本不是新代码生成的。
我临时创建了一个最小的 macOS 应用，只注册一种自定义文件类型，再给它加入一个最简单的 Quick Look view extension。
这个扩展不解析 Markdown，不读取主题，也没有 Mermaid。它只显示一个原生的 NSView，上面写着：
Quick Look view extension is working
安装之后，Finder 正确显示出了这个界面。
这说明 view-based Quick Look 本身没有问题。Finder 能加载扩展，扩展也能提供自己的视图。
不过这还不够。Writer 真正需要的是 JavaScript，不是一个静态的 NSTextField。于是我又把探针改成 WKWebView，加载一段完全内嵌的 HTML，并运行一小段 JavaScript，让页面显示：
JavaScript check: 6 × 7 = 42
结果，探针也变成了白色。
到这里，问题已经很清楚了。不是 Markdown，不是 Mermaid，也不是 Writer 的主题代码。只要在 Quick Look 扩展里换成 WKWebView，页面就出不来。
我查看了系统日志，终于看到了真正的错误：
Application does not have permission to communicate with network resources.
Invalid connection identifier (web process failed to launch)
这就很有意思了。
我加载的是 loadHTMLString，HTML 在内存里，JavaScript也在应用包里，没有 CDN，没有远程图片，甚至连一个 HTTP 请求都没有。你告诉我缺少网络权限？
可日志里写得很清楚，不是页面加载失败，而是 WebKit 的 Web Content 进程根本没有启动成功。
我于是给 Quick Look 扩展加入了：
<key>com.apple.security.network.client</key>
<true/>
重新编译，重新安装。
探针页面显示出来了，JavaScript 也成功计算出了 42。
故障排除。
按照苹果文档，这个 entitlement 表示沙盒应用可以主动建立网络连接。从字面上看，一个完全离线的 WKWebView 不应该需要它。可在我当前使用的 macOS 版本和 Quick Look 扩展环境中，没有这个权限，WebKit 的内容进程就无法正常启动。
我不敢说所有 macOS 版本、所有 Quick Look 扩展都一定如此。但至少在实际测试中，这不是推测，也不是所谓“可能和沙盒有关”。系统日志和最小探针已经把因果关系摆在这里了。
苹果告诉你 network.client 是用来联网的，却没有告诉你，在 Quick Look 扩展里，即使只加载一段本地 HTML，它也可能决定 WKWebView 能不能活着启动。
这才是这次最坑的地方。
我本来不愿意给 Quick Look 增加网络权限，就是因为快速预览的内容来自用户文件。Markdown 里可以写远程图片，也可以写 HTML。如果直接让这些内容进入一个能够联网的 WKWebView，那么用户只是在 Finder 里按了一下空格，文档就可能向外部服务器发出请求。
这肯定不行。
但这里要分清两件事。扩展拥有网络 entitlement，是为了让 WebKit 的进程能够正常启动，并不意味着页面里的内容也必须获得网络访问能力。
Writer 的 Quick Look 页面加入了严格的 Content Security Policy：
default-src 'none';
img-src data: blob:;
script-src 'nonce-writer-mermaid';
connect-src 'none';
frame-src 'none';
object-src 'none';
也就是说，页面默认什么都不能加载。图片只允许 data: 和 blob:，脚本只允许 Writer 自己注入并带有指定 nonce 的 Mermaid 脚本，网络连接直接设为 none。
在 HTML 进入 WKWebView 之前，扩展还会清理 script、iframe、object、事件属性和其他主动内容。普通 Markdown 的本地附件会转换成 data: URL，远程图片则继续显示占位内容。
这叫给 WebKit 启动进程的权限，不叫给 Markdown 文件自由上网的权限。两者看起来差不多，实际完全不是一回事。
改成 view-based extension 以后，Quick Look 的入口也变了。
原来的实现是生成一个 QLPreviewReply。现在则是由 QLPreviewingController 实现异步的 preparePreviewOfFile(at:)，自己创建并维护 WKWebView。
如果调用 loadHTMLString 以后立刻告诉 Finder“准备好了”，WebView 其实可能还没有完成导航。于是我让扩展等待 WKNavigationDelegate.didFinish，失败、导航失败或者 Web Content 进程终止时，也会结束等待并返回真正的错误。
这不是为了架构漂亮，而是 Quick Look 的生命周期和普通应用窗口不同。应用里的 WKWebView 一直活着，晚一点显示也没关系。Finder 是来向扩展要一份预览的，扩展什么时候回答“准备完成”，本身就是协议的一部分。
同时，Mermaid 的 Tiny 构建和许可证也必须真正进入 .appex 的资源目录。放在主应用里不算。Finder 运行的是扩展进程，它不会因为资源在 Writer.app 的另一个角落，就自动帮你找到。
这类问题只看 Xcode 构建成功没有意义。Quick Look 扩展编译成功，不等于 Finder 正在使用它。Finder 正在使用它，也不等于 WebKit 进程成功启动。WebKit 启动了，也不等于 JavaScript真的执行了。
我最后做了几层验证：
WKWebView 和 JavaScript，复现白屏。network.client 后，确认 JavaScript 成功算出 6 × 7 = 42。其中最有价值的不是后面的测试全部通过，而是那个什么都不做的探针。没有它，我很容易继续怀疑 Markdown 渲染器、主题样式、资源路径或者 Finder 缓存。它把几十个变量砍到只剩一个：Quick Look 扩展里的 WKWebView 为什么启动不了？
这次遇到的坑可以归纳成三件事：
WKWebView 的方式执行 JavaScript。WKWebView，也可以运行 Mermaid，但在实际测试的系统环境中，即使内容完全离线，扩展仍然需要 com.apple.security.network.client，否则 Web Content 进程可能直接启动失败。所以，Finder 的快速预览使用扩展模式以后，运行起来的确可以和应用内预览很接近。但这个“很接近”不是把 WKWebView 塞进 NSViewController 就结束了。
真正的结论是：Quick Look 扩展可以执行 JavaScript，也可以渲染 Mermaid。之前那片空白不是平台不支持，而是 WebKit 的进程根本没有成功启动。苹果没告诉你的，恰恰就是这一点。
]]>Session 的确停了。但是我转动表冠打开 Smart Stack，发现 SleepTap 仍然显示 Wake Up。后来我手动进入 SleepTap，应用里已经没有 Wake Up 了。再回到 Smart Stack，它也变成了当晚 23:00 上床。
我当时认为，Stop 只是终止了 Session，其余步骤是在我进入应用后才执行的。这是我根据按下 Stop 后看到的现象作出的判断。但我并不确定，于是询问 AI。
AI和我讲，Apple Watch 的系统 Stop 会使 WKExtendedRuntimeSession 失效，然后调用：
extendedRuntimeSession(_:didInvalidateWith:error:)
SleepTap 收到这个回调以后，会检查 Session 是否正常结束、之前是否已经通过 notifyUser 叫醒用户，以及这次失效是不是应用自己触发的。如果这些条件都符合，就会把它当成用户点击了系统 Stop，自动记录起床。
记录起床以后，SleepTap 还会写入 HealthKit，清空本轮睡眠时间线，通知手机取消对应的起床闹钟，然后重新生成 Smart Stack 使用的数据，最后调用 reloadAllTimelines() 请求 WidgetKit 刷新。
这套后台路径本来就存在，并不是一定要打开应用。
不过代码里也的确有一个前台兜底。如果系统已经叫醒了用户，但是后台处理没有完成，那么用户下次进入 SleepTap 时，应用会再次检查状态并补记起床。这样一来，前天的现象其实存在两种解释：一种是后台处理没有完成，打开应用以后走了兜底；另一种是后台早就处理完了，只是 Smart Stack 还在显示旧内容，打开应用以后又请求了一次刷新。
只看 Smart Stack，根本分不清。于是我和AI说，那我再试一晚，明天不手动进应用，看看Smart Stack到底能不能更新。AI说，应该这么做，并且建议我分不同时段，多次观察，每次截图。
今天的 Session 大约在凌晨 4:30 开始运行，我在 4:33 左右点击了 Stop。之后我一直没有打开 SleepTap。期间我多次观察，在几分钟后，半小时后都观察了，看到的都还是Wake Up。到了 5:33，我发现 Smart Stack 已经从 Wake Up 自动变成了 Bed Time 23:00。
这至少证明了一件事：不打开应用，后台链路也能完成。前台兜底并不是必需的。
但我很快又产生了另一个判断：难道 extendedRuntimeSession(_:didInvalidateWith:error:) 花了接近一个小时才执行？
我询问AI，AI建议我去看健康应用，根据健康应用的起床时间来辅助判断。
我打开健康 App，里面记录的起床时间是 4:33，和点击 Stop 的时间基本一致。SleepTap 在后台记录起床时，使用的是当时的当前时间。如果这段代码真的拖到 5:33 才执行，健康里的起床时间也应该接近 5:33，而不会是 4:33。
也就是说，Session 的失效回调和起床记录在 4:33 左右就已经完成了。延迟的不是业务处理，而是 Smart Stack 的显示。
这不叫回调执行了一小时，这叫 WidgetKit 一小时以后才把结果画出来。
当然，我只是在 5:33 才发现它发生了变化，并不能证明它正好延迟了一个小时。实际刷新时间位于我上一次查看和 5:33 之间。不过可以确认的是，在这段时间里，HealthKit 里的数据已经是正确的，而 Smart Stack 仍然可能显示旧的 Wake Up。
reloadAllTimelines() 这个名字很容易让人误会。看起来像是“立即重新加载所有 Timeline”，其实它只是向 WidgetKit 提交刷新请求。什么时候重新生成 Timeline，什么时候重绘，什么时候改变 Smart Stack 里的优先级，最终还是系统说了算。调用成功，不等于用户马上能看到结果。
这和我以前调查 Widget 问题时遇到的情况一样：共享数据已经变了，Widget 还在显示旧数据。很多时候不是数据没写进去，也不是业务代码没执行，而是 WidgetKit 继续保留了上一份 Timeline。
这两天的调查结果已经很明确：
点击 Stop 后，Smart Alarm Session 会正常结束。SleepTap 的后台回调也会立即记录起床、写入 HealthKit，并更新 Smart Stack 使用的数据。打开应用只是兜底，不是完成这些操作的必要条件。
Smart Stack 最多可能在相当长的一段时间里继续显示旧的 Wake Up，但它最终会自行刷新。这是 WidgetKit 的可见状态延迟，不是 Session 延迟，也不是睡眠记录延迟。
一开始我根据界面判断后台代码没有执行。第二天又根据刷新时间判断回调执行了一个小时。两次判断都很合理，也都被健康数据推翻了。
所以，调查 Widget 问题，不能只看 Widget。界面是界面，数据是数据。把两者混在一起，肯定会追错方向。
]]>ChatGPT和我说，这是因为copilot这种有时候只会使用环境变量，我需要设置的是http_proxy和https_proxy。我设置好之后，更新了copilot，这下有500KB/s的速度了。
再次打开copilot，对话后我发现，默认的模型变成sonnet-4.6了。我很意外！因为我是中国用户的原因，很久以前就没法使用任何Claude的模型，只能使用OpenAI的。之前我虽然听说如果VPN开启全局模式也能做到，但是我嫌麻烦，就没有弄。
此外，我还发现，现在copilot响应速度快了很多。之前我就觉得copilot的gpt-5.4比OpenAI Codex app里的慢很多。我还以为是copilot的问题。因为我问ChatGPT为啥copilot比Codex的慢，它还给我解释的头头是道，什么copilot搞了负载均衡，额外会加载其他内容，还有Codex可能是独享的，copilot的是共享的。不过从这次改变可以知道，其实原因并不是ChatGPT说的那样，就是因为原本的代理设置不被copilot支持导致的。我们应该警惕大模型的回复，有的时候它说的也不一定对。
]]>你需要一个开发者账户，一个测试账号。这是因为作为收钱的开发者账户，我们需要使用自己的真实信息，这样才能通过Google的开发者账户的验证。因此，开发者账户是中国账户，加上单Visa的信用卡即可，我使用的是招商银行的单Visa的全币卡。你还需要找银行要一下对账单，准备好身份证，这些都是Google验证时需要的。
测试账户需要新建一个美国账户。感谢AI，ChatGPT告诉我，Google账户是根据你注册时的IP来判断你属于哪个国家的。所以，我们主要开启一个美国的VPN，然后注册就可以。特别的，注册时会要求手机号来验证。很多人担心能否用中国的手机号来验证，没问题的。因为这个只是验证你是真人，不作为判断国别的依据。因此，只要你注册时的IP是美国，以后也一直使用这个IP，就没问题。
此外，由于我们的测试账户只是为了测试。并且我们也没有美国的信用卡用来支付，所以我们的账户将不绑定任何信用卡。以免因为绑定了中国的信用卡而导致账户被风控。
如果测试时，在选择“快速卡，一直通过”之后遇到问题，那是因为你的VPN选择的是规则，导致Play商店和Google服务的IP不一致。解决办法就是关掉应用，然后将VPN的规则改为全局，然后重新测试。这样就可以了。
我们采用这种方式，是没办法的的办法。因为我们中国的开发者账户直接用来测试，经常会遇到“设备或者账户不支持支付”这类的问题。那样的话，我们就没有办法测试应用内购买是否正确了。
]]>
我一开始只是想把后退去掉，换成三个点的菜单，然后去掉标题。结果发现后退去不掉。于是我就想看看苹果自己是如何做的。于是我打开了苹果自己的Notes和Numbers。不过Notes其实是有内部库的，于是主要参考的Numbers。
我把Numbers截图给AI，说想要弄一个这个风格的。结果AI搞不定。它虽然设置了标题为空，但是标题始终显示。于是我有把这个描述给Grok，Grok说，这是因为DocumentGroup自动包含了一层Navigation，你需要将它禁用。结果我禁用了，还是不行。又去问Grok，它又说，这是因为iOS的某些版本，有bug，不执行这个操作。但是网友总结了三种办法，1，2，3，然后挨个试。结果第一种就可以了。
这个是我应用最终的效果。
最核心的代码只需要如下的部分。
fork 了一个第三方 macOS 应用，原 release 版本未签名，但提供了源码，为Swift Package格式，需要重新签名并公证后分发。
问题：使用 swift build 构建的可执行文件，无法通过签名添加 hardened runtime。公证时一直报错：
The executable does not have the hardened runtime enabled.
原因：Swift Package Manager 构建时不会启用 hardened runtime，签名时添加也不被认可。
解决：使用 XcodeGen 生成 Xcode 项目，在项目配置中启用。
问题：最初只有 Apple Development 证书（用于开发调试），公证时报错：
The binary is not signed with a valid Developer ID certificate.
原因：公证必须使用 Developer ID Application 证书，不能用 Apple Development。
解决：在 Apple Developer 账号中添加 Developer ID Application 证书。
问题：签名缺少安全时间戳：
The signature does not include a secure timestamp.
解决：在签名配置中添加 --timestamp 参数。
问题：分发版本包含开发用 entitlement：
The executable requests the com.apple.security.get-task-allow entitlement.
解决：在 entitlements 配置中明确设置 com.apple.security.get-task-allow: false。
| 证书类型 | 用途 |
|---|---|
| Apple Development | 开发调试，不能公证 |
| Developer ID Application | 分发和公证 ✅ |
# 安装 XcodeGen
brew install xcodegen
# 配置 project.yml（关键设置）
targets:
YourApp:
settings:
base:
ENABLE_HARDENED_RUNTIME: YES
CODE_SIGN_STYLE: Manual
CODE_SIGN_IDENTITY: "Developer ID Application: Your Name (TEAM_ID)"
OTHER_CODE_SIGN_FLAGS: "--timestamp"
entitlements:
properties:
com.apple.security.get-task-allow: false
# 生成项目
xcodegen generate
# 构建
xcodebuild -project YourApp.xcodeproj -scheme YourApp -configuration Release build
codesign -dvv YourApp.app/Contents/MacOS/YourApp
确认输出包含：
flags=0x10000(runtime) - hardened runtime 已启用Timestamp=... - 有时间戳# 1. 创建 zip
zip -r YourApp.zip YourApp.app
# 2. 提交公证（需要 App 专用密码）
xcrun notarytool submit YourApp.zip \
--apple-id "your@email.com" \
--password "app-specific-password" \
--team-id "TEAM_ID"
# 3. 等待完成
xcrun notarytool wait <submission-id> --apple-id "your@email.com" --password "password" --team-id "TEAM_ID"
# 4. 附加票据
xcrun stapler staple YourApp.app
最简单有效的方式：
project.yml 中配置好签名和 hardened runtime不要试图用 swift build + 手动签名的方式来处理需要公证的分发版本，SPM 的构建产物不兼容。
使用
.toolbar(removing: .sidebarToggle)
可以隐藏侧边栏切换按钮。但是注意，这个不是放在作用在NavigationSplitView上面的。而不是作用在sidebar的视图上面。即必须按照如下的方式使用：
NavigationSplitView(columnVisibility: $columnVisibility) {
sidebar
.toolbar(removing: .sidebarToggle)
} content: {
content
} detail: {
detail
}
NavigationSplitView是三栏的，但是如果你要使用两栏，则有两种方式。
使用sidebar的好处是，sidebar可以隐藏，也可以显示。
使用sidebar+detail的方式。
如果你希望永远显示为两栏，不希望隐藏任何一个栏隐藏，那么使用此方式。
NavigationSplitView(columnVisibility: .constant(.doubleColumn)) {
EmptyView()
.toolbar(removing: .sidebarToggle)
} content: {
content
} detail: {
detail
}
这个的重点在于，通过sidebar设置隐藏了切换sidebar按钮。同时，选择两栏模式，默认不显示sidebar。这样sidebar就无法被调用出来了。并且一直是两栏。
在使用Settings时候，包含sidebar的NavigationSplitView的sidebar按钮会导致出现问题。因此，必须使用上面的第二种方式，隐藏sidebar，并且使用一直存在的两栏。
TabView是最简单的方式，只要你应用的根视图为TabView，那么你的系统架构会自动转成Navigation Tab Bar的方式，自动在工具栏显示Tab的标签。
不过这个方式有一种缺陷，就是应用的标题不会在工具栏上显示。如果你想强制限制，必须引入AppKit然后，覆盖Window的相应设置。
使用Picker的方式则更为友好。之需要在toolbar里添加Picker，然后使用segment样式，就可以获得同样的显示效果。然后使用Switch切换视图即可。
这么做不如直接使用TabView简单，但是可定制化强，并且不会影响标题的显示。
如果不需要设置标题栏，使用TabView更为简便。否则就使用Picker，这样效果更好。
]]>把任务分配给AI，AI很快完成了第一版。我运行一看，怎么没看到新图标，再仔细一找，的确是两个图标了，但是两个图标是各自独立的，彼此之间还间隔了几个其它的图标。这和我看到的不一样，我其实希望的是像音乐播放器那样的，几个图标一体的方式。于是我和AI说明了要一体的。AI表示了解，然后重新生成了代码。AI特意解释说，一体之后，点击时就需要用点击的位置进行二次判断，还确定用户点击的是哪个图标。
最终结果我实验了一下，的确和音乐播放器的一样。看来他们也是这么做的。
]]>这是因为这种方式启动应用后，SwiftUI的应用不会主动创建窗口，视图会在用户手动点击应用之后才创建。而这可能不是我们所需要的。因为如果我们有使用onAppear来执行一些代码。我们实际上是希望代码可以在应用启动时就运行，而这个机制会导致执行会推迟到用户点击时。
因此，我们需要保证即便SwiftUI没有生成Window，也要自己主动来生成Window。
要解决这个问题，我们首先要了解这个启动的整个过程，然后才能知道如何来改进。具体调试的过程我就不讲了，最终我确认启动的过程是这样的：
我们可以使用NSApplication.shared.windows.count来判断。如果是用户手动打开的应用，SwiftUI会创建SwiftUI.AppKitWindow的窗口。而如果是跟随系统登录后后台启动，则不会有这个窗口。
我使用的判断函数是这个：
func isLaunchedAtLogin() -> Bool {
NSApplication.shared.windows.count < 2
}
之所以用2，而不是1判断。是因为我还使用了菜单栏图标，菜单栏图标使用的是NSStatusItem，因此还会包含一个叫NSStatusWindow的窗口。
func applicationDidFinishLaunching(_ notification: Notification) {
createContentViewWindow()
}
/// 用户启动时SwiftUI的窗口会先创建，因此window不会为nil，但是有可能存在延迟，因为是通过.updateWindow还获取的。
/// 所以这里使用其他的方式进行判断，而不是使用window是否为nil
private func createContentViewWindow() {
/// 若是用户点击，会有两个窗口，一个是SwiftUI创建的主窗口，一个status窗口。后者应该是对应菜单栏图标的。
/// 如果是伴随系统启动，则SwiftUI创建的主窗口不存在，只有status的窗口。
func isLaunchedAtLogin() -> Bool {
NSApplication.shared.windows.count < 2
}
if isLaunchedAtLogin() {
let contentView = ContentView()
.environment(\.managedObjectContext, ModelProvider.shared.container.viewContext)
let window = NSWindow(
contentRect: NSRect(x: 0, y: 0, width: 400, height: 240),
styleMask: [.titled, .closable, .miniaturizable, .resizable],
backing: .buffered, defer: false)
window.setFrameAutosaveName("Main Window")
window.contentView = NSHostingView(rootView: contentView)
window.center()
window.makeKeyAndOrderFront(nil)
self.window = window
}
}
传统上，如果我们使用loginItem来实现应用伴随系统启动，那么为了区分是用户手动启动，还是伴随系统启动，需要使用传递参数的方式。但是传递参数，就需要使用额外的launcher辅助应用。
设置辅助应用的步骤是很复杂的。因此，我们现在大多都是直接使用下面的代码来直接使用自动伴随系统登录启动。
try SMAppService.mainApp.register()
这个办法虽然大大简化了设置系统启动后启动应用的步骤。但是这么做之后，由于没有辅助应用，也就没法使用传递参数的办法了。
本文给出的使用NSApplication.shared.windows.count，用窗口数量来间接判断的方式，利用了SwiftUI在后台启动后，不会主动创建窗口的特性，解决了这个问题。
Macro “DefaultsMacrosDeclarations” from package “Defaults” must be enabled before it can be used.
这个问题是我应用所使用的第三方的库 “Defaults”在其内部使用了宏。这个宏在Xcode本地编译时，需要用户手动点击确认才能继续。但是Xcode Cloud中，没有点击确认的位置。因此，就无法完成打包应用的过程。
通过运行脚本的方式，在克隆完文件夹之后，运行脚本，规避掉对于宏的验证。
#!/bin/sh
defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES
必须在Xcode中的根部位置，创建一个新组，命名为ci_scripts，然后在这个组中创建ci_post_clone.sh，内容是上面的内容。
必须在Xcode的根部位置创建组，并且命名也不能错。
我其实最开始是像GPT 4.1提出了这个问题。GPT 4.1的解答只对了一半。它提出了创建文件夹和脚本，文件夹是正确的，脚本名字是错误的。并且它也没有告诉需要在Xcode中创建组，而只是说在项目的根目录创建就可以。最后，它创建的脚本内容不完全正确。
之后我使用了Google搜索。Google搜索默认的AI总结的是正确的，但应该就是从stackoverflow里的答案总结的。我最后是看的SO里的回答，进行的总结。
另外，我建议你完整阅读下面的第一个引用。我使用了里面最为简便的方案。而非最安全的。也许你看了之后，会选择一条不同的手段。
事情的起因是这样的。因为苹果的新系统发布了嘛。我不能免俗的也要改进我之前的应用，添加对于新系统特性的一些支持之类的。
但是我在修改代码后测试时发现，当使用ZStack模拟弹窗之后，弹窗后面的视图的颜色会出错。我一开始以为是ZStack的问题，于是将模拟弹窗改成了.fullScreenCover的方式。这个问题在当时看起来时解决了。但是今天我在使用中发现，这个问题又重新出现了。
于是我在Google上搜索了一下，没想到这还是一个SwiftUI长期存在的一个问题。
How do I stop the AccentColor from turning Gray when a sheet is being presented?
原来在SwiftUI中实际使用时。原本应该一致的Color.accentColor和Color("AccentColor")在实际使用中是不一致的。说得更具体些，就是Color.accentColor会使用应用设置和用户的系统设置。而Color("AccentColor")则是将AccentColor作为颜色资源从Asset文件夹直接读取。因此，虽然它的名字也叫"AccentColor"，但是实际上它只是名字叫"AccentColor"的一个颜色，你改成别的名字，比如"MyAppColor"也是一样的。虽然这样会失去Color.accentColor一些独特的个性，但是能保证颜色的一致，即颜色不会莫名其妙的改变。
系统弹sheet的时候，Color.accentColor会改变的问题，应该就是sheet本身可能存在某种机制，将应用内设置的Color.accentColor从Asset文件夹设置的内容，改成了系统默认设置的内容。比如下图红色圈起来的部分，就是系统允许用户自定义用户AccentColor偏好的地方。
今天遇到了一个sheet弹窗之后，视图更新不同步的问题。由于我已经在提示词中，告诉了我倾向使用@Observable，而不是旧版的ObservableObject，所以一开始大模型创建了正确的@Observable class，然后在视图中使用@State创建了这个model的实例。
但是为什么还是出错了呢？那就要看使用时更具体的实现了。在开启sheet之前，大模型调用了一个准备函数，在这个函数中，对于model进行了一系列的初始化。具体的步骤是这样的，先新建一个model，然后修改它，然后用这个修改完成的model，替换为系统@State里的那个model。
我首先将问题描述给大模型，sheet首次打开的时候，显示的界面并不符合预期，应该有值的地方，实际上为空。但是如果关掉，再次打开，就又正确了。
大模型思考了一番，说这可能是sheet的机制造成，sheet有时会提前锁定一些值，这会造成打开视图时的不同步。它的建议是，在sheet打开的视图内部的onAppear中新增一个fallback的调用，重新检查并赋值。然后还说，如果这样还不行，可以考虑使用GCD延迟的方式，也就是使用DispatchQueme.main.async调用来实现改动。
试了，onAppear的确不行。但是我没有继续使用它建议的GCD延迟的方式。我问它是否还有其它的办法。
大模型想了想，说可以考虑将@Observable的class改成纯粹的struct的方式。然后就其次咔嚓地修改起来，我一看改动后的代码，妈呀！连mutating都搞出来了。SwiftUI的代码哪有这么写的啊？我果断点了Undo，取消了这次修改。
我再次看了一下代码，突然我发现了问题的所在。前面提到，在准备函数中，大模型的改动方式是“先新建一个model，然后修改它，然后用这个修改完成model，替换为系统@State里的那个model。”这个方式在SwiftUI中显然是错误的。SwfitUI中@State的class类型，你不能替换它，因为一替换之前的跟踪就被中断了。
所以我和大模型说，我们不应该“新建model，修改，然后替换@State”，而是应该直接修改@State中的变量。
大模型想了想，觉得我说得有道理，就修改了。然后还跟我说，如果我确定这个好用，那么onAppear那里的代码，就可以删掉了。
于是我先注释掉onAppear那里的代码，然后运行应用，果然一切都正常了。
大模型并没有真正了解SwiftUI的更新机制，这部分的代码写的时候，它更像是一个拙略的模仿者。虽然这部分，我之前的领悟也不怎么深刻，但是我随着持续不断地学习和使用SwiftUI，现在在这方面，我有信心可以说，我可比大模型强多了。
这个说法听起来是反直觉的。大模型相比于人类，应该更擅长重构吧。为什么说它不擅长呢？
事实如此。昨天我想重构一个900多行的SwiftUI的文件，里面包含一个主视图，主视图下的视图组件，以及一个弹出视图。如果是开发者来重构这个文件，之需要新建文件，然后复制，粘贴，再删掉旧的就可以了。可以很快就完成。
但是我用大模型来重构。却接连几次失败。过程一般是这样。一开始大模型计划的挺好。
我为了节省上下文，又单独增加了对于上下文节省的办法。每次重构一个文件，复制、粘贴、删除完了，验证有没有错误。有错误修复，没有再继续。并且可以抛弃掉使用过的上下文。
再次运行，稍微好了些，多实现几个文件，但是最后还是因为上下文不够而失败了。
大模型不擅长重构，不是因为它无法规划重构。而是因为大模型重构时需要考虑大量的上下文信息，最终会因为上下文耗尽而无法继续。
]]>我开始使用macOS 26 beta系列也有一段时间了，目前在使用的最新版本是beta 7。长久以来，我一直遇到一个有些奇怪的问题，就是每次系统睡眠之后唤醒，苹果表的解锁总是失败。但是进入系统之后，在需要苹果表解锁的其它情况下，比如打开密码应用或者钥匙串，双击苹果表侧键解锁的这个功能却总是能成功。
不过苹果表解锁也不总是失败。我有两台Mac mini，一台是M1，一台是M4，M1的解锁就总是成功，而M4这台就总是失败。
今天我突发奇想，想要在AI的辅助下解决这个问题。我首先怀疑的时候VPN软件。因为更新到最新的macOS 26 beta之后，原来使用Clash X Pro不好用了，我不得不换成了Clash Verge rev。我问AI有没有可能是VPN软件造成的。AI说有可能。让我关了它再试。我试了。还是一样。
之后我又和AI一起开启了macOS控制台应用，想尝试通过读取日志来找到问题的解决方案。最后发现了一个loginwindow的一条故障日志，故障（红色）是比错误（黄色）等级更高的错误。它说在创建main文件夹的某个临时文件夹时出错，可能是沙盒的问题。我当时也信了，因为我的M4是256G的，为了节省磁盘空间，我将home文件夹设置到了外置的SSD上。我想这种比较罕见的设置，可能是苹果没有考虑过。我甚至还差一点儿就去跟苹果反馈这个问题。但是后来我放弃了。因为我觉得每次输入密码也还好，不算很麻烦，就没有反馈。同时我在想，以后我再买新电脑，一定要多花些钱，买个大一些的硬盘。
的确。我没能解决这个问题。我只是放下了它。然后，我开始着手解决我的另外一个开源应用的小问题。
App Helper，应用助手。是我开源在GitHub上的一个macOS的助手应用。它的其中一个功能，是一键切换HDR模式，即在开启和关闭之间切换。不过，我发现，我的显示器，虽然支持HDR，但是使用不同的连接方式它对于HDR的支持不同。比如用USB-C线直接连接，就不支持HDR，用HDMI或者DisplayPort线连接，就支持。
所以，我的目标是通过系统API检测，在不支持HDR的时候，隐藏这个一键切换的按钮。因为我当前是USB-C的连接，不支持HDR，所以我首先完成了这部分的代码。
因为我还需要测试支持HDR下的部分。于是我同时使用HDMI进行连接。macOS有一个问题，就是你用两根不同的线连接同一个显示器，但是在macOS看来你就是在使用双显示器。它的显示器设置中，同时显示出两台显示器，并且不能设置禁用其中的一个。这样就比较麻烦了。因为我虽然可以通过显示器上的信号源菜单来切换到不同的接口，但是存在一个主副窗口的问题。
最终没办法，我只能将Mac mini上的USB-C连接显示器的那根拔了下来。将HDMI的连接作为唯一的连接，这样可以方便我进行调试。
这次HDR的选项还是不能显示。经过调试我发现，必须显示器先打开HDR模式，苹果的API才能检测出显示器支持HDR，如果没有开启，那就检测不出来。
那也无妨，大不了我就跟原来一样，不检测了。我又测试一键切换的功能。结果这个功能也不好用。这就比较郁闷了。因为苹果本身并没有提供切换的HDR切换的API，我使用的是脚本调用控件的方式，这个方法生效的前提是控件的位置必须固定。我管它叫数格子，脚本的写法类似，找到xx组的xx格子，然后把它上面的开关打开/关闭。现在系统升级了，位置变了。苹果💊。
算了，心累。我打算彻底去掉这个功能。毕竟，苹果动动手指，我就得重新数格子，并且还需要考虑不同版本macOS的兼容性，实在得不偿失。
休息结束之后，重新唤醒已经睡眠的Mac，手表传来熟悉的解锁声。我居然成功解锁了这台M4。又试了几次，无论是睡眠之后立即解锁，还是睡眠了几小时之后再解锁，都是次次成功。
“这是为什么呢？”（蔡明）如是说。“排除了一切不可能，那么剩下的那个无论多么不合理，就是唯一的可能。”——福尔摩斯。
我做的最大改动只有一点，使用HDMI连接显示器，并且拿掉了USB-C的连线。所以，这个问题的原因就是使用USB-C连接显示器，会导致苹果表无法解锁macOS。这谁能想到啊，你说是不是奇葩的解决办法？
]]>特别说明，这个USB-C连接显示器，就是两边都是USB-C接口。而HDMI连接，则是用Mac mini独有的HDMI接口连接显示器的HDMI接口。
理论上，这个USB-C除了传递数据，还能同时获得显示器传来最大90瓦的电量。不过由于Mac mini的USB-C不支持反向供电，所以没啥用。如果比MacBook，是可以同时供电的。但是不知道是不是这一点影响了苹果表的解锁。我不是硬件工程师，不敢妄言。但是觉得这个值得提一下。
我是从beta 4开始当成主力机使用的，因此从beta 4开始记录。之后会不定期更新。
之前要查看USB设备，需要使用
system_profiler SPUSBDataType
但是新系统中，参数改变了，变成了SPUSBHostDataType。并且输出的结果中的属性也有了变化，需要进行对应的修改。
如果要应用伴随系统启动，现在有两种方式：
方法1是很早就有的方式。方法2是后来新增的方式。不过在新系统中，如果你使用的是方法1，那么在设置的启动项中，只有后台有主应用的名字，系统自动其中中不会有。如果是使用的方法2，那么启动项和后台中都会有主应用的名字。
两种方式都可以成功伴随系统启动。
新系统中，我发现有的应用的菜单栏常驻图标会消失。进一步调查我发现，如果你的菜单栏常驻图标中使用attributedTitle，并且重复设置了相同的值，常驻图标就会消失。
临时解决方案是，每次更改之前比较值是否发生了改变，变了再重新设置。
上面的临时解决方案虽然在系统运行时可以解决问题，但是一旦系统睡眠，唤醒之后还是可能出现同样的问题。经过进一步研究，我发现了更好的解决方案：
假设你的代码是类似这种
class AppDelegate: NSObject, NSApplicationDelegate {
private var statusItem: NSStatusItem?
private func setupMenubarTray() {
let statusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength)
self.statusItem = statusItem
guard let button = statusItem.button else {
fatalError()
}
// 其他代码
}
}
那么将代码改成
class AppDelegate: NSObject, NSApplicationDelegate {
private var statusItem: NSStatusItem?
private func setupMenubarTray() {
if self.statusItem == nil {
self.statusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength)
}
guard let button = self.statusItem?.button else {
fatalError()
}
// 其他代码
}
}
我想问题应该是出在
NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength)这个函数。它可能没有正确的释放。导致同时存在多个实例了。
Beta 5修正了MacCatalyst下.fullScreenCover的显示问题。上一版，会透出后面视图的内容。
]]>最终判定，就是在计算百分比时将Decimal计算的百分比，通过（decimal as NSDecimalNumber).intValue进行输出时出错的。
深入分析具体的原因，是因为Int的精度不足以转换NSDecimalNumber，所以就自动设置为0了。这个对于普通人来说，可能很难理解。毕竟结果也才46，怎么说Int的精度不足呢？但是事实就是如此，你可以简单地认为就是46后面的小数点之后的位数过多了。
解决的办法有有两个，一种是直接使用.doubleValue，然后取整。
let intValue = Int(nsDecimalNumber.doubleValue)
另一种则比较复杂，使用了专门的rounding函数。
let rounded = nsDecimalNumber.rounding(accordingToBehavior: NSDecimalNumberHandler(
roundingMode: .plain,
scale: 0,
raiseOnExactness: false,
raiseOnOverflow: false,
raiseOnUnderflow: false,
raiseOnDivideByZero: true
))
let intValue = rounded.intValue
Claude Sonnet 4（C）：
在SwiftUI中，如果你在一个函数中同时修改两个@State属性，View只会刷新1次，而不是两次。
这是因为SwiftUI有一个重要的优化机制：批量更新（Batch Updates）。当多个状态变化发生在同一个运行循环中时，SwiftUI会将这些变化合并成一次更新。
让我用一个例子来说明：
struct ContentView: View {
@State private var count1 = 0
@State private var count2 = 0
var body: some View {
VStack {
Text("Count1: \(count1)")
Text("Count2: \(count2)")
Button("同时更新两个值") {
// 在同一个函数中修改两个@State
count1 += 1
count2 += 1
print("函数执行完毕") // 这会在View刷新之前打印
}
}
}
}
在这个例子中，点击按钮时：
1. count1和count2都会被修改
2. SwiftUI会将这两个状态变化合并
3. View只会重新渲染1次，同时反映两个值的变化
这种机制的好处是：
• 性能优化：避免不必要的多次渲染
• 视觉连贯性：用户看到的是一次性的状态更新，而不是闪烁的分步更新
• 逻辑一致性：相关的状态变化作为一个整体呈现
如果你想要强制分开更新，可以使用DispatchQueue：
Button("分开更新") {
count1 += 1
DispatchQueue.main.async {
count2 += 1 // 这会导致第二次刷新
}
}
但在绝大多数情况下，SwiftUI的默认批量更新机制是最佳选择。
我：
如果是@Observable这种，也会是批量刷新吗？
C：
是的，**@Observable也会进行批量刷新！**这是SwiftUI观察系统的一个核心特性，不仅适用于@State，也适用于@Observable。
让我用例子来演示：
@Observable
class UserData {
var name = ""
var age = 0
var email = ""
}
struct ContentView: View {
@State private var userData = UserData()
var body: some View {
VStack {
Text("姓名: \(userData.name)")
Text("年龄: \(userData.age)")
Text("邮箱: \(userData.email)")
Button("同时更新多个属性") {
// 在同一个函数中修改多个@Observable属性
userData.name = "张三"
userData.age = 25
userData.email = "zhangsan@example.com"
print("所有属性更新完毕") // 这会在View刷新之前打印
}
}
}
}
在这个例子中，虽然修改了3个不同的属性，但View只会刷新1次。
@Observable使用了Swift的新观察系统（Observation framework），它具有以下特点：
1. **事务性更新：**多个属性变化会被合并成一个更新事务
2. **智能依赖追踪：**只有被View实际使用的属性变化才会触发刷新
3. **性能优化：**避免了不必要的多次渲染
@Observable
class ShoppingCart {
var items: [String] = []
var totalPrice: Double = 0.0
var discountApplied: Bool = false
func addItem(_ item: String, price: Double) {
// 这些修改会被批量处理
items.append(item)
totalPrice += price
if totalPrice > 100 {
discountApplied = true
totalPrice *= 0.9 // 应用10%折扣
}
}
}
struct ShoppingView: View {
@State private var cart = ShoppingCart()
var body: some View {
VStack {
Text("商品数量: \(cart.items.count)")
Text("总价: \(cart.totalPrice, specifier: "%.2f")")
Text("折扣: \(cart.discountApplied ? "已应用" : "未应用")")
Button("添加昂贵商品") {
cart.addItem("iPhone", price: 120.0)
// 即使函数内部修改了多个属性，View也只刷新1次
}
}
}
}
• **批量更新是自动的：**无需特殊配置
• **跨属性合并：**同一对象的多个属性变化会合并
• **运行循环边界：**更新会在当前运行循环结束时统一执行
• **性能友好：**这种机制显著提升了UI响应性能
所以无论是@State、@Observable，还是其他SwiftUI的状态管理方式，都会享受到这种批量刷新的优化机制。
是的，@ObservedObject确实在性能上相对较差，主要原因是它基于较老的ObservableObject协议和Combine框架。关于批量刷新，情况比较复杂：
@ObservedObject理论上也支持批量刷新，但实际效果取决于具体实现：
class UserDataOld: ObservableObject {
@Published var name = ""
@Published var age = 0
@Published var email = ""
}
struct ContentView: View {
@ObservedObject var userData = UserDataOld()
var body: some View {
VStack {
Text("姓名: \(userData.name)")
Text("年龄: \(userData.age)")
Text("邮箱: \(userData.email)")
Button("同时更新多个属性") {
userData.name = "李四"
userData.age = 30
userData.email = "lisi@example.com"
// 这通常会触发1次刷新，但不如@Observable稳定
}
}
}
class ProblematicModel: ObservableObject {
@Published var importantData = ""
@Published var trivialData = "" // 即使只是这个改变
func updateTrivialData() {
trivialData = "无关紧要的数据"
// 整个View都会刷新，即使View可能不关心这个属性
}
}
struct InefficientView: View {
@ObservedObject var model = ProblematicModel()
var body: some View {
VStack {
Text("重要数据: \(model.importantData)")
// 即使这个View只使用importantData
// 但model中任何@Published属性变化都会导致刷新
}
}
}
// 老式方式 - @ObservedObject
class OldUserData: ObservableObject {
@Published var profile = ""
@Published var settings = ""
@Published var cache = "" // 改变这个会刷新整个View
}
// 新式方式 - @Observable
@Observable
class NewUserData {
var profile = ""
var settings = ""
var cache = "" // 只有被使用的属性改变才会刷新View
}
struct ComparisonView: View {
@ObservedObject var oldData = OldUserData()
@State private var newData = NewUserData()
var body: some View {
VStack {
// 使用oldData时，任何@Published属性变化都会刷新
Text("老数据: \(oldData.profile)")
// 使用newData时，只有profile变化才会刷新这个Text
Text("新数据: \(newData.profile)")
Button("更新缓存") {
oldData.cache = "新缓存" // 会刷新整个View
newData.cache = "新缓存" // 不会刷新View，因为没有Text使用cache
}
}
}
}
// 推荐的现代方式
@Observable
class ModernUserData {
var name = ""
var age = 0
var email = ""
}
class OptimizedModel: ObservableObject {
// 只对重要数据使用@Published
@Published var criticalData = ""
// 不重要的数据不使用@Published
private var _cacheData = ""
var cacheData: String {
get { _cacheData }
set {
_cacheData = newValue
// 不会触发View刷新
}
}
}
• **@ObservedObject：**支持批量刷新，但容易过度刷新，性能较差
• **@Observable：**精确的依赖追踪，更好的批量刷新，性能优秀
• **建议：**新项目优先使用@Observable，老项目逐步迁移
@Observable是SwiftUI未来的方向，它解决了@ObservedObject的大部分性能问题。
我：
我注意到，你在使用@Observable的类时，使用了@State，@State private var newData = NewUserData()，而不是let或者var，这是为什么呢？
C：
这是一个非常好的观察！你提到的这个细节很重要，让我详细解释一下：
@Observable
class UserData {
var name = ""
var age = 0
}
struct ContentView: View {
// ❌ 错误方式 - 不会触发View更新
let userData = UserData()
// ❌ 错误方式 - 也不会触发View更新
var userData = UserData()
// ✅ 正确方式 - 会触发View更新
@State private var userData = UserData()
var body: some View {
VStack {
Text("姓名: \(userData.name)")
Button("更新姓名") {
userData.name = "张三"
// 只有使用@State时，这个变化才会触发View刷新
}
}
}
}
@Observable虽然让类具备了被观察的能力，但在SwiftUI中，View仍然需要通过属性包装器来建立观察关系：
@Observable
class Counter {
var value = 0
func increment() {
value += 1
}
}
struct CounterView: View {
// @State告诉SwiftUI："请观察这个对象的变化"
@State private var counter = Counter()
var body: some View {
VStack {
Text("计数: \(counter.value)")
Button("增加") {
counter.increment()
// 因为用了@State，View会自动刷新
}
}
}
}
@Observable
class AppState {
var isLoggedIn = false
var username = ""
}
struct LoginView: View {
// 场景1: View拥有并管理对象的生命周期
@State private var appState = AppState()
var body: some View {
VStack {
if appState.isLoggedIn {
Text("欢迎, \(appState.username)")
} else {
loginForm
}
}
}
var loginForm: some View {
Button("登录") {
appState.username = "用户"
appState.isLoggedIn = true
}
}
}
struct SharedDataView: View {
// 场景2: 对象从外部传入
let sharedAppState: AppState
var body: some View {
VStack {
Text("共享状态: \(sharedAppState.username)")
// 注意：这里不会自动刷新，因为没有使用属性包装器
}
}
}
如果需要在多个View之间共享@Observable对象：
@Observable
class SharedAppState {
var theme = "light"
var language = "zh"
}
struct RootView: View {
@State private var appState = SharedAppState()
var body: some View {
NavigationView {
VStack {
SettingsView(appState: appState)
ProfileView(appState: appState)
}
}
}
}
struct SettingsView: View {
@Bindable var appState: SharedAppState // 用于接收外部传入的@Observable对象
var body: some View {
VStack {
Text("当前主题: \(appState.theme)")
Button("切换主题") {
appState.theme = appState.theme == "light" ? "dark" : "light"
}
}
}
}
• **@State：**告诉SwiftUI”我拥有这个对象，请观察它的变化”
• **@Bindable：**告诉SwiftUI”这个对象是从外部传入的，请观察它的变化”
• **let/var：**普通属性，SwiftUI不会观察其变化
使用@State是为了让SwiftUI知道需要观察这个@Observable对象，从而在对象属性发生变化时自动更新View。这是SwiftUI观察系统的要求，而不是@Observable本身的限制。
我：
你上面的说法有一部分并不准确。在苹果的官方文档中，https://developer.apple.com/documentation/swiftui/migrating-from-the-observable-object-protocol-to-the-observable-macro/，苹果用来替代@StateObject的是@State，用来替代@ObservedObject的，就是var。
C：
你说得完全正确！我之前的解释确实有不准确的地方。感谢你提供的官方文档链接，让我重新准确地解释：
根据苹果官方文档，从ObservableObject迁移到@Observable的对应关系是：
// 旧的ObservableObject方式
class OldDataModel: ObservableObject {
@Published var name = ""
}
struct OldView: View {
@StateObject private var model = OldDataModel() // 创建并拥有
@ObservedObject var shared: OldDataModel // 接收外部传入
}
// 新的@Observable方式
@Observable
class NewDataModel {
var name = ""
}
struct NewView: View {
@State private var model = NewDataModel() // ✅ 替代@StateObject
var shared: NewDataModel // ✅ 替代@ObservedObject (普通var!)
}
struct OwnerView: View {
// 创建并拥有对象的生命周期
@State private var userData = UserData()
var body: some View {
UserDetailView(user: userData)
}
}
struct UserDetailView: View {
// 接收外部传入的@Observable对象 - 就是普通var!
var user: UserData
var body: some View {
VStack {
Text(user.name)
Button("更新") {
user.name = "新名字" // 这会自动触发View更新!
}
}
}
}
这是因为@Observable宏为类生成了观察机制，SwiftUI会自动检测到对@Observable对象的访问和修改：
@Observable
class UserData {
var name = ""
var age = 0
}
struct DetailView: View {
var userData: UserData // 普通属性，无需@ObservedObject
var body: some View {
VStack {
Text(userData.name) // SwiftUI自动追踪这个访问
Text("\(userData.age)") // SwiftUI自动追踪这个访问
Button("更新") {
userData.name = "新名字" // 自动触发刷新
userData.age += 1 // 自动触发刷新
}
}
}
}
// === 旧方式 ===
class OldShoppingCart: ObservableObject {
@Published var items: [String] = []
@Published var total: Double = 0
}
struct OldShoppingView: View {
@StateObject private var cart = OldShoppingCart()
var body: some View {
OldCartDetailView(cart: cart)
}
}
struct OldCartDetailView: View {
@ObservedObject var cart: OldShoppingCart // 需要@ObservedObject
var body: some View {
VStack {
Text("商品数: \(cart.items.count)")
Text("总价: \(cart.total)")
}
}
}
// === 新方式 ===
@Observable
class ShoppingCart {
var items: [String] = []
var total: Double = 0
}
struct ShoppingView: View {
@State private var cart = ShoppingCart() // @State替代@StateObject
var body: some View {
CartDetailView(cart: cart)
}
}
struct CartDetailView: View {
var cart: ShoppingCart // 普通var替代@ObservedObject!
var body: some View {
VStack {
Text("商品数: \(cart.items.count)")
Text("总价: \(cart.total)")
Button("添加商品") {
cart.items.append("新商品") // 自动触发更新
cart.total += 10.0 // 自动触发更新
}
}
}
}
感谢你的纠正！@Observable的强大之处就在于，接收外部传入的对象时只需要普通的var属性，SwiftUI会自动处理观察关系。
我：
我有一些疑惑，@StateObject和@ObservedObject似乎没有什么区别啊。
C：
你的疑惑很正常！从表面上看，@StateObject和@ObservedObject确实很相似，但它们有一个关键的区别：对象的生命周期管理。
@StateObject - “我创建并拥有这个对象”
struct ParentView: View {
@State private var counter = 0
var body: some View {
VStack {
Text("父视图计数: \(counter)")
// 每次counter变化，ChildView都会重新创建
ChildView(parentCounter: counter)
Button("增加父计数") {
counter += 1 // 这会导致ChildView重建！
}
}
}
}
class DataModel: ObservableObject {
@Published var value = 0
init() {
print("DataModel创建了！")
}
deinit {
print("DataModel销毁了！")
}
}
struct ChildView: View {
let parentCounter: Int
// ❌ 错误用法 - 每次父视图刷新都会重新创建DataModel
@ObservedObject private var wrongModel = DataModel()
// ✅ 正确用法 - 无论父视图如何刷新，DataModel只创建一次
@StateObject private var correctModel = DataModel()
var body: some View {
VStack {
Text("父传入的值: \(parentCounter)")
Text("子视图数据: \(correctModel.value)")
Button("增加子数据") {
correctModel.value += 1
}
}
}
}
运行上面的代码，你会发现：
struct ProblematicChildView: View {
let parentCounter: Int
@ObservedObject private var model = DataModel() // ❌ 问题代码
var body: some View {
VStack {
Text("数据: \(model.value)")
Button("增加") {
model.value += 1
}
}
}
}
**问题：**每当父视图刷新时，DataModel()会被重新执行，创建新对象，之前的数据丢失！
struct CorrectChildView: View {
let parentCounter: Int
@StateObject private var model = DataModel() // ✅ 正确代码
var body: some View {
VStack {
Text("数据: \(model.value)")
Button("增加") {
model.value += 1 // 数据会被保持，不会因父视图刷新而丢失
}
}
}
}
class Timer: ObservableObject {
@Published var count = 0
private var timer: Foundation.Timer?
init() {
print("⚠️ Timer对象创建")
startTimer()
}
deinit {
print("💥 Timer对象销毁")
timer?.invalidate()
}
private func startTimer() {
timer = Foundation.Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { _ in
self.count += 1
}
}
}
struct MainView: View {
@State private var refreshTrigger = 0
var body: some View {
VStack(spacing: 20) {
Text("主视图刷新触发器: \(refreshTrigger)")
// 每次点击都会导致子视图重建
BadTimerView(trigger: refreshTrigger)
GoodTimerView(trigger: refreshTrigger)
Button("触发父视图刷新") {
refreshTrigger += 1
}
}
}
}
struct BadTimerView: View {
let trigger: Int
@ObservedObject private var timer = Timer() // ❌ 每次父视图刷新都重新创建
var body: some View {
VStack {
Text("错误方式 - 计时: \(timer.count)")
Text("触发值: \(trigger)")
}
.border(Color.red)
}
}
struct GoodTimerView: View {
let trigger: Int
@StateObject private var timer = Timer() // ✅ 只创建一次，状态保持
var body: some View {
VStack {
Text("正确方式 - 计时: \(timer.count)")
Text("触发值: \(trigger)")
}
.border(Color.green)
}
}
struct MyView: View {
// ✅ 我创建并拥有这个对象
@StateObject private var myData = MyDataModel()
// ✅ 这个对象是从外部传入的
@ObservedObject var sharedData: SharedDataModel
var body: some View {
ChildView(data: myData) // 传递给子视图
}
}
struct ChildView: View {
// ✅ 接收从父视图传来的对象
@ObservedObject var data: MyDataModel
var body: some View {
Text("\(data.value)")
}
}
• **@StateObject：**我创建 = 我负责
• **@ObservedObject：**别人创建 = 我只观察
这就是为什么在迁移到@Observable时，@StateObject对应@State（创建并拥有），@ObservedObject对应普通var（接收外部对象）。
]]>使用初始化函数的方式之后，始终显示的是xtTransUnits.isEmpty == true的分支，这是为什么呢？
#AI回答
问题出在初始化器的实现方式上。当前的实现使用了立即执行的闭包来设置 xtTransUnits，但因为 @State 属性在初始化器中的特殊性，这种方式并不会正确地设置初始值。
修改建议如下：
struct AITranslationView: View {
// ... 其他属性 ...
init(trees: [Tree<IDTree>]) {
self.trees = trees
let allUnits = Xliff_Tool.getXTTransUnits(from: trees)
_xtTransUnits = State(initialValue: allUnits.filter { $0.target == nil || $0.target?.isEmpty == true })
}
}
关键修改点：
这样修改后，xtTransUnits 将被正确初始化，视图也会显示正确的分支。
]]>原始的代码是这样的
.sheet(isPresented: $showAITranslationGuideView) {
let xtTransUnits: [XTTransUnit] = {
let xtTransUnits = Xliff_Tool.getXTTransUnits(from: trees)
return xtTransUnits.filter { $0.target == nil || $0.target?.isEmpty == true }
}()
AITranslationView(xtTransUnits: xtTransUnits)
}
询问AI啥原因，AI是这么回答的。
.sheet(isPresented: $showAITranslationGuideView)为什么会多次执行？
在 .sheet(isPresented: $showAITranslationGuideView) 代码块中，每次 showAITranslationGuideView 状态变化时都会重新执行闭包内的代码。这里的问题是 xtTransUnits 的计算被放在了视图构建的闭包中，而不是在实际需要时才执行。
建议将这些逻辑移到 AITranslationView 的初始化或 onAppear 中。以下是修改建议：
.sheet(isPresented: $showAITranslationGuideView) {
AITranslationView(trees: trees)
}
然后在 AITranslationView 中处理数据：
struct AITranslationView: View {
let trees: [Tree<IDTree>]
@State private var xtTransUnits: [XTTransUnit] = []
var body: some View {
// 你的视图内容
.onAppear {
xtTransUnits = getXTTransUnits(from: trees)
.filter { $0.target == nil || $0.target?.isEmpty == true }
}
}
}
这样可以确保计算只在实际需要时执行一次。
]]>需要注意的是，AI的解释是对的，但是不是真正的原因。但是解法又同样是对的。只要移出这个初始化的代码之后，的确就不会重复计算了。
我认为真正原因是这样的。像.sheet(isPresented: $showAITranslationGuideView)的sheet，是在View初始化时就会被生成的。它是不变的。这就是为什么还有一个同名的但是使用Optional的sheet，那个才是动态的。但是我这里面的代码，在sheet使用前重新进行了计算。这导致原本应该只能是静态的sheet，变成了动态的，从而导致它从新被加载，而这种情形，其实是为定义的，因为这里不应该使用动态的。这个才是出错的真正原因。