Xcode 就是毒瘤，是内存杀手，是硬盘杀手

虽然 Xcode 是很烂，但内存不用拿来做什么呢？

如果不想让用这么大内存就买个 8G 的，它想用也用不了。既然买了大内存，还不让用。你说你是不是有点大病

@dorentus @deplivesb 这种调调是病，得治。
用不用是系统根据用户意愿决定的事，多任务系统下什么时候轮得到你一个小小的用户空间应用来显摆了？
你个应用说，我要完成的任务占用存储天生下限就高，不给够我就罢工，那行。但你个 xcode 是什么牛鬼蛇神，完成的那么点任务，也配上来随随便便就吃个几 G ？真当自己是在整 Chromium 的 ld+lto1 了？
退一步讲，你要是给服务端应用做极端吞吐量上的优化，开起来以后就不打算动，那也就罢了；偏偏这就是时刻要求维护系统响应的典型客户端环境。
“内存不用拿来做什么”，哦，你 xcode 是用户脑子里的寄生虫，知道用户不用立即多运行其它占用巨大运存的程序？万一不够用开不起来了或者被迫 swap 卡翔了，浪费的操作和时间你 xcode 赔，还是说用户活该用你 xcode ？

同理适用大多数 JVM 上的客户端应用，以及 Linux 有大病的默认 OOM killer 配置。（所以 xcode 就更拉胯了；明明苹果都知道 GC 和超卖 OOM 的下场，所以还刻意强调了 ARC 如何优越，作为门面的开发工具却还这般耍无赖。）
病不治的后果就是以后随便哪个系统上来多开个应用就卡翔成低端 Android ，可用空间真快完了又各种抽风；或者就是 iOS 的相机 app 一出，别的后台应用就该想着怎么“保活”了。
（虽然这不表示其它抽风的可能性不存在，例如 Win32 快 OOM 了 GDI 直接整不出来字，注销都没用。）

xcode 有比较大的内存泄漏，放个几天会占用 20g+的内存，得定期重启一下

你需要的不是 Xcode ，是 vscode 或者 appcode 而已。

@FrankHB 你仔细看看我发的图，有没有发觉里面 Xcode 占用的内存相对比较小？有没有想过是因为什么？

Xcode 不是“一个小小的用户空间程序”，它是一个(可能有内存泄露的)包含了相当多组件的集成开发环境。

“内存万一不够用怎么办”这个是操作系统需要考虑的事情，天天用人脑思考机器应该做的事且过分纠结要么是强迫症，要么是太闲，得治。

硬盘就吃了十几 g ，

@deplivesb 但是啥也不干就占这么多，肯定不正常呀。如果是微信上来就占满内存，你开心吗

@dorentus “小小”的用户空间程序，首先说的是存储所有权和默认优先占用运行时资源的地位。不论相对内核还是用户，它就应该保持卑微。做了显然违反用户需求的事，而用户没有误操作，那就该出来挨骂。
因为没有资格僭越用户的需求，任何用户空间程序在没有明确得到授权或请求时，在多任务系统上就应该保持保守占用资源。这是本分。

你的截图中的 2G 多的占用相对 OP 的例子看似不过分，但考虑 xcode 干的事，已经开始离谱了。
xcode 调用的真正干活的必要开发工具（编译器和链接器之类），乃至一些分析工具，都是单独开进程占用资源的，而要编译链接占 2G 多的规模程序的项目已经不算小了。对这种体积的项目来说，相比之下，devenv 分析完同时开几十个文件稳定占用也不过几百 M （这还包括没通过 clangd 之类另外的进程外包出去的活）；所以即便只是个开始，也至少说明 xcode 很拉胯。
并且，这不支持你的观点。你说“不用拿来做什么”，言下就是在你这 xcode 用得还不够多。OP 遇到的状况反而还比你完善一点；但是，体验毫无疑问地糟糕。

所谓“内存万一不够用怎么办”这就不可能只是操作系统需要考虑的事情，因为操作系统没有道德义务也没有技术能力对犯傻没下限的应用负责。可见的未来，操作系统不可能智能到真正区分出一个应用到底是确实需要分配资源还是有很大嫌疑占着茅坑不拉屎，因为这涉及对任务内容的主观价值判断，而瞎判断 OOM 乱杀任务的问题上面已经说了；所以哪个任务占用过多哪个任务欠杀，必须依赖用户的决断。
（若有不服，你可以先搞出一个带有强人工智能保证不会比现在的人类用户误判更多的操作系统实现来试着让和你观点不同的用户闭嘴。）
操作系统能做的也就是提供简便的接口放权给用户（顺便，这也是 Android 和 iOS 做的比几乎所有桌面系统更烂的地方），反过来用户同样有义务了解这个局限性，清楚不被信任的任务可能被干掉。
一般意义上，操作系统的用户包含应用和最终用户，无论是应用占用资源的策略还是最终用户选择是否启动并容忍任务对资源的占用，都是人（应用开发者或者最终用户）在根据任务自身的是否有理由继续存在的主观判断直接或者间接地作出决定，而不是机器的思考。不管是开发者还是最终用户，放弃行使这种权利理应后果自负；你所谓的“太闲”，不管出发点是什么（基于对机器能力的蜜汁自信，或者对人类用户的权利的蔑视），完全是颠倒黑白，可以说非蠢即坏，并不冤枉。

顺便，历史上，乔布斯是一贯蔑视消费产品的最终用户对和自己不同的产品方面理解的能力的，最好用户都是傻子。但 xcode 作为一个用户不能太傻的开发工具，苹果还没好意思把逻辑一起贯彻上。
你是想进一步教苹果做产品么？那么第一步，你看来就不该承认内存泄露的 bug ，而是说，这是 xcode 的伟光正开发者决定的 feature 的一部分，至于具体是什么你们最终用户不配管，爱用用不用润。

就因为 xcode 资源占用太大，我一直在考虑用 pyobjc 之类的开发带 GUI 的自用工具，而不是 swift 或者 objc

@FrankHB 是的，占内存没问题，但不能泄露呀。Xcode 是一个开发工具，使用者是特定人群，不是普通用户，不能太傻。

@FrankHB 我截图里面的 2g 是因为有其它程序需要用内存，于是 Xcode 它(不知道怎么想方设法)把自己的内存占用降下来了。能理解吗？

@dorentus 降了个毛线，Xcode 的内存不止 Xcode 那个进程的，还有多个依赖的进程 XCBBuild 、lldb 都是 Xcode 的

@xtinput 啊对对对

@dorentus 系统显示的内存占用变小，可能是被压缩或者交换。前者的效果不确定（除非进程真是傻乎乎分配极大量连操作系统都认识的站着茅坑不拉屎的页——这也就是被烂应用逼的），后者以系统响应（以及其它次要的，比如硬盘寿命）为代价。两者都是全局有限的，所以流氓进程一多可能绷不住。这些机制主要是为了优化吞吐，把系统潜能抠出来，所以对响应天然不友好。而对合理利用存储的进程，两者效果都有限。
你看看活动监视器内存选项卡下方的变化，至少交换多用了多少应该看得出来。或者用 top 看实时的 RSS/SwSS 。

建议各位拉黑 dorentus 以提升自己的浏览体验