高德客户端及引擎技术架构演进与思考

主要分享三个方面的内容:

  • 融合
  • 架构治理
  • 动态化

一、三管齐下 深度融合

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

    原文作者:乐动体育
    原文地址: https://segmentfault.com/a/1190000021046816
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注