Uso de Android: proceso

Tengo este archivo AndroidManifest.xml:

   

android: process” se agrega como etiqueta de manifiesto y etiqueta de proveedor, sé que si se agrega como etiqueta de proveedor, el proveedor se puede ejecutar en el proceso “com.lily.process”. Pero, ¿cuál es su uso cuando se escribe como una etiqueta de manifiesto? Lo he intentado, pero no todos los componentes se pueden ejecutar en el proceso identificado.

Estoy de acuerdo en que no muchas personas encontrarían android: process para ser útil como un atributo de la etiqueta de la aplicación. Sin embargo, he encontrado que es útil como un atributo de la etiqueta de actividad .

El propósito de android:process en una actividad es especificar que su actividad debe iniciarse en un proceso que tenga un nombre específico. La elección de ese nombre se puede utilizar para aislar la actividad en su propio proceso (diferente de la que lo lanzó), o para obligarlo a convivir en un solo proceso con otras actividades que usan el mismo nombre.

Según la guía Dev ( http://developer.android.com/guide/topics/manifest/activity-element.html ):

“Si el nombre asignado a este atributo comienza con dos puntos (‘:’), se crea un nuevo proceso, privado para la aplicación, cuando es necesario y la actividad se ejecuta en ese proceso. Si el nombre del proceso comienza con un carácter en minúscula, la actividad se ejecutará en un proceso global de ese nombre, siempre que tenga permiso para hacerlo. Esto permite que los componentes en diferentes aplicaciones compartan un proceso, reduciendo el uso de recursos “.

Recientemente descubrí que este atributo es útil para resolver un problema que tuve al lanzar una actividad de ayuda para una aplicación que, en determinadas circunstancias, era bastante cercana al límite de almacenamiento dynamic de 16 MB que todavía se aplica a algunos dispositivos. Lanzar su actividad de ayuda fue, en esas situaciones, impulsar mi aplicación más allá del límite, lo que provocó un cierre forzado.

Al usar la etiqueta android:process , pude especificar que mi actividad de ayuda debería iniciarse en un proceso independiente. Este proceso tenía su propio montón de 16MB, y no contaba contra el montón de mi aplicación principal que lo lanzó. Esto evitó de forma permanente y completa que mi aplicación se quedara sin espacio y se bloqueara cuando se lanzó la ayuda.

Si su aplicación de lanzamiento tiene el nombre del paquete

 com.mycompany.mymainapp 

y, por lo tanto, se le asigna un nombre de proceso que es la misma cadena, luego, si usa

 android:process=":myhelp" 

en su actividad lanzada, se le asignará el nombre del proceso

 com.mycompany.mymainapp:myhelp 

y ese proceso tendrá su propia identificación de proceso separada, que puede ver (por ejemplo, en DDMS).

Esa, al menos, ha sido mi experiencia. Hasta ahora, mis pruebas se han realizado en un viejo Moto Droid que ejecuta CM6 (Android 2.2.1), configurado para tener un límite de almacenamiento dynamic de 16 MB.

En mi caso, dado que no quería que el usuario percibiera la ayuda como algo separado de mi aplicación, incluí el

 android:excludeFromRecents="true" 

atributo para evitar que la actividad de ayuda aparezca en la lista de aplicaciones recientes (presionar prolongadamente Inicio). También incluí

 android:taskAffinity="com.mycompany.mymainapp.HelpActivity" 

donde HelpActivity es el nombre de la actividad de ayuda, para segregar la actividad en su propia tarea

También agregué:

 android:launchMode="singleInstance" 

para evitar que se creen instancias múltiples de esta aplicación cada vez que el usuario invoque ayuda.

También agregué la bandera:

 Intent.FLAG_ACTIVITY_NEW_TASK 

a la intención utilizada para iniciar la actividad de ayuda.

Estos parámetros pueden o no ser necesarios, dependiendo del uso que esté haciendo del atributo android:process .

Teniendo en cuenta la frecuencia con la que uno encuentra límites de memoria al desarrollar dispositivos Android, tener una técnica que, en algunos casos, le permita dividir partes de su aplicación en procesos separados, cada uno con su propio montón, parece un regalo maravilloso. Puede haber peligros ocultos al hacer esto que aún no he considerado o experimentado, pero hasta ahora, muy bien, en mi caso particular.

@Carl

Puede haber riesgos ocultos:

  • La memoria no se puede liberar cuando hay un servicio en segundo plano (por ejemplo: android: process = “: myhelp”) en el mismo proceso.
  • El patrón Singleton no se puede usar.

Ref: http://developer.android.com/training/articles/memory.html#MultipleProcesses

El proceso casi se ha triplicado en tamaño, a 4MB, simplemente mostrando un poco de texto en la interfaz de usuario. Esto lleva a una conclusión importante: si va a dividir su aplicación en múltiples procesos, solo un proceso debe ser responsable de la IU. Otros procesos deben evitar cualquier interfaz de usuario, ya que esto boostá rápidamente la memoria RAM requerida por el proceso (especialmente una vez que comience a cargar los recursos de mapas de bits y otros recursos). Puede ser difícil o imposible reducir el uso de memoria una vez que se dibuja la IU.

android: process y shareduserid se pueden usar para transferir recursos entre paquetes. En mi caso, esto es útil ahora 🙂

Ejemplo del código fuente: https://github.com/ikust/hello-sharedprocess