基于预测分析表法的语法分析程序_基于视频处理的小程序离线性能分析方案

目前业内对应用的性能监测在方方面面都有所建树，主要有通过性能埋点上报（页面加载时间等）和运行时硬件数据采集（CPU、内存、FPS、流量等数据），前者需要在业务代码中接入SDK或植入埋点代码，后者需要编写脚本实时监控和采集应用进程数据等。且以上的性能指标的统计结果，由于受多种外在因素的影响，如网络延迟等，往往并不能直接反应用户的直观感受。

本文结合Google提出的以用户为中心的性能指标，讨论设计了一种基于视频分析的性能统计分析方法，设计了六项性能指标和一项综合评价指标。该方案无需入侵业务，且黑盒的统计结果能比较直接地反应出用户的交互感官体验。

行业现状

在应用性能指标的采集上，基于业务集成的成熟方案有很多，如WebPageTest，CAT。但无论是否需要埋点，都需要应用主动接入。明显的优点是，能在线采集大量用户的数据做分析，能得到普遍性的结果。缺点就是，SDK的实现方法各有差异，且会受各种因素的影响，采集结果可能并不能真实地反映用户的直观感受。

目前，阿里、腾讯、知乎团队，都有探索从应用的录频进行分析，采用机器学习的方法统计启动耗时等指标。方案大致相同，首先人工标注了应用加载中各个阶段的图像，使用PCA、SIFT等特征提取方法对分帧图像进行特征提取，随后使用SVM等机器学习方法对测试集进行训练，最后使用训练后的模型对目标帧做预测。引用其中一篇文章的结论：

通过人工录屏，然后用QuickTime分帧查看时间轴，计算出的首屏加载耗时跟这套方案得到的结果误差基本在100毫秒以内，但这个过程一次取数需要15分钟左右，而现在这套方案一次取数只需要3分钟左右，效率明显提升，还避免了不同人操作采集标准不一致的问题。

可以看出，上述方案的目的是为了提升人效，但由于方案需要人工标注，前期需要耗费人力做采集标注工作，且无法适用于其他应用。机器学习探索的方法值得借鉴学习，因此本文在场景识别上结合了传统算法与机器学习的方法。

值得注意的是，本文探讨分析的对象是小程序应用，与传统的原生应用在启动上有所差异，如小程序启动只有统一的加载画面，没有Splash屏和广告屏，但方案经过修改，可以扩展。

性能指标定义

Google在提出以用户为中心的性能指标时，提出了这四个问题：是否发生？是否有用？是否可用？是否令人愉快？。然后针对前三个问题，又详细定义了首次绘制 (FP，First Paint)、首次内容绘制 (FCP，First Content Paint)、首次有效绘制 (FMP，First Meaningful Paint)/主角元素计时、可交互时间 (TTI，Time to Interact)这四个性能指标来量化（如下图所示，图片来源）。而针对最后一个问题，是否令人愉快？指交互是否顺畅而自然，没有滞后和卡顿，使用的度量方案是跟踪较长的耗时任务。

在本文中希望通过对视频的分析，将页面拆分识别加载过程中的不同场景（查看下图所示），以此来映射各个画面渲染绘制的阶段，即可统计出相关的性能指标来回答上述四个问题。本文以外卖小程序为例，指标定义如下：

1. 页面切换耗时（FP耗时）
   应用在初次进入或者切换进入下一个页面的过程中，所消耗的时间，对应FP耗时。
2. 加载耗时（FCP耗时）
   由于不同的应用加载过程中，可能不会同时出现过渡加载场景和骨架屏场景，因此本文将两者的场景耗时累加起来称之为加载耗时，对应FCP耗时。
3. FMP耗时
   FMP耗时主要统计，实际的业务数据进入用户画面所需要的时间，在本文的场景中，是从页面切换场景开始，到加载场景（过渡加载或骨架屏）结束所需的时间。
4. 数据渲染耗时
   统计了从过渡加载场景或者骨架屏场景结束到可交互场景出现之前的时间段。本文认为在该时间段内，应用将业务数据渲染到画面，该渲染过程结束后，用户进入可交互时间。
