【问题标题】:Android app OOM (Out Of Memory) adjustment priorities for processesAndroid app OOM (Out Of Memory) 进程优先级调整
【发布时间】:2012-11-22 15:55:34
【问题描述】:

我正在开发一个 Android 启动器(主屏幕替换)应用程序并遇到启动器在低内存情况下被杀死。当用户回到家必须等待时,这显然不是很好。

在我的研究中,我发现 Android 将进程分为几个优先级组,从最高到最低:

系统

坚持

前景

可见

可感知

服务

首页

上一个

B 服务

背景

您可以通过执行以下命令检查哪些进程:adb shell dumpsys meminfo

我能找到的关于这个主题的最全面的文档是:http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle

但是,它并没有给出上述所有组的清晰画面。具体来说,

  1. 一个过程如何/何时被认为是“可感知的”?一些应用程序(例如Go Launcher EX)似乎已经弄清楚了如何在不在前台时保持在这个类别中。这样,它就不会经常被杀死。他们是怎么做到的?

    我从 adb shell dumpsys 活动中发现 Go Launcher Ex 被视为前台服务。我能找到的关于这个主题的唯一文档说你需要在状态栏中放置一个持久通知。然而,Go Launcher Ex 以某种方式绕过了这个要求。我不知道怎么做:-(

  2. “A 服务”、“首页”和“B 服务”有什么区别?

  3. 关于启动器应用程序如何获得比常规应用程序更高的优先级的任何其他一般建议?我认为这是一个完全合法的请求,因为对于用户而言,启动器应该被视为比大多数事情(当前前台活动除外)更高的优先级。

【问题讨论】:

  • 好问题!为 dumpsys 添加 1。

标签: android out-of-memory scheduler launcher


【解决方案1】:

回答问题 1) 和 3)
如果您logcat -b events 您可以看到那些具有可感知优先级的应用程序确实会创建通知。但是所有属性(甚至 contentView)都设置为 null。
所以在我对同样问题的研究中,我只是尝试创建一个空通知并用它启动我的服务:

startForeground(42, new Notification())

瞧:logcat 说:

I/notification_enqueue( 1607): [my.testapp.TestApp,42,NULL,Notification(pri=0 contentView=null vibrate=null sound=null defaults=0x0 flags=0x40 kind=[null])]

和dumpsys meminfo:

...
17539 kB: Perceptible  
     ...  
     6164 kB: my.testapp.TestApp (pid 25573)  
...

我不认为这是有意的,应该理解的是,只有在真正需要时才应该使用它。我不想想象每个糟糕的服务都使用它。

【讨论】:

  • 感谢您的回答!我刚刚确认了一切,这真是太神奇了...我现在有点想隐藏这个答案,因为担心每个糟糕的应用程序都可能会尝试使用它并完全绕过 Android 的内存管理:-)
  • 我正在使用 startForeground(0,notify) 并使用 startForeground(1,notify) 为我工作,感谢您提出找出代码中错误的想法。我从没想过将通知 ID 设置为 1 或 42 会改变很多事情
【解决方案2】:

根据您引用的文档,您可以尝试在Launcher中启动具有更高优先级的长期服务并检查KILL次数性能。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2023-03-27
    • 1970-01-01
    • 2022-07-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-08-24
    相关资源
    最近更新 更多