1. 前言

       随着互联网的快速发展,目前已经进入存量用户竞品角逐的时代, 大环境的改变, 任何影响用户体验的场景或细节都会引发用户流失, 各环节, 各维度的数据分析能力, 对产品的决策, 精细化运营, 异常问题发现, 优化效果验证等方面起着至关重要的作用。

       说到数据分析, 已经成为互联网技术人的必备技能, 总的概括可解决五大类问题, 即是多少(数据描述现状);是什么(到底现状好不好);为什么(出现这个情况的原因是什么);会怎样(可以预测后续的影响);又如何 (治理动作是什么, 试点后再用数据予以验证,给出效果结论)。

       一切数据分析的核心价值都是通过多维度分析, 找到业务现存不足, 发现共性问题, 提升功能品质, 指引优化方向, 优体验促转化、到达。例如: 通过用户进行画像分析, 精细化运营,提升拉新转化提升拉新转化; 通过分析新沉流用户活跃场景, 跨场景合作, 提升激活效率等。

       在端基础的这些场景中, 我们也通过技数能力的实践, 发现现存的体验问题, 挖掘业务的共性问题, 从而优化并提升用户的使用体验。

2. 整体治理思路

       本文主要论述的是在支付宝研发链路的各个阶段(线下/灰度/线上) , 针对端基础的几个核心场景, 如: 首跳, 首页, 唤端等场景, 是如何通过线下数据检测做防劣化, 通过灰度阶段精细化数据分析感知业务新突增问题, 以及通过线上的多维度数据监控及智能分析能力, 持续高效发现及定位水位上涨背后原因, 以及通过共性分析能力, 持续高效挖掘可优化项, 通过动态化运营手段实现千人千面的。

解释说明:

● 竞品分析 通过录屏分帧等一些采集能力, 获取竞品相同场景的性能体验数据, 知己知彼,对较竞品差的分析背后原因；

● 线下白盒诊断: 由于唤端链路中, 小程序的性能对整体唤端性能起着决定性作用, 我们通过DexAOP, 增加SP、端内Service加载、类加载、动态Bundle加载、Load so库加载耗时的采集; C++ 部分的性能诊断, 初步使用SimplePerf profile进行探索, 对perf.data 进行算法解析处理, 得到各函数的耗时,对高耗时函数加以分析；

● 线上多维共性分析: 如唤端链路, 通过建立多维度分析, 共性分析等能力, 智能分析线上水位波动原因, 分析共性表象, 指引优化方向。

3. 线下数据采集及分析

       我们依托线下性能检测平台, 对版本的性能进行分析, 覆盖核心场景: 冷启动, 首跳, 唤端, 小程序等, 锁定发生的劣化版本, 根据细粒度子阶段耗时定位劣化原因, 从线下采集的子阶段耗时分析, 可以清晰得出全链路具体阶段发生性能劣化及确定劣化的原因。

       为了在线下能发现更多的优化方向, 通过独立的性能采集bundle, 获取对应场景起终点范围内SP, service, 类加载等耗时情况, 通过 IO detectSdk 监控对应场景的IO耗时,该项能力在子小程序启动优化中进行实践, 对监测到的高耗时servcie等进行预加载处理等, 小程序的启动性能较年初明显提升。

      针对c++性能优化诊断方面, 通过SimplePerf-profile采集运行时数据, 对采集数据进行数据处理, 可以发现c++层耗时问题, 可以通过堆栈反解找到耗时的具体函数调用。

4. 灰度阶段数据分析

1.以首跳等场景为例, 由于业务场景多且复杂, 通过线下性能测试无法覆盖完全, 增加灰度体验巡检的能力, 弥补体验类问题在灰度期间卡劣的空白。

2.客户端开关一般在灰度阶段推送放量验证, 需要在灰度期间感知新增开关对该场景性能的影响。

       为了在灰度阶段发现细粒度的性能问题, (整体性能的涨跌数据让开发同学不知如何下手分析), 我们进行了线程维度的耗时对比, 针对首跳, 首页起末点过程中的主/子线程耗时进行采集并上报, 原理也并不复杂, 主线程:通过主线程中Looper的loop()方法, 在分发处理消息开始前和结束后的打印log回调信息, 采集执行耗时; 子线程: 通过切面获取Runnable耗时, 按照对应的数据结构组装上报(由性能诊断spiderSdk完成), 定时巡检, 当触发告警规则, 同步到群。

● 遇到的问题

1) 用任务名称判断新增与否存在误报问题: 线程所在的类发生变化, 但并非该线程发生变更, 例如在该线程前加入新的runnable, 导致新版本$x发生变化, 导致造成误报；

2) 突增任务指向不明确: 某任务耗时虽突增, 但任务本身没有发生代码变更, 是依赖的底层逻辑发生变更, 希望可以分析出变更的对应的类.方法, 引导业务同学进行排查确认。

● 解决方案

1) 通过对方法体进行md5处理(不限md5, 任务里的内容做唯一标识处理即可), 得到任务名称及该唯一标识的映射关系, 巡检时分析新增任务时进行两个版本的唯一标识比对, 如果一致则为非新增问题；

