Android hat eine sehr begrenzte maximale Heap-Größe, jedes Gerät hat einen anderen Max-Heap.
Einige Apps müssen Objekte (normalerweise Bilder) im Speicher und nicht nur im internen / externen Speicher zwischenspeichern können.
Natürlich gibt es viele nette Tipps in Bezug auf Umgang mit Bitmaps und Verwendung so wenig Speicher wie möglich, aber Caching ist auch eine notwendige Sache.
Ich habe viele mögliche Lösungen für das Caching gelesen, aber keines bietet eine Art Caching, das eine mörderische Caching-Lösung wäre. Was ich gerne haben möchte, ist ein Caching-Mechanismus, der die nächsten Funktionen hat:
Unbegrenzte Verwendung des Heapspeichers, ohne sich Gedanken über zu wenig Arbeitsspeicher machen zu müssen. App braucht Speicher und es gibt nicht genug freien Speicher? also einige (nicht referenzierte) Elemente (und ihre Schlüssel) freigeben.
Thread Sicherheit / Gleichzeitigkeit.
Bieten Sie LRU-basiertes Caching an, so dass Elemente, die kürzlich verwendet wurden, eine höhere Chance haben, zu bleiben.
Am Leben bleiben so viel wie möglich (noch keine Abstürze verursachen). Leider werden Soft / Weak-Referenzen auf Android im Vergleich zu Java sehr schnell GC-ediert.
Fähigkeit, mit Objekten umzugehen, die ihre wahre Größe verbergen. In Android, auf API 10 und darunter, verwendeten Bitmaps nicht den Heap - Speicher, sondern wurden als solche betrachtet, so dass die VM nicht wissen konnte, wann sie freigegeben werden sollten, da sie dieselbe Speichermenge wie eine einzige Referenz verwendet (4 Bytes oder so). Aus diesem Grund bieten einige Lösungen die Möglichkeit, künstlich zu bestimmen, wie groß die einzelnen Elemente sind und was zu tun ist, wenn sie entfernt werden sollen.
LruCache - eine Klasse von API 12 (Sie können einfach seinen Code kopieren).
Vorteile: # 2 (?), # 3, # 5.
Nachteile: # 1, # 4, und Sie müssen seinen Quellcode kopieren, da er in API 12 dargestellt wurde.
Ein hashmap mit einer weichen / schwachen Referenz für seine Werte , wie in hier auf Seite 50, aufgenommen von diesem Vortrag .
Vorteile: # 1 (aber nicht Schlüssel entfernen), # 2 (müssen verwenden ConcurrentHashMap )
Nachteile: # 3, # 4, # 5
MapMaker (verfügbar unter die Guava-Bibliothek ), die wie eine erweiterte Version der vorherigen Lösung aussieht.
>Vorteile: # 1, # 2
Nachteile: # 3, # 4, # 5
Caching-Lösungen über die Guavenbibliothek. Vor- und Nachteile basieren auf Ihrer Wahl. Nicht sicher, welche Konfigurationen die Bedürfnisse am besten erfüllt, und ob es auf Android funktioniert. Leider kann ich nicht einmal die Bibliothek für Android kompilieren.
Android-Abfrage - nicht sicher, wie es funktioniert. Scheint sehr einfach zu bedienen, aber nicht sicher über seine Vor- und Nachteile.
Kennt jemand einen Killer-Caching-Mechanismus?
Ich interessiere mich weniger für Feature # 5, da es ziemlich fortgeschritten ist und in Zukunft nicht so oft benötigt wird, da immer mehr Leute neue Android-Versionen haben.
Wie ich sehen kann, gibt es ein praktisches Verbotsproblem mit # 1. Sie können keine Objekte freigeben, auf die von anderen Teilen der App verwiesen wird. Daher ist es unmöglich, ein Konstrukt zu erstellen, das den Willen des Gedächtnisses freigibt.
Die einzige Lösung, die ich sehe, ist das Erstellen eines eigenen Caches, das LRU unterstützt und sowohl schwache als auch starke Referenzen verarbeiten kann. Ein Element beginnt als stark referenziertes Objekt und wenn es eine Weile nicht verwendet wird oder Speicherbeschränkungen erzwingen, ändern Sie es in eine schwache Referenz. Dies ist nicht einfach zu erstellen und Feinabstimmung muss in allen Anwendungen sicher durchgeführt werden.
Sie suchen wahrscheinlich nach einer allgemeineren Lösung, aber wenn Sie sich hauptsächlich auf Bilder konzentrieren, sehen Sie sich ImageLoader . Ich benutze es seit einer Weile und es funktioniert sehr gut für das, was ich brauche. Wenn Sie es initialisieren, können Sie ihm einen LRUCache geben und ihm sagen, wieviel% des freien Speichers er verwenden soll.
Als Nebenbemerkung macht HttpResponseCache das Zwischenspeichern von Daten von einem Server sehr, sehr schön.
Tags und Links android caching bitmap out-of-memory heap-memory