Welche Android-Tools und -Methoden eignen sich am besten, um Speicher- / Ressourcenlecks zu finden? [geschlossen]

Ich habe eine Android-App entwickelt und bin am Punkt einer Telefon-App-Entwicklung angelangt, bei der alles gut zu funktionieren scheint und Sie den Sieg erklären und versenden möchten, aber Sie wissen, dass es nur einige Speicher- und Ressourcenlecks geben muss da drin; und es gibt nur 16 MB Heap auf dem Android und es ist anscheinend überraschend einfach, in einer Android-App zu lecken.

Ich habe mich umgesehen und konnte bisher nur Informationen zu 'hprof' und 'traceview' ausgraben und bekomme auch nicht viele positive Bewertungen.

Welche Tools oder Methoden sind Ihnen begegnet oder wurden entwickelt und möchten Sie möglicherweise in einem Betriebssystemprojekt teilen?

Einer der häufigsten Fehler bei der Entwicklung von Android-Apps ist der Fehler "java.lang.OutOfMemoryError: Bitmap-Größe überschreitet VM-Budget". Ich habe diesen Fehler häufig bei Aktivitäten festgestellt, bei denen viele Bitmaps verwendet wurden, nachdem die Ausrichtung geändert wurde: Die Aktivität wird zerstört, erneut erstellt und die Layouts werden aus dem XML-Code "aufgeblasen", wodurch der für Bitmaps verfügbare VM-Speicher belegt wird.

Bitmaps im vorherigen Aktivitätslayout werden vom Garbage Collector nicht ordnungsgemäß freigegeben, da sie Verweise auf ihre Aktivität gekreuzt haben. Nach vielen Experimenten habe ich eine recht gute Lösung für dieses Problem gefunden.

Legen Sie zunächst das Attribut "id" in der übergeordneten Ansicht Ihres XML-Layouts fest:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
     android:layout_width="fill_parent"
     android:layout_height="fill_parent"
     android:id="@+id/RootView"
     >
     ...

Rufen Sie dann in der onDestroy () -Methode Ihrer Aktivität die unbindDrawables () -Methode auf, die eine Referenz an die übergeordnete Ansicht übergibt, und führen Sie dann ein System.gc () aus.

@Override
protected void onDestroy() {
    super.onDestroy();

    unbindDrawables(findViewById(R.id.RootView));
    System.gc();
}


private void unbindDrawables(View view) {

    if (view.getBackground() != null) {
        view.getBackground().setCallback(null);
    }

    if (view instanceof ViewGroup) {
        for (int i = 0; i < ((ViewGroup) view).getChildCount(); i++) {
            unbindDrawables(((ViewGroup) view).getChildAt(i));
        }

        ((ViewGroup) view).removeAllViews();
    }
}

Diese unbindDrawables () -Methode untersucht den Ansichtsbaum rekursiv und:

1. Entfernt Rückrufe auf allen Hintergrundzeichnungen
2. Entfernt untergeordnete Elemente in jeder Ansichtsgruppe

Holen Sie sich den Eclipse Memory Analyzer ( http://www.eclipse.org/mat/ ). Überprüfen Sie http://kohlerm.blogspot.com/2010/02/android-memory-usage-analysis-slides.html und http: // kohlerm.blogspot.com/search/label/memory

Hauptsächlich für Google-Reisende aus der Zukunft:

Die meisten Java-Tools sind für diese Aufgabe leider nicht geeignet, da sie nur den JVM-Heap analysieren. Jede Android-Anwendung hat jedoch auch einen nativen Heap, der ebenfalls innerhalb der ~ 16 MB-Grenze liegen muss. Es wird normalerweise zum Beispiel für Bitmap-Daten verwendet. Sie können also leicht auf Speicherfehler stoßen, obwohl Ihr JVM-Heap etwa 3 MB groß ist, wenn Sie viele Drawables verwenden.

Die Antwort von @ hp.android funktioniert gut, wenn Sie nur mit Bitmap-Hintergründen arbeiten, aber in meinem Fall hatte ich BaseAdaptereine Reihe von ImageViews für a GridView. Ich habe die unbindDrawables()Methode wie empfohlen geändert , sodass folgende Bedingung erfüllt ist:

if (view instanceof ViewGroup && !(view instanceof AdapterView)) {
  ...
}

aber das Problem ist dann, dass die rekursive Methode niemals die Kinder der AdapterView. Um dies zu beheben, habe ich stattdessen Folgendes getan:

if (view instanceof ViewGroup) {
  ViewGroup viewGroup = (ViewGroup) view;
  for (int i = 0; i < viewGroup.getChildCount(); i++)
    unbindDrawables(viewGroup.getChildAt(i));

  if (!(view instanceof AdapterView))
    viewGroup.removeAllViews();
}

Damit die untergeordneten AdapterViewElemente weiterhin verarbeitet werden, versucht die Methode nicht, alle untergeordneten Elemente zu entfernen (was nicht unterstützt wird).

Dies behebt das Problem jedoch nicht ganz, da ImageViews eine Bitmap verwaltet, die nicht ihr Hintergrund ist. Ich habe daher folgendes hinzugefügt. Es ist nicht ideal, aber es funktioniert:

if (view instanceof ImageView) {
  ImageView imageView = (ImageView) view;
  imageView.setImageBitmap(null);
}

Insgesamt ist die unbindDrawables()Methode dann:

private void unbindDrawables(View view) {
  if (view.getBackground() != null)
    view.getBackground().setCallback(null);

  if (view instanceof ImageView) {
    ImageView imageView = (ImageView) view;
    imageView.setImageBitmap(null);
  } else if (view instanceof ViewGroup) {
    ViewGroup viewGroup = (ViewGroup) view;
    for (int i = 0; i < viewGroup.getChildCount(); i++)
    unbindDrawables(viewGroup.getChildAt(i));

    if (!(view instanceof AdapterView))
      viewGroup.removeAllViews();
  }
}

Ich hoffe, dass es einen prinzipielleren Ansatz gibt, um solche Ressourcen freizusetzen.

Gutes Google I / O-Gespräch (2011) über Speicherverwaltung in Android sowie Details zu Tools und Techniken für die Speicherprofilerstellung:
http://www.youtube.com/watch?v=_CruQY55HOk

Valgrind wurde auf Android portiert (gesponsert von Mozilla). Siehe Valgrind unter Android - Aktueller Status und Support Ausführen von Valgrind für Android unter ARM (Kommentar 67).

Nun, das sind die Tools, die sich mit den einzigartigen Formaten verbinden, die Android verwendet. Ich denke, Sie sind möglicherweise nicht zufrieden mit dem zugrunde liegenden Testcode-Framework, das verwendet wird.

Haben Sie versucht, Codebereiche mit dem Android Mock Framework zu testen?