Aplicación de Android OOM (Memoria insuficiente) prioridades de ajuste para los procesos
Estoy desarrollando una aplicación de Android Launcher (reemplazo de pantalla de inicio) y corriendo en el lanzador de obtener muertos en situaciones de baja memoria. Esto obviamente no es grande cuando el usuario regresa a casa y tiene que esperar.
En mi investigación, he encontrado que Android clasifica los procesos en varios grupos prioritarios, de mayor a menor:
- Error fatal: Adreno-GSL
- Widget no actualizado en el reinicio del lanzador
- Android cómo ocultar programaticamente el ícono del lanzador
- Información sobre Action MAIN y el lanzador de categorías en Android Manifest
- Creación de una actividad principal que NO aparece en la lista de lanzadores
Sistema
Persistente
Primer plano
Visible
Perceptible
A Servicios
Casa
Anterior
B Servicios
Fondo
Puede examinar qué procesos caen bajo los cuales ejecutando: adb shell dumpsys meminfo
La documentación más completa que pude encontrar sobre este tema fue: http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle
Sin embargo, no da una imagen clara de todos los grupos mencionados anteriormente. Específicamente,
-
¿Cómo / cuándo es un proceso considerado "perceptible"? Algunas aplicaciones (como el Go Launcher EX ) parecen haber descubierto cómo permanecer en esta categoría cuando no están en primer plano. De esta manera, no se matan como a menudo. ¿Cómo lo hacen?
Encuentro de la actividad de los dumpsys de la cáscara del adb que Go Launcher Ex se considera un servicio del primero plano. La única documentación que puedo encontrar en este tema dice que es necesario poner una notificación persistente en la barra de estado. Sin embargo, Go Launcher Ex de alguna manera consiguió alrededor de este requisito. Estoy perdido en cuanto a cómo
-
¿Cuál es la diferencia entre "A Services", "Home" y "B Services"?
-
Cualquier otro consejo general para una aplicación de lanzador sobre cómo puede obtener mayor prioridad que una aplicación regular? Creo que esto es una solicitud completamente legítima dado que un lanzador debe ser considerado como una prioridad más alta que la mayoría de las cosas (excepto la actividad de primer plano actual) para los usuarios.
- Icono de fondo en Samsung Galaxy S? Cómo cambiar esto?
- Cambiar el nombre de la actividad del lanzador en una nueva versión de la aplicación
- Android: la aplicación sin actividad de LAUNCHER no funciona
- Icono de Lanzador y actividad separado con Android
- Hacer un icono de lanzador dinámico
- Android: Cómo crear un lanzador
- Icono de lanzador de Android demasiado pequeño
- Alojamiento de widgets en un lanzador de Android
Para responder a la pregunta 1) y 3)
Si logcat -b events se pueden ver las aplicaciones con prioridad perceptible de hecho crear una notificación. Pero todas las propiedades (incluso contentView) se establecen en null.
Así que en mi investigación para el mismo problema que sólo trató de crear una notificación de vacío y comenzar mi servicio con él:
startForeground(42, new Notification())
Y voilà: logcat dice:
I/notification_enqueue( 1607): [my.testapp.TestApp,42,NULL,Notification(pri=0 contentView=null vibrate=null sound=null defaults=0x0 flags=0x40 kind=[null])]
Y dumpsys meminfo:
... 17539 kB: Perceptible ... 6164 kB: my.testapp.TestApp (pid 25573) ...
No pienso que esto se piensa, y debe ser entendido que esto debe ser utilizado solamente si realmente realmente requerido. No quiero imaginar cada pésimo servicio usando esto.
De acuerdo con el documento referenciado, puede intentar iniciar un servicio a largo plazo con mayor prioridad en el Lanzador y comprobar el rendimiento KILL veces.