¿Por qué los desarrolladores de Android recomiendan universalmente usar un dispositivo real en lugar de confiar en el emulador? Bueno, la queja común que todos tenían era que el emulador era demasiado lento, pero con emuladores basados en virtualización en máquinas Intel (no funciona en Linux o máquinas antiguas y las aplicaciones basadas en NDK deben ser atendidas por separado) al menos ese problema está resuelto. Entonces, lo que da entonces, es una comparación de paridad de características entre un emulador y un dispositivo real.
# Limitación de características de hardware en el emulador
– No se admite el número IMEI (se devuelve 00000) o la ID del dispositivo.
– No es compatible con la dirección Mac.
– No hay soporte para pruebas de GPS en el mundo real.
– No hay soporte para la cámara.
– No es compatible con la reproducción y grabación de audio.
– No hay soporte para sensores (sensor de aceleración, sensor de gravedad, giroscopio)
– No hay soporte para realizar o recibir llamadas telefónicas reales. Sin embargo, puede simular llamadas telefónicas (realizadas y recibidas) a través de la consola del emulador.
– No hay soporte para determinar el estado conectado a la red (esta verificación está presente en la mayoría de las aplicaciones y necesita comentarios para que la aplicación funcione en el emulador)
– No hay soporte para determinar el nivel de carga de la batería y el estado de carga de CA
– No es compatible con Bluetooth.
– No hay soporte para conexiones USB.
– No es compatible con auriculares conectados al dispositivo.
– No hay soporte para determinar la inserción / expulsión de la tarjeta SD.
# Limitación de funciones de software en el emulador
– Algunas de las API se comportan de manera diferente o no funcionan en absoluto en el emulador (por ejemplo, API de Canvas como clipPath, drawPath, etc.). Pocos de los API de la barra de acción como setHasOptionsMenu se comportan de manera diferente en los dispositivos debido a la inconsistencia de la implementación entre los fabricantes.
– No hay soporte para openGL 2.0 API.
– No se puede probar la facturación en la aplicación.
– No hay soporte para eventos Multi Touch como pellizcar para hacer zoom, arrastrar, rotar, etc.
– PlayStore no es compatible con el emulador por debajo de 4.2.2, por lo que los servicios dependientes como Maps, Notificaciones Push no funcionan.
- ¿Puedo desarrollar y publicar una aplicación de Android con habilidades intermedias de Java dentro de 3-4 meses?
- ¿Cuáles son los componentes principales del ciclo de vida de desarrollo de una aplicación de Android?
- ¿Por qué ni siquiera Google puede escribir aplicaciones de Android que no se bloqueen?
- ¿Qué aplicaciones se desarrollan en Xamarin?
- ¿Es posible construir una aplicación de Android usando HTML5, CSS3 y JavaScript?
Entonces, hoy en día, si uno logra hacer una aplicación que no tiene ninguna de las características mencionadas anteriormente, ¿está bien usar un emulador para probar? Bueno, aparte del hecho de que una serie de chips complementarios como WLAN, Bluetooth, GPS, radio están presentes en el dispositivo real e interactúan con la CPU de maneras que no son predecibles y difíciles de simular en el emulador, el emulador no es real. procesador y no puede usar aceleradores físicos disponibles en un dispositivo real. También utiliza el hardware de la máquina host para muchas cosas, lo que significa que el acceso a la memoria y elementos similares se comportan de manera diferente en comparación con las pruebas en un dispositivo real. Como resultado, un emulador no puede ayudarte a probar.
– Aspecto exacto debido a la diferencia en las densidades de pantalla que pueden no corresponder correctamente con el emulador,
– Tiempos de carga de la aplicación, sería demasiado lento en un emulador normal y muy rápido en un emulador basado en x86.
– Rendimiento de la aplicación por los motivos mencionados anteriormente y por la falta de periféricos y servicios que se ejecutan en un dispositivo real.
– Rendimiento de la interfaz de usuario (Ver transiciones, cambios de orientación, desplazamiento)
– Diferencias del navegador (para aplicaciones web).
– Diferencias sutiles en los eventos táctiles de la interfaz de usuario.
– Uso / consumo de batería.
Todo dicho y hecho, incluso Google menciona que al crear una aplicación móvil, es importante que siempre pruebe su aplicación en un dispositivo real antes de lanzarla. Por lo tanto, tenemos que probar en un dispositivo real en algún momento durante el ciclo de desarrollo, entonces, ¿por qué no hacerlo temprano y detectar errores que, de lo contrario, podrían aparecer en una etapa muy tardía?
Personalmente, prefiero un dispositivo porque encuentro gestos táctiles como deslizar, desplazarse en un emulador muy cansado y torpe. No estoy diciendo que uno no deba usar el emulador en absoluto. Se puede usar para verificar las diferencias de UI en varios tamaños y densidades de pantalla. Pero eso es todo.
Aquí hay algunas publicaciones / publicaciones sobre por qué uno debería preferir dispositivos en lugar de emuladores.
pruebas – ¿Qué tan “bueno” es el emulador de Android? – Desbordamiento de pila
¿Qué usan los desarrolladores profesionales de Android para probar sus aplicaciones? emulador, dispositivo físico, otro?
Emulador de Android vs dispositivo real
¿Cuántos dispositivos Android necesito para realizar pruebas exhaustivas?
Cómo la mayoría de las empresas prueban para Android. En promedio, los desarrolladores mantienen unos 20 dispositivos para las pruebas de Android.
¿Cómo prueban sus aplicaciones los mejores desarrolladores de Android de control de calidad? El | TechCrunch
Pruebas de Android en dispositivos y emuladores
Así es como se ve el desarrollo para Android | TechCrunch
