wakelock使用过度的问题。

今天,测试提交了一个bug,说有个任务执行一半没了。(因为任务是由一个不可关闭的dialog控制,换句话说,dialog意外关闭了),差看了下log,细心的发现了一条ActivityManager发出来的log

Killing 10190:com.xxx.xxx.xxx/u0a59 (adj 7):excessive wake held 900036 during 900036

很费解,这是系统杀的,系统为啥杀呢?从字面意思看好像是过度使用了wake(因为dialog有个倒计时,所以,使用了wakelock锁)
那就从系统源码上看吧,ActivityManager发出的信息是在ActivityManagerService里执行的,直接打开该文件,搜索,直接到下面的函数(去掉部分和本次无关的代码)

//这个是检查是否过度使用wakelock以及cpu(cpu部分,有兴趣的自己看源码),如果过渡使用,则干掉
//这个检查函数是每隔15分钟检查一次的,从开机的时候开始。
final void checkExcessivePowerUsageLocked(boolean doKills) {
        updateCpuStatsNow();

        BatteryStatsImpl stats = mBatteryStatsService.getActiveStatistics();  //wakelock一些信息是在BatteryStats里保存的
        boolean doWakeKills = doKills;  //刚开始是true,也就是默认要干掉
        boolean doCpuKills = doKills;
        if (mLastPowerCheckRealtime == 0) {
            doWakeKills = false;  //这个是上次检查的时间,如果是0,则表示这是第一次检查,则不会干掉任何进程(开机完成即启用第一次检查)
        }
       //.....
        if (stats.isScreenOn()) {
            doWakeKills = false;//如果屏幕开启的时候也不会干掉,所以这个是为了防止后台的。
        }
        final long curRealtime = SystemClock.elapsedRealtime();
        final long realtimeSince = curRealtime - mLastPowerCheckRealtime;  //从上次检查到现在的时间
        final long curUptime = SystemClock.uptimeMillis();
        final long uptimeSince = curUptime - mLastPowerCheckUptime;
        mLastPowerCheckRealtime = curRealtime;
        mLastPowerCheckUptime = curUptime;
        if (realtimeSince < WAKE_LOCK_MIN_CHECK_DURATION) {
            doWakeKills = false;  //如果检查时间小于5分钟,则不杀进程,WAKE_LOCK_MIN_CHECK_DURATION是5分钟,可以自己看下定义
        }
        if (uptimeSince < CPU_MIN_CHECK_DURATION) {
            doCpuKills = false;
        }
        int i = mLruProcesses.size();
        while (i > 0) {  //遍历所有进程
            i--;
            ProcessRecord app = mLruProcesses.get(i);
            if (app.setProcState >= ActivityManager.PROCESS_STATE_HOME) {
                //对于setProcState>=PROCESS_STATE_HOME生效,这个定义,每个sdk可能不一样,大概是状态是在后台或者更低级别(数值越小,优先级越高,换句话说,如果当前正在显示或者是在前台的,即使关闭屏幕也不会被杀掉,所以,测试条件一定是返回桌面,并且关闭屏幕)
                long wtime;
                synchronized (stats) {
                    wtime = stats.getProcessWakeTime(app.info.uid,
                            app.pid, curRealtime);  //根据进程的uid和pid查找上次使用wakelock的时间,便于计算使用wakelock时间
                }
                long wtimeUsed = wtime - app.lastWakeTime;
                long cputimeUsed = app.curCpuTime - app.lastCpuTime;

                //其实这句话已经解释得很清楚了,一个进程如果拥有wakelock超过他总长时间的一半,就直接杀掉。
                //加上前面的判断,如果一个进程在后台,并且屏幕关闭的条件下,如果存在时间超过5分钟,并且,使用wakelock的时间超过总时间的一半,则杀掉)
                // If a process has held a wake lock for more
                // than 50% of the time during this period,
                // that sounds bad.  Kill!
                if (doWakeKills && realtimeSince > 0
                        && ((wtimeUsed*100)/realtimeSince) >= 50) {
                    synchronized (stats) {
                        stats.reportExcessiveWakeLocked(app.info.uid, app.processName,
                                realtimeSince, wtimeUsed);
                    }
                    //这个就是杀进程,也是通过这句log查找到这儿的。
                    app.kill("excessive wake held " + wtimeUsed + " during " + realtimeSince, true);
                    app.baseProcessTracker.reportExcessiveWake(app.pkgList);
                } 
                //......其他的判断,其中cpu是使用超过四分一,有兴趣自己看。
            }
        }
    }

ok,杀进程的函数已经找到了,那么,什么时候调用的呢?

final class MainHandler extends Handler {
        public MainHandler(Looper looper) {
            super(looper, null, true);
        }