5. 可交互（TTI）耗时
   该指标统计了整个场景加载流程的总耗时。
6. >1s卡顿次数/最长卡顿耗时
   根据RAIL模型，为了持续吸引用户，需要在1s内呈现交互内容，因此统计整个加载流程中，大于1s的卡顿次数以及最长卡顿时间，既能正面反映了用户对应用加载过程中流畅度的感受，以此来反映加载过程是否愉悦。

下图展示了应用初次进入到可交互场景过程中的各个性能指标：

下图展示了应用执行页面切换后，到可交互场景过程中的各个性能指标：

预先准备

本文提出的分析方案，在前期数据准备上，大致相同和现有的视频探索方案相同，都需要提前录制操作视频。具体需要准备如下几点：

1.录制应用视频

在应用操作开始前，启动录屏功能，从入口点击进入应用，并执行相关操作，并在当前场景首屏加载完成时停留足够长的时间（如20s，用于TTI场景检测，下文会作详细解释）后，再执行后续操作，如进入下一个场景，则需重复上述操作。结束操作后停止录屏。以上操作可以通过自动化测试的方案来代替人为操作，具体本文不过多作介绍。

此外，录制的视频需要具备普遍性，如，有些情况仅在初次打开才会出现，如新手引导，首页弹窗等，应尽量避免此类特殊场景的出现。

2.入口模版图片

可以是应用点击入口的Logo图，或者具体页面点击位置的截图，用于页面切换场景的检测。

关键方法

1. 去帧黑边

由于原始的录制的视频可能包含一些无关的部分，主要是黑边，以及Android系统中底部的导航栏，为避免此类像素点的干扰，可以预先统计出视频帧的裁剪位置。方法比较简单，采用线性扫描逼近的方法，即可计算出主题图像的裁剪位置，且此过程只需要在最开始执行一次，一劳永逸。

2.模版匹配算法

模版匹配，顾名思义，就是在图像中寻找模版的位置。流行的算法有很多，如sift特征匹配等，本文在实践中，考虑到准确度和速度等因素，采用了opencv库中的cv2.matchTemplate方法，其原理类似于二维卷积操作，使用相关性评价算法，求取相似值，取值最高的位置，即为图像中最有可能有此模版的位置。在下图的展示中，图像（a）将匹配模版（b），通过TM_CCOEFF评价算法作类卷积操作得到灰阶图像（c），图中最亮的点即为最佳匹配点，也就是最有可能有目标模板图像的位置，即在图像（d）中展示的位置。

3.图像相似度计算

图像像素度的计算方法很多，如结构相似性度量（SSIM），余弦相似度，基于直方图的计算方法等等。前两种的计算方法能较好地反映出直观感受上的相似性。而由于应用的录屏场景，大部分由线框图块构成，因此在本文中，综合考虑了场景特殊性和计算耗时，使用了较为入门级的基于直方图的计算方法，该方法能够描述一幅图像中颜色的全局分布（如下图所示，图片来源），只能捕捉到颜色信息的相似度，虽然有局限性，但在实际使用中效果也不差。

首先通过cv2.calcHist计算出图像的直方图信息，然后计算直方图的重合度，并归一化，即可得到[0,1]的相似度区间值，如果想更加贴近用户视觉感知，可以在对每个RGB通道相应地乘上(0.114, 0.587, 0.299)色彩心理学的权重值。

4.图像主题色提取算法

一个图像对于用户的直观感觉，主要依靠于图像的主题色，通过主题色能让用户感受到图像的冷暖属性，而在应用场景中，主题色的提取能用来识别某些特殊场景，如加载过渡场景等。目前主题色的提取方法主要包括颜色量化法、聚类以及颜色建模的方法。在本文中使用了较为普遍的KMeans（K均值）聚类算法，属于一种无监督的机器学习算法，以此来提取视频帧中的主题色，核心算法的实现使用了sklearn中的实现方法。

K均值算法的核心思想为"物以类聚"。我们的目的是将图像中的每个像素点都归到K个类别中，K由人工指定，可以认为是K个主题色。i）随机选取K个像素点为类别的中心点，然后每个像素点分别和这K个点算“欧式距离”：

