多地图架构设计

一、地图介绍

1、使用地图的APP

• 百度地图：路径导航、周边搜索，生活中必备的工具。
• 小猪巴士：班车定制的APP。
• 神州租车：租车、订车的一款APP
• 酷米客实时公交：查询公交线路、指定线路公交位置。
• Waze 社交导航：Waze可以让司机报告实时的交通状况，例如：交通事故、天气甚至是警车的踪迹。Google当年以9.66亿美元的价格收购了这个应用。

因此可以说地图是我们生活中的一部分，而使用地图的主要功能包括：用户位置展示、定位服务、数据服务、出行服务、轨迹服务、导航服务等等具体参考实际地图。
当前主流地图如：

1、Google地图
2、百度地图
3、高德地图
4、搜狗地图

     地图的功能大致相当，但细节上可能有些差异；由于国能的原因Google业务是用不了的，因此在国能只能选择百度地图或高德地图或其他地图，具体选择看业务需求及个人喜好；国外用Google地图就搞定了，如果没有限制一个地图那是最好的，可现实还要面对；下面就基于这个问题提出个人解决解决方案：

2、多地图的分层结构设计

3、设计说明

• 1、地图选择：国内选择一种地图，如百度地图（后续都以百度地图说明），国外用Google（国内是无法直接访问的，开发测试时需要开VPN或其他专线等，有消息称后续Google会逐步进入国内，那是后话），多地图时需要在项目中导入两种地图；导入时如果支持pod建议使用这种方式。

• 2、地图接口层设计说明：
  1）APP具体选用哪种地图可以通过编译宏来解决，一般APP国内一个版本，国外一个版本，编译时通过宏的不同值决定选择哪种地图。

  2）封装层设计为单例还是多实例取决于具体应用，如果一定会加载地图，那么设计为单例可能会有优势，原因是：地图服务的启动，地图界面的展示，当前位置的定位等需要消耗一些流量（地图是由图片拼接的，图片的流量、位置信息的流量等）及消耗大量的CPU、内存，通过测试地图在加载时CPU会突然飙升，建议APP的首页尽量不要直接使用地图，如果使用会有1到3秒的卡顿;如果无论在什么情况都要使用地图，那使用单例可能性能、体验要好些；如果只是有些页面点到菜使用时，那使用时在创建可能更好些。

• 3、封装层提供的接口：
  1）地图试图的获取、地图属性配置、地图的基本操作。
  2）Mark标注的创建、清除。
  3）划线、画图的封装。
  4）地图按钮的封装：归位、放大、缩小、指北针等。
  5）地图操作：点击、选择点等。
  6）地图工具方法：截图、计算经纬度距离、坐标转换等。

• 4、位置服务的管理，地址的解析。

  如下图：
  

优点

• 1、屏蔽地图功使用者需要学习地图相关内容,降低门槛，如不需要了解是否允许定位的配置、如何创建地图、如何添加标注、划线、画图、POI等等，这些底层封装了；使用者只需要使用相关接口即可。
• 2、便于问题的统一修改，一个问题只要在底层修改了，使用点均不需要修改。
• 3、代码的封装，避免冗余代码：我们知道地图有很多的代理方法，每个页面使用都需要创建一套，封装后则避免了该问题。
• 4、避免了多地图导致的代码复杂，因为每个地图要写一套业务逻辑。
• 5、避免地图更换对业务层的影响。

缺点

• 1、如果同时导入两个地图会使编译后的安装包增大；编译时是将使用到的内容编译到可以执行文件中，以Google为例，编译后的安装包添加Google地图和不添加相差大约2M左右（较真的同学可以花时间在验证下，也要看具体项目使用接口的多少）；解决方法是：可以用个编译宏屏蔽，编译国内版本时指定国内的地图；编译国外版本时编译Google地图。
• 2、地图单例，会导致前一个页面添加的标注在其他页面也显示，解决方法：页面在viewWillDisappear 时清理掉添加的所有附属物。

扩展说明

• 1、无论是IOS还是Android版本在使用SDK的原生接口时，有时也可以考虑使用地图提供的服务接口（API接口），如经纬度的地址反解析，原生接口更易失败，效果也不是很理想，经验证API接口效果要好很多。
• 2、以前百度地图如2.4之前的版本是不支持标注的聚合，目前版本已经支持了。
• 3、行程数据绘制时数据很多会导致很卡，一般每隔5S一个数据，4个小时的数据还可以接受，太多有些会导致崩溃。
• 4、IOS位置服务定位的地理坐标，画到地图上时需要进行火星坐标转换，否则有几百米的偏差。

二、地图我们能做的

• 1、标注的使用
  

• 2、标注的使用
  

• 3、行程轨迹的
  

• 4、行程的回放、快进、后退（当前百度好像支持了）
  

• 5、多信息在标注的使用
  

• 6、用户位置的发送
  

• 7、地图控件的封装：归位、放大、缩小
  

• 8、简单的地图view、及一些基本属性的设置
  

三、我们现状

我们互生的代码中的Map中的代码基本比较传统的写法，需要使用地图的页面，导入地图的库、添加地图视图、添加地图的代理等；这中方式最主要的问题有一下及方面：
1、 有很多关于地图的代码分散到业务逻辑的中，冗余，重复的内容比较多。
2、出现问题不便于问题的统一修改。
3、每个人使用时需要学习地图使用相关的一些API，封装后的有部分人维护，这样更加专业。
4、如果地图切换要大量修改。
5、无法支撑多个地图的应用。
6、统一管理位置服务，在APP耗电方面有些优势。

四、优化点

1、将地图封装出一套API，屏蔽地图的差异，业务层使用API接口。
2、封装层根据需要可以封装几套地图，一般是国内一个、国外一个。
3、地理位置统一管理，其他需要位置信息，调用接口获取即可。

Good luck！