android - 在 GoogleMap 中使用 GroundOverlay 或 TileOverlay 显示大覆盖图的一些问题

Question

我有一个应用程序，用户可以在其中将图像加载到 Google map 上。这是为 2.3 开发的，因此有一个 MapActivity、一个 MapView 和显示图像的自定义 Overlay 类。在覆盖类绘制方法中，我每次都重新计算一个矩阵，以便图像获得正确的大小和位置。我还有一个校准模式，用户可以通过拖动引用点来调整图像。

我将向应用程序添加一些功能，并且我想从一些更新开始，例如使用 fragment 。用 MapFragment 替换 MapActivity 会带来一些问题，因为似乎不支持可以自己实现绘制的叠加层。看来我将不得不使用 GroundOverlays 或 TileOverlay。 (如有错误请指正。)

这些似乎都不支持在添加叠加层后对其进行任何修改，因此图像的校准将不起作用。我对该部分的计划是将一个普通的 ImageView 放在 MapFragment 之上以用于校准模式。 (这将隐藏所有标记，但这在校准期间无关紧要。)为此，我需要两件事:* 接收影响校准点的所有触摸事件并转发其余的以允许正常缩放等。* 随时检测位置/旋转/缩放级别的变化，以便我可以调整图像。问题 #1:我能预料到这会有什么大问题吗？

然后我必须决定是 GroundOverlays 还是 TileOverlay 更可取。

GroundOverlay:这似乎需要最少的工作，因为它仍然会加载整个图像。我还认为它会自动处理诸如屏幕方向更改之类的事情。问题 #2:GroundOverlay 是否适用于大图像(最大 2000*2000 像素)？是否涉及图像的复制？由于图像太大，我无法在内存中保存一份以上的副本。

TileOverlay:在某种程度上，这似乎是一个更专业的解决方案，因为它只使用了实际需要的部分，我稍后可以引入对同时使用多个 map 图像源的支持。我可能必须提前生成图 block 并为每个图 block 保存一个单独的文件，将其保存在内存中并按需创建图 block 可能会占用大量内存。 (或者也许我可以创建一个单独的图 block 服务，但这看起来有点脏。)问题 #3:是否可以控制切片缓存将使用多少内存？通常的限制适用吗？我不想仅仅因为缓存占用了我允许使用的大部分内存而在应用程序的其他地方耗尽内存。问题 #4:文档说“请注意，与其他叠加层不同，如果重新创建 map ，瓦片叠加层不会自动恢复，必须手动重新添加”。我想这会在每次屏幕旋转时发生，因此这意味着必须再次读取文件，从而导致明显的加载延迟。有什么好的办法解决这个问题吗？问题5:调用getTile返回null时(因为tile保存在文件中，不想阻塞ui线程读取)，要等多久才会再次请求？ (似乎没有办法手动加载单个图 block 。)问题 6:如何确定一张图 block 图像的良好图像分辨率(关于性能和质量)？

Answer 1

很多问题。我会尝试解决一些问题。

1. 通常，请注意 Maps API v2 比 v1 宽松得多。这是一件好事。 v2 具有更多 v1 所没有的内置函数和优化，并且通过限制性 API 强制您使用其优化。

2. 例如，如果您使用 GroundOverlay 来显示图像 [假设您不需要旋转或扭曲它]，您只需指定它的纬度/经度范围，Maps v2 将拉伸(stretch)图片给你。 2000x2000 将是 2000x2000x4 字节，因此内存中有 16MBytes。但是 GroundOverlayOptions 使用 BitmapDescriptor，所以它可能永远不会将图像完全加载到内存中。我对 GroundOverlay 不是很熟悉。

   另一种选择是在您第一次加载图像时将图像剪切成图 block 并将它们保存在本地存储中，然后可以非常直接地与 TileOverlay 一起使用。您无法合理地直接从 2kx2k 图像中读取图 block ，因为它会涉及全部读取(如果压缩，我猜是这样)。如果您需要显示图像的修改版本，请记住您只需要在确保位图可变后在位图上创建一个 Canvas 。

3. 我对经常使用的 TileOverlay 更加熟悉。 tiles 缓存对我来说看起来很公平，我已经加载了大量的 256x256 tiles 并且始终保持在 13M 和 20M 堆之间。我认为它使用与谷歌地图图 block 相同的方法，在本地存储内存中缓存一些但不会太多，并且根本不在未显示的内存图 block 中缓存。您可以在填充时看到瓷砖正在重新加载。

   您可以通过列出内部存储的文件轻松查看 GMaps 切片缓存策略。在那里您会看到 GMaps 缓存图 block 。

4. 是的，当停止/启动时，GoogleMap 将为每个显示的图 block 调用 getTile(x, y, zoom)。看起来每次调用 getTile 都有自己的线程，所以加载时间不是问题。如果您的磁贴已存储在您的设备上，则加载速度非常快。如果您以巧妙的方式存储数据，那真的不是问题。

5. 我从未返回过 null。不知道在这种情况下会发生什么。也许它会触发一个被忽略的异常。请注意，您的代码在 getTile 中生成的任何运行时异常甚至某些 java.lang.error 都将被 GoogleMap 调用忽略...我已在此处报告问题，您可能希望应用补丁以简化您的开发:https://code.google.com/p/gmap...

   为了回答您的问题，我返回了“NO_TILE”对象，然后 GMap 像任何图 block 一样缓存它。您可以通过调用 TileOverlay.clearTileCache() 强制重新加载磁贴。

6. 我一直在考虑这个问题，但我只使用 256x256 的图 block ，即使在高 DPI Nexus 10 上看起来也足够好。我没有对这个问题进行更多调查，但可能是 GMaps 已经根据缩放级别选择最适合显示的图 block ，前提是 256p 是相当标准的图 block 尺寸。