Android应用性能测试之CPU和内存实时监测

最近在做设备性能测试，下面和大家分享一下android应用程序的CPU和内存的性能测试。我们知道监测CPU和内存占用是一个实时变化的状态，我们可以通过Linux的资源监控命令来实现对android平台的资源实时监控。

要做到上面的测试环境需要具备以下几点：知谈

（1）adb shell

(2）echo 3>/埋猛桐proc/sys/vm/drop_caches(清除系统cache）

（3）top -d 1 | grep com.baidu.BaiduMap(以百度为例，每一秒打印一次资源利用情况）

由于使用了复合查询”管道符“的方式，所以必须拥有root权限，否则grep的命令无法识别。

在这里我们看到cmd并没有显示出所对应的列的标题，所以我们可以单独通过top命令来了解到：

至于以上各列的含义我不说我想大家也应该猜得到了，在这里仅说一下我们要用到的两个参数，其他的可以再网上查询了解：

|--CPU%：CPU占用率

|--RSS：实际占用的物理内存数，单位KB

我们可以针对不同的业务，打印出不同的“标签”，用于区别弯坦现在从事的那个业务，并为后期分析各业务模块中CPU和内存的占用以及对比使用。

网络不通畅，导致控制很卡，对方电脑运行的程序过多，电脑响应速度慢。

远程控制出现卡顿原因要先检查宽带网速或者在使用网络人少的时间段，再进行远程控制。先让对方清理一下对方的电脑，关闭不需要的程序，确定清理完成之后，再次进行远程控制。大多数远程协助软件都是通过第三方中转的，所以州仿只要是开启远程控制电脑速度一定不如平时绝答流畅。

建议还是用微软自带的远程登陆，如果对方开启远程登陆，并且主机可以获得一个公网IP那么用远程登陆访问对方主机是很快的，比起其他的软件要快的很多。

扩展资料

远程控制一般支持以下网络方式：LAN、WLAN、WAN、拨号方式、Internet 方式。此外，有的远程控制软件还支持通过串口、并口、USB、红外端口来对有限距离范围内的远程机进行控制。

传统的远程控制一般使用 NETBIOS、IPX/SPX、TCP/IP等协议来实现，目前也有通过 WEB 页面和 Java技术来实现不同 *** 作系统下的远程控制。

远程控制性能因素分析

一个远程控制系统必须快速、准确、稳定、可靠的运行。影响一个远程控制系统正常运行的因素主要有时间因素、可靠性因素、系统稳定性因素。

时间因素分析

实时性是远程控制系统的一个比较重要的性能指标。如果由于各种原因，使得监控用户发送的控制命令不能立即使设备产生作用，造成了设备动作的不连续，影响控制系统的正常工作。同时，设备的一些状态信息不能及时反馈给用户，必然引起用户在判断现场设备运行时出现偏差。

这些都可以导致远程控制系统的性能不可靠。一个系统的实时性通常采用响应时间来定量描述。响应时间是指某一系统对输入做出响应所需要的时间。响应时间越短，就标志着系统的性能越好。

在远程控制系统中，需要传输的数据有多种，但主要是反馈的设备状态数据和用户的控制命令这两种数据，它们的处理时间和传输时间对实时性产生主要影响。

可靠性因素的分析

一个远程控制平台的可靠性主要是指远程监控终端系统、传输系统的传输可靠性和现场监控系统的可靠性。可靠性是一个控并迹慧制系统的基本要求之一。对于远程控制来说，传输系统的可靠性是最为重要的一个方面。而传输系统的可靠性在于传输介质与传输方式等因素。可靠性可以用公式描述 R=MTBF/(MTBF +MTTR)

其中 R 表示可靠性，MTBF 表示平均无故障时间，MTTR 表示平均故障修复时间。因此，增大可靠性的有效思路是增大平均无故障时间或者减少平均故障修复时间。

稳定性因素

稳定性因素是指现场监控终端的在监控终端的监控下，能够稳定运行，不产生震动、中断、跳变等不正常现象。一方面，由于时延的影响，现场监控系统在上一步命令执行完成，而没有接收到下一步执行的控制命令时，必然产生一定控制过程中断。

如果现场监控系统没有对该中断作出一定的弥补措施，必然导致不可预测的结果；另外，现场控制系统产生了异常错误，要求监控终端给予快速修正，但是，由于传输时延影响，数据到达监控终端需要一定的时间，从而使得异常错误在现场没有得到有效的终止，有可能导致不可预测的结果。

第三方面，数据传输的错误有可能导致出现不稳定状态，传输系统可能由于外界干扰等原因使得数据传输错误，导致了对设备控制出现不可预测的结果，从而影响系统的控制稳定性。

参考资料来源：百度百科（远程控制平台）

如果你不喜欢记上述条件，那么一般Swap分区设置内存2倍就可以

例子：一个4c8g的机器，给其创建一个16g的swap分区。

2.1 创建步骤：

1. 创建swap交换区硬盘存储用的空白文件。

# 这里bs是块大小，bs*count就是我们要创建的swap空文件大小

dd if=/dev/zero of=/swap bs=1024M count=8

2.使用mkswap格式化文件为swap文件系统

#-f 使用文件作为swap交换区

mkswap -f /swap

3.启用刚才创建的swap文件

swapon /swap

4.设置开机自动启用swap文件交换区（ 否则重启后swap分区会消失，这里会自动挂载 ）:

    vim /etc/fstab,添加如下内容

5.关闭swap分区，可以纤链使用swapoff命令关闭swap。

    1）关闭swap 分区

            swapoff /swap

    2）确认swap分区关闭成功

          swapoff

6. 调整swap分区大小

        1）关闭swap 分区

                 swapoff /swap

        2）确认swap分区关闭成功

                  swapoff

         3)   手喊删除swap分区

                 rm -rf /swap

        然后按照1~4步骤，重新创建和挂载开启swap分区即可

7. 确认swap分区是否真的开启

        free -m或则top，能够看到swap分区的大小。

        swap分区一般毁薯孙是在系统内存不足的时候才会发生换入换出，我们知道swap分区是硬盘上的一块儿区域，所以 性能上肯定不如真实的物理内存, 那么在实际的性能测试过程中，我们都要注意哪几点呢？

        1) swap分区开始被使用（top命令观察）

            这时候说明系统的内存不足了，一般的性能测试不建议压测到大量使用swap分区（自行控制压测tps），如果大量使用swap分区，我们可能会看到wa（io等待）有些高，这个时候整个机器系统效率不会很高。        

       2）压测场景

            很多实时性比较高，且耗内存的程序在设计性能测试case的时候，需要分开启swap分区和不开启swap分区两种场景进行测试，这种一般需要和开发沟通测试场景。

       3）swap分区的性能

            由于swap分区是硬盘的一部分，可想而知，硬盘的档次也会决定了swap分区的性能，比如ssd的硬盘的的swap分区性能就比普通硬盘要好，所以这个在性能测试上也要考虑真正在生产环境部署的时候我们使用哪类硬盘作为swap分区（包括程序的大量IO性能），以确定一个性能参数。

---