android - tiene - La aplicación puede estar haciendo demasiado trabajo en su hilo principal

que tiene mucho trabajo

Question

Soy nuevo en el entorno de Android SDK / API. Es el primero que estoy tratando de dibujar una trama / gráfico. Intenté ejecutar diferentes tipos de códigos de muestra en el emulador utilizando 3 bibliotecas gratuitas diferentes, no se muestra nada en la pantalla de diseño. El logcat está repitiendo el siguiente mensaje:

W/Trace(1378): Unexpected value from nativeGetEnabledTags: 0 I/Choreographer(1378): Skipped 55 frames! The application may be doing too much work on its main thread.

El problema no persistió y el gráfico funcionó cuando ejecuté un código de muestra correspondiente a una copia de evaluación de una biblioteca con licencia.

Answer 1

Como otros respondieron arriba, "¡Se saltaron 55 cuadros!" significa que un poco de procesamiento pesado está en su aplicación.

Para mi caso, no hay proceso pesado en mi aplicación. Doblé y triplicé todo, y eliminé el proceso, creo que fue un poco pesado.

Quité Fragmentos, Actividades, Bibliotecas hasta que solo quedara el esqueleto. Pero aún así el problema no desapareció. Decidí revisar los recursos y encontré que algunos iconos y el fondo que uso son bastante grandes, ya que me olvidé de verificar el tamaño de esos recursos.

Por lo tanto, mi sugerencia es que si ninguna de las respuestas anteriores ayuda, también puede verificar el tamaño de los archivos de recursos.

Answer 2

Después de hacer mucha I + D en este tema, obtuve la Solución,

En mi caso, estoy usando un servicio que se ejecutará cada 2 segundos y con el runonUIThread, me preguntaba si el problema estaba allí, pero no fue así. El siguiente problema que encontré es que estoy usando una imagen grande en la aplicación May y ese es el problema.

Quité las imágenes y configuré nuevas imágenes.

Conclusión: - Busque en su código si hay algún archivo en bruto que esté usando que sea de gran tamaño.

Answer 3

Mi aplicación tenía el mismo problema. Pero no estaba haciendo otra cosa que mostrar una lista de tarjetas y texto en él. Nada corriendo en el fondo. Pero luego, después de una investigación, se encontró que la imagen configurada para el fondo de la tarjeta estaba causando esto, aunque era pequeña (350 kb). Luego convertí la imagen a imágenes de 9patch utilizando http://romannurik.github.io/AndroidAssetStudio/index.html .
Esto funcionó para mí.

Answer 4

No soy un experto, pero recibí este mensaje de depuración cuando quería enviar datos desde mi aplicación de Android a un servidor web. Aunque utilicé la clase AsyncTask e hice la transferencia de datos en segundo plano, para obtener los datos de resultados del servidor usé el método get () de la clase AsyncTask, que hace que la IU sea sincrónica, lo que significa que su UI estará esperando demasiado tiempo. Por lo tanto, mi consejo es hacer que su aplicación realice todas las tareas orientadas a la red en un hilo separado.

Answer 5

Obtuve el mismo problema al desarrollar una aplicación que usa muchos archivos png dibujables en el diseño de cuadrícula. También traté de optimizar mi código en la medida de lo posible ... pero no funcionó para mí .. Luego traté de reducir el tamaño de esos png ... y supongo que está funcionando absolutamente bien ... Así que mi sugerencia es reducir Tamaño de los recursos dibujables si los hubiera.

Answer 6

Optimice sus imágenes ... No use imágenes de más de 100 KB ... La carga de imágenes requiere demasiada CPU y hace que su aplicación se cuelgue.

Answer 7

Otra causa común de demoras en el subproceso de la IU es el acceso SharedPreferences. Cuando llama por primera vez a PreferenceManager.getSharedPreferences y otros métodos similares, el archivo .xml asociado se carga y analiza inmediatamente en el mismo subproceso .

Una de las buenas maneras de combatir este problema es desencadenar la primera carga de SharedPreference desde el subproceso en segundo plano, que se inició lo antes posible (por ejemplo, desde onCreate de su clase de aplicación). De esta manera, el objeto de preferencia ya puede estar construido para el momento en que querría usarlo.

Desafortunadamente, a veces es necesario leer los archivos de preferencias durante las fases iniciales del inicio (por ejemplo, en la Actividad inicial o incluso en la propia Aplicación). En tales casos, todavía es posible evitar el bloqueo de la interfaz de usuario utilizando MessageQueue.IdleHandler . Haga todo lo que necesita para realizar en el hilo principal, luego instale IdleHandler para ejecutar el código una vez que su Actividad haya sido completamente dibujada. En ese Runnable, debería poder acceder a SharedPreferences sin demorar demasiadas operaciones de dibujo y hacer que el coreógrafo no esté contento.

Answer 8

Primero lea la advertencia. Dice más carga en el hilo principal. Entonces, lo que tienes que hacer es ejecutar funciones con más trabajo en un hilo.

Answer 9

Puede usar la biblioteca Glide para cargar imágenes ... cargará la imagen en el hilo del fondo ...

Answer 10

Trate de usar las siguientes estrategias para mejorar el rendimiento de su aplicación:

• Utilice la programación de subprocesos múltiples si es posible. Los beneficios de rendimiento son enormes, incluso si su teléfono inteligente tiene un núcleo (los subprocesos pueden ejecutarse en diferentes núcleos, si el procesador tiene dos o más). Es útil hacer que la lógica de tu aplicación esté separada de la interfaz de usuario. Utilice hilos de Java, AsyncTask o IntentService. Mira esto
• Lea y siga los diversos consejos de rendimiento del sitio web de desarrollo de Android. Compruebe aquí .