        @Override
        public void handleMessage(Message msg) {
            switch (msg.what) {
           //other case
            case CHECK_EXCESSIVE_WAKE_LOCKS_MSG: {
                synchronized (ActivityManagerService.this) {
                    //调用刚才分析的函数,并且,默认的kill操作是true的
                    checkExcessivePowerUsageLocked(true);
                    removeMessages(CHECK_EXCESSIVE_WAKE_LOCKS_MSG);
                    Message nmsg = obtainMessage(CHECK_EXCESSIVE_WAKE_LOCKS_MSG);  //继续发送同一个信息,也就是定时检查,检查间隔是POWER_CHECK_DELAY,15分钟
                    sendMessageDelayed(nmsg, POWER_CHECK_DELAY);
                }
            } break;
            //other cases
        }
    };

ok,很简单,就是一个handler处理机制,并且15分钟定时检查,那么第一条信息是谁发送的呢?继续查.

final void finishBooting() {
        //other code

        synchronized (this) {
           //other code

            //这里的mFactoryTest 是不等于FactoryTest.FACTORY_TEST_LOW_LEVEL的,待会儿说
            if (mFactoryTest != FactoryTest.FACTORY_TEST_LOW_LEVEL) {
                // Start looking for apps that are abusing wake locks.
                //这里发送第一条信息
                Message nmsg = mHandler.obtainMessage(CHECK_EXCESSIVE_WAKE_LOCKS_MSG);
                mHandler.sendMessageDelayed(nmsg, POWER_CHECK_DELAY);
               //  other code
        }
    }

这里的函数,从名字看就知道是启动完成后,剩下的就不继续分析了,有兴趣的可以自己再去看下,不过,估计要从开机启动开始分析了。
接下来分析下mFactoryTest这个变量,全局搜索下,就在AMS的构造函数有赋值

 public ActivityManagerService(Context systemContext) {
        mContext = systemContext;
        mFactoryTest = FactoryTest.getMode();
        mSystemThread = ActivityThread.currentActivityThread();

        Slog.i(TAG, "Memory class: " + ActivityManager.staticGetMemoryClass());
        //other code
}

FactoryTest代码太简单了,直接附上代码得了

public final class FactoryTest {
    public static final int FACTORY_TEST_OFF = 0;
    public static final int FACTORY_TEST_LOW_LEVEL = 1;
    public static final int FACTORY_TEST_HIGH_LEVEL = 2;

    /**
     * Gets the current factory test mode.
     *
     * @return One of: {@link #FACTORY_TEST_OFF}, {@link #FACTORY_TEST_LOW_LEVEL},
     * or {@link #FACTORY_TEST_HIGH_LEVEL}.
     */
    public static int getMode() {
        //默认是FACTORY_TEST_OFF(0),而不是FACTORY_TEST_LOW_LEVEL(1),正常的机子都是工厂测试都是关闭的,换句话说,如果是工厂测试的机子,是不会过渡使用的。
        //如果硬是要看的话,可以到以下几个目录查看是否具有该值
        /default.prop
        /system/build.prop
        /system/default.prop
        /data/local.prop
        /data/property目录下所有presist属性
        return SystemProperties.getInt("ro.factorytest", FACTORY_TEST_OFF);
    }

    /**
     * When true, long-press on power should immediately cause the device to
     * shut down, without prompting the user.
     */
    public static boolean isLongPressOnPowerOffEnabled() {
        return SystemProperties.getInt("factory.long_press_power_off", 0) != 0;
    }
}

好了,分析以上的原因就是说下,wakelock虽然好用,但是也不能过度使用,使用的时候先确认下是否真的需要,以及cpu(这个就要避免一直在后台频繁操作了),最后,15分钟检查一次的,如果看了源码会发现,如果调试态是可以缩短的,目前不知道在不动用底层的前提下,如何开启ams调试态(开了调试态,多了很多log,除了这个,也会很有帮助的),如果有知道的,麻烦告知下

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 195,980评论 5 462
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 82,422评论 2 373
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 143,130评论 0 325
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,553评论 1 267
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,408评论 5 358
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,326评论 1 273
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,720评论 3 386
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,373评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,678评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,722评论 2 312
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,486评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,335评论 3 313
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,738评论 3 299
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,009评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,283评论 1 251
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,692评论 2 342
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,893评论 2 335

推荐阅读更多精彩内容

  • 1:InputChannel提供函数创建底层的Pipe对象 2: 1)客户端需要新建窗口 2)new ViewRo...
    自由人是工程师阅读 5,208评论 0 18
  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 171,138评论 25 707
  • ANR问题,相信是每位开发日常都会遇到的问题,对于这类问题的分析,按照官方的推荐,或网络博客的总结思路能解决一定的...
    tiger桂阅读 17,774评论 5 28
  • 想不动声色 但脑子里有情绪和扭曲的五官 想温文儒雅 但骨子里有叛逆和好动的四肢 想通情达理 但生活里有无理和蛮横的...
    烦人日记阅读 255评论 0 1
  • 近来迷恋听异域风的小语种音乐,尤其是泰语歌,好像泰国人有种神奇的天赋,能把生就的热情和开放融进歌曲里,唱天空唱流水...
    一枕阅读 756评论 0 2