作者：杨夕凯、吴文扬

高德地图从19年开始对全链路性能体验进行了持续三年的优化，最终整体核心链路上实现了打对折优化，用户体验上大幅提升。过程中，对性能优化的一些思考和实践经验，本文进行了总结，希望对大家有些助益。

优化前后效果对比（以优化前的耗时为基线100%）

思路

整体思路分为明确性能卡点，倒序专项解题和正序长线管控三个部分：

明确性能卡点：找到优化点才能有的放矢，科学的评测标准和明确的优化点对于优化至关重要，科学的评测标准需要能够合理评估性能体验的好坏，并更贴近用户的真实感受，而目标则需要可量化，这样才能够保住在专项过程中快速对焦高效执行，避免走弯路；
倒序专项解题：性能问题不是单一业务问题，往往涉及多个产研测团队协作，我们从问题出发快速倒序以专项形式凝聚多团队资源，确定目标，快速攻坚拿结果，增强团队信心；
正序长线管控：优化是从“果”倒退“因”的过程，已经发生问题了再去解决，是一种倒序解题的思路。那么如何让问题从“因”的源头上截住，或者说让已经优化的效果不发生倒退，那么我们的思路三是：长线持续的正序管控，避免原有业务的持续恶化，同时巩固专项的优化成果。

接下来，本位将针对这三个部分，逐一解析。

明确性能卡点

制定标准

首屏加载速度的快慢极大影响着用户体验，所以首屏耗时作为我们页面耗时的统计标准。随着手机硬件的不断升级，很多高端设备硬件性能好掩盖了程序性能问题，因此我们会对不同机型等级设备进行优化，最大程度的覆盖到线上用户。

1 统计标准

确定了首屏显示耗时是统计标准，下面是如何确定首屏显示耗时的几个维度：

业务角度：业务形态各异，不同页面的首屏定义一定不同；
产品角度：定义首屏围绕着功能使用量进行，高频功能优先；
研发角度：通过业务流程上的日志埋点来锚定首屏的起终点；
产研测拉通标准：建立统一的产研测沟通语言，那就是量化数据。

2 机型标准

机型等级：根据设备评分将设备分为高中低三种等级；
选定机型：选定不同等级代表机型的准则，我们采取的是依据线上用户设备的占比，尽可能的覆盖比较多的用户，尽可能选取有代表性的厂商设备，当然也需要综合考虑现有测试实验室可用设备情况，毕竟采购不一定很及时和避免不必要的浪费。

确定优化项

高德地图长期以来的历史累计，导致每个场景的优化，都面临着复杂的业务代码，甚至还存在业务盲区。这就对快速分析历史大量业务，精确定位耗时点带来极大的挑战。如果靠人工梳理分析，人力投入和时长都不现实。这就需要从工具和方法论上找到加速方案。

1 自上而下明确优化点

手机设备维度分析：

无限的业务场景通过移动设备运行在有限的性能资源上，资源分配势必捉襟见肘。所以我们需要根据设备的不同来分析耗时问题。比如在比较差的手机上出现的耗时问题，可能在高端的手机上并不是问题。优化点也不同，需要个性化策略来进行针对性优化。例如：低端机的复杂交互动画就是一个耗时点，比如搜索页面关闭一些动画，性能上带来不小的收益，同时也不损害用户体验，在高端机上这个耗时点就可以不考虑。

业务平行维度分析：

业务点特别多，那么为什么我们要选择出行场景、搜索场景等去分析耗时呢？这就需要拉通产品和BI，用数据说话。通过分析线上用户行为，大部分用户选择了点击搜索框进入搜索首页，而线上用户反馈也是进入搜索卡顿耗时等，相比其他功能，搜索首页的及时性和重要性不言而喻，于是根据线上数据进行业务分级，该场景排在首位，性能资源应该向这里倾斜，需要首先分析这里的耗时点。

业务内部维度分析：

首先对业务场景本身进行全链路梳理，找出其中的关键时间点，然后通过场景日志工具进行埋点并上传至服务，收集线上用户真正的首屏时间数据，为量化目标提供有效依据。其中两两关键点之间的时间戳差值即为阶段耗时，能辅助分析业务耗时问题。围绕着业务分析的过程我们还沉淀了很多分析工具来辅助分析。

