En mi trabajo, todos tenemos dispositivos Android que se utilizan para enviarnos trabajos. Utiliza una aplicación web accesible a través de cualquier navegador web. Cuando llega un nuevo trabajo, se nos notifica con una alerta audible. Sin embargo, debido a la forma en que Android maneja la memoria, a menudo "suspende" (no conoce la terminología adecuada) el navegador web, por lo que si obtenemos un nuevo trabajo, no se nos notifica a menos que volvamos a abrir manualmente la web. navegador para "despertarlo".
¿Hay alguna solución para este problema?
Salud
Presumiblemente, el dispositivo está usando wifi para acceder a Internet; podría valer la pena intentarlo:
De esa manera, cuando el dispositivo se va a dormir, el wifi aún está activo y funcionando y la aplicación web aún debería funcionar y
Cuando llega un nuevo trabajo, se nos notifica con una alerta audible
La respuesta anterior no es la respuesta correcta, más bien de los comentarios a continuación, esta es definitivamente la que cito.
Tal vez, el enfoque para administrar los trabajos se hace de manera incorrecta , especialmente en el contexto de Android: una aplicación personalizada que tiene un servicio que usa un bloqueo de activación parcial para "hacer ping" al verificar trabajos, enviar un evento a la aplicación y la aplicación se levanta. En mi humilde opinión, un navegador no es la herramienta adecuada para los requisitos en su caso.
En resumen, no se puede hacer nada para mantener el navegador web "vivo" mientras el dispositivo está inactivo, ya que Android, detrás de escena, cuando el kernel no está en estado inactivo, está rastreando qué aplicaciones se están ejecutando y dependiendo sobre las limitaciones de energía y memoria, especialmente en el caso de una página de navegador web (si tiene muchos estilos, cuanto más elaborada sea la página, más recursos acumulará como resultado, especialmente si tiene mucho Javascript detrás) la página) este podría ser el trabajo para que el núcleo lo derribe y lo expulse de la memoria, por lo tanto, no es una ruta confiable a tomar.
TL; DR: una aplicación adecuada en lugar de solo un navegador web resolverá el problema del OP.
Fuera de tema: hubo un artículo cubierto por la sección de tecnología en las noticias de la BBC con respecto a la navegación web móvil y cómo puede afectar la batería debido a la forma en que las páginas web están diseñadas, más bien, fueron diseñadas incorrectamente para la plataforma móvil, demasiados estilos, demasiadas secuencias de comandos, sin mencionar Flash también, todos tuvieron un efecto adverso en la forma en que Android muestra/presenta la página, lo que a su vez significó una gran cantidad de ciclos de CPU consumidos para hacer precisamente eso.
La mejor opción sería ajustar los parámetros minfree del asesino de memoria baja.
Algunos antecedentes:
Low Memory Killer es el pilar de la gestión de memoria de Android. Es un enfoque más elegante que el oomkiller de Linux y funciona de manera proactiva para mantener el grupo libre en lugar de solo activarse cuando se queda completamente sin memoria libre. Separa las aplicaciones en varias categorías para matar si el grupo de memoria libre está por debajo de ciertos puntos. Por lo general, están en el siguiente orden, desde el primero en morir hasta el último:
EMPTY_APP: son aplicaciones que no hacen nada ni esperan para hacer nada. Simplemente están sentados en la memoria.
CONTENT_PROVIDER: estas son aplicaciones en segundo plano que contienen contenido para aplicaciones activas (por ejemplo, Play Store usa una para buscar actualizaciones periódicamente. HTC Facebook Sync es otro ejemplo común).
HIDDEN_APP: están sentados en segundo plano, sin hacer nada, pero aún están vivos y posiblemente esperando algo.
SECONDARY_SERVER: un servidor que se ejecuta en segundo plano para proporcionar servicios para una aplicación que se está ejecutando actualmente.
VISIBLE_APP: esta es una aplicación que está en segundo plano, pero actualmente está haciendo algo.
FOREGROUND_APP: esto es lo que se está ejecutando actualmente y en la pantalla.
Si el grupo de memoria libre cae por debajo de cierta cantidad (por ejemplo, 80 MB es el valor predeterminado en mi GS3), el sistema primero comenzará a eliminar todo lo que aparezca como una aplicación vacía hasta que el grupo vuelva a estar por encima de esa línea. Si después de eliminar todas las aplicaciones vacías, la memoria aún está por debajo de la siguiente línea (por ejemplo, 64 MB), comenzará en los proveedores de contenido, y así sucesivamente, hasta que finalmente, si solo la aplicación en primer plano ocupa toda la memoria (en mi GS3, si todo, excepto la aplicación de primer plano, se eliminó y todavía hay menos de 32 MB de memoria libre) y amenaza el sistema, eventualmente se eliminará.
Volviendo a su pregunta real, lo que queremos hacer es ajustar estos valores hacia abajo, de modo que el asesino se active más tarde y, con suerte, no elimine el navegador cuando aún desee abrirlo.
La aplicación MinFreeManager le permitirá ajustar estos valores. Alternativamente, se pueden editar directamente en /sys/module/lowmemorykiller/parameters/minfreedonde están los parámetros en las páginas (4 kilobytes, por lo que un valor de 8192 significa 32 MB como ((8192 * 4)/1024 = 32 MB), y se enumeran en orden inverso al que mencioné anteriormente. Ambos de estos requerirá root Si no tiene root, básicamente no hay nada que podamos hacer para ayudar.
En su caso, el parámetro HIDDEN_APP (cuarto elemento en el archivo minfree) es probablemente lo que necesitamos cambiar. Por ejemplo, este parámetro es por defecto 56 MB en mi GS3. Reducir esto a la mitad a 28M o usar el preajuste suave en MinFreeManager sería un buen punto de partida para ajustar.
roxana
t0mm13b
roxana