想不到 2026 年，像抖音这种超级 App 居然还可以适配 Android 5 ，还能做到流畅运行，这在技术上确实很值得膜拜，因为老机型的运行环境有多艰辛大家应该也知道： ART 虚拟机 heap 只有 256MB、单个进程 fd 上限 1024、线程和进程数不超过 500 等，而为了让抖音可以在老旧手机上流畅运行，技术上不得不做各种"骚操作"：
一、ART Heap 扩容
在 Android 5 -7 上 ，即使你声明了 largeHeap，一些老机型的 ART 虚拟机 Heap 还是会被厂商限制在 256 MB，而抖音表示："你说没有就没有？" 。
❝
所以抖音通过 inline hook 控制 Copy GC 时序，再利用 main/backup 双 malloc space 机制，动态释放并创建更大空间，实现 Heap 从 256 MB 扩容到 740 - 980 MB，实现 Java OOM 率降低 60.77%。
怎么理解？要知道 ART 的 Heap 是系统强控的，只能在 GC 时动手脚，比如 Copy GC 会在特定时机搬内存，类似于趁着 GC "搬家"时插一脚（inline hook），然后释放旧的 malloc space，重新申请一个更大的，再把数据搬过去，当然双空间（main / backup）管理和数据搬运的时机都要卡好。
❝
这就像搬家时，趁搬家公司在打包，偷偷把"小房子合同"换成"大房子" ，而这个过程还需要不被发现异常。
二、ART Heap扩容
Android 8 - 9 region space，其实就是"分块内存管理"强行扩容 。
针对 Android 8 - 9 只有 512 MB 的 region space，抖音又进行动态扩容，通过在低 4 GB 地址空间搜索连续内存、修改 regions 数组及相关结构，实现 Heap 扩至约 740 MB（+45%），让整体 crash 率下降 8.8%，OOM 率下降 6.93%，GC 后内存渗透率超 90% 的情况减少 73.34%。
因为 Android 8+ 用的是 region（分块堆），不能像 malloc space 那样整体替换，而 region 数组 + 地址空间是"固定结构"，所以可以在低 4GB 地址空间找连续大块内存，扩大 region 数组（相当于扩"格子数量"），然后修改 ART 内部结构，让 GC 认为这些是合法 region。
❝
大概就类似，你不给我申请内存，我就自己申请后，然后让 ART 相信这些内存是它自己管理的。
三、FD/FD_SET 扩容
在 Android 9 等老版本上，一个进程里的 fd 最大数量默认被限制在 1024 ，这对于抖音远远不够，你可以把 fd 理解成 app 跟系统拿到的一张张"资源号码牌"：
- 打开文件要一个 fd
- socket 网络连接要一个 fd
- 某些管道、事件、匿名共享资源也要 fd
老系统里一个进程最多大概就 1024 张号码牌， 而抖音这种超级 App，图片、视频、网络、缓存、日志、线程协作全都在抢这些牌。
所以抖音通过对所有的 fd_set 在堆内存上开辟 peer 对象，然后一一映射，例如：
- 进入方法时触发 fd_set 扩容，期间所有 fd_set 都将进行堆上创建扩容 fd_set 映射
- 退出方法时停止 fd_set 扩容，释放当前扩容场景创建的 fd_set
通过这个骚操作，android 9 以下版本 FD/FD_SET 超限问题几乎全部解决， android 9 以下系统整体 crash -7.23% 。
❝
也就是系统给 app 的"句柄名额"不够了，抖音直接把这个上限顶开，你管不了的，我帮你管。
四、M:N 用户态线程
因为 Android 9 和部分厂商 Android 8 内核会限制 App 进程+ 线程总数必须 ≤ 500 ，所以：
- 不能真的创建太多线程，因为内核不允许
- FD_SET 也是固定大小，有 select 限制
所以还是 hook，通过 hook clone syscall 透明代理 pthread 创建，利用实时信号定时器实现抢占式调度，完整保存/恢复 CPU 上下文（含TLS隔离），让单个 LWP 可承载多个虚拟线程，然后创建 peer 映射并透明扩展，从而解决 FD/FD_SET 的相关问题，整体crash率下降 7.23 %。
抖音为什么需要那么多线程这个并不重要，但是 Hook 后自己接管线程创建，而不是真的创建线程，这个做法就很 6 ，这等于是创建"虚拟线程"，再映射到少量真实线程（LWP），这简直就是自定义版本的底层协程有木有？？？
单个 LWP 可承载多个虚拟线程，抖音实测 1 个LWP稳定运行 15 个Java线程 + 3 个native pthread，这里有啥难度？那可多了，比如：
- 抢占调度，怎么用实时信号（timer）打断线程
- 上下文切换，如何保存 CPU 寄存器 + 栈
- TLS 隔离，每个虚拟线程都要有自己的 ThreadLocal
❝
这就类似于把 Java Thread 变成了 Kotlin 协程的操作，把"系统资源限制问题"，全部变成"用户态可控问题"。
最后
是不是看不懂？看不懂就对了，满满黑科技和骚操作有没有？比如 「实时的信号 timer 抢占式调度，完整 CPU 上下文切换（含 TLS 隔离）1 个 LWP 运行 15 个 java 线程 + 3 个 native pthread」，这完全是场景不支持，我就创造场景，这个流程都是在系统漏洞上表示：
❝
"你给的不够，我需要更多，你给不了的，我自己拿，你管不了的，我帮你管"。
不过话说回来，现在很多低端机型，因为权限和安全都没那么严格，普遍是灰产的挚爱，所以也不知道在这些普惠的用户里，有多少的真实用户，多少是灰产工会，但是这兼容和优化能力，不可不佩服，膜拜。
❝