¿Android o Java usan más potencia ya que se ejecuta en una máquina virtual?

Dado que las aplicaciones de Android se ejecutan en una JVM (Dalvik VM) que es básicamente un procesador virtual, y cada instrucción virtual tiene que asignarse a la instrucción nativa del conjunto de chips subyacente, ¿esta asignación genera más consumo de energía debido a la sobrecarga de esta asignación?

Esta pregunta puede extenderse a Java y también expresarse como "¿las aplicaciones Java usan más potencia?". ¿Es por eso que los teléfonos Android tienen una duración de batería tan terrible en comparación con otras plataformas / teléfonos?

Editar : Basado en las respuestas, he aclarado algunos puntos porque había hablado erróneamente de JVM y Dalvik indistintamente. En este momento, estoy hablando de Java solo para preguntar si usa más energía y, en caso afirmativo, ¿eso también se aplica conceptualmente a Android y da como resultado una menor duración de la batería?

Contexto : citado de Wikipedia:

1. El código de bytes de Java es análogo al lenguaje ensamblador para el código C.
2. Desde el punto de vista de un compilador, la máquina virtual Java es solo otro procesador con un conjunto de instrucciones, Java bytecode, para el cual se puede generar código.
3. JVM tiene una arquitectura de pila. Dalvik es una máquina virtual de proceso que no es el mismo tipo de virtualización que JVM y tiene una arquitectura de registro.

Dado que el lenguaje de programación Java se compila en bytecode (como ensamblado) y se ejecuta en un procesador virtual, proporciona una verdadera portabilidad del código de software. Además, dado que hay una JVM para Linux y Linux se ha portado en hardware abierto, la combinación puede proporcionar una verdadera portabilidad de la aplicación en toda la pila.

Potencia : la pregunta se reduce esencialmente a esto: para el mismo conjunto de funcionalidades de su código de software o aplicación, qué porcentaje de los ciclos de reloj de su CPU se atribuyen al entorno de tiempo de ejecución. Esto es con el entorno de compilación Just-In-Time de las JVM modernas, donde si el bytecode se compila a la instrucción nativa del conjunto de chips subyacente, entonces el tiempo de ejecución solo debería estar activo durante la compilación jit. Entonces, ¿cuánto más ciclos de reloj de CPU se utilizan para tener el entorno de tiempo de ejecución que se espera que genere una sobrecarga de consumo de energía? Solo me interesa el aspecto del consumo de energía, y no el rendimiento relativo en comparación con los lenguajes estáticamente escritos y construidos, y entiendo las ventajas de Java. Subpreguntas que pueden estar relacionadas:

• ¿El tiempo de ejecución de Java utiliza la libc por su funcionalidad?
• ¿Alguno de estos puntos relacionados con el consumo de energía se traducen en Dalvik VM y Android?
• En lugar de generalizar el bajo consumo de batería de Android sin hablar de la pantalla y los conjuntos de chips inalámbricos, hablemos de cómo el iPhone 5 tiene una batería de 1440 mAH que es pequeña en comparación con los teléfonos Nexus modernos. Todo este tren de pensamiento (Java, procesador virtual, mapeo de instrucciones, Android) surgió porque un amigo leal al iPhone afirmó que esta podría ser la razón probable de que su iPhone tenga una mejor duración de la batería que mi (impresionante) nexo.

En cualquier caso, gracias por las respuestas a continuación.

Su pregunta se basa en muchos supuestos erróneos. Déjame intentar aclararlos:

• Dijiste "JVM (Dalvik VM)". Eso es como decir "Avión (bicicleta)". Estas dos cosas no tienen absolutamente nada que ver el uno con el otro.

• Dijiste "... que es básicamente un procesador virtual". Simplemente falso Es no el caso de que, cada vez que las palabras "Virtual Machine" o las siglas "VM" se usa en un contexto técnico, que es esencialmente equivalente a VMware Workstation . Esto se debe a productos como VMware , de hecho, emular un equipo completo, no sólo la CPU, y se ejecuta un sistema operativo en la parte superior de otro sistema operativo. Dalvik VM no funciona así. Ni siquiera cerca.

