Sunt de lucru pe un joc pentru iPhone, care utilizează un MKMapView ca playfield. După numai câteva minute de joc app în mod inevitabil, începe să se lent și în cele din urmă se blochează din cauza memoriei reduse. După ce în jurul valorii de săpat vinovatul pare să fie că vizualizarea hărții cere în mod constant mai multă memorie. Jocul necesită o mulțime de zoom și panoramare a hărții, așa că am putea presupune doar că memoria cache a hărții de dale doar continuă să crească până când rămâne fără memorie. Există vreo modalitate de a forța hărții pentru a spăla este cache de gresie sau conțin este consumul de memorie?
Goliți memoria cache MKMapView de gresie?
voturi
6
3 răspunsuri
voturi 4
4
* NOTĂ: Acest răspuns este relevant numai la iOS 4.1 și mai mici. Problemele descrise în acest răspuns au fost în mare parte fixă în iOS 4.2 *
Am făcut niște cercetări pe aceasta ca aplicația mea folosește atât pe hartă, și, de asemenea, are alte caracteristici care necesită memorie RAM de mare.
Nu am găsit un răspuns, ci o soluție. cererile de memorie MKMapView lui escalada exponențial pe măsură ce măriți mai aproape într-o zonă, și deplasa în această zonă mărită.
Există două niveluri de MKMapView cache sect. Unul se manifestă ca un malloc ~ 196kb în Instruments, celălalt este NSData (magazin) de diferite dimensiuni.
Malloc pare a fi activi blocurileafișate-utilizare, și există un capac greu pe cât de multe pot fi alocate. În aplicația mea acest număr este de 16, nu este sigur dacă se bazează pe dimensiunea sa UIView sau nu. Aceste alocări par să fie gestionate stringent, și răspunde la avertismente de memorie.
Oricum, la un anumit nivel de zoom, să zicem, nivelul de continent (suficient pentru a se potrivi cele mai multe dintre America de Nord într-un ecran iPad), având în vedere dimensiunea placilor, în cazul în care nu are într-adevăr pentru a ajunge la acest al doilea nivel de cache (NSData (magazin) ), în scopul de a completa harta. Totul este clar și curat. Dacă aș încărca într-o tona de imagini externe în memoria activă, gresie sa se curete. Minunat!
Problema vine atunci când hit-uri ca al doilea nivel de cache. Acest lucru se întâmplă când măriți, și dintr-o dată în loc de 16 piese pentru a arăta întreaga PLANAT, ea are nevoie de 16 placi doar pentru a scoate în Los Angelas, și în timp ce pan in jurul in loc de dumping aceste placi vechi le pune în NSData (magazin ), alocările în cazul în care acestea nu par să se elibereze.
Acest NSData (magazin) este NSURLConnectionCache care există în mod implicit numai în memorie. Nu puteți accesa această memorie cache pentru ao limita, pentru că nu este cache-ul implicit partajat (încercat deja).
Deci, acest lucru este în cazul în care mă blocat.
Răspunsul nesatisfacator este că, dacă dezactivați harta zoom-ului și fixați-l la un nivel rezonabil de zoom larg, puteți evita această problemă complet, dar, evident, unele aplicații au nevoie de acest lucru ... și asta e ceea ce am primit.
Am depus un bilet de sprijin cu Apple pentru a vedea dacă acestea pot divulga nici un fel de a limita acest cache ridicol pentru hartă (care, prin modul în care am fost în stare să manivelă la întâmplare până la 50+ magabytes RAM alocate în memoria activă).
Sper că acest lucru vă ajută.
Editați | ×
Următorul comunicat de iOS pare să fi rezolvat această problemă cache nelimitate. MKMapView acum agresiv datele sale curăță țiglă stocate în memoria cache. BUCURA!
voturi 2
2
Sunteți setarea identificatorul de reutilizare pe opiniile adnotări? (Acest lucru înseamnă că sistemul poate detașa aceste puncte de vedere și doar să păstreze un număr mic de puncte de vedere în memorie la o dată. De asemenea, crește performanța de derulare, deoarece defilare va reutiliza opiniile detașate.)
Utilizați această metodă pentru a obține o imagine adnotare pentru a fi reutilizate:
- (MKAnnotationView *)dequeueReusableAnnotationViewWithIdentifier:(NSString *)identifier
voturi 1
1
Dacă creați o aplicație cu doar mapkit și o dimensiune vedere 768x1024 (dimensiunea iPad), aplicația poate consuma cu ușurință peste 30+ MB de „Bytes Live“ raportate de programul Instruments Alocări. Acest lucru a fost observat care rulează pe v3.2.2 iPad iOS (cea mai recentă versiune până la următoarea săptămâni presupuse 4.2 de eliberare). Din cercetarea mea se pare că această cantitate de memorie este mult pentru o singură aplicație, în cazul în care majoritatea dezvoltatorilor care primesc rapoarte o memorie de nivel 1 de avertizare în jurul valorii de 15-25 MB și se blochează la scurt timp după acest nivel.