Quali sono gli errori più facili da fare che possono essere i sink di prestazione su Android?Problemi comuni di prestazioni su Android?
La documentazione menziona "alcune operazioni in virgola mobile" possono essere "dell'ordine di millisecondi" - qualcuno ha provato questo?
Per motivi di discussione, supponiamo che funzioni su un dispositivo G1/simile.
Per suggerimenti prestazioni di rendering-specifici, vedere questi Google I/O 2009 colloqui:
Il motivo per cui vogliono evitare l'uso di float è perché è raramente implementato su CPU cpu (Probbly arm) e deve essere implementato in un software lento. Il punto fisso è usualmente surportato nell'hardware sebbene.
Alcuni telefoni implementano l'hardware in virgola mobile, ma dal momento che non si utilizza il telefono su cui la tua app può essere distribuita, non lo rischiano.
Un sacco di persone dicono anche di evitare l'uso di oggetti, ai tempi di telefoni molto lenti e java me persone usate per scrivere java proceduralmente con funzioni statiche. Non lo consiglierei però ora.
Non preoccuparti delle prestazioni finché non conosci che il codice presenta problemi importanti. I piccoli aggiustamenti (gli interi invece dei float, usando gli iteratori anziché l'enumerazione degli array espliciti) tendono ad essere davvero minimi e si sta meglio osservandoli quando l'app non funziona. Rendi più complesso il 5% del codice che è lento piuttosto che creare l'intera app.
Secondo gli utenti di Android, è necessario evitare di utilizzare i nomi dell'interfaccia per le raccolte. Per esempio, la migliore pratica standard per Java standard sarebbe dire
List<String> strings = new ArrayList<String>();
considerando che Android si dice che è meglio dichiararla con il suo tipo runtime
ArrayList<String> strings = new ArrayList<String>();
nota che - nonostante sia nella documentazione - questo non è in realtà vero. ho corretto questo nella documentazione per Froyo. (in particolare, la versione froyo della documentazione non conterrà alcun reclamo non supportato da un benchmark.) –
WRT virgola mobile:
su un G1, l'aggiunta di due float richiede circa 400ns. l'aggiunta di due interi richiede circa 250ns.
su un nexus uno in esecuzione eclair (pre-JIT), entrambe le operazioni richiedono circa 120ns. (gli intagli sono leggermente più veloci, ma dovresti fare il microbenchmarking per notare.) C'è una piccola differenza percentuale tra int e long, float e double, ma in fondo se puoi permetterti uno, puoi probabilmente permetterti l'altro.
altri dispositivi attuali saranno a metà strada tra questi estremi. (anche altre operazioni differiscono: la moltiplicazione è più costosa di addizione/sottrazione e la divisione è ancora più costosa, nessun dispositivo attuale ha divisione di interi hardware.)
ma non ossessionare nulla di ciò finché non si ha un problema . è probabile che i problemi di prestazioni si ridurranno a una scelta scadente dell'algoritmo o della struttura dei dati, proprio come lo sono sempre i problemi di prestazioni di tutti.
la maggior parte della documentazione corrente (Eclair) sulle prestazioni non è corretta. confronta le cose da te, sul dispositivo (s) che ti interessa.
ma se si fosse veramente chiedendo "che cosa dovrebbe un/server programmatore Java Desktop attenzione?", Io suggerirei: allocazione inutili. non hai un core di riserva per fare il tuo GC come fai sul desktop/server, e non hai gigabyte di heap come fai sul desktop/server. se stai facendo GC, non stai facendo un vero lavoro, e il tuo heap sarà al massimo di 24MiB sui dispositivi attuali. quindi potresti voler evitare l'allocazione non necessaria nei loop interni.
* ma non ossessionare su nulla di ciò fino a quando non si presenta un problema. è probabile che i problemi di prestazioni si ridurranno a una scelta scadente di algoritmo o struttura dati, proprio come lo sono sempre tutti i problemi di prestazioni di . * Questo è enorme. Posso darti un abbraccio? – Cheezmeister
Ho trovato che l'emulatore di AppInventor è estremamente lento per le operazioni in virgola mobile, anche su una macchina i3/4Gb 2014. Ho scritto un generatore di frattali per confrontare l'emulatore e ho scoperto che per calcolare un singolo pixel, a 10 iterazioni sono bastati più di due secondi - sì, 2.000 ms. Non ho completamente disinteressato per scoprire quali particolari operazioni sono così lente ma lo farò presto.
Ogni iterazione implica quattro moltiplicazioni, due aggiunte e una sottrazione, cinque variabili. Il test dopo ogni iterazione comporta due moltiplicazioni, un'aggiunta e due confronti - circa 30 flop. Non ho ancora ottimizzato il codice memorizzando i risultati per la successiva iterazione.
Chiaramente, se c'è un modo per forzare il punto fisso o utilizzare solo numeri interi che potrebbero aiutare, ma l'entità del problema che ho affrontato con questo piccolo progetto non è di buon auspicio.
Mentre sono d'accordo su non ottimizzare presto ecc, questo non è il problema qui. Se per esempio tutte le operazioni float prendono 1ms e tutte le operazioni int 1ns, progettare tutte le strutture dati per punto fisso dall'inizio è solo buon senso. – Viktor
Se hai un budget di 50ms per eseguire il lavoro, se impiega 1ms o 1ns non ha importanza. Ottieni il codice funzionante e poi preoccupati per i dettagli. Convertire tra punto fisso e float è un giorno o due di lavoro al meglio. Ottieni app con algoritmi efficienti e quindi se hai bisogno di fare queste ottimizzazioni. In quasi tutte le app che ho visto, le grandi prestazioni non sono mai in micro ottimizzazioni. Stanno facendo in modo che non stiate facendo cose stupide (disegnando oggetti 2x, ordinando quando non è necessario, ...). Ci sono casi in cui la microottimizzazione è corretta. Lo saprai quando succede – hacken