2010-11-30 13 views
61

Tengo un BroadcastReceiver que se llama de vez en cuando, y he notado que muchas personas usan¿Debo usar android: process = ": remote" en mi receptor?

android: process =":remote" 

en su receptor. El mío se usa para verificar algunas cosas y si las condiciones coinciden, activa una alarma. Mi pregunta es si debo usar la línea que publiqué arriba en mi manifiesto. Y si es así, ¿cuáles son los beneficios de hacerlo?

+0

¿En qué contexto (actividad, servicio, etc.) está definido el receptor? – Pentium10

+0

el Receptor se define en el manifiesto. Se llama desde la utilidad AlarmManager de Android. – Jason

Respuesta

146

Al definir su receptor con android:process=":remote", básicamente ejecuta su receptor en un proceso diferente (= VM). Para casos de uso típicos, no necesita ejecutar esto en un proceso diferente, y lo que sea que quiera hacer probablemente se ejecute perfectamente localmente (en su proceso de APK).

El inconveniente de utilizar android:process=":remote" es que necesita recursos adicionales para que se ejecute (en este caso, un proceso separado). Al hacerlo, básicamente se trata de 2 VM, y algunos patrones como los singletons, los campos estáticos ya no se pueden compartir entre su aplicación y su servicio remoto.

La ventaja de usar android:process=":remote" es que para algunos casos de uso, puede ser útil iniciar un servicio que continuará ejecutándose (en su propio proceso) después de que haya cerrado su aplicación, o si desea clientes remotos para poder vincularse a su servicio. Su receptor de difusión no bloqueará el hilo principal de su aplicación cuando se ejecute en un proceso separado al llamar al método onReceive() (sin embargo, existen otras formas de implementarlo).

He encontrado que la mayoría de las veces, para casos de uso más comunes, puede escaparse sin usar android:process=":remote".

+3

Muchas gracias, Exactamente la explicación que necesitaba – Jason

+0

¿Podría preguntarme qué otras formas de implementar un método no receptor() que está mencionando wpuld be? De hecho, tengo exactamente ese escenario en marcha, un método onReceive que realmente hace bastante trabajo y sospecho que podría estar causando algunos problemas en mi software ... – TiGer

+0

Hay otro beneficio implícito que no se menciona: cuando se ejecuta un componente en un proceso separado, tiene un nuevo montón de VM nuevo para usar. Entonces, en caso de que su aplicación esté realizando operaciones intensas de memoria, un proceso separado puede ser una solución para evitar errores de falta de memoria. –

Cuestiones relacionadas