¿Las aplicaciones de iOS son más rápidas que las de Android ya que las aplicaciones de Android se interpretan?

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

Es no una buena pregunta porque las aplicaciones de Android no se interpretan, así como la correcta respuesta apunta realmente a cabo.

— Aaronaught

Normalmente, la respuesta aceptada que no es la mejor respuesta no es un gran problema, ya que el objetivo es ayudar a quien hizo la pregunta (ver esta meta publicación). Pero este es un caso bastante extremo @ArmonSafai La respuesta que seleccionó como correcta está llena de información errónea y ha pasado el punto de ser salvable con ediciones. Por favor considere seleccionar otra respuesta.

— Selali Adobor

Tenga en cuenta que algunas corporaciones importantes, incluida IBM, están escribiendo aplicaciones importantes en Java en estos días. Dado un compilador Just-In-Time (JIT), que es una parte estándar de una máquina virtual Java moderna, el rendimiento es realmente comparable con cualquier otro lenguaje de alto nivel. Java no ha sido solo "un lenguaje interpretado" durante muchos años.

— keshlam

Los compiladores JIT no están vinculados al concepto de JVM en absoluto. Hay JVM que no usan compiladores JIT, incluso comerciales. Algunas variaciones de JVM de IBM no habilitan JIT de forma predeterminada, sino que se configuran de manera predeterminada para la compilación AOT. Además, una pequeña nota, "las principales aplicaciones en Java en estos días" probablemente era un poco más adecuado hace una década y media (IBM estaba agregando a Java antes de 1997)

— Selali Adobor

La pregunta es algo engañosa. Una aplicación iOS "nativa" está escrita en Objective-C (o Swift) y compilada, mientras que una aplicación Android "estándar" está escrita en Java y compilada en bytecode. Ver la respuesta de @ DanHulme. Pero es posible escribir aplicaciones para cualquier plataforma en HTML y JavaScript usando, por ejemplo, PhoneGap / Cordova. Por lo general, se percibe que una aplicación HTML se ejecuta más lentamente que una aplicación nativa en la misma plataforma. Entonces, si una aplicación similar para la "otra" plataforma parece más lenta, tal vez sea porque fue creada usando tecnología diferente.

— David

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.

— Dan Hulme
fuente

+1 para una gran explicación. En realidad estaba esperando una respuesta como esta.

— MANI

En realidad, no es muy diferente del viejo debate cansado ".NET / Java vs. C ++ performance" en PC. Son manzanas y naranjas.

— Aaronaught

@ArmonSafai Muy cierto.

— Dan Hulme

@MTilsted: Esa es la clase de verdad, pero cachés casi todo, así que lo que está hablando probablemente ocurrirá solamente la primera vez que se ejecuta una aplicación.

— Aaronaught

El principal problema aquí es que Dalvik es considerado como una JVM "normal". Entre estar basado en el registro, en lugar de estar basado en la pila como HotSpot (debido a la naturaleza de los procesadores ARM frente a los que apuntó HotSpot [como IA32]), es el uso de Zygote y el concepto de archivos odex (es decir, toda la idea de no [más o menos] yendo directamente del archivo de clase al cargador de clases), tratar a Dalvik como una JVM normal seguramente conducirá a algunos conceptos erróneos. Especialmente porque muchos de los detalles de la implementación de HotSpot a menudo se asocian erróneamente con JVM en general (como su compilador JIT).

— Selali Adobor

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.)

— Fattie
fuente

-3

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.

— See-Sharp
fuente

¿qué quiere decir "una vez puede cambiar aleatoriamente la secuencia de ejecución y cómo están más potente y dinámica también no estoy diciendo que theyre lento, sólo que son más lentos, aunque sea un poco??.

— Armon safai

Esto no es del todo cierto. Es engañoso decir que no tener que volver a compilar es una ventaja, ya que aún necesita crear un archivo APK e implementarlo en el dispositivo de prueba. Google no decidió usar Java: Android ya estaba basado en Java antes de que Google lo comprara. Los archivos APK no contienen el código "en el mismo formato que ingresó [el programador]".

— Dan Hulme

Microsoft .NET se compila en código IL, que también se interpreta al igual que Java se compila en bytecode.

— Esben Skov Pedersen

Mucha información en esta respuesta realmente no es relevante o técnicamente correcta. Sinceramente, sugiero que esta respuesta sea totalmente revisada por precisión técnica.

— Aza

Java generalmente no es un lenguaje interpretado , a menos que esté lidiando con una implementación JVM inusual. La compilación JIT no es lo mismo que un intérprete, por lo que la mayoría de esta respuesta es honestamente irrelevante en el contexto del rendimiento de Android, ya que utiliza JIT.

— eldarerathis