• Java es solo un lenguaje de programación. Es sintaxis Los programas Android / Dalvik utilizan la misma sintaxis o una muy similar a un lenguaje de programación de escritorio / servidor completamente no relacionado llamado Java, que se ejecuta en una máquina virtual Java. En teoría, podría escribir código Java que tenga casi la misma velocidad que el código C, ya que ambos son lenguajes de programación de alto nivel. El diablo está en los detalles de la implementación de las llamadas a la biblioteca y la forma en que está diseñado el tiempo de ejecución, que tiene muy poco que ver con la sintaxis del lenguaje.

• Es una generalización excesiva decir que Dalvik VM, Sun Java Hotspot JVM o la sintaxis del lenguaje de programación Java son responsables del alto consumo de energía. La razón es que tienes que comparar lo que sea que estés hablando con el rendimiento de otra cosa . En el caso más general, cuando solo está comparando las capacidades del "mejor caso" de ambas plataformas, en principio es posible crear aplicaciones Dalvik que sean tan rápidas o más rápidas que los programas en cualquier otra plataforma. Además de la gestión automática de memoria y la compilación JIT, características que son estándar en casi todos los entornos de programación en estos días, incluso en iOS y en JavaScript / HTML5, hay muy poco que separe a Dalvik de Objective-C, .NET, Ruby, the Oracle Hotspot JVM, Python, etc.

• La percepción de que "Java es lento" se debe a un problema con las versiones antiguas de Java, ya que no tenían un compilador Just-In-Time (JIT), o el JIT que tenían tenía una funcionalidad muy limitada. La JVM ha tenido un compilador Just-In Timepor mucho tiempo ahora. Un compilador JIT es parte del tiempo de ejecución (por ejemplo, la JVM) que toma el código de bytes independiente del procesador, por ejemplo, el código de bytes de Java, y lo compila en instrucciones nativas para la CPU. Este proceso se realiza cuando se inicia el programa Java, y los compiladores JIT avanzados pueden optimizar funciones o instrucciones individuales en tiempo de ejecución para mejorar su rendimiento en función de los resultados observados. Por ejemplo, si un método devuelve verdadero cada vez que se llama, pero del código de bytes original no es obvio que lo haría, el compilador JIT puede reconocer que solo devuelve verdadero y reemplazar la llamada de función con un hard- valor codificado de "verdadero". Esto es sólo un ejemplo.

• Las técnicas de compilación JIT y análisis de código dinámico en tiempo de ejecución han hecho grandes avances en los últimos años. Muchos en la comunidad de la informática creen que, en otra década o dos, el análisis sofisticado disponible en lenguajes interpretados / compilados dinámicamente, como Java, C # y Ruby, será tan avanzado que, en la mayoría de los casos, estos lenguajes se ejecutarán más rápido en tiempo de ejecución que lenguajes compilados estáticamente como C y C ++. Esto se debe a que los compiladores estáticos generalmente se limitan a compilar código en tiempo de compilación, y el código no se modifica en tiempo de ejecución. Sin embargo, en un entorno de ejecución en el código del programa puede volver a escribir en síDurante la ejecución para realizar de manera más eficiente, hay una gran cantidad de ventajas que se pueden lograr analizando el rendimiento del código y haciendo ajustes para reducir la complejidad del código o la cantidad de instrucciones que se ejecutan en la CPU. Para el código llamado con frecuencia, la inversión de tiempo requerida para realizar el análisis es muy superior a los beneficios de rendimiento de llamar repetidamente a un código más rápido.

• Cabe señalar que la VM Dalvik de Android también contiene un JIT y que no utiliza el mismo formato de código de bytes que la JVM de Sun / Oracle. El JIT de Dalvik está optimizado para entornos con poca memoria y es muy avanzado en cuanto a mejoras de rendimiento en tiempo de ejecución. Por lo tanto, es una coincidencia que JVM y Dalvik implementen optimizaciones similares para sus respectivos entornos de tiempo de ejecución basados ​​en Java, pero bajo el capó son bastante diferentes.

• No olvides que Dalvik mismo; el kernel de Linux; procesos del sistema de bajo nivel; y el núcleo de los navegadores web de Android (tanto Firefox como Chrome) están escritos en C / C ++ nativo, por lo que no tienen ninguna de las preocupaciones generales que tendría un programa Dalvik. Esto es lo mismo que iOS. Si está hablando de Android puro y no de la hincha del operador / tercero que se encuentra encima de él, una gran proporción de lo que comprende el núcleo de Android no está escrito usando Dalvik.

