Las aplicaciones de Android se interpretan en lugar de compilarse. ¿Esto los hace más lentos que las aplicaciones de iOS en tiempo de ejecución?
applications
ios
Armon Safai
fuente
fuente
Respuestas:
Java no se interpreta en Android. El desarrollador compila las aplicaciones de Android en código de bytes . Bytecode es una representación compacta del programa: más pequeño que el código fuente escrito por el programador, pero aún no ejecutable directamente por la CPU. Algunas optimizaciones, como la eliminación de código muerto, se pueden realizar en esta etapa.
Cuando carga la aplicación en un dispositivo, Dalvik JVM compila el código de bytes en código ejecutable nativo, justo cuando está a punto de ejecutarse. Esta es una compilación justo a tiempo . Causa una breve ralentización mientras el programa espera a ser compilado, pero después de eso no hay sobrecarga de rendimiento, porque el código se ha compilado en código ejecutable nativo.
Hay algunas ventajas de rendimiento al hacerlo de esta manera en lugar de compilar por adelantado en la computadora del desarrollador. La aplicación se puede compilar para la CPU particular del teléfono, aprovechando sus características de hardware y utilizando sus características de rendimiento. Por ejemplo, puede usar operaciones de punto flotante de hardware si la CPU lo admite. Además, un inteligente compilador JIT (es cierto que Dalvik no es tan inteligente) puede monitorear la forma en que se ejecuta el programa y realizar optimizaciones basadas en la forma en que el programa se usa en uso real. Podría volver a compilar el código con una mejor sugerencia de sucursal una vez que haya visto qué opciones están activadas y desactivadas en su entorno, en su teléfono. Un compilador inicial no tiene esta información para usar.
Dalvik usa el caché Dalvik y otras técnicas para mitigar los inconvenientes de la compilación JIT. El nuevo JVM para Android L y posterior, ART, reemplaza el JIT por completo con un compilador anticipado . Esto compila el código de bytes al código ejecutable nativo cuando se instala la aplicación, para obtener la mayoría de las ventajas de JIT sin la demora en cargar la aplicación.
No olvide que las aplicaciones de Android no consisten completamente en Java. Los desarrolladores tienen el NDK para escribir todas o parte de sus aplicaciones en C o C ++, para partes críticas de rendimiento de la aplicación, especialmente para 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ómputo.
Entonces, realmente, no hay una respuesta simple a su pregunta. El uso de JIT en lugar de la compilación inicial hace que algunas cosas sean más rápidas, algunas más lentas. Es solo una parte del rendimiento general del sistema operativo.
fuente
Como esta es una pregunta amplia, aquí hay una respuesta amplia.
"¿Las aplicaciones de iOS son más rápidas que las de Android ya que las aplicaciones de Android se interpretan?"
En primer lugar, las aplicaciones de iOS no son "más rápidas que" las aplicaciones de Android.
En segundo lugar, con respecto al tema "Las aplicaciones de Android se interpretan". Esto es algo que diría sobre la informática, como "hace 15 años": como puede ver en la discusión anterior, la situación es mucho más complicada hoy en día; Tecnologías completamente nuevas han aparecido. El concepto "compilado es más rápido que interpretado". fue relevante comparar, ya sabes, perl con el código de máquina hace 20 años; las cosas han avanzado tanto que el problema no se puede aplicar realmente claramente a "iOS V Android" hoy.
En tercer lugar, hay otros problemas en la programación móvil que inundan totalmente estas consideraciones. Solo un ejemplo en el terreno, los programadores móviles se sorprenden al manejar grandes listas de desplazamiento de imágenes, carga diferida y problemas similares. La forma en que los dos sistemas operativos y las diversas bibliotecas populares manejan estos problemas críticos a menudo inundan otros problemas.
En cuarto lugar, solo un problema abrumador más en los móviles son los problemas del conjunto de chips de gráficos y las diversas relaciones complicadas de eso con el software, OpenGL, etc. Por ejemplo, Apple está lanzando un sistema que llaman "Metal" en relación con estos problemas, y Android está lanzando su propia "cosita" en este campo. Estos problemas relacionados con la canalización de gráficos son tremendamente importantes para la forma en que las aplicaciones "se sienten" en la mano.
La respuesta muy breve a su pregunta es "compilado V. interpretado" es básicamente un punto de discusión desactualizado, ¿sabe?
(Además, no encuentro particularmente un Note3 "más lento" que un iPhone. Además, parte de esto es puro artefacto; existen teléfonos Android económicos: simplemente no se fabrican iPhones de bajo rendimiento, por lo que algunas personas pueden tener ideas de esto.)
fuente
Porque las aplicaciones interpretadas no significa que siempre sean lentas. A veces son más potentes y dinámicos en comparación con uno compilado. 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 un lenguaje interpretado, una vez puede cambiar aleatoriamente la secuencia de ejecución. Por lo tanto, puedo decir que depende de un desarrollador a otro y de la programación.
Sin embargo, Java (lenguaje de programación de Android) no se interpreta sino que se compila JIT. Eso significa que los programas de Android se compilan justo antes de ejecutarlos, lo que proporciona un rendimiento razonablemente similar al Objetivo 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 iOS. En otras palabras, la próxima versión de Android presumiblemente será tan rápida como iOS.
Actualizar
Los lenguajes de programación generalmente se dividen en una de dos categorías: compilados o interpretados. Con un lenguaje compilado, el código que ingresa se reduce a un conjunto de instrucciones específicas de la máquina antes de guardarse como un archivo ejecutable. Con los idiomas interpretados, el código se guarda en el mismo formato que ingresó. Los programas compilados generalmente se ejecutan más rápido que los interpretados porque los programas interpretados deben reducirse a instrucciones de máquina en tiempo de ejecución. Sin embargo, con un lenguaje interpretado puede hacer cosas que no se pueden hacer en un lenguaje compilado. Por ejemplo, los programas interpretados pueden modificarse agregando o cambiando funciones en tiempo de ejecución. También suele ser más fácil desarrollar aplicaciones en un entorno interpretado porque no tiene que volver a compilar su aplicación cada vez que quiera probar una pequeña sección.
fuente