Der AFNetworking Image-Cache wird nicht im Speicher gelöscht

8

Ich habe eine Image-starke Anwendung, in der ich Bilder mit der Kategorie UIImageView + AFNetworking herunterlade.

Ich bemerkte, dass mein Speicherbedarf weiter ansteigen würde, wenn ich mehr und mehr Bilder geladen hätte. Als ich schließlich eine Erinnerung erhielt, gab es keinen Speicher frei - und die Anwendung stürzte ab. Mein Verständnis davon ist, dass AFNetworking eine Unterklasse von NSCache namens AFImageCache verwendet, die Speicherwarnungen selbst behandeln soll. Link 1 Link 2

Mit einigen Dirty-Hacks löschte ich alle Objekte aus dem geteilten Cache manuell und sah eine signifikante Verringerung der Speicherzuweisungen. Dies scheint niemals zu passieren, ohne diesen Aufruf manuell auszuführen.

Ich habe das in einer einfachen Anwendung dupliziert, die die Titelseite von Imgur herunterlädt und in einer einfachen Tabellenansicht anzeigt. Oben sehen Sie das Zuordnungsprofil für die Anwendung.

Ich habe versucht, etwas ausgefallenes zu entfernen und der Code ist an einigen Stellen unordentlich. Es beinhaltet nicht meinen Dirty-Hack, also stirbt es einfach bei Speicherwarnungen. Sie können die Anwendung hier sehen.

Sie müssen eine Anwendung bei imgur einrichten, um sie zu verwenden.

Das Lesen von github-Problemen Mattt scheint darauf hinzuweisen, dass es ausreichend und vollständig selbstverwaltend sein sollte, solange Sie die richtige Cache-Policy auf die von Ihnen übergebene NSURLRequest setzen. Ich vermisse etwas, aber ich bin mir nicht sicher, welcher Cache Politik würde ich einstellen. Es scheint alles so zu sein, dass man geänderte Bilder zurückholt, anstatt sich um der Erinnerung willen zu reinigen.

Ich denke auch, dass sich "lieven" in demselben Problem mit dem gleichen Problem befasst, dass, außer wenn totalCostLimit gesetzt ist Cache wird nicht selbstreinigend. Obwohl ich in solchen Fällen den Simulator gepaart mit simulierten Speicherwarnungen nicht traue, sind die Symptome identisch.

Ich freue mich über jede Hilfe bei der Fehlersuche

Bearbeiten

Profiling-Aktualisierung nach dem Hinzufügen des vorgeschlagenen Codes von

    
niklasdstrom 04.02.2014, 00:02
quelle

2 Antworten

11

Der Bild-Cache von AFNetworking verwendet NSCache, das den systemweiten Speicherdruck löscht, jedoch nicht die Speicherwarnung einer einzelnen App.

Um das zu erreichen, 2.x-Zweig von AFNetworking diesen Code hinzugefügt:

%Vor%

, wodurch der Cache bei einer Speicherwarnung gelöscht wird.

Wenn Sie sich noch immer im 1.x-Zweig befinden , dieser Code ist nicht enthalten ( UPDATE: wurde in dieses Commit ), was zu dem angezeigten Verhalten führen kann. Sie könnten auf 2.x aktualisieren oder diesen Code einfach in Ihre App einfügen.

  

Es sollte ausreichend sein und vollständig selbst verwaltet werden, solange Sie die richtige Cache-Richtlinie für die NSURLRequest festlegen, die Sie übergeben

Beachten Sie, dass NSCache und NSURLCache zwei sehr unterschiedliche Klassen sind. NSCache ist derjenige, den Sie in Ihrer Frage suchen. NSURLCache dagegen speichert nur Antworten auf URL-Ladeanforderungen.

UIImageView + AFNetworking verwendet NSCache zum Speichern von UIImage-Objekten. NSURLCache speichert NSData-Objekte, und das Abrufen von Objekten aus diesem Cache ist normalerweise nicht leistungsfähig genug für Anwendungen mit hohem Image, die Bilder in einer UITableView- oder UICollectionView anzeigen.

Abschließend möchten Sie vielleicht Ihre Implementierung mit einer vergleichen, die das Projekt SDWebImage verwendet. SDWebImage bietet Festplatten- und Speicher-Caching und gibt Ihnen viel mehr Kontrolle über die Details als AFiWorking's UIImageView + AFNetworking.

    
Aaron Brager 04.02.2014, 00:05
quelle
0

AFNetworking hat diesen Fix nun für seinen 1.x-Zweig und seinen 2.x-Zweig festgelegt. Es ist nicht mehr notwendig, auf AFNetworking 2.x zu aktualisieren, um das Problem zu beheben. Sie müssen UIImageView + AFNetworking.m nicht länger bearbeiten.

Hier ist das Commit: Ссылка

Sie können die feste Version der Datei hier sehen: Ссылка

    
Kyle Robson 21.08.2014 01:02
quelle