Welche Android-Tools und -Methoden funktionieren am besten, um Speicher-/Ressourcenlecks zu finden? [closed]

Lesezeit: 7 Minuten

Ich habe eine Android-App entwickelt, und ich bin an einem Punkt der Entwicklung einer Telefon-App, an dem alles gut zu funktionieren scheint und Sie den Sieg und die Lieferung verkünden 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 keiner von beiden erhält viele positive Bewertungen.

Auf welche Tools oder Methoden sind Sie gestoßen oder haben sie entwickelt und möchten sie vielleicht in einem OS-Projekt teilen?

  • Kann ich dafür stimmen, dass Р̀СТȢѸ́ФХѾЦЧШЩЪЫЬѢѤЮѦѪѨѬѠѺѮѰѲѴ seinen Namen in etwas lesbares ändert.

    – JPM

    11. Februar 2015 um 16:47 Uhr

  • Wäre es in Ordnung, diese Frage erneut zu öffnen, wenn wir das Wort „Android-Tools“ aus dem Fragentitel entfernen? Die hier gefundenen Antworten waren sehr nützlich, um meine Probleme mit Speicherlecks zu lösen

    – k3b

    5. Juli 2015 um 7:49 Uhr

  • Okay, ich habe also einen Benutzer, der ständig zwischen Aktivitäten wechselt, was bedeutet, dass er möglicherweise 15 Aktivitäten in 20 Sekunden gewechselt hat. Könnte das eine Ursache für einen Speicherfehler sein? Was soll ich tun, um es zu beheben? Danke!

    – Ruchir Baronia

    5. Januar 2016 um 5:45 Uhr

  • Kann dies nicht als Antwort geben, da die Frage geschlossen wurde, aber ich würde empfehlen, einen Blick darauf zu werfen Leck Kanarienvogel. Verwenden Sie einfach Ihre App, öffnen und schließen Sie Aktivitäten und lassen Sie die Bibliothek ihre Arbeit erledigen. Es wird Ihnen sogar sagen, wo das Leck aufgetreten ist. Geben Sie dem Leckanalysator einfach etwas Zeit, um seine Arbeit zu erledigen, nachdem das Leck aufgetreten ist – es dauert normalerweise etwa 2 Minuten oder länger, bis die Quelle des Lecks gefunden wurde. Danach wird es Ihnen ordentlich in der App präsentiert. Keine zusätzlichen Werkzeuge erforderlich!

    – Ubuntudroid

    2. Januar 2017 um 19:55 Uhr

Welche Android Tools und Methoden funktionieren am besten um Speicher Ressourcenlecks zu
hp.android

Einer der häufigsten Fehler, die ich bei der Entwicklung von Android-Apps gefunden habe, ist der Fehler „java.lang.OutOfMemoryError: Bitmap Size Exceeds VM Budget“. Ich habe diesen Fehler häufig bei Aktivitäten gefunden, die viele Bitmaps verwenden, nachdem die Ausrichtung geändert wurde: Die Aktivität wird zerstört, neu erstellt und die Layouts werden aus dem XML „aufgeblasen“, wodurch der für Bitmaps verfügbare VM-Speicher verbraucht wird.

Bitmaps im vorherigen Aktivitätslayout werden vom Garbage Collector nicht ordnungsgemäß freigegeben, da sie Querverweise auf ihre Aktivität aufweisen. Nach vielen Experimenten fand ich eine ziemlich gute Lösung für dieses Problem.

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, übergeben Sie eine Referenz an die übergeordnete View und führen Sie dann eine 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 Methode unbindDrawables() durchsucht den Ansichtsbaum rekursiv und:

  1. Entfernt Callbacks auf allen Drawables im Hintergrund
  2. Entfernt untergeordnete Elemente in jeder Ansichtsgruppe

  • Gute Lösung für ein allgemeines Problem.

    – Während-E

    8. August 2011 um 6:33 Uhr

  • Dies funktioniert nicht für Unterklassen von AdapterView (ListView, GridView usw.).

    – Arjun

    18. November 2011 um 20:56 Uhr

  • @Arjun Ja … es funktioniert nicht für AdapterView-Unterklassen. Dafür müssen Sie Ausnahmen behandeln. Ruhe es funktioniert gut. Das ist, was ich in meinem Code verwende und es funktioniert gut. Hoffe das hilft.

    – hp.android

    21. November 2011 um 13:27 Uhr

  • @hp.android Haben Sie mit “behandeln Sie dies in der Ausnahme” ein Beispiel dafür, wie das aussehen würde? Ich frage, weil ich Seiten mit Bildern in meinem habe PageAdapter und ich werde von diesem Fehler überarbeitet 🙁

    – Jacksonkr

    2. Mai 2012 um 17:40 Uhr

  • @Jackson ändern Sie einfach die Bedingung: if (view instanceof ViewGroup && !(view instanceof AdapterView)) Dadurch wird die Ausnahme beseitigt, die Sie für Adapter erhalten

    – hp.android

    8. Mai 2012 um 6:29 Uhr

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

