studio - ¿Por qué Android usa Java?

oracle demanda a google (9)

Algunos puntos:

Java es un lenguaje conocido, los desarrolladores lo saben y no tienen que aprenderlo
es más difícil dispararse con Java que con código C / C ++ ya que no tiene aritmética de puntero
se ejecuta en una máquina virtual, por lo que no es necesario volver a compilarlo para cada teléfono y fácil de asegurar
gran cantidad de herramientas de desarrollo para Java (ver punto 1)
varios teléfonos móviles ya usaban Java ME, por lo que Java era conocido en la industria
la diferencia de velocidad no es un problema para la mayoría de las aplicaciones; si fuera así, debes codificar en un lenguaje de bajo nivel

De acuerdo, esto realmente debería pedírselo a alguien de Google, pero solo quiero otras opiniones.

Incluso Android admite aplicaciones de código nativo, la principal herramienta de desarrollo es Java. ¿Pero por qué? Quiero decir, ¿no es demasiado lento interpretar el código en un dispositivo móvil? Al presentar Froyo, Google dijo que el nuevo compilador JIT puede lograr aplicaciones 2-5 veces más rápidas. Esto significa que el uso de Java sobre el código nativo es 2 veces más lento.

Sí, sé que usar aplicaciones de código administrado es más seguro en términos de estabilidad del sistema, ya que la máquina virtual tiene un mejor control del programa, pero aún así, esta caída en el rendimiento es enorme, y no veo ningún motivo para usarlo.

Como se mencionó en otra parte, el problema principal es que Android está diseñado como un sistema operativo portátil, para ejecutarse en una amplia variedad de hardware. También se basa en un marco y un lenguaje familiar para muchos desarrolladores móviles existentes.

Finalmente, diría que es una apuesta contra el futuro: independientemente de los problemas de rendimiento que puedan existir, se volverá irrelevante a medida que mejore el hardware. Igualmente, logrando que los desarrolladores codifiquen contra una abstracción, Google puede arrancar y cambiar el sistema operativo subyacente mucho más fácilmente que si los desarrolladores estaban codificando las API de POSIX / Unix.

Para la mayoría de las aplicaciones, la sobrecarga de usar un lenguaje basado en VM sobre nativo no es significativo (el cuello de botella para las aplicaciones que consumen servicios web, como Twitter, es principalmente la creación de redes). Palm WebOS también demuestra esto, y eso usa JavaScript en lugar de Java como idioma principal.

Dado que casi todas las máquinas virtuales JIT compilan hasta el código nativo, la velocidad del código sin formato a menudo es comparable con la velocidad nativa. Una gran cantidad de retrasos atribuidos a los lenguajes de alto nivel tienen menos que ver con la sobrecarga de la VM que otros factores (un tiempo de ejecución de objetos complejo, acceso a la memoria de ''seguridad'' al verificar los límites, etc.).

También recuerde que, independientemente del idioma utilizado para escribir una aplicación, gran parte del trabajo real se realiza en API de nivel inferior. El lenguaje de nivel superior a menudo solo encadena las llamadas API juntas.

Hay, por supuesto, muchas excepciones a esta regla: juegos, audio y aplicaciones gráficas que superan los límites del hardware del teléfono. Incluso en iOS, los desarrolladores a menudo descienden a C / C ++ para obtener velocidad en estas áreas.

El código nativo no es necesariamente más rápido que el código Java. ¿Dónde están los datos de tu perfil que muestran que el código nativo podría funcionar más rápido?

Por qué Java?

Android se ejecuta en muchas plataformas de hardware diferentes. Necesitará compilar y optimizar su código nativo para cada una de estas plataformas diferentes para ver los beneficios reales.
Hay una gran cantidad de desarrolladores que ya son competentes en Java.
Java tiene un gran soporte de código abierto, con muchas bibliotecas y herramientas disponibles para facilitar la vida de los desarrolladores.
Java lo protege de muchos de los problemas inherentes al código nativo, como pérdidas de memoria, mal uso del puntero, etc.
Java les permite crear aplicaciones de espacio aislado y crear un mejor modelo de seguridad para que una aplicación incorrecta no pueda eliminar todo su sistema operativo.

El nuevo JIT está ejecutando las aplicaciones 2 a 5 veces más rápido que el antiguo dalvikVM (ambos JAVA). Entonces la comparación no es C sobre JAVA, sino JIT sobre dalvikVM.

En el nivel de código de bytes, Android no usa Java. La fuente es Java, pero no usa una JVM.

En primer lugar, se trata de lo mismo Windows Mobile o el iPhone, el .NET Framework necesita su propia máquina virtual y cacao.

E incluso si el rendimiento no es el mejor, porque es una interpretación del código de bytes, Android ofrece a toda la comunidad Java como posibles desarrolladores. Más aplicaciones, más clientes, etc.

Para finalizar, ningún rendimiento no es tan malo, es por eso que java se usa incluso en dispositivos más pequeños (ver JavaMe).

En primer lugar, según Google, Android no usa Java. Es por eso que Oracle está demandando a Google. Oracle afirma que Android infringe cierta tecnología Java, pero Google dice que es Dalvik.

En segundo lugar, no he visto un intérprete de código de bytes de Java desde 1995.

¿Puedes respaldar tu conjetura de rendimiento con algunos puntos de referencia reales? El alcance de sus presunciones no parece justificado dada la información de antecedentes inexacta que proporciona.

Java tiene un argumento bastante convincente para que Google lo use en Android: tiene una gran base de desarrolladores. Todos estos desarrolladores están (algo así como) listos para desarrollar su plataforma móvil.

Tenga en cuenta que, técnicamente hablando, Android no usa Java puro .

La mejora de la estabilidad del sistema es muy importante en un dispositivo como un teléfono celular.

La seguridad es aún más importante. El entorno Android permite a los usuarios ejecutar aplicaciones semi-confiables que podrían explotar el teléfono de maneras realmente desagradables sin una seguridad excelente. Al ejecutar todas las aplicaciones en una máquina virtual, usted garantiza que ninguna aplicación puede explotar el núcleo del sistema operativo a menos que haya un defecto en la implementación de la máquina virtual. La implementación de VM, a su vez, es presumiblemente pequeña y tiene una superficie de seguridad pequeña y bien definida.

Quizás lo más importante es que cuando los programas se compilan para codificar una máquina virtual, no es necesario recompilarlos para hardware nuevo. El mercado de los chips telefónicos es diverso y cambia rápidamente, así que eso es un gran problema.

Además, el uso de Java hace que sea menos probable que las aplicaciones que las personas escriben sean explotables por sí mismas. Sin exceso de memoria, errores con punteros, etc.