Qual è START_STICKY, START_NOT_STICKY e START_REDELIVER_INTENT Servizio

Question

io sono in grado di comprendere

1. START_STICKY,
2. START_NOT_STICKY e
3. START_REDELIVER_INTENT

Qualcuno può spiegare in modo chiaro con esempi.

Sono passato attraverso il link this ma non ho potuto capire chiaramente.

Answer 1

Questi sono relativi ai servizi. Sappiamo tutti che i servizi continuano a funzionare in background e consumano anche parte della memoria da eseguire.

Così, mentre più dell'applicazione gira su dispositivo Android, la memoria del dispositivo continua ad abbassarsi e quando arriva il momento, quando la memoria del dispositivo diventa criticamente bassa, il sistema Android inizia a terminare i processi, in modo da rilasciare la memoria occupato dai processi.

Ma si potrebbe svolgere un compito importante con i servizi, che potrebbe anche essere interrotto quando il servizio si interrompe. quindi questi concetti devono dire al sistema Android quale azione si desidera eseguire quando la memoria del dispositivo diventa stabile e quando è pronta per il rilancio dei servizi.

La spiegazione più semplice di questi potrebbe essere,

START_STICKY- dice al sistema di creare una nuova copia del servizio, quando la memoria disponibile è sufficiente, dopo che recupera dalla memoria bassa. Qui perderai i risultati che potrebbero essere stati calcolati prima.

START_NOT_STICKY- dice al sistema di non preoccuparsi di riavviare il servizio, anche quando ha memoria sufficiente.

START_REDELIVER_INTENT- indica al sistema di riavviare il servizio dopo l'arresto anomalo e anche di riconsegnare gli intenti presenti al momento dell'arresto.

Answer 2

Bene, ho letto il thread nel tuo collegamento e dice tutto.

se il servizio viene ucciso da Android a causa di poca memoria, e Android cancella un po 'di memoria, quindi ...

1. Rilievo: ... Android riavviare il servizio, perché quel particolare flag è impostato.
2. NOT_STICKY: ... Android non si preoccuperà di ricominciare, perché la bandiera dice ad Android che non dovrebbe preoccuparsi.
3. REDELIVER_INTENT: ... Android riavvierà il servizio E riconsegnerà lo stesso intento a onStartCommand() del servizio, perché, ancora una volta, della bandiera.

Answer 3

Entrambi i codici sono rilevanti solo quando il telefono esaurisce la memoria e uccide il servizio prima che termini l'esecuzione. START_STICKY indica al sistema operativo di ricreare il servizio dopo che ha memoria sufficiente e chiama nuovamente onStartCommand() con un tentativo nullo. START_NOT_STICKY dice al sistema operativo di non preoccuparsi di ricreare nuovamente il servizio. Esiste anche un terzo codice START_REDELIVER_INTENT che indica al sistema operativo di ricreare il servizio E riconsegna lo stesso intento a onStartCommand().

Questo articolo di Dianne Hackborn ha spiegato il contesto di ciò molto meglio della documentazione ufficiale.

Fonte: http://android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html

La parte chiave qui è un nuovo codice risultato restituito dalla funzione, dicendo al sistema di quello che dovrebbe fare con il servizio se il suo processo viene ucciso mentre è in esecuzione:

START_STICKY è fondamentalmente uguale al comportamento precedente, in cui il servizio viene lasciato "avviato" e verrà successivamente riavviato dal sistema. L'unica differenza rispetto alle versioni precedenti della piattaforma è che è se viene riavviato perché il suo processo viene interrotto, onStartCommand() verrà chiamato alla successiva istanza del servizio con un Intento nullo invece di non essere chiamato affatto . I servizi che utilizzano questa modalità dovrebbero controllare sempre per questo caso e gestirlo in modo appropriato.

START_NOT_STICKY dice che, dopo il ritorno dal onStartCreated(), se il processo viene ucciso con i comandi senza inizio rimanente per fornire, allora il servizio verrà arrestato, invece di riavvio. Ciò rende molto più sensato il per i servizi destinati a essere eseguiti solo mentre esegue comandi inviati a loro. Ad esempio, è possibile avviare un servizio ogni 15 minuti da un allarme per eseguire il polling di alcuni stati della rete. Se ottiene ucciso mentre fa quel lavoro, sarebbe meglio lasciare che fosse fermato e iniziare la prossima volta che scatta l'allarme.

START_REDELIVER_INTENT è come START_NOT_STICKY, a meno che il processo del servizio di viene ucciso prima di chiamare stopSelf() per un dato intenti, che l'intento sarà ri-consegnato ad esso fino al completamento (a meno che dopo un certo numero di altri tentativi non può ancora essere completato, al che indica il sistema si arrende). Questo è utile per i servizi che sono che ricevono comandi di lavoro da fare e vogliono assicurarsi che facciano il lavoro alla fine per ogni comando inviato.