1. casa
  2. Domanda e risposta
  3. Come gli Intenti funzionano internamente?

Come gli Intenti funzionano internamente?

2012-06-18 19 views
14

Ho sviluppato un'applicazione e ho eseguito alcuni test. Questo test consiste nello invio di dati da un servizio in background a un altro servizio di background . Tutti i dati sono stati ricevuti quando la velocità di trasmissione era bassa (4 intenti/secondo). Tuttavia, quando ho aumentato la velocità di trasmissione (8 e 12 intenti/secondo), alcuni dati (in genere 2- 3%) sono stati non ricevuti dal servizio di destinazione.Come gli Intenti funzionano internamente?

Tutti gli intenti sono stati trasmessi ei servizi erano in esecuzione localmente.

Qualcuno può dirmi, come il sistema operativo tratta gli Intenti e l'intero meccanismo funziona, al fine di trovare il motivo per cui i dati non sono stati ricevuti dal suo ricevitore?

Con i migliori saluti,

fonte

2012-06-18 João Nunes

+0

puoi pubblicare alcuni esempi di codice che hai usato per testare questo? – FoamyGuy

+1

ho appena eseguito sendBroadcast() all'interno di un ciclo, controllando la velocità con Thread.sleep(). Volevo solo vedere come intenti bahave con alta velocità di trasmissione. Ho solo usato Intents prima di iniziare servizi, attività e così via ... –

+3

Senza fornire una serie completa di progetti di esempio che dimostrino il tuo problema, dobbiamo presumere che il problema risieda nel tuo codice. "il modo in cui il sistema operativo tratta gli Intenti e l'intero meccanismo funziona" è un argomento estremamente complesso, probabilmente dozzine di pagine, e potrebbe non avere nulla a che fare con il problema attuale. – CommonsWare

risposta

1

Una possibile ragione è che la comunicazione tra processi di Android è sincrona. Il processo del client chiamante è bloccato per la durata della risposta del processo del server. Il tuo servizio con il timer è bloccato per (molto piccoli) periodi di tempo, il che potrebbe comportare il comportamento osservato.

Fonte: Android Binder - Android Interprocess Communication by Thorsten Schreiber, pag 11 - 13.

EDIT: Ho mantenuto la risposta pubblicata perché i commenti di João Nunes di Chris Stratton e sono preziosi.

fonte

2012-06-26 15:50:38

+0

In realtà il "processo client chiamante" non è bloccato.C'è un'importante distinzione tra attività/servizio, processo e thread. Mentre il thread che chiama una particolare API può benissimo bloccarsi, gli altri thread del processo sono * non * bloccati, purché il processo esista e non siano (di loro scelta) in attesa del ritorno delle chiamate di sistema bloccanti (direttamente, o avendo chiamato API della piattaforma che alla fine sono). –

+0

Quando inviamo gli intent usando il metodo sendBroadcast(), ci sono asincroni, almeno è scritto dagli sviluppatori Android. Ma la tua risposta potrebbe darmi un'altra opinione su come funziona l'intera implementazione. Potrebbe essere che il ricevitore della trasmissione sia occupato e il sistema operativo ignori gli intenti perché non possono essere inviati al ricevitore broadcast corrispondente? –

+0

@Chris Stratton, grazie per i chiarimenti. La mia comprensione era che l'IPC tra diversi processi era sincrono, basato sulla fonte a cui mi sono collegato, mentre il tuo commento si riferisce a diversi thread (e non necessariamente a processi diversi). Quindi se i servizi sono in processi diversi, la comunicazione sarebbe sincrona, ma se sono in thread diversi nello stesso processo la comunicazione è asincrona. Apprezzo la tua prospettiva su questo. –

Problemi correlati

 Problemi correlati