amap_tech
1.导读
随着移动互联网的成熟发展,移动应用技术上呈现出多样化的趋势,业务上倾向打造平台及超级入口,超级应用应运而生。但业务快速扩张与有限的系统资源必然是冲突的,如何实现多(能力服务的高增长)、快(体验流畅)、好(兼容稳定)、省(资源成本低),让大象也能跳舞,成为摆在超级应用面前必须解决的问题。
 
伴随着高德地图APP近几年的高速发展,也面临到这些问题,从2019年开始,我们开启了一系列性能优化专项,对高德地图APP进行了深入性能分析和极致优化,取得比较显著的效果。在这个过程中总结了一系列优化思路和技术方案,希望对同样面临超级应用性能问题的你有所帮助。
 
经过一系列优化动作,我们在保证业务需求正常迭代新增的基础上,启动、核心链路交互、行中内存、包大小等多方面均实现了性能的成倍提升,尤其是低端机上达到了3倍+的提升,从多个维度改善了用户性能体验。
  • 启动攻坚:启动耗时降低70%+,实现2s地图元素完成展示,并管控保持在稳定低水位,呈下降趋势。
  • 核心链路交互优化:在搜索、路线等链路上实现中高端机型秒开、低端机型2s内打开,整体提升用户流畅交互体验 。
  • 行中内存优化:全机型优化了30%左右,提高稳定性。
  • 包大小攻坚:双端体积降低20%,提高安装转换率。
2.性能优化业务背景
某段时间,高德地图APP面临着性能恶化、管控困难的问题。以启动耗时为例,双端启动等待体感明显,并且历史上治理后出现反复,整体呈上升趋势,我们思考问题背后的问题,主要有以下几个方面:
 
业务庞大
超级应用一般都经历这样的发展过程。首先,应用提供服务给用户,用户开始增长,增长的用户会产生更多的需求。应用为满足新增需求不断迭代,提供新的服务。新的服务推动用户进一步增长,进入下一个循环。正是在这个正循环发展中,应用像滚雪球一样越滚越大,终于成为超级应用。
 
然而,随着业务需求的不断增长,业务量和复杂度也随着上升,系统资源会越占越多。但机器资源是有限的,资源的争夺不可避免地会导致性能问题,从而影响用户体验和业务扩展,成为超级应用正循环发展的拦路虎。
高德地图也同样经历了这样的过程,随着这几年的快速发展,应用从手机扩展到了车机,平台从iOS、Android扩展了Windows和Liunx,覆盖10多种出行方式的同时,还在不断提供组队、视频、语音、AR等新服务。与此相应的是单端代码行超百万行,线程上百,任务上千,造成了持续的性能压力。
 
环境复杂
性能问题面临的另一个主要挑战是超级应用的环境复杂。一方面,随着移动设备的长线发展,系统碎片化情况越来越严重,Android系统横跨11个主版本,iOS横跨14个主版本,加之设备厂商对系统进行各种各样的改造,进一步增加了系统的碎片化;另一方面,用户移动设备的环境是非常不稳定的,电量、温度的变化以及其他应用的抢占都会造成内存、CPU、GPU等资源波动。复杂不可控的环境为一致的性能体验的保持增加了很大的难度。
 
但作为大用户体量的超级应用,任何环境的体验都要保证。特别是地图领域,用户习惯对不同产品直接对比,任何环境下性能体验问题,都会直接影响产品的整体口碑,导致用户流失。所以需要兼顾所有环境,不只是主流机型系统和场景,在长尾场景与机型系统上也必须流畅运行,这就要求超级应用这头大象不但要在舞台上跳舞,在凳子上、甚至在水里也能跳舞。
 
技术链路长
为了满足研发效率提升、产品动态化等多样需求,移动应用技术上除支持原生开发外,也要支持小程序、Web H5、C基础库等跨平台、容器化、动态化开发。从高德APP来看,最顶层业务除了OC、Java外,还支持JS开发。支撑层提供了AJX、小程序、原生、C等多种容器框架,同时还涉及JS、JNI等桥接层。最下面则用C++提供地图各个引擎能力,这里包括OpenGL、定位传感器融合等多种底层能力。技术链路自上而下开始变得长且复杂,链路上任何一环都可能导致性能问题,原有的单技术语言的排查工具已经无法定位明确性能卡点模块,为性能排查和管控带来挑战。
 
3.解法:低成本优化迁移,长线管控
基于上面的问题,原有传统的一招鲜的优化方案,显然解决不了需求日益增长和复杂环境下的性能一致体验。所以,我们在专项实践过程中,沉淀了一套自适应资源调度框架,解决历史性能问题的同时,能够在不影响现有的研发效率的情况下,低成本优化迁移,实现新业务高性能的开发。此外,从系统底层进行全维度资源监控,自动定位分发问题,来实现长线管控,避免先治理后反弹的情况。
 
