Android o Java consumano più energia poiché è in esecuzione su una macchina virtuale?

Poiché le applicazioni Android vengono eseguite su una JVM (Dalvik VM) che è fondamentalmente un processore virtuale e ogni istruzione virtuale deve essere mappata sull'istruzione nativa del chipset sottostante, questa mappatura comporta un maggiore consumo di energia a causa del sovraccarico di questa mappatura?

Questa domanda può essere estesa a Java e può anche essere definita come "le applicazioni Java usano più potenza?". È per questo che i telefoni Android hanno una durata della batteria così spaventosa rispetto ad altre piattaforme / telefoni?

Modifica : in base alle risposte che ho chiarito alcuni punti perché avevo erroneamente parlato di JVM e Dalvik in modo intercambiabile. In questo momento sto parlando di Java solo per chiedere se utilizza più energia e, in caso affermativo, si applica concettualmente anche ad Android e si traduce in una durata della batteria ridotta.

Contesto : citato da Wikipedia:

1. Il bytecode Java è analogo al linguaggio assembly per il codice C.
2. Dal punto di vista di un compilatore, la macchina virtuale Java è solo un altro processore con un set di istruzioni, bytecode Java, per il quale è possibile generare il codice.
3. JVM ha un'architettura stack. Dalvik è una macchina virtuale di processo che non è lo stesso tipo di virtualizzazione di JVM e ha un'architettura di registro.

Poiché il linguaggio di programmazione Java viene compilato in bytecode (simile ad un assembly) e viene eseguito su un processore virtuale, garantisce la portabilità del vero codice del software. Inoltre, poiché esiste una JVM per Linux e Linux è stato portato su hardware aperto, la combinazione può fornire una vera portabilità dell'applicazione su tutto lo stack.

Potenza : La domanda si riduce essenzialmente a questo - per lo stesso insieme di funzionalità del codice software o applicazione, quale percentuale dei vostri cicli di clock della CPU sono attribuiti all'ambiente fase di esecuzione. Questo è con l'ambiente di compilazione Just-In-Time delle moderne JVM in cui se il bytecode viene compilato secondo l'istruzione nativa del chipset sottostante, il runtime dovrebbe essere attivo solo durante la compilazione jit. Quindi, quanti più cicli di clock della CPU vengono consumati nell'ambiente di runtime che dovrebbe comportare un sovraccarico di consumo energetico. Sono interessato solo all'aspetto del consumo di energia, e non alle prestazioni relative rispetto ai linguaggi tipizzati e costruiti staticamente e capisco i vantaggi di Java. Sotto-domande che potrebbero essere correlate:

• Java Run time utilizza libc per la sua funzionalità?
• Qualcuno di questi punti relativi al consumo di energia si traducono in VM Dalvik e Android?
• Invece di generalizzare lo scarso consumo della batteria di Android senza parlare dello schermo e dei chipset wireless, parliamo di come l'iPhone 5 abbia una batteria da 1440 mAH che è minuscola rispetto ai moderni telefoni Nexus. L'intero gruppo di pensieri (Java, processore virtuale, mappatura delle istruzioni, Android) è nato perché un amico lealista di iPhone ha affermato che questo potrebbe essere il motivo probabile per il suo iPhone con una durata della batteria migliore rispetto al mio (fantastico) nesso.

In ogni caso, grazie per le risposte di seguito.

La tua domanda si basa su molti presupposti imperfetti. Vorrei provare a chiarirli:

• Hai detto "JVM (Dalvik VM)". È come dire "Aereo (bicicletta)". Queste due cose non hanno assolutamente nulla a che fare l'una con l'altra.

• Hai detto "... che è fondamentalmente un processore virtuale". Semplicemente falso. È non il caso che, ogni volta che i termini "Virtual Machine" o acronimo "VM" è usato in un contesto tecnico, che è sostanzialmente equivalente a VMware Workstation . Questo perché prodotti come VMware emulano infatti un intero computer, non solo la CPU, e eseguono un sistema operativo su un altro sistema operativo. Dalvik VM non funziona in questo modo. Neanche vicino.

