https://www.mywiki.cn/Hovercool/index.php?action=history&feed=atom&title=BUG%E5%AE%9E%E4%BE%8B%E5%88%86%E6%9E%90%E4%B8%80%EF%BC%9A%E6%AD%BB%E6%9C%BA BUG实例分析一：死机 - 版本历史 2026-09-01T05:36:23Z 本wiki上该页面的版本历史 MediaWiki 1.45.1 https://www.mywiki.cn/Hovercool/index.php?title=BUG%E5%AE%9E%E4%BE%8B%E5%88%86%E6%9E%90%E4%B8%80%EF%BC%9A%E6%AD%BB%E6%9C%BA&diff=854&oldid=prev 2015年5月6日 (三) 12:10 Hovercool 2015-05-06T12:10:50Z <p></p> <p><b>新页面</b></p><div>=== 一、现象 ===<br /> <br /> 手机睡眠后按power键无法正常唤醒，具体表现如下：<br /> <br /> 现象一：无法点亮屏幕，按任意键无响应；<br /> <br /> 现象二：可以点亮屏幕，但触屏、按键无响应，电话也无法呼入，但插入usb偶尔可以更新状态栏时间<br /> <br /> <br /> === 二、初步判断 ===<br /> <br /> 从log上看，有两个案例log是有明显异常，在不停地打印同一条log，由于这些log是在有触屏事件时会出现的（包括但不限于），因此初步判断是input（如按键、触屏）事件出现异常，导致系统的input机制拥挤阻塞，但由于input及powerManager很多log屏蔽，无法作出进一步有效判断，故这里提供一个增加了大量log的image，请协助测试一下，力争抓到log（如能发掘必现规律就更好了）。<br /> <br /> <br /> === 三、解决思路 ===<br /> <br /> 一方面，由于input消息流程中大部分log是关闭的，因此仅从产品上抓取的log消息不足以定位问题点，因此决定发一版包含input所有log并在关键函数加入了不少log的软件给品质部测试(同时也鼓励内部试用机用户烧写这个软件)，并且要求品质部一旦发现此问题立马将现场保留，以便我们进行adb分析。<br /> <br /> 另一方面，之前今天有过一台出现此问题的机器，在不停地打印按键的 &quot;repeatCount=xxx&quot;，并且这个数值一直在递增，因此我们也做了第二手准备：即如果短期内无法重现这个问题，那则在打印 &quot;repeatCount&quot;这个地方进行判断，当 &quot;repeatCount&quot;大于某个值时则认为出现了异常，这样则重启手机。如此一来，至少问题会得到恢复，而不至于一直处理“死机”状态而不得不拔电池。这是为了不影响发货不得已的临时解决方案。<br /> <br /> <br /> === 四、终得真机分析 ===<br /> <br /> 几天过去，品质部同事重现了此问题！<br /> <br /> adb Go!!!<br /> <br /> 1、adb logcat，按键，inputDispatcher中的 notifyKey有无log产生？——无<br /> <br /> 2、adb shell getevent，按键，是否能接收到按键消息？——是<br /> <br /> ==&gt;驱动ok，问题发生在了framework<br /> <br /> 3、动态卸载、添加event2 ——无论卸载还是添加，均不成功<br /> <br /> ==&gt;怀疑 inputReader所在的 Thread阻塞<br /> <br /> 4、查看anr ——InputReader处于 WAIT状态，栈直指 interceptKeyBeforeQueueing中所调用的某一个函数，而这个函数调用了ContentResolver中的parse操作<br /> <br /> ==&gt;这就是卡的地方？！<br /> <br /> <br /> === 五、验证 ===<br /> <br /> 又在上述关键的地方加了些log，发个了软件(品质的同事辛苦了！)，幸运的是这次不到一天便出现了三台问题机器，其中有一台的log显示：<br /> &lt;pre calss=&quot;prettyprint&quot;&gt;<br /> 7824 07-14 15:53:03.688 D/InputDispatcher( 278): before call interceptKeyBeforeQueueing, 2816<br /> 7825 07-14 15:53:03.688 W/WindowManager( 278): interceptKeyBeforeQueueing start<br /> 7888 07-14 15:53:03.694 W/WindowManager( 278): interceptKeyBeforeQueueing end<br /> 7891 07-14 15:53:03.694 D/InputDispatcher( 278): after call interceptKeyBeforeQueueing, 2818<br /> 7917 07-14 15:53:03.697 D/InputDispatcher( 278): before call interceptKeyBeforeQueueing, 2816<br /> 7918 07-14 15:53:03.697 W/WindowManager( 278): interceptKeyBeforeQueueing start<br /> 7923 07-14 15:53:03.699 W/WindowManager( 278): interceptKeyBeforeQueueing end<br /> 7926 07-14 15:53:03.699 D/InputDispatcher( 278): after call interceptKeyBeforeQueueing, 2818<br /> 22072 07-14 15:57:54.647 D/InputDispatcher( 278): before call interceptKeyBeforeQueueing, 2816<br /> 22073 07-14 15:57:54.647 W/WindowManager( 278): interceptKeyBeforeQueueing start<br /> 22135 07-14 15:57:54.652 W/WindowManager( 278): interceptKeyBeforeQueueing end<br /> 22141 07-14 15:57:54.654 D/InputDispatcher( 278): after call interceptKeyBeforeQueueing, 2818<br /> 22186 07-14 15:57:54.887 D/InputDispatcher( 278): before call interceptKeyBeforeQueueing, 2816<br /> 22187 07-14 15:57:54.887 W/WindowManager( 278): interceptKeyBeforeQueueing start<br /> 22192 07-14 15:57:54.888 W/WindowManager( 278): interceptKeyBeforeQueueing end<br /> 22195 07-14 15:57:54.888 D/InputDispatcher( 278): after call interceptKeyBeforeQueueing, 2818<br /> 40764 07-14 16:01:19.988 D/InputDispatcher( 278): before call interceptKeyBeforeQueueing, 2816<br /> 40765 07-14 16:01:19.988 W/WindowManager( 278): interceptKeyBeforeQueueing start<br /> 40767 07-14 16:01:19.989 W/WindowManager( 278): interceptKeyBeforeQueueing end<br /> 40770 07-14 16:01:19.989 D/InputDispatcher( 278): after call interceptKeyBeforeQueueing, 2818<br /> 40799 07-14 16:01:20.404 D/InputDispatcher( 278): before call interceptKeyBeforeQueueing, 2816<br /> 40800 07-14 16:01:20.404 W/WindowManager( 278): interceptKeyBeforeQueueing start<br /> &lt;/pre&gt;<br /> 完美地验证了之前的猜测！<br /> <br /> <br /> === 六、后续规避 ===<br /> <br /> 这个问题的原因主要是在关键的路径（所有input事件都要调用的函数）上，增加了比较复杂的、有风险的ContentResolver操作，而一旦操作超时则导致整个系统的input系统瘫痪，用户无法操作，手机也无法自动恢复，只有拔电池了。<br /> <br /> 所以在后续framework的修改时，一定要考虑到所作更改的影响，在这些地方的更改也尽量要使用简单的逻辑、可靠数据操作方式进行，同时也要兼顾到性能方面的影响，如这里的更改就会导致每个input事件都要去操作ContentResolver，且不论是否可靠，单从性能上讲也不太可取。</div> Hovercool