5. 线上智能多维数据分析

       当线上水位发生波动时, 如何从数据指标中快速定位原因, 通常我们擅长分析绝对值类的指标波动，比如成交金额、活跃用户数、接入商户数等的波动，按照业务分类对这些核心指标下钻即可定位到问题。但我们面对的端基础类的体验指标均为率类型（A/B，对应为单指标多维度型), 甚至需要复杂场景的自定义类（K=f(a,b,c,....)，对应为多指标相关型）的指标波动分析，我们该如何着手呢？

       车品觉在《数据的本质》中说: “数据如何证明业务好还是不好, 建立分析框架，对一个业务指标进行指标化拆解，并通过有限个指标客观地量化地描述业务状况（即业务指标的贡献度拆解，哪些因素做了正向的贡献（动力) ,哪些因素做了负向的贡献（阻力)).业务好还是不好,是需要不断寻找对比标的（比较对象）的"。

       首先我们要先了解全貌, 需要清楚指标水位的上升(下降)主要归功的业务分布, 根据业务纬度处理, 我们很快能得到对比日期下, 业务水位的贡献值情况, 锁定主要分析业务。需要注意的是, 可能今天某个业务指标表现不好,并不能一棒子打死, 可能是表现较好因素的动力(正向贡献)抵不过表现不好因素的阻力(负向贡献), 反之亦然; 不波动, 也不一定意味着风平浪静, 可能是表现较好因素的动力和表现不好因素的阻力此消彼长。因此需要进一步拆解纬度, 对细粒度纬度进行分析. 本章节通过唤端指标来阐述是如何实践的。

理清业务流程链路, 梳理40+纬度因子, 智能分析, 助力线上波动原因定位

       性能数据分析不同于稳定性数据分析, 上涨的百十ms暂且不需要快速的问题应急, 线上实时的盘面波动整体较大, 针对性能的水位监控及问题的定位因看不清全局而变得十分盲目, 所以建议使用T+1 离线数据, 通过客户端线上版本间对比, 全版本数据趋势监控, 确定维度因子贡献占比。

       以唤端链路为例, 全链路从框架启动, 流量海关, 容器框架启动, 再到业务渲染完成, 理清业务链路后, 细化拆解影响水位变化的全部影响因子, 第一级纬度影响因子有: 各子阶段耗时, PV量, 低端机占比等, 第二级纬度中, 直接影响耗时因子如: 优化项占比(例如: 跳过首页占比/uc预加载占比/prefetch预加载占比等), 容器链路各子项占比(例如: uc各初始化类型占比, 同步下载离线包占比等); 间接影响因子如: 业务发版, 客户端发版等。

案例1: 智能分析-业务贡献度

针对整体水位波动--分析业务的水位贡献值, 通过业务耗时贡献度得出上涨业务主因。

案例2: 智能分析-业务耗时多维分析

锁定上涨主因业务后, 继续下探多维分析,

1) 对于Top50的唤端业务, 我们会进行日纬度线上水位巡检, 智能分出水位上涨原因, 如上图所示, 确定主因业务及业务上涨原因；

2) 同时具备剔除低端机分析能力, 排除因低端机水位上涨导致的水位上涨影响；

3) 提供业务自助智能诊断的能力--性能劣化, 到达率流失自助排查。

案例3: 业务呈现的共性, 更加准确的锁定水位波动原因

      下图是某阶段耗时水位上涨的趋势监控, 当我们发现8月19号持续水位上升后, 通过智能维度分析能力, 已经将导致上涨影响最大因子最呈现出来。

1) 我们提供线上版本同期对比, 全版本整体趋势分析对比的能力。

2) 针对每个维度分析业务的共性情况, 更加准确的锁定水位波动原因。

案例4: 智能共性分析能力- 在各个维度, 或者各种组合纬度上, 业务是否存在相似的数据表象呢?

       http类请求共性分析: 如下图所示, 我们能够清晰发些, 约有10+业务, 在某阶段阶段 5s异常率占比高于30%, 发现这类共性数据表象后, 智能分析在某一维度的共性, 进而发现优化空间。

心得体会:

● 通过线上多维度分析, 一部分可以直接分析得到根因, 一部分的数据表象是为原因定位指引方向. 找到共性指征后, 需要捞取该指征的用户日志进一步分析根因(捞取用户日志也是有技巧的)。

● 通过线上智能分析也无法定位原因的需要不断进行复盘, 补充线下缺失能力, 补充线上智能分析缺失纬度, 逐渐完善分析引擎。

6.依托用户数据的业务动态化

       以上已经从线下-> 灰度 -> 线上阐述了通过技数能力发现的性能体验类问题, 如唤端的用户增长投放渠道来说，该渠道到达率治理面临痛点问题 1) 用户群体中低频+新沉流 2) 低性能 3) 冷启动占比50%+, 常规的体验优化策略在该类用户上呈现的效果并不明显, 如何提升这批用户群体的到达率。

极速唤端

我们通过用户设备性能分做决策, 通过通用的模版设计, 可以快速到达native落地页。

写在最后

      以上仅从所负责的端框架关注的核心场景, 阐述如何从线下, 灰度以及线上的各个阶段, 通过获取关键的多维数据, 智能的辅助业务发现性能存在的问题, 进而优体验降流失。 数据分析不再是数据开发同学的一项工作, 在目前掌控数据即掌控方向的时代, 数据分析已经变成每个互联网人的必备技能, 通过对应的业务特性, 整理正确的的数据分析方法及分析维度, 尽可能多的的串联链路上下游, 透过数据看"本质", 可以从中发现更大的世界。

如对本文有任何建议或问题，请关注我们的微信公众号，我们将私信回复 ❤️