`Unbekannt` (` Other`) Speicherleck in Android?

Question

Android Studio Memory Profiler meldet Zuordnungen in Others Kategorie.

Nach https://developer.android.com/studio/profile/memory-profiler.html: Andere: Speicher durch Ihre Anwendung verwendet, die das System nicht sicher ist, wie zu kategorisieren.

Wenn wir tiefer graben, ähnliche Speicherbedarf Informationen können https://developer.android.com/reference/android/os/Debug.MemoryInfo.html#getMemoryStat(java.lang.String)

mit zur Laufzeit abgerufen werden Es ist wie Others in Android Studio Memory Profiler sucht entspricht summary.private-other in Debug.MemoryInfo Klasse. Dieser Parameter wird gemeldet als:

public int getSummaryPrivateOther() { 
      return getTotalPrivateClean() 
       + getTotalPrivateDirty() 
       - getSummaryJavaHeap() 
       - getSummaryNativeHeap() 
       - getSummaryCode() 
       - getSummaryStack() 
       - getSummaryGraphics(); 
     } 

Welche Art von Speicherzuweisungen enden in dieser Kategorie? Es ist offensichtlich nicht Java, Native, Code, Stack und Grafik.

Wenn meine App (mit enorm großen Codebasis, so dass ich nicht wirklich einen bestimmten Code, der es verursacht) zeigen kann verbraucht viel Other Speicher, gibt es eine bestimmte Quelle/Muster, die zu einem solchen Verbrauch führt?

Edit 1 ich in der Lage war teilweise meine eigene Frage des ersten Teil zu beantworten:

Welche Art von Speicherzuordnungen in dieser Kategorie am Ende? Es ist offensichtlich nicht Java, Native, Code, Stack und Grafik.

RAM Info kann auch adb shell dumpsys meminfo <your proc name> abgerufen wird unter Verwendung von und in der Regel wie folgt aussieht:

Experimentell kann ich sehen, dass Unknown wird höchstwahrscheinlich in Private Other enthält. Was wirft die nächste Frage auf: Was ist Unknown? Nach https://developer.android.com/studio/command-line/dumpsys.html#meminfo:

Jede RAM-Seiten, die das System nicht in einem der die anderen speziellere Produkte klassifizieren könnte. Momentan enthält dies meist native Zuordnungen, die vom Tool beim Sammeln dieser Daten aufgrund von Address Space Layout Randomization (ASLR) nicht identifiziert werden können. Wie die Dalvik-Heap berücksichtigt die Pss Total für Unknown Freigabe mit Zygote, und Private Dirty ist unbekannt RAM nur für Ihre App gewidmet.

Es sieht aus wie es noch native Zuordnungen ist. Identifizierbare native Zuordnungen enden in der Kategorie Native. Native Zuordnungen, deren Daten aufgrund von ASLR nicht mehr identifizierbar sind, scheinen jedoch in Unknown zu enden.

Die Hauptfrage hält jedoch nach wie vor:

Wenn meine app (mit enorm großen Code-Basis, so kann ich nicht wirklich Stift Punkt ein bestimmter Code, der es verursacht) verbraucht viel Other Speicher, ist Gibt es eine bestimmte Quelle/Muster, die zu einem solchen Konsum führt? Ich bin für Antworten wie hängende Fäden suche, offene Cursor, WebViews usw.

Answer 1

Nach vielen Stunden der Forschung habe ich endlich ein gemeinsames Muster, die zu hohem Unknown Speicherverbrauch führt: WebView mit Javascript aktiviert .

Der folgende Beispielcode führt über 100mb von unknown Speicher auf dem HTC One API 19 und über 120mb auf Samsung Galaxy Note 4 (API23) und etwa 94mb auf Samsung Galaxy S8 (API-24) zu raubend:

val webView1 = findViewById<WebView>(R.id.webview_1) 
    webView1.settings.javaScriptEnabled = true 
    webView1.webViewClient = WebViewClient() 
    findViewById<Button>(R.id.load_webview_1).setOnClickListener { 
     webView1.loadUrl("http://www.nbcsports.com/") // can be any arbitrary URL 
    } 

Der folgende Befehl gibt Unknown Speicher in kb Kategorie jede Sekunde):

while sleep 1; do adb shell dumpsys meminfo com.dkarmazi.memoryleakerapp | grep Unknown; done 

Ausgang:

Nun wirft er eine Reihe von Fragen nachgehen, die außerhalb dieser Frage gehen:

1. Does OS Bericht WebView Speicher unter Unknown in dumpsys meminfo absichtlich oder es ist ein Fehler? Wenn es sich um einen Fehler handelt, ist dieser für bestimmte Betriebssystem- und API-Ebenen spezifisch? Wenn es absichtlich ist, dann wird die Anwendung mit sehr verwirrenden Spuren zum Absturz bringen, wenn Sie 4-5 aktive WebView s haben.
2. Ist so hoher Speicherverbrauch für eine moderne typische Webseite mit Javascript normal oder gibt es auch einen Fehler, der von bestimmten Javascript-Code ausgelöst wird? Experimentell nehmen einfachere Sites wie http://stackoverflow.com/23mb. Seiten mit einer umfassenderen Benutzererfahrung, wie jede Nachrichtenwebsite, werden bis zu 120mb-130mb dauern.

TLDR: WebView mit aktivierter Javascript ist ein häufiger Anwendungsfall, der eine Menge unknown Speicher auf bestimmte Hersteller zu raubend führt.