App Launch time 101 (Android Performance Patterns Season 6 Ep. 1)

[REPRODUCCIÓN DE MÚSICA] COLT MCANLIS: Y vete. [BIP] ¿ Sabes lo que significa este temporizador? Cada cuarto de
segundo que un usuario pasa mirando una pantalla en blanco
en lugar de interactuar con su aplicación, es un
cuarto de segundo más que está dispuesto
a cerrar su aplicación y prestar atención
a otra cosa. [BIP] Mi nombre es Colt McAnlis
y no entender todas las cosas complejas que
suceden durante el inicio de la aplicación puede provocar
problemas graves de rendimiento. Ahora, Android
es bastante inteligente cuando se trata de comprender la
percepción del desempeño humano. Tan pronto como el usuario
inicie su aplicación, Android mostrará inmediatamente
una ventana de inicio, que permanecerá abierta hasta que su
aplicación esté completamente cargada, inicializada y pueda
dibujar su primer fotograma.

Este comportamiento se
observa con mayor frecuencia cuando la aplicación se inicia
por primera vez, pero también puede ocurrir fácilmente en
otras ocasiones, como cuando la actividad
pasa al primer plano, o después de que el usuario
sale de la aplicación, o después de una
parte. El sistema ha eliminado una parte de su aplicación
para ahorrar memoria. Básicamente, cada vez que el usuario
pasa de otra cosa a su aplicación,
existe la posibilidad de que pueda ver este
tipo de comportamiento. El
punto importante aquí es este. Dejar que el usuario pase
demasiado tiempo mirando la ventana de inicio le brinda
amplias oportunidades para aburrirse y pasar
a otras cosas. Y,
en general, tardar demasiado podría incluso hacer que
aparezca el cuadro de diálogo La aplicación no responde. Ninguno de estos es muy
bueno para la retención de usuarios. Entonces, desde el
punto de vista técnico, todo el proceso funciona más o menos así.

Cuando el usuario inicia su aplicación,
el sistema hace un poco de trabajo para cargar la
información de su aplicación y crear un
proceso único para su aplicación. A partir de ahí, el
proceso del sistema mostrará la ventana de inicio
y básicamente permanecerá colgado hasta que la
aplicación esté en funcionamiento. Mientras tanto, el
proceso de solicitud creará el
objeto de la aplicación e iniciará el hilo principal.

Aquí es donde
se inicializará, creará,
inflará y finalmente dibujará su actividad de inicio. Sólo en este punto,
después de que la aplicación ha dibujado su primer fotograma,
el proceso del sistema cambia la
ventana de inicio de la aplicación. Ahora bien, para ser claros, la mayor parte
de todo ese proceso ocurre de manera bastante limpia. Realmente no hay muchas
posibilidades de que el rendimiento se descarrile. Sin embargo, hay
tres grandes áreas donde las cosas podrían
volverse problemáticas y que debes vigilar. Lo primero que
realmente deberías considerar es todo el trabajo que implica
crear tu clase de actividad. La mayoría de las veces, se produce
mucho trabajo pesado durante este
proceso, pero lo más pesado tiene que ser la inflación
de diseños y la carga de recursos que
lo acompaña. Este no es un proceso barato, y
si sus diseños son demasiado complejos o tiene alguna
lógica de bloqueo, esto puede causar
problemas realmente grandes. En una nota similar, asegúrese de
echar un vistazo a la inicialización de su aplicación .

Para aplicaciones realmente complejas
, la inicialización del objeto de la aplicación a menudo
se convierte en un cajón de basura para muchas
clases globales que podrían usarse entre actividades. Por lo tanto,
aquí suele haber mucho trabajo que podría posponerse
para momentos posteriores o tal vez cargarse de
forma diferida. Ahora, existen muchas
aplicaciones que proporcionan
ventanas de inicio personalizadas. Esto se
hace para ayudar a marcar la aplicación o
para hacer que una carga lenta parezca una aplicación de marca personalizada
. Ahora bien, si estás haciendo esto
para ocultar tiempos de carga incorrectos, obviamente debes
solucionarlo primero.

Pero si
lo haces para promocionar tu marca, entonces debes ser consciente de que
hay una forma correcta y otra incorrecta de configurarlo, para que
no influya demasiado negativamente en la percepción del usuario. Pero antes de
adentrarse en la maleza y tratar de arreglar este
tipo de patrones comunes, primero debe
sentarse y descubrir si tiene un problema
. Afortunadamente, Android tiene
algunas herramientas para ayudar. En primer lugar está el tiempo de visualización. Para las versiones posteriores a
KitKat, Logcat incluirá una
línea de salida que muestra la cantidad de tiempo
entre el inicio del proceso y la actividad
finalmente mostrada en la pantalla.

Esto puede resultar útil
porque le da una idea general de cuánto tiempo tarda
en realizarse su solicitud. Ah, por cierto
, tenga en cuenta que si desea ver este valor dentro
de Android Studio, debe desactivar los filtros
para la salida de Logcat. Así que tenlo en cuenta. En segundo lugar está la
función reportFullyDrawn. La métrica mostrada
que se informa en Logcat es útil para la mayoría de
situaciones en las que desea realizar un seguimiento del
tiempo que lleva pasar desde el inicio de la aplicación
hasta su primera visibilidad. Sin embargo, en el
desarrollo de aplicaciones modernas, a menudo hay una gran cantidad
de carga diferida, es decir, en lugar de bloquear el
dibujo inicial de la ventana, se cargan recursos y vistas de forma asincrónica
en segundo plano y se actualiza la
jerarquía de vistas en consecuencia.

El resultado es que, si bien
la actividad inicial puede ser visible, es posible que aún no
esté completamente cargada con respecto a los recursos, lo que
podría considerarse una métrica separada para usar
al evaluar el rendimiento del tiempo de lanzamiento . Para solucionar este problema,
puede llamar manualmente a la
función Activity.reportFullyDrawn para que el sistema sepa
que su actividad ha finalizado con su carga diferida. En tercer lugar está el rastreo de métodos. Si bien el tiempo de visualización
y el informeFullyDrawn brindan una buena comprensión
del tiempo de carga general de su aplicación,
no brindan detalles sobre lo que puede estar
causando que partes particulares de esa canalización duren
más de lo esperado. Para obtener más información
en esta área, puede utilizar la herramienta de
seguimiento del método de inicio dentro de Android Studio.

Y finalmente está el
grande, Systrace. Cuando agrega
funciones de seguimiento dentro de sus métodos onCreate,
aumentará su registro, de modo que la
herramienta Systrace pueda descubrir correctamente todas las
subsecciones y mostrarlas en su proceso de gráficos. Y si busca más
información valiosa sobre el rendimiento, no olvide consultar
el resto del contenido "Patrones de rendimiento de Android". Y asegúrese de unirse a la
comunidad de Google+ para hacer preguntas a otros gurús del rendimiento.

Así que mantenga la calma, perfile su
código y recuerde siempre que el rendimiento importa. [REPRODUCCIÓN DE MÚSICA].

As found on YouTube