比如， rgb(0,0,0)与 rgb(1,2,3)的距离就是 14。将每个像素点分派到与之距离最近的类别中。 ii）重新计算每个类别的中心，使用求坐标均值的方法，以此确立出K个类别的 新中心点。 iii）重复步骤 i）和 ii），直到K个类别的中心点稳定（不变或者在一定范围内变动）。至此，可以将K类别中的像素点统计出来，占比最大的（或者直接取中心点）即为主题色，下图（图片来源）展示了K从2到9的主题色提取情况。

启始帧检测/定位

为了保证能完整地抓取应用初次加载的过程，录屏一般会以点击进入应用前开始录制，因此会包含无效的帧，因此在分析前，需要定位出准确的启始帧。
由于在打开应用的过程千差万别，如直接点击桌面的logo启动应用，或是在打开微信-进入小程序列表-进入微信等等，因此在本文中，保守使用了在上文提及的模版匹配和相似度计算的方法来解决定位问题。将每一帧与预先提供的入口模版进行比对和相似度计算，直至不再出现入口模版为止的那一帧，定位启始帧。

场景识别

在一般情况下，应用的非初次（初次加载可能会有引导流程）视觉加载过程是按流水线模式进行的，从应用启动或者页面切换开始，会依次存在以下几个可能的场景，1）初次启动场景（Splash Screen或者是小程序的启动动画），2）启动广告场景（倒计时结束），3）加载过渡场景（loading动画），4）骨架屏场景，5）内容加载/渲染过程，6）可交互（TTI，Time to Interact）场景。其中，2、3、4场景可能会缺失，比如小程序中不会出现场景2，以及第五个场景，内容稳定也是相对的，允许存在UI动画或者轮播图的情况。下文会具体介绍上述场景的识别方法。
多场景的识别目的，是为了排除前置场景干扰，准确识别出TTI场景的开始时间，以及能统计出更详细的性能指标。
本文假定所有提及的场景都是按顺序出现的，因此不同场景的识别算法，当且仅当上一个场景结束后才触发执行。

场景1: 页面切换

初次启动场景，可以通过启始帧的定位来确定开始时间。而在页面切换启动场景中，需要判定页面切换开始的时间点，在小程序中的页面切换一般是一个切换动画，左切或者上切，通过观察，发现切换初期到切换完成的过程中，一般是一个纯色的背景页面。于是，本文通过一个纯色边检测的方法，检测帧中左侧边的颜色分布情况，来判定切换启动的开始帧，具体步骤如下：

1. 选取左侧中间指定宽高（100 x 300 x Scale）的矩形检测区域，并选取中心位置的像素点为种子像素点
2. 遍历区域内所有像素点与之进行距离计算（采用上文提及的欧拉距离），如果距离大于设定值（9），则认为是差异点。
3. 累加差异点个数，如果占比大于设定的阈值（5%），则可认为退出该场景，即场景结束时间。反之，则可认为已在当前场景中，其第一个记录点为场景开始时间。

场景2: 过渡加载

加载过渡场景，从直观感受上是一个无实际内容的纯色画面，或者是由一个loading元素组成的加载过渡画面，可以认为是首次绘制 (FP，First Paint)或者首次内容绘制 (FCP，First Content Paint)。本文对此场景的识别方法，主要采用上文提及的主题色提取的方法。步骤如下:

1. 首先设定了K=4个类别，对每帧图像进行KMeans聚类，统计出K个类别的像素点占比，并排序；
2. 如果最高占比值小于设定的阈值（95%），则退出当前场景，并记录当前时间为场景结束时间；
3. 如果连续n=5帧都符合规则，则进入当前场景，记录初次符合规则的帧为场景开始时间。

场景3: 骨架屏

