我关注的qq浏览器关了还在播放

关掉之后，到底是谁还在播放

这不是一篇排错指南。我现在能确定的只有现象、部分日志和几个尚未闭合的假设。

3月10日晚上九点十七分，我把手机屏幕朝下扣在书房窗台上，去厨房倒了杯水。回来时，那集《隐秘的角落》第四集的片尾曲还在响——qq浏览器明明已经被我从最近任务里划掉了。窗外是杭州三月的湿冷，窗台上的水杯留下一个圈，我站在那儿听完了整段片尾曲，大约 1 分 43 秒，直到它自己停。那一刻我意识到，我面对的不是一个“偶尔卡一下”的 bug，而是一个可以被计时、被复现、被写进笔记的现象。

所以我把这件事记了下来，而不是划过去。

次日早上，我做了第一次正式记录：设备是红米 K70，系统 MIUI 15.0.8，qq浏览器版本 15.2.0。测试方法很朴素——打开一集视频，播放到片尾前 10 秒，打开最近任务列表，向上划掉浏览器卡片，用秒表计时直到声音消失。五次结果分别是 11 秒、23 秒、38 秒、1 分 02 秒、1 分 43 秒。这里必须说明，样本量很小，且我在测试时连着蓝牙耳机，蓝牙编解码的缓冲可能也是变量之一。但即便如此，这个时长分布仍然不正常——如果进程真的结束了，音频不该以任何速度继续。

我把日志导出来，在开发者选项里执行 dumpsys media_session，关闭后仍能看到一条 active 状态的媒体会话，包名指向 com.tencent.mtt。我又试着执行 dumpsys audio，AudioFlinger 里确实还有 track 在跑。这意味着系统层面仍认为有应用持有音频输出。但为什么最近任务卡片消失、进程却似乎没被完全回收？做 ROM 的朋友王岑在微信上回了我一句：“进程还在，只是被藏起来了。” 这句话我盯了很久，仍然没法把它变成一个完整的因果链——是谁在隐藏它，是系统的回收策略，还是应用自己注册了某种前台服务？

问题在这里卡住了，我选择把它写出来，而不是假装已经解决。

版本对照给了一点线索。我拿两台备机做了比较：15.1.3 上关闭后几乎立刻静音，15.2.0 则会残留一段音频。差异出现在 2 月 26 日之后的那次更新里，但更新日志只有“优化播放体验”六个字。我不打算据此认定是更新引入的回归，因为我没有拿到差异化的代码变更，也没有足够的对照样本排除系统侧的变化。同样，我用 Chrome 136 做了同一个测试，完全静音；华为 P60 与一加 12 上我都没复现。这些沉默的对照组说明问题并非“安卓都这样”，但也仅此而已。

• 具体数字：红米 K70 上 5 次复现，最长残留 1 分 43 秒，最短 11 秒。
• 具体动作：我把手机扣在窗台上，去厨房接水，来回约 4 秒；回来时声音仍在。
• 具体人物与对话：李岚在群里说“像有人按了暂停又没完全按下去”；王岑只回了一句“进程还在，只是被藏起来了”。

在翻旧笔记的时候，我还顺手回看了两篇自己以前写的站内记录，一篇是关于 手机qq文件在哪里打开 的路径说明，另一篇整理过 49图库恢复正常使用免费打开49图库资料下载方法 的操作步骤。它们和音频问题没有直接关系，但我意识到自己记东西的习惯一直是这样：先把路径、版本、时间写清楚，哪怕结论悬着。如果之后我要补充安装包层面的对照测试，大概会参考 49图库下载安装安卓版怎么下载 那篇里记版本号的方式。

说实话，我不太相信这仅仅是“清理后台没清干净”这么简单。如果只是进程没被杀，音频不该在 1 分 43 秒后自己停下——那更像是某个缓冲耗尽或服务超时。我更倾向于认为：应用在关闭时没有显式释放音频焦点，而系统的回收策略恰好又延迟了进程终止。但这是一个观点，不是结论。我写下来，是因为我希望它被证伪或被证实，而不是被一句“重启一下就好了”盖过去。

我还没有答案，但我有计时器和日志。

接下来我打算做三件事：第一，在关闭「允许后台播放」开关后重复同样的测试，确认是否存在联动；第二，用两台同型号但不同系统版本的设备做交叉对照，排除设备个体差异；第三，等下一次版本更新后立刻复测，看这个 1 分 43 秒会不会变。如果哪一天我把这三个问题都答完了，我会回来把这篇笔记改写成一份完整的记录。在那之前，这就是一篇带着问号的追踪。