android P版本 系统稳定性问题案例分析(二)

前言:
对这个专题总结就到此为止了。

android是一个内容庞大的操作系统,若没有足够的时间去研究学习那就只知皮毛了,遇到问题也无法真正的解决,所以深入源码、了解原理才是系统稳定性的关键,案例看起来是没有什么意义的。而且我对案例的总结只是对问题分析过程的记录,没有过多的分析代码,只是想为此类问题提供下分析的思路。

一、老化测试时SystemUI 出现anr问题

问题分析:
(1)机器在进行音视频老化测试时发生了anr
(2)音视频老化测试的操作主要有
    视频播放
    音频播放以及音频播放方式的循环切换(从喇叭到听筒)
(3)猜测有可能出现问题的原因
    老化测试CPU资源消耗太多,系统卡顿进而导致systemui发生ANR(此种情况发生概率不大)
    systemui自身操作太多,进而导致发生ANR(概率较大)

问题排查(没有anr详细信息,这个要命了):
(1)log中的报错信息:
am_anr  : [0,23485,com.android.systemui,818429453,Broadcast of Intent { act=android.intent.action.TIME_TICK flg=0x50200014 (has extras) }]

从报错信息看是广播超时导致的anr,但是广播确实很常见的android.intent.action.TIME_TICK广播。那么到这里暂时就不要分析是否是接收android.intent.action.TIME_TICK时导致的anr了,因为TIME_TICK是定时发出的(系统每分钟会发出该广播),不应该是造成anr的主因。

(2)没法继续分析:
到上面为止,问题已经没有办法继续分析了
    a.信息不够
    b.问题原因无法定位
    c.复现问题困难(老化测试耗时且不是必现)
没办法,只能交给测试的同学帮忙复现。

(3)好运气:
我在进行老化测试时,发现systemUI有个奇怪的现象,systemUI进程一直在持续的弹出有关VolumeDialogImpl的log,那anr会不会和这个有关系?

(4)找到突破点:
通过分析SystemUI对Volume的有关处理发现,SystemUI为了在实体按键按下时能够正确的改变当前音频设备的声音大小,一直在监听音频播放方式(喇叭、听筒),当听音频播放方式发生变化是,SystemUI会通过Handler的post方式去处理音频播放方式变化之后的操作。

(5)找到问题原因:
在对SystemUI的Handler的处理过程分析时发现,每次音频播放方式变化的话Handler都会post一个Runnable去处理事件,也就是说当音频播放方式变化频率很高时,Handler所在线程的Looper事件队列中可能会堆积很多等待处理的事件,这就有可能发生anr事件。
那么综上所述,SystemUI的Volume模块可能发生anr报错的条件就有两个
    a.变化频率很高。这个是有可能的,毕竟老化测试是对音频模块极限的测试(看下代码发现是3秒一次切换)。
    b.Volume的Handler应该是主线程。这个就可以通过以下代码证明。

    private final H mHandler = new H();
    private final class H extends Handler {

        public H() {
            super(Looper.getMainLooper());
        }

    }

问题总结:

此问题是在运气加成的基础上解决的(VolumeDialogImpl其实是没有这个log的,我的同事为了分析其他问题临时添加了一个log,所以运气大大的好),是Handler处理过程设计的不当造成(当然google也没想到我们这么能玩)。android对Looper的设计很棒,这样的设计对于开发者也很友好,但是如果没有真正理解Looper的原理,那就会出现不怎么好玩的问题了。

 

 

 

 

 

你可能感兴趣的:(android,源码)