• Los desarrolladores de aplicaciones en Android también pueden, a su elección, escribir código nativo, sin pasar por Dalvik. Si un desarrollador de aplicaciones considera que Dalvik estaba actuando como un cuello de botella en el desempeño de su código, o que le agota la batería, simplemente podría escribir C / C ++ o incluso código de ensamblaje si así lo desea, sin tener que obtener la aprobación de Google para hacerlo, y distribuir su aplicación de esa manera.

Estas son algunas razones reales por las que un dispositivo con batería de Android, o cualquier dispositivo, puede tener problemas con la duración de la batería:

• Aplicaciones que mantienen despierta la CPU, la pantalla o la conexión de datos. En particular, los conjuntos de chips 4G como LTE utilizan una gran cantidad de energía cuando están encendidos, por lo que si tiene programas en segundo plano que activan continuamente el chip LTE para transferir unos pocos kilobytes de datos, eso agotará su batería muy rápido. La pantalla en los teléfonos inteligentes y tabletas modernos también consume mucha energía, a menos que reduzca el brillo al mínimo.

• "Bloatware" que se requiere para estar en el dispositivo y no se puede desinstalar. Algunos operadores sin escrúpulos requieren que ejecute bloatware que toma ciclos de CPU y mantiene la conexión de datos activa. Esto puede deberse a la incompetencia de los desarrolladores de software del bloatware, o a un objetivo intencional de monitorear sus actividades en su teléfono inteligente y enviarlas a un servidor remoto para la extracción de datos, que consume mucha energía para su batería.

Finalmente, no estoy de acuerdo con su evaluación de que Android tiene peores problemas de duración de la batería que en otras plataformas móviles. Ciertos teléfonos y dispositivos pueden tener problemas de duración de la batería, ya sea debido a la capacidad de la batería en relación con el consumo de energía del hardware; configuraciones de energía mal optimizadas (elegidas por el usuario, el operador o el fabricante); o aplicaciones de bloatware que mantienen los chips en el teléfono despiertos todo el tiempo. Pero por cada ejemplo de un dispositivo que tiene problemas de batería, puedo darle un contraejemplo de un dispositivo con excelente duración de batería. No hay una manera simple de generalizar que "es Dalvik" o "es Linux" o "es Java". La optimización de energía es una complicada mezcla de hardware / software de preocupaciones en competencia, incluido el rendimiento, la capacidad de respuesta, y las expectativas del usuario sobre la duración de la batería, con ventajas y desventajas para cada opción. Para comprender completamente el perfil de energía de un dispositivo, debe observar de cerca la batería, todo el hardware y todo el software que se ejecuta en el dispositivo.

En esta respuesta, compararé el rendimiento con Android e IOS, ya que los dos ocupan más del 80% de la cuota de mercado.

