阅读 1114

多地图源业务向地图控件开发思路

很多应用的都会使用到地图控件,我们目前使用到地图的场景是规划无人机的飞行路线。最常见的是规划一块要飞行的区域,然后生成巡航的路线,最后用拍到的照片进行建模。有了模型后就可以获得场地的一些数字化信息。

我们有些客户要建模的区域在郊区,因此地图的信息准确对于我们规划飞行区域的帮助很大。我们调研后发现高德和百度的图源质量各有长短,因此我们决定同时接入多个地图源。客户可以根据现场的具体情况选择地图源。

我们的地图控件在规划路线时有很多的自定义 UI 需要展示,下面是我们的规划正射飞行的一张设计图:

如果我们使用地图 SDK 提供的绘制方法,同样的自定义 UI 在不同的地图源上就要重复的实现一遍。如果我们支持三个地图源,那么就要针对三个地图源提供的方法实现三套 UI。这显然不是一个可以接受的方案。因此我们决定将自定义 UI 绘制抽离出来,这样最复杂的自定义 UI 绘制只要维护一份代码,地图源当做组件可以替换。

最后在手机上看起来就像下图这样,地图源在最底层,自定义 UI 在地图上层。这样更换地图源只是最底层的视图发生了变化:

数据流

下面展示自定义 UI 和地图源映射的过程:

如果要添加一个新元素,那么调用地图的接口获取这个标注的地理坐标在地图上的视图坐标,接着在自定义视图上添加标注。显然如果地图的展示区域变了,标注的坐标也需要一起改变。因此需要监听地图的区域变动事件,一旦改变,需要重新计算标注的平面坐标,更新标注位置。 换成伪代码是这样的:

除了自定义的 UI 的展示外,有时自定义的 UI 还要支持交互。在我眼前的业务场景里,需要交互的元素交互时都是处在视图的最顶层。如果可交互元素和展示元素放在一个视图里,就需要有状态区分哪些元素会响应交互事件。因为最底层的地图也要接收交互事件(用户可能会调整地图)。因此视图的 hittest 处理起来就会有些杂乱,因此我将可交互的元素都统一放在一个图层里。这个图层里所有的元素都响应用户交互事件。其他的交互事件最后都会传给底部的地图。

整体的视图结构大概就是这样:

缺陷

这个方案的优势是将自定义 UI 的实现与具体的地图 SDK 隔离,当地图源切换时,自定义 UI 可以直接复用。但是这个方案也有一个固有缺陷:当地图持续响应用户交互,自定义的 UI 绘制会略有卡顿。

如果将 UI 通过地图 SDK 添加到地图上,自定义 UI 的绘制与地图的渲染发生在同一帧里。因此任意一帧里,自定义 UI 和地图的位置总是对应的,从用户的角度看就是图形的变换很顺滑。但是我们的选择的方案,自定义的 UI 变换前有两个步骤:收到地图区域变化通知,重新计算图形在地图上的平面坐标。假设手机没有性能问题,那么地图原生图层的绘制频率是 60Hz。当用户进行连续缩放时,地图的图层每秒绘制 60 次。用户感觉很顺滑。地图区域变化的外界通知的频率由于性能考虑会低于 60Hz,因此即便重新计算图形坐标、绘制可以在 1/60 秒完成,自定义 UI 的渲染频率还是会低于 60Hz。给用户的体验就是连续移动时,自定义 UI 没有那么跟手。

至于自定义 UI 的绘制延迟是否可以接受这就看各自的场景了。但是从我的测试结果看,虽然性能会差一些,但是大部分场景不会影响到用户的使用。

关注下面的标签,发现更多相似文章
评论