Приложение Android OOM (Out Of Memory) корректирует приоритеты для процессов

Я разрабатываю приложение Android Launcher (замена домашнего экрана) и сталкиваюсь с тем, что пусковая установка убивается в ситуациях с нехваткой памяти. Это явно не очень хорошо, когда пользователь возвращается домой и должен ждать.

В своем исследовании я обнаружил, что Android классифицирует процессы по нескольким приоритетным группам, от высшего к низшему:

Система

Настойчивый

Передний план

Видимый

Ощутимый

Услуги

Дом

Предыдущий

Б Услуги

Фон

Вы можете проверить, какие процессы подпадают под какие, выполнив: adb shell dumpsys meminfo

Самая полная документация, которую я смог найти по этой теме, была: http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle

Однако он не дает четкого представления обо всех упомянутых выше группах. Конкретно,

  1. Как/когда процесс считается «воспринимаемым»? Некоторые приложения (например, Go Launcher EX), похоже, придумали, как оставаться в этой категории, когда не на переднем плане. Таким образом, его убивают не так часто. Как они это делают?

    Из активности dumpsys оболочки adb я обнаружил, что Go Launcher Ex считается службой переднего плана. Единственная документация, которую я могу найти на эту тему, говорит, что вам нужно поместить постоянное уведомление в строку состояния. Однако Go Launcher Ex каким-то образом обошел это требование. Я потерялся, как :- (

  2. В чем разница между «A Services», «Home» и «B Services»?

  3. Любые другие общие советы для приложения запуска о том, как оно может получить более высокий приоритет, чем обычное приложение? Я думаю, что это совершенно законный запрос, учитывая, что программа запуска должна считаться более приоритетной, чем большинство вещей (кроме текущей активности на переднем плане) для пользователей.


person dubchoi    schedule 04.12.2012    source источник
comment
Хороший вопрос! Добавьте 1 для dumpsys.   -  person herbertD    schedule 05.12.2012


Ответы (2)


чтобы ответить на вопросы 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:

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

Я не думаю, что это предназначено, и следует понимать, что это следует использовать только в том случае, если это действительно необходимо. Я не хочу представить, что каждый паршивый сервис использует это.

person Jantlem    schedule 17.12.2012
comment
Спасибо за ответ! Я только что все подтвердил, и это довольно удивительно ... Я как бы хочу скрыть этот ответ сейчас, опасаясь, что каждое паршивое приложение может попытаться использовать это и полностью обойти управление памятью Android :-) - person dubchoi; 17.12.2012
comment
я использовал startForeground(0,notify), и использование startForeground(1,notify) сработало для меня, спасибо за идею выяснить, что не так в коде. Я никогда не думал, что установка идентификатора уведомления на 1 или 42 изменит так много вещей - person Diljeet; 25.02.2013

Согласно документу, на который вы ссылались, вы можете попробовать запустить долгосрочную службу с более высоким приоритетом в Launcher и проверить производительность KILL times.

person herbertD    schedule 05.12.2012