Answer 11

Yo también tuve el mismo problema.
El mío fue un caso en el que estaba usando una imagen de fondo que estaba dibujada. Esa imagen en particular tenía aproximadamente 130 kB y se usó durante la pantalla de inicio y la página de inicio en mi aplicación para Android.

Solución : acabo de cambiar esa imagen en particular a la carpeta drawables-xxx de drawables y pude liberar una gran cantidad de memoria ocupada en el fondo y los marcos que saltaban ya no se saltaban.

Actualización Use la carpeta de recursos dibujables ''nodp'' para almacenar archivos dibujables de fondo.
¿Tendrá prioridad una carpeta dibujable calificada por densidad o un nodpi dibujable?

Answer 12

Yo tuve el mismo problema. Cuando ejecuté el código en otra computadora, funcionó bien. En la mía, sin embargo, mostraba "La aplicación puede estar haciendo demasiado trabajo en su hilo principal".

Resolví mi problema reiniciando Android studio [Archivo -> Cachés no válidos / Reiniciar -> haga clic en "Invalidar y reiniciar"].

Answer 13

Yo tuve el mismo problema. El emulador de Android funcionó perfectamente en Android <= 6.0. Cuando probé el emulador Nexus 5 (Android 6.0), la aplicación funcionó muy lentamente con I/Choreographer: Skipped frames en los registros.

Por lo tanto, resolví este problema cambiando en hardwareAccelerated opción Manejada del hardwareAccelerated archivo Manifest a true como esto:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myapplication">
<application android:hardwareAccelerated="true">
...
</application>
</manifest>

Answer 14

Yo tuve el mismo problema. En mi caso tuve 2 diseños relativos anidados. RelativeLayout siempre tiene que hacer dos pases de medida. Si anida RelativeLayouts, obtendrá un algoritmo de medición exponencial.

Answer 15

tomado de: interfaz de usuario de Android: reparación de marcos omitidos

Cualquier persona que comience a desarrollar la aplicación para Android ve este mensaje en logcat "Coreógrafo (abc): ¡Marcos xx omitidos! La aplicación puede estar haciendo demasiado trabajo en su hilo principal ”. Entonces, ¿qué significa realmente, por qué debería preocuparse y cómo resolverlo?

Lo que esto significa es que su código se está demorando en procesar y los marcos se omiten debido a esto, tal vez debido a un gran procesamiento que está haciendo en el corazón de su aplicación o acceso a DB o cualquier otra cosa que haga que el hilo detente un rato Aquí hay una explicación más detallada:

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.

fuente: Significado de los mensajes del coreógrafo en Logcat

¿Por qué debería preocuparse?

Cuando aparece este mensaje en el emulador de Android y el número de cuadros omitidos es bastante pequeño (<100), entonces puede apostar que el emulador es lento, lo que sucede casi todas las veces. Pero si el número de fotogramas omitidos es grande y en el orden de más de 300, entonces puede haber algunos problemas serios con su código. Los dispositivos Android vienen en una amplia gama de hardware, a diferencia de los dispositivos iOS y Windows. La memoria RAM y la CPU varían y si desea un rendimiento razonable y la experiencia del usuario en todos los dispositivos, entonces necesita arreglar esto. Cuando se omiten los marcos, la IU es lenta y lenta, lo que no es una experiencia de usuario deseable.

Como arreglarlo

Para solucionar este problema, es necesario identificar los nodos en los que existe o posiblemente puede ocurrir una larga duración de procesamiento. La mejor manera es realizar todo el procesamiento, sin importar cuán pequeño o grande sea un hilo separado del hilo principal de la interfaz de usuario. Entonces, ya sea accediendo a la base de datos de SQLite Database o haciendo algunas matemáticas incondicionales o simplemente ordenando una matriz - Hágalo en un hilo diferente

Ahora hay un retén aquí. Creará un nuevo subproceso para realizar estas operaciones y cuando ejecute su aplicación, se bloqueará diciendo "Solo el subproceso original que creó una jerarquía de vistas puede tocar sus vistas". Debe saber este hecho de que la interfaz de usuario en Android se puede cambiar solo por el hilo principal o por la interfaz de usuario. Cualquier otro subproceso que intente hacerlo, falla y se bloquea con este error. Lo que debe hacer es crear un nuevo Runnable dentro de runOnUiThread y dentro de este Runnable debe hacer todas las operaciones relacionadas con la interfaz de usuario. Encuentra un ejemplo here .

Así que tenemos Thread y Runnable para procesar datos fuera de Thread principal, ¿qué más? Existe AsyncTask en Android que permite realizar procesos de larga duración en el subproceso de la interfaz de usuario. Esto es lo más útil cuando las aplicaciones son controladas por datos o por API web o utilizan interfaces de usuario complejas como las que se construyen con Canvas. El poder de AsyncTask es que permite hacer cosas en segundo plano y una vez que haya terminado de procesar, simplemente puede realizar las acciones necesarias en la interfaz de usuario sin causar ningún efecto de retraso. Esto es posible porque AsyncTask se deriva del subproceso de la interfaz de usuario de la actividad: todas las operaciones que realiza en la interfaz de usuario a través de AsyncTask se realizan en un subproceso diferente del subproceso de la interfaz de usuario principal, sin obstáculos para la interacción del usuario.

Así que esto es lo que necesitas saber para hacer aplicaciones de Android sin problemas y hasta ahora sé que cada principiante recibe este mensaje en su consola.