Estoy trabajando en un juego de iPhone que utiliza un MKMapView como el campo de juego. Después de sólo un par de minutos de juego se inicia la aplicación, inevitablemente, para obtener lento y finalmente se bloquea por falta de memoria. Después de cavar en torno al culpable parece ser que la vista del mapa exige constantemente más memoria. El juego requiere una gran cantidad de zoom y paneo del mapa por lo que sólo puede asumir que el caché del mapa de baldosas sigue creciendo hasta que se queda sin memoria. ¿Hay alguna manera de forzar la vista del mapa para vaciar su caché de baldosas o contenerla es el consumo de memoria?
caché de clara MKMapView de baldosas?
votos
6
3 respuestas
votos 4
4
* NOTA: Esta respuesta sólo es relevante para iOS 4.1 y superior. Los problemas descritos en esta respuesta se fijaron en su mayoría en iOS 4.2 *
He estado haciendo algo de investigación en esto como mi aplicación utiliza tanto el mapa y también tiene otras características que demandan una alta memoria RAM.
No he encontrado una respuesta, pero una solución. demandas de memoria de MKMapView aumentan exponencialmente a medida que uno se acerca más cerca a un área, y moverse dentro de esa zona ampliada.
Hay dos niveles de caché MKMapView azulejo. Uno se manifiesta como una Malloc ~ 196KB de instrumentos, el otro es NSData (tienda) de diferentes tamaños.
El Malloc parece ser activos los azulejos en uso, y hay un límite estricto de la cantidad puede ser asignado. En mi aplicación de ese número es 16, no estoy seguro si es en base al tamaño UIView o no. Estas asignaciones parecen ser administrado rigurosamente, y que responde a las advertencias de memoria.
De todos modos, en un cierto nivel de zoom, por ejemplo, el nivel de continente (lo suficiente para adaptarse a la mayor parte de América del Norte en una pantalla del iPad), dado el tamaño de las baldosas, si en realidad nunca tiene que llegar a ese segundo nivel de almacenamiento en caché (NSData (tienda) ) con el fin de completar el mapa. Todo es fresco y limpio. Si se me carga de una tonelada de imágenes externas en la memoria activa, los azulejos podan a sí mismos. ¡Increíble!
El problema viene cuando llega a ese segundo nivel de almacenamiento en caché. Esto sucede cuando se acerca la imagen, y de repente en lugar de 16 fichas para mostrar toda la PLANAT, que necesita 16 fichas sólo para mostrar Los Angelas, y como desplazarse por lugar de sólo vertido esos azulejos antiguos que los pone en el NSData (tienda asignaciones) donde parecen nunca son liberados.
Este NSData (tienda) es la NSURLConnectionCache que existe por defecto sólo en la memoria. No se puede tener acceso a esta memoria caché para limitarlo, porque no es la memoria caché compartida por defecto (bastante bueno en ello).
Así que aquí es donde se queda bloqueado.
La respuesta insatisfactoria es que si se desactiva mapa zoom y fijarlo en un nivel de zoom razonablemente amplio, puede evitar este problema por completo, pero es evidente que algunas aplicaciones necesitan esto ... y eso es por lo que yo tengo.
Yo presenté un ticket de soporte con Apple para ver si se puede divulgar ninguna manera de limitar este caché ridículo para el mapa (que por cierto yo era capaz de hacer girar casualmente hasta más de 50 megas de RAM asignados en la memoria activa).
Espero que esto ayude.
editar
La próxima versión de iOS parece haber resuelto este problema caché ilimitada. MKMapView ahora poda agresiva sus datos en caché de baldosas. ¡ALEGRARSE!
votos 2
2
¿Está configurando el identificador de reutilización en sus vistas de anotación? (Esto significa que el sistema puede separar esos puntos de vista y sólo mantener un pequeño número de puntos de vista en la memoria a la vez. También aumenta el rendimiento del desplazamiento, ya que el desplazamiento va a volver a utilizar las vistas separadas.)
Utilizar este método para obtener una vista de anotación para ser reutilizado:
- (MKAnnotationView *)dequeueReusableAnnotationViewWithIdentifier:(NSString *)identifier
votos 1
1
Si crea una aplicación con sólo el MapKit y un tamaño de vista de 768x1024 (tamaño de ipad), la aplicación puede consumir fácilmente más de 30 MB de "en vivo" Bytes según lo informado por el programa Instrumentos asignaciones. Esto fue notado ejecuta en el IPAD V3.2.2 iOS (la última versión hasta próximas semanas supuestas 4.2 liberación). De mi investigación, parece que esta cantidad de memoria es mucho para una sola aplicación, donde la mayoría de los desarrolladores informan de recibir un registro de nivel 1 de alerta alrededor de 15-25 MB y se estrella poco después de ese nivel.