Jeg jobber med en iPhone spill som bruker en MKMapView som playfield. Etter bare et par minutters spill app uunngåelig begynner å bli svak og til slutt krasjer på grunn av lite minne. Etter å grave rundt den skyldige synes å være at kartvisningen stadig krever mer minne. Spillet krever mye zooming og panorering av kartet, så jeg kan bare anta at kartets cache av fliser bare fortsetter å vokse helt til den går tom for minne. Er det noen måte å tvinge kartvisningen for å skylle det er cache av fliser eller inneholder det er minneforbruket?
Clear MKMapView buffer av fliser?
stemmer
6
3 svar
stemmer 4
4
* MERK: Dette svaret er kun relevant for iOS 4.1 og lavere. Problemene som er beskrevet i dette svaret var for det meste løst i iOS 4.2 *
Jeg har gjort noen graving på dette som min app bruker både kartet og har også andre funksjoner som krever høy RAM.
Jeg har ikke funnet et svar, men en midlertidig løsning. MKMapView sin minne krav eskalere eksponentielt når du zoomer nærmere i et område, og panorere rundt i det zoomet inn området.
Det er to nivåer av MKMapView flis cache. En manifesterer seg som en Malloc ~ 196kb i Instruments, er den andre NSData (lagre) av varierende størrelser.
Malloc ser ut til å være aktive i bruk fliser, og det er et hardt tak på hvor mange som kan bli tildelt. I min app som nummer 16, ikke sikker på om det er basert på UIView størrelse eller ikke. Disse bevilgningene synes å være strengt styrt, og den reagerer på minne advarsler.
Uansett, på et bestemt zoomnivå, sier kontinentet nivå (nok til å passe de fleste av Nord-Amerika i en iPad-skjermen), gitt størrelsen på flisene, om aldri egentlig har å komme til det andre nivået av caching (NSData (Store) ) for å fullføre kartet. Alt er klar og ren. Hvis jeg legger inn massevis av eksterne bilder til aktiv hukommelse, flisene beskjære selv. Rått!
Problemet kommer når den treffer det andre nivået av caching. Dette skjer når du zoomer inn, og plutselig i stedet for 16 brikker for å vise hele planat, det er behov for 16 brikker bare for å vise fram Los Angelas, og som du panorere rundt i stedet for bare dumping de gamle flisene det setter dem inn i NSData (butikken ) bevilgninger hvor de ser ut til å aldri bli frigjort.
Dette NSData (butikk) er NSURLConnectionCache som eksisterer som standard bare i minnet. Du kan ikke få tilgang til denne bufferen for å begrense det, fordi det ikke er standard delt cache (allerede prøvd det).
Så det er her jeg står fast.
Den utilfredsstillende svaret er at hvis du deaktiverer kartet zooming og fikse det på en rimelig bred zoomnivå, kan du unngå dette problemet helt, men tydeligvis noen apps trenger dette ... og det er så vidt jeg fikk.
Jeg lagt inn en support billett med Apple for å se om de kan røpe noen måte å begrense denne latterlig cache for kartet (som forresten var jeg i stand til å casually skru opp til 50 + Megs RAM tildelt i aktive minnet).
Håper dette hjelper.
redigere
Den neste iOS versjonen ser ut til å ha løst dette ubegrensede cache problemet. MKMapView nå aggressivt beskjærer sine bufret fliser data. FRYDE!
stemmer 2
2
Er du sette gjenbruk identifikator på merknads synspunkter? (Dette betyr at systemet kan løsne disse synspunkter og bare holde et lite antall utsikt i minnet på en gang. Det øker også rulling ytelse, fordi rulling vil gjenbruke de løsnede visninger.)
Bruk denne metoden for å få en kommentar sikte på å bli gjenbrukt:
- (MKAnnotationView *)dequeueReusableAnnotationViewWithIdentifier:(NSString *)identifier
stemmer 1
1
Hvis du oppretter en app med bare mapkit og utsikt størrelse 768x1024 (ipad størrelse), kan programmet lett forbruke over 30 + MB "Levende Bytes" som rapportert av Instruments Bevilgninger program. Dette ble lagt merke kjører på iPad iOS v3.2.2 (siste versjon før neste ukene ment 4.2 utgaven). Fra min forskning ser det ut til at denne mengden minne er mye for en enkelt app, der de fleste utviklerne rapportere motta et nivå en minne advarsel rundt 15-25 MB og krasjer like etter det nivået.