2 最小集，加法，减法

最小集是一个探底的过程，在保证首屏产品形态不变形的情况下做出最小可运行，去掉其他所有跟首屏无关项，这就是减法。我们可以理解这个最小集是在不改变现有架构的情况下，我们最优的优化效果。如果最小集的极限数据达标，接下来就要在此基础上把必要的相关依赖项逐个加回来，保障产品功能完善，其他没必要的依赖性可以优化、或者去掉、或者延后等，这就是加法。当然如果这个最小集的极限数据都不能达标，那我们就需要从其他维度去寻找优化点了，一般能够从网络耗时和架构合理性两个方面找到突破点。

倒序专项解题

性能问题不是单一业务问题，往往涉及多个产研测团队协作。所以我们的思路是：

从问题出发快速倒序以专项形式凝聚多团队资源，确定目标，快速攻坚拿结果，增强团队信心

专项攻坚

专项攻坚，也是个边打边建，边打边沉淀的过程。排查性能问题的手段最初是比较离散的。往往是遇到一个解决一个，下次不同的场景需要重复工作再来一遍，那么我们的思路是：

沉淀可复用方案，解题思想、通用框架和工具平台，针对“优化手段”本身的效率进行优化，让成本逐渐降低

启动专项是第一个性能专题项目，完成了一个场景优化，耗费30人，3个版本迭代。之所以人力比较多，是因为“第一次”面临的问题非常多，指标要分析定义标准、埋点工具要新建、优化过程没经验、管控手段要新建。

搜索专项完成了一个场景优化，耗费8人，人力情况就好了很多，版本变成2版。当时已经有启动期间已经建设好的埋点工具，有了一定的优化经验，少走了很多弯路。

核心链路专项完成了六个场景，耗费24人，一版搞定。优化的过程有条不紊，人力少、场景多、时间短。这得益于优化效率的提升，成本逐渐降低。在不断优化的过程中积累了相对成熟的分析工具、优化工具、管控工具。

优化方案

性能优化是一个体系化问题，我们在优化方案上分为三层，业务、引擎和基础能力，分别自上而下明确优化点。上层业务进行自适应资源调度，中间引擎提供加速能力，底层能力提供高性能组件。

1 业务自适应资源调度

业务层优化主要通过业务编排调度来实现性能最优状态，但业务各自调度优化工作重复且繁琐。为了降低这部分成本，我们开发了一套资源调度框架，业务接入后，调度工作由框架完成。调度框架在应用运行过程中，感知采集运行环境，然后对不同环境状态进行不同的调度决策，生成相应的性能优化策略，最终根据优化策略执行对应优化功能。与此同时，监测调度上下文以及调度策略执行效果，并将其反馈给调度决策系统，从而为进一步的决策调优提供信息输入。这样，可以做到在不同的运行环境下都能达到可预期的极致性能体验。

一、环境感知

感知环境分为硬件设备、业务场景、用户行为和系统状态四个维度：

硬件设备上，一方面通过集团实验室对已知设备进行评测跑分，以此确定高中低端机型，另一方面在用户设备上本地对硬件进行实时算力评估；
业务场景上，将业务分为前台展示、后台运行、交互操作等几类，一般情况下前台正在进行交互操作的业务场景优先级最高，后台数据预处理业务场景优先级最低；对于同类别业务场景，根据业务UV、交易量、资源消耗等维度进行PK，确定细分优先级；

用户行为上，结合服务用户画像和本地实时推算，确定用户功能偏好和操作习惯，为下一步针对用户的精准优化决策做准备；
系统状态上，一方面通过系统提供接口，获取诸如内存警告、温度警告及省电模式等来获取系统极端状态，另一方面通过对内存、线程、CPU和电量进行监控，来实时确定系统性能资源情况。

二、调度决策

感知到环境状态之后，调度系统将结合各种状态与调度规则，进行业务以及资源调配决策。

