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

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

2019杭州云栖大会上,高德地图技术团队向与会者分享了包括视觉与机器智能、路线规划、场景化/精细化定位、时空数据应用、亿级流量架构演进等多个出行技术领域的热门话题。现场火爆,听众反响强烈。我们把其中的优秀演讲内容整理成文并陆续发布出来,本文为其中一篇。


阿里巴巴高级无线开发专家宋照春在高德技术专场做了题为《高德客户端及引擎技术架构演进与思考》的演讲,主要分享了高德地图客户端技术架构沿着「上漂下沉」、「模块化、Bundle化」的思路演进所做的一系列架构升级中的经验和思考。


以下为宋照春演讲内容的简版实录:


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

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


一、三管齐下 深度融合


高德最初有两个端,车机版的高德导航,手机版的高德地图,两个团队,一个是2B,一个是2C,分别是汽车业务和手机业务。当时在引擎/技术上,分为离线引擎和在线引擎,但两个团队之间交流比较少,各自有自己的研发、产品和测试,而作为一款端上的APP,两块业务都需要有地图渲染、路线规划、导航以及定位等通用能力。从公司层面看,存在较大的重复建设,整体研发效率较低。


于是我们做了一件事:利用技术手段,打通端上引擎,打造一套能同时支撑多端的APP能力。具体到执行层面,先从A团队拉一部分人到B团队一起建设,建设完之后再从B团队拉到A团队。在同时支撑好主线业务发展的情况下,通过一年左右时间,完成了引擎上的融合,做到同时支撑手机、车机以及开放平台。


这样就从引擎的维度,实现了渲染、定位、规划和引导的统一。具体来说,我们的各大引擎有好多套代码,好几个开发团队,每个团队有各自的开发方式和开发环境(Linux,Windows,Mac OS)。各种开发环境,工程配置文件大量重复,修改非常繁琐。

为此,我们通过两种方法:


1.建立了一套构建系统Abtor,通过一个配置系统实现统一构建,能够同时支持多个子引擎,在构建集成效率上得到了很大的提升;

2.对基础库进行了整体重构,形成了一套涵盖了文件I/O、KV存储、多线程框架&异步框架、归档、基础容器等一系列标准能力的基础库,同时也做了引擎核心架构的统一。


二、架构治理


通过引擎的融合同时支持多端,在研发效率上实现比较大的收益。而通过技术的抓手来实现团队的融合,对公司发展而言,这其实是更大的收益,团队融合的意义在于人才拉通和复用,组织效率得到了较大提升。


随着高德业务的快速发展,业务上持续扩品类,需求量激增,高德地图从最初的驾车导航,到后来的步行、骑行、摩托车导航等等,App所承载的业务发展非常快,而原有的架构治理模式的问题也逐渐暴露出来。


首先就是App的代码规模变得特别大。当时一个仓库达到了10G以上,由此导致的一个典型的问题就是编译慢,编译出一次安装包需要一个小时。伴随代码规模的另一个问题是团队规模快速增长。代码增长和大团队并行开发,最终导致合版慢,每次迭代,客户端合版需要2天。

代码膨胀导致的架构腐化问题特别突出,所以测试质量以及线上的质量有段时间也比较差。此外,从产品提出需求到上线,平均需要45天,版本迭代周期很长。


为解决以上架构问题,我们采取了三个手段:升级Native基础组件,搭建Native容器和页面框架,Bundle化分拆(微应用)。


下面重点介绍下页面框架和微应用。


页面框架主要借鉴和融合了Android和iOS的生命期管理机制。从高德地图App架构看,下层模块是一套标准地图,所有上层业务都要基于地图模块开发。为确保上层业务低耦合、一致性,我们设计了一个页面框架。

如上图,左边的Activity是Android的系统页面控制器,右边的UIViewController是iOS的系统页面控制器,通过虚线连接比较,我们发现两端的页面状态设计基本相同。


所以,我们在设计自己的页面框架时沿用了这些系统页面状态,同时从命名上也保持一致,这样可以让Android和iOS原生开发的同学更容易理解和上手。

我们吸取了双端各自的优点。比如,Android端页面有四种启动模式,但是iOS 端并没有这些,我们就把Android的四种启动模式运用到了iOS端;iOS端有Present特性,但是Android端没有,那么也把这种特性融合到Android端的页面框架中;最后,还有一些小设计,比如Android的onResult设计,也可以借鉴融合到iOS端。


此外,我们还做了微应用,所谓微应用,首先是模块化,就是把大模块仓库大模块拆成一个个小的Bundle,除了实现模块化,还主要实现以下几个目标:

粒度:以业务为单位,以业务线为分组

