飘在云端

东西南北,海角天涯

· Android · · 159次浏览

system_server CPU 占用高的排查

环境
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 调度没有问题了

评论 (0条)