2012-12-24 20 views
11

Spero che qualcuno possa spiegarmi questo o indicarmi una risorsa che posso leggere per saperne di più. Sto costruendo un app che utilizza una ListView e un adattatore elenco personalizzato che ho modellato fuori uno dei molti tutorial disponibili online come questo:Capire quando e perché utilizzare thread Android diversi

http://www.softwarepassion.com/android-series-custom-listview-items-and-adapters/

Ha funzionato bene. Tuttavia, ogni esempio di come eseguire ciò esegue il processo di creazione dell'elenco di oggetti da visualizzare e la raccolta dei dati richiesti su thread separati.

Voglio sapere perché/Non potresti semplicemente inserire tutto in onCreate? Non riesco a vedere una ragione per cui avresti bisogno di thread separati per farlo accadere. C'è qualche forma/standard generale per quando/cosa devo eseguire su determinati thread?

risposta

7

The Android docs su questo sono molto buoni, come con la maggior parte delle cose.

Il risultato è: l'interfaccia utente deve essere sempre reattiva. Quindi if you have some operation that will take enough time that the user will notice, you might want to consider not running it in the UI thread. Alcuni esempi comuni sono network IO e database accesses. Tuttavia, si tratta di una soluzione caso per caso, quindi devi fare un po 'di richiamo.

+0

Ok quindi l'idea è di delegare compiti che potrebbero richiedere più tempo ad altri thread in modo che il thread principale non sia in attesa di informazioni da altrove mentre potrebbe essere in esecuzione qualcos'altro. Quindi, mentre puoi eseguire tutto da onCreate, probabilmente non è il modo più efficace per farlo. – Rarw

+0

Beh, dipende da come si definisce "efficiente". La migliore pratica suggerisce in genere che se si dispone di qualcosa che richiede una quantità "notevole" di tempo, è necessario spostarlo fuori dal thread dell'interfaccia utente e quindi da onCreate. È anche un po 'condizionale se hai bisogno o meno dei risultati per visualizzare l'interfaccia utente, ecc. Ma sì, il tuo commento è corretto in generale direi. – mfrankli

2

Bene, se la creazione dell'elenco di oggetti non è un processo relativamente breve, eseguirlo in onCreate() bloccherebbe/rallenterebbe il thread principale. Se si utilizza un thread separato, consentirà al sistema operativo Android di caricare tutti gli elementi dell'interfaccia utente mentre si è in attesa della compilazione dell'elenco. Quindi, quando l'elenco degli oggetti è pronto, puoi inserire immediatamente l'interfaccia utente già inizializzata, anziché aspettare di inizializzare l'interfaccia utente fino a quando non viene creato l'elenco degli oggetti. Garantisce che la tua applicazione sarà sempre reattiva per l'utente.

0

Poiché è necessario eseguire 0,5 secondi su onCreate, dopo di che viene visualizzato il messaggio di errore ADN (l'applicazione non risponde). Quindi, a meno che la tua vista elenco sia super semplice, non ce la farai in tempo. E anche se la visualizzazione della tua lista è semplicissima, è meglio impararla nel modo giusto.

BTW: Non utilizzo nemmeno thread, utilizzo uno o più servizi per fare tutto il lavoro. Ancora più difficile da attuare ma più robusto e reattivo.

0

La ragione per cui non si fanno cose su onCreate o sul thread dell'interfaccia utente è per la reattività. Se la tua app impiega troppo tempo per essere elaborata, all'utente viene visualizzata una finestra di dialogo Non risposta app.

0

una volta il mio insegnante ha detto: ogni software può essere scritto in un singolo ciclo (grande).

E se si pensa: può essere ... forse a livello NDK.

Alcuni sviluppatori di SDK hanno voluto rendere più semplici le attività degli sviluppatori di software e, quindi, perché esistono gli SDK e i framework.

A meno che non sia necessario nulla dal multitasking, è necessario utilizzare la filettatura singola.

A volte ci sono limitazioni di tempo, a volte UI/background/limitazioni di rete e devono fare roba nei thread diff.

0

Se vedi il codice sorgente di Asyntask e Handler, vedrai il loro codice esclusivamente in Java. (Naturalmente, ci sono alcune eccezioni, ma non è un punto importante).

Perché significa? Non significa magia in Asyntask o Handler. Semplicemente rendono il tuo lavoro più semplice come sviluppatore.

Per esempio: se Programa chiama Methoda(), Methoda() verrebbe eseguito in un thread diverso con ProgramA.You può facilmente verificare da:

Thread t = Thread.currentThread();
int id = t.getId();

e perché si dovrebbe usare nuovo thread? Puoi google per questo. Molte molte ragioni.

Quindi, qual è la differenza?

AsyncTask e Handler sono scritti in Java (utilizzano internamente un thread), quindi tutto ciò che si può fare con Handler o AsyncTask, si può ottenere usando anche un Thread.

Con quale Handler e AsyncTask è veramente d'aiuto?

Il motivo più ovvio è la comunicazione tra thread chiamante e thread di lavoro. (Thread chiamante: un thread che chiama il thread worker per eseguire alcune attività. Un thread del chiamante potrebbe non essere il thread dell'interfaccia utente sempre). E, naturalmente, puoi comunicare tra due thread in altri modi, ma ci sono molti svantaggi, ad esempio: il thread principale non è thread-safe (nella maggior parte dei casi), in altre parole, PERICOLOSO.

Ecco perché è necessario utilizzare Handler e AsyncTask. Loro fanno la maggior parte del lavoro per te, hai solo bisogno di sapere quali metodi superare.

Gestione delle differenze e AsyncTask: utilizzare AsyncTask quando il thread del chiamante è un thread dell'interfaccia utente. Questo è ciò che dice il documento Android:

AsyncTask enables proper and easy use of the UI thread. This class allows to perform background operations and publish results on the UI thread without having to manipulate threads and/or handlers

Voglio sottolineare due punti:

1) Facilità d'uso del thread UI (così, usare quando filo chiamante è UI thread).

2) Non è necessario manipolare i gestori. (significa: puoi usare Handler invece di AsyncTask, ma AsyncTask è un'opzione più semplice).

Ci sono molte cose in questo post che non ho ancora detto, ad esempio: cos'è l'interfaccia utente, del perché è più facile. È necessario conoscere un metodo dietro ogni tipo e utilizzarlo, sarà completamente capire perché ..

@: quando si legge il documento di Android, si vedrà:

Handler allows you to send and process Message and Runnable objects associated with a thread's MessageQueue

Possono sembrare strano in un primo momento . Basta capire che ogni thread ha ogni coda di messaggi. (come una lista delle cose da fare), e thread prenderà ciascun messaggio e lo farà fino a quando la coda del messaggio emty. (Ah, forse come se finissi il tuo lavoro e vai a letto). Quindi, quando Handler comunica, dà semplicemente un messaggio al thread del chiamante e attenderà l'elaborazione. (sophiscate? ma tu lo sai, Handler può comunicare con thread chiamante in modo sicuro)

Problemi correlati