Leo en un blog un articulo que deja mucho que desear:
http://www.elandroidelibre.com/2016/...os-antutu.html
No conozco al escritor, ni ganas tengo tampoco, pero creo que vale la pena exponer un punto de vista valido, y preciso para tratar de responder esta pregunta, y claro, no lo voy a poner en terminos de procesador como lo expone el "escritor" respecto del "articulo" en cuestion.
Pues bueno, todos estamos de acuerdo (espero) con la siguiente tesis:
" los celulares echos por apple ocupan de menos recursos para brindar un mejor rendimiento que los fabricados por la competencia "
Donde "competencia", entiendase por Android. Ahora bien, a que se debe que esto suceda?
Bien, desde mi punto de vista, la respuesta es una sola palabra : java
SI! java, este amigo es el culpable de todo, les aseguro que una aplicacion nativa de android que ocupe puramente codigo de maquina, sin tener que ejecturarse atravez de la jvm sera mucho mas eficiente y rivalizaria facilmente con las de Apple.
La maquina virtual de java, sobre la que corren todas aplicaciones de android es una version reducida y "optimizada", pero sigue siendo java...
![]()
La jvm es una capa mas de software sobre el hardware del dispositivo que ademas soporta (en el caso de android) linux como SO, pero, en ios, todas las aplicaciones se desarrollan no para una maquina virtual, sino para ejecutarse directamente sobre iOS.
Y la pregunta es porque??? porque google opto por esta arquitectura? y Java?? yo personalmente creo que se debe a que es un lenguaje muy popular, y encontrar desarrolladores no seria un problemas, ademas, una capa extra de software trae ventajas:
- Multiplataforma: cuandos telefonos con distintas arquitecturas tenemos en el mercado?, para ejecutar java, solo se ocupa que el telefono tenga la jvm adecuada..
- Seguridad: un proceso java es totalmente ajeno al OS, y puede ser eliminado facilmente.
- Es un lenguaje popular y muy conocido, por lo que mucha gente no ocupa un entrenamiento "brutal" para desarrollar, si ya viene de java.
Y las desventajas:
- es muy "comelon" de recursos, la jvm no se distingue por ser precisamente noble con el huesped, su consumo de recursos es elevado y grosero. Solamente iniciar la jvm consume bastante memoria del huesped.
- Es una capa mas de software, por lo que el codigo se tiene que traducir de una capa a otra, hasta llegar al "hardware", eso es malo cuando los recursos son limitados.
Yo personalmente creo que la jvm puede requierir entre un 30 ~ 35 % de los recursos del huesped para "virtualizar" bien un proceso comparado con un proceso nativo, por lo que un proceso nativo puede rondar entre un 40 a un 60% mas rapido... es por eso que el famoso "codigo de maquina" es siempre mas eficiente...
Soluciones?
1. Cache: pues cache para las aplicaciones por ejemplo buscan optimizar una aplicacion "pre" cargando las aplicaciones en memoria para evitar "lag" en la carga, pero lastimozamente eso no funciona tan bien cuando la aplicacion es muy grande.. como juegos (les suena?), pero si con aplicaciones pequenas (de uso diario)...
2. Jit: lo que es una mentira que hace tiempo IBM hace tiempo abandono.. hhaha, los famosos "just in time" son compiladores que buscan optimizar el ejecutable para que el codigo que se ejecute en java sea mas eficiente, pero eso (creo yo) es historia, porque el compilador jdk ya es bastante eficiente.
3. Bibliotecas nativas, si! me parece que esta la verdadera solucion, pero requiere de un verdadero compromiso, el codigo java es mucho mas eficiente en ambientes con arquitectura sparc, y la jvm mucho mas pequena, porque? pues porque Java fue creado con base en esa arquitectura, si una libreria nativa se pueda crear para optimizar el acceso a recursos el resultado seria excelente.. creo que es el caso de vulkan, pero el problema? se ocupa de compromiso por parte de los fabricantes.. osea: no...
Pero respondimos la pregunta? No, porque en realidad nadie puede precisar que tan optimizado esta el jvm, pero una cosa es segura, es un peso mas que nuestros telefonos tienen que llevar, les guste o no, cosa que no llevan los de la manzana, y es por eso que manejan un unico modelo, y es por eso tambien, que son mas eficientes, pero... preguntemonos, es esa diferencia de milisegundos (en muchos casos) o segundos, tan crucial como para dar mas dinero que tanto nos cuesta?
Saludos
http://www.elandroidelibre.com/2016/...os-antutu.html
No conozco al escritor, ni ganas tengo tampoco, pero creo que vale la pena exponer un punto de vista valido, y preciso para tratar de responder esta pregunta, y claro, no lo voy a poner en terminos de procesador como lo expone el "escritor" respecto del "articulo" en cuestion.
Pues bueno, todos estamos de acuerdo (espero) con la siguiente tesis:
" los celulares echos por apple ocupan de menos recursos para brindar un mejor rendimiento que los fabricados por la competencia "
Donde "competencia", entiendase por Android. Ahora bien, a que se debe que esto suceda?
Bien, desde mi punto de vista, la respuesta es una sola palabra : java
SI! java, este amigo es el culpable de todo, les aseguro que una aplicacion nativa de android que ocupe puramente codigo de maquina, sin tener que ejecturarse atravez de la jvm sera mucho mas eficiente y rivalizaria facilmente con las de Apple.
La maquina virtual de java, sobre la que corren todas aplicaciones de android es una version reducida y "optimizada", pero sigue siendo java...
La jvm es una capa mas de software sobre el hardware del dispositivo que ademas soporta (en el caso de android) linux como SO, pero, en ios, todas las aplicaciones se desarrollan no para una maquina virtual, sino para ejecutarse directamente sobre iOS.
Y la pregunta es porque??? porque google opto por esta arquitectura? y Java?? yo personalmente creo que se debe a que es un lenguaje muy popular, y encontrar desarrolladores no seria un problemas, ademas, una capa extra de software trae ventajas:
- Multiplataforma: cuandos telefonos con distintas arquitecturas tenemos en el mercado?, para ejecutar java, solo se ocupa que el telefono tenga la jvm adecuada..
- Seguridad: un proceso java es totalmente ajeno al OS, y puede ser eliminado facilmente.
- Es un lenguaje popular y muy conocido, por lo que mucha gente no ocupa un entrenamiento "brutal" para desarrollar, si ya viene de java.
Y las desventajas:
- es muy "comelon" de recursos, la jvm no se distingue por ser precisamente noble con el huesped, su consumo de recursos es elevado y grosero. Solamente iniciar la jvm consume bastante memoria del huesped.
- Es una capa mas de software, por lo que el codigo se tiene que traducir de una capa a otra, hasta llegar al "hardware", eso es malo cuando los recursos son limitados.
Yo personalmente creo que la jvm puede requierir entre un 30 ~ 35 % de los recursos del huesped para "virtualizar" bien un proceso comparado con un proceso nativo, por lo que un proceso nativo puede rondar entre un 40 a un 60% mas rapido... es por eso que el famoso "codigo de maquina" es siempre mas eficiente...
Soluciones?
1. Cache: pues cache para las aplicaciones por ejemplo buscan optimizar una aplicacion "pre" cargando las aplicaciones en memoria para evitar "lag" en la carga, pero lastimozamente eso no funciona tan bien cuando la aplicacion es muy grande.. como juegos (les suena?), pero si con aplicaciones pequenas (de uso diario)...
2. Jit: lo que es una mentira que hace tiempo IBM hace tiempo abandono.. hhaha, los famosos "just in time" son compiladores que buscan optimizar el ejecutable para que el codigo que se ejecute en java sea mas eficiente, pero eso (creo yo) es historia, porque el compilador jdk ya es bastante eficiente.
3. Bibliotecas nativas, si! me parece que esta la verdadera solucion, pero requiere de un verdadero compromiso, el codigo java es mucho mas eficiente en ambientes con arquitectura sparc, y la jvm mucho mas pequena, porque? pues porque Java fue creado con base en esa arquitectura, si una libreria nativa se pueda crear para optimizar el acceso a recursos el resultado seria excelente.. creo que es el caso de vulkan, pero el problema? se ocupa de compromiso por parte de los fabricantes.. osea: no...
Pero respondimos la pregunta? No, porque en realidad nadie puede precisar que tan optimizado esta el jvm, pero una cosa es segura, es un peso mas que nuestros telefonos tienen que llevar, les guste o no, cosa que no llevan los de la manzana, y es por eso que manejan un unico modelo, y es por eso tambien, que son mas eficientes, pero... preguntemonos, es esa diferencia de milisegundos (en muchos casos) o segundos, tan crucial como para dar mas dinero que tanto nos cuesta?
Saludos