Aktivität Leerlauf-Timeout für ActivityRecord

So, ich habe ein seltsames problem, und ich bin mir nicht ganz sicher, was alle Informationen, die ich liefern sollte, aber ich werde mein bestes tun-nur lassen Sie mich wissen, wenn ich brauche, um hinzuzufügen mehr info. Ich habe ein Problem, dass wenn ich fertig bin meine Activity und zurück zum vorherigen Activity (oder starten Sie es mit einem neuen Intent - das problem scheint zu sein, zentriert auf die Fertigstellung des Activity) die UI-Leistung sinkt drastisch um ungefähr sechs oder sieben Sekunden, dann wieder normal.

Vom LogCat diese Warnung erscheint 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ät mal aus, UI ist die Leistung wieder normal. Bis zu diesem Punkt ist es sehr träge. Ich habe kein code, ich bin mir bewusst, dass blockieren könnte der Haupt-thread, und ich bin sogar so weit gegangen, zu kommentieren, meine gesamte onPause() Methode, um zu sehen, ob es einen Unterschied macht, und es funktioniert nicht.

Den Activity nicht laichen alle hintergrund-threads, die nicht durchführen jegliche Netzwerk-Aktivität, die nur Zugriff auf die Festplatte hat es Zugriff auf einige der SharedPreferences. Die bisherigen Fragen habe ich in der Lage zu lokalisieren sind über idle-timeouts für HistoryRecord, nicht ActivityRecord.

Irgendwelche Ideen, was würde das verursachen? Oder wie könnte ich gehen, über die Bestimmung, was ist die Blockierung der UI-thread, wenn es das ist, was passiert ist?

BEARBEITEN : Okay, habe gerade versucht auskommentieren alles außer super.onCreate() und setContentView() -- das problem noch besteht. Es tritt nicht mit anderen Aktivitäten, aber diese ein, aber es ist NICHTS ZU dieser. :/

  • Technisch ist es möglich, das blockieren der UI-thread w/ SharedPreferences, aber ich denke, es ist wahrscheinlich nicht so wahrscheinlich, wie ein Netzwerk zugreifen oder etwas. Haben Sie versucht, es zu entfernen irgendwie?
  • Danke für die Idee. Habe gerade versucht, die; entfernt alle Verweise auf SharedPreferences, kommentierte meine onPause() und onResume(), aber kein Unterschied.
  • kcoppock siehe auch meine Frage stackoverflow.com/questions/30053090/...
InformationsquelleAutor kcoppock | 2012-07-12
  1. 12

    Oh geez. Eines der Dinge, die ziemlich schwer zu diagnostizieren, die außerhalb von Versuch und Irrtum, aber ich habe es herausgefunden. Für Referenz, sollte jemand anderes dieses problem haben, kam es zu einer benutzerdefinierten Ansicht in meinem layout. Ich habe dazu eine ViewTreeObserver.OnGlobalLayoutListener() zu tun, einige layout-änderungen nach dem layout übergeben, aber innerhalb dieser listener habe ich geändert, das layout und verursacht damit ein anderes layout, im wesentlichen die Schaffung einer unendlichen Schleife (aber irgendwie nicht Ursache einer ANR). Meine Lösung war wie folgt:

    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 ist ziemlich ironisch, wenn man bedenkt meine zweite am höchsten bewerteten Antwort auf StackOverflow beschäftigt sich explizit mit dieser. 😛

    Seufzer

    • hahahah... Mach dir keine sorgen, ich vor ein paar Wochen war zu Lesen, Antworten auf SO, und einer von Ihnen war besonders aufschlussreich, also ging ich zu upvote... stellt sich heraus, dass ich die Frage beantwortet haben 1,5 Jahre her und ich kann mich nicht erinnern, eine Sache 😛
    • Haha, genial! 😛
    • Hier ist, warum gibt es keine AnR : groups.google.com/forum/?fromgroups=#!Thema/android-Entwickler/... (Danke Mutter Dianne)
    InformationsquelleAutor kcoppock
  2. 1

    Ich habe das gleiche Problem heute, aber als es stellte sich heraus, haben eine andere Ursache und Lösung, die ich entschieden, um die Informationen werden hier nur für den Fall, es könnte jemand anderes helfen.

    In meinem Fall problem verursacht wurde, da hatte ich folgende Zeile in meine onActivityResult() Methode:

    android.os.Debug.waitForDebugger();

    Ich habe Gerade die Zeile gelöscht und das problem war Weg.
    Diese Linie ist in der Regel verwendet zum synchronisieren der debugger mit der OS-threads, aber ich dachte es sollte nicht überall eingesetzt werden. Seltsam, das problem würde nicht auftauchen, bis ich hatte mein Handy getrennt vom desktop.

    Hinsichtlich

    InformationsquelleAutor ulix
Schreibe einen Kommentar