Dolgozom egy iPhone játék, amely egy MKMapView mint a pályán. Miután csak egy pár perc játék az alkalmazás elkerülhetetlenül kezd lassú és végül összeomlik az alacsony memória. Ásó körbe a tettes úgy tűnik, hogy a térkép folyamatosan követeli több memóriát. A játék megköveteli a sok nagyítás és pásztázás a térképen, így csak arra tudok gondolni, hogy a térkép cache csempe folyamatosan növekszik, amíg elfogy a memória. Van-e bármilyen módon, hogy erőt a térkép öblítse ez cache csempét vagy tartalmazhat ez a memória fogyasztás?
Tiszta MKMapView a gyorsítótárat lapban?
* Megjegyzés: Ez a válasz csak akkor vonatkozik a iOS 4.1 és az alacsonyabb. A leírt problémákat ez a válasz többnyire rögzített iOS 4.2 *
Csináltam néhány ásó ezen az én app használja mind a térkép és a másik jellemzővel is rendelkezik, hogy a kereslet a magas RAM.
Én nem találtam választ, de a megoldás. MKMapView memóriája igények megnőnek exponenciálisan zoom közelebb Egy terület, és mozgathatja belül nagyított területet.
Két szintje MKMapView csempe cache. Egy nyilvánul meg, mint egy Malloc ~ 196kb a Instruments, a másik pedig NSData (store) különböző méretű.
A Malloc tűnik az aktív használat csempe, és van egy kemény sapkát hány lehet felosztani. Az én app ez a szám 16, nem biztos abban, hogy alapul UIView mérete vagy sem. Ez a felosztás úgy tűnik, hogy szigorúan irányított, és reagál a memória figyelmeztetéseket.
Különben is, egy bizonyos nagyítási szinten, mondjuk, a kontinens szintjén (ahhoz, hogy elférjen a legtöbb észak-amerikai iPad képernyőn), mivel a méret a csempe, ha nem igazán van, hogy erre a második szintű gyorsítótár-(NSData (Store) ) annak érdekében, hogy töltse ki a térképet. Minden éles és tiszta. Ha töltsek egy csomó külső képeket aktív memóriát, a cserép szilva magukat. Fantasztikus!
A probléma akkor jön, amikor eléri a második szintű cache-t. Ez történik, ha nagyítani, és hirtelen 16 helyett csempe, hogy a teljes PLANAT, szüksége van 16 csempe, csak hogy megmutassák Los Angelas, és ahogy mozgathatja helyett csak dömping a régi csempe hozza őket a NSData (store ) elosztása, ahol úgy tűnik, hogy soha nem szabadult.
Ez NSData (store) a NSURLConnectionCache ami létezik alapértelmezés szerint csak a memóriában. Nem férhet hozzá ezt a gyorsítótárat korlátozni, mert ez nem az alapértelmezett megosztott cache (már próbáltam).
Tehát ez az, ahol elakad.
A nem kielégítő válasz az, hogy ha letiltja a térkép zoom és rögzítse azt egy eléggé széles nagyítási szinten, akkor elkerülhető ez a probléma teljesen, de természetesen néhány apps kell ez ... és ez amennyire kaptam.
Azt nyújtott be támogatási jegyet az Apple hátha tudnak hoznak nyilvánosságra semmilyen módon korlátozni ezt a nevetséges cache térkép (ami mellesleg tudtam, hogy véletlenül hajtókar akár 50+ mega RAM memóriát aktív memória).
Remélem ez segít.
szerkesztés
A következő iOS kiadása, úgy tűnik, megoldotta ezt a határtalan cache kérdés. MKMapView most agresszíven megtisztítja a gyorsítótárban tárolt csempe adatokat. Örvendjetek!
Te beállítás az újrahasznosítás azonosítót a kommentár nézeteit? (Ez azt jelenti, a rendszer le azokat a nézeteket, és csak tartani néhány nézetek a memóriában egyszerre. Ez is növeli görgetés teljesítményét, mert a görgetés lesz újra a családi nézeteit.)
Ezzel a módszerrel, hogy egy kommentárt céljából újra felhasználhatók:
- (MKAnnotationView *)dequeueReusableAnnotationViewWithIdentifier:(NSString *)identifier
Ha létrehoz egy alkalmazás csak a mapkit és a kilátás mérete 768x1024 (ipad méret), az alkalmazás könnyen elérhetik a több mint 30 + MB „Élő bájt” jelentése szerint Instruments Allocations programot. Ezt vették észre, fut a iPad iOS v3.2.2 (a legújabb verzió, amíg a következő hetekben állítólag 4.2 kiadás). Az én kutatási úgy tűnik, hogy ez a memória mennyisége sokkal egyetlen app, ahol a legtöbb fejlesztő jelentést kap egy 1. szintű memória figyelmeztető körül 15-25 MB és összeomlik után hamarosan ezt a szintet.