自适应资源调度框架
自适应资源调度框架在应用运行过程中,感知采集运行环境。然后对不同环境状态进行不同的调度决策,生成相应的性能优化策略,最终根据优化策略执行对应优化功能。与此同时,监测调度上下文以及调度策略执行效果,并将其反馈给调度决策系统,从而为进一步的决策调优提供信息输入。这样,可以做到在不同的运行环境下都能达到可预期的极致性能体验。并且,整个过程,对业务无需额外开发,做到无感接入,避免影响业务开发效率。
• 环境感知
感知环境分为硬件设备、业务场景、用户行为和系统状态四个维度:
  • 硬件设备上,一方面通过集团实验室对已知设备进行评测跑分确定高中低端机型,另一方面在用户设备上本地对硬件进行实时算力评估。
  • 业务场景上,将业务分为前台展示、后台运行、交互操作等几类,一般情况下前台正在进行交互操作的业务场景优先级最高,后台数据预处理业务场景优先级最低。对于同类别业务场景,根据业务UV、交易量、资源消耗等维度进行PK,确定细分优先级。
  • 用户行为上,结合服务用户画像和本地实时推算,确定用户功能偏好和操作习惯,为下一步针对用户的精准优化决策做准备。
  • 系统状态上,一方面通过系统提供接口获取诸如内存警告、温度警告及省电模式等来获取系统极端状态,另一方面通过对内存、线程、CPU和电量进行监控,来实时确定系统性能资源情况。
调度决策
感知到环境状态之后,调度系统将结合各种状态与调度规则,进行业务以及资源调配决策:
  • 降级规则:在低端设备上或者系统资源紧张告警(如内存、温度告警)时,关闭高耗能功能或者低优先级功能。
  • 避让规则:高优先级功能运行时,低优先级功能进行避让,如用户点击搜索框时到搜索结果完全展示到时间段内,后台低优任务进行暂停避让,保证用户交互体验。
  • 预处理规则:依据用户操作及习惯进行预处理,如某用户通常在启动3s后,点击搜索,则在3s之前对该用户搜索结果进行预加载,从而在用户点击时呈现极致的交互体验效果。
  • 拥塞控制规则:在设备资源紧张时,主动降低资源申请量,如CPU繁忙时,主动降低线程并发量;这样在高优任务到来时,避免出现资源紧缺申请不到资源性能体验问题。
策略执行
策略执行分为任务执行和硬件调优:其中任务执行,主要是通过内存缓存、数据库、线程池和网络库对相应任务的进行运行控制,来间接实现对各类资源的调度控制。而硬件调优,则是通过与系统厂商合作,直接对硬件资源进行控制,如CPU密集的高优业务开始运行时,将提高CPU频率,并将其运行线程绑定到大核上,避免线程来回切换损耗性能,最大化地调度系统资源来提升性能。
 
• 效果监测
在资源调度过程中对各个模块进行监测,并将环境状态、调度策略、执行记录、业务效果、资源消耗等情况反馈给调度系统,调度系则统以此来评判本次调度策略的优劣,以做进一步的调优。
 
全维度资源监控
由于技术链路长、关联模块复杂,原来出现性能问题时,需要所有相关方集中排查,check所有的改动代码,依赖个人经验判断代码的成本来定位问题,协作和排查成本都很高,导致性能管控有效落地阻力很大。所以我们就思考,性能问题的根本是硬件资源的竞争,那能不能逆向解题,反过来对资源成本进行监控,如果发现异常再回溯产生成本的代码,以及分发给相应owner.
那基于这个思路,在构建的时候,首先通过代码扫描建立代码模块关联库。然后,进行成本和调用栈采集。采集完成后,对基线版本和当前版本的成本进行对比,如果发现异常,则通过符号反解异常成本的调用栈直接定位到问题代码。另外,基于问题代码查找代码模块关联库,来定位问题模块,最后将问题准确分发给模块相应的owner,最终实现问题的自动定位和分发,支持团队并行解题。
 
管控流程体系
性能的有效长线管控,除了上面的资源监控平台,还需要配套的流程体系及组织保障。所以在APP的生命周期每个阶段都建立了从测试分析到修复验证的闭环管控。前置监控在迭代开发阶段,早发现早解决。在集成阶段监控每一个改动,保证及时处理。线上通过实时监控和动态下发,实现快速修复。
 
4.总结与思考
 
决心大于方案
超级应用的性能问题往往关联多方业务,需要多方团队协作,所以自上而下对性能的重视程度和优化决心是决定成败的关键,打通任督二脉,才能事半功倍,把优化方案顺利落地。
 
攻城难,守城更难
业务与技术都在快速迭代,要想保证优化成果防止反弹,管控是必须的,而管控就会有束缚和效率影响,管控过程中就难免会遇到各种各样的阻力。所以一方面技术上,建立标准规则,配合提效工具和优化流程,尽量避免影响业务开发。另一方面,团队需要具有共同认知,性能体验与功能体验同等重要,用户对比心智很强,性能体验往往与产品口碑直接挂钩。
 
性能优化永远在路上
目前,我们很多优化策略以及数据参数还是从实验室调校而来。未来,我们会进一步探索云端一体、端智能等技术,做到更懂用户,贴合业务和用户特点,实现性能体验的个性化提升。

相关文章: