环境
MIUI v13.0.11 稳定版，安卓 12
Magisk alpha v27002、LSPosed 1.9.2(7058)、Termux v0.118.0、BusyBox v1.36.1
Scene v7.3.0 Alpha8
手机什么没运行什么都能 cpu 温度干到 95℃，在省电模式下调度，大小核都能经常干到满频率运行，要是放开温度墙，分分钟是 105 ℃、120℃ 直接 CPU 虚焊(即使是216度高温锡也顶不住长久浪呀）
屏幕、机身背部滚烫到无法使用
不同的是，我的手机环境趋于稳定，从22年9月份购机之后配置好环境，就使用官方的出厂系统版本进行打磨优化，使用的 LSPosed 模块、Magisk 模块都是经过很久验证的，不会去更新的
但是最近开始，一直这样，Magisk 也有2个多月没更新了，时间尺度上也不符合，我卸载所有模块排查，开机后仍然持续增高占用，且是系统级进程 system_server，强制杀死该进程会触发热重启，回退到 MIUI 动画的开机界面 持续十几秒后锁屏
只能尝试 DeBUG 了
打开 Termux，输入 su - 切换到 root 用户
调查 system_server 具体线程占用
top -H -p 1841
1841 为 system_server的进程 PID
看到一个线程名为 android.fg 的线程一直占用 40% + 的 CPU 资源，查了下资料得知 android.fg可能指的是一个与前台应用（foreground app）相关的线程。这个线程通常处理与当前活跃应用相关的操作，因此如果当前应用在进行密集的计算或频繁的操作，可能会导致 CPU 占用较高
这个提示已经让我一个激灵了，前台服务有且只有一个我在使用的，我有用 Scene 7 调度管控 CPU/GPU/屏幕刷新率等系统资源，关键是什么呢，我最近去他们官方 tg 频道逛了一下，陆续更新了几个 Alpha 的版本，当前是 Scene v7.3.0 Alpha8
并且为了保活，它在前台注册了一个服务和显示通知，显示当前应用的 CPU 性能调度计划和一些策略，这不是全对上了吗，并且它也不作为 magisk 模块/LSPosed 模块挂载使用（虽然它有这个功能），所以我之前排查把 LSPosed 和 Magisk 都查了一遍没找到问题
进一步调查，导出一些系统日志，Termux 下执行命令导出日志
logcat>/sdcard/debug.txt
一瞬间就在内置存储根目录生成了 2.36 MiB 大小的日志文件，传到电脑分析
这部分引起我的注意，看到了一个相关信息，因为一直间隔性频繁出现打印
06-29 23:59:33.869 6312 0 E Go : Use Scheme 极速响应 Launcher
06-29 23:59:34.349 833 833 I Zygote : Process 6811 exited due to signal 9 (Killed)
06-29 23:59:34.708 6312 0 E Go : Use Scheme 一般APP WhiteList
06-29 23:59:35.643 833 833 I Zygote : Process 3315 exited due to signal 9 (Killed)
06-29 23:59:36.361 6992 6992 I flags_health_check: ServerConfigurableFlagsReset reset_mode value: 1
06-29 23:59:36.361 6992 6992 I flags_health_check: ServerConfigurableFlagsReset updatable crashing detected, resetting flags.
06-29 23:59:36.375 6993 6993 I flags_health_check: ServerConfigurableFlagsReset reset_mode value: 1
06-29 23:59:36.375 6993 6993 I flags_health_check: ServerConfigurableFlagsReset updatable crashing detected, resetting flags.
极速响应、一般APP 这些关键字与 Scene 系统资源调度策略有关
一共 18531 行日志，系统检测到某些配置标志导致了崩溃，并重置了这些标志，每隔几秒到十几秒就打印一次，统计 ServerConfigurableFlagsReset 关键字，出现 2068 次
Scene 7 的前台服务一直在崩溃并反复触发重置，最近我还更新了它好几个版本
好家伙，然后我还想起来一些操作可能还导致了 DeBUFF 叠加，为了保证 Scene 7 的资源调度/辅助服务存活，我在 Scene 7 的设置中开启了这些设置开关
资源监视器保持开启
精准监视器
无障碍 Daemon
性能调节 Daemon
然后还使用了 ASGuard magisk 无障碍守护模块保活 Scene 的无障碍相关服务，这 DeBuff 叠加的...
有怀疑的根源就好处理了
关闭 Scene 无障碍服务，并关闭 scene 内置的 无障碍/性能调节后台守护保活设置开关，然后 ASGuard 保活白名单移除 Scene 相关服务
重新检查占用，效果实时生效，占用降低，但仍然还是高
一个个模块排查，最后定位到一个 优雅的禁用log模块，这个如果开启并配合 scene 使用，直接 1+2﹥2 的效果，即使它以前没问题，最后把它禁用问题解决，单独开启 scene 调度没有问题了