9

Tengo un problema extraño, y no estoy del todo seguro de toda la información que debo proporcionar, pero haré todo lo posible. Solo déjenme saber si necesito agregar más información. Tengo un problema que cuando termino mi Activity y vuelvo al Activity anterior (o lo inicio con un nuevo Intent - el problema parece estar centrado en terminar el Activity) el rendimiento de la interfaz de usuario cae drásticamente durante unos seis o siete segundos , luego vuelve a la normalidadTiempo de inactividad de actividad para ActivityRecord

De LogCat, esta advertencia aparece constantemente:

07-11 22:09:42.594: W/ActivityManager(292): Launch timeout has expired, giving up wake lock! 
07-11 22:09:42.601: W/ActivityManager(292): Activity idle timeout for ActivityRecord{42bf6e00 com.kcoppock.sudokubeta/com.kcoppock.sudoku.SudokuBoardActivity} 

Tan pronto como los tiempos de actividad fuera, el rendimiento vuelve a la interfaz de usuario normal. Hasta ese punto, es muy lento. No tengo ningún código del que tenga conocimiento que pueda estar bloqueando el hilo principal, e incluso he llegado a comentar todo el método onPause() para ver si hace alguna diferencia, y no es así.

Activity no genera ningún subproceso de fondo, no realiza ninguna actividad de red, el único acceso de disco que tiene es un acceso de SharedPreferences. Las preguntas anteriores que he podido encontrar se refieren a los tiempos de espera inactivos para HistoryRecord, no a ActivityRecord.

¿Alguna idea de qué podría causar esto? ¿O cómo podría determinar qué está bloqueando el hilo de UI, si eso es lo que está sucediendo?

EDITAR: Está bien, sólo trató comentando todo lo excepto super.onCreate() y setContentView() - el problema aún persiste. No ocurre con ninguna otra actividad excepto esta, pero está NADA AL éste. :/

+0

Técnicamente es posible bloquear el hilo de interfaz de usuario w/'SharedPreferences', pero supongo que probablemente no es tan probable como un acceso a la red o algo así.¿Has intentado eliminarlo de alguna manera? –

+0

@AlexLockwood Gracias por la idea. Solo intenté eso; eliminé todas las referencias a cualquier SharedPreferences, comenté mi onPause() y onResume(), pero no hubo diferencia. – kcoppock

+0

kcoppock también vea mi pregunta http://stackoverflow.com/questions/30053090/flash-toggle-button-crash-android – Nepster

Respuesta

12

Oh, caramba. Una de esas cosas que es bastante difícil de diagnosticar fuera de prueba y error, pero lo he descubierto. Como referencia, si alguien más tiene este problema, se redujo a una vista personalizada en mi diseño. Agregué un ViewTreeObserver.OnGlobalLayoutListener() para hacer algunas modificaciones de diseño después del pase de diseño, pero dentro de ese oyente modifiqué el diseño y por lo tanto causé otro diseño, esencialmente creando un ciclo infinito (pero de alguna manera no causando un ANR). Mi solución fue así:

private class BoardLayoutListener implements OnGlobalLayoutListener { 
    @Override 
    public void onGlobalLayout() { 
     //...do stuff here 

     //REMOVE this listener so that you don't repeat this forever 
     ViewTreeObserver obs = SudokuBoard.this.getViewTreeObserver(); 
     obs.removeGlobalOnLayoutListener(this); 
    } 
} 

Esta solución es bastante irónico, teniendo en cuenta mi second highest rated answer on StackOverflow se ocupa específicamente de esto. : P

suspiro

+8

jajajaja ... no se preocupe, hace unas semanas estaba leyendo las respuestas en SO, y una de ellos fue particularmente esclarecedor, así que fui a votar ... resulta que respondí la pregunta hace 1,5 años y no recuerdo nada: P –

+0

¡Jaja, increíble! : P – kcoppock

+1

He aquí por qué no hay AnR: https://groups.google.com/forum/?fromgroups=#!topic/android-developers/TfkPlN5b-ig (Gracias, madre Dianne) – Reno

1

que he tenido el mismo problema hoy, pero ya que resultó tener una causa y solución diferente decidí añadir la información aquí, en caso de que pudiera ayudar a alguien más.
En mi caso problema fue causado porque tenía la siguiente línea dentro de mi método onActivityResult():
android.os.Debug.waitForDebugger();
Sólo he borrado la línea y el problema desapareció. Esta línea se usa generalmente para sincronizar el depurador con los hilos del sistema operativo, pero me imaginé que no debería usarse en ninguna parte. Curiosamente, el problema no aparecería hasta que mi teléfono se desconectara del escritorio.

Saludos

Cuestiones relacionadas