Detaillierte Erklärung für das Profil von "adb shell dumpsys meminfo my-app-name"?

Question

Kann mir jemand eine detaillierte Erklärung über das Profil von adb shell dumpsys meminfo my-app-name geben?

Das Ergebnis ist wie unten, wie es in How do I discover memory usage of my application in Android? erwähnt:

** MEMINFO in pid 890 [process-name] ** 
        native dalvik other total 
      size: 10940  7047  N/A 17987 
     allocated:  8943  5516  N/A 14459 
      free:  336  1531  N/A  1867 
      (Pss):  4585  9282 11916 25783 
    (shared dirty):  2184  3596  916  6696 
    (priv dirty):  4504  5956  7456 17916 

Objects 
      Views:  149  ViewRoots:  4 
    AppContexts:  13  Activities:  0 
      Assets:  4 AssetManagers:  4 
    Local Binders:  141 Proxy Binders:  158 
Death Recipients:  49 
OpenSSL Sockets:  0 

SQL 
      heap:  205   dbFiles:  0 
     numPagers:  0 inactivePageKB:  0 
    activePageKB:  0 

Was bedeutet die jede Spalte (native, Dalvik, andere, insgesamt) bedeuten? vor allem, was ist die "andere" Spalte (ich kann nicht herausfinden, was das neben nativen und Dalvik ist)? Es wäre schön, wenn jemand ein konkretes Beispiel dafür geben könnte. z.B. Ich habe eine App A. A hat sein eigenes Objekt obj_private und seine eigene native Bibliothek lib_private. Außerdem verweist A auf ein Objekt des Android-Frameworks obj_shared und auf eine native lib des Android-Frameworks lib_shared. Und obj_shared verweist auf eine native lib von Android lib_shared_indirect. Kann ich das für diesen Fall sagen?

1. Die "Gesamtgröße" entspricht den gesamten Speicher verwendet von "obj_private + lib_private + obj_shared + lib_shared + lib_shared_indirect".
2. Die „private dirty“ gleich Speicher dirtied von „obj_private + lib_private“

Der Grund, warum wir klar machen wollen, dabei ist: Es gibt einige ungewöhnliche Laufzeit-Speicher Erhöhung unserer neuesten Version App im Vergleich zu früheren Ausführung. Und als ich die dumpsys meminfo benutzte, fand ich die Spalten "nativ" und "andere" dramatisch erhöht. Aber die Änderung der neuen Version bezieht sich nur auf Java und es gibt keine Erklärung über die "andere" Spalte. Ich habe das gegoogelt und kein Dokument gefunden. Ich habe auch versucht, den Quellcode des Adb zu lesen. Aber ich fand es leicht, sich im Quellcode für Anfänger wie mich zu verlieren. Also poste ich diese Frage hier für den Fall, dass jemand helfen kann.

Answer 1

Wir haben jetzt mehr Dokumentation über die RAM-Nutzung in Android, die etwas ins Detail geht, was verschiedene RAM-Nummern bedeuten: Managing Your App's Memory. Sehen Sie sich insbesondere die Mitte der Seite an, auf der wichtige Teile des meminfo-Dumps behandelt werden: Investigating Your RAM Usage.

Es sieht so aus, als ob Ihre meminfo-Ausgabe von einer ziemlich alten Version von Android stammt, bevor wir viele der verschiedenen Arten von Zuteilungen identifizieren konnten. Um das, was Sie gerade sehen, der aktuellen Dokumentation zuzuordnen, betrachten Sie "Andere" als alles, was die moderne Müllhalde neben den einheimischen und dalvischen Sektionen zeigt. In Ihrer Müllkippe glaube ich, dass Ihr Dalvik-Abschnitt eigentlich der moderne "Dalvik Heap" und "Dalvik Other" zusammen ist.

Soweit die nativen und andere Abschnitte zunehmend nur nach einer Änderung im Java-Code, ja das kann sicherlich passieren. Eine Reihe von Teilen der Android Java API befindet sich über nativen Zuordnungen und kann auch andere Zuweisungen verursachen. Das klassische Beispiel hierfür sind Bitmaps auf Gingerbread und früher, bei denen die Daten für die Bitmap eine native Zuweisung waren und keine Arrayzuweisungen im Java-Heap wie heute.

Ihre erhöhten anderen Zuweisungen können auf eine Reihe von Dingen zurückzuführen sein, wie Sie in den neueren Versionen der Daten sehen werden - die Memory Backing Cursor, freigegebene Speicherbereiche von Ashmem, Geräte, die Dinge für Sie wie Grafiken zuweisen Texturen usw. Es gibt so viele Dinge, dass es schwierig sein kann zu sagen, was passieren könnte, weshalb der Bericht heutzutage detaillierter ist. (Und selbst dort haben wir immer noch eine Anzahl von Dingen, die zu unbekannt zusammenfallen.)

Für das Debuggen möchten Sie wahrscheinlich Ihren Java-Heap für ausgelaufene Objekte betrachten. Da die tatsächliche Zuweisung für das Objekt nicht im Java-Heap ist, kann dies natürlich schwierig sein.Ich würde vorschlagen, einen Heap-Dump früh in Ihrer App zu machen, alles zu tun, was dazu führt, dass sich der RAM-Footprint erhöht, danach einen Heap-Dump macht und nach dem Anstieg der Objektanzahl sucht. Die referenzierte Dokumentation zeigt, wie Sie Heap-Dumps mit MAT vergleichen.

Auch wenn Sie Ihren Java-Heap nur als allgemeine Analyse betrachten (außer bei Diffs), befolgen Sie immer die Anweisungen zum Entfernen des Zygote-Teils des Heaps. Wie die Dokumentation erwähnt, hat jeder Prozess eine große Anzahl von Zuweisungen von Zygote, aber diese werden über alle Prozesse verteilt und sind daher für die Heap-Analyse im Allgemeinen nicht relevant. Ich sehe sehr oft Leute, die betroffen sind, weil sie viele sehr große Bitmaps in ihrer App sehen, die das System ihnen zugeteilt hat, und denken, dass das Hauptanliegen RAM in ihrer App ist, wenn nicht, ist es nur das freigegebene Zuweisungen von Zygote.