Meistens für Google-Reisende aus der Zukunft:

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

  • Ab Android 3.0 (Honeycomb) werden Drawables im Heap gespeichert

    – Gu1234

    13. September 2011 um 8:16 Uhr

  • @Timo was würden Sie dann verwenden, um Lecks im nativen Heap zu erkennen?

    – sydd

    5. Dezember 2011 um 2:59 Uhr

  • Testen, viel testen. Das Problem ist, dass Sie aufgrund von Speicherfreigabe und anderen Optimierungstechniken nicht einmal wirklich sagen können, wie viel Speicher Ihre App verwendet. Sie können Speicherwerte mit den üblichen Shell-Befehlen abrufen, aber das sind sehr, sehr grobe Schätzungen.

    – Timo Ohr

    6. Dezember 2011 um 9:03 Uhr

Die Antwort von @hp.android funktioniert gut, wenn Sie nur mit Bitmap-Hintergründen arbeiten, aber in meinem Fall hatte ich eine BaseAdapter Bereitstellung einer Reihe von ImageViews für a GridView. Ich habe die modifiziert unbindDrawables() Methode wie empfohlen, so dass die Bedingung ist:

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

aber das Problem ist dann, dass die rekursive Methode niemals die Kinder von verarbeitet 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 Kinder der AdapterView werden immer noch verarbeitet – die Methode versucht einfach nicht, alle untergeordneten Elemente zu entfernen (was nicht unterstützt wird).

Dies behebt das Problem jedoch nicht ganz ImageViews verwalten eine Bitmap, 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 die unbindDrawables() Methode ist 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 prinzipientreueren Ansatz gibt, um solche Ressourcen freizugeben.

Guter Google I/O Vortrag (2011) über Memory Management in Android, sowie Details zu Tools + Techniken für Memory Profiling:
http://www.youtube.com/watch?v=_CruQY55HOk

  • Oder der entsprechende Blogbeitrag: android-developers.blogspot.com/2011/03/…

    – greg7gkb

    17. April 2012 um 0:35 Uhr

  • Okay, ich habe also einen Benutzer, der ständig zwischen Aktivitäten wechselt, was bedeutet, dass er möglicherweise 15 Aktivitäten in 20 Sekunden gewechselt hat. Könnte das eine Ursache für einen Speicherfehler sein? Was soll ich tun, um es zu beheben? Danke!’

    – Ruchir Baronia

    5. Januar 2016 um 5:44 Uhr

Welche Android Tools und Methoden funktionieren am besten um Speicher Ressourcenlecks zu
jww

Valgrind wurde auf Android portiert (gesponsert von Mozilla). Sehen Valgrind auf Android – Aktueller Status und Unterstützung der Ausführung von Valgrind für Android auf ARM (Kommentar 67).

  • Oder der entsprechende Blogbeitrag: android-developers.blogspot.com/2011/03/…

    – greg7gkb

    17. April 2012 um 0:35 Uhr

  • Okay, ich habe also einen Benutzer, der ständig zwischen Aktivitäten wechselt, was bedeutet, dass er möglicherweise 15 Aktivitäten in 20 Sekunden gewechselt hat. Könnte das eine Ursache für einen Speicherfehler sein? Was soll ich tun, um es zu beheben? Danke!’

    – Ruchir Baronia

    5. Januar 2016 um 5:44 Uhr

Welche Android Tools und Methoden funktionieren am besten um Speicher Ressourcenlecks zu
Fred Grott

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

Haben Sie versucht, Bereiche des Codes mit dem Android Mock Framework zu testen?

  • nicht so sehr, Tests dieser Art sind weniger das Problem als aufzuzeichnen, was tatsächlich passiert, während die Anwendung läuft. Was ich wirklich brauche, ist ein Ressourcen-/Speicherleck-Profilerstellungstool

    – Jottos

    20. Juli 2009 um 18:48 Uhr

928990cookie-checkWelche Android-Tools und -Methoden funktionieren am besten, um Speicher-/Ressourcenlecks zu finden? [closed]

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy