prefacio
Esta serie optimización del rendimiento de los artículos:
1, con una forma fácil de usar para explicar, explicar el valor práctico de una tecnología
2, un seguimiento de fuentes detallado por escrito, captura en el origen, la estructura de clases de dibujo, trata de explicar en detalle los principios del proceso de exploración
3 proporcionando el proyecto de demostración Github puede correr, pero yo he proporcionado el código, proporcionan más ideas, mejores ideas, por favor cv apropiada,
4, terminando una serie de precauciones durante el principio de funcionamiento del proceso de exploración de una cisterna, o en la demo
5, La figura usando gif, la mayoría de los resultados operativos intuitivos muestran demostración **
Si cree que los detalles son demasiado delgadas, puede omitir para ver la conclusión.
capacidad limitada, si la descripción que se encuentra inadecuada, la bienvenida a los mensajes de la crítica.
cartilla
la optimización del rendimiento de aplicaciones, todos los desarrolladores deben tener un alto nivel de habilidades, pero ahora los artículos de optimización de rendimiento de red en la mayoría de los casos que no está escrito, y ninguna introducción conocimiento, por lo que la gente necesita entender esta tecnología no puede empezar a aprender. Esta serie de artículos explicará en primer lugar el caso y que pueda ver el efecto, y luego explicar los detalles, para que sepa que funciona. Quiero ayuda.
caso
la optimización del rendimiento de aplicaciones, naturalmente, hay un problema antes de la optimización, para diagnosticar estos problemas? No es un medio natural.
Q: ¿Cómo sabemos que nuestra propia aplicación se inicia el tiempo que tomó?
R: comando adb. Los pasos siguientes:
- Asegúrese de que el dispositivo conectado al ordenador;
- ventana de cmd inicio
- Introduzca los siguientes datos:
adb shell am start -W [app包名]/[launcherActivity的全类名]
resultados en el simulador android29 es:
vivo máquina real, entonces el resultado es:
Aquí habrá tres veces:
thisTime: Comando de arranque Am puede iniciar múltiples actividades, si se inicia múltiple, thisTime se refiere a la hora de inicio de la última actividad si el inicio es que uno, entonces thisTime igual TotalTime.
TotalTimeNuevo tiempo aplicación de inicio de actividad.
WaitTime: AMS cambio de la actividad actual onResume onPause, y luego iniciar una nueva duración de la aplicación Actividad total, incluyendo el TotalTime incluido, por lo que WaitTime TotalTime más tiempo.
Por supuesto, también se puede añadir -S-R10, comenzó 10 veces seguidas, y luego calcular la duración media de su propio principio.
adb shell am start -S -R 10 -W packagename/.MainActivity
Aquí tres veces, probablemente podemos ver que están empezando la aplicación específica el tiempo que tomó. hora habitual obtenida por observación visual, pero adaptadas a los valores numéricos exactos, o la necesidad de utilizar la línea de comandos. La pregunta, entonces, si encuentra la puesta en marcha de aplicaciones consume tiempo no es lo ideal, como casos extremos, hemos añadido algunas operaciones que consumen mucho tiempo en la Actividad onCreate,
O se pone en la operación que consume tiempo en onResume:
entonces:
Aquí es la hora de inicio se ralentizará todo el 4000ms.
Esto está por encima del caso extremo realizo operación que consume tiempo en el hilo de interfaz de usuario analógica. En el proyecto actual, que puede disminuir algunos de estos tiempo de inicio de las tareas que consumen mucho tiempo de actividad son complejos, el tiempo cómo debe ser manejado?
Todas las tareas de inicio en dos dimensiones en cuatro categorías: 必要: Por ejemplo, nuestro lanzador es WelcomeActivity, terminará automáticamente, y luego el siguiente es MainActivity, si es necesario MainActivity necesaria para obtener algunos parámetros de antelación, a continuación, la adquisición de estos parámetros es tarea tareas esenciales. 耗时: Do como la longitud de tiempo consumiendo cerca dividida, no consume mucho tiempo, por lo general rastrear el cálculo puede realizarse rápidamente, no ha perdido demasiado tiempo en el hilo principal. Consume mucho tiempo, por lo general un SDK de inicialización de terceros, o realizar solicitudes de red.
Estos cuatro tratamientos diferentes fueron:
- Necesaria y requiere mucho tiempo
de esto, terceros SDK de inicialización, por ejemploTinker, la página de bienvenida se necesita saber si es o no el parche de fusión, esto es una necesidad, y es mucho tiempo, o aurora inicialización empuje SDK. Esto es similar al uso异步线程de tratar, se recomienda aquí para realizar nueva rosca directa, en lugar de la actividad de inicio en el interior con un grupo de subprocesos, debido a inicializar el grupo de subprocesos es a llevar mucho tiempo, no rinda como nueva hebra ejecutable.
La ejecución asíncrona beneficio no es el momento de llevar el retraso en el subproceso de interfaz de usuario, dando a los usuarios una mejor experiencia de la página de bienvenida. - No se requiere mucho tiempo la necesidad
de este, o en onCreate onResume dentro de todos modos. - Sin consumir innecesaria
para este innecesaria, pero no mucho tiempo, podemos tolerar que se inicia la actividad, pero aún así entrar en el nuevo hilo funcione mejor, hora de inicio, ahorro. - Innecesaria y consume mucho tiempo
, por ejemplo, los datos reportados SDK de inicialización, la siguiente actividad no requiere que usted tiene que se complete la inicialización. No ponga esto en el inicio de actividad. Directamente en los datos comunicados por el primer código de inicialización para ir.
Además, la regla de oro: para la necesaria y tarea que consume tiempo, si el número es muy grande, con un hilo directo para ejecutar, pero la página principal Actividad permanecerá por mucho tiempo, esta vez, puede ser una distinguida para todas las tareas 轻重缓急, completado una misión importante después de eso, vamos a la siguiente actividad, sin esperar los resultados de las tareas no críticas. (De acuerdo con esta idea, creo que usted puede escribir su propio código de aplicación Gangster, que no hablan fuera de turno).
Por último mencionar, en algunos casos, iniciar la aplicación, habrá significativa 白屏, entonces otra vez escribimos el diseño de interfaz de usuario. Esto se debe a la AMS en nuestro tiempo de inicio de actividad, primero se mostrará una ventana en blanco de forma predeterminada, y luego otra vez escribimos el diseño de interfaz de usuario, ya que si partimos de la propia aplicación tarda demasiado tiempo, lo que resulta en blanco y negro demasiado tiempo, la experiencia es muy mala. Esto tiene dos soluciones:
1, el conjunto de actividades tema, el color de fondo a transparente.
<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
<item name="android:windowIsTranslucent">true</item>
<item name="android:windowNoTitle">true</item>
</style>
2, la actividad del tema se ajusta a una imagen, pero lo mejor es consistente con el fondo de la página de inicio, la página de inicio o en el caso de una verdadera Ui sería más abrupta.
<style name="splash" parent="AppTheme.NoActionBar"> <item name="android:windowBackground">@drawable/bg_splash</item> <item name="android:windowFullscreen">true</item> </style>
epílogo
Inicio optimización de la velocidad, es la primera experiencia de aplicación de puerta optimizado, lo hará la actualización directamente a nuestra experiencia de usuario de la aplicación. Pero, en realidad podemos hacer mucho más que eso simple. Por ejemplo: si la página de inicio de la interfaz de usuario es más complejo, sobre la base de la interfaz de usuario también tomar algún tiempo conducir a una mala experiencia, incluso Caton, pero esto es por aplastamiento requisitos de interfaz de usuario, no podemos cambiar el país? Haga un poco de optimización a su suerte en el sorteo. artículo detallada siguiente serie.