编译:二进制级别的产物,可独立编译、出包时链接

依赖:松耦合,以“服务”为导向,不关心模块归属

而Native容器层面,要实现四个核心目标:路由管理、服务管理、UI生命期管理、微应用管理。

通过一年时间的Bundle化改造,高德地图单端App完成了300多个页面的建设,拆分了100多个Bundle。


从收益来看,总编译时间从原来的60分钟降低到了8分钟,合版周期从原来的3天降到1天,需求上线周期降到了1个月以内,线上质量和测试质量都得到了极大的提升,崩溃率从万分之八降低到十万分之八。


三、动态化


随着高德地图业务发展沿着扩品类、在垂直品类做精做细,景区、酒店、银行商铺、充电桩等个性化定制需求凸显,对前端展现提出了更高的要求,对“快速应变”要求也更高了。


实际上,在2015年,高德就开始做动态化。最早的时候业内就有React Native,团队做了技术调研,发现不能完全满足业务上的需要,尤其是性能方面。最后我们决定自研一套动态化技术。

具体来说,就是通过一个核心C++引擎,把两端业务(Android、iOS)用一套JavaScript代码解决,实现双端归一,Android实现业务动态化发布。

架构层面,最下面是高德App核心的地图引擎,我们在上面搭建了一套动态化应用引擎,通过C++来实现。应用引擎的作用是为了承上启下,上面承载动态化业务,下层完成地图引擎的直接打通。众所周知,GUI的核心是DOM树,所以应用引擎不但要实现和JavaScript引擎的整合,还要负责DOM树的核心逻辑计算。


其次,动态化的技术和前端Web技术一致:样式、布局。应用引擎负责完成样式的布局计算、DOM树Diff、事件生成。而GUI的绘制,通过Diff事件,交由原生的Android以及iOS去完成。这样,所有的GUI都是原生的组件。

在之上,我们搭建了一套前端框架,前端框架采用当前前端响应式框架做,前端框架之上又搭建了一套前端的UI卡片库和UI组件库,让上层业务能够更高效的开发。


而对于一些通过动态化的技术无法实现,或者性能上存在卡点的功能,我们就通过Native扩展能力来支撑,这样,完整的动态化的业务能够直接运行在Android以及iOS上。


JS去执行代码之后,前端框架会产生虚拟的DOM树,最后提交到C++引擎,形成C++的DOM树。C++引擎去完成布局、样式计算,Diff计算,将每个节点的属性和坐标交给Android以及iOS,由Native来完成最终UI的渲染。

总体来说,动态化的特点:首先是它与主流前端框架融合,充分融合了大前端的生态;第二,性能、扩展性较好。因为采用C++实现整个核心逻辑,静态和动态的语言绑定技术,能够保证地图引擎的能力能够直接透出到上层,或者从上层能够直接call底层的C++能力;第三,多端归一和动态化,充分利用Native优势,接近原生Native体验。


动态化技术改造完成之后,双端不一致的问题降低了90%,开发、测试成本降低30%,发版周期从T+30到T+0。


最后,总结下高德客户端及引擎技术架构演进的几个重要阶段:第一个阶段,通过在线&离线引擎的融合拉通,让高德最核心的导航能力提到提升;第二阶段,在客户端发展成为“巨型”APP,代码量发展到超大规模的时候,通过架构治理,满足业务快速增长的诉求,解决大规模业务体量下的架构合理性问题,消除架构瓶颈;第三个阶段通过动态化的技术,实现多端归一,以及动态发版能力,为业务发展提供更大的助力。


 

