清除MKMapView的磁贴缓存？

我正在使用MKMapView作为游戏区的iPhone游戏。在玩了几分钟后，应用程序不可避免地会开始变得迟钝，并且由于内存不足而最终崩溃。在挖掘出罪魁祸首后，似乎地图视图不断要求更多的内存。游戏需要大量的地图缩放和平移，所以我只能假设地图的平铺缓存不断增长，直到内存耗尽。有什么办法强制地图视图刷新它的缓存瓷砖或包含它的内存消耗？清除MKMapView的磁贴缓存？

来源

2009-12-16 Mattia

我有这个完全相同的问题Mattia。每个人都喜欢说“ololol地图别针，泄漏！”但是，不，MKMapView实际上吞噬了大量的RAM，并且随着缩放级别的变化而变得更糟。现在就处理这个问题，希望我找到一些东西。 – 2010-10-29 17:25:30

*注意：此答案只与iOS 4.1及更低版本相关。在这个答案中描述的问题大多在iOS 4.2 *

大部分修复我一直在做一些挖掘，因为我的应用程序使用这两个地图，也有其他功能，需要高RAM。

我还没有找到答案，但一个解决方法。当你放大一个区域时，MKMapView的内存需求呈指数级增长，并在放大区域内平移。

有两个级别的MKMapView瓷砖缓存。一个在乐器中表现为Malloc〜196kb，另一个是大小不等的NSData（商店）。

Malloc似乎是活跃的使用中的瓷砖，并且有多少可以分配的硬盘。在我的应用程序中，这个数字是16，不确定它是否基于UIView大小。这些拨款似乎得到严格管理，并对记忆警告作出响应。

无论如何，在一定的缩放级别上，比如大陆级别（足以适应北美大部分地区的iPad屏幕），考虑到tile的大小，如果永远不需要达到第二级缓存（ NSData（Store））以完成地图。一切都清脆干净。如果我将大量外部图像加载到活动内存中，则会自行修剪。真棒！

问题出现在它达到第二级缓存时。当你放大时会发生这种情况，突然而不是16个瓷砖显示整个planat，它需要16个瓷砖来炫耀Los Angelas，当你平移而不是倾倒那些旧的瓷砖时，它将它们放入NSData（商店）分配，他们似乎永远不会被释放。

此NSData（存储）是NSURLConnectionCache默认情况下存在于内存中。您无法访问此缓存来限制它，因为它不是默认的共享缓存（已经尝试过）。

所以这是我卡住的地方。

令人不满意的答案是，如果您禁用地图缩放并将其修复到相当广泛的缩放级别，则可以完全避免此问题，但显然有些应用程序需要此操作......而且就我而言。

我向苹果提交了一张支持凭单，看看他们是否可以通过任何方式来限制这张荒谬的地图缓存（通过这种方式，我可以随意启动多达50多MB的RAM分配到活动内存中）。

希望这会有所帮助。

编辑

下一个版本的iOS似乎已经解决了这个无限的缓存问题。 MKMapView现在积极修剪其缓存的磁贴数据。麾！

来源

2010-11-01 16:41:49

虽然如你所说，它并没有解决这个问题，但至少它能给出一个很好的诊断。感谢您挖掘并分享结果 – Mattia 2010-11-01 20:58:57

嗨，Mattie，我添加了一个编辑... iOS的下一个版本修复了这个问题。 – 2010-11-02 15:07:26

您是否在注解视图上设置了重用标识符？（这意味着系统可以分离这些视图，并且只保留内存中的少量视图，同时也增加了滚动性能，因为滚动将重新使用分离视图。）

使用此方法可以获取注释视图可重复使用：

- (MKAnnotationView *)dequeueReusableAnnotationViewWithIdentifier:(NSString *)identifier

来源

2009-12-17 13:02:10

感谢您的回复。我确实在注解视图中使用重用标识符，所以不应该成为问题，但我会再次检查它们以确保。 – Mattia 2009-12-18 12:33:51

如果您使用mapkit创建应用程序并且视图大小为768x1024（ipad size），则该应用程序可轻松使用Instrument Allocations程序报告的超过30 MB以上的“Live Bytes”。这被发现运行在iPad的iOS v3.2.2（最新版本，直到下周推测4.2版本）。从我的研究中可以看出，对于单个应用程序而言，这种内存量很大，大多数开发人员报告接收到15-25 MB左右的1级内存警告，并在该级别之后不久崩溃。

来源

2010-11-17 18:24:14 gtsky303

清除MKMapView的磁贴缓存？

回答

相关问题