清除 MKMapView 的图块缓存？
我正在开发一款使用 MKMapView 作为游戏场的 iPhone 游戏。玩了几分钟后，应用程序不可避免地开始变得缓慢，并最终由于内存不足而崩溃。经过深入研究，罪魁祸首似乎是地图视图不断需要更多内存。游戏需要对地图进行大量缩放和平移，因此我只能假设地图的图块缓存会不断增长，直到内存耗尽。有没有什么方法可以强制地图视图刷新其图块缓存或控制其内存消耗？
I'm working on an iPhone game that uses an MKMapView as the playfield. After only a couple of minutes of play the app inevitably starts to get sluggish and eventually crashes due to low memory. After digging around the culprit seems to be that the map view constantly demands more memory. The game requires a lot of zooming and panning of the map so I can only assume that the map's cache of tiles just keeps growing until it runs out of memory. Is there any way to force the map view to flush it's cache of tiles or contain it's memory consumption?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
* 注意：此答案仅与 iOS 4.1 及更低版本相关。这个答案中描述的问题大部分在 iOS 4.2 中得到了解决 *
我一直在对此进行一些挖掘，因为我的应用程序既使用地图，又具有需要高 RAM 的其他功能。
我还没有找到答案，但找到了解决方法。当您放大某个区域并在该放大区域内平移时，MKMapView 的内存需求会呈指数级增长。
MKMapView 切片缓存有两级。一种在 Instruments 中表现为 Malloc ~196kb，另一种是不同大小的 NSData（存储）。
Malloc 似乎是正在使用的活动块，并且对可以分配的数量有硬性上限。在我的应用程序中，这个数字是 16，不确定它是否基于 UIView 大小。这些分配似乎受到严格管理，并且它响应内存警告。
无论如何，在某个缩放级别，例如大陆级别（足以在 iPad 屏幕上容纳北美大部分地区），考虑到图块的大小，如果永远不需要真正达到第二级缓存（NSData（商店）） ）以完成地图。一切都清爽干净。如果我将大量外部图像加载到活动内存中，图块就会自行修剪。惊人的！
当达到第二级缓存时，问题就出现了。当你放大时就会发生这种情况，突然不再需要 16 个图块来显示整个平面，而是需要 16 个图块来展示洛杉矶，当你平移而不是仅仅转储那些旧图块时，它会将它们放入 NSData （存储）分配，它们似乎永远不会被释放。
这个NSData（存储）是NSURLConnectionCache，默认情况下仅存在于内存中。您无法访问此缓存来限制它，因为它不是默认的共享缓存（已经尝试过）。
所以这就是我陷入困境的地方。
令人不满意的答案是，如果您禁用地图缩放并将其修复在相当广泛的缩放级别，您可以完全避免这个问题，但显然有些应用程序需要这个......这就是我所得到的。
我向 Apple 提交了一份支持票，看看他们是否可以透露任何方法来限制这种荒谬的地图缓存（顺便说一句，我能够随意地在活动内存中分配高达 50+ 兆的 RAM）。
希望这有帮助。
编辑
下一个 iOS 版本似乎已经解决了这个无限缓存问题。 MKMapView 现在会积极修剪其缓存的图块数据。麾！
* NOTE: This answer is only relevant to iOS 4.1 and lower. The problems described in this answer were mostly fixed in iOS 4.2 *
I've been doing some digging on this as my app uses both the map and also has other features that demand high RAM.
I haven't found an answer, but a workaround. MKMapView's memory demands escalate exponentially as you zoom closer in to an area, and pan around within that zoomed in area.
There are two levels of MKMapView tile cache. One manifests itself as a Malloc ~196kb in Instruments, the other is NSData (store) of varying sizes.
The Malloc appears to be the active in-use tiles, and there is a hard cap on how many can be allocated. In my app that number is 16, not sure if its based on UIView size or not. These allocations seem to be stringently managed, and it responds to memory warnings.
Anyway, at a certain zoom level, say, continent level (enough to fit most of North America in an iPad screen), given the size of the tiles, if never really has to get to that second level of caching (NSData (Store)) in order to complete the map. Everything is crisp and clean. If I load in a ton of external images into active memory, the tiles prune themselves. Awesome!
The problem comes when it hits that second level of caching. This happens when you zoom in, and suddenly instead of 16 tiles to show the entire planat, it needs 16 tiles just to show off Los Angelas, and as you pan around instead of just dumping those old tiles it puts them into the NSData (store) allocations where they seem to never get freed.
This NSData (store) is the NSURLConnectionCache which exists by default only in memory. You can't access this cache to limit it, because it's not the default shared cache (already tried it).
So this is where I get stuck.
The unsatisfying answer is that if you disable map zooming and fix it at a reasonably broad zoom level, you can avoid this problem completely, but obviously some apps need this... and that's as far as I got.
I filed a support ticket with Apple to see if they can divulge any way to limit this ridiculous cache for the map (which by the way I was able to casually crank up to 50+ megs of RAM allocated in active memory).
Hope this helps.
edit
The next iOS release appears to have solved this limitless cache issue. MKMapView now aggressively prunes its cached tile data. REJOICE!
您是否在注释视图上设置重用标识符？ （这意味着系统可以分离这些视图，并且一次只在内存中保留少量视图。它还提高了滚动性能，因为滚动将重用分离的视图。）
使用此方法获取要重用的注释视图：
Are you setting the reuse identifier on your annotation views? (This means the system can detach those views and only keep a small number of views in memory at once. It also increases scrolling performance, because scrolling will reuse the detached views.)
Use this method to get an annotation view to be reused:
如果您创建一个仅包含地图套件且视图大小为 768x1024（ipad 大小）的应用程序，则根据 Instruments Allocations 程序的报告，该应用程序可以轻松消耗超过 30+ MB 的“实时字节”。人们注意到它在 iPad iOS v3.2.2 上运行（最新版本预计下周发布 4.2）。根据我的研究，对于单个应用程序来说，这个内存量似乎很大，大多数开发人员报告收到大约 15-25 MB 的 1 级内存警告，并在该级别后不久崩溃。
If you create an app with just the mapkit and a view size of 768x1024 (ipad size), the app can easily consume over 30+ MB of "Live Bytes" as reported by Instruments Allocations program. This was noticed running on the iPad iOS v3.2.2 (the latest version until next weeks supposed 4.2 release). From my research it seems that this amount of memory is a lot for a single app, where most developers report receiving a level 1 memory warning around 15-25 MB and crashes soon after that level.