降级规则：在低端设备上或者系统资源紧张告警（如内存、温度告警）时，关闭高耗能功能或者低优先级功能
避让规则：高优先级功能运行时，低优先级功能进行避让，如用户点击搜索框时到搜索结果完全展示的时间段内，后台低优任务进行暂停避让，保证用户交互体验；
预处理规则：依据用户操作及习惯进行预处理，如某用户通常在启动3s后，点击搜索，则在3s之前对该用户搜索结果进行预加载，从而在用户点击时呈现极致的交互体验效果
拥塞控制规则：在设备资源紧张时，主动降低资源申请量，如CPU繁忙时，主动降低线程并发量。这样在高优任务到来时，避免出现资源紧缺申请不到资源性能体验问题

三、策略执行

策略执行分为任务执行和硬件调优：其中任务执行，主要是通过内存缓存、数据库、线程池和网络库对相应任务的进行运行控制，来间接实现对各类资源的调度控制；而硬件调优，则是通过与系统厂商合作，直接对硬件资源进行控制；如CPU密集的高优业务开始运行时，将提高CPU频率，并将其运行线程绑定到大核上，避免线程来回切换损耗性能，最大化地调度系统资源来提升性能

四、效果监测

在资源调度过程中对各个模块进行监测，并将环境状态、调度策略、执行记录、业务效果、资源消耗等情况反馈给调度系统，调度系统则以此来评判本次调度策略的优劣，以做进一步的调优

2 引擎加速能力

一、地图引擎

地图引擎是地图应用独特的部分。这块主要从绘制优化策略入手，主要包括分批分块渲染、帧率调度、消息调度等。

二、跨端引擎

跨端引擎则需要给业务提供支撑，它也是全场景通用的方案，比客户端优化更有施展空间，与业务直接接触离业务够近。所以跨端引擎的优化策略就是降低业务代码的性能成本。主要方案有：

线程提优先级
上下文预加载
业务框架复用
require引用复用

这里简单介绍下上下文预加载，为了不影响现有业务的运行状态，我们设计了一种闲时分段预加载的方案，能够在页面未进入之前，将页面需要计算的耗时、导入文件的耗时等提前执行。

闲时：当业务线程空闲时再做预加载，避免影响其他页面
分段：每次预加载的内容粒度小于16ms，避免预加载任务阻塞当前线程
预加载：将目标页面的计算量提前，加速进入目标页面

三、H5容器

1、离线包加速

离线包加速，主要解决复杂 H5 页面的加载速度问题：资源文件数量较多，下载耗时较长，导致页面加载缓慢，通常通过增加loading来减少界面加载等待问题，从而导致用户等待耗时长，最终带来的是转换率流失。在此大背景下，结合高德已有的一些平台能力，搭建了离线包加速能力。整个链路包含：

离线包构建：通过前端脚手架，提速业务开发效率，动态指定离线包资源配置；
离线包发布：对接已有的服务发布能力，搭建前端可视化发布平台，提供灰度控制、包更新、数据统计等能力；
端管理：包下载、管理、生效，控制下载及更新时机——对于高频页面进行预下载请求，打开页面时实现“秒开”；
资源生效：容器内资源加载拦截，对接离线资源管理模块，命中缓存则直接生效，未命中走正常网络请求进行下载。

2、容器预创建

容器的预创建和预热，对于H5页面的加载速度将会有很大的提升，WebView的实例创建成本本身是相对较高的，在APP启动后合适的时机进行预创建并缓存复用，可以解决首次开启和二次加载的速度。AMap本身有启动任务编排及闲时任务调度，在此基础上可在对应WebView模块内进行预创建操作。对于预创建WebView Context切换问题，由于AMap的页面栈实际为自定义实现，仅有一个独立的Activity，因此具有天然的良好兼容性。对于预创建，本身是空间换时间的一种做法，对于不同性能设备的差异化配置，需要重点打磨——此外，也可以结合端智能的特征行为，类似用户页面跳转的行为习惯及频次等，来动态决策是否需要进行预创建。

3 架构高性能组件

一、线程池

线程池支持业务进行任务优先级编排、线程总数控制、线程避让等调度策略，使设备资源得到充分合理的利用。

