Wie viel RAM kann eine App maximal verwenden?

Ich bin ziemlich neugierig auf diese Frage bezüglich der Speicherverwaltung des Android-Betriebssystems Daher hoffe ich auf eine recht ausführliche Antwort zu diesem Thema.

Was ich wissen möchte:

• Was ist der maximale Speicherkapazität (in Megabyte / wie
  Prozentsatz des gesamten Arbeitsspeichers), die eine Android-Anwendung (die keine System-App ist) verwenden kann?
• Gibt es Unterschiede zw Android-Versionen?
• Gibt es Unterschiede bzgl Hersteller des Geräts?

Und am wichtigsten:

• Was gilt als / wovon hängt es ab wenn es darum geht, das System zu bestimmen, wie viel RAM eine App zur Laufzeit verwenden kann (unter der Annahme, dass das Speichermaximum pro App keine statische Zahl ist)?

Was ich bisher gehört habe (bis 2013):

• Frühe Android-Geräte hatten eine Obergrenze von 16 MB pro App
• Später wurde diese Obergrenze auf 24 MB oder 32 MB erhöht

Was mich sehr neugierig macht:

Beide Grenzwerte sind sehr niedrig.

Ich habe die erst kürzlich heruntergeladen Android-Task-Manager um den RAM meines Geräts zu überprüfen. Was mir aufgefallen ist, ist, dass es Anwendungen gibt, die etwa 40-50 Megabyte RAM verwenden, was offensichtlich mehr ist als die erwähnte maximale RAM-Nutzung von sagen wir 32 MB. Wie bestimmt Android also, wie viel RAM eine App verwenden kann? Wie ist es möglich, dass Apps dieses Limit überschreiten?

Außerdem ist mir aufgefallen, dass einige Apps von mir mit einem abstürzen (vom System getötet?). OutOfMemoryException bei der Verwendung von etwa 30-40 Megabyte. Auf der anderen Seite laufen Apps auf meinem Telefon 100 MB und mehr nach einiger Zeit (wahrscheinlich aufgrund von Speicherlecks), die nicht abstürzen oder getötet werden. So Es hängt natürlich auch von der App selbst ab wenn es darum geht zu bestimmen, wie viel RAM eingespart werden kann. Wie ist das möglich? (Ich habe meine Tests mit einem HTC One S mit 768 MB RAM durchgeführt)

Haftungsausschluss: Ich bin in keiner Weise mit der Android Task Manager-App verbunden.

Was ist die maximale Speichermenge (in Megabyte / als Prozentsatz des gesamten RAM), die eine Android-Anwendung (die keine System-App ist) verwenden kann?

Das ist je nach Gerät unterschiedlich. getMemoryClass() an ActivityManager gibt Ihnen den Wert für das Gerät, auf dem Ihr Code ausgeführt wird.

Gibt es Unterschiede zwischen den Android-Versionen?

Ja, sofern die Anforderungen an die Betriebssysteme im Laufe der Jahre gestiegen sind und sich die Geräte daran anpassen müssen.

Gibt es Unterschiede bezüglich des Geräteherstellers?

Ja, sofern Hersteller Geräte herstellen und die Größe je nach Gerät variiert.

Welche “Nebenfaktoren” werden berücksichtigt, wenn es darum geht, zu bestimmen, wie viel RAM eine App verwenden kann?

Ich habe keine Ahnung, was “Nebenfaktoren” bedeutet.

Frühe Geräte hatten eine Obergrenze von 16 MB pro App; Spätere Geräte erhöhten diese auf 24 MB oder 32 MB

Das ist ungefähr richtig. Die Bildschirmauflösung ist eine wichtige Determinante, da größere Auflösungen größere Bitmaps bedeuten, und daher haben Tablets und hochauflösende Telefone tendenziell noch höhere Werte. Beispielsweise sehen Sie Geräte mit 48-MB-Heaps, und es würde mich nicht überraschen, wenn es höhere Werte gibt.

Wie ist es möglich, dass Apps dieses Limit überschreiten?

Sie gehen davon aus, dass der Autor dieser App weiß, was er tut. In Anbetracht der Tatsache, dass die Speichernutzung einer App für einen Core-Android-Ingenieur schwer zu bestimmen ist, würde ich nicht davon ausgehen, dass die betreffende App unbedingt besonders genaue Ergebnisse liefert.

