Caja negra

Supongamos que una aplicación es una caja negra. Por ahora, ignoremos la cuestión de su categoría (juegos, negocios, educación, estilo de vida), ya que no es realmente importante en este momento. Además, supongamos que nuestra aplicación está escrita de forma nativa para una plataforma móvil determinada (por ejemplo, iOS – Swift, Objective-C, Android – Java, Kotlin) con el uso de las mejores prácticas de software y plantillas de proyectos. Creo que si está considerando la eficiencia del software, no tiene sentido entrar en los detalles de las soluciones multiplataforma como, por ejemplo, Xamarin o las híbridas que usan HTML5. Eso es incluso si, en el caso de un software simple, podemos asumir que la eficiencia de una solución basada en Xamarin será comparativa con el idioma nativo.

Soy consciente del hecho de que no podré discutir todos los aspectos de la eficiencia de las aplicaciones móviles y los factores que la configuran. Sin embargo, me gustaría centrarme en los más importantes.

Dispositivos

El primer factor y probablemente el más olvidado se refiere a los dispositivos en sí. Dependiendo de la plataforma y la versión del software disponible, es útil armar una lista de dispositivos en los que finalmente se instalará el software.

Esos dispositivos no solo determinan la interfaz de usuario, sino principalmente cómo funcionarán capas de software particulares en dispositivos móviles más antiguos. Estos pueden incluir dispositivos con peores unidades (procesador más débil, menos RAM). También debe considerar la disponibilidad de los dispositivos, especialmente los más antiguos. Con mayor frecuencia, los programadores utilizan simuladores, además de uno o dos dispositivos móviles. Esta debería ser una señal de advertencia para que los probadores comiencen sus pruebas con los dispositivos más antiguos. La negligencia puede llevar a una costosa reescritura de funcionalidades que operan incorrectamente en dispositivos particulares debido a razones de eficiencia. En cualquier caso, esto no justifica a los programadores, que a menudo copian las plantillas de proyecto incorrectas por pereza e inician las aplicaciones solo en los dispositivos más nuevos, que se ocupan de procesar operaciones complicadas sin ningún problema. En tales casos, generalmente aprendemos sobre los inconvenientes relacionados con la eficiencia del usuario final.

Redes

Otro punto comprende las redes y, en particular, cuándo y con qué frecuencia la aplicación utiliza la conexión a Internet. Los errores más frecuentes que afectan directamente al rendimiento se deben a que la aplicación solicita datos al servidor con demasiada frecuencia o una mala estructura para almacenar los datos en la caché. Aquí, la mejor solución es planificar bien la generación de datos, siempre que sea necesario, y almacenar en caché las respuestas del servidor.

Las operaciones de generación de datos deben ejecutarse de forma asincrónica, sin bloquear el hilo principal, que es responsable de representar la interfaz de usuario. Al descargar imágenes, uno debe recordar dos cosas: guardarlas en el disco duro y sobre la compresión adecuada.

Además, también vale la pena asegurarse de que la aplicación funcione bien sin conexión, a menos que no sea necesario en la especificación incluida en la documentación. Desde mi experiencia, los problemas a veces ocurren debido a la falta de información explícita de que la aplicación debe operar en línea. A veces, volver a desarrollar una aplicación ya compleja puede ser muy arriesgado, ya que esto puede generar errores adicionales (que son difíciles de resolver). Creo que este problema tiene que ver con el desarrollo de la capa de comunicación con el servidor en los negocios más que en los juegos, que, como se puede suponer, deben operar fuera de línea. Por “sin conexión” también me refiero a una mala conexión a Internet, como 3G o EDGE, que no siempre es suficiente al 100%.

También debemos considerar la efectividad de la capa comunicativa del servidor. Es particularmente importante cuando nuestra aplicación genera un gran tráfico de preguntas sobre la parte del servidor. El problema puede complicarse aún más debido, por ejemplo, a la transmisión de audio o video. Desafortunadamente, en este caso, no siempre tenemos un impacto directo a través del desarrollo continuo. Sin embargo, creo que es bueno tener esto en cuenta también.

Terceros

El tercer punto involucra el uso de bibliotecas de empresas externas. Esto se ha vuelto muy popular recientemente. Cualquiera que haya trabajado con un gran proyecto que involucró bibliotecas que no se actualizaron de forma continua (¡especialmente las de código abierto!) Sabrá de lo que estoy hablando. Facilitan el proceso de desarrollo y lo aceleran, especialmente si son complejos. Proporcionan funcionalidades que normalmente llevaría mucho tiempo escribirlas un programador desde cero.

El desarrollo en sí puede apoyarse con dispositivos adicionales. Estos pueden permitir un monitoreo adecuado de la eficiencia de la aplicación, la aparición de fallas y el cierre repentino de una aplicación, o el registro adicional de los eventos de la aplicación. Dichos dispositivos incluyen, por ejemplo: Fabric, Crashlytics, Flurry, HockeyApp, AppDynamics, New Relic. Deben agregarse y utilizarse desde el inicio del proyecto.

Resumen

En resumen, debemos recordar que todos los elementos aquí enumerados forman un todo y, en última instancia, determinan cómo ve la aplicación el usuario final. La eficiencia influye en la interfaz de usuario, así como en sus sentimientos generales relacionados con el uso de la aplicación. Por lo tanto, no debemos dejar que sientan la necesidad de desinstalar de inmediato nuestro software recientemente desarrollado o, peor aún, que sientan que tienen un teléfono viejo y deben reemplazarlo.