SDK启动时间测试方案

点击蓝字关注这个神奇的公众号～

目前笔者主要负责商业广告SDK的测试，需要对接大量的媒体APP，媒体方经常会反应一些性能问题，而好的用户体验与性能表现才能让集成方更加满意，最近有媒体提出在集成SDK的时候，启动时间测试不够理想，因此本文从SDK的角度对启动时间进行测试。

启动时间概念

应用启动分别包括冷启动、热启动、温启动和首次启动，这几种方式的区别似乎不好理解。我们引用Andriod Developers官方的解释来帮助我们理解[1]。

• Cold Start：A cold start refers to an app’s starting from scratch: the system’s process has not, until this start, created the app’s process. Cold starts happen in cases such as your app’s being launched for the first time since the device booted, or since the system killed the app. This type of start presents the greatest challenge in terms of minimizing startup time, because the system and app have more work to do than in the other launch states.

  冷启动就是在启动应用前，系统中没有该应用的进程 (包括 Activity、Service等) 。通常出现在设备开机后应用的第一次启动，系统杀掉应用进程 (系统因内存紧张触发kill和用户主动的kill) 后的再次启动等。那么在这种方式下，应用的启动时间最长，因为相比另外两种启动方式，系统和应用要做的准备工作最多。
  

• Warm Start：A warm start of your application is much simpler and lower-overhead than a   cold start. In a warm start, all the system does is bring your activity to the foreground. If all of your application’s activities are still resident in memory, then the app can avoid having to repeat object initialization, layout inflation, and rendering.

  热启动（有翻译为暖启动的，这里借鉴硬件的warm boot，理解为热启动比较合适）比冷启动简单得多，开销也小。热启动中系统要做的不过是将activity调到前台。如果应用中的activity仍然驻留在内存中，则应用不需要再次初始化对象，加载和渲染布局。PS：某些对象可能在响应onTrimMemory()时被释放掉了，则需要在热启动时重新创建。
  

• Lukewarm Start：A lukewarm start encompasses some subset of the operations that take place during a cold start; at the same time, it represents less overhead than a warm start. There are many potential states that could be considered lukewarm starts.

  温启动（有翻译为热启动，我想温启动来形容不冷不热更贴切一些） 其实也是热启动的一种，不过它的消耗要比热启动更低。有两个典型的场景可以看作是温启动：

    1. 按返回键一直退出应用，然后你又马上打开这个应用；

    2. 系统降低应用的优先级，把应用给退出了，但是用户自己又进入了应用。

测试方案介绍

根据笔者测试的SDK，最终选择首次冷启、非首次冷启和热启三种方式，选择这三种的原因有以下两点：

•  冷启过程中必然去拉取云更云控请求、配置文件请求，另外根据业务场景不同，还会初始化去请求开屏广告，包括图片或者视频的下载，而首次冷启会拉取配置请求和云更云控，非首次冷启则不拉取但要初始化，热启则无须初始化相关内容。简单画个流程图：

• 笔者要测试SDK是的启动时间，因此要降低Demo对启动时间的影响，所以Demo初始化时要尽量影响范围很小。

基于以上，最终将选择冷启(Cold Start) 和热启（Warm Start）来测试启动时间。这里要注意，使用non-debuggable模式的app进行分析。debuggable模式会开启debug特性，可能导致跟真实用户不一样的启动时间。

下面是测试SDK启动时间考虑的测试场景和测试环境：

• 基于理想条件下测试，因此选用纯安卓系统手机，如nexus系列手机，且选用一款机型即可，不同手机肯定会不同，选择多机型测试没有必要。

• 网络情况，因为不同的网络条件下，totaltime也受一定影响，如数据网络、WIFI、弱网。

• 单进程与多进程。

• 初始化时是否预加载开屏广告接口。

• 有开屏广告时，要下载的图片或者视频的大小，因为集成SDK后的应用启动时也会加载相关东西，会出现资源抢占情况。

由于笔者测试的场景不同，因此需要有不同的demo来满足业务去测试启动时间，比如有的集成方无开屏广告位，而有的集成方则有开屏广告位。

启动时间测试和测试结果考量如下：

使用的命令即adb shell am –W [packageName]/[packageName.MainActivity]

执行成功后将返回三个时间，即ThisTime、TotalTime和WaitTime。这三个值相信大家也都非常熟悉了，总之，如果只关心某个应用自身启动耗时，参考TotalTime；如果关心系统启动应用耗时，参考WaitTime；如果关心应用有界面Activity启动耗时，参考ThisTime。那么我们SDK就使用TotalTime来衡量启动时间。

下面是冷启动的部分参考代码（shell脚本）：

系统中运行的其他app会对启动时间有干扰因素，如果需要进行版本对比及竞品对比，最好要尽量保持环境一致，并反复执行多次，为防止数据出现波动，建议去掉最高值和最低值后取平均值。

测试中遇到的问题

最后说下本次遇到的一个问题，也是对shell脚本下awk语法的不熟悉导致，之前获取totaltime时间是通过adb shell am start -W $PackageName/$ActivityName |grep TotalTime|awk -F ' ' '{print $2}'|tr -d "\r"，但是执行多次总是报错，其实这种方式是取不到数据的，awk过滤查询时，后面是跟着file文件的，大家想了解这方面的知识可以参考下http://www.runoob.com/linux/linux-comm-awk.html

参考文献：

[1]https://developer.android.com/topic/performance/launch-time.html

Qtest是360旗下的专业测试团队！

是WEB平台部测试技术平台化、效率化的先锋力量！

陪伴是最长情的告白

每日为你推送最in的测试技术

识别二维码

关注我们