app启动时长统计方法对比

科技互联界

2022-01-25 14:46
关注

移动应用的启动时间,是App性能的重要衡量指标。启动时间的快慢会直接影响用户对一款应用的判断和使用体验。随着业务需求的迭代,线上数据监控反映出来我们的启动时间越来越慢。而启动时间的快慢,本身是一个比较主观的感受。因此,除了App自己的启动时长数据,还需要对启动时长进行横向统计。这篇文章将详细介绍app启动时长统计方法介绍及对比。

首先我们需要了解的是应用(APP)的启动方式:

冷启动和热启动

冷启动:当启动应用时,后台没有该应用的进程,这时系统会重新创建一个新的进程分配给该应用,这个启动方式就是冷启动。

热启动:当启动应用时,后台已有该应用的进程(例:按home键回到桌面,但是该应用的进程是依然会保留在后台,可进入任务列表查看),所以在已有进程的情况下,这种启动会从已有的进程中来启动应用,这个方式叫热启动。

app启动时长统计方法介绍及对比

1.物理统计

通过高速相机,从点击launcher上面的图标开始,到MainActivity的第一个可见帧,算作启动时间。

2.adb 统计

adb shell am start -w pageage/activityname 通过这条命令启动,可以获得启动时间。

3.线上版本统计

如果是在线上版本,无法使用命令统计,我们分析下,所谓冷启动,就是创建applicaiton开始,一直到MainActivity第一个可视画面。

applicaiton 创建,可以从attachBaseContext开始,得到startTime。MainActivity的第一个可视画面,onResume其实还没有看到画面,最合适的回调是onWindowFocusChanged,也就是获得焦点。

但是这个回调需要做适当的过滤,就能获得endTime。

所以冷启动就是两个时间差。热启动的startTime 就是MainActivity的onRestart。

如果获取onWindowFocusChanged 的时间,需要结合MainActivity的整个生命周期。

这里有2个关键点,activity的启动流程 & applicaiton到activity的生命周期。

activity启动流程:

从launcher点击应用图标,launcher调用startactivity,

通过binder机制可以理解,所有的服务最终都会通过AMS。

AMS首先会通过zygote fork出进程。进程启动后准备好looper & 消息队列。然后调用attach方法将应用进程绑定到ActivityManagerService,然后进入loop循环,不断地读取消息队列里的消息,并分发消息。

AMS保存进程的代理对象,然后AMS通过该进程,创建activity的实例& 执行各生命周期。

4.友盟+U-APM平台的统计方式

Android平台:

sdk版本v5.2.0及之后:

app的单次使用时长=本次启动的结束时间减去本次启动的开始时间,即end_time减去start_time。

如果在本次启动过程中,应用退到后台运行(例如启动应用的过程中接了个电话,接电话的时候应用会退到后台运行),后台运行时间不超过30s,则此时间会被计算到应用的单次使用时长中;后台运行时间超过30s,则视为本次使用结束,运行到后台的时间不会被计入单次使用时长中。

sdk版本v5.2.0之前

app的单次使用时长=每个Activity的时长之和,每个Activity的时长是通过onResume和onPause方法统计的。同时app在后台运行时间无论多长都不会被计入到本次使用时长中,后台运行时长超过30s再回到前端会被视为一次新启动。

iOS平台

app的单次使用时长=session从开始到结束的时长,

即“UIApplicationDidBecomeActiveNotification”和“UIApplicationWillResignActiveNotification”两个系统消息之间的时长差值。

iOS退到后台无论多长时间再回到前端都视为一次新启动。

友盟+U-APM应用性能监控平台,还能通过轻量级的集成接入,即可拥有实时、可靠、全面的应用崩溃、ANR、自定义异常等捕获能力,及卡顿、启动分析、内存分析、网络分析等性能监测能力.

U-APM同时提供云真机测试能力,助力开发者从研发测试质量验收到线上问题复现排查,保障应用品质,提升测试效率。在云真机测试 期间自动采集崩溃信息,提供详尽的崩溃报告协助筛查,真正实现监控测试全流程深度打通。

举报/反馈