线程队列管理模块，其提供5个优先级队列：

高优队列：用于处理 UI 相关的任务，能够快速返回执行结果，如启动阶段高优任务等；
次高优队列：用于执行需要立即返回的任务，如业务page文件加载等；
普通（低优）队列：主要用于不需要立即返回的任务，如网络请求；
后台（最低优）队列：用于处理一些用户不会感知的任务，如埋点、耗时的IO操作等；
主线程闲时队列：用于处理不需要立即执行，但业务又不支持按需执行的任务，只有在主线程检测处于空闲状态时才会执行

二、网络库

网路请求作为场景中耗时大头，其性能表现几乎决定了场景首屏耗时表现，我们针对网络请求的各个环节，做了链路监控与极致优化，重点包含：请求精细化调度、并发预处理、DNS预加载、连接复用等。

请求链路示意图：

排队：对请求进行精细化调度；对线程资源分级，高优请求有自己独立的资源，同时资源可以高占低，但低不能占高，实现高优请求 0 排队。同时限制低优请求并发量，避免并发过多导致底层带宽抢占；
预处理：主要包含公参、签名、加密等一系列耗时操作，将预处理操作从原来的串行转为并行，压低预处理耗时；
DNS解析：常用域名做白名单，在启动时即会进行常用域名DNS预解析，真正使用时，实现解析0耗时；
建连：通过使用h2长连接、预建连等策略，实现建连几乎0耗时；
请求上/下行：根据body大小，智能判断是否需要压缩，降低body大小，减少传输耗时；
解析回调：针对响应较复杂的场景（如规划），使用更高效的数据协议格式（如pb），降低数据大小&解析时间。

正序长线管控

优化是从“果”倒退“因”的过程，已经发生问题了再去解决，是一种倒序解题的思路。那么如何让问题从“因”的源头上截住，或者说让已经优化的效果不发生倒退，那么我们的思路三是：

长线持续的正序管控，避免原有业务的持续恶化，同时巩固专项的优化成果。

高德地图客户端横向业务上包含出行、搜索、打车等业务线，纵向架构上包含业务层、平台适配层、跨端引擎层和地图引擎层，跨多个语言栈，性能问题具有跟进流程长和排查链路长的特点。因此管控思路集中在标准、流程、自动化平台和工具的建设上。

标准

在经过全面的专项治理后，性能管控的目标和要求是避免持续恶化的状态，由于测试波动的存在及热更、快速迭代、动态化插件的频繁发布，需要管控的出口非常多，如果存在管控遗漏区，性能就会不可避免的持续恶化。因此管控标准确定为以固定基线为基准，以环比数值为量化标准，把所有变化因素都包含到管控中，有效防止叠加恶化。

流程

高德客户端主版流程主要分为三个大阶段：需求分析和设计、业务独立迭代开发、集成测试，集成测试阶段本身有大量的业务BUG，所以留给性能问题发现和解决的时间非常紧张，为了解决这些问题，管控流程需要利用好主版流程的每一个阶段，分阶段消灭性能问题。

需求分析和方案设计计算，提前识别问题；
迭代开发阶段，提前发现和解决问题，降低性能问题暴露晚导致来不及修复，影响线上用户体验的风险；
集成测试阶段每天汇总数据大盘，及时发现问题，依托平台和工具快速排查，加速问题流转；
灰度和发布阶段关注线上数据大盘，建立报警机制，及时发现问题，通过用户日志排查线上问题。

平台

依托泰坦持续集成平台和ATap自动化测试平台，打造连通开发，构建，性能测试，问题跟进、排查、流转、解决完整链路的工具链，提高问题发现和解决的效率。

泰坦持续集成平台

-- 定时构建，支持定位出包任务，构建类型支持性能包

-- 自动化测试触发，支持打包触发和定时触发两种触发方式

-- 集成卡口及决策，集成申请展示性能测试结果，集成决策审批流程

ATap自动化测试平台

-- 性能大盘，汇总性能数据，快速发现问题

-- 埋点详情，整合快速排查工具，加速排查

