Share
En el mundo hiperconectado de hoy, la gente quiere resultados rápidos. Como desarrolladores móviles, somos más conscientes de esto que la mayoría. Nuestros usuarios no se sientan frente a un escritorio. Están en movimiento, ejecutando nuestras aplicaciones mientras intentan caminar, hablar y conducir, por lo que esperan experiencias ágiles. Entra entra.
Varios estudios de Akamai, Google y otros han correlacionado la velocidad del sitio web con la retención de usuarios. Y hasta ahora, la evidencia sugiere que las personas son al menos tan exigentes cuando usan aplicaciones nativas. En una encuesta a usuarios móviles realizada por Apigee, la principal queja acerca de las aplicaciones móviles es la congelación, y más del 44% de los usuarios encuestados dijeron que eliminarían una aplicación de rendimiento lento de inmediato..
Pregunta a Facebook sobre la importancia de las aplicaciones móviles rápidas. Cuando sus acciones cayeron en la adolescencia, Mark Zuckerberg dijo que basar su aplicación en HTML5 fue el mayor error que cometieron como compañía. ¿Por qué? Porque era lento. Tres semanas después del lanzamiento de la nueva aplicación nativa más rápida de Facebook, la calificación de la aplicación había subido de 1,5 a 4. Las aplicaciones lentas causan un gran dolor comercial. Usuarios perdidos. Dólares perdidos.
Al hablar por primera vez con los desarrolladores sobre el monitoreo del rendimiento de la aplicación en producción, la respuesta más común fue "Mi aplicación ya es rápida".
El problema es que, como el mundo de los fragmentos móviles, es difícil ofrecer una experiencia rápida y constante. ¿Cómo funciona su aplicación en China en un teléfono antiguo y una red lenta? Estoy dispuesto a apostar que no tienes ni idea. Ciertamente, no es lo mismo que funciona en su nuevo iPhone conectado a su oficina Wi-Fi.
El rendimiento depende completamente del contexto en el que se ejecuta su aplicación. Aquí hay una lista rápida pero no completa de errores de rendimiento:
Estamos acostumbrados a pensar en los problemas de Internet en términos de limitaciones de ancho de banda, pero en las redes celulares, la latencia es a menudo el factor dominante. En una red 3G, puede tomar alrededor de 2,5 segundos pasar de inactivo a conectado antes de que se transmita un solo byte. Y Sprint dice que la latencia promedio en su red 3G es de 400 ms. No importa qué tan rápido su servidor procese una solicitud si la respuesta es lenta para llegar al teléfono.
Como geeks, a menudo desarrollamos lo último y lo mejor, pero la mayor parte del mundo, incluidos los mercados masivos en los que le gustaría penetrar, se rinden a la velocidad para lograr la asequibilidad. Nuestras pruebas muestran que el código de CPU en un iPod 4G tarda aproximadamente cuatro veces más que en un iPhone 5S. En Android, la disparidad es aún más significativa..
Si su aplicación usa demasiada memoria, el sistema operativo lo mata. Para el usuario, esto parece lo mismo que una excepción de puntero nulo. Incluso si su código está absolutamente limpio sin una sola pérdida de memoria, su marca de límite de memoria puede provocar fallos en teléfonos menos potentes pero populares en mercados importantes.
Las baterías son una de las primeras cosas que se reducen cuando los fabricantes intentan ahorrar espacio y dinero. Pero eso no hará que los usuarios comprendan mejor cuando tu aplicación consume toda su potencia..
Digamos por un momento que está convencido de que necesita una aplicación rápida, y debería ser rápida en todas partes, no solo para usted cuando ejecuta su aplicación a través del generador de perfiles de CPU de Apple Instruments. ¿Qué debe hacer un desarrollador? En este momento, tienes dos opciones básicas:
Una API rápida significa una aplicación rápida. ¿Derecha? Esta es la mentalidad de un desarrollador web, y si eres un desarrollador móvil, está mal.
La web es una arquitectura de cliente ligero. Dejando a un lado las aplicaciones web pesadas de JavaScript, la mayoría del código interesante detrás de los sitios web se ejecuta en el servidor. El cliente, el navegador, es efectivamente solo un motor de renderizado sin estado. Cuando el rendimiento disminuye, normalmente se trata de un problema de escala en su infraestructura de servidor..
Las aplicaciones nativas y móviles, por otro lado, son clientes pesados. Tienen bases de código grandes, multi-hilo. Mantienen estado. Y tienen que actuar en una gran variedad de terminales, sistemas operativos y redes. El equipo de su servidor aún puede arruinar la experiencia del usuario, pero hay una serie de problemas completamente nuevos que no aparecerán en las alertas de su servidor..
Multa. Usted lo consigue. Debes asegurarte de probar tus aplicaciones en un montón de mundo real Escenarios. Así que vas a construir un laboratorio de control de calidad con 100 teléfonos diferentes. Luego los encerrará en una jaula de Faraday para poder simular las condiciones adversas de la red y contratar un ejército de personas de control de calidad para ejecutar cada nueva versión a través de cada acción posible en su aplicación..
Lo admito, si te lo puedes permitir, no es una mala idea. Pero las combinaciones rápidamente se vuelven abrumadoras. Imagine que le importan los 100 teléfonos principales, 10 velocidades de red, 20 mercados extranjeros diferentes con latencias diferentes y 5 versiones de SO diferentes. Ahora imagina que tienes 50 acciones distintas en tu aplicación. Al ignorar la interdependencia entre las acciones y los datos variables del usuario, tiene 1 millón de combinaciones para probar. Ay!
Este es un problema de control de calidad clásico. Asegurar la calidad significa hacer todo lo posible para probar los casos de uso más comunes. Pero nunca debe ser un reemplazo para el monitoreo. Es simplemente imposible estar al tanto de todos los posibles casos de falla.
Necesitamos un nuevo conjunto de herramientas, construido desde cero para medir específicamente los problemas de rendimiento de las aplicaciones móviles. ¿Qué métricas deberían capturar estas nuevas herramientas??
Nada molesta más a un usuario que una pantalla congelada. Al capturar cada vez que su aplicación tarda más de un umbral de tiempo para renderizar un marco, puede tener una idea de la frecuencia con la que ven un congelamiento notable.
Si sigues buenas prácticas de UI / UX, cada vez que necesites hacer un trabajo que lleve más de unos pocos milisegundos, debes hacerlo en segundo plano y lanzar una ruleta. Pero incluso si está en la parte superior de su subproceso, los usuarios todavía tienen paciencia limitada.
Después de 1 segundo, los usuarios tienen un cambio de contexto mental, y después de 10 segundos, los usuarios abandonan su tarea. Si captura cada vez que muestra un girador, tiene un buen indicador genérico de cuánto tiempo está esperando el usuario típico en su aplicación.
Los errores de memoria son una de las cosas más difíciles de rastrear, especialmente debido a que Sin memoria killer en iOS no da lugar a un seguimiento de pila. Es demasiado costoso realizar un seguimiento de cada asignación, pero el registro de la memoria residente en iOS o el uso de VM Heap en Android es una buena medición de gastos generales..
La latencia y el ancho de banda son muy variables en las redes celulares y desempeñan un papel clave en la experiencia del usuario. Para cada solicitud de API, puede registrar cuánto tiempo se tarda en obtener la respuesta inicial (latencia), cuánto tiempo se tarda en obtener la respuesta completa (tiempo de descarga) y los bytes descargados (el tiempo de descarga / bytes equivale al ancho de banda).
Una de las pocas razones por las que desinstalo aplicaciones es el uso de batería alta. Es obvio que la batería apesta, como usar el GPS del dispositivo, pero hay otros errores inesperados, como activar la antena inalámbrica con demasiada frecuencia. Tanto iOS como Android ofrecen API para monitorear los niveles de carga de la batería.
En el móvil, el contexto lo es todo. Cuando algo sale mal, debe saber como mínimo la versión de la aplicación, la ubicación, la red del operador, la versión del sistema operativo y el dispositivo..
Si eres ambicioso, es posible que tengas algún instrumento de rendimiento propio en tu aplicación. Probablemente tenga algunos temporizadores básicos para acciones clave en su aplicación, y luego llame por teléfono a los datos a través de un registro o un paquete especializado de JSON.
Si es así, dése una palmadita en la espalda. Has hecho mucho más que la mayoría. Pero hay muchos inconvenientes a este enfoque. ¿Qué sucede si tiene problemas de rendimiento en lugares inesperados en su aplicación? Si tiene un problema, ¿cómo sabe qué lo causó? ¿Fue una llamada a un método largo, una solicitud de API lenta o demasiados datos en el cable??
Y una vez que obtiene los datos de rendimiento en bruto, ¿cómo los analiza y visualiza? Si escribe un script único, ¿con qué frecuencia lo ejecuta? Y, Dios no lo quiera, ¿qué sucede si su instrumentación de rendimiento causa problemas de rendimiento??
En Pulse.io, hemos estado trabajando duro durante el último año en la creación de un SDK repleto de monitoreo de bondad. Capturamos todas las métricas enumeradas anteriormente mientras mantenemos una huella muy ligera. Consumimos menos del 3% de la CPU, enviamos por lotes nuestros datos para evitar encender la radio y limitamos el uso de nuestra memoria descartando la información de baja prioridad.
La mejor parte de Pulse.io es que captura todo este material de forma automática. Una cosa es instrumentar manualmente su aplicación con su solución casera. Otra cosa es convencer a todos los ingenieros de su equipo para que lo hagan, y aplicar la misma metodología de instrumentación de manera consistente a lo largo del tiempo..
Con Pulse.io, simplemente suelta el SDK y encuentra automáticamente todas las interacciones del usuario dentro de su aplicación y registra cuando esas interacciones causan un mal comportamiento, como la congelación de la pantalla o las largas tareas asíncronas..
Instalar Pulse.io te llevará menos tiempo que leer este artículo. Actualmente estamos en beta privada, pero si nos envía un correo electrónico a beta [at] pulse [dot] io y menciona que leyó sobre nosotros en Tuts +, le configuraremos una cuenta.
Una vez que hayas descargado el SDK, la instalación es super simple. Coloque el SDK en su aplicación, agregue algunas dependencias y llame [Monitor PulseSDK: @ "YOUR_APP_KEY"] dentro de su aplicación main.m. Has terminado.
Espero haberte convencido de tres cosas:
Te animo a investigar el rendimiento en el mundo real de tu propia aplicación. Prueba Pulse.io. No hay mucho que perder y mucho rendimiento que ganar..
Accentsconagua