• Java è solo un linguaggio di programmazione. È sintassi. I programmi Android / Dalvik usano la stessa o molto simile sintassi con un linguaggio di programmazione desktop / server completamente non correlato chiamato Java, che gira su una Java Virtual Machine. In teoria, potresti scrivere un codice Java che ha quasi la stessa velocità del codice C, poiché sono entrambi linguaggi di programmazione di alto livello. Il diavolo sta nei dettagli dell'implementazione delle chiamate della libreria e nel modo in cui è progettato il runtime, che ha ben poco a che fare con la sintassi del linguaggio.

• È una generalizzazione eccessiva affermare che Dalvik VM, Sun Java Hotspot JVM o la sintassi del linguaggio di programmazione Java sono responsabili di un elevato consumo energetico. Il motivo è che devi confrontare qualsiasi cosa tu stia parlando con le prestazioni di qualcos'altro . Nel caso più generale, quando si stanno solo confrontando le funzionalità "best-case" di entrambe le piattaforme, è in linea di principio possibile creare app Dalvik altrettanto veloci o più veloci dei programmi su qualsiasi altra piattaforma. Oltre alla gestione automatica della memoria e alla compilazione JIT - funzionalità che sono standard in quasi tutti gli ambienti di programmazione al giorno d'oggi, anche su iOS e JavaScript / HTML5 - c'è ben poco che separa Dalvik da Objective-C, .NET, Ruby, Oracle Hotspot JVM, Python e così via.

• La percezione che "Java sia lento" è dovuta a un problema con le vecchie versioni di Java, in quanto o non avevano un compilatore Just-In-Time (JIT), o il JIT che avevano era molto limitato in termini di funzionalità. La JVM ha avuto un compilatore Just-In Timeda molto tempo ormai. Un compilatore JIT è una parte del runtime (ad esempio, la JVM) che accetta il bytecode indipendente dal processore - ad esempio il bytecode Java - e lo compila in istruzioni native per la CPU. Questo processo viene eseguito all'avvio del programma Java e i compilatori JIT avanzati possono ottimizzare singole funzioni o istruzioni in fase di esecuzione per migliorare le loro prestazioni in base ai risultati osservati. Ad esempio, se un metodo restituisce true ogni volta che viene chiamato, ma non è ovvio dal bytecode originale che lo farebbe, il compilatore JIT può riconoscere che restituisce true e sostituire la chiamata di funzione con un hard- valore codificato di "true". Questo è solo un esempio.

• La compilazione JIT e le tecniche di analisi del codice dinamico di runtime hanno fatto enormi progressi negli ultimi anni. Molti nella comunità informatica credono che, in un altro decennio o due, l'analisi sofisticata disponibile in linguaggi interpretati / compilati in modo dinamico, come Java, C # e Ruby, sarà così avanzata che, nella maggior parte dei casi, questi linguaggi si eseguiranno più velocemente a runtime rispetto a linguaggi compilati staticamente come C e C ++. Questo perché i compilatori statici sono generalmente limitati alla compilazione del codice in fase di compilazione e il codice non viene modificato in fase di esecuzione. Ma in un ambiente di runtime in cui il codice del programma può riscrivere se stessodurante l'esecuzione per eseguire in modo più efficiente, è possibile ottenere un'enorme quantità di vantaggi analizzando le prestazioni del codice e apportando modifiche per ridurre la complessità del codice o il numero di istruzioni eseguite sulla CPU. Per il codice chiamato di frequente, il tempo necessario per eseguire l'analisi è ampiamente compensato dai vantaggi in termini di prestazioni derivanti dalla chiamata ripetuta di codice più veloce.

• Va notato che Android Dalvik VM contiene anche una JIT e che non utilizza lo stesso formato bytecode di Sun / Oracle JVM. Il JIT di Dalvik è ottimizzato per ambienti con poca memoria ed è molto avanzato per quanto riguarda i miglioramenti delle prestazioni di runtime. Quindi è in qualche modo una coincidenza che JVM e Dalvik implementino ottimizzazioni simili per il rispettivo ambiente di runtime basato su Java, ma sotto il cofano sono piuttosto diverse.

• Non dimenticare che Dalvik stesso; il kernel Linux; processi di sistema di basso livello; e il nucleo dei browser Web Android (sia Firefox che Chrome) sono scritti in C / C ++ nativo, e quindi non hanno nessuna delle preoccupazioni generali che un programma Dalvik avrebbe. Questo è lo stesso di iOS. Se stai parlando di Android puro e non del gonfiore di terze parti o di terze parti che si trova al di sopra di esso, una percentuale molto grande di ciò che comprende il core Android non è scritta usando Dalvik.