-- 问题跟进，结合Aone，监控问题解决流程，加速流转

总结

目前为止，高德核心链路的性能体验优化效果得到了较大的提升。从最初的拿到优化结果，到后来的优化效率提升，优化成本降低。整体的优化进程总结下来：

战术上，采用“专项”+“技术沉淀”+“长线管控”的方式，能够保障性能体验问题得到良性解决。
战略上，过去我们靠“人”解决问题，现在我们靠“人”、“架构”和“工具”解决问题。未来是否能够“工具”自己解决问题或者避免出现问题呢？随着“技术沉淀”积累的工具和“长线管控”建设的平台不断增加，相信量变引起质变只是时间问题。

关注【阿里巴巴移动技术】微信公众号，每周 3 篇移动技术实践&干货给你思考！

三年磨一剑，高德地图体验优化总结相关推荐

三年磨一剑，高德地图体验优化实践总结
高德地图从19年开始对全链路性能体验进行了持续三年的优化,最终整体核心链路上实现了打对折优化,用户体验上大幅提升.过程中,对性能优化的一些思考和实践经验,本文进行了总结,希望对大家有些助益. 优化前后 ...
三年磨一剑：蚂蚁金服的研发效能洞察实践
本文共计9279字,建议阅读时间:19-20分钟. ‍ 阅读本文你将收获: 1.蚂蚁金服研发团队效能建设概述: 2.研发效能体系建设过程中遇到的问题与挑战 3.研发效能体系搭建具体方案与实现 4.构建 ...
三年磨一剑，五次被拒稿，交大博士坚持稿件申诉，终发表学科顶刊
全世界只有3.14 % 的人关注了爆炸吧知识本文来源:募格学术三年磨一剑,经历五轮审稿被拒, 他坚持不懈, 最终申诉成功发表物理顶刊: 厚积薄发.精益求精, 他潜心科研, 2年内发表6篇高水平论 ...
Android高德地图线优化,Android 接入高德地图SDK模块的优化点点滴滴
起因: 由于在最近接手了一个关于导航的App,发现地图页面跳来跳去实在是卡顿地不行(运行在车载设备上的APP,机器性能实在是有限). 初步判断: 应该是是关于地图等控件的反复创建和销毁,给内存GC带来 ...
拆解AppleTV 4：三年磨一剑，苹果希望AppleTV成为智能家居的中心---ESM
苹果在今年的秋季新品发布会上推出了第四代Apple TV,包括一个机顶盒和一个遥控器,表示在电视体验方面它代表着电视的未来.配置方面,搭载64位A8芯片,支持蓝牙4.0.802.11ac Wi-Fi ...
三年磨一剑，领域驱动设计布道师出版了《解构领域驱动设计》
解构领域驱动设计作者:张逸本书全面阐释了领域驱动设计(domain-driven design,DDD)的知识体系,内容覆盖领域驱动设计的主要模式与主流方法,并在此基础上提出"领域驱动设 ...
三年磨一剑大话数据结构——数据结构起源、概念和术语
QQ 1274510382 Wechat JNZ_aming 商业联盟 QQ群538250800 技术搞事 QQ群599020441 解决方案 QQ群152889761 加入我们 QQ群6493473 ...
全新界面改版+实用功能上线高德地图新版全体验
全国大部分地区已进入踏青季,为了让人们的出行更加便捷,国内领先的移动互联网地图软件高德地图推出了全新的7.6.6版本,从功能.体验.视觉三个方面都取得了突破性的改进.一目了然的是其UI界面有了很大的变 ...
百度地图保存图片_百度地图与高德地图PK，你pick哪一个？
随着智能手机的广泛使用,地图软件几乎成为像微信.支付宝等手机必不可少的一款手机应用.而且随着智慧城市的进一步发展,城市的交通系统也变得更加复杂而且日新月异,面对日益复杂的交通系统,手机地图更是人们出行 ...

三年磨一剑，高德地图体验优化总结

思路

明确性能卡点

倒序专项解题

正序长线管控

总结

三年磨一剑，高德地图体验优化总结相关推荐

最新文章

热门文章