ios 在不同 app 之间分享文件会不会增加设备占用空间？

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

应该是会的

即使是一楼说的情况。我记得 ios 存储系统是有去重的

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

APFS 在文件系统层级 Copy-on-Write 。 是不会占用更多空间的，只有在修改文件内容的时候会 Duplicate 一份再修改

同疑惑，因为删掉一个 app 里的文件，对另一个 app 无影响

beimenjun 的说法是错误的，APFS 作为 CoW 文件系统支持 copy by reflink ，这跟去重是两码事。如果从外部往 APFS 里复制两个一样的文件 APFS 是不会自动触发去重的所以会增加占用，但在 APFS 里内部复制是不会增加空间占用的，即使后续有修改操作也只增加修改部分的体积，这个 feature 是在引入 APFS 的时候专门强调的优点

@zhigang1992 修改文件内容只会增加 modified content 对应的 block ，并不会整个文件 duplicate

APFS （ macOS 、iOS 等 Apple 设备使用的文件系统）支持 Clones 和拆分编码（增量编码，Delta encoding ）。

> Clones allow the operating system to make efficient file copies on the same volume without occupying additional storage space. Changes to a cloned file are saved as delta extents, reducing storage space required for document revisions and copies.
https://en.wikipedia.org/wiki/Apple_File_System

我记得 APFS 和 iOS 的内存管理有点像，有类似的引用计数功能来去重

微信:我不管，我就复制多一份

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

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

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

所以一般情况下会增加。

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

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

@dooogle 可不止多一份

不会，iOS10 引入了 apfs 解决了你说的这个问题，你可以试一下 iOS9 的老机器分享个大文件去 QQ 或者微信，再弹出分享界面之前是要有一段时间没反应的，就是在复制文件，iOS10 之后就不需要了

删除的时候呢？还保留了一份啊

@beimenjun 你这 iOS 开发技术不过关呀，是两个相同的文件，但是只占一份存储空间 https://sspai.com/post/38377

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

https://github.com/zizicici/Duplicator

@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 左右，符合两个应用加起来的体积。

@beimenjun 你是正确的，这些科技自媒体乱写文章误导人，mac 端还有 iPhone 自带的一些应用内部是共用的，三方 app 直接还是独立的拷贝,你是专业的 iOSer

@beimenjun 支持你，很多人空对空分析一大堆，和实际情况具体场景相差十万八千里