@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 的沙盒里。

你这样子倒像是真的拷贝过敏感数据。

我和你说，节假日赶不上车时人生经验之一……

虽然这次体验到了下次也还会体验就是了……

明明连十年后的事情都看不出来，却敢问更大的维度……

好家伙，年化 2236%，做梦呢……

我有年化这么高的途径，我有空就去借钱了，哪里有时间在论坛当高手回复你，对我有什么好处。

看了一些官方宣传视频和稿件，大概搞懂了最终呈现的效果了。

你可以给一个邮箱，个人的预期是大概一周内可以出一个 TF 包，到时候可以给你测试用。

@FFFMML 那有你觉得比较好的讲诉三星画壁功能的帖子或者视频吗？

我并没有三星电视，想高仿都不知道要仿什么细节。希望你可以提供更多信息，我可能可以做一做。

当然，你也可以考虑使用 Photo 播放特定你上传的相册。