骨架屏主要用于提升用户对加载渲染过程的体验，该场景在整个场景序列中，可以认为是首次有效绘制 (FMP，First Meaningful Paint）或者主角元素渲染的时间点。通过多个应用的骨架屏观察发现，其通常会由纯色块和文字块构成，图像构造简单，颜色单一。因此，本文对于此场景的识别主要用到切片比对的方法，具体操作如下:

1. 将图像从上到下均等分为六个部分，去掉第一部分和最后一部分（由于头尾通常会包含非主体信息）；
2. 将剩余的4个部分，进行两两相似度的计算（计算方法参考上文），如果结果大于设定的阈值(0.7，通过对采集得到的20多个骨架屏进行测试得出)，则累计数量；
3. 如果累计数量的占比大于设定值(5/6)，则认为符合骨架屏的场景。

检测方法虽然简单明了，但实际测试下来效果不错，从网络采集的骨架屏样本中检测准确率达87.5%，在下文的实验场景中均能100%检测出骨架屏场景

场景4: 可交互（TTI）

本文中提及的可交互（TTI）场景，是指首次有效绘制 (FMP）之后，视觉内容渲染完毕，用户可以开始交互的场景。经过上述几个阶段场景后，数据均已准备完毕，开始数据渲染的阶段，内容填充结束后，就迎来了TTI场景。在本场景视觉内容几乎不会变动，例外的是，存在着视觉动画和轮播动画的干扰。待上个场景检测结束后，即进入当前场景的检测过程，大致思想是滑动窗口，选出TTI的候选队列，具体步骤如下：

1. 计算与上一帧的相似度（计算方法参考上文），相似度大于设定阈值(0.85)，则入窗口栈，反之清空栈；
2. 当栈的大小达到设定值（25帧）时，则可认为是疑似TTI窗口，进入候选队列；
3. 待下一个场景（页面）检测到时，开始进入下一个环节：对候选队列的TTI窗口进行合并筛选。

由于存在动画效果，对UI动画来说，帧间的变动时很小的，但是如果存在多个UI动画或者轮播动画，那么整体上的帧间相似度就很远低于阈值，因此需要对此类情况（即不同窗口的头尾帧的相似度低于阈值，但时间差1s以内）的窗口进行合并，并挑选出最大窗口的头帧为TTI场景。
为了保证筛选的最大的窗口就是实际的TTI窗口，因此，用户在录屏环节中，需要刻意停留相对较长的时间，以保证结果的准确性。

综合评价指标：SpeedIndex

上文详细分析各个分项指标的采集统计过程，在本节中，希望使用一个综合评价指标，从感官角度上量化应用整体加载过程的好坏。
本文采用了SpeedIndex指标，其是google著名的开源项目WebPageTest中的一个性能指标，用于衡量页面渲染用户可见内容的迅速程度（越低越好），计算公式如下：

简单来说，计算从开始到结束，每一帧中内容占比（当前帧的像素/最后一帧的像素），然后计算与x轴的面积，如下图所示（图片来源）：

A页面：speedIndex小，表示填充块

B页面：speedIndex大，表示填充慢

在官网中提及了两种采集方式，视频捕捉和基于浏览器的Paint事件，但官方说前者的方式存在问题，对视频的最后一帧（即视频结束时间）非常敏感，因此推荐采用后者。但后者强依赖于浏览器的Webkit。而在浏览器中，若有轮播图的场景，在页面加载完成后也会不断变化，因此会降低Speed Index分数。
而在本文的方案中，通过精确地场景拆分，能识别页面准确的TTI事件，因此能准确地截取视频分析片段，计算得出的SpeedIndex值也具有说服力。

实验&总结

本文对两大应用的容器进行了实验，分别是微信小程序和支付宝小程序/webview，具体测试了美团外卖、饿了么、京东、拼多多的小程序和h5应用，在各个场景上均有准确的识别。下图展示了在单机Android (API 8)上10次+的平均测试结果，涉及三个场景（首页、商家页、提单页）的性能指标数据，由于测试环境为室内，因此只具备横向参考性。

首页、商家页、提单页指标数据

本文提出了一种基于视频分析的离线性能指标计算方法，结合机器学习方法与传统算法，准确拆分识别了页面加载过程中的各类场景，同时在Google提出的以用户为中心的性能指标的基础上，重新设计了七种指标的统计规则和方法，具有有效的参考价值。

参考

【1】https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics?hl=zh-cn
【2】http://www.alanzucconi.com/2015/05/24/how-to-find-the-main-colours-in-an-image/