相关文章
|
6天前
|
机器学习/深度学习 人工智能 自然语言处理
Transformer架构:重塑现代AI的核心引擎
Transformer架构:重塑现代AI的核心引擎
248 98
|
10天前
|
存储 人工智能 关系型数据库
阿里云AnalyticDB for PostgreSQL 入选VLDB 2025:统一架构破局HTAP,Beam+Laser引擎赋能Data+AI融合新范式
在数据驱动与人工智能深度融合的时代,企业对数据仓库的需求早已超越“查得快”这一基础能力。面对传统数仓挑战,阿里云瑶池数据库AnalyticDB for PostgreSQL(简称ADB-PG)创新性地构建了统一架构下的Shared-Nothing与Shared-Storage双模融合体系,并自主研发Beam混合存储引擎与Laser向量化执行引擎,全面解决HTAP场景下性能、弹性、成本与实时性的矛盾。 近日,相关研究成果发表于在英国伦敦召开的数据库领域顶级会议 VLDB 2025,标志着中国自研云数仓技术再次登上国际舞台。
91 0
|
3月前
|
监控 搜索推荐 应用服务中间件
301重定向:网站迁移、SEO优化与架构重塑的核心引擎
301重定向是数字世界中确保网站迁移无缝过渡的关键策略。它通过HTTP状态码告知浏览器和搜索引擎资源的永久迁移,帮助维持权重传递与用户体验。本文深入解析301重定向的工作机制、SEO影响及实施策略,涵盖域名迁移、HTTPS升级、URL标准化等场景,并提供服务器配置示例(如.htaccess和Nginx规则)。同时,强调避免重定向链、循环等问题,推荐使用专业工具监控效果。掌握这些技巧,可确保网站在架构调整或迁移时保持流量稳定与搜索引擎信任,成为网站管理不可或缺的战略工具。
95 8
|
10月前
|
运维 监控 负载均衡
动态服务管理平台:驱动微服务架构的高效引擎
动态服务管理平台:驱动微服务架构的高效引擎
204 17
|
5月前
|
前端开发 API 开发工具
一年撸完百万行代码,企业微信的全新鸿蒙NEXT客户端架构演进之路
本文将要分享的是企业微信的鸿蒙Next客户端架构的演进过程,面对代码移植和API不稳定的挑战,提出了DataList框架解决方案。通过结构化、动态和认知三重熵减机制,将业务逻辑与UI解耦,实现数据驱动开发。采用MVDM分层架构(业务实体层、逻辑层、UI数据层、表示层),屏蔽系统差异,确保业务代码稳定。
231 0
|
6月前
|
调度 决策智能 知识图谱
腾讯云大模型知识引擎驱动 DeepSeek 满血版能源革命大模型:架构、优势与产业变革
腾讯云大模型知识引擎驱动的DeepSeek满血版能源革命大模型,融合了超大规模知识、极致计算效能和深度行业理解,具备智能预测、优化调度、设备健康管理和能源安全预警等七大功能模块。该模型通过分布式计算和多模态融合,提供精准的能源市场分析与决策支持,广泛应用于智慧风电场管理、油气田开发、能源市场交易等十大场景,助力能源行业的数字化转型与可持续发展。
|
9月前
|
存储 SQL 分布式计算
大数据时代的引擎:大数据架构随记
大数据架构通常分为四层:数据采集层、数据存储层、数据计算层和数据应用层。数据采集层负责从各种源采集、清洗和转换数据,常用技术包括Flume、Sqoop和Logstash+Filebeat。数据存储层管理数据的持久性和组织,常用技术有Hadoop HDFS、HBase和Elasticsearch。数据计算层处理大规模数据集,支持离线和在线计算,如Spark SQL、Flink等。数据应用层将结果可视化或提供给第三方应用,常用工具为Tableau、Zeppelin和Superset。
3847 8
|
9月前
|
机器学习/深度学习 人工智能 调度
【AI系统】推理引擎架构
本文详细介绍了推理引擎的基本概念、特点、技术挑战及架构设计。推理引擎作为 AI 系统中的关键组件,负责将训练好的模型部署到实际应用中,实现智能决策和自动化处理。文章首先概述了推理引擎的四大特点:轻量、通用、易用和高效,接着探讨了其面临的三大技术挑战:需求复杂性与程序大小的权衡、算力需求与资源碎片化的矛盾、执行效率与模型精度的双重要求。随后,文章深入分析了推理引擎的整体架构,包括优化阶段的模型转换工具、模型压缩、端侧学习等关键技术,以及运行阶段的调度层、执行层等核心组件。最后,通过具体的开发流程示例,展示了如何使用推理引擎进行模型的加载、配置、数据预处理、推理执行及结果后处理。
733 0
|
11月前
|
运维 Cloud Native 持续交付
探索云原生架构:企业数字化转型的新引擎
在当今数字化浪潮中,云原生架构以其独特的优势成为企业转型的关键。它通过容器化、微服务、DevOps和持续交付等技术,使企业能够快速响应市场变化,实现应用的高效开发、部署和运维。本文将深入探讨云原生的概念、核心技术及其在现代IT环境中的重要性。
|
11月前
|
运维 Kubernetes Cloud Native
探索云原生架构:企业数字化转型的新引擎
【10月更文挑战第9天】 在当今数字化浪潮中,云原生架构以其独特的优势成为企业实现高效运营和快速创新的关键。本文将深入探讨云原生的核心概念、关键技术以及实际应用案例,揭示其如何助力企业加速数字化转型步伐。通过对云原生技术的剖析,我们将看到这一新兴架构是如何重新定义软件开发、部署和运维模式的,进而推动企业在激烈的市场竞争中脱颖而出。