共计 3801 个字符，预计需要花费 10 分钟才能阅读完成。
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. 总结与思考
信心大于计划
超级利用的性能问题往往关联多方业务，须要多方团队合作，所以自上而下对性能的器重水平和优化信心是决定成败的要害，打通任督二脉，能力事倍功半，把优化计划顺利落地。
攻城难，守城更难
业务与技术都在疾速迭代，要想保障优化成绩避免反弹，管控是必须的，而管控就会有解放和效率影响，管控过程中就难免会遇到各种各样的阻力。所以一方面技术上，建设规范规定，配合提效工具和优化流程，尽量避免影响业务开发。另一方面，团队须要具备独特认知，性能体验与性能体验等同重要，用户比照心智很强，性能体验往往与产品口碑间接挂钩。
性能优化永远在路上
目前，咱们很多优化策略以及数据参数还是从实验室调校而来。将来，咱们会进一步摸索云端一体、端智能等技术，做到更懂用户，贴合业务和用户特点，实现性能体验的个性化晋升。
