ein wenig aus den Grafika issue tracker regurgitating:
Der hüpfenden Ball ist eine Software gerendert, so alles, was die CPU-Zeit aufsaugt geht es nach unten machen verlangsamen. Auf Geräten mit mittelgroßen CPUs und großen Displays (z. B. Nexus 10) erreicht es nie annähernd 60 fps. Also eine Verlangsamung während Sie spielen mit der Nav-Bar mich nicht überrascht, aber wenn es weiterhin langsam ist, auch nachdem Sie aufhören zu spielen mit der Nav-Bar, dann ist das ein bisschen seltsam.
Die Videowiedergabe sollte weniger beeinträchtigt werden, da dies weniger mit der CPU geschieht.
Die Untersuchung solcher Probleme beginnt normalerweise mit systrace, um Spuren in "guten" und "schlechten" Zuständen zu erfassen und die beiden zu vergleichen.
Der Schlüsselpunkt von BufferQueue "Async-Modus" ist, Frames zuzulassen, wenn der Consumer nicht mit dem Producer mithalten kann. Es ist in erster Linie für SurfaceTexture gedacht, wo sich Produzent und Konsument in der gleichen App befinden, möglicherweise im selben Thread. Wenn also der Producer-Stall auf den Consumer wartet, könnte das Programm hängen bleiben. Ich bin mir nicht sicher, was du meinst, wenn du es brauchst, um 60fps zu überschreiten, aber ich schätze, du wirfst Frames auf dem Display schneller als es sie rendern kann ... also erhöhst du nicht wirklich die Framerate, du bist Verwenden Sie einfach die BufferQueue, um die Frames zu löschen, anstatt Choreographer zu verwenden, um zu entscheiden, wann Sie sie selbst löschen müssen.
Jedenfalls verließ ich Google im Juni 2014, lange bevor Lollipop fertig war. Wenn etwas auf KitKat richtig funktioniert, aber seltsamerweise auf Lollipop, kann ich leider nicht viel Einblick geben. Wenn Sie das Verhalten leicht reproduzieren können, lohnt es sich, ein Video aufzunehmen, das das Problem demonstriert (zeigen Sie ein zweites Smartphone auf das Gerät mit dem Problem, damit Sie sehen können, wie Sie das Gerät manipulieren) und einen Fehler unter http://b.android.com/ einreichen.
Einige vom OP hochgeladen Spuren:
am kitkat Spur sucht, etwas seltsam ist in Surface los. Der Hauptfaden sitzt sehr lange in postFrameBuffer (23-32ms). Es wacht schließlich auf, und die CPU-Reihe deutet darauf hin, dass es auf Aktivität von einem "Galcore-Daemon" wartete, mit dem ich nicht vertraut bin (scheint Vivante GPU besonders zu sein).
Die Lollipop-Traces zeigen nur die CPU-Zeilen an, als ob die Erfassung ohne die erforderlichen Tags erfolgt wäre. Ich glaube nicht, dass sich der Systrace-Capture-Befehl zwischen Kitkat und Lollipop signifikant geändert hat. Daher bin ich verwirrt darüber, warum die vom Benutzer-Space initiierte Protokollierung verschwinden würde, aber das Kernel-Thread-Scheduling bleiben würde. Stellen Sie sicher, dass Sie sched gfx view angegeben haben.
Die neueren Lollipop-Spuren haben nur etwa eine Sekunde gute Daten. Wenn Sie "Nicht beendet" sehen, bedeutet dies, dass ein "Start" -Datensatz keinen übereinstimmenden "End" -Datensatz hatte. Sie können die Puffergröße für die Systrace-Protokollierung mit dem Flag -b erhöhen. Ich denke, es ist genug da.
Blick auf die Zeile /system/bin/surfaceflinger können Sie sehen, dass in der "guten" Spur, postFrameBuffer in der Regel in etwa 16ms endet, aber es ist immer noch auf Galcore warten. Vergrößern Sie 388 ms (verwenden Sie die WASD-Tasten). Bei 388,196 ms, in der Zeile CPU 2, können Sie sehen, dass Galcore etwas tut. Gleich nach dem Abschluss wechselt die dünne Linie an der Spitze der Surface-Flinder-Reihe von hellgrau (schlafend) zu grün (läuft). Bei 388.548ms, wieder auf CPU 2, läuft galcore erneut, und direkt danach auf der SurfaceFlinger Zeile sieht man, dass queueBuffer mit der Ausführung beginnt.
Die "schlechte" Spur sieht identisch aus. Zum Beispiel können Sie zwei Galcore-Ausführungen bei 101.146ms und 101.666ms sehen, mit scheinbar ähnlichen Effekten in der SurfaceFlinger-Reihe. Der Hauptunterschied ist die Zeit in postFrameBuffer, die etwa 16 ms für "gut" und etwa 30 ms für "schlecht" ist.
Das scheint also keine Verhaltensänderung zu sein; Vielmehr dauert es länger und es werden Fristen verpasst.
Soweit ich das beurteilen kann, wird SurfaceFlinger von Galcore-Daemon gehalten. Dies gilt sowohl für "gute" als auch für "schlechte" Fälle. Um zu sehen, wie das Timing aussehen sollte, können Sie Systrace auf einem Nexus-Gerät ausführen oder mit Spuren von anderen Geräten vergleichen (z. B. das in this case study oder this SO question). Wenn Sie hineinzoomen, sehen Sie doComposition in wenigen Millisekunden und postFrameBuffer in einigen Zehntel Millisekunden.
Zusammenfassend: Sie haben nicht gut und schlecht, Sie haben schlecht und schlechter. :-) Ich weiß nicht, was Galcore ist, aber Sie müssen wahrscheinlich ein Gespräch mit dem GPU-OEM haben.
Ja, ich habe alle oben genannten Tags beim Capturen in Kitkat und Lollipop verwendet, und ich folgte [] https: //community.freescale.com/thread/380812 um alle Traces im Kernel zu aktivieren, aber CONFIG_SCHED_TRACER verpasst, werde ich das aktivieren und Sie wissen lassen, ob sich die Systrace-Ausgabe ändert – Gurtaj
Wenn es ein Kernel-Konfigurationsproblem wäre, würde ich erwarten, dass sched fehlt und der ganze Benutzer Space-Zeug, um da zu sein. Ihr Trace ist genau umgekehrt, wie der ftrace-Code funktioniert, ignoriert aber die User-Space-Sachen. – fadden
Hallo @fadden Aktualisiert systrace Dumps sind https://www.dropbox.com/s/hnebmkkghp534iy/lp_bad.zip?dl=0 und https://www.dropbox.com/s/zr3dwibj4yb89h7/lp_good.zip?dl = 0. Das Problem war mit debugfs Erlaubnis, die verhindert, dass die anderen Prozesse in systrace dump – Gurtaj