Las aplicaciones Java no usan más potencia. ( http://www.javarants.com/2004/05/04/looks-like-apple-should-switch/ ) Oracle VM de Java o en realidad Dalvik VM de Google se considera mucho más eficiente que el Objective-C de IOS. Java puede optimizar el código antes de que se ejecute en el teléfono, lo que podría resultar en un rendimiento mucho mejor. Las bibliotecas de Java son de código abierto y, por lo tanto, han sido optimizadas por cientos de desarrolladores diferentes. Por otro lado, con iOS, solo los desarrolladores de Apple pueden cambiar el código. Menos revisión = menos rendimiento potencial.

Los programas de Android también pueden ejecutar código C nativo que podría disputarse como más rápido que Object-C (el único lenguaje compatible con IOS).

La razón por la que Google decidió usar la VM Dalvik es por la portabilidad. Sé de cuatro arquitecturas de CPU diferentes que Android puede ejecutar oficialmente (ARM, MIPS, x86, I.MX). Mientras que cualquier otro sistema operativo del teléfono solo puede usar uno (ARM). ( http://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems ) Por lo tanto, comparar diferentes tipos de CPU con, por ejemplo, iPhone es injusto. Si Android se ejecutara en un iPhone, Android tendría un rendimiento y duración de la batería comparables.

"¿Las aplicaciones Java usan más potencia?" Simplemente no.
¿Por qué los teléfonos Android tienen una duración de batería tan terrible en comparación con otras plataformas / teléfonos? Muchos teléfonos Android se construyen más baratos que el iPhone de Apple, pero observe la diferencia de precio. El iPhone cuesta más debido a la batería mucho más grande que contiene (y en promedio es una CPU más lenta). Mi teléfono Android (Google Galaxy Nexus) tiene una duración de batería comparable a la del iPhone 4G, pero tiene especificaciones de hardware mucho más rápidas (1 GHz frente a 1,2 GHz).

EDITAR: Java puede optimizar el código sin el conocimiento requerido del programador. Perfecto, el código C siempre se ejecutará más rápido que Java / Objective-C / C #; Dicho esto, ¿cuántos programadores por ahí son perfectos? En el nivel JVM, Java y las bibliotecas siempre serán "más perfectas" debido a sus principios de desarrollo de código abierto. ( http://www.infoq.com/news/2012/03/Defects-Open-Source-Commercial )

EDIT 2: pequeño dato de información: el nuevo teléfono Android P780 de Lenovo: 42 horas de conversación frente a 12 horas en iPhone.

Sí, se relaciona con un mayor consumo de energía: las capas de abstracción lo harán. También conduce a una disminución de la velocidad (lado opuesto de la misma moneda; si algo tiene una sobrecarga mayor, llevará más tiempo realizarlo y, por lo tanto, usará más CPU). Si entiendo correctamente, esa es una de las ventajas de lo que hace el NDK : permitir aceleraciones para procesadores específicos escribiendo código específico.

Dicho esto, para la mayoría de los trabajos me imagino que los gastos generales "relacionados con la energía" de ejecutar una VM se ven eclipsados ​​por otras consideraciones: para la mayoría de los programas, el uso de pantallas y radios consumirá la mayor parte de la energía.

Con respecto a todos los demás carteles, creo que lo más importante aquí no es si C / C ++ / Java existe, sino qué están haciendo las aplicaciones.

Dado que el consumo de energía se mapea directamente con el procesamiento, me preguntaría qué procesamiento haría un programa.

Digamos que estás sumando números. Digamos que está agregando 2 con 2 en un ciclo infinito hasta llegar a 2.000.000. Surgen dos preguntas:

1. ¿Cómo se implementa: es un bucle for? ¿Es un bucle while? (¿Es un truco Goto / Label?)
2. Cómo se está optimizando el código.

Estas dos preguntas definen en última instancia cuántas operaciones debe realizar el procesador y, en última instancia, cuánta energía utiliza un dispositivo. Dicho esto, la "sobrecarga" de ejecutar un entorno virtualizado puede ser insignificante debido a la optimización previa realizada por Java en todo el programa, pero, de nuevo, todo depende de lo que esté haciendo la aplicación.

Si.

Las máquinas virtuales 'hacen todo dos veces', y no necesariamente de manera eficiente. Por lo tanto, utilizarán al menos el doble de potencia para procesar las mismas instrucciones que una 'máquina real'. La presencia de una máquina virtual ralentiza las cosas y usa más energía. Básicamente, los sistemas operativos como iOS y Windows harán todo más rápido y con menos consumo de energía.

Esto se traduce en diferencias reales en las transiciones de pantalla, carga de páginas, navegación, cosas así. Actualmente estoy comparando Android (VM) y Windows Phone, e incluso con un procesador más lento (1GHz vs 1.6GHz), Windows supera significativamente a Android haciendo el mismo tipo de tareas.

Sin embargo, lo que atrae la atención de la mayoría de las personas es cuando instalan una aplicación y de repente su batería se agota más rápidamente. En realidad, eso no se debe a la máquina virtual, sino a una aplicación que utiliza los recursos con avidez.

Toda la razón para un sistema operativo de máquina virtual, la portabilidad, no es una buena razón para basar un sistema operativo. ¿Ves personas comprando teléfonos con su arquitectura favorita y usando Android porque es portátil? ¿Ves a personas que renuncian a un mayor rendimiento y confiabilidad y ponen Android en sus teléfonos que no son Android? La gente compra un teléfono Android, un teléfono Windows o un iPhone, etc. No es práctico sacrificar el rendimiento por la portabilidad en dispositivos de bajo costo. Fue una buena idea que se convirtió en un fracaso.