Je travaille sur un jeu iPhone qui utilise un MKMapView comme la surface de jeu. Après seulement quelques minutes de jeu l'application commence inévitablement à obtenir atone et finalement tombe en panne en raison de la faible mémoire. Après avoir creusé autour du coupable semble être que la vue de la carte exige toujours plus de mémoire. Le jeu nécessite beaucoup de zoom et de panoramique de la carte, donc je ne peux que supposer que le cache de tuiles de la carte ne cesse de grandir jusqu'à ce qu'il est à court de mémoire. Est-il possible de forcer l'affichage de la carte pour vider son cache de tuiles ou contenir sa consommation de mémoire?
Le cache de Clear MKMapView de tuiles?
voix
6
3 réponses
voix 4
4
* NOTE: Cette réponse ne concerne que iOS 4.1 et inférieur. Les problèmes décrits dans cette réponse ont été la plupart du temps fixés dans iOS 4.2 *
Je fais quelques recherches sur ce que mon application utilise la carte et a également d'autres fonctionnalités qui nécessitent une grande RAM.
Je ne l'ai pas trouvé une réponse, mais une solution de contournement. Les exigences de mémoire de façon exponentielle MKMapView ne dégénèrent que vous effectuez un zoom plus pour une zone, déplacant dans ce zoomé dans la région.
Il y a deux niveaux de cache de tuiles MKMapView. L'un se manifeste comme Malloc ~ 196kb d'instruments, l'autre est NSData (magasin) de différentes tailles.
Le Malloc semble être les tuiles actives en cours d'utilisation, et il y a un plafond dur sur combien peuvent être attribués. Dans mon application ce nombre est de 16, pas sûr que sa fonction de la taille UIView ou non. Ces allocations semblent être géré avec rigueur, et il répond aux avertissements de mémoire.
Quoi qu'il en soit, à un certain niveau de zoom, par exemple, le niveau du continent (assez pour adapter la plupart d'Amérique du Nord dans un écran iPad), compte tenu de la taille des tuiles, si jamais a vraiment pour arriver à ce deuxième niveau de mise en cache (NSData (Store) ) afin de compléter la carte. Tout est clair et propre. Si je charge une tonne d'images externes en mémoire active, les tuiles se taillent. Impressionnant!
Le problème vient quand il frappe ce second niveau de la mise en cache. Cela se produit lorsque vous effectuez un zoom, et tout à coup au lieu de 16 carreaux pour montrer l'ensemble PLANAT, il a besoin de 16 tuiles juste pour montrer Los Angelas, et que vous effectuez un panoramique autour de la place de dumping que ces vieilles tuiles il les met dans le NSData (magasin ) les allocations où ils semblent ne jamais se libérer.
Ce NSData (magasin) est le NSURLConnectionCache qui existe par défaut uniquement en mémoire. Vous ne pouvez pas accéder à ce cache pour limiter, parce que ce n'est pas le cache partagé par défaut (déjà essayé).
C'est donc là que je suis bloqué.
La réponse peu satisfaisante est que si vous désactivez la carte zoom et le fixer à un niveau de zoom assez large, vous pouvez éviter ce problème complètement, mais de toute évidence certaines applications ont besoin de ce ... et qui est aussi loin que je suis arrivé.
J'ai déposé un ticket de support avec Apple pour voir si elles peuvent révéler un moyen de limiter ce cache ridicule pour la carte (qui, par la façon dont je pouvais tourner la manivelle avec désinvolture jusqu'à plus de 50 Mo de mémoire RAM allouée en mémoire active).
J'espère que cela t'aides.
modifier
La prochaine version iOS semble avoir résolu cette question sans limite de cache. MKMapView maintenant émonde agressivement ses données de tuiles mises en cache. RÉJOUIR!
voix 2
2
Est-ce que vous définissez l'identifiant de la réutilisation sur vos vues d'annotation? (Cela signifie que le système peut détacher ces vues et seulement garder un petit nombre de vues dans la mémoire à la fois. Il augmente également le défilement des performances, car le défilement réutilisera les vues individuelles.)
Utilisez cette méthode pour obtenir une vue d'annotation pour être réutilisés:
- (MKAnnotationView *)dequeueReusableAnnotationViewWithIdentifier:(NSString *)identifier
voix 1
1
Si vous créez une application avec juste la MapKit et une taille de vue de 768x1024 (taille de l'iPad), l'application peut facilement consommer plus de 30 Mo de « Octets Live » comme indiqué par les instruments programme Les affectations. Cela a été remarqué en cours d'exécution sur l'iPad v3.2.2 iOS (la dernière version jusqu'à 4,2 semaines supposée libération). D'après mes recherches, il semble que cette quantité de mémoire est beaucoup pour une seule application, où la plupart des développeurs déclarent recevoir un niveau 1 mémoire d'avertissement autour de 15-25 Mo et s'écrase peu après ce niveau.