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