最全滴滴国际化项目 Android 端演进，掌握这套精编Android高级面试题解析

文末

今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。

最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

【算法合集】

【延伸Android必备知识点】

【Android部分高级架构视频学习资源】

**Android精讲视频领取学习后更加是如虎添翼！**进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

这次我们调研了 Mapbox、Nutiteq、Here、Tomtom、Bing 共五款海外地图。其中
Bing 没有 Android 版；
Tomtom 有很古老的 Android 版，但功能过于简单，文档又几乎没有；
Here SDK 高达 40M，与他们沟通后，精简也只能到 25M，这个大小对我们是绝对接受不了的；
所以我们重点集成和测试的是 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 机制，所以最终放弃 Mapbox 而选择 Nutiteq。
后话：经过过滴滴这次合作事件后，Mapbox 开始重视起国内市场，在国内成立了研发中心，沟通方便了很多，并且最新已经解决了上面 arm so 的问题。

1.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 中更换依赖即可。

1.3 新的地图模块设计的好处

(1) 解耦，切换成本低
这个上面已经介绍，再也不会因为换了地图牵一发而动全身。
(2) 学习成本低
业务开发人员只需要熟悉标准 MapSDK API 即可，不用了解其他地图的具体使用，时间成本降低。
(3) 通用
适用于所有 App，以后新增 App，可直接使用之前成型的 Adapter。

1.4 地图切换实现的注意事项

(1) 所有 API 适配
理论上 MapSDK 应为地图所有 API 最大集，实际可以根据情况先去做所需功能的定义和适配。

(2) 标尺
需要统一标尺，如缩放尺度、相同坐标系等。

(3) 未支持 API 处理
因为标准层的 MapSDK 是地图功能最大集，所以不可避免某些三方地图不支持 MapSDK 定义的功能。比如根据一组点缩放这个功能，其对应的 Adapter 在实现这个功能时如果是 Debug 模式则抛异常，Release 模式则空实现。

还有如 MapSDK 的 API 规范前面已经介绍过以 Google Map API 为标准。另 Adapter 有具体的开发规范要求。

2. 漫游网络

前面介绍过我们初期针对的是国内用户海外打车场景，这时用户是用国内手机和运营商海外漫游接入网络，所以需要针对网络访问进行优化。
一般漫游网络流程如下图：

用户由海外运营商接入国内运营商，再通过公网(有墙)访问 Web。我们的服务器部署在 AWS 上，用户海外漫游打车网络流程如下图：

由于公网访问 AWS 非常慢，我们添加了海外专线，优化后用户海外漫游打车网络流程如下图：

用户先访问到国内的中转服务器，中转服务器再通过海外专线访问 AWS。

这个过程中客户端要做的工作包括： (1) 拉取中转服务器域名列表
(2) 使用中转服务器域名列表中域名访问，出错则用原始域名降级重试
(3) 定时及推送更新域名列表
这里域名顺序由服务端自己负载均衡，返回的中转服务器域名列表是中转服务器域名还是直接海外域名也由服务器决定。

3. Android 项目演进

3.1 原有模式

之前国际化业务的工程是很简单的方式，所有业务、组件、工具放在一起，根据具体包名划分：

这个在早期问题不大，并且开发起来快速方便，但随着更多业务接入，如我们前面说过的新的国家运力接入，问题就日益明显，包括：
(1) 组件之间耦合
虽然已经划分包名，但依然可以互相调用，组件间依赖关系不清，甚至有循环依赖。
(2) 添加新业务不便
(3) 开发问题
规模越来越大致提交冲突可能性变大。

3.2 SDK 工程提取

将原工程整体拆分为业务工程和 SDK 工程，单业务工程直接依赖 SDK，可独立开发、独立运行、独立打包。如下：

这样在接入新的业务后，总体项目结构如下图：

每个业务作为单独工程，共用组件、工具、业务统一到 SDK 层中。
集成工程负责集成 Lyft、Ola、GrabTaxi 项目，所有业务项目提供 AAR，由集成工程整体打包对外发布。

3.3 SDK 工程组件化拆分

为了解决组件之间耦合，防止后续问题加剧，同时方便协同开发和更好的复用，将 SDK 工程组件化拆分如下：

SDK 整体拆分为 Business Library 和 Util Library 两大部分，主要依据是是否可以独立于我们业务，他们间不允许反向依赖。每个部分包含若干组件，每个组件都以 Module 形式存在。

Business Library 为通用业务层，包含通用业务组件，如平滑移动、上车点、定位、地理信息、打点、网络封装。 其中 CommonBusiness 存放暂时通用、但尚不足以作为一个单独组件的公共业务，以后可能独立出来，注意包名规范方便未来独立。

Util Library 为工具库，大致分为 View 和 Util，DidiSDK 为滴滴 App 整体通用组件包，包含通用的图片缓存、网络请求、基础登陆组件等等。

3.4 SDK 组件化拆分后依赖关系图

通过上图我们可以发现即便只是 Business Library 层，组件也根据依赖关系划分为明显的上下层。

3.5 SDK 组件化划分事项

(1) 单一及开闭原则
每个模块只代表一个功能模块或一个公共业务，对于个性化或定制功能以接口形式对外开放。
PS：目前 CommonBusiness 模块暂时作为国际化 SDK 整体集成打包的模块，即国际化 SDK 项目中的 sdk Module，后续当其中某个公共业务足够成为一个模块时可继续拆分出来。

学习分享

①「Android面试真题解析大全」PDF完整高清版+②「Android面试知识体系」学习思维导图压缩包

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

份系统化学习资料的朋友，可以戳这里获取](https://bbs.csdn.net/topics/618156601)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！