腾讯移动品质中心TMQ [腾讯 TMQ] 探秘 APP 性能三角区

匿名 · 2016年07月28日 · 最后由江隆君回复于 2016年12月06日 · 2679 次阅读

作者：TMQ melodyliu

APP 要做性能测试，什么样的数据能反应应用的性能情况，如何评估应用的性能状态？不知道该如何入手？一起来分析下如何给 APP 做性能测试。

性能测试三要素：性能指标、测试场景、测试工具。

首先要思考选哪些指标来评估性能：内存、cpu、电量还是什么？接着，选择你需要测试的场景，测试场景描述了你需要在何种场景下取性能数据，要测试 APP 何种功能等等。最后，根据你的指标和场景选择适合你的测试工具。

下面就从这三方面来具体分析。

性能指标

常见的性能指标有：内存、CPU、电量、流量、速度/耗时。这里从 2 个角度分析：

1）为什么选这个指标？

2）指标常用单位有哪些？

着重讲下关注最多的：内存、CPU。

1. 内存

为什么要选内存呢？需要知道 Android 的 OOM 和 Low Memory Killer。

OOM：Out Of Memory，顾名思义是说内存不够用或者耗尽了，进程会被强制终止。安卓框架限制了每个应用进程所占用的最大内存值。关注内存的一个目的就是避免内存使用过大，出现 OOM。主要关注内存使用较多时的场景，例如游戏 app 正在游戏中。

Low Memory Killer：Low Memory Killer 在用户空间中指定了一组内存临界值，当其中的某个值与进程描述中的 oom_adj 值在同一范围时，该进程将被 Kill 掉。如果你的 APP 某个进程需要一直保存存活，你需要保持你的进程优先级足够高，并且占用比较小，因为 Low Memory Killer 在工作时，同一优先级的进程会先 kill 那个占用最大的。性能测试时主要关注待机时的内存是不是够小。

这里再补充一点：Low Memory Killer 的工作可能致系统变卡。为什么呢？因为它 kill 了一些进程，然而现在市面的很多 APP 为了保活都会自启，刚刚被 kill，立刻又起来。启动占用大量内存（还有 CPU），又触发 Low Memory Killer。频繁的被 kill 和启动形成了恶性循环，so…系统变的很卡。

内存指标有 VSS、RSS、PSS、USS。差别如下：

VSS- Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS- Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS- Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS- Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）

一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS。

测试中比较常见的的选择是 PSS total，这种算法共享库内存按比例分配，对 APP 来说比较公平。依据 APP 关注点，也可选择其他指标例如 USS，或者将其他指标也一起统计，用于分析。

例如用 dumpsys meminfo 命令看到，手机管家进程的 pss total = 16708 kb。

2. CPU

为什么要关注 CPU？

（1）CPU 使用率

想必你肯定有这样的经历：玩某个游戏或者 APP 的时候，手机发热发烫。是的，CPU 的频繁使用，会让你的手机发烫，让你的手机变卡（CPU 资源不足）。如果让用户发现你的 APP 用起来发烫，那就等着他的吐槽和卸载吧。

也就是说 CPU 性能，我们需要关注 APP 使用中 CPU 消耗情况，通常会使用 CPU 使用率这个指标。

（2）CPU jiffies

如果 APP 在退出界面后还有进程长期运行，那你需要关注下待机场景的 CPU。待机场景下 CPU 的消耗一般不会很大，例如手机管家，可能消耗经常是 0%，1%，长时间平均下，可能只有 0.1%、0.2%，看看竞品，也是差不多，好像没有太大区别。

那么 CPU 消耗这么少是不是就不用管 CPU 了呢，然而即使是平均值很小，但是长时间待机，例如安全类工具，CPU 的消耗还是不容忽视。那么这种情况如何评估 CPU 呢，这里引入一个更精确的指标：CPU 时间片： jiffies！

Jiffies：为 Linux 核心变数 (unsigned long)，它被用来记录系统自开机以来，已经过了多少 tick。一定时间占用的 jiffies 可以反映出此进程的 CPU 消耗。

Android 系统可以获取到 APP 进程当前的 CPU jiffies（这个数值不断累加）。我们测试时常用的单位有：消耗 XX jiffies/分钟；半/1 小时共增加 XX jiffies。

Tips :Jiffies 与变频

Linux 内核中提供了 performance 、powersave 、userspace、conservative 和 ondemand 五种变频模式供用户选择使用，它们在选择 CPU 合适的运行频率时使用的是各自不同的标准并分别适用于不同的应用场景。那么，测试 CPU jiffies 的时候是否需要固定 CPU 频率呢？理论来讲，固定 CPU 频率肯定是可以的，那么不固定会怎样呢？

经测试数据验证，保持手机同环境情况下，不固定 CPU 频率对于测试无太大影响。

这组测试数据是没有固定 CPU 频率情况下测试了 5 次的 jiffies 数据（每次 30min），可以看出，标准差为 1.56，波动并不大，基本可以排除变频的影响。

3. 电量

手机电池资源有限，电量的重要性就不必说了。现在很多手机都有电量排行，如果你的 APP 总是排在前面，小心被卸载哦。电量通常的单位是：mAs 或者 mAh。

4. 流量

手机的一个特点就是有移动网络。移动网络下的流量消耗需要特别关注，wifi 下的流量优先级略低。流量单位：kb，M。

5. 速度/耗时

可用性原则里面有个 2 秒原则：一个松散的原则，即用户没有必要对某些系统响应等待 2 秒以上的时间，比如应用程序转换和开始的响应时间。对于启动 APP，进入某页面，这些操作时间都应不超过 2 秒，且越短用户体验越好。

