Python基于stagesepx库测试APP启动响应时间

在APP端统计应用操作耗时的主要方法有：

1. 埋点：开发人员喜欢使用的方法。对于开发人员而言在某项操作的起点，终点各打一个点，做个差，拿到耗时数据。

2. 眼睛看：测试人员更喜欢使用的方法。这种方法统计出来的数据，是用户感知最真实数据。最常用方法：压力感应器+录制视频+读帧计算。手机端录屏+读帧计算。

关于stagesepx

这里给大家介绍一种基于图像处理与机器学习的自动化视频分析方法 —— stagesepx

stagesepx能将视频拆分为帧，并将其划分为多个阶段。在此之后，你可以清晰的得知视频包含了几个阶段，以及每个阶段在干什么，且这一切都是自动完成的。

简单的demo

APP启动的阶段切割

App启动页性能优化。这几乎是每个App开发团队绕不开的工作之一。下面将通过一个简单的例子给大家介绍如何使用stagesepx做App启动耗时统计。

使用手机自带录屏adb shell screenrecord 录制一段GoogleDialer的启动视频，可以看到APP启动分为以下几个阶段.

video.gif

• 静置手机桌面

• 用户点击应用

• 应用启动闪屏

• 应用启动首页

而我们要计算的app启动响应时间即用户点击应用 -> 应用启动首页

怎么使用stagesepx进行性能统计

本文介绍的使用stagesepx方式统计分析某项操作的耗时，主要基于Keras分析方法。
使用stagesepx方式进行耗时统计的整个过程可以分为切割视频，判断稳定区间，训练模型和预测分析四个步骤

1. 切割视频和判断稳定区间

from stagesepx.cutter import VideoCutter
from stagesepx.video import VideoObject

# 将视频切分成帧
file_name = 'video.mp4'
video = videoObject(file_name)

# 新建帧，计算视频总共有多少帧，每帧多少ms
video.load_frames()

# 压缩视频
cutter = VideoCutter()

# 计算每一帧视频的每一个block的ssim和psnr
res = cutter.cut(video, block=6)

# 计算出判断A帧到B帧之间是稳定还是不稳定
stable,unstable = res.get_range(threshold=0.96)

# 把分好类的稳定阶段的图片存本地
res.pick_and_save(stable, 20, to_dir='./picture/stable_frame', meaningful_name=True)

• VideoObject().init(self, path:typing.Union[str,os.PathLike], pre_load: bool = None, fps: int=None,)

• path: 视频文件路径

• pre_load: pre_load has been deprecated. use video.load_frames() instead.

• fps: fps转换，使用ffmpeg进行初始化视频

• VideoCutter().init(self, step: int = None, compress_rate: float = None, target_size: typing.Tuple[int, int] = None)

• step : 帧间步长，默认为1

• compress_rate : 压缩率，默认取值范围为（0,1], 默认值是0.2。 压缩率越高，可能会将用户点击屏幕这个时间的帧和前后帧，一同判定成一个稳定区间。

• target_size : （100, 200）表示压缩到100x200

• VideoCutter().cut(video, block,window_size, window_coefficient, *_,kwargs)

• video: video file path or VideoObject

• block: default to 3. when block == 3, frame will be split into 3 * 3 = 9 parts

通过上述过程，stagesepx可以将一个视频文件切分成若干帧图像，并将其认定的处于稳定状态的图像保存到stable_frame文件夹内。
在stable_frame文件夹内, 帧图像又被细分到了多个子文件夹中。stagesepx判断每个子文件夹中的帧图像为一个稳定区间。它认为稳定区间中的图像内容处于非变化状态的。例如之前分阶段所提及的静置手机桌面，应用启动闪屏和应用启动首页结束后这三个阶段都是很稳定的区间。

image.png

2. 模型训练
   现在我们要使用stable_frame中稳定区间内的帧图像，来训练一个模型文件，该模型文件将用于后续的预测工作。在我们调用cutter.cut(video)方法后，视频文件被切分到了不同的文件夹中。正如上面所说，这个切分结果并不是很让人满意，他讲视频切的太细了。这时候我们可以对切分结果进行人工调整。如果某个本应该被划分在同一个稳定区间的帧图像被分在了多个文件夹，我们可以人工将其合并到一个文件夹下。

随后对更新后的stable_frame文件夹内的帧图像进行训练，得到模型文件。

from stagesepx.classifier.keras import KerasClassifier

# 训练默认文件
cl = KerasClassifier(epochs=10)
cl.train('./picture/stable_frame')
cl.save_model('./model.h5',overwirte=True)

3. 预测
   得到模型文件后，我们将其存储到本地。后续我们将使用该模型，预测其他视频文件中，App的启动耗时。预测过程如下

from stagesepx.classifier.keras import KerasClassifier
from stagesepx.cutter import VideoCutter
from stagesepx.reporter import Reporter
from stagesepx.video import VideoObject

# 使用Keras方法进行预测
cl = KerasClassitier()
cl.loadmodel('./model.h5')

# 将视频切分成帧
file_name = './video2.mp4'
video = videoObject(file_name)

# 新建帧，计算视频总共有多少帧，每帧多少ms
video.load_frames()

# 压缩视频
cutter = VideoCutter()

# 计算每一帧视频的每一个block的ssim和psnr
res = cutter.cut(video)

# 判断A帧到B帧之间是稳定还是不稳定
stable, unstable = res.get_range()

# 把分好类的稳定阶段的图片存本地
res.pick_and_save(stable, 20, to_dir='./forecast_frame', meaningful_name=True)

# 对切分后的稳定区间，进行归类。
classify_result = cl.classify(file_name, stable, keep_data=True)

result_dict = classify_result.to_dict()

# 打印结果
print(result_dict)

# 输入html报告
r = Reporter()
r.draw(classify_result, './result.html')

result_dict字典中存储了预测结果。Keras算法认为预测时归属在key=0中的帧，和训练模型时文件夹0中的帧属于同一类。同理归属到key=1中的帧，和训练模型时文件夹1中的帧属于同一类。至于处于不稳定状态的帧，则归属到key=-3中。

影响稳定区间定的参数

在将视频文件切分成帧图像时，为了能得到更准确的切分结果，我们需要调整视频切割时的入参，主要参数如下：

参数名	作用	默认值	取值范围
threshold	判断某一帧图片是否稳定的阈值。阈值越高，则某一帧越难被认定是稳定的。	0.95	[0,1]
offset	补偿值，和threshold相互影响。 有时候设置太高的threshold，会将一个变化很小的区间，切分成多个稳定区间。通过设置offset值，可以将变化不大的多个稳定区间，连在一起。	None	[0, +∞)
block	判定某一帧视频的稳定程度时，将帧图像切分的程度。改制越大，计算出的ssim值越敏感。 block =2，则切分成4宫格。1则不切割	2	[1,+∞)

如何初始化视频

通过手机或者电脑adb录制出的视频，由于软件录制的帧不稳定，存在每一帧的时长不恒定的现象。为了避免该现象影响分析结果，我们在做切割视频之前，需要使用ffmpeg对视频进行初始化。方法如下：

video = VideoObject(Video_NAME, fps=60)

或者直接在cmd中调用ffmpeg，(使用该方法，需要将ffmpeg路径添加到环境变量)：

ffmpg -i 待初始化视频路径 -r fps 输出文件名

---

原文章：https://blog.csdn.net/wsc106/article/details/107351675