高德客户端及引擎技术架构演进与思考
主要分享三个方面的内容：
- 融合
- 架构治理
- 动态化
一、三管齐下 深度融合
高德最初有两个端，车机版的高德导航，手机版的高德地图，两个团队，一个是2B，一个是2C，分别是汽车业务和手机业务。当时在引擎/技术上，分为离线引擎和在线引擎，但两个团队之间交流比较少，各自有自己的研发、产品和测试，而作为一款端上的APP，两块业务都需要有地图渲染、路线规划、导航以及定位等通用能力。从公司层面看，存在较大的重复建设，整体研发效率较低。
于是我们做了一件事：利用技术手段，打通端上引擎，打造一套能同时支撑多端的APP能力。具体到执行层面，先从A团队拉一部分人到B团队一起建设，建设完之后再从B团队拉到A团队。在同时支撑好主线业务发展的情况下，通过一年左右时间，完成了引擎上的融合，做到同时支撑手机、车机以及开放平台。这样就从引擎的维度，实现了渲染、定位、规划和引导的统一。具体来说，我们的各大引擎有好多套代码，好几个开发团队，每个团队有各自的开发方式和开发环境（Linux，Windows，Mac OS，乐动体育LD90.VIP）。各种开发环境，工程配置文件大量重复，修改非常繁琐。
为此，我们通过两种方法：
1.建立了一套构建系统Abtor，通过一个配置系统实现统一构建，能够同时支持多个子引擎，在构建集成效率上得到了很大的提升；
2.对基础库进行了整体重构，形成了一套涵盖了文件I/O、KV存储、多线程框架&异步框架、归档、基础容器等一系列标准能力的基础库，同时也做了引擎核心架构的统一。二、架构治理
通过引擎的融合同时支持多端，在研发效率上实现比较大的收益。而通过技术的抓手来实现团队的融合，对公司发展而言，这其实是更大的收益，团队融合的意义在于人才拉通和复用，组织效率得到了较大提升。
随着高德业务的快速发展，业务上持续扩品类，需求量激增，高德地图从最初的驾车导航，到后来的步行、骑行、摩托车导航等等，App所承载的业务发展非常快，而原有的架构治理模式的问题也逐渐暴露出来。
首先就是App的代码规模变得特别大。当时一个仓库达到了10G以上，由此导致的一个典型的问题就是编译慢，编译出一次安装包需要一个小时。伴随代码规模的另一个问题是团队规模快速增长。代码增长和大团队并行开发，最终导致合版慢，每次迭代，客户端合版需要2天。
代码膨胀导致的架构腐化问题特别突出，所以测试质量以及线上的质量有段时间也比较差。此外，从产品提出需求到上线，平均需要45天，版本迭代周期很长。
为解决以上架构问题，我们采取了三个手段：升级Native基础组件，搭建Native容器和页面框架，Bundle化分拆（微应用）。
下面重点介绍下页面框架和微应用。
页面框架主要借鉴和融合了Android和iOS的生命期管理机制。从高德地图App架构看，下层模块是一套标准地图，所有上层业务都要基于地图模块开发。为确保上层业务低耦合、一致性，我们设计了一个页面框架。JS去执行代码之后，前端框架会产生虚拟的DOM树，最后提交到C++引擎，形成C++的DOM树。C++引擎去完成布局、样式计算，Diff计算，将每个节点的属性和坐标交给Android以及iOS，由Native来完成最终UI的渲染。
总体来说，动态化的特点：首先是它与主流前端框架融合，充分融合了大前端的生态；第二，性能、扩展性较好。因为采用C++实现整个核心逻辑，静态和动态的语言绑定技术，能够保证地图引擎的能力能够直接透出到上层，或者从上层能够直接call底层的C++能力；第三，多端归一和动态化，充分利用Native优势，接近原生Native体验。
动态化技术改造完成之后，双端不一致的问题降低了90%，开发、测试成本降低30%，发版周期从T+30到T+0。
最后，总结下高德客户端及引擎技术架构演进的几个重要阶段：第一个阶段，通过在线&离线引擎的融合拉通，让高德最核心的导航能力提到提升；第二阶段，在客户端发展成为“巨型”APP，代码量发展到超大规模的时候，通过架构治理，满足业务快速增长的诉求，解决大规模业务体量下的架构合理性问题，消除架构瓶颈；第三个阶段通过动态化的技术，实现多端归一，以及动态发版能力，为业务发展提供更大的助力。
