1. 项目概述一个被低估的开发者“清道夫”如果你是一名开发者尤其是长期在 macOS 或 Windows 上使用 Xcode 进行 iOS/macOS 开发的同行那么你的硬盘空间一定经历过被 Xcode 无情吞噬的恐惧。动辄几十 GB 的 DerivedData、Archives、DeviceSupport 文件夹就像房间里看不见的灰尘日积月累悄无声息地占满了宝贵的 SSD 空间。手动清理不仅繁琐还总担心误删了重要文件。今天要聊的这个开源工具——wookat/DevCleaner就是专门为解决这个痛点而生的。它不是什么复杂的框架或库而是一个功能纯粹、界面直观的“清道夫”核心任务就是帮你安全、高效地清理 Xcode 开发过程中产生的各种缓存和中间文件释放硬盘空间。我第一次接触 DevCleaner 是在一个项目归档后发现 Mac 的剩余空间突然告急用系统自带的存储管理一看Xcode 相关文件竟然占了近 100GB。手动进入~/Library/Developer/Xcode目录下面对DerivedData、Archives、iOS DeviceSupport等文件夹一时不知从何下手哪些能删哪些正在被使用心里完全没底。DevCleaner 的出现就像给这个混乱的仓库装上了智能分类和过期标识系统。它不是一个简单的rm -rf命令封装而是深度理解了 Xcode 的工作流能够智能识别哪些缓存是陈旧的、哪些归档文件是可以安全移除的、哪些设备支持文件是针对早已不再使用的 iOS 版本的。这个工具特别适合所有 Apple 平台iOS, macOS, tvOS, watchOS的开发者无论是独立开发者还是团队中的一员。对于使用 Intel 或 Apple Silicon Mac 的用户它都能完美适配。它的价值在于将“清理”这个日常维护动作从一项充满不确定性的手工劳动变成了一个可信任的、一键式的自动化流程。接下来我们就深入拆解它的设计思路、核心功能以及在实际使用中积累的那些宝贵经验。2. 核心功能与设计哲学解析2.1 靶向清理理解 Xcode 的“垃圾”产生机制要有效清理首先得知道“垃圾”从哪来。DevCleaner 的设计建立在对 Xcode 工作流的深刻理解之上。它主要瞄准以下几个“重灾区”DerivedData派生数据这是最大的空间占用者。每当你在 Xcode 中编译Build一个项目时生成的中间文件如编译后的对象文件、索引、日志等都会存储在这里。每个项目、每个编译配置Debug/Release都会生成独立的子文件夹。问题在于即使你很久没打开某个项目它的 DerivedData 依然会留在硬盘上。DevCleaner 可以识别出哪些项目的 DerivedData 最近没有被访问过从而建议清理。Archives归档文件当你使用Product - Archive为应用打包准备上传到 App Store Connect 或进行分发时Xcode 会在这里生成.xcarchive文件。每个归档都包含应用的二进制文件、符号文件dSYMs以及所有资源。对于已经成功上传并发布或者仅用于临时测试的归档保留它们只会白白占用空间。DevCleaner 可以列出所有归档并显示其创建日期和包含的应用版本信息方便你决策。iOS/tvOS Device Support设备支持文件当你将真机设备连接到 Mac 进行调试时Xcode 会自动下载该设备 iOS/tvOS 系统版本对应的符号文件和调试支持文件。如果你经常测试不同版本的设备这里很快就会积累多个版本的庞大文件每个版本可能高达数 GB。对于你已经不再测试或开发的旧系统版本例如 iOS 14.x, 15.x这些文件完全可以删除。旧版模拟器运行时Old Simulator Runtimes与 Device Support 类似模拟器也会下载不同系统版本的运行时文件。在升级 Xcode 或不再需要测试旧系统后这些文件可以移除。DevCleaner 的设计哲学是“安全第一信息透明”。它不会在你不知情的情况下删除任何文件。它的界面更像是一个详细的报告仪表盘清晰地展示每一类文件占用的空间大小、具体包含哪些项目或版本并由你来做最终的决定。这种设计把控制权完全交给了用户消除了对自动化工具“乱删东西”的恐惧。2.2 工具选型与架构亮点DevCleaner 是一个用 Swift 编写的原生 macOS 应用这带来了几个天然优势性能与体验直接调用 macOS 原生框架如FileManager文件扫描和大小计算速度快界面响应流畅符合 macOS 应用的设计规范。安全性通过沙盒机制和明确的用户权限请求如访问~/Library目录确保了操作的安全性。它只读取和删除自己扫描到的、用户明确勾选的文件不会触及系统或其他应用的核心区域。开源透明其代码托管在 GitHub任何人都可以审查其清理逻辑确保没有恶意行为。这对于涉及文件删除的工具来说是建立信任的关键。在架构上它采用了典型的 MVC 模式但针对文件扫描这一核心耗时操作做了优化。扫描任务被放在后台线程执行避免阻塞 UI。扫描完成后它会使用高效的算法汇总各个目录的大小并以人类可读的形式GB/MB展示出来。一个值得称道的细节是它在计算大小时会利用文件系统的元数据避免重复遍历这在处理数十万个文件时显著提升了速度。注意虽然 DevCleaner 非常安全但任何删除操作都是不可逆的。在首次使用或清理大型归档前建议先通过 Time Machine 或其它备份工具对重要数据进行备份这是一个良好的操作习惯。3. 实操指南从安装到精准清理3.1 获取与安装的几种途径DevCleaner 提供了多种安装方式适合不同习惯的开发者Homebrew推荐这是最快捷、最便于管理升级、卸载的方式。如果你已经安装了 Homebrew只需在终端中执行一行命令brew install --cask devcleaner通过 Homebrew Cask 安装应用会被直接放置在/Applications目录下就像从官网下载一样。手动下载访问项目的 GitHub Releases 页面下载最新的.dmg磁盘映像文件。打开后将 DevCleaner 应用图标拖拽到“应用程序”文件夹即可。Mac App StoreDevCleaner 也在 Mac App Store 上架。这种方式的好处是能自动更新但版本更新可能会比 GitHub 版本稍慢一些且需要经过苹果审核。我个人强烈推荐使用 Homebrew 安装因为它能与你的开发者工具链无缝集成更新时一句brew upgrade就能搞定所有通过 Homebrew 安装的工具和应用。3.2 首次运行与界面详解首次启动 DevCleaner它会立即请求访问~/Library/Developer/Xcode文件夹的权限。你必须点击“好”或“允许”否则工具无法扫描到任何内容。授权后它会开始首次扫描界面主要分为以下几个区域侧边栏列出了四大清理类别 - Derived Data, Archives, Device Support, Simulator Runtimes。点击任一类别主区域会显示详细信息。主信息面板顶部显示该类文件的总大小和项目数量。例如“Derived Data: 45.8 GB (来自 18 个项目)”。文件列表这是核心区域。以 Derived Data 为例它会列出每个项目名称、路径和占用空间。最关键的是每个条目前面都有一个复选框默认全部未勾选。你需要手动勾选想要清理的项目。列表通常按占用空间大小降序排列让你一眼就能看到“大户”。底部操作栏显示当前勾选项目的预估释放空间以及一个醒目的“Move Selected to Trash”将所选项目移至废纸篓按钮。注意它默认是“移至废纸篓”而不是直接永久删除这给了你最后一道保险。3.3 分步清理策略与实战演示最有效的清理不是一次性全选而是有策略地进行。下面是我的常规清理流程第一步清理 Derived Data这是最安全、收益也往往最高的一步。我会按照以下策略勾选勾选所有超过一个月没有打开或编译过的项目。勾选那些已经归档或不再活跃的个人实验项目。保留最近一周内正在活跃开发的项目避免重新编译时浪费时间。例如列表显示一个名为“OldPrototype_2023”的项目占了 3.5 GB上次修改日期是去年果断勾选。而当前正在攻坚的“MainProject”虽然也占了 2.1 GB但日期是昨天则保留。第二步清理 Archives进入 Archives 标签页。这里的信息非常有用它会显示归档的应用名称、版本号和创建日期。勾选所有已经成功上传到 App Store Connect 并完成发布的归档。通常保留最近一次提交的归档用于可能的回退或调查即可。勾选那些仅为临时测试生成的 Ad Hoc 或 Development 版本归档。谨慎对待如果你需要为已上架的应用排查历史崩溃报告那么对应的 dSYM 文件在归档里。确保你已有这些 dSYM 的备份例如已上传到崩溃报告服务如 Firebase Crashlytics或者确认不再需要它们。第三步清理 Device Support 和 Simulator Runtimes在 Device Support 中查看 iOS/tvOS 版本。如果你和你的测试团队已经全面转向 iOS 17 和 18 进行开发和测试那么可以安全地勾选删除 iOS 15.x, 16.x 的支持文件。每个旧版本都可能释放出 2-5 GB 的空间。Simulator Runtimes 同理。如果你在 Xcode 的 Devices and Simulators 窗口中已经删除了旧的模拟器那么对应的运行时文件在这里也可以清理掉。执行清理 勾选完毕后查看底部预估的释放空间比如 68.4 GB然后点击“Move Selected to Trash”。此时这些文件会被移动到系统的废纸篓。你需要手动清空废纸篓才能真正释放磁盘空间。这再次体现了其安全设计。4. 高级技巧与自动化配置4.1 使用命令行进行自动化清理对于喜欢自动化或需要在 CI/CD 环境中定期清理的开发者DevCleaner 提供了强大的命令行工具。安装后你可以在终端中直接使用devcleaner命令。几个实用的命令示例查看可清理项模拟运行在删除前先查看有什么可以清理这是一个好习惯。devcleaner list这会输出一个类似 GUI 界面的文本报告列出各类别中可清理的项目和大小。仅清理 Derived Data如果你只想快速清理编译缓存。devcleaner cleanup --category derived-data默认情况下cleanup命令会直接删除文件而不是移到废纸篓。使用前请务必确认。清理除指定项目外的所有 Derived Data这是一个非常实用的场景保留当前正在开发的项目缓存。devcleaner cleanup --category derived-data --keep-recent 7d --exclude “MyCurrentProject”这个命令会清理超过7天未访问的 Derived Data但排除名为“MyCurrentProject”的项目。清理特定版本之前的 Device Supportdevcleaner cleanup --category device-support --ios-before 16.0这将清理所有 iOS 16.0 版本之前的设备支持文件。自动化脚本示例 你可以创建一个每周运行的 cron 任务或 LaunchAgent自动清理旧的缓存。例如创建一个脚本~/scripts/clean_dev_cache.sh#!/bin/bash # 清理超过30天的 Derived Data 和 Archives但保留最近3个归档 devcleaner cleanup --category derived-data --keep-recent 30d devcleaner cleanup --category archives --keep-latest 3然后通过crontab -e添加定时任务0 2 * * 0 /bin/bash ~/scripts/clean_dev_cache.sh /tmp/devcleaner.log 21这将在每周日凌晨2点执行清理并将日志输出到文件。重要提示在 CI/CD 环境如 GitHub Actions, Jenkins中使用时务必仔细测试命令参数并确保不会删除构建过程中正在使用或后续步骤需要的文件如用于符号化崩溃报告的 dSYM 归档。4.2 与 Xcode 使用习惯的深度结合要让 DevCleaner 发挥最大效用需要调整一些 Xcode 使用习惯规范项目命名Derived Data 中的文件夹名称通常基于项目路径生成。如果你的项目名称含糊不清如Test1,Demo在 DevCleaner 的列表中会很难辨认。使用清晰的项目名能让你在清理时快速做出判断。利用 Archive 的注释功能在 Xcode 中创建归档时可以填写注释如“App Store Release v1.2.3”。这个注释会在 DevCleaner 的 Archives 列表中显示帮助你识别归档的用途。定期清理习惯不要等到硬盘报警才想起来清理。可以设定一个每月或每季度的日历提醒花5分钟运行一下 DevCleaner 进行检查。养成习惯后它能帮你始终保持开发环境的清爽。5. 常见问题排查与使用心得5.1 典型问题与解决方案即使工具设计得再完善在实际使用中也可能遇到一些小问题。下面是一些常见情况及应对方法问题现象可能原因解决方案DevCleaner 扫描不到任何内容列表为空。1. 未授予磁盘访问权限。2. Xcode 的开发者目录不在默认位置~/Library/Developer。1. 检查系统设置 - 隐私与安全性 - 文件与文件夹确保 DevCleaner 有权限访问~/Library/Developer目录。如果没有可能需要卸载并重装应用以重新触发授权。2. 如果自定义了 Xcode 的 Derived Data 或 Archives 路径在 Xcode - Locations 中设置DevCleaner 可能无法识别。目前 DevCleaner 主要扫描默认位置这是一个已知限制。点击“Move to Trash”后空间没有释放。文件只是被移到了系统废纸篓并未永久删除。前往 Finder右键点击“废纸篓”选择“清空废纸篓”。请注意清空后文件将无法恢复。清理了某个项目的 Derived Data 后下次打开 Xcode 编译该项目变慢了。这是预期行为。Derived Data 包含了项目的索引和编译中间文件清理后 Xcode 需要重新生成这些文件因此首次编译会较慢。后续编译速度会恢复正常。对于正在频繁开发的核心项目可以在清理时将其排除通过命令行--exclude参数或在 GUI 中不勾选。命令行工具执行cleanup命令时报错或无效。1. 命令参数错误。2. 命令行工具版本与 GUI 应用版本不匹配。3. 没有足够的权限。1. 使用devcleaner --help查看正确的参数格式。2. 确保通过同一渠道如 Homebrew更新了 CLI 工具。3. 尝试使用sudo运行但需极其谨慎并确保命令无误。5.2 个人实操心得与避坑指南经过长期使用我总结了几条非常重要的经验“归档”清理的黄金法则对于已经提交到 App Store Connect 的归档在清理前务必确保对应的 dSYM 文件已经上传到你的崩溃报告收集系统如 Firebase Crashlytics、Bugly 或 Apple 自己的 App Store Connect 中的崩溃报告模块。dSYM 是符号化崩溃日志的关键一旦丢失历史崩溃报告将变得难以解读。一个安全的做法是在 Xcode 的 Organizer 窗口中选中归档后使用“Download Debug Symbols”功能下载 dSYM 并备份或者使用脚本在归档后自动上传 dSYM。Device Support 的版本管理策略不要一味追求清理得越干净越好。考虑到测试机型的多样性建议至少保留当前 iOS 主要版本的上一个版本和当前版本的支持文件。例如如果当前主流是 iOS 17那么保留 iOS 16 和 17 的支持文件。这样当需要复现一个仅在旧版本系统上出现的 Bug 时你不需要重新下载数 GB 的文件。模拟器运行时清理的联动在 DevCleaner 中清理了 Simulator Runtimes 后记得去 Xcode 的 “Devices and Simulators” 窗口Window - Devices and Simulators中检查一下。有时那里可能还会显示已被删除运行时的模拟器状态会是不可用。你可以在这里将其删除保持列表整洁。空间告急时的急救流程如果硬盘空间突然爆满影响系统运行可以按以下优先级使用 DevCleaner 快速释放空间第一优先级清理所有Archives确保 dSYM 已备份。第二优先级清理Derived Data中除当前项目外的所有内容。第三优先级清理Device Support中最早的两个大版本如 iOS 14, 15。 这个组合拳通常能快速释放出数十 GB 的空间。不要完全依赖自动化虽然命令行工具很适合自动化但我建议至少每月一次打开 GUI 版本进行一次“人工复核”。图形界面提供的详细信息如项目名、归档版本、日期能帮助你做出更精准的判断避免自动化脚本因规则不当而误删重要文件。人眼检查是最可靠的最后一道防线。DevCleaner 就是这样一款工具它不炫技功能专注但恰恰解决了开发者一个持久、真实且高频的痛点。它通过透明、安全的设计将一项繁琐且有风险的系统维护工作变成了一个简单、可控的日常操作。将它纳入你的开发工具链就像为你的工作环境请了一位沉默而高效的管家让你能更专注于代码本身而不是与硬盘空间搏斗。