@RayJiang9 哎呀，尴尬，是这个 Shortcuts 链接 https://www.icloud.com/shortcuts/6766a221591b4c8398d3cdb0eaf5d123

@changanl 之前链接贴错了，是这个 https://www.icloud.com/shortcuts/6766a221591b4c8398d3cdb0eaf5d123

@Iiang iOS 版本是多少，我收集一下信息。

@SkywalkerJi 准确说是不允许三方应用操控系统的 Clock 底下的闹钟信息。

@changanl 可以试试这个 Shortcuts https://apps.apple.com/app/id6501973975

@jy03179163 其实如果你睡眠闹钟时间是在 14 点前，感觉跳过下一个睡眠闹钟，应该还是可以的，我这边睡眠闹钟 7:00 ，执行完“跳过下一个睡眠闹钟”，闹钟页面显示的是“已跳过（仅明天）”。

@6364v2 谢谢，我争取搞一个 iOS 16 设备来弄一下……

@qq2511296 我觉得我这个如果要增加减少某一些天简单一些些。

@jiandandkl iOS 系统层面不支持

@6364v2 你看看能不能在底下不是有个“搜索 App 和操作”那个输入框，看看输入“休息日”有没有啥结果。

@dengshen 因为 App Intents 最低 16 开始的，不过好像 16 的支持也有点奇怪，推荐 17 使用。

@6364v2 你看看快捷指令里面能找到休息日及其指令吗？

@vruzo 不需要，你可以打开快捷指令页面，选择某个特定的闹钟，然后点开 “>” ，把“运行时显示”关掉。你只有不设置或者对应值变成“每次均询问”，才会每次都要选择，否则无感的。

@6364v2 我感觉得整个 iOS 16 设备测试下……

休息日的判断逻辑是这样的：“用户标注” 大于 “公共假期模板信息” 大于 “这一天是不是周末”

@klo424 单休因为香港很多人是单休的，所以后面会加上一个单休双休的选项，但是这个要看需求多不多了。

大小周可以自己在第二个 Tab 日历进行把隔周的周六或者周日（具体决定权在用户手上）标记成工作日，实现大小周。

毕竟有些大小周是三周一个双休，总之又复杂又苦逼，我觉得做出来代码也很复杂很苦逼。

@ysxb1145 其实是 Android 的厂家有动力在自己的系统里定制这种定制化的服务。毕竟其他家都做了，而且人家是靠广告和设备赚钱的，这些免费的功能你已经为其付费了。

另外我不觉得这些国内定制版这件事情上做得特别好，很多家 Android 厂家应该根本没考虑自治区也有自己的节假日安排。

而我，既然决定修修补补，那就要收我觉得合理的价钱。

--------------------

而回到这个“节假日闹钟”，我觉得 Google 和 Apple 不做是很非常好理解的，节假日安排这种东西其实是很复杂的：

比如马来西亚，各个洲有不同的法定节日，你也许可以大概判断用户是马来西亚的，但是怎么判断用户属于哪一个洲，如果他就住在两洲的交界处呢。

甚至用户的身份、从事的行业直接决定了他们的法律假期是哪一些。

这种事情做了成本太高，最终效果未必好。

@chengYT @hheng101 @dilidilid @zhigang1992 @AceRacer @1145148964

请到 https://github.com/zizicici/Duplicator 里自取代码，跑一下测试一下。看看你们说的是不是正确的。

-------------------

所谓 iOS 10.3 blabla APFS blabla 的，其实对于这个场景是不奏效的。

你们说的场景可能在一个沙盒内部的某些情况会奏效，但是对于通过系统控件 Sharing 到另外一个 App 是没有用的。

大概的流程是 iOS 系统把分享的文件先投递到 Receiver 的 Documents/Inbox 处，这时候文件已经进入 Receiver 的沙盒里了，然后 Receiver 在 `scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>)` 处进行处理。

甚至 Receiver 这一步处理中，你选择将 URL 里的 data 直接读取再转存，会再增加数据的体积。

---------------------

另外因为每个 Documents/Inbox 是有可能因为空间不够，被系统删除。所以正常靠谱点的 App ，如果有需要会将 Inbox 里的文件挪到自己沙盒里设计好的位置。

---------------------

附录：

测试内容：

我这边用了一个 1.53 G 的文件测试。

在分享前：

Sender 占用体积 1.54G ，Receiver 占用体积 300K 。
iOS 可用空间比之前少了 1.5G 左右，符合两个应用加起来的体积。

在分享后：

Sender 占用体积 1.54G ，Receiver 占用体积 1.53G 。
iOS 可用空间比之前少了 3.1G 左右，符合两个应用加起来的体积。

@AceRacer 自己看代码去调试吧……

https://github.com/zizicici/Duplicator

@zhigang1992 @dilidilid 作为 iOS App 开发，稍微解释一下我的看法吧。

当文件通过分享过来的时候，使用 AppDelegate/SceneDelegate 来管理周期的 iOS 应用，使用的是类似 application(_:open:options:) 方法来响应，这一步系统会传来一个 url ，然后接收方可以通过这个 URL 来读取文件的 Data 。

但是在 OP 举的这个例子里，市面上正常点的 PDF 阅读器，都会把 Data 保存为 PDF 格式到自己的沙盒里。除非有谁写了接收 PDF 分享过来，但是不做持久化保存，只存在内存里。

所以一般情况下会增加。

---------------

这个问题还可以延展出来，比如开发者也许可以保存系统提供 URL 到数据库里，以供下次使用？我个人是不建议。因为这个 URL 可能系统重启了就没了。

@1145148964 系统不会管你沙盒里两份文件是不是一样的。不存在什么去重。

作为一个 App 开发者和一个搬家喜欢装箱子的来说一下。

你这个想法感觉是个很典型的算法题目啊。

但不管是商业上还是日常生活里，一般涉及到：在更大的箱子里装小箱子。感觉最佳实践都是优先使用统一的固定尺寸的小箱子，而且对这些箱子的置放方向与堆叠载荷都是有明确要求的。这种时候都不太需要用到 App 。

唯一能想到用途的就是快递企业了。

一般情况下会增加，因为这相当于文件从一个 App 的沙盒，传到了另外一个 App 的沙盒里。