android - studio - Significado de los mensajes del Coreógrafo en Logcat
mensajes log android (5)
Choreographer permite que las aplicaciones se conecten a sí mismas con el vsync y cronometren adecuadamente las cosas para mejorar el rendimiento.
Las animaciones de visualización de Android utilizan Choreographer internamente para el mismo propósito: cronometrar adecuadamente las animaciones y posiblemente mejorar el rendimiento.
Ya que se informa a Choreographer sobre todos los eventos vsync, puedo decir si uno de los Runnables pasados por Choreographer.post * apis no finaliza en el tiempo de un cuadro, lo que hace que los cuadros se omitan.
A mi entender, el Coreógrafo solo puede detectar el salto de fotogramas. No tiene forma de decir por qué sucede esto.
El mensaje "La aplicación puede estar haciendo demasiado trabajo en su hilo principal". podría ser engañoso
Esta pregunta ya tiene una respuesta aquí:
Instalé las últimas versiones de SDK (API 16) y obtuve la última versión de ADT. Ahora estoy viendo estos mensajes en el logcat, que estoy bastante seguro, no he visto antes. ¿Alguien tiene una idea sobre esto?
06-29 23: 11: 17.796: I / Coreógrafo (691): ¡Se saltaron 647 cuadros! La aplicación puede estar haciendo demasiado trabajo en su hilo principal.
Hice una búsqueda y encontré este enlace: http://developer.android.com/reference/android/view/Choreographer.html . Esta es una nueva clase introducida en API 16.
Necesito saber cómo puedo determinar qué "demasiado trabajo" puede hacer mi aplicación, ya que todo mi procesamiento se realiza en AsyncTask s.
En mi caso, tengo estos mensajes cuando muestro la barra de progreso inderterminate de la barra de acción de sherlock. Como no es mi biblioteca, decidí ocultar los resultados del Coreógrafo.
Puede ocultar los resultados de Choreographer en la vista Logcat, utilizando esta expresión de filtro:
etiqueta: ^ ((?! Coreógrafo). *) $
Usé una expresión regular explicada en otra parte: ¿ Expresión regular para hacer coincidir una línea que no contiene una palabra?
Esto si es un mensaje de información que podría aparecer en su LogCat en muchas situaciones.
En mi caso, sucedió cuando estaba inflando varias vistas de los archivos de diseño XML mediante programación. El mensaje es inofensivo por sí mismo, pero podría ser el signo de un problema posterior que usaría toda la memoria RAM que su aplicación puede usar y que cause el cierre de la Fuerza del mega malvado. He crecido hasta ser el tipo de desarrollador que le gusta ver su registro WARN / INFO / ERROR gratis. ;)
Entonces, esta es mi propia experiencia:
Recibí el mensaje:
10-09 01:25:08.373: I/Choreographer(11134): Skipped XXX frames! The application may be doing too much work on its main thread.
... cuando estaba creando mi propia "lista multisección súper compleja" personalizada al inflar una vista de XML y poblar sus campos (imágenes, texto, etc.) con los datos provenientes de la respuesta de un REST / Servicio web JSON (sin capacidades de paginación) estas vistas actuarían como filas, encabezados de subsección y encabezados de sección agregándolos todos en el orden correcto a un LinearLayout (con orientación vertical dentro de un ScrollView). Todo eso para simular un listView con elementos pulsables ... pero bueno, eso es para otra pregunta.
Como desarrollador responsable, desea que la aplicación sea realmente eficiente con los recursos del sistema, por lo que la mejor práctica para las listas (cuando sus listas no son tan complejas) es usar un ListActivity o ListFragment con un cargador y llenar el ListView con un adaptador. esto es supuestamente más eficiente, de hecho lo es y debes hacerlo todo el tiempo, nuevamente ... si tu lista no es tan compleja.
Solución: Implementé la paginación en mi servicio web REST / JSON para evitar "tamaños de respuesta grandes" y envolví el código que agregó las vistas "filas", "encabezados de sección" y "encabezados de subsección" en una AsyncTask para mantener la principal Hilo fresco.
Entonces ... espero que mi experiencia ayude a otra persona que está abriendo sus cabezas con este mensaje de información.
¡Feliz piratería!
Esto suele suceder cuando se realiza la depuración con el emulador, que de todos modos se sabe que es lento.
Llego tarde a la fiesta, pero espero que esta sea una adición útil a las otras respuestas aquí ...
Respondiendo a la pregunta / tl: dr;
Necesito saber cómo puedo determinar qué "demasiado trabajo" puede estar haciendo mi aplicación, ya que todo mi procesamiento se realiza en AsyncTasks.
Los siguientes son todos los candidatos:
- IO o procesamiento costoso en el hilo principal (cargar elementos dibujables, inflar diseños y configurar los
UrienImageView''s constituyen IO en el hilo principal) - Representación de jerarquías de
Viewgrandes / complejas / profundas - Invalidando grandes porciones de una jerarquía de
View - Métodos
onDrawcaros enViewpersonalizadas - Cálculos caros en animaciones.
- Ejecutar subprocesos "de trabajo" con una prioridad demasiado alta para que se consideren "fondo" (los
AsyncTaskson "fondo" por defecto,java.lang.Threadno lo es) - Generando mucha basura, lo que hace que el recolector de basura "detenga el mundo", incluido el hilo principal, mientras se limpia
Para determinar realmente la causa específica, deberá crear un perfil de su aplicación.
Mas detalle
He estado tratando de entender al coreógrafo experimentando y mirando el code .
La documentación de Choreographer se abre con "Coordina la sincronización de las animaciones, la entrada y el dibujo". que en realidad es una buena descripción, pero el resto continúa enfatizando demasiado las animaciones.
El Coreógrafo es realmente responsable de ejecutar 3 tipos de devoluciones de llamada, que se ejecutan en este orden:
- devolución de llamadas de manejo de entrada (manejo de entrada de usuario como eventos táctiles)
- devoluciones de llamada de animación para interpolar entre fotogramas, proporcionando un tiempo de inicio de fotogramas estable a cualquier / todas las animaciones que se estén ejecutando. La ejecución de estas devoluciones de llamada 2 significa que todos los cálculos relacionados con la animación (por ejemplo, el cambio de posiciones de View) ya se han realizado en el momento en que se invoca el tercer tipo de devolución de llamada ...
- Ver devoluciones de llamada transversales para dibujar la jerarquía de vistas.
El objetivo es hacer coincidir la velocidad a la que se vuelven a dibujar las vistas invalidadas (y las animaciones se interpolan) con la pantalla vsync, normalmente 60 fps.
La advertencia sobre los marcos omitidos parece una ocurrencia tardía: el mensaje se registra si una sola pasada a través de los 3 pasos toma más de 30 veces la duración esperada del marco, por lo que el número más pequeño que puede esperar ver en los mensajes de registro es "omitido 30 marcos" ; Si cada pase dura 50% más de lo debido, aún así, saltará 30 fotogramas ( ¡travieso! ) Pero no se lo advertirá.
De los 3 pasos implicados, queda claro que no solo las animaciones pueden desencadenar la advertencia: la invalidación de una parte significativa de una jerarquía de View grande o una View con un método onDraw complicado puede ser suficiente.
Por ejemplo, esto activará la advertencia repetidamente:
public class AnnoyTheChoreographerActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.simple_linear_layout);
ViewGroup root = (ViewGroup) findViewById(R.id.root);
root.addView(new TextView(this){
@Override
protected void onDraw(Canvas canvas) {
super.onDraw(canvas);
long sleep = (long)(Math.random() * 1000L);
setText("" + sleep);
try {
Thread.sleep(sleep);
} catch (Exception exc) {}
}
});
}
}
... lo que produce el registro de esta manera:
11-06 09:35:15.865 13721-13721/example I/Choreographer﹕ Skipped 42 frames! The application may be doing too much work on its main thread.
11-06 09:35:17.395 13721-13721/example I/Choreographer﹕ Skipped 59 frames! The application may be doing too much work on its main thread.
11-06 09:35:18.030 13721-13721/example I/Choreographer﹕ Skipped 37 frames! The application may be doing too much work on its main thread.
Puedes ver en la pila durante onDraw que el coreógrafo está involucrado sin importar si estás animando:
en example.AnnoyTheChoreographerActivity $ 1.onDraw (AnnoyTheChoreographerActivity.java:25) en android.view.View.draw (View.java:13759)
... bastante repetición ...
en android.view.ViewGroup.drawChild (ViewGroup.java:3169) en android.view.ViewGroup.dispatchDraw (ViewGroup.java:3039) en android.view.View.draw (View.java:13762) en android.widget. FrameLayout.draw (FrameLayout.java:467) en com.android.internal.policy.impl.PhoneWindow $ DecorView.draw (PhoneWindow.java:2396) en android.view.View.getDisplayList (View.java:12710) en android .view.View.getDisplayList (View.java:12754) en android.view.HardwareRenderer $ GlRenderer.draw (HardwareRenderer.java:1144) en android.view.ViewRootImpl.draw (ViewRootImpl.java:2273) en android.view. ViewRootImpl.performDraw (ViewRootImpl.java:2145) en android.view.ViewRootImpl.performTraversals (ViewRootImpl.java:1956) en android.view.ViewRootImpl.doTraversplaspayas.com (ViewRootImpl.java:4472) en android.view.Choreographer $ CallbackRecord.run (Choreographer.java:725) en android.view.Choreographer.doCallbacks (Choreographer.java:555) en android.view.Choreographer.doFrame (Cho reographer.java:525) en android.view.Choreographer $ FrameDisplayEventReceiver.run (Choreographer.java:711) en android.os.Handler.handleCallback (Handler.java:615) en android.os.Handler.dispatchMessage (Handler.java : 92) en android.os.Looper.loop (Looper.java:137) en android.app.ActivityThread.main (ActivityThread.java:4898)
Finalmente, si hay contención de otros subprocesos que reducen la cantidad de trabajo que puede realizar el subproceso principal, la posibilidad de omitir marcos aumenta dramáticamente aunque no esté haciendo el trabajo en el subproceso principal.
En esta situación, podría considerarse engañoso sugerir que la aplicación está haciendo demasiado en el subproceso principal, pero Android realmente quiere que los subprocesos de los trabajadores se ejecuten con baja prioridad para evitar que se mueran de hambre en el subproceso principal. Si los subprocesos de trabajo son de baja prioridad, la única manera de activar la advertencia del Coreógrafo realmente es hacer demasiado en el subproceso principal.