2009-06-21 20 views
17

Actualmente estoy escribiendo un artículo sobre la plataforma Android. Después de algunos research, está claro que Dalvik tiene margen de mejora. Me preguntaba, ¿cuál crees que sería el mejor uso del tiempo de un desarrollador con este objetivo?¿Cómo mejorarías Dalvik? La máquina virtual de Android

La compilación de JIT parece ser la más importante, pero también he escuchado que esto sería de uso limitado en una máquina de tan bajo nivel de recursos. ¿Alguien tiene un recurso o datos que respalden esto?

¿Hay alguna otra opción que deba tenerse en cuenta? Además de desarrollar un kit de desarrollo nativo robusto para eludir la VM.

Para aquellos que estén interesados, hay una conferencia que ha sido grabada y puesta en línea con respecto al Dalvik VM.

Cualquier idea bienvenida, ya que esta pregunta parece subjetiva voy a aclarar que la respuesta que voy a aceptar debe tener alguna justificación para los cambios propuestos. Cualquier dato que lo respalde, como la mejora en Sun JVM cuando se introdujo, sería una gran ventaja.

+1

¿Cómo se puede afirmar en un documento que: "está claro que Dalvik tiene margen de mejora" sin saber qué son esas habitaciones? Repartir la compilación de JIT es mucho: todo lenguaje interpretado se beneficiaría de ello. ¿Qué más notaste? –

+0

Disculpas, debería haber aclarado más. Primero, cuando digo papel, esto es más como un preliminar para mi trabajo y, por lo tanto, no es necesario que sea tan formal como una tesis publicada. Segundo, si haces clic en el enlace de investigación en el texto anterior, verás algunos de mis primeros resultados. A lo que me refiero es que Dalvik está lejos de ser tan rápido como el código nativo, en comparación con JVM en un escritorio, hay margen de mejora. También después de haber visto la charla de Dalvik VM, el otro enlace de arriba, los diseñadores reconocen que el rendimiento no es óptimo. Solo me gustaría algunas ideas para optimizaciones aún no implementadas en Dalvik – gav

+0

Para aquellos que miran este Q & A hoy y se preguntan, las versiones anteriores de Android/Dalvik no tenían JIT. Android 2.2 introdujo JIT para Dalvik. Android 2.1 lo tenía en el código fuente, pero se deshabilitó en las compilaciones de producción. – HRJ

Respuesta

18
  1. mejor recolección de basura: compactar al mínimo (para eliminar los problemas de fragmentación de memoria que experimentan hoy en día), lo ideal es menos intensivo de la CPU en hacer la colección en sí (para reducir los "mis velocidades de cuadro juego chupan" quejas)
  2. JIT, como usted cita
  3. documentación suficiente que, cuando se combina con un NDK, alguien lo suficientemente loco podría compilar Dalvik bytecode a código nativo para una opción de compilación AOT
  4. que sea separable del propio Android, de manera que otros proyectos puedan experimentar con ella y las contribuciones de la comunidad pueden llegar en mayor cantidad y a un ritmo más rápido

Estoy seguro de que podría encontrar otras ideas si las necesita.

0

Uno de los principales problemas con Dalvik es el rendimiento, que es terrible, lo escuché, pero una de las cosas que más me gustaría es la adición de más idiomas.

La JVM ha tenido proyectos comunitarios para ejecutar Python y Ruby en la plataforma, e incluso se han desarrollado lenguajes especiales como Scala, Groovy y Closure. Sería bueno ver estos (y/u otros) en la plataforma Dalvik también. Sun también ha estado trabajando en la máquina Da Vinci, una extensión de tipado dinámico de la JVM, que indica un cambio importante respecto de la filosofía de "un idioma se adapta a todos" que Sun ha seguido en los últimos 15 años.

+0

Android ahora es compatible con el lenguaje de scripting. No es mucho, pero mejorará: http://stackoverflow.com/questions/101754/is-there-any-way-to-run-python-on-android. –

3
  1. JIT. Lo que no ayuda es un montón de basura. Es posible que sea más selectivo con respecto a qué código JIT pero con una décima parte del rendimiento del código nativo siempre será limitado

  2. Decent GC. Los recolectores de basura generacionales modernos no tienen grandes tartamudeos.

  3. Mejor análisis de código. Hay muchos casos en los que no es necesario realizar asignaciones/liberaciones, mantener bloqueos, etc. Se le permite escribir código limpio en lugar de optimizaciones que hacen que la máquina es mejor en

En teoría la mayoría de los lenguajes de alto nivel (Java, JavaScript, Python, ...) debería estar dentro del 20% del rendimiento del código nativo para la mayoría de los casos. Pero requiere que el proveedor de la plataforma gaste más de 100 años en desarrollador. Sun Java se está poniendo bueno. También han estado trabajando en eso por 10 años.

+4

Su último punto resalta la falla fundamental de diseño al elegir escribir Dalvik en lugar de comenzar con una base de código establecida. Si eligieran Mono, estarían años por delante de donde están ahora como plataforma. –

Cuestiones relacionadas