Las aplicaciones de Android se interpretan en lugar de compilarse. ¿Esto hace que sean más lentas que las aplicaciones de iOS en tiempo de ejecución?
Respuestas
¿Demasiados anuncios?
Java no se interpreta en Android. Las aplicaciones de Android se compilan en bytecode por el promotor. El bytecode es una representación compacta del programa: más pequeño que el código fuente escrito por el programador, pero no directamente ejecutable por la CPU. En esta fase se pueden realizar algunas optimizaciones, como la eliminación de código muerto.
Cuando se carga la aplicación en un dispositivo, la JVM Dalvik compila el bytecode a código nativo ejecutable, justo cuando está a punto de ejecutarse. Esto es justo a tiempo compilación. Causa una breve ralentización mientras el programa espera a ser compilado, pero después no hay sobrecarga de rendimiento, porque el código ha sido compilado a código ejecutable nativo.
Hay algunas ventajas de rendimiento al hacerlo de esta manera en lugar de compilar por adelantado en el ordenador del desarrollador. La aplicación puede ser compilada para la CPU particular del teléfono, aprovechando sus características de hardware y utilizando sus características de rendimiento. Por ejemplo, puede utilizar operaciones de punto flotante por hardware si la CPU lo admite. Además, un compilador JIT inteligente (hay que admitir que Dalvik no es tan inteligente) puede supervisar la forma en que se ejecuta el programa y realizar optimizaciones basadas en la forma en que se utiliza el programa en el uso real. Puede volver a compilar el código con mejores sugerencias de bifurcación una vez que haya visto qué opciones están activadas y desactivadas en tu entorno, en tu teléfono. Un compilador por adelantado no tiene esta información para usarla.
Dalvik utiliza el Caché de Dalvik y otras técnicas para mitigar los inconvenientes de la compilación JIT. La nueva JVM para Android L y posteriores, ART, sustituye por completo el JIT por un antes de tiempo compilador. Esto compila el bytecode a código ejecutable nativo cuando se instala la aplicación, para obtener la mayoría de las ventajas del JIT sin el retraso en la carga de la aplicación.
No olvides que las aplicaciones de Android no se componen enteramente de Java. Los desarrolladores tienen la NDK para escribir toda o parte de sus aplicaciones en C o C++, para las partes de la aplicación que son críticas para el rendimiento, especialmente para los juegos. Las interfaces de propósito especial, como OpenGL y Renderscript, permiten a los programadores aprovechar el hardware especial, como la GPU y el coprocesador SIMD, para algunos tipos de cálculo.
Así que, en realidad, no hay una respuesta sencilla a tu pregunta. El uso de JIT en lugar de la compilación por adelantado hace que algunas cosas sean más rápidas y otras más lentas. Es sólo una parte del rendimiento general del sistema operativo.
user29440
Puntos
255
Dado que se trata de una pregunta amplia, he aquí una respuesta amplia.
"¿Son las aplicaciones de iOS más rápidas que las de Android, ya que éstas se interpretan?"
En primer lugar, las aplicaciones de iOS no son "más rápidas" que las de Android.
En segundo lugar, respecto al tema "Las aplicaciones de Android son interpretadas". Esto es algo que se diría sobre la informática, como "hace 15 años": como se puede ver en la discusión anterior, la situación es mucho más complicada hoy en día; tecnologías totalmente nuevas han pasado a primer plano. El concepto "¡compilado es más rápido que interpretado!" era relevante comparando, ya sabes, el perl con el código máquina hace 20 años; las cosas han avanzado tanto que la cuestión no puede aplicarse realmente con claridad a "iOS V Android" hoy en día.
En tercer lugar, hay otras cuestiones en la programación de móviles que eclipsan totalmente estas consideraciones. Por ejemplo, los programadores de móviles se preocupan por el manejo de grandes listas de imágenes, la carga lenta y otras cuestiones similares. La forma en que los dos sistemas operativos, y las diversas bibliotecas populares, manejan estas cuestiones críticas a menudo eclipsa otras cuestiones.
En cuarto lugar, otra cuestión abrumadora en los móviles es la del conjunto de chips gráficos y las diversas y complicadas relaciones de éste con el software, OpenGL, etc. Por ejemplo, Apple está sacando un sistema que llaman "Metal" en relación con estos problemas, y Android está sacando su propia "cosita" en este campo. Estas cuestiones relacionadas con la canalización de los gráficos son tremendamente importantes para la "sensación" de las aplicaciones en la mano.
La respuesta muy corta a tu pregunta es "compilado V. interpretado" es básicamente un punto de discusión obsoleto, ¿sabes?
(Además, un Note3 no me parece especialmente "más lento" que un iPhone. Además, parte de esto es puro artefacto - sí existen teléfonos Android baratos: simplemente no se fabrican iPhones de bajo rendimiento, por lo que algunas personas pueden tener ideas incorrectas a partir de esto).
See-Sharp
Puntos
318
Que las aplicaciones sean interpretadas no significa que sean siempre lentas. A veces son más potentes y dinámicas que las compiladas. Como todos los códigos en la aplicación compilada se compilan una vez y la salida se mantiene en forma de bibliotecas o ejecutables, mientras que en el lenguaje interprated, una vez puede cambiar al azar la secuencia de ejecución. Así que puedo decir, que depende de desarrollador a desarrollador y hay forma de programación.
Sin embargo, Java (el lenguaje de programación de Android) no se interpreta, sino que se compila en JIT. Esto significa que los programas de Android se compilan justo antes de ejecutarlos, lo que ofrece un rendimiento razonablemente similar al de Objective C de iOS.
Más recientemente, el marco ART de Android precompila las aplicaciones, por lo que se ejecutan de la misma manera que las aplicaciones de iOS. En otras palabras, la próxima versión de Android será presumiblemente tan rápida como la de iOS.
Actualización
Los lenguajes de programación suelen pertenecer a una de estas dos categorías: Compilados o interpretados. Con un lenguaje compilado, el código que se introduce se reduce a un conjunto de instrucciones específicas de la máquina antes de guardarlo como un archivo ejecutable. En el caso de los lenguajes interpretados, el código se guarda en el mismo formato que el introducido. Los programas compilados suelen ejecutarse más rápido que los interpretados, ya que éstos últimos deben reducirse a instrucciones de máquina en tiempo de ejecución. Sin embargo, con un lenguaje interpretado se pueden hacer cosas que no se pueden hacer en un lenguaje compilado. Por ejemplo, los programas interpretados pueden modificarse a sí mismos añadiendo o cambiando funciones en tiempo de ejecución. También suele ser más fácil desarrollar aplicaciones en un entorno interpretado porque no hay que recompilar la aplicación cada vez que se quiere probar una pequeña sección.