• Gli sviluppatori di applicazioni su Android possono anche, a loro discrezione, scrivere codice nativo, aggirando Dalvik. Se uno sviluppatore di applicazioni ritenesse che Dalvik stesse agendo come un collo di bottiglia nell'esecuzione del proprio codice, o facendogli scaricare troppa batteria, potrebbe semplicemente scrivere C / C ++ o addirittura codice assembly se lo avesse scelto, senza dover ottenere l'approvazione di Google per farlo e distribuire la loro app in questo modo.

Ecco alcuni dei motivi reali per cui un dispositivo Android alimentato a batteria, o qualsiasi dispositivo, potrebbe avere problemi con la durata della batteria:

• Applicazioni che mantengono attiva la CPU, lo schermo o la connessione dati. In particolare, i chipset 4G come LTE consumano molta energia quando sono accesi, quindi se si dispone di programmi in background che riattivano continuamente il chip LTE per trasferire alcuni kilobyte di dati, che scaricheranno la batteria molto velocemente. Lo schermo su moderni smartphone e tablet è anche ad alta intensità energetica, a meno che non si riduca al minimo la luminosità.

• "Bloatware" che deve essere sul dispositivo e non può essere disinstallato. Alcuni gestori senza scrupoli richiedono di eseguire bloatware che occupa cicli di CPU e mantiene attiva la connessione dati. Ciò può essere dovuto all'incompetenza degli sviluppatori software del bloatware o a un obiettivo intenzionale di monitorare le attività sullo smartphone e inviarle a un server remoto per il data mining, che richiede molta energia per la batteria.

