我正在开发一款使用MKMapView作为游戏区的iPhone游戏。仅仅几分钟的播放后，该应用程序不可避免地开始变得缓慢，并最终因内存不足而崩溃。挖掘罪魁祸首似乎是地图视图不断需要更多的记忆。游戏需要对地图进行大量的缩放和平移，因此我只能假设地图的平铺缓存一直在增长，直到内存耗尽为止。有没有办法强制地图视图刷新它的磁贴缓存或包含它的内存消耗？
答案 0 :(得分：4)
*注意：此答案仅与iOS 4.1及更低版本相关。此答案中描述的问题大多在iOS 4.2 *
中修复我一直在做一些挖掘，因为我的应用程序同时使用地图，还有其他需要高RAM的功能。
我没有找到答案，但有一个解决方法。当您缩放到一个区域时，MKMapView的内存需求会呈指数级增长，并在该放大区域内平移。
MKMapView平铺缓存有两个级别。一个表现为仪器中的Malloc~196kb，另一个是不同大小的NSData（商店）。
Malloc似乎是活跃的使用中的磁贴，并且可以分配多少硬盘。在我的应用程序中，该数字为16，不确定它是否基于UIView大小。这些分配似乎是严格管理的，它会响应内存警告。
无论如何，在某个缩放级别，比如大陆级别（足以适应iPad屏幕中的大部分北美地区），考虑到磁贴的大小，如果从来没有真正必须达到第二级缓存（NSData） （商店））以完成地图。一切都清爽干净。如果我将大量外部图像加载到活动内存中，则瓷砖会自行修剪。真棒！
问题来自第二级缓存。当您放大时会发生这种情况，突然而不是16个瓷砖显示整个平面，它需要16个瓷砖才能展示Los Angelas，当您平移而不是仅仅倾倒那些旧瓷砖时，它会将它们放入NSData（商店） ）他们似乎永远不会被释放的分配。
此NSData（存储）是NSURLConnectionCache，默认情况下仅存在于内存中。您无法访问此缓存来限制它，因为它不是默认的共享缓存（已经尝试过）。
所以这就是我被卡住的地方。
令人不满意的答案是，如果你禁用地图缩放并以相当宽的缩放级别修复它，你可以完全避免这个问题，但显然有些应用程序需要这个...而且这就是我所拥有的。
我向Apple提交了一张支持票，看看他们是否可以透露任何方式来限制地图的这个荒谬的缓存（顺便说一下，我能够随意地调整到活动内存中分配的50+ megs）。
希望这有帮助。
修改的
下一个iOS版本似乎已经解决了这个无限的缓存问题。 MKMapView现在积极地修剪其缓存的磁贴数据。飘柔！
答案 1 :(得分：2)
您是否在注释视图上设置了重用标识符？ （这意味着系统可以分离这些视图，并且只在内存中保留少量视图。它还可以提高滚动性能，因为滚动将重用分离的视图。）
使用此方法获取要重复使用的注释视图：
- (MKAnnotationView *)dequeueReusableAnnotationViewWithIdentifier:(NSString *)identifier
答案 2 :(得分：1)
如果你创建一个只有mapkit并且视图大小为768x1024（ipad大小）的应用程序，应用程序可以轻松消耗超过30多MB的“Live Bytes”，如Instruments Allocations计划所报告的。这被注意到在iPad iOS v3.2.2上运行（最新版本直到下周才推出4.2版）。根据我的研究，对于单个应用程序而言，这个内存量似乎很多，大多数开发人员都会报告在15-25 MB左右接收1级内存警告，并在该级别之后很快崩溃。