Ik ben bezig met een iPhone-spel dat een MKMapView als het speelveld gebruikt. Na slechts een paar minuten van het spel onvermijdelijk de app begint traag te komen en uiteindelijk crasht vanwege de lage geheugen. Na het graven rond de boosdoener lijkt te zijn dat de kaartweergave voortdurend vraagt om meer geheugen. Het spel vereist veel zoomen en panning van de kaart, dus ik kan alleen maar veronderstellen dat de kaart de cache van de tegels blijft maar groeien totdat het loopt uit van het geheugen. Is er een manier om de kaartweergave te dwingen om te spoelen is het cache van tegels of bevatten het geheugengebruik?
Clear MKMapView's cache van de tegels?
stemmen
6
3 antwoorden
stemmen 4
4
* Opmerking: Dit antwoord is alleen relevant voor iOS 4.1 en lager. De in dit antwoord beschreven problemen werden vooral vastgesteld in iOS 4.2 *
Ik heb wat graven op dit als mijn app maakt gebruik van zowel de kaart en heeft ook andere functies die hoge RAM eisen.
Ik heb geen antwoord gevonden, maar een tijdelijke oplossing. MKMapView geheugen eisen escaleren exponentieel als je dichter in om een gebied te zoomen en pannen rond binnen die ingezoomde gebied.
Er zijn twee niveaus van MKMapView tegel cache. Eén manifesteert zich als een Malloc ~ 196kb in Instruments, de andere is NSData (winkel) van verschillende grootte.
De Malloc lijkt de actief in gebruik tegels, en er is een harde cap op hoeveel kan worden toegewezen. In mijn app die nummer is 16, niet zeker of het op basis van UIView grootte of niet. Deze toewijzingen lijken streng worden beheerd, en het reageert op het geheugen waarschuwingen.
Hoe dan ook, op een bepaald zoomniveau, laten we zeggen, continent niveau (genoeg om de meeste van Noord-Amerika past in een iPad-scherm), gezien de omvang van de tegels, als nooit echt moet dat tweede niveau van caching te krijgen (NSData (Store) ), om de kaart te voltooien. Alles is fris en schoon. Als ik geladen in een ton van externe afbeeldingen in actieve geheugen, de tegels snoeien zichzelf. Geweldig!
Het probleem komt wanneer het hits die tweede niveau van caching. Dit gebeurt wanneer je inzoomt, en plotseling in plaats van 16 tegels om de hele Planat laten zien, het moet 16 tegels gewoon om te pronken met Los Angelas, en zoals u rond te kijken in plaats van alleen dumping die oude tegels het brengt hen in de NSData (winkel ) toewijzingen waar ze lijken te worden nooit bevrijd.
Dit NSData (opslag) de NSURLConnectionCache die alleen in het geheugen bestaat standaard. U hebt geen toegang tot deze cache te beperken, want het is niet de standaard gedeelde cache (al geprobeerd).
Dus dit is waar ik vast komen te zitten.
De onbevredigende antwoord is dat als je kaart zoomen uitschakelen en bevestig deze op een redelijk brede zoom-niveau, kunt u dit probleem volledig te vermijden, maar uiteraard sommige apps dit nodig hebben ... en dat is voor zover ik kreeg.
Ik diende een support ticket met Apple om te zien of ze een manier om dit belachelijke cache voor de kaart (die door de manier was ik in staat om terloops crank tot 50+ Mb RAM-geheugen in het actieve geheugen toegewezen) te beperken kunnen onthullen.
Ik hoop dat dit helpt.
Bewerk
De volgende iOS versie lijkt dit onbegrensde cache probleem te hebben opgelost. MKMapView nu agressief snoeit haar gecachte tegel data. VERHEUGEN!
stemmen 2
2
Bent u het instellen van het hergebruik identifier op uw mening annotatie? (Dit betekent dat het systeem kan deze opvattingen los te maken en alleen houden een klein aantal aanzichten in het geheugen in een keer. Het verhoogt ook het scrollen prestaties, omdat het scrollen Het vrijstaande standpunten opnieuw te gebruiken.)
Gebruik deze methode om een aantekening te worden hergebruikt krijgen:
- (MKAnnotationView *)dequeueReusableAnnotationViewWithIdentifier:(NSString *)identifier
stemmen 1
1
Als u een app met alleen de mapkit en een grootte van 768x1024 (ipad grootte) uitzicht te creëren, kan de app gemakkelijk te consumeren meer dan 30 + MB "Leef Bytes" zoals gerapporteerd door Instruments Toekenningen programma. Dit werd opgemerkt draait op de iPad iOS v3.2.2 (de laatste versie tot volgende weken zou versie 4.2). Uit mijn onderzoek blijkt dat deze hoeveelheid geheugen is veel voor een enkele app, waar de meeste ontwikkelaars melden ontvangst van een level 1 geheugen waarschuwing rond 15-25 MB en crasht kort na dat niveau.