十二毫秒长帧的追缉：当 bitmap 池恒空，GC churn 才是卡顿的真凶

「卡卡的”是一种体感，而体感是最不可靠的报案人。真正定案的，是日志里那个不起眼的 pool=0.0/25MB。

一、先证伪：引擎根本没崩

真机、正式 release 包、60Hz 面板上采样，数据出来第一件事是推翻自己的假设：

场景	fps 均值	fps 最低	drawMax	>8ms 长帧	同屏弹幕峰值	缓存命中
直播间·中低密度 90s	59.3	58.0	12.0ms	5 帧	17	100%
直播间·较密 180s	58.2	54.0	12.2ms	18 帧	35	100%

盒子的 FOS 面板显示 240 FPS，一度让人以为跑满了——但那是装饰性计数器，面板实际是 60Hz。也就是说弹幕引擎 59.3fps 在 60Hz 面板上等于帧率几乎跑满，直播房间这个密度下引擎没有性能问题。自研渲染器加文字预渲染 bitmap 加平滑时钟加自适应密度这套架构，是健康的。

但日志里每 30 秒一次 10MB 的并发 GC 值得警惕。而 pool=0.0/25MB——bitmap 池完全没用起来——是更硬的线索。卡顿的真凶不在引擎，在内存。

二、第一层根因：池和预算抢同一份额度

顺着 CacheManager 和 BitmapMemoryBudget 读下去，根因很快就定位了，而且它是设计问题：

池和位图预算共用同一份 25MB 额度，且预算腾挪时 evictPooled 是第一顺位。这意味着弹幕位图刚进池，下一个新弹幕申请额度时就把池掏空回收——池永远攒不起来（pool=0），所有位图都在 create/recycle 循环里。那就是 10MB/30s 的 GC churn，也就是 12ms 长帧的主要嫌疑。

修法直接：腾挪顺序改成先淘汰共享表、池留作最后手段。

同时修正 P1 的范围——另两项里有一项被数据否掉了。自适应降档即时化保留，但要说实话：实测最低 54fps（等于 0.90 乘 60Hz）根本没跌破降档线 0.72，所以这条针对的是点播高密度场景，不是今天测到的直播场景。而阴影开关砍掉：代码里弹幕位图根本不走 setShadowLayer（只有描边），这个改动没有测量数据支撑，不做。

三、第二层根因：喂食路径全被挡着

第一处修复上车，复测。fps 和长帧都改善了——drawMax 从 12ms 降到 2.5-4.3ms、over8=0——但 pool 仍然是 0。池子还是没吃上。

再往下挖，真相比第一层更深：共享表淘汰（removeEldestEntry）和预算腾挪（evictShared）都是直接 recycleBitmap，根本不过池。而池唯一的喂食路径（item 释放）又被共享表的引用计数挡着——表不退引用，item 释放永远到不了 0。

所以池恒空是设计必然，不是调参问题。修法：让共享表淘汰也走 recycleEntryBitmap，先进池，失败了才 recycle。

四、一次逻辑自我否决

第三处修复加下去之后，作者自己停下来发现了一个漏洞：

预算腾挪的目的是释放内存，而进池的位图仍然占着额度。池和预算共用一份额度，这样腾挪循环永远腾不出空间。

于是第三处被撤回，换成自洽的策略：预算压力下的共享表淘汰直接回收（释放额度），常规 LRU 溢出的淘汰才进池（稳定喂食）。两种淘汰走两条路，各干各的活。

这种中途撤回自己的修复，比一口气堆三个补丁重要得多——前者是设计在思考，后者只是代码在变多。

五、采样陷阱：pool=0 在一个房间是正常的

第三次复测，pool 还是 0。但这次先问的是：这个房间本身密度极低——同屏 3-6 个、仅 100 个位图。查 MAX_SHARED_CACHE 的值就知道：100 个位图小于 256 的共享表容量，根本不会触发淘汰，pool=0 在这里是正常的、也无法验证修复。

换房间。关注页里「全球总决赛」34.9 万热度是最密的，采 3 分钟。关键数据出来了：pool=1.5/25MB——池子在密级流房间正常工作了（328 个位图等于 256 表加 72 池，喂食路径生效）。

而 GC churn 仍在（每约 13 秒一次 10MB）——说明还有另一个分配源：直播弹幕消息对象，不是位图。P1 的两个修复都已验证生效，剩下的分配源是下一个案子。

六、被导航纠正的一次

密级房间的寻找过程也不是一帆风顺。几次导航跑偏——焦点跑过头到导航顶部、误进播放器、开错标签页——最后主人直接指定：「在我的-历史-第一个直播间，就行，别自己找了」。

这句纠正值得记下来：当目标明确时，穷举式探索不如直接问。前面几轮瞎撞消耗的不只是时间，还有主人对过程的信任。

七、收尾：还原比修复同样重要

测量做完了，数据推翻了”引擎有重大问题”的假设，并锁定了真正值得修的点。而盒子和代码都已还原——干净包已装回、日志开关已关、探针补丁已移除且与测量前逐字节一致。本地领先 Mac/GitHub 三个提交（两个测量补丁加一个 revert，净效果为零），没有推任何远端。

这是性能侦破的纪律：你留下的必须是一个可复现的现场，而不是一堆说不清的补丁。十二条长帧的追缉到头来，治的不是引擎，是一份被抢光了额度的池子——而发现这件事的入口，只是日志里那个被大多数人跳过的 pool=0.0。