Allerdings unterliegt nativer Code (NDK) nicht dem Heap-Limit. Und seit Android 3.0 können Apps einen “großen Heap” anfordern, normalerweise im Bereich von Hunderten von MB, aber das wird für die meisten Apps als schlechte Form angesehen.

Außerdem ist mir aufgefallen, dass einige Apps von mir mit einer OutOfMemoryException abstürzen, wenn sie etwa 30-40 Megabyte verwenden.

Beachten Sie, dass der Android-Garbage Collector kein komprimierender Garbage Collector ist. Die Ausnahme sollte wirklich sein CouldNotFindSufficientlyLargeBlockOfMemoryExceptionaber das wurde wohl als zu wortreich empfunden. OutOfMemoryException bedeutet, dass Sie konnte Ihren angeforderten Block nicht zuweisennicht dass Sie Ihren Haufen vollständig erschöpft haben.

Es ist Ende 2018, also haben sich die Dinge geändert.

Zunächst einmal: Führen Sie Ihre App aus und öffnen Sie die Registerkarte Android Profiler in Android Studio. Sie werden sehen, wie viel Speicher es verbraucht, Sie werden überrascht sein, aber es kann viel RAM zuweisen.

Ebenfalls hier ist ein toller Artikel in offiziellen Dokumenten mit detaillierten Anweisungen zur Verwendung von Memory Profiler, die Ihnen einen detaillierten Einblick in Ihre Speicherverwaltung geben können.

In den meisten Fällen reicht Ihnen jedoch Ihr normaler Android-Profiler aus.

Normalerweise beginnt eine App mit 50 MB RAM-Zuweisung, springt aber sofort auf 90 MB, wenn Sie beginnen, einige Fotos in den Speicher zu laden. Wenn Sie Activity mit einem ViewPager mit vorinstallierten Fotos (jeweils 3,5 MB) öffnen, können Sie in Sekundenschnelle 190 MB erreichen.

Dies bedeutet jedoch nicht, dass Sie Probleme mit der Speicherverwaltung haben.

Der beste Rat, den ich geben kann, ist, die Richtlinien und Best Practices zu befolgen, die besten Bibliotheken zum Laden von Bildern zu verwenden (Glide, Picasso) und Sie werden in Ordnung sein.

Aber wenn Sie etwas anpassen müssen und wirklich wissen müssen, wie viel Speicher Sie manuell zuweisen können, können Sie den gesamten freien Speicher abrufen und einen vorher festgelegten Anteil (in %) daraus berechnen. In meinem Fall musste ich entschlüsselte Fotos im Speicher zwischenspeichern, damit ich sie nicht jedes Mal entschlüsseln muss, wenn der Benutzer durch die Liste gleitet.

Zu diesem Zweck können Sie gebrauchsfertig verwenden LruCache-Klasse. Es ist eine Cache-Klasse, die automatisch verfolgt, wie viel Speicher Ihre Objekte zuweisen (oder die Anzahl der Instanzen), und die ältesten entfernt, um die neuesten anhand ihres Nutzungsverlaufs beizubehalten.
Hier ist ein tolles Tutorial, wie man es benutzt.

In meinem Fall habe ich zwei Instanzen von Caches erstellt: für Daumen und Anhänge. Sie wurden mit Singleton-Zugriff statisch gemacht, sodass sie global in der gesamten App verfügbar sind.

Cache-Klasse:

public class BitmapLruCache extends LruCache<Uri, byte[]> {

