2010-12-13 13 views
12

No estoy seguro si alguien más lo notó, pero el emulador de Gingerbread funciona como un perro, con desplazamiento, navegación e interacción, todo lo cual lleva mucho más tiempo y es mucho más agitado. Incluso obtuve un ANR en el navegador cuando traté de usarlo: http://www.androidpolice.com/2010/12/06/walkthrough-and-hands-on-with-the-gingerbread-ui-the-new-gingerbread-keyboard-in-all-its-sexiness/ (mira hacia la parte inferior).La instancia del emulador de Gingerbread es mucho más lenta que Froyo y más abajo. ¿Por qué?

Acabo de leer sobre el nuevo StrictMode en http://android-developers.blogspot.com/2010/12/new-gingerbread-api-strictmode.html y sobre todas las mejoras de rendimiento en Gbread, pero mi experiencia hasta el momento sugiere todo lo contrario.

¿Podemos llegar al fondo de esto? Me da miedo abrir una instancia de Gingerbread en este punto.

Respuesta

2

Todas las respuestas anteriores tienen sus ventajas y deben tenerse en cuenta, pero tenga en cuenta que la implementación de Google de una máquina virtual para simular dispositivos no es tan buena como las de Microsoft y Apple; puede que no sea mucho lo que puede hacer, pero asegúrese optimizas la configuración y obtienes una máquina mejor.

Con la introducción de Honeycomb, el sistema android está utilizando más poder de gráficos para hacer la representación de la interfaz de usuario. Esto, cuando se ejecuta en un simulador, no puede usar de forma nativa la potencia gráfica del hardware de su PC, pero la mayoría emula el hardware del teléfono, lo que siempre resulta en una pérdida de rendimiento. Se han puesto a disposición emuladores X86 más genéricos, como VMWare, pero esto puede demorar un tiempo en estar disponible para Android SDK. Hasta que esté disponible un puerto X86 de Android Honeycomb que pueda aprovechar su GPU nativa, el emulador será lento.

La única solución real es comprar un dispositivo Honeycomb para el trabajo de desarrollo.

+1

Y probablemente descubra que tiene que rootearlo para que sea más fácil hacer las cosas que hacen los desarrolladores, anulando así la garantía. –

+0

Yo recomendaría no comprar ningún dispositivo Samsung para el desarrollo, a menos que tenga Android Vanilla, no continuarán el soporte para el dispositivo –

1

Vi una discusión de esto en otro lugar que sugería que los parámetros del emulador no estaban bien configurados. Si le das más memoria al emulador, aparentemente se vuelve mucho más útil.

+0

¿Qué quiere decir con "dar más memoria"? – yuku

+0

@yuku cuando crea un AVD puede asignarle una cantidad de RAM – bigstones

+0

¿Quiere decir la opción "Tamaño máximo del montón de la aplicación VM" al hacer el AVD? Si es así, ¿qué debería ser? –

2

Cuando crees tu nuevo AVD GingerBread (nivel API 9), dale una cantidad realista de RAM.

Por ejemplo el Nexus S tiene 512

Esto se hace en el "Crear nuevo dispositivo virtual Android (AVD)" de diálogo.

Presione "Nuevo ..." para agregar un nuevo parámetro de hardware y elija "Tamaño de ram de dispositivo", haga clic en Aceptar.

Editar la cantidad por defecto de 96 a 512.

+0

Como se señaló en la discusión de Brad Fitzpatrick ya, este ajuste no hizo ninguna diferencia. –

+2

Si lee con cuidado, Brad analiza el "Tamaño máximo del montón de la aplicación VM". Estoy hablando del "tamaño de ram de dispositivo", que es una propiedad muy diferente. Funcionó para mí De lo contrario, el valor predeterminado de 96 Mb no es suficiente para ejecutar tareas en segundo plano. – byeo

+0

No hizo ninguna diferencia para mí tampoco, podría ser que mi computadora necesita más RAM, aunque 4 gb serían suficientes ... –

1

Ahora que se puede editar fácilmente AVDs, he tratado de jugar con algunos de los ajustes de mi AVD pan de jengibre, y es finalmente bastante utilizable.

  • tarjeta SD: 500MiB
  • Piel: WVGA800
  • Abstracted densidad LCD: 240
  • Cache tamaño de la partición: 128MB
  • Max VM tamaño de la aplicación montón: 48
  • tamaño de la RAM
  • Dispositivo: 512

Mi suposición es que la RAM y el montón máximo de VM son los más importantes, pero higo ured sería mejor incluir todas las configuraciones, por lo que puede probar esto como punto de partida y luego modificarlo.

+1

Intenté estos ajustes exactos, sin diferencia visible para mí. –

+0

Cambiar el tamaño del montón de la aplicación MAX VM a 500 no es tan apropiado. Esto indica que cada aplicación puede usar hasta 500 MB de datos. Hasta hace poco, Delvic VM solo podía admitir algo menos de 48 MB en total. Por lo que sé, el dispositivo con más presupuesto de VM es el Xoom y creo que tiene 48 MB. Además, una sola aplicación no debería poder usar todos los recursos de un dispositivo Android. También recuerde que hay otras aplicaciones. Sé que la aplicación Android Services requiere alrededor de 50MB, y otros procesos/hardware nativos necesitan una porción de ese RAM. – ddcruver

+0

@ddcruver gracias por la captura; ese fue un error tipográfico que debería haber sido 50 pero 48 tiene sentido si eso es lo que usa Xoom. Actualizaré mi respuesta. –

0

mis sugerencias:

Fijar sólo una tarjeta SD si lo necesita y lo más probable es que no asignar más de lo necesario. Esto debe ser emulado de alguna manera.

Cualquier otra propiedad no se debe inflar más allá de su dispositivo de destino. Si aumenta el tamaño del almacenamiento dinámico de la aplicación VM y excede los valores de los dispositivos reales, tendrá bloqueos que ni siquiera notó durante el desarrollo.

Es cierto que los valores predeterminados no son suficientes para ciertas aplicaciones y Device Ram debe estar al menos 258 en los límites de su dispositivo Android objetivo. También recuerde que si su máquina host de desarrollo tiene poca memoria, la memoria que asignó para su emulador deberá intercambiarse y, al proporcionar una cantidad menor, evitará visitas innecesarias a la página.

0

Después de cambiar la resolución de la pantalla, el ram del dispositivo, dejando que el dispositivo se "caliente" y se ejecute en un nuevo hardware, grabé la velocidad del emulador Honeycomb.

Resultado en: http://www.youtube.com/watch?v=-7OR8vPsIak

me parece no es muy diferente a continuación, pan de jengibre en hardware antiguo. Espero que el GL acelerado por el host encuentre su camino al SDK pronto. Por ahora, podría ser posible un desarrollo sencillo, pero la creación o demostración de UX es imposible.

Cuestiones relacionadas