@atrexl @fromzero @GeruzoniAnsasu 这人是 TUNA 群的传奇贵物，建议别理，直接 block 完事。刚才没看发帖人 ID 是我的疏失，我要是知道就不会回了。

edge 终于优化了万年垢病的宽额头

帮忙转发原文，免得之后链接失效。

「
抖音客户端基础技术团队的于聪分享了对存量旧手机体验优化的三项底层技术方案。

背景是超级 App 在 Android 5-9 老机型上遭遇三个硬限制：ART 虚拟机 heap 仅 256MB （即使声明 largeHeap ）、单进程 fd 上限 1024 、线程+进程数不超过 500 。

第一项方案是 ART heap 扩容——Android 5-7 上利用 malloc space 的 main/backup 双空间机制，通过 inline hook 阻塞 copy gc 、释放 backup space 并创建更大空间、再触发 copy gc 切换，将 heap 从 256MB 扩至 740-980MB ，OOM 率降 60.77%。Android 8-9 上对 region space 做类似扩容，从 512MB 扩至 740MB ，crash 率降 8.8%。

第二项是 FD/FD_SET 扩容，通过 setrlimit 突破内核限制，再 hook libc 的 FD_SET 系列函数在堆上创建 peer 映射解决用户态 fd_set 栈内存固定大小问题，crash 率降 7.23%。

第三项最硬核——实现 M:N 用户态透明线程，通过 hook clone syscall 代理 pthread 创建，用实时信号 timer 做抢占式调度，保存/恢复完整 CPU 上下文（含 tpidr_el0 的 TLS 隔离），用一个 LWP 承载多个虚拟线程，突破 500 线程限制。技术深度极高，涉及 ART 源码、inline hook 、指针压缩、内存布局搜索、信号处理、syscall interrupt 补偿等，是 Android 深度性能优化的标杆级实践。对高爷的 SmartPerfetto 工作和性能优化方向有直接参考价值，尤其是 ART 内存管理和线程调度部分。

随着业务发展，国内各类 App 均朝向"超级 App"的方向发展，这对存量旧手机的体验与稳定性带来了极大的挑战：Android art 虚拟机的 heap 内存十分有限，部分老机型即使在 app 标注 largeHeap 后还是仅有 256MB ； Android 9 以下版本，单个进程的 fd 上限为 1024 ；部分厂商在 Android 8 以下系统版本，更是限制一个 app 的进程+线程数不能超过 500 。

1. ART 虚拟机 malloc space 扩容

利用 malloc space 的 main/backup 双空间机制，通过 inline hook 控制 copy gc 时序，将 heap 从 256MB 扩至 740-980MB 。OOM 率 -60.77%。

2. ART 虚拟机 region space 扩容

Android 8-9 上对 region space 扩容，从 512MB 扩至 740MB 。crash 率 -8.8%，OOM 率 -6.93%，gc 后内存水位超 90% 渗透率 -73.34%。

3. FD/FD_SET 扩容

通过 setrlimit 突破内核 fd 限制，hook libc FD_SET 在堆上创建 peer 映射。Android 9 以下 crash -7.23%。

4. M:N 透明用户态线程

Hook clone syscall 代理 pthread ，实时信号 timer 抢占式调度，完整 CPU 上下文切换（含 TLS 隔离），1 个 LWP 承载多个虚拟线程，突破 500 线程限制。实测 1 个 LWP 运行 15 个 java 线程 + 3 个 native pthread 。
」

你用 mihomo 套壳，可以把核心代理和分流功能还原个七七八八。

@rizon 你可以用 ssh 把本地代理软件的端口映射到远程服务器上。

@Stargaze 说话的信息密度很低，你感觉说话快只是说话字多，实际上都是水份。

标题吓我一跳，还以为是那个 PC 。

@tlerbao Antigravity 以前至少便宜、好上手，上强度后就拉了，只能当玩具。

@night98 同意，现在反重力就是又贵又难用。

@emmathoermer 整个项目的上下文要用 docs/ 来管，我直接建一个单独的 repo 用来放项目上下文了，api 、schema 定义和 plans 都放在项目文档 repo 里，需要的时候 prompt 提醒智能体读指定路径就行。

要推广 extra credits 吧 都送钱了

不要用小龙虾

@383394544 额度被砍最狠的还是 20 刀的 AI Pro 方案（砍完比同价位的 Claude Pro 少），我换成 200 刀的 AI Ultra 方案根本用不完（只是反重力的服务器不稳让额度成为摆设）。Claude 100 刀的 max5x 就刚好符合我的需求，同样价钱能调用的 opus 量还更多，所以我觉得实际可用的量增加了。至于 Gemini 3.1 Pro 的用量我不在乎，本来用反重力只是为了它的编辑器，不是它的模型。

@MuyuQ #5 昨天用上了，真的超级好用。https://github.com/obra/superpowers

@vfx666 有 vscode 插件和 claude desktop ，都不好用。习惯 cli 后你会爱上的

@movq 反重力只有测 api 端点会用 curl ，让它查文档就会开浏览器，比网页版对话式 LLM 还狼狈。

@tomchen 其实让我下定决心转 cc 的原因不是"Antigravity 中的 Opus 的用量被砍"，虽然确实砍了一些，但没到不够用的程度。让我受不了的是上周开始疯狂报高峰期让我 retry （额度还有的情况），不管 gemini 3.1 还是 a/ 模型都这样，真用不了一点。