当前位置：首页 > news >正文

高德终端技术总结：高可用架构如何练成？

news 来源：原创 2025/8/2 19:13:31

前言

高德地图作为国民级应用，特别是出行场景的独特性，要确保在线导航高并发和交通安全级的超稳定性，这对技术团队提出异乎寻常的高要求，无论是终端、云端，还是“终端-云端”之间的连接，都必须实现“高可用、高性能、高效率”的技术目标。

2024年，国内外都出现过大的互联网平台的崩溃性故障，数字经济大发展的时代，这些常用的基础平台出现大故障，会迅速造成舆情和巨大的业务损失。「系统稳定性」问题一定要警钟长鸣，不可大意。

稳定性工作的性质

稳定性工作属于「流水不腐,户枢不蠹」。它和做业务的维度大不相同：稳定性工作一定要保持踏实的工匠精神、不能有丝毫的夸张或隐藏。既要做好系统的架构设计夯实地基，也要老老实实的去做大量日常繁琐的事情，还要有“功成不必在我”的心理素质。

对高德超稳定性工作的要求

防架构腐化｜历史上的死角和垃圾一定要坚决清理；
全链路实战演练｜平常多流汗，战时少流血。摒弃侥幸心理：你担心的一定会发生；
多云架构支持｜ 任何基础设施都会出现意外。架构要「可依赖、可扩展、简单」。

2024年国庆节，高德地图的用户量突破新高。这么一个超级APP，在业务快速演进、产品体验不断完善、智能技术持续加持的压力下，如何保持“启动秒开、瘦安装包、低网络流量”，同时还要考虑“多系统、多设备、多语言（国际化）”的业务拓展要求，是一道非常难解的技术课题。现在把这几年我们在终端方面的解题思路做个整理，分享经验，以期同行批评指正，大家互相取经、教学相长，共同为中国数字经济的持续发展添砖加瓦。

背景

随着多年来快速发展，高德地图已成为了国民级超级应用，终端也不可避免面临超级应用的通用效率难题，即如何高效地支撑多系统、多设备、多语言和多业务的快速发展。高德地图终端也面临着其独有的性能与稳定性难题，由于出行导航使用场景的特殊性，用户往往时间比较紧迫，对交互耗时的敏感度非常强，同时稳定性也必须保证交通安全级的高可用。

因此我们在全团队提出了“高可用、高性能、高效率”三大技术目标，发起了技术攻坚。经过全体团队的不懈努力与磨练，我们终于做到了：
「高可用」溃率达到十万分水位，并持续稳定保持低水位；
「高性能」包体积与流量双降，包体积减少近一半；启动速度实现“秒开”，达到业内领先水平；
「高效率」通过“一体化容器架构”的结构化升级，我们实现了一套架构支撑多系统、多设备、多语言和多业务，支撑国际图上线，同时在业内率先支持鸿蒙 NEXT 系统。

高德终端团队“不仅要把问题解决了，方式上更是要从技术架构和机制层面根本解题” ，这篇总结与各位技术伙伴分享与探讨过程中的探索与实践，希望能有所助益。

架构解题

过去，终端技术治理的惯性更倾向于遇题解题、单点局部运动式解题。但随着持续发展，技术债务逐渐累积，这种方式带来的成本越来越高，而且效果会反复恶化，经常出现“按下葫芦起了瓢”的情况。因此我们思考需要从这种“局部优化”到“结构性简化”的转变，用一套架构统一支撑多系统、多设备、多语言，才能系统性解决面临的问题。围绕这一方向，我们从顶层整体设计并落地了一体化容器架构：

整体设计统一容器，向下统一封装适配多环境（包括多设备、多系统、多语言、多网络、多规则），解决业务需要各自分别高成本适配各种环境的问题；向上对业务提供跨平台、可复用、一致性的一体化地图终端能力（包括Engine、UI、Service、IO、Framework），支撑多业务的快速迭代。

在技术栈设计上，除调用系统平台服务的部分使用原生语言（Java//OC//ArtTS）外，其他均使用跨平台语言，来实现最大限度的跨平台，其中对于高性能要求的能力（如地图引擎、基础库）使用C++实现，而对于高效率要求的能力（如前端页面）则使用JS实现。这样在满足性能的要求下，实现一码多端的高效跨平台开发。

篇幅所限，这里仅从启动秒开、包体积瘦身、多系统、多设备、多语言等几个方面，具体介绍我们的思考与实践。

启动秒开：按需加载框架

过去，很多能力只管功能完成，而性能问题往往被推到上线前做决策，结果常常“带伤”上线。一旦上线，这些遗留问题因为优先级低，很难再被安排优化，即上线即终点，管生不管养，这就导致问题越积越多，最后只能运动式解决，再周而复始。这就能理解为什么运动式优化，优化之后又快速反弹的原因。无论是启动性能、包体积还是存储，都存在类似的问题。

为此，针对启动性能，我们在App上制定了“秒开”的高目标，这个目标回头来看也极具挑战性，这样也倒逼我们打破过去路径依赖的思维模式，实现结构性的简化。此前整个端的架构是，所有业务模块都是在启动阶段无差别的进行初始化，比如音乐模块，即使用户不开启音乐，也会在应用启动阶段进行加载初始化。这就导致启动阶段，随着时间业务发展，越来越慢，而且每次治理后很快就会反弹。因此，终端团队通过按需加载框架的设计，一方面，实现从“全功能加载”到“即用即加载”的结构性简化，根据用户实际需求动态加载模块，减少资源浪费和性能开销。另一方面，重新定义首屏启动模块，对启动模块极致简化，同时在结构上解耦启动与具体业务，这样也避免了启动性能因后续业务迭代而恶化，做到了长治久安。

