滴滴国际化目前有着一些不同于国内打车的特殊场景——国内用户拿着国产手机出国打车。国内地图、Google 地图均没法用；手机移动漫游网络太慢；同时需要对接不同合作公司的司机运力，这是国际化客户端项目面临的主要问题。本文为滴滴出行技术专家 吴更新在 MDCC 2016 移动开发者大会上的演讲，主要介绍了滴滴国际化在地图选型、地图扩展适配、网络相关优化、项目整体技术拆分、演进方面的经验。
PPT 下载地址：
https://github.com/MDCC2016/Android-Session-Slides
视频观看地址：
http://edu.csdn.net/course/detail/3094
目前大家用滴滴 App 在美国可以直接打车，不用下载新的 App，现在的滴滴 App 在美国打开就会自动显示海外打车页面。但是，国际化在技术上有一定的特殊性，滴滴国际化业务主要服务于国内用户在国外打车的场景，因此会涉及到与国内业务不太相同的地方，主要体现在地图、网络、运力来源三个方面。前两者很好理解，运力来源中的运力主要是指司机。在国内，个人可以注册滴滴司机，但是在国外我们是与合作伙伴合作，由合作方提供运力，所以在不同的国家，会与不同的合作伙伴实现接入。具体如下：
以上的三个特殊性决定着我们需要在技术上的差异，接下来将围绕地图模块、漫游网络、多业务接入项目演进详细展开。
这部分主要包括两大问题：地图选型、地图切换。
1. 地图选型
滴滴是个重度依赖地图的 App，而目前我们的友商及大部分国内地图提供商都没有海外的路网数据。我们前期针对的场景是国内用户海外打车，Google Map 依赖 Google Play Service，国内手机几乎都没有这个 Service，即便安装了 Google Play Service 部分手机也无法运行，另外即便都有了，漫游网络也不能访问 Google Map，所以最靠谱的 Google Map 一开始便被排除。
另外国内有些 App 在海外用了 Google Map，不过是通过中转下发地图切片的方式完成的，但滴滴对于地图各方面的要求都很高，我们必须找到一个合适的国外地图。
(1) 海外地图选型考察点
我们对地图强依赖，有些定制需求，如：很多 Marker 并且添加后需要修改、画圆并可以动态调整半径等等。
国外可用地图数据源主要有 OpenStreetMap、Here、Tomtom，OpenStreetMap 是个开源的地图数据源，类似维基百科的模式，所以数据很全很新，甚至超过 Google Map，但不可避免会有些脏数据，前期的话主要是针对大城市，OpenStreetMap 的数据可以满足需求。但因为涉及到异地跨时区沟通，所以希望技术支持力度够大。
性能方面则包括地图启动时间、渲染速度、前端响应速度、后端响应速度。
在开始国际化前，当时滴滴的安装包就已经很大了，基本是国内主流 App 之首(当然现在滴滴 App 已经挺小了)，所以我们希望新的地图够小。
(2) 海外地图全面对比
这次我们调研了 Mapbox、Nutiteq、Here、Tomtom、Bing 共五款海外地图。其中：
所以我们重点集成和测试的是 Mapbox 和 Nutiteq 这两家地图供应商。
Mapbox 和 Nutiteq 的功能和性能都满足我们需求，地图数据源也都是以OSM(OpenStreetMap) 为主。Mapbox 的 API 设计和国内地图类似，都是向 Google Map 靠拢，所以上手简单，并且整个 SDK 都是开源的，地图的样式也更美观些，而 Nutiteq 的地图底层设计比较独特，API 用法很不寻常，这也给我们接入带来了很大的麻烦。
Mapbox 有众多的 Web 用户，包括访问量都不低的 Foursquare、Pinterest 等，但Android 端用户并不多；Nutiteq 的 Android 用户多些，但整体量也不是很大，不过我们并没有更好的选择，而且前期我们的量也不会很大，所以他们都在可接受范围内。
综合下来看的话，我们是更倾向于 Mapbox，不过 Mapbox 只能通过 GitHub Issues 和邮件反馈问题，反应很慢；Nutiteq 可以 Skype 沟通，效率很高。为了保险起见，Mapbox 和 Nutiteq 都做了全面接入和测试，最终证明这样是有用的。
跟多数 App 一样，为了使得包更小，我们的主工程配置了 abiFilter “armeabi”，仅打armabi 的 so，而 Mapbox 的 armeabi so 无法跑在 armv7 机器上，前期集成测试我们通过修改 Gradle 脚本在编译时 copy so 的方式让测试通过，而 Mapbox 一直不愿意改，国内市场又不支持 Google 的 Apk Splits 机制，所以最终放弃选择 Nutiteq。
后话：Mapbox 最新版已经解决了这个问题，而且国内有相关的市场人员，沟通起来也顺畅多了。
2. 地图切换
用不了 Google Map 带来一个要求，我们选择的地图必须支持多国家，并且在设计时要支持以后不同地图任意切换。是的，即地图和 App 弱依赖。针对这个问题我们设计了地图隔离层。总体设计如下：
上图第二层 MapSDK 是地图的标准 API 层，App 只与此层打交道，标准层的 API 设计以 Google Map API 为标准。
第三层 Adapter 层是具体地图到标准 API 的适配实现层。每个地图都有个 Adapter，负责将地图 API 转换成标准 API。
将原来的 App 与三方地图直接依赖改为 App 依赖表示标准 API 的 MapSDK 层，由 MapSDK 通过具体的 Adapter 调用三方 SDK，这样地图切换只需要替换依赖的 Adapter 即可，其他地方无需改动。
新的设计后编译依赖关系如下：
App 依赖 Map Adapter，Map Adapter 依赖我们的 MapSDK 和三方的 Map SDK。当我们需要更换三方地图 SDK 时，仅需更换对应的 Map Adapter 即可。对于 Android，build.gradle 中更换依赖即可。
3. 新的地图模块设计的好处
4. 地图切换实现的注意事项