Infine, non sono d'accordo con la tua valutazione secondo cui Android ha problemi di durata della batteria peggiori rispetto ad altre piattaforme mobili. Alcuni telefoni e dispositivi possono effettivamente avere problemi di durata della batteria, sia a causa della capacità della batteria relativa al consumo di energia dell'hardware; impostazioni di alimentazione scarsamente ottimizzate (elette dall'utente, dal corriere o dal produttore); o app bloatware che mantengono costantemente attivi i chip nel telefono. Ma per ogni esempio di dispositivo con problemi di batteria, posso fornirti un controesempio di dispositivo con un'eccellente durata della batteria. Non esiste un modo semplice per generalizzare che "è Dalvik" o "è Linux" o "è Java". L'ottimizzazione della potenza è un complicato miscuglio hardware / software di preoccupazioni concorrenti, tra cui prestazioni, reattività, e le aspettative degli utenti per la durata della batteria, con pro e contro per ogni scelta. Per comprendere appieno il profilo di potenza di un dispositivo, è necessario esaminare da vicino la batteria stessa, tutto l'hardware e tutto il software in esecuzione sul dispositivo.

In questa risposta confronterò le prestazioni con Android e IOS poiché i due occupano oltre l'80% della quota di mercato.

Le app Java non consumano più energia. ( http://www.javarants.com/2004/05/04/looks-like-apple-should-switch/ ) La VM Java di Oracle o in realtà la VM Dalvik di Google è considerata molto più efficiente della Objective-C di IOS. Java è in grado di ottimizzare il codice prima che venga eseguito sul telefono, il che potrebbe comportare prestazioni molto migliori. Le librerie Java sono Open Source e quindi sono state ottimizzate da centinaia di sviluppatori diversi. D'altra parte con IOS solo gli sviluppatori Apple sono in grado di modificare il codice. Meno recensioni = meno prestazioni potenziali.

I programmi Android sono anche in grado di eseguire codice C nativo che potrebbe essere contestato più velocemente di quanto Object-C (l'unica lingua supportata su IOS).

Il motivo per cui Google ha deciso di utilizzare la VM Dalvik è per la portabilità. Conosco quattro diverse architetture CPU su cui Android può funzionare ufficialmente (ARM, MIPS, x86, I.MX). Mentre ogni altro sistema operativo del telefono può utilizzarne solo uno (ARM). ( http://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems ) Quindi confrontare diversi tipi di CPU con, ad esempio, IPhone non è giusto. Se Android funzionasse su IPhone, Android sarebbe paragonabile a prestazioni e durata della batteria superiori.

"le applicazioni Java usano più potenza?" Semplicemente no.
Perché i telefoni Android hanno una durata della batteria così spaventosa rispetto ad altre piattaforme / telefoni? Molti telefoni Android sono più economici dell'iPhone di Apple, ma osservano la differenza di prezzo. L'iPhone costa di più a causa della batteria molto più grande con dentro (ed è in media CPU più lenta). Il mio telefono Android (Google Galaxy Nexus) ha una durata della batteria paragonabile a IPhone 4G ma ha specifiche hardware molto più veloci (1GHz contro 1.2GHZ).

EDIT: Java può ottimizzare il codice senza la conoscenza del programmatore richiesta. Perfetto, il codice C funzionerà sempre più velocemente di Java / Objective-C / C #; Detto questo, quanti programmatori là fuori sono perfetti? A livello di JVM Java e le librerie saranno sempre "più perfette" a causa dei suoi principi di sviluppo open source. ( http://www.infoq.com/news/2012/03/Defects-Open-Source-Commercial )

EDIT 2: piccola quantità di informazioni: il nuovo telefono Android P780 di Lenovo - 42 ore di conversazione contro 12 ore su IPhone.

Sì, si riferisce all'aumento del consumo di energia: lo faranno gli strati di astrazione. Porta anche a una diminuzione della velocità (lato opposto della stessa medaglia - se qualcosa ha un sovraccarico maggiore ci vorrà più tempo per eseguire e quindi utilizzare più CPU). Se capisco correttamente che è uno dei vantaggi di ciò che fa l' NDK : consentire accelerazioni per processori specifici scrivendo codice specifico.

Detto questo, per la maggior parte dei lavori immagino che le spese generali "legate all'alimentazione" della gestione di una VM siano sminuite da altre considerazioni: per la maggior parte dei programmi l'uso dello schermo e delle radio consumerà la maggior parte dell'energia.

Per quanto riguarda tutti gli altri poster, credo che ciò che conta di più non sia l'esistenza di C / C ++ / Java, ma ciò che le applicazioni stanno facendo.

Dal momento che il consumo di energia si associa direttamente all'elaborazione, mi chiedo quale elaborazione farebbe un programma.

Supponi di aggiungere numeri. Supponi di aggiungere 2 con 2 su un ciclo infinito fino a raggiungere 2.000.000. Sorgono due domande:

1. Come viene implementato: è un for-loop? È un ciclo while? (È un hack Goto / Label?)
2. Come viene ottimizzato il codice.

Queste due domande definiscono in definitiva quante operazioni deve essere eseguita dal processore e, infine, quanta potenza utilizza un dispositivo. Detto questo, il "sovraccarico" di esecuzione di un ambiente virtualizzato potrebbe essere trascurabile a causa della precedente ottimizzazione effettuata da Java sull'intero programma, ma, di nuovo, tutto dipende da ciò che l'applicazione sta facendo.

Sì.

Le macchine virtuali "fanno tutto due volte" e non necessariamente in modo efficiente. Pertanto, utilizzeranno almeno il doppio della potenza per elaborare le stesse istruzioni di una "macchina reale". La presenza di una macchina virtuale rallenta le cose e consuma più energia. Fondamentalmente, i sistemi operativi come iOS e Windows faranno tutto più velocemente e con un minore consumo di energia.

Questo si traduce in differenze reali nelle transizioni dello schermo, nel caricamento della pagina, nella navigazione, cose del genere. Attualmente sto confrontando Android (VM) e Windows Phone, e anche con un processore più lento (1 GHz contro 1,6 GHz), Windows supera significativamente Android facendo lo stesso tipo di attività.

Tuttavia, ciò che attira l'attenzione della maggior parte delle persone è quando installano un'app e improvvisamente la loro batteria si esaurisce più rapidamente. Questo non è in realtà dovuto alla macchina virtuale, ma a un'app che utilizza le risorse con fame.

L'intero motivo di un sistema operativo di una macchina virtuale, la portabilità, non è un buon motivo su cui basare un sistema operativo. Vedi persone che acquistano telefoni con la loro architettura preferita e usano Android perché è portatile? Vedi persone che rinunciano a prestazioni e affidabilità superiori e mettono Android sui loro telefoni non Android? Le persone acquistano un telefono Android, un Windows Phone o un iPhone, ecc. Sacrificare le prestazioni per la portabilità in dispositivi a basso costo è impraticabile. È stata una buona idea che è diventata un fallimento.