Compose Idle Redraw

Compose 自持重绘循环诊断（idle-redraw feedback loop）

实战锚点：2026-09，history/favourites 页空闲 5s 渲染 620-642 帧而 feed 为 0， 根因为两个独立反馈环，修复 commit 46047d6a7（devel 分支）。归零后全功能回归通过。

1. 判定与第一反应

症状：页面静止、无输入、无动画，dumpsys gfxinfo 的 "Total frames rendered" 持续增长（120Hz 面板上 ≈ 60fps，即 5s 约 600 帧）。伴随现象：耗电、列表屏滚动发热。

第一反应不是找"最热的符号"。实测教训：LazyGridState.applyMeasureResult 占快照 写入 56%，但它只是"每帧重测"的下游后果，不是原因。链条是： 某状态写入 → 祖先重组 → 布局阶段跑 → applyMeasureResult 写快照 → … 追最热符号会带你绕一整圈回到起点。

正确的第一刀是对照组：

• 有问题的页 vs 恒为 0 的页（feed/订阅页），共用了哪些组件 → 差异即嫌疑面。
• 根层探针 IdleProbeActivity（已提交，app/src/debug/.../core/dev/IdleProbeActivity.kt， commit 4a124102e）：KototoroTheme + 裸 LazyVerticalGrid + 240 静态项。 它 0 帧 → 主题/窗口/insets/系统栏/Application 全部无罪，一次性剪掉大半搜索空间。

2. 测量协议（每次都按这个来，数字才可比）

P=org.skepsun.kototoro.debug
adb shell am force-stop $P
adb shell am start -n $P/org.skepsun.kototoro.main.ui.MainActivity
sleep 8                        # 冷启动稳定
adb shell input tap 342 2577   # 底部导航；Redmi K70 (1280x2772)：
                               # history=342, favourites=535, feed=923, 行 y=2577
sleep 6                        # 转场动画结束
adb shell dumpsys gfxinfo $P reset
sleep 5                        # 纯空闲窗口
adb shell dumpsys gfxinfo $P | grep -m1 'Total frames rendered'

规矩：每测一次都 force-stop 重来（进程内状态会互相污染）；先 reset 再读增量； 对照组页每轮都测（确认协议本身没坏）。修一处后全部页重测——history 修完后 favourites 还有 624 帧，因为它是第二个独立环，单根因假设会漏。

3. 归因阶梯（从粗到细，别跳级）

1. 快照 apply observer（最有效的单步）：Snapshot.registerApplyObserver 能看到 每个被 apply 的快照实际改变了哪些 state 对象，按对象 identity 计数。反复出现的 对象 = 重组 driver。registerGlobalWriteObserver 看不到嵌套快照（重组协程内） 的写入，别用它做第一步归因。
2. put 点栈采样：给疑似写入点加 1/40 采样栈打印（见工具箱），拿到完整调用链 Choreographer.doFrame → applyChanges → dispatchSideEffects/RememberObservers → 路由代码 → map.put，直接指认写者。
3. identityHashCode 探针区分"key 变了"vs"slot churn"：对 effect 的每个 key 逐个打 identity。vm 稳定 + callback 稳定 + router 每次新 → 嫌疑立刻收敛到 router。
4. 布局阶段频率（measure/ogp 每秒次数 vs compose 每秒次数）：measure ≈ 2×compose 说明每帧双测（scrollable 内容区 + 外层），是重组的下游证据，不是独立根因。

4. 三大根因模式（已实证，先对照再创新）

模式 A：SnapshotStateMap 的 put 通知语义 + data-class lambda 字段

MutableState.setValue 在值相等时会去重；SnapshotStateMap.put 不会——值相等 也通知所有读者。而路由每次重组都重报状态，data-class 里的 lambda 字段 （onSortOrderSelected、onClick）每次构造都是新实例、用 identity 比较 → == 永远不等 → shell 的相等门形同虚设 → 每次 put 都通知 → shell 重组 → 路由再报。 环闭合条件：写 map 的人（或其祖先）自己也读这个 map。

模式 B：get-property 每读构造 → DisposableEffect 每帧 re-key

inline val FragmentActivity.router: AppRouter get() = AppRouter(this)  // 每读一个新实例！

把它直接写进组合，DisposableEffect(appRouter, vm) 的 key 每帧都变： 每帧 forget（onDispose → 报空 → map.remove）+ remember（onRemembered → 报有 → map.put）。这种"在场/缺席交替"是真变化，任何相等门都救不了——必须让 key 稳定 （remember(activity) { activity.router }）。无状态 facade 对象都该这么包。

模式 C：反馈环 = 写者的祖先读它写的东西

通用判定：列出"谁写 X、谁读 X"。shell 把路由报告存进 snapshot map，又在自己 scope 里读这个 map 渲染顶栏 → 自持。哪怕写入值不变，map 的通知语义也够点火。

模式 D：无限动画挂在玻璃外壳底下（2026-09-26 实证）

rememberInfiniteTransition 只要有一个值在 draw 阶段被读（哪怕是 graphicsLayer {} 里 几个像素的漂移），整个窗口就按面板刷新率重绘；玻璃顶栏/底栏会采样下层，代价更高。 实例：TopChromeGlow 14s 漂移（0bfb78dfa）让所有一级页空闲 ~130fps、release 进程 空闲 ~42% 单核，两张相隔 1s 的截图却逐像素相同。apply observer 里表现为 唯一一个 Float 状态每帧变，写者栈落在 InfiniteTransition.onFrame。 对策：环境装饰一律静态；确需动效时必须受设置/可见性门控（参照 DiscoverHeroCarousel 的 isPanoramaAnimationEnabled）。排查时 grep rememberInfiniteTransition 最快。

模式 E：组合阶段读 LazyListState.layoutInfo（2026-09-26 实证）

每次测量都会产出新的 LazyListMeasureResult 对象，组合里直接读 layoutInfo 就会 "测量 → 重组 → 子项新 lambda → 重测 → 新 layoutInfo" 自持。apply observer 里表现为 LazyListMeasureResult 状态与某个 …Kt$$ExternalSyntheticLambda 状态每帧同步变化。 实例：订阅页 UpdatedContentCarousel 按偏移算倾斜/宽度（64dad203c）。 对策：用 derivedStateOf 只取需要的数值（偏移表等 data class），空闲时结构相等即不失效。