2010-08-03 12 views
6

Mentre la mia app matura, trovo sempre più usi per i thread. Ormai devo avere circa 25 discussioni, tutte facendo cose importanti e lavorando insieme in sinfonia.Le discussioni aggiungono un sacco di spese generali a un'app?

Tuttavia, ho notato che la mia app è di circa 15.5 MB residenti. Rispetto al browser (+/- 35 MB) mi sento abbastanza sicuro, ma noto che la dimensione residente della mia app è in costante aumento.

La domanda è: quanto sovraccarico è coinvolto nell'aggiunta di un thread?

Mi chiedo anche se la parola chiave synchronized riscontri sempre più latenza con ogni nuovo thread che è presente?

Grazie!

+2

25 thread è un sacco di discussioni per un'applicazione mobile. Che cosa fa? –

+2

Se stai facendo questa domanda, è probabilmente tempo di riconsiderare la tua architettura. –

+0

Va notato che i thread dormono per il 99% della loro durata e si attivano solo quando necessario. @ Silico è un'app Bluetooth, che esegue comunicazioni avanzate con i computer incorporati di un Veicolo. Connessioni Bluetooth multiple, visualizzazione su schermo e attività in background che devono avvenire in base a una pianificazione. –

risposta

2

I fili sono molto utili ma allo stesso tempo possono essere una minaccia. Sto lavorando a un progetto per verificare le minacce presentate da un'applicazione. Se si esegue la parte superiore tramite la shell adb, specifica in particolare quanti thread può essere in esecuzione un'applicazione.

L'utilizzo del processore è direttamente proporzionale al numero di thread. Questo significa più che il numero di thread più alto è il sovraccarico. Anche se sembrano mantenere la tua attività libera dal rimanere bloccata a tempo, può diventare un vero dolore sincronizzare le loro azioni e quindi potresti avere un punto morto, non molto carino. Anche più no di thread sollevano sospetti sul comportamento di un'applicazione. Quindi dovrebbero essere utilizzati nello spirito che devono essere.

+0

Pensiero interessante: "più thread ~ = attività senza scrupoli" ... Tutti i miei thread sono su e giù, ma io ' Lo prendo in considerazione :) Grazie per il consiglio di adb, non mi ero reso conto che il programma di utilità principale mostrava discussioni! –

+4

Er non c'è nulla di sospetto dal punto di vista della sicurezza su un'app con molti thread. – hackbod

+0

@hackbod forse hai ragione, ma ho trovato le discussioni come fastidiose. Alcune applicazioni a cui non mi interessa attività una volta che ho smesso in qualche modo di mantenere il processo in vita utilizzando thread. Ora che chiamerei attività sospette1 – Shouvik

0

Un numero incontrollabile di thread può essere sospeso per l'applicazione. La tua APP sembra avere già un numero maggiore di thread per l'app per dispositivi mobili.

sincronizzato comporta la manutenzione per blocchi sugli oggetti.

Verificare se è possibile utilizzare ThreadPoolExecutor. Ciò contribuirà a limitare i thread nel sistema, inoltre ridurrà poco il sovraccarico di creazione e distruzione dei thread.

2

Se si creano e si distruggono i thread più e più volte, allora sì, sarà tassativo e causerà un sovraccarico. È possibile eliminarlo utilizzando il ThreadPool, che mantiene disponibile una cache di thread per l'esecuzione. In caso contrario, i thread sono il modo per andare oltre i processi.

Si consiglia di pensare a modifiche pratiche all'architettura. Ad esempio, se stai mantenendo più thread attivi per il gusto di avere un'interfaccia utente reattiva, (cioè in attesa di input) anche se un particolare thread sarebbe stato usato solo dopo cinque salti di menu allora forse non è necessario mantenere i thread vivi tutti il tempo. Raramente ho usato 15 thread distinti in una singola applicazione, anche quando quell'applicazione eseguiva una massiccia macchina utensile .... (Avevo ripetuti thread di lavoro andando però). Non dimenticare che i thread devono ancora essere programmati, quindi non tenerli intorno inutilmente.

Infine, assicurati di non avere gli stessi vecchi problemi con il programma parallelo; evitare deadlock ecc ....

+0

Quasi tutti i thread vengono creati una sola volta per tutta la durata dell'app. Grazie per la nota sulla macchina utensile, che aiuta a metterla in prospettiva. Sì, ne ho usati così tanti per mantenere l'app molto reattiva all'utente. Ho anche scoperto che i numerosi livelli di applicazione funzionano bene insieme nell'ambiente asincrono multi-thread. Mi piace l'idea di threadPool, grazie. –

3

Per una certa prospettiva qui, un'applicazione Browser appena lanciata ha circa 20 thread in esecuzione. Avere 25 discussioni non è assolutamente irragionevole. Dipende davvero da cosa stai facendo con loro.

app_1  17309 67 182452 27944 ffffffff 00000000 S com.android.browser 
app_1  17310 17309 182452 27944 ffffffff 00000000 S HeapWorker 
app_1  17311 17309 182452 27944 ffffffff 00000000 S Signal Catcher 
app_1  17312 17309 182452 27944 ffffffff 00000000 S JDWP 
app_1  17313 17309 182452 27944 ffffffff 00000000 S Compiler 
app_1  17314 17309 182452 27944 ffffffff 00000000 S Binder Thread # 
app_1  17315 17309 182452 27944 ffffffff 00000000 S Binder Thread # 
app_1  17317 17309 182452 27944 ffffffff 00000000 S CookieSyncManag 
app_1  17319 17309 182452 27944 ffffffff 00000000 S WebViewCoreThre 
app_1  17321 17309 182452 27944 ffffffff 00000000 S AsyncTask #1 
app_1  17322 17309 182452 27944 ffffffff 00000000 S AsyncTask #2 
app_1  17323 17309 182452 27944 ffffffff 00000000 S WebViewCoreThre 
app_1  17324 17309 182452 27944 ffffffff 00000000 S http0 
app_1  17325 17309 182452 27944 ffffffff 00000000 S http1 
app_1  17326 17309 182452 27944 ffffffff 00000000 S http2 
app_1  17327 17309 182452 27944 ffffffff 00000000 S http3 
app_1  17328 17309 182452 27944 ffffffff 00000000 S WebViewWorkerTh 
app_1  17329 17309 182452 27944 ffffffff 00000000 S AsyncTask #3 
app_1  17330 17309 182452 27944 ffffffff 00000000 S AsyncTask #4 
app_1  17332 17309 182452 27944 ffffffff 00000000 S AsyncTask #5 
Problemi correlati