高德引擎构建及持续集成技术演进之路

01

背景

由于导航应用中的地图渲染、导航等核心功能对性能要求很高，所以高德地图客户端中大量功能采用 C++ 实现。随着业务的飞速发展，仅地图引擎库就有40多个模块，工程配置极其复杂，原有的构建及持续集成技术已无法满足日益增长的需求变化。

除了以百万计的代码行数带来的复杂度外，高德地图客户端中的 C++ 引擎库工程（以下简称引擎库）的构建和持续集成还面临以下几个挑战：

• 支持多团队协作：多团队意味着多操作系统多 IDE ，降低不同操作系统和不同 IDE 下的工程配置的难度是重点要解决的难题之一；

• 支持多业务线定制：引擎库为手机、车机、开放平台等业务线提供支持，而各个业务线的诉求不同，所以需要具备按功能构建的能力；

• 支持车机环境：在诸多业务线中，高德地图有一个非常特殊的业务线，即车机（AMAP AUTO）。车机直接面对各大车厂和众多设备商，环境多为定制化，构建工具链各式各样。如果针对每个车机环境都定制一套构建配置文件，那么其维护成本将非常高，所以如何用一套构建配置满足车机的多样化构建需求成为亟需解决的问题；

此外，由于历史原因，引擎库中源码和依赖库混杂，都存放于 Git 仓库中，这样会带来两个问题：

• 随着构建次数不断增加，Git 仓库越来越大，代码与依赖库检出越来越慢，极大影响本地开发以及打包效率；

• 缺乏统一管理，依赖关系混乱，经常出现因为依赖问题而导致的构建失败，或者虽然构建成功但运行时发生错误的情况；

上述的挑战和历史遗留问题严重阻碍了研发效能的提升。为此，我们对现有的构建及持续集成工具进行了深入的研究和分析，并结合自身的业务特性，最终发展出高德地图 C++ 本地构建工具 Abtor 和持续集成工具 Amap CI 。

02

本地构建

现有工具分析

C++ 是一门靠近底层的语言。不同的硬件、操作系统、编译器，再加上交叉编译，导致 C++ 构建的难度非常高。针对这些问题，C++ 社区涌现出许多优秀的构建工具，比如大名鼎鼎的 Make 和 CMake 。

Make，即 GNU Make ，于1988年发布，是一个用来执行 Makefile 的工具。Makefile 的基本语法包括目标、依赖和命令等。使用过程中，当某些文件变了，只有直接或者间接依赖这些文件的目标才需要重新构建，这样大大提升了编译速度。

Make 和 Makefile 的组合可以看作项目管理工具，但它们过于基础，在跨平台的使用方面有很高的门槛和较多的限制，此外大项目的构建还会遇到 Makefile 严重膨胀的问题。

CMake 产生于2000年，是一个跨平台的编译、测试以及打包工具。它将配置文件转化为 Makefile ，并运行 Make 命令将源码编译成可执行程序或库。CMake 属于 Make 系列，配置文件比 Makefile 具有可读性，支持跨平台构建，构建性能高。

但是 CMake 也有两项明显不足，一是配置文件的复杂度远高于其它现代语言，对于 CMake 语法初学者有一定的学习成本，二是与不同 IDE 的配合使用不够友好。

可以看出 Make 和 CMake 的抽象度还是比较低，从而对构建人员的要求过高。为了降低构建成本，C++ 社区又出现了一些新的 C++ 构建工具，现在使用较广泛的包括 Google 的 Bazel 和 Ninja ，以及 SCons 。这些工具的特点和不足如下：

经过上述对现有 C++ 构建工具的研究和分析，可以得出每个工具既有所长又有不足的结论。再考虑到高德地图引擎库工程面临的挑战和历史遗留问题，我们发现以上工具没有一个可以完美契合业务需求，且改造成本非常高，所以我们决定基于 CMake 自建 C++ 本地构建工具，即现在引擎库工程使用的 Abtor 。

Abtor

首先，我们需要解释一个问题，即 Abtor 是什么？

Abtor 是一个 C++ 跨平台构建工具。Abtor 采用 Python 编写构建脚本，生成 CMake 配置文件，并通过内置 CMake 组件生成构建文件，最终产出可执行程序或库。它抽象出构建描述，使得复杂的编译器和连接器对开发者透明；它提供强大的内置功能，从而有效的降低开发者编写构建脚本的难度。

其次，我们需要阐述一个问题，即Abtor的构建流程是什么？

如上图所示