百度 APP iOS 端磁盘优化实践（上）
01 概览
在 APP 的开发中，磁盘管理已成为不可忽视的部分。随着功能的复杂化和数据量的快速增长，如何高效管理磁盘空间直接关系到用户体验和 APP 性能。本文将结合磁盘管理的实践经验，详细介绍 iOS 沙盒环境下的文件存储规范，探讨业务缓存、用户资产及系统缓存的清理策略。同时，分享自动清理与手动清理相结合的机制，展示如何在不同触发条件下合理执行磁盘清理。文章使用文心一言辅助编写。
02 磁盘系统介绍
2.1 ios 沙盒系统
沙盒机制是 iOS 系统中的一种安全体系。每个 iOS 程序都有一个独立的文件系统，而且只能在对应的文件系统中进行操作，此区域被称之为沙盒（SandBox）。APP 中所有文件都保存在此，如文本文件、图片、图标、媒体资源、Mach-O 等。主要包含 4 个目录 MyApp.app、Documents、Library、tmp。
MyApp.app 目录包含应用程序及其所有资源，即.ipa 安装包解压后的.app 内容，仅支持只读访问。Documents 目录用于存储用户生成的内容，可以通过文件共享提供给用户，并由 iCloud 备份。Library 目录则用于存放非用户数据文件的顶级目录，通常包含几个标准子目录，如 Application Support 和 Caches，并由 iCloud（Caches 除外）备份。而 tmp 目录用于写入临时文件，这些文件不需要在应用程序启动之间保留，当不再需要时应由应用程序删除，且不被 iCloud 备份。
2.2 获取目录 API
NSSearchPathForDirectoriesInDomains()函数用于查找目录，返回指定范围内的指定名称的目录的路径集合。
2.3 文件存储规范
iOS 项目开发中，文件管理至关重要。我们结合 Apple 官方指导与项目实践，形成了一套详细的文件使用规范。这些规范不仅遵循了 iCloud 备份策略，还充分考虑了文件类型特性和业务需求。结合业务使用场景，能够更准确地判断哪些文件是临时数据、哪些是用户生成的重要文件，为后续进行磁盘监控和清理提供了便利。
MyApp.app：
用途：应用程序的包，此目录包含应用程序 Mach-O 可执行文件及其所有资源，iCloud 默认不备份此目录。
使用规范：
开发者不能写入此目录。写入此目录会影响签名导致 APP 无法启动。
开发者可以获得对应用程序包中存储的任何资源的只读访问权限。
Documents：
用途：存储用户生成的内容的顶级目录，iCloud 默认备份此目录。
使用规范：
该目录应仅包含开发者可能希望向用户公开的文件。
Documents/Inbox：
用途：存储通过外部共享方式导入到 APP 的文件，iCloud 默认备份此目录。
使用规范：
开发者不应自行在此目录下创建文件。
开发者可读可删，将此目录中文件移出后再编辑。
Library：
用途：存储非用户数据文件的顶级目录，iCloud 默认备份此目录（Caches 除外）。
使用规范：
可以创建自定义子目录，用于保存不向用户公开的任何文件。
各业务方需要创建业务相关的子目录存储数据。
Library/Caches：
用途：用于存放再次下载或重新生成的数据，iCloud 不会备份此目录。
使用规范：
存放可以重新下载或生成的数据，如图片缓存文件、临时文件等。
系统在系统储存不足时可能会删除该目录以释放磁盘空间。
各业务数据缓存文件应放在/Library/Caches 的子目录下，方便管理。
Library/Application Support：
用途：用于存储 APP 配置和数据文件，iCloud 默认备份此目录。
使用规范：
存放程序配置和数据文件，如配置文件、模板等，不应存放缓存文件。
避免在此目录下创建不必要的文件，以减少备份时间和存储空间占用。
Library/Preferences：
用途：用于存储应用程序的首选项值，iCloud 默认备份此目录。
存放建议：
开发者不应自行在此目录下创建文件。
NSUserDefaults 或 CFPreferences 来获取和设置 APP 的首选项值。
tmp：
用途：用于存放临时数据，iCloud 不会备份此目录。
存放建议：
仅存放临时数据，开发者应在使用完这些文件后及时删除。
系统会清除目录下文件，应用程序终止后可能不存在。
不推荐业务方使用此目录存放重要数据。
2.3.1 文件命名规则
文件夹命名推荐 Pascal 命名法，第一个字母大写。
一个业务最多 3 个二级路径：
业务数据放在 Library/下的一个目录下。
数据缓存文件放在 Library/Caches 的一个目录下。
用户数据放 Documents/下的一个目录下。
2.3.2 iCloud 备份与恢复
iCloud 会默认同步 Documents、Library 目录下的文件（Caches 子目录除外），用户在设置中开启 iCloud 同步功能，同步 APP 数据时会上传所有沙盒数据。如果没有按照规范创建目录，会导致大量缓存文件被上传到 iCloud，严重占用用户 iCloud 空间，严重时甚至会被 Apple 官方警告。如果将数据写入这些目录，但是又不希望同步到 iCloud，iOS 提供了 API 可以排除默认同步的目录，需要开发者在创建文件时主动设置。
由于无法查看 iCloud 备份的沙盒文件内容，使用 Mac 本地备份的方式模拟 iCloud 备份行为。iPhone 连接 Mac，打开访达，选择将数据备份到 Mac，恢复备份。测试发现 Document 文件夹下的子目录和子文件，属性被设置为 NSURLIsExcludedFromBackupKey，恢复备份后不在，符合预期。不过用电脑备份和 iCloud 有个差异，Library/Caches 下的文件也会被备份。
注意：此方法对于在 App Store 的应用，即使在恢复备份前将 APP 删除，也会在恢复备份后自动下载 APP，并且恢复数据。对于不在 App Store 的应用，比如我们的测试 DemoAPP，在恢复备份前不要删除 DemoAPP，否则无法查看效果。因为无法下载不在 Appstore 的 APP 安装包，所以备份内容也无法还原。测试 APP 在恢复备份后重新安装就可以查看完整的沙盒文件。
API 设置对于性能的损耗：
iPhone12 ：总计 14780 个文件，总计耗时 1124.180794 ms，平均每次耗时 0.076ms
iPhone6p：总计 11650 个文件，总计耗时 3730.319023 ms，平均每次耗时 0.32ms
NSURLIsExcludedFromBackupKey 不需要每次使用目录或文件时都调用，只需要设置一次即可。设置属性后，该目录下所有子目录和文件都不会同步到 iCloud，但是子目录和文件的属性 NSURLIsExcludedFromBackupKey 依旧为 NO。
创建文件 URL 时需要调用[NSURL fileURLWithPath:] ，然后获取和设置 NSURLIsExcludedFromBackupKey。
2.4 磁盘大小计算方式
在系统中可以查看一个 APP 占用磁盘大小，iPhone 存储空间通常由 APP 大小和文稿数据大小组成。getResourceValue:forKey:error: 或者 attributesOfItemAtPath:error: 直接获取的是“文件大小”，不是文件占用的磁盘物理空间。计算文件的磁盘占用大小需要通过磁盘块的方式。标准头文件 stat.h 的 st_blocks 可以获取到块的数量，st_blocks * 512 计算出文件的磁盘占用大小。 扇区（block）是磁盘读写的最小物理单位。之所以扇区大小是 512 字节，这种做法源自较早的磁盘扇区大小标准。这种设计是基于早期磁盘技术的物理限制，尽管现代硬盘的物理扇区大小可能已经增加到了 4096 字节，但 512 字节的逻辑块大小在许多文件系统和操作系统的接口中仍然被保留。iOS 系统存储单位为十进制，且保留有效小数机制为四舍五入。
2.5 APP 包大小
APP 包大小是手机沙盒的重要组成部分，包体积直接影响用户转化率。用户可以在 iPhone 存储空间设置中查看设备上各 APP 大小和文稿与数据大小。
百度 APP 在 iOS17 系统的 iPhone 存储空间设置中，系统不显示 APP 大小，只有文稿与数据大小。经过调研，发现在 iOS17 系统 APP 使用 ODR 功能后，会导致 APP 大小被计算到了 iOS 系统数据。推测是 iOS17 系统 BUG，iOS18 系统已经恢复正常。
03 磁盘清理
在综合性 APP 的开发中，多个业务方共同使用沙盒空间，磁盘缓存的管理面临诸多挑战。每个业务方对磁盘使用的整体感知较弱，难以准确评估自身的空间占用大小是否合理，磁盘占用很容易出现无限增长的问题。同时，不同业务方可能独立设计了缓存清理策略，缺乏统一规范，难以满足统一管理的需求。
为解决这些问题，从全局出发设计一套高效的磁盘清理方案。这套方案结合自动清理与手动清理的机制，对磁盘使用进行统一管理。自动清理负责监测磁盘占用情况，通过设置清理阈值和判断条件，在空间不足时通知或触发业务方执行清理操作。清理范围以业务缓存为主，支持按业务个性化配置清理规则，确保管理灵活高效。手动清理则面向用户，提供简单直观的操作界面，允许用户自主选择清理范围，管理下载文件等数据，从而平衡自动化与用户自主权。
此外，在 iOS 平台上，系统本身具有定期清理临时文件和部分缓存内容的机制。设计磁盘清理方案时，合理利用这些系统行为，同时避免依赖其不可控性。通过以上策略，可以在确保磁盘空间高效管理的同时，最大限度地保障用户体验，为综合性 APP 提供可靠的存储管理支持。
3.1 自助清理
3.1.1 业务限额
为了管理和规范业务方对磁盘的使用，根据业务的使用场景和必要性，评估每个业务方需要使用的磁盘空间，每一个业务占用的缓存大小会被分配一个限额，业务需要保证自身缓存占用限制在限额以下。业务方从磁盘组件获取业务自身限额值，保证自身缓存占用在限额以内；而磁盘组件会从磁盘剩余大小、APP 已使用大小、业务使用频率等条件实时分配合适的限额给各个业务方。
3.1.2 磁盘等级
根据设备的剩余磁盘空间与应用程序所占用的磁盘空间大小，我们可以将磁盘状态细分 为 Normal、Warning、以及 Critical 三个等级，每个等级都反映了用户磁盘空间的使用状况。当处于 Normal 时，表明用户的手机尚拥有充裕的剩余空间，且 APP 所占用的磁盘空间相对较小。在此情境下，我们可以适度增加分配给各个业务方的限额，使得业务方有机会缓存更多内容，从而实现以空间换取时间的性能优化，进一步提升用户体验。
然而，一旦进入 Critical 等级，意味着用户的手机剩余空间已所剩无几，或是 APP 占用了过多的空间。这种情况下，用户的手机很容易出现卡顿现象，甚至面临存储空间告急的困境。更为严重的是，这可能会迫使用户做出卸载 APP 的极端选择。因此，在 Critical 等级下，我们必须对业务方使用磁盘空间的行为进行严格限制，并强制要求业务方彻底清理任何不必要的缓存，以确保用户的手机能够维持基本的运行需求。
3.1.3 状态检测
磁盘状态检测是磁盘组件的核心功能，检测 APP 运行期间设备磁盘的使用情况，判断是否需要触发自动清理操作。APP 启动后周期性的执行磁盘使用状态检查，自动触发相应的清理机制。通过不同条件触发磁盘清理，以优化应用性能并提升用户体验。为此设计了多种触发清理机制的机制，确保不同情况下都能触发清理操作：
等级：根据磁盘使用等级的变化来决定是否清理；
版本：如果应用版本发生升级，会强制业务方执行一次清理。 时间：根据磁盘等级设定兜底的定期清理间隔。
3.1.4 触发清理
业务方在各自的组件中注册磁盘清理回调 protocol，不同的业务模块能够响应磁盘等级变化并进行相应的处理，实现了磁盘清理服务与业务模块之间的解耦合。业务在收到磁盘状态等级变化时，重新查询业务限额，并调整自身策略，管控和优化自身占用缓存，保证保证自身缓存占用在限额以内。
磁盘组件会逐一调用各业务模块注册的清理回调，通过 protocol 抽象各模块的清理逻辑，实现了对多业务模块的统一管理和扩展性支持。结合信号量机制实现同步等待，确保每个模块的清理任务按顺序完成。所有清理任务完成后，磁盘组件会触发全局回调进行状态更新。
3.2 手动清理
手动清理沿用自动清理的设计思路，业务方实现清理协议，注册到磁盘组件，然后由磁盘组件统一管控。和自动清理不同的是，手动清理提供了一个用户可视化页面，并且详细列出可清理的内容供用户选择。支持深度清理，在大多数情况下，业务逻辑要求清除所有缓存数据。除此之外，还另外添加了用户资产管理功能。
3.2.1 用户资产管理
用户资产定义为用户自主下载并保存的各类文件，包括但不限于视频、图片、安装包、PDF 文档、Excel 表格以及 Word 文件等。百度 APP 是一个综合性 APP ，兼具浏览器的功能。用户在浏览网页的过程中，会下载各种内容。特别是在 iOS 设备上，用户还可能会下载一些无法安装的安装包。尽管这些文件是用户主动下载的，但实际上它们可能并无实际用途，且长期占用用户的磁盘空间。用户资产管理模块可以帮助用户轻松地识别并清理那些不再需要或无效的用户资产，从而有效释放存储空间，提升设备的整体性能。
3.3 系统缓存清理
3.3.1 tmp 目录
iOS 的 tmp 目录是系统缓存目录，Apple 官方文档的说明是使用此目录写入不需要在 APP 启动之间保留的临时文件。当不再需要文件时，APP 应从该目录中删除这些文件，系统也可能会在 APP 未使用时清除此目录。实际使用过程中发现，依赖系统清理该文件夹具有不可控性，因此需要对该文件夹进行清理，tmp 目录主要包含以下文件：
1. 下载缓存文件
NSURLSessionDownloadTask 进行文件下载的过程中，系统为了确保数据的完整性和安全性，会在文件下载完成前，将其暂时保存在以.tmp 为扩展名的临时文件中。这些临时文件的命名遵循 CFNetworkDownload_xxxx.tmp 的格式，其中 CFNetworkDownload_是固定的前缀，而后续的 xxxx 部分则根据每个下载任务的不同而有所区别。
NSURLSessionConfiguration 配置会导致这些临时文件被存储在沙盒的不同位置。defaultSessionConfiguration 创建的下载任务，其临时文件会被保存在沙盒的 tmp 文件夹内。backgroundSessionConfiguration，临时文件的存储位置则有所不同。在后台下载模式下，为确保即使应用进入后台，下载任务也能继续进行。这些文件会存放在 Library/Caches/com.apple.nsurlsessiond/Downloads/<bundle_id>。
然而，需要注意的是，沙盒中的 tmp 文件夹主要用于存放临时文件，这些文件在磁盘空间不足时可能会被系统自动清理。因此，如果下载任务被取消，且临时文件没有被及时移动到其他安全的存储位置，它们可能会因为 tmp 文件夹的清理机制而被删除。这将导致用户无法从上次中断的位置继续下载，即无法实现断点续传。
2. tmp 目录清理
统计 tmp 目录下可以被清理的文件，可以选择全部清理，也可以按照业务实际应用场景，选择过期清理等方案。
3.3.2 WKWebView 清理
WKWebView 是 iOS 和 MacOS 上用于加载和展示网页内容的控件，它利用了多种缓存机制来提升加载速度和用户体验。以下是 WKWebView 缓存产生的几个主要原因：
资源缓存（HTTP 缓存）：WKWebView 会缓存通过网络请求加载的网页资源（如 HTML、CSS、JS、图片等），以减少重复下载，提升网页的加载速度。这些资源通常存储在本地磁盘上。
Cookie 缓存：网站使用的 Cookie 会被 WKWebView 缓存，用于维护会话状态、用户登录信息等。
Session Storage 和 Local Storage：WKWebView 支持 HTML5 的 sessionStorage 和 localStorage，用于本地存储网站数据，以便后续访问时能够直接从缓存中读取，而无需重新下载。
WebKit Cache（WebKit 内部缓存）：WebKit 内部有一套复杂的缓存系统，用于管理各种网页资源、脚本、图像等的缓存。WKWebView 依赖这些机制来加速网页内容加载。
Service Workers 和离线缓存：一些网页使用 Service Workers 来实现离线功能或加速加载特定资源，WKWebView 会缓存这些资源，以便在后续使用时能够从本地获取。
1. WKWebView 缓存清理方法
清理指定数据类型的缓存：通过 WKWebsiteDataStore 可以清理特定类型的缓存，比如 Cookies、缓存、localStorage 等。该方法可以清理指定类型的缓存数据，并支持自定义时间范围。以下代码展示了如何清理 WKWebView 的缓存数据：
清理指定域名的数据如果只想清理某个特定网站的缓存，可以通过查询 WKWebsiteDataRecord 来实现：
2. WKWebView 清理实践
在 WKWebView 的清理实践中，先计算 NetworkCache 文件夹的大小，一旦超过设定的限制即会触发清理流程。在清理过程中，为了保证缓存带来的性能优化和磁盘空间占用达到平衡，我们并没有选择全部删 WKWebView 的所有缓存，而是按照文件的修改日期进行排序，确保最老的文件在后续的清理中会被优先处理。
3.3.3 dyld 缓存清理
dyld 是 iOS 和 MacOS 系统中的一个关键组件，负责在程序启动时加载和链接动态库（如框架和共享库）。在 iOS 13 及更早版本中，dyld 可能会在 tmp 目录下创建一些临时缓存文件，用于加速后续的程序启动过程。这些缓存文件包含了动态库的加载信息，使得系统在下次启动相同程序时能够更快地找到并加载所需的库。
然而，iOS13 系统之前会在每次 APP 升级后的首次启动生成一个新的 dyld 缓存，保存在 tmp/com.apple.dyld，并且之前的 APP 版本的 dyld 缓存也不会自动删除。该部分缓存会随着版本升级不断累加，需要管理这部分缓存，实际上还有部分用户从 iOS13 系统升级到更高系统，这部分缓存就会一直遗留在用户手机中，高达上百 MB。iOS14 系统则是迁移到了 Library/Caches/com.apple.dyld，且系统会自动清理。
3.3.4 其他系统缓存清理
Documents/Inbox 是 iOS 应用接收文件的默认目录，直接清理即可；
Library/Preferences 目录下属于应用的临时 .plist 文件。这些文件通常由 NSUserDefaults 自动生成，有时在写入或更新过程中会生成临时文件。
04 总结
本篇文章围绕百度 APP 的磁盘清理问题，从 iOS 沙盒文件存储机制出发，系统性地阐述了磁盘管理的重要性和技术实现。文章探讨了自动清理与手动清理的结合策略，通过多维度触发机制和灵活的用户交互设计，平衡了系统性能与用户体验。后续我们还会分享磁盘监控和磁盘异常问题治理相关的文章。
————END————
推荐阅读
如何定量分析 Llama 3，大模型系统工程师视角的 Transformer 架构
百度官方技术账号 2021-01-22 加入
关注我们，带你了解更多百度技术干货。
评论