为什么抖音的思路跟正常人不一样？

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

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

背景是超级 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 。
」