Android系统工程师的日常：一次StartingWindow黑屏问题的排查与修复实录

Android系统工程师手记StartingWindow黑屏问题的深度剖析与实战修复1. 问题现象与初步定位那天早上刚到办公室测试组的同事就急匆匆地跑过来王工用户反馈解锁手机后偶尔会出现短暂黑屏概率大概5%左右能帮忙看下吗作为ROM团队的资深系统工程师这类显示异常问题正是我的专长领域。问题特征仅发生在屏幕解锁场景低概率出现约5%重现率黑屏持续时间约300-500ms设备型号搭载Android 13的自研旗舰机排查工具准备# 开启WMS详细日志 adb shell setprop log.tag.WM_DEBUG_STARTING_WINDOW VERBOSE adb shell setprop debug.wms.enable true # 捕获系统trace需root adb shell su root atrace -b 32768 wm am res --async-dump -o /data/local/tmp/trace.perfetto通过复现问题并分析logcat发现关键异常日志W/WindowManager: Unexpected window state: mNumInterestingWindows2 but only 1 visible window这提示窗口状态统计出现异常。进一步分析ActivityRecord.updateDrawnWindowStates()的调用栈发现当黑屏发生时mNumInterestingWindows计数异常增加实际可见窗口只有主窗口存在未被正确识别的TYPE_APPLICATION_STARTING类型窗口2. StartingWindow机制深度解析2.1 StartingWindow的核心作用设计初衷填补应用进程启动到首帧绘制的时间间隙避免用户感知到白屏或无响应提供视觉连续性尤其对冷启动场景三种窗口类型对比类型常量值适用场景视觉表现NONE0应用内Activity切换无过渡效果SNAPSHOT1任务切换到前台最后可见内容的快照SPLASH_SCREEN2应用冷启动品牌LOGO主题背景2.2 关键代码流程分析添加流程核心路径// 启动入口 ActivityStarter.startActivityLocked() → Task.startActivityLocked() → ActivityRecord.showStartingWindow() → StartingSurfaceController.showStartingWindow() // 类型判断关键点 ActivityRecord.getStartingWindowType() { if (newTask !processRunning) { return STARTING_WINDOW_TYPE_SPLASH_SCREEN; } if (taskSwitch allowTaskSnapshot) { return STARTING_WINDOW_TYPE_SNAPSHOT; } }窗口创建时序系统进程创建StartingData实例通过TaskOrganizerController跨进程调用WMShellStartingWindowController创建实际Surface最终调用WindowManagerService.addWindow()注意StartingWindow的添加运行在android.anim线程避免阻塞主线程3. 问题根因定位通过分析系统trace和源码发现黑屏问题的核心矛盾点异常场景解锁时系统创建Snapshot类型StartingWindowActivityRecord.mStartingWindow赋值延迟updateDrawnWindowStates()统计时误判void updateDrawnWindowStates() { // 原有判断条件不足 if (w ! mStartingWindow) { mNumInterestingWindows; } }根本原因竞态条件导致mStartingWindow尚未赋值窗口类型检查缺失WMShell侧异常处理不完善4. 多维度解决方案4.1 Framework层修复方案核心修改点// 修改ActivityRecord.java void updateDrawnWindowStates() { // 增加类型判断 if (w ! mStartingWindow w.mAttrs.type ! TYPE_APPLICATION_STARTING) { mNumInterestingWindows; } }兼容性处理// 在WindowState构造时标记StartingWindow class WindowState { WindowState(...) { mIsStartingWindow (type TYPE_APPLICATION_STARTING); } }4.2 WMShell侧增强异常捕获机制// StartingWindowController.java public void addStartingWindow(...) { try { // 原有逻辑 } catch (RemoteException e) { Slog.e(TAG, Failed to add starting window, e); // 回滚操作 mStartingSurfaceDrawer.removeWindowImmediately(token); } }心跳检测机制// 新增超时监控 private final Handler mHandler new Handler(); private final Runnable mTimeoutCheck () - { if (!mWindowAdded.get()) { Slog.w(TAG, StartingWindow add timeout); removeStartingWindow(token); } }; void scheduleTimeoutCheck() { mHandler.postDelayed(mTimeoutCheck, 300); }4.3 系统参数调优新增调试选项# 在device.mk中添加 PRODUCT_PROPERTY_OVERRIDES \ persist.debug.wm.starting_window_log1 \ debug.wm.starting_window_timeout300窗口超时配置!-- 在frameworks/base/core/res/res/values/config.xml -- integer nameconfig_startingWindowTimeout300/integer5. 验证与效果评估测试方案压力测试连续执行500次解锁操作边界测试低内存场景触发onTrimMemory快速连续解锁自动化测试# 使用uiautomator编写测试用例 def test_unlock_stability(): for i in range(100): device.wakeup() device.unlock() device.sleep() assert_no_black_screen()优化效果指标修复前修复后黑屏发生率5.2%0%平均响应时间320ms280msCPU负载峰值42%38%6. 经验总结与最佳实践排查方法论现象定位区分冷启动/热启动/解锁场景日志分析重点关注WM_DEBUG_STARTING_WINDOW标签流程还原绘制窗口状态转换时序图增量验证通过系统属性动态调整参数性能优化技巧# 动态调整StartingWindow超时无需重启 adb shell setprop debug.wm.starting_window_timeout 200代码审查要点检查所有TYPE_APPLICATION_STARTING相关判断验证mStartingWindow的读写同步监控mNumInterestingWindows的变化这次排查经历让我深刻体会到系统级问题的解决往往需要对机制原理的透彻理解多维度的问题分析能力谨慎的修改策略完善的验证方案在后续的ROM开发中我们建立了StartingWindow的专项监控体系确保类似问题能够被及时发现和修复。