Le app Android vengono interpretate anziché compilate. Questo li rende più lenti delle app iOS in fase di runtime?
Le app Android vengono interpretate anziché compilate. Questo li rende più lenti delle app iOS in fase di runtime?
Risposte:
Java non è interpretato su Android. Le app Android vengono compilate in bytecode dallo sviluppatore. Bytecode è una rappresentazione compatta del programma: più piccola del codice sorgente scritto dal programmatore, ma non ancora eseguibile direttamente dalla CPU. In questa fase è possibile apportare alcune ottimizzazioni, come la rimozione del codice morto.
Quando carichi l'app su un dispositivo, Dalvik JVM compila il bytecode in codice eseguibile nativo, proprio mentre sta per essere eseguito. Questa è una compilazione just-in-time . Provoca un breve rallentamento mentre il programma attende di essere compilato, ma in seguito non vi è alcun sovraccarico di prestazioni, poiché il codice è stato compilato in codice eseguibile nativo.
Ci sono alcuni vantaggi prestazionali nel farlo in questo modo invece di compilare in anticipo sul computer dello sviluppatore. L'app può essere compilata per la CPU specifica sul telefono, sfruttando le sue funzionalità hardware e utilizzando le sue caratteristiche prestazionali. Ad esempio, può utilizzare operazioni hardware in virgola mobile se la CPU lo supporta. Inoltre, un compilatore JIT intelligente (è vero, Dalvik non è così intelligente) può monitorare il modo in cui il programma viene eseguito ed eseguire ottimizzazioni in base al modo in cui il programma viene utilizzato nell'uso reale. Potrebbe ricompilare il codice con un migliore suggerimento di diramazione una volta che ha visto quali opzioni sono attivate e disattivate nel proprio ambiente, sul telefono. Un compilatore iniziale non ha queste informazioni da usare.
Dalvik utilizza la cache Dalvik e altre tecniche per mitigare gli svantaggi della compilazione JIT. La nuova JVM per Android L e successive, ART, sostituisce interamente la JIT con un compilatore in anticipo . Questo compila il bytecode in codice eseguibile nativo quando l'app è installata, per ottenere la maggior parte dei vantaggi di JIT senza il ritardo nel caricamento dell'app.
Non dimenticare che le app Android non sono interamente composte da Java. Gli sviluppatori hanno l' NDK per scrivere tutte o parte delle loro app in C o C ++, per le parti critiche delle prestazioni dell'app, in particolare per i giochi. Interfacce speciali come OpenGL e Renderscript consentono ai programmatori di sfruttare hardware speciale come la GPU e il coprocessore SIMD per alcuni tipi di calcolo.
Quindi davvero, non c'è una risposta semplice alla tua domanda. L'uso di JIT invece della compilazione anticipata rende alcune cose più veloci, altre più lente. È solo una parte delle prestazioni complessive del sistema operativo.
Poiché questa è una domanda ampia, ecco una risposta ampia.
"Le app iOS sono più veloci delle app Android poiché le app Android vengono interpretate?"
Innanzitutto le app iOS non sono "più veloci" delle app Android.
In secondo luogo, per quanto riguarda il problema "Le app Android vengono interpretate". Questo è qualcosa che diresti sull'informatica, come "15 anni fa": come puoi vedere dalla discussione sopra, la situazione oggi è molto più complicata; tecnologie completamente nuove sono venute alla ribalta. Il concetto "compilato è più veloce di quello interpretato!" era pertinente confrontando, sai, perl con il codice macchina 20 anni fa; le cose sono andate avanti così tanto che il problema non può essere realmente applicato chiaramente a "iOS V Android" oggi.
In terzo luogo, ci sono altri problemi nella programmazione mobile che sommergono totalmente tali considerazioni. Solo un esempio sul campo, i programmatori di telefonia mobile si sbarazzano della gestione di grandi elenchi scorrevoli di immagini, caricamento lento e problemi simili. Il modo in cui i due sistemi operativi e le varie librerie popolari gestiscono questi problemi critici spesso sommerge altri problemi.
In quarto luogo, solo un altro problema travolgente sui cellulari è il problema del chipset grafico e le varie relazioni complicate di ciò con il software, OpenGL e così via. Ad esempio, Apple sta uscendo con un sistema che chiamano "Metal" in relazione a questi problemi e Android sta uscendo con il proprio "oggetto" in questo campo. Questi problemi intorno alla pipeline grafica sono estremamente importanti per il modo in cui le app "sentono" nelle tue mani.
La risposta molto breve alla tua domanda è "compilata V. interpretata" è fondamentalmente un punto di discussione obsoleto che conosci?
(Inoltre, non trovo in particolare un Note3 "più lento" di un iPhone. Inoltre, alcuni di questi sono artefatti puri: esistono telefoni Android economici: semplicemente non sono realizzati iPhone a basso rendimento, quindi alcune persone potrebbero non avere idee da questo.)
Perché le app interpretate non significano che sono sempre lente. A volte sono più potenti e dinamici rispetto a quello compilato. Poiché tutti i codici nell'app compilata vengono compilati una volta e l'output viene mantenuto in forma di librerie o eseguibili, mentre in linguaggio interpretato, una volta è possibile modificare in modo casuale la sequenza di esecuzione. Quindi posso dire che dipende dallo sviluppatore allo sviluppatore e dal modo di programmare.
Tuttavia, Java (il linguaggio di programmazione di Android) non viene interpretato ma viene compilato JIT. Ciò significa che i programmi Android vengono compilati appena prima di eseguirli, offrendo prestazioni ragionevolmente simili all'obiettivo iOS di iOS.
Più recentemente, il framework ART di Android precompila le app, quindi vengono eseguite allo stesso modo delle app iOS. In altre parole, la prossima versione di Android sarà presumibilmente veloce quanto iOS.
Aggiornare
I linguaggi di programmazione generalmente rientrano in una delle due categorie: compilata o interpretata. Con una lingua compilata, il codice inserito viene ridotto a un set di istruzioni specifiche della macchina prima di essere salvato come file eseguibile. Con le lingue interpretate, il codice viene salvato nello stesso formato inserito. I programmi compilati generalmente funzionano più velocemente di quelli interpretati perché i programmi interpretati devono essere ridotti alle istruzioni della macchina in fase di esecuzione. Tuttavia, con un linguaggio interpretato puoi fare cose che non possono essere fatte in un linguaggio compilato. Ad esempio, i programmi interpretati possono modificarsi aggiungendo o modificando le funzioni in fase di esecuzione. Di solito è anche più semplice sviluppare applicazioni in un ambiente interpretato perché non è necessario ricompilare l'applicazione ogni volta che si desidera testare una piccola sezione.