9

Also habe ich ein seltsames Problem, und ich bin mir nicht ganz sicher, welche Informationen ich liefern sollte, aber ich werde mein Bestes geben - lassen Sie es mich wissen, wenn ich weitere Informationen hinzufügen muss. Ich habe ein Problem, dass, wenn ich meine Activity beenden und zur vorherigen Activity (oder starten Sie es mit einer neuen Intent - das Problem scheint auf die Fertigstellung der Activity zentriert) die UI-Leistung drastisch für etwa sechs oder sieben Sekunden fällt , kehrt dann zu normal zurück.Aktivitäts-Leerlauf-Timeout für ActivityRecord

Von LogCat, erscheint diese Warnung konsequent:

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} 

Sobald die Aktivitätszeiten aus, UI Performance wieder normal. Bis dahin ist es sehr träge. Ich habe keinen Code, von dem ich weiß, dass er den Hauptthread blockieren könnte, und ich bin sogar so weit gegangen, meine gesamte onPause()-Methode zu kommentieren, um zu sehen, ob es einen Unterschied macht, und das tut es auch nicht.

Die Activity erzeugt keine Hintergrundthreads, führt keine Netzwerkaktivität aus, der einzige verfügbare Festplattenzugriff ist ein Zugriff auf SharedPreferences. Bei den vorherigen Fragen, die ich finden konnte, handelt es sich um Leerlaufzeitüberschreitungen für HistoryRecord, nicht .

Irgendwelche Ideen, was würde dies verursachen? Oder wie könnte ich herausfinden, was den UI-Thread blockiert, wenn das passiert?

EDIT: Okay, kommentiert alles nur ausprobiert außer super.onCreate() und setContentView() - das Problem weiterhin besteht. Es kommt nicht mit anderen Aktivitäten vor, aber dieses hier, aber es gibt NOTHING TO dieses. :/

+0

Technisch ist es möglich, den UI-Thread w/'SharedPreferences' zu blockieren, aber ich denke, es ist wahrscheinlich nicht so wahrscheinlich wie ein Netzwerkzugang oder so etwas.Hast du versucht es irgendwie zu entfernen? –

+0

@AlexLockwood Danke für die Idee. Ich habe das gerade versucht; habe alle Verweise auf SharedPreferences entfernt, meine onPause() und onResume() auskommentiert, aber keinen Unterschied. – kcoppock

+0

kcoppock auch meine Frage http://stackoverflow.com/questions/30053090/flash-toggle-button-crash-android – Nepster

Antwort

12

Oh mein Gott. Eines dieser Dinge, die außerhalb von Versuch und Irrtum kaum zu diagnostizieren sind, aber ich habe es herausgefunden. Falls jemand anderes dieses Problem hat, kam es zu einer benutzerdefinierten Ansicht in meinem Layout. Ich hatte eine ViewTreeObserver.OnGlobalLayoutListener() hinzugefügt, um einige Layoutänderungen nach dem Layoutdurchlauf vorzunehmen, aber innerhalb dieses Zuhörers habe ich das Layout geändert und somit ein anderes Layout verursacht, das im Wesentlichen eine Endlosschleife erzeugte (aber irgendwie keinen ANR verursachte). Meine Lösung war etwa so:

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); 
    } 
} 

Diese Lösung ziemlich ironisch ist, wenn man bedenkt meine second highest rated answer on StackOverflow speziell mit diesem befasst. : P

Seufzer

+8

hahahah ... mach dir keine Sorgen, vor ein paar Wochen habe ich Antworten auf SO gelesen, und eins von ihnen war besonders aufschlussreich, also ging ich zum upvote ... stellt sich heraus, dass ich die Frage vor 1.5 Jahren beantwortete und ich mich an nichts erinnern konnte: P –

+0

Haha, fantastisch! : P – kcoppock

+1

Hier ist, warum gibt es keine AnR: https://groups.google.com/forum/?fromgroups=#!topic/android-developers/TfkPlN5b-ig (Danke Mutter Dianne) – Reno

1

Ich habe das gleiche Problem heute hatte, aber da es eine andere Ursache zu haben, stellte sich heraus, und Lösung habe ich beschlossen, die Informationen hier nur für den Fall hinzufügen, es könnte jemand anderes helfen.
In meinem Fall Problem verursacht wurde, weil ich die folgende Zeile in meiner onActivityResult() Methode hatte:
android.os.Debug.waitForDebugger();
Ich löschte einfach die Linie und das Problem war verschwunden. Diese Zeile wird normalerweise verwendet, um den Debugger mit den OS-Threads zu synchronisieren, aber ich dachte mir, dass es nirgends verwendet werden sollte. Seltsamerweise wurde das Problem erst angezeigt, als ich mein Telefon vom Desktop trennte.

Grüße

Verwandte Themen