Ich arbeite an einem iPhone-Spiel, das ein MKMapView als Spielfeld benutzt. Nach nur ein paar Minuten Spielzeit startet die App unweigerlich träge zu bekommen und schließlich aufgrund des geringen Speichers abstürzt. Nach rund um die Täter zu graben scheint, dass die Kartenansicht ständig mehr Speicher verlangt werden. Das Spiel erfordert eine Menge Zoomen und Verschieben der Karte, so kann ich nur annehmen, dass der Cache des Karte von Fliesen einfach weiter wächst, bis es über genügend Arbeitsspeicher ausgeführt. Gibt es eine Möglichkeit die Kartenansicht zu zwingen, es ist Cache von Fliesen zu spülen oder es enthalten ist der Speicherverbrauch?
Klar MKMapView Cache von Fliesen?
stimmen
6
3 antworten
stimmen 4
4
* HINWEIS: Diese Antwort ist nur relevant für iOS 4.1 und niedriger. Die Probleme in dieser Antwort beschrieben wurden meist in iOS 4.2 gefixt *
Ich habe zu diesem Thema einige graben getan als meine App nutzt sowohl die Karte und hat auch andere Funktionen, die hohe RAM verlangen.
Ich habe keine Antwort, sondern eine Abhilfe gefunden. MKMapView die Speicheranforderungen eskalieren exponentiell, wie Sie näher heran in einem Bereich, und schwenken um, dass innerhalb der Fläche vergrößert.
Es gibt zwei Ebenen von MKMapView Kachel-Cache. Man äußert sich als Malloc ~ 196KB in Instruments, das andere ist NSData (Speicher) in unterschiedlichen Größen.
Die Malloc erscheint die aktiven In-Use-Fliesen zu sein, und es ist eine harte Kappe auf, wie viele können zugeordnet werden. In meiner app ist, dass Nummer 16, nicht sicher, ob seine basierend auf UIView Größe oder nicht. Diese Zuweisungen scheinen stringent verwaltet werden, und es reagiert auf Speicher Warnungen.
Wie auch immer, bei einer bestimmten Zoomstufe, sagt sie, Kontinent Ebene (genug, um die meisten von Nordamerika in einem iPad Bildschirm passen), die Größe der Fliesen gegeben, wenn nie wirklich auf diese zweite Ebene des Caching erhalten hat (NSData (Store) ), um die Karte zu vervollständigen. Alles ist frisch und sauber. Wenn ich in einer Tonne von externen Bildern in den aktiven Speicher zu laden, beschneiden die Fliesen selbst. Genial!
Das Problem kommt, wenn es diese zweite Ebene der Cache-Hits. Dies geschieht, wenn Sie die Ansicht vergrößern, und plötzlich statt 16 Kacheln die gesamte PLANAT zu zeigen, braucht es 16 Fliesen in unmittelbarem Los Angelas zu zeigen, und wie Sie statt schwenken um nur die alten Fliesen Dumping es setzt sie in die NSData (store ) Zuweisungen, wo sie scheinen nie freigegeben zu bekommen.
Diese NSData (Speicher) ist das NSURLConnectionCache, die nur im Speicher standardmäßig vorhanden ist. Sie können diesen Cache zugreifen, es zu begrenzen, weil es nicht der Standard-Shared-Cache ist (bereits versucht).
Also das ist, wo ich stecken.
Die unbefriedigende Antwort ist, dass, wenn Sie Karte Zoomen und fixieren Sie es zu einer einigermaßen breiten Zoomstufe zu deaktivieren, können Sie dieses Problem vollständig vermeiden können, aber offensichtlich einige Anwendungen benötigen diese ... und das ist so weit wie ich habe.
Ich legte ein Support-Ticket mit Apple, um zu sehen, ob sie irgendwelche Art und Weise verbreiten können diese lächerlichen Cache für die Karte zu begrenzen (die durch die Art und Weise kann mich beiläufig zu 50+ MB RAM im aktiven Speicher zugewiesen aufdrehen).
Hoffe das hilft.
bearbeiten
Die nächste iOS-Release erscheint dieses grenzenlos Cache Problem gelöst zu haben. MKMapView jetzt beschneidet aggressiv seine gecached Fliese Daten. JUBELN!
stimmen 2
2
Setzen Sie die Wiederverwendung Kennung auf Ihrer Beschriftungsansicht? (Dies bedeutet, dass das System diese Ansichten lösen kann und nur auf einmal eine kleine Anzahl von Ansichten in Erinnerung behalten. Es erhöht auch die Leistung Scrollen, weil Scrollen wird die abgelösten Ansichten wiederverwenden.)
Verwenden Sie diese Methode eine Anmerkung Ansicht erhalten wieder verwendet werden:
- (MKAnnotationView *)dequeueReusableAnnotationViewWithIdentifier:(NSString *)identifier
stimmen 1
1
Wenn Sie eine App nur mit dem MapKit und Blick Größe von 768x1024 (ipad Größe) erstellen, kann die App leicht verbrauchen über 30 + MB „Live-Bytes“, wie Instrumente Verrechnungen Programm gemeldet. Dies wurde auf dem iPad iOS v3.2.2 bemerkt läuft (die neueste Version bis zum nächsten Wochen Version 4.2 soll). Aus meiner Forschung scheint es, dass diese Menge an Speicher viel für eine einzelne App ist, wo die meisten Entwickler berichten über einen Level-1-Speicher Warnung um 15 bis 25 MB empfangen und stürzt bald nach diesem Niveau.