在onDestroy()中的致命陷阱)
引言
在Android车机开发中,我们遇到了一个看似简单却颇为隐蔽的问题:节日彩蛋视频播放时,CSD(中控屏)没有立即显示画面,用户看到了约3秒的黑屏。这个问题的表面现象很简单,但背后的原理涉及Android的SharedPreferences机制、QueuedWork工作队列、以及视频渲染管道。
本文将详细记录这个问题的完整分析过程,包括我最初的错误判断和最终的正确诊断,希望能给大家提供一个真实的问题排查思路。
问题现象
问题描述: 播放节日彩蛋视频时,CSD没有立即进入播放界面,出现黑屏现象
发生时间: 2026-01-04 16:22左右
问题频率: 偶现
影响范围: 用户体验受损,彩蛋功能效果大打折扣
初步分析(错误的方向)
拿到这个问题后,我的第一反应是查看日志中是否有重复调用或者Activity生命周期异常。通过grep搜索日志,我发现了这样的信息:
# 搜索SurpriseManager的executeSurprise调用grep"executeSurprise"aplog*|grep-i"16:22"日志显示在短时间内executeSurprise被调用了4次,每次都会创建DialogActivity。基于此,我得出了初步结论:
错误结论:
- 根因:SurpriseManager缺少去重/防抖机制
- 现象:DialogActivity被重复创建4次,覆盖了CSDVideoActivity
- 解决方案:在SurpriseManager中添加防重复执行逻辑
这个分析看起来很合理,DialogActivity确实被多次创建了,但问题是——这不是根本原因。
关键证据浮现
在深入思考调整分析方向后,找到了关键的日志证据:
01-04 16:22:38.777 16942 16942 W .auto.eastereg: Long monitor contention with owner queued-work-looper (17018) at void android.app.QueuedWork.processPendingWork()(QueuedWork.java:273) waiters=0 in void android.app.QueuedWork.processPendingWork() for 2.746s 01-04 16:22:38.800 16942 16942 I Choreographer: Skipped 162 frames! The application may be doing too much work on its main thread.这两条日志彻底颠覆了我的分析。让我们来仔细解读:
关键信息解读
- Long monitor contention: 主线程在
QueuedWork.processPendingWork()处被阻塞了2.746秒 - Skipped 162 frames: Choreographer跳过了162帧
- 数学验证: 2.746秒 × 60fps = 164.76帧 ≈ 162帧 ✓
这个计算完美吻合!说明主线程确实被阻塞了将近3秒。
正确的根因分析
QueuedWork阻塞机制
让我们通过流程图来理解这个问题:
图表说明:展示了从DialogActivity.onDestroy()调用到主线程阻塞的完整流程
问题代码定位
// DialogActivity.java - 问题代码@OverrideprotectedvoidonDestroy(){super.onDestroy();SharedPreferencesprefs=getSharedPreferences("easter_egg",MODE_PRIVATE);SharedPreferences.Editoreditor=prefs.edit();editor.putBoolean("played",true);editor.apply();// ❌ 致命问题:在onDestroy中使用apply()}SharedPreferences.apply()的工作机制
SharedPreferences.apply()的设计初衷是异步写入,避免阻塞主线程:
// Android源码简化版publicvoid