    private static final float CACHE_PART_FOR_THUMBS_PRC = 0.01f; // 1% (Nexus 5X - 5Mb)
    private static final float CACHE_PART_FOR_ATTACHMENTS_PRC = 0.03f;// 3% (Nexus 5X - 16Mb)
    private static BitmapLruCache thumbCacheInstance;
    private static BitmapLruCache attachmentCacheInstance;

public static synchronized BitmapLruCache getDecryptedThumbCacheInstance() {
    if (thumbCacheInstance == null) {

        int cacheSize = getCacheSize(CACHE_PART_FOR_THUMBS_PRC);
    //L.log("creating BitmapLruCache for Thumb with size: " + cacheSize + " bytes");
        thumbCacheInstance = new BitmapLruCache(cacheSize);
        return thumbCacheInstance;
    } else {
        return thumbCacheInstance;
    }
}

public static synchronized BitmapLruCache getDecryptedAttachmentCacheInstance() {
    if (attachmentCacheInstance == null) {

        int cacheSize = getCacheSize(CACHE_PART_FOR_ATTACHMENTS_PRC);
    //            L.log("creating BitmapLruCache for Attachment with size: " + cacheSize + " bytes");
        attachmentCacheInstance = new BitmapLruCache(cacheSize);
        return attachmentCacheInstance;
    } else {
        return attachmentCacheInstance;
    }
}

private BitmapLruCache(int maxSize) {
    super(maxSize);
}

public void addBitmap(Uri uri, byte[] bitmapBytes) {
    if (get(uri) == null && bitmapBytes != null)
        put(uri, bitmapBytes);
}

public byte[] getBitmap(Uri uri) {
    return get(uri);
}


@Override
protected int sizeOf(Uri uri, byte[] bitmapBytes) {
    // The cache size will be measured in bytes rather than number of items.
    return bitmapBytes.length;
}
}

So berechne ich den verfügbaren freien RAM und wie viel ich daraus beißen kann:

private static int getCacheSize(float partOfTotalFreeMemoryToUseAsCache){
    final long maxMemory = Runtime.getRuntime().maxMemory();
    //Use ... of available memory for List Notes thumb cache
    return (int) (maxMemory * partOfTotalFreeMemoryToUseAsCache);
}

Und so verwende ich es in Adaptern, um ein zwischengespeichertes Bild zu erhalten:

byte[] decryptedThumbnail = BitmapLruCache.getDecryptedThumbCacheInstance().getBitmap(thumbUri);

und wie ich es im Hintergrundthread (reguläre AsyncTask) in den Cache setze:

BitmapLruCache.getDecryptedThumbCacheInstance().addBitmap(thumbUri, thumbBytes); 

Meine App zielt auf API 19+ ab, sodass die Geräte nicht alt sind und diese Teile des verfügbaren RAM in meinem Fall gut genug für den Cache sind (1 % und 3 %).

Lustige Tatsache: Android hat keine APIs oder andere Hacks, um die Ihrer App zugewiesene Speichermenge abzurufen, sie wird spontan auf der Grundlage verschiedener Faktoren berechnet.

PS Ich verwende ein statisches Klassenfeld, um einen Cache zu speichern, aber gemäß den neuesten Android-Richtlinien wird die Verwendung empfohlen ViewModel-Architekturkomponente zu diesem Zweck.

Speicherlimits pro App sind hier abhängig von Bildschirmgröße und Android-Version: https://drive.google.com/file/d/0B7Vx1OvzrLa3Y0R0X1BZbUpicGc/view?usp=sharing

Quelle: Downloads zur Android-Kompatibilität http://source.android.com/compatibility/downloads.html; Compatibility Definition Document (CDD), Abschnitt Virtual Machine Compatibility oder Runtime Compatibility

Es gibt kein Limit mehr, zumindest wenn Sie NDK wählen. Warum sollte es? Denken Sie daran, dass Android ursprünglich aus der Welt der eingebetteten Geräte stammte, in der jede App klare, einfache Aufgaben zu erledigen hatte und oft überhaupt keine dynamische Speichernutzung zuließ.

Es wurde nicht als Allzwecksystem betrachtet. Wir können immer noch viele Designartefakte dieser alten Zeiten sehen, die auf einem “echten Computer” nie Sinn gemacht haben und ein Grund dafür sind, warum iOS so viele bessere Apps hat als Android, es wurde viel besser und einfacher für benutzergesteuerte Aufgaben programmiert .

Wichtig beim App-Design ist, dass Ihre Aktivität gut auf „onLowMemory“-Signale reagiert.

Im Moment arbeite ich an einer App und das Samsung Ultra S21, das ich verwende (obwohl 16 GB RAM verfügbar sind …), erlaubt mir nicht, mehr als 500 MB für diese App zu verwenden, selbst mit android:largeHeap=”true” in das Manifest.