从结果看，在低端机（17年 PIXEL手机）上，都能够实现启动秒开。同时，运行一年以来，在业务快速发展下，耗时持续保持平稳。

包大小瘦身&流量降本

包大小重点不只是反映体积大小的表象，更重要的是反映架构臃肿，代码债高筑，稳定性、性能和效率风险成比例上升的问题。这就像减肥，过分胖了不止是形象问题，他是一种身体不健康表征，隐含着心脑血管并发症等整体机制问题。同样包大小优化表象目标上是降体积，根本目标是整体的技术架构健康，是对整个应用各个已有模块进行架构简化、瘦身增肌，同时长序地对新增模块进行良好的架构设计。因此，在具体落地过程中我们关注两个方面：

对于降体积，上云是一个常用手段，但上云很容易带来流量成本上涨，所以从目标上我们降体积和降流量并举，避免姿势变形，拆东墙补西墙。并从整体架构上提供端云一体的全栈按需加载能力和降流量能力，在云端通过数据压缩，继承复用，差量更新进行数据优化，来减少流量；在通道上，通过升级ODR和xCDN能力，实现流量降成本；在终端通过全技术栈按需加载能力，降低包体积，并通过预加载、静默、差量加载来保证包大小降低的同时，用户数据加载体验不受损。

用户体验是综合题，包括流畅、稳定、存储、能耗等，一项项见题解题，很容易治标不治本，根本上需要产研架构设计的机制和素养的形成。所以，在推动包大小优化过程中，主要的不是包大小指标，而是更关注是否有架构设计以及设计的合理性，长期全局的架构设计要求从一开始业务设计判断上就融合考虑。所以在平台上，终端团队建立数据管控机制，从一个需求开始到下线全生命周期中每个环节中，都要保证架构的前置和全局设计。

多系统：鸿蒙高性能CAPI框架

随着设备及系统不断增多，每个系统都有自己的生态开发语言与服务特点，如果每个系统单独开发势必成本会越来越大，高德终端团队一直思考如何做到用一套代码跨平台运行来支持多系统产品。我们在各系统之上设计封装了系统服务与交互组件的平台层，基于自研的与地图深度融合的跨平台AJX前端引擎，搭建了高性能的跨平台容器环境，支持业务一次JS语言开发、多系统多设备运行。正得益于此，我们能够鸿蒙系统快速适配，在业内率先支持鸿蒙 NEXT系统。

在鸿蒙系统适配过程中，遇到了一些技术难点。鸿蒙提供的原生开发方式是ArkUI，因为其动态语言的特性，导致用其来开发平台层组件时，整体性能不理想。于是我们联合华为推进性能更高的C语言的CAPI方案演进，CAPI是ArkUI的底层绘制接口，由C语言编写，具有更好的性能以及系统一致性的体验。但应用CAPI方案也存在一些问题：一个是组件丰富度不全；另一个是一些三方模块比如lottie是以ArkUI方式提供的，代码上万行，如果翻译到CAPI上成本巨大；三是CAPI有很多枚举、万能接口，直接用成本高，易出错。我们设计了通用UI引擎，封装抽象一体化的UI套件，提供给上层开箱即用，同时，向下也支持灵活扩展其他UI库。另外建设HybridView层将CAPI不支持的复杂组件桥接到ArkUI层，在保证整体性能的同时，避免了CAPI组件不足影响业务快速迭代的问题。

多设备：多屏合一框架

由于地图应用场景的广泛性，高德地图终端不但需要支持多尺寸手机、平板、手表等移动设备，还需要支持各种车机投屏。各设备单独定制适配与维护会消耗大量人力成本，因此，整体设计了多屏合一框架，封装统一投屏接口层，组合地图面、标准化控件、状态控制一体的地图UI 设计，通过自适应布局能力让一套方案能够支持多种投屏协议以及设备屏幕。同时，增强配置化设计，支持不同设备屏幕尺寸、屏幕方位下的灵活扩展、动态加载和高效定制。

（多屏合一&探路合一）

多语言：配置化框架

随着高德国际化的发展，需要在不同国家提供不同功能与语言，甚至还需要满足包体积、不同平台的要求，因此整体上设计了一套配置化框架来实现多应用形态，满足国际图、包体积、多平台的不同需求。

配置化设计由两种通道组成，一种是将当前语言标识上传的服务，服务根据语言不同下发相应数据，端侧根据数据进行展示，从而实现功能的配置，这种通道适用于类似信息瀑布流的服务数据驱动场景。另一种则对于功能逻辑存在于终端本地（如启动、导航链路）的场景，通过对UI组件标签进行不同语言环境下的配置，根据配置进行相应展示，实现端侧 Feature 化的配置。两种通道相互协同，能更灵活应对全球化场景下的多语言、多功能需求。

感谢

这一年，我们在技术探索和业务支持上不断突破，也在架构师机制建设中迈出扎实一步。高德内部一直强调“人人都是架构师” ，技术同学如果只把需求堆上线，不做技术架构，就没法做好技术。无论面对复杂的技术挑战，还是多样化的业务目标，我们在攻克一个个难题的同时，也清楚地知道，每一次进步都离不开全员的共同努力。

衷心感谢高德各团队的每一位成员，是你们的努力和专注，让我们一次次攻克难关。同时也感谢集团合作方在技术方面的交流学习。

这是一场协作的胜利，也是一场架构与机制的实践成果，感谢每一位参与者的付出！

相关文章：