主要分享三个方面的内容：
- 融合
- 架构治理
- 动态化
一、三管齐下 深度融合
高德最初有两个端，车机版的高德导航，手机版的高德地图，两个团队，一个是 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，代码量发展到超大规模的时候，通过架构治理，满足业务快速增长的诉求，解决大规模业务体量下的架构合理性问题，消除架构瓶颈；第三个阶段通过动态化的技术，实现多端归一，以及动态发版能力，为业务发展提供更大的助力。