2012-06-18 16 views
14

Desarrollé una aplicación y ejecuté algunas pruebas. Esta prueba consiste en enviando datos de un servicio en segundo plano a otro servicio de fondo . Todos los datos se recibieron cuando la velocidad de transmisión era baja (4 intents/second). Sin embargo, cuando aumenté la velocidad de transmisión (8 y 12 intentos/segundo), algunos datos (típicamente 2- 3%) fueron no recibidos por el servicio de destino.¿Cómo funcionan los Intents internamente?

Todos los intentos se emitieron y los servicios se ejecutan localmente.

Puede alguien decirme, cómo el sistema operativo trata los intentos y funciona todo el mecanismo, con el fin de encontrar la razón por la cual los datos no fue recibido por el receptor que es?

Saludos,

+0

¿Puedes publicar algún código de muestra que usaste para probar esto? – FoamyGuy

+1

acabo de ejecutar sendBroadcast() dentro de un bucle, controlando la velocidad con Thread.sleep(). Solo quería ver cómo Intents bahave con alta velocidad de transmisión. Solo utilicé Intents antes para comenzar servicios, actividades, etc. –

+3

Sin proporcionar un conjunto completo de proyectos de muestra que demuestren su problema, debemos suponer que el problema radica en su código. "Cómo trata el SO los Intentos y funciona todo el mecanismo" es un tema extremadamente complejo, probablemente docenas de páginas de longitud, y puede que no tenga nada que ver con el problema actual. – CommonsWare

Respuesta

1

Una posible razón es que la comunicación entre procesos de Android es sincrónica. El proceso del cliente llamante se bloquea durante la respuesta del proceso del servidor. Su servicio con el temporizador está bloqueado durante periodos de tiempo (muy pequeños), lo que podría provocar el comportamiento que observó.

Fuente: Android Binder - Android Interprocess Communication by Thorsten Schreiber, p 11 - 13.

EDITAR: He mantenido la respuesta publicada debido a los comentarios de João Nunes de Chris Stratton y son valiosos.

+0

En realidad, el "proceso de cliente llamante" no está bloqueado.Hay una distinción importante entre actividad/servicio, proceso e hilo. Mientras que el hilo que llama a una API en particular puede bloquear, otros hilos del proceso * no * están bloqueados, mientras exista el proceso y no estén (por su propia elección) esperando la devolución de las llamadas al sistema de bloqueo (ya sea directamente, o al haber llamado API de la plataforma que finalmente lo son). –

+0

Cuando enviamos intents utilizando el método sendBroadcast(), hay asincrónicos, al menos eso está escrito en los desarrolladores de Android. Pero su respuesta podría darme otra opinión sobre cómo funciona toda la implementación. ¿Podría ser que el receptor de difusión esté ocupado y el sistema operativo descarte las intenciones porque no se pueden enviar al receptor de difusión correspondiente? –

+0

@Chris Stratton gracias por la aclaración. Según entendí, el IPC entre los diferentes procesos era sincrónico, según la fuente a la que yo estaba vinculado, mientras que su comentario se refería a diferentes hilos (y no necesariamente a procesos diferentes). Entonces, si los servicios están en procesos diferentes, la comunicación sería sincrónica, pero si están en diferentes hilos en el mismo proceso, la comunicación es asincrónica. Aprecia tu perspectiva sobre esto. –

Cuestiones relacionadas