当然，2 秒并不是绝对的，对于一些用户感知明显的功能，例如垃圾扫描，病毒查杀，可能需要更多的时间，但是操作进行期间，需要给用户适当的感知和预期，避免用户因等待过久而离开。当然，用户是期望能够又准又快。

测试场景

性能要测哪些场景呢？用户实际使用中，场景是多种多样的。拿手机管家来说，有的用户每天喜欢拉拉小火箭；有的用户经常安装卸载 app；有的用户喜欢用它清理垃圾；又有的用户有很多骚扰电话和短信；还有用户喜欢用它连免费 wifi；另一些用户安装后不怎么使用。用户多种多样，功能多种多样，场景多种多样。要测试性能，这么多场景全部覆盖是不太可能的，要选择什么场景比较合适呢？

选择性能测试场景前，我们可以先将上述说的这些场景来分分类。

从用户使用 APP 时 APP 的 activity 是否在最前端，可将 APP 的使用场景分为：前台、后台。

在后台时根据 APP 只是保持心跳等最基础功能，还是一些场景触发了相关功能，可分为：后台待机和后台使用场景。

于是我们有了下面三个层次的场景：后台待机、后台使用、前台使用，场景模型如下：

1. 场景与性能指标

先说说这些场景要关注些哪些性能指标。

（1）后台待机

指标：重点关注待机内存和待机耗电情况。流量有需要则关注。

内存和耗电可取实际测试值作为数据。例如待机内存 19M；24h 待机电量 3mAh。如果你的 APP 的耗电模块主要是 CPU，你可以考虑使用 CPU 时间片（jiffies）来评估。

测试时长：这个场景的耗电和 CPU 消耗会比较小，测试时需要考虑较长时间的测试数据以便反应 APP 的性能情况。

（2）后台使用

指标：重点关注一个场景触发 APP 功能时的内存、CPU 使用率或电量。

内存通常会取增量，即：触发功能后的内存 - 触发前的待机内存，作为某功能消耗的内存。

（3）前台使用
常关注使用时的内存、CPU 使用率、流量。如果是某个操作需要一些时间，需要关注速度和耗时。

2. 场景与用户感知

（1）后台待机

这个场景下用户的感知是：我没有使用这个 APP，因此这种场景如果有性能消耗的情况下，一定是非常小的，否则用户会认为：我没用都占这么大内存！耗这么多电！让用户有这种感受是非常危险的。

例如：手机管家只在通知栏有个小图标，用户没有感觉自己在使用。

（2）后台使用

这个场景下 APP 确实进行了一些工作，但是用户对于自己使用了 APP 并不会有特别明显的感知。例如来电话时手机管家会进行电话的识别以判断是不是骚扰电话等，用户看到的是一个来去电悬浮窗，但是用户并没有主动使用，因此这种情况下性能消耗也不可以过高。

（3）前台使用

这个场景是用户打开了 APP 进行使用，此时的性能消耗也是比较大的，但是用户的容忍度也会相对比较大。但是 OOM 导致闪退、手机发烫这些现象是绝对不允许的。性能消耗当然是越小用户越喜欢。

3. 场景与测试优先级

场景分层图中，三个层次场景成金字塔形状，他们的占用面积同时反映了他们在用户侧使用时占用的时长。

这么多场景，时间有限，哪个场景更重要，我应该先测哪个呢？下面说说如何评估这些场景的重要程度和优先级。

原则：用户在该场景停留越久，该场景越重要；场景被用户使用到的频率越高，该场景优先级越高。评估方法有：

（1）运营数据评估

对于后台待机场景，我们使用时长来评估优先级。重要程度=时长（数值越高越重要）。从运营数据中我们可以得到场景 1、2、3 在用户侧使用的时长 T1、T2、T3。例如用户平均每天亮屏 5 小时，灭屏 19 小时，那么灭屏待机场景重要程度=19，高于亮屏的 5。

对于后台使用和前台使用场景，我们用使用频率来评估，优先级=N，N=几天 1 次（数值越小优先级越高）。例如：收短信场景，这个场景每个用户每天都会遇到；而安装/卸载 APP 这个场景，用户可能平均 5 天操作一次。那么收短信场景的优先级=1，安装卸载 app 场景优先级=5。

（2）ACC 测试建模

当我们没有获得运营数据时，可以考虑使用 ACC 建模思路来帮助区分性能场景优先级：分析产品的核心价值；分析产品的主要模块、系统；FENIX 每个系统提供何种能力实现产品价值；区分优先级。

测试工具

测试工具的本质是获取性能数据，当然一些工具在使用和观察数据上有差别。工具分 2 类：现有工具，其他获取方案。这里列举下目前我们常用的工具共选择和参考：

手工和自动化测试

如果是新手或者只需测试几次，可考虑手工进行性能测试，建议选择方便直观易用的工具。测试内存和 CPU 使用率，推荐使用 APT（http://code.tencent.com/apt.htmleclipse 插件，可实时监控 Android 手机上多个应用的 CPU、内存数据曲线，直观方便。），它最为

如果是需要长期测试的内容，需要考虑自动化测试。自动化测试方案我们常用 UIAutomator 来实现，其中获取性能数据的方案，可查看上表。

这里需要特别提下，在获取 CPU 时间片（jiffies）数据时需要注意，测试工具应该做尽量少的事情（不要同时用 dumpsys meminfo 获取内存会增加该进程的 CPU 消耗），减少对被测 app 性能的影响，选择性能消耗小的方式。建议：工具获取方式从系统文件/proc/(pid)/stat 读取 CPU jiffies，不做其他测试内存等等事情。