一.什么是ANdroid端流量测试？
Android 端流量测试是指对运行在 Android 操作系统设备（如智能手机、平板电脑等）上的应用程序（App）所消耗的网络流量进行检测和评估的过程。这主要是为了了解 App 在各种使用场景下（如启动、运行、更新、下载等）的数据传输情况。
二.测试的重要性
-
用户体验方面
用户通常对流量使用比较敏感。如果一个 App 消耗的流量过大，可能会导致用户的移动数据套餐很快用完，特别是在用户没有连接 Wi - Fi 的情况下。例如，一个视频播放 App，如果在没有用户明确允许的情况下，后台自动播放高清视频，会消耗大量的数据流量，这可能会引起用户的不满，降低用户体验。 -
成本控制方面
对于用户来说，流量消耗过多意味着费用增加。对于应用开发者而言，合理控制流量可以降低服务器成本。例如，若应用频繁地向服务器发送不必要的数据请求，不仅会增加用户的流量消耗，也会使开发者的服务器带宽成本上升。 -
性能优化方面
通过流量测试，可以发现 App 中可能存在的流量浪费问题。比如，App 可能在某些场景下重复下载相同的数据，或者加载了过多不必要的资源。优化这些问题可以提高 App 的性能和效率。
三、测试的主要内容
1.不同网络环境下的流量测试
包括 Wi - Fi 和移动数据（如 4G、5G）网络。在 Wi - Fi 环境下，网络带宽通常较宽，流量限制相对较小，但也需要测试 App 是否会因为 Wi - Fi 网络的稳定性等因素出现异常流量消耗。在移动数据环境下，由于网络带宽和流量套餐的限制，更要严格测试 App 的流量使用情
2.不同功能模块的流量测试
以社交 App 为例，发送文字消息、发送语音消息、上传和查看图片、视频通话等不同功能模块消耗的流量是不同的。测试人员需要分别对这些功能模块进行测试，以确定每个功能的流量消耗范围。例如，视频通话功能可能会消耗大量的流量，测试时需要关注其在不同分辨率和帧率下的流量消耗情况。
3.后台流量测试
很多 App 在后台也会消耗一定的流量，如用于接收推送消息、更新数据等。需要测试 App 在后台运行时的流量消耗是否合理。例如，一个新闻类 App 如果在后台频繁地更新新闻内容，即使用户没有打开 App，也可能会消耗较多的流量。
四、测试方法
使用系统自带的流量统计工具
Android 系统本身提供了一定的流量统计功能。可以在手机的 “设置” - “网络和互联网” - “数据使用情况” 中查看每个 App 在一定时期内（如当天、本周、本月）的流量消耗情况。不过，这种方法的精度有限，它只能提供一个大概的流量消耗范围，且对于具体的功能模块的流量消耗区分不够细致。
借助专业的流量测试工具
例如，Tcpdump 是一款强大的网络数据包捕获工具。它可以捕获 Android 设备上的网络数据包，通过分析这些数据包来确定流量消耗情况。另外，还有一些商业的流量测试工具，如 Charles 和 Fiddler，它们不仅可以捕获数据包，还能提供更加直观的流量分析报告，包括请求次数、数据大小、流量峰值等信息。这些工具可以帮助开发者深入了解 App 的流量使用细节，以便进行针对性的优化。
通过adb命令来拿手机日志中的数据
今天重点学习一下这个方法
五、如何判断一个应用的流量消耗偏高
如果看流量的绝对值看不出高低，那就找几个同类型的产品对比一下。如果完成同样的事务，被测应用比同类产品高很多，那就是偏高了，可能有优化空间。
六、如何使用ADB工具进行Android端流量测试
-
前提条件
- 首先要确保你的计算机上已经安装了 Android SDK（软件开发工具包），并且配置好了 ADB（Android Debug Bridge）环境变量。ADB 是一个功能强大的命令行工具，用于与 Android 设备进行通信，包括安装应用、调试等多种操作。
-
连接设备
- 通过 USB 数据线将 Android 设备连接到计算机上。在设备上，你可能需要开启 “开发者选项” 和 “USB 调试” 模式。通常可以通过多次点击设备的 “关于手机” 中的 “软件信息” 中的 “版本号” 来激活开发者选项，然后在开发者选项中开启 USB 调试。
- 打开命令提示符（在 Windows 系统中）或终端（在 Mac 和 Linux 系统中），输入 “adb devices” 命令来检查设备是否已成功连接。如果连接成功，你会看到设备的序列号等相关信息显示出来。
-
使用 ADB 命令获取流量数据
- 获取应用总的流量数据
- 可以使用 “adb shell cat /proc/net/xt_qtaguid/stats” 命令。这个命令会输出大量关于网络流量的信息，包括每个应用的 UID（用户 ID）对应的流量数据。这些数据是以字节为单位的，包括发送（tx）和接收（rx）的流量。
- 不过，这些输出的数据比较复杂，需要进行一些筛选和解析。例如，要找到特定应用的流量数据，可以通过应用的 UID 来识别。你可以先通过 “adb shell dumpsys package <package - name>” 命令获取应用的 UID，其中 < package - name > 是你要测试的应用的包名。然后在 “adb shell cat /proc/net/xt_qtaguid/stats” 输出的数据中查找对应的 UID 的流量信息。
- 实时监测流量数据变化
- 虽然 ADB 没有像专门的流量监测工具那样提供图形化的实时监测功能，但你可以通过编写脚本来定期执行 “adb shell cat /proc/net/xt_qtaguid/stats” 命令，从而实现对流量数据变化的近似实时监测。
- 例如，在 Linux 或 Mac 系统中，可以使用 “while true; do adb shell cat /proc/net/xt_qtaguid/stats; sleep 1; done” 命令来每隔 1 秒获取一次流量数据。在 Windows 系统中，可以使用批处理脚本（.bat 文件）来实现类似的功能。通过对比不同时间点的数据，就可以大致了解流量的消耗情况和变化趋势。
- 获取应用总的流量数据
-
结合其他工具进行分析
- 由于 ADB 命令输出的流量数据比较原始，为了更好地进行分析，可以将这些数据导入到电子表格软件（如 Excel）或编程语言（如 Python）中进行处理。
- 在 Python 中，你可以使用相关的库（如 pandas）来解析和分析 ADB 输出的流量数据。例如，将 ADB 命令输出的数据读取到一个数据列表中，然后使用 pandas 库将其转换为表格形式，方便进行数据筛选、统计和可视化操作，从而更直观地了解应用的流量消耗情况。
七、通过UserId获取流量（推荐）
- 先获取app的UserId，通过uid获取流量，第六列代表下载，第八列代表上传。一个uid可能对应多个进程，把数据累加就行。两个时间片中间应用流量的消耗，就计算接收字节数的差值就行。
注：下方命令里windows电脑把grep换成findstr
adb shell dumpsys package email.homescreen.launcher.mailapp | grep userId
adb shell cat /proc/net/xt_qtaguid/stats | grep 10962
wlan0代表WiFi，wlan0如何初始化0 只需打开手机飞行模式再关掉就清0了
八、通过pid获取流量（了解）
- 先获取app的pid，然后按照pid查询流量
adb shell ps -A |grep email.homescreen.launcher.mailapp：查询进程
adb shell ps -Aa：查看抬头
- 先获取app的pid，然后按照pid查询流量
adb shell cat /proc/Pid/net/dev
九、常见问题
- 冗余内容 ：同类请求被间隔执行，请求的内容包含一些相对静态的信息，正确的处理是第一次请求包括静态信息就好，后面的同类请求只包含必要的即时变化信息即可。错误的处理方式是每次请求服务器都返回一次静态信息。
- 冗余请求 ：有的时候会发现应用短时间内发出多个同样的请求，收到结果也都几乎一 样，这种情况应该尽量减少请求次数，同时注意排查程序逻辑错误，也许 问题不像表面看起来那么简单。
- 无用请求 ：有的请求，你会发现谁也不知道它是干嘛的，很可能是以前版本遗留下来的无用请求，或者是引用的其他代码包偷偷发出的，甚至是间谍请求，请收集一切证据后，毫不犹豫的干掉它
- 永远无法得到回应的请求： 如果见到某类请求永远的连接失败或被返回 404 之类的失败结果，那它不是历史遗留的多余请求，就是某个不易察觉的功能已经失效了
- 过多的失败请求 ：有见过一类或一组请求，n 个成功之中夹着 m 个失败的吗？举个简单的场景，某类请求，间隔 1 分钟后连续发两次，总是先有一次失败的请求，1s后马上再次发出一次同样的请求就成功了（这里 1s 后发出的请求是指业务逻辑层判断前面请求失败后延迟 1s 后重传的）。很好奇为什么第一次总失败是吧，就有这么种情况，客户端两次请求乐观的想要复用同一个 TCP 连接(长连接半长连接)，但是服务端不这么想，也许是客户端发起两次请求的间隔，超出了服务端长设置的长连接无响应时限。。如何判断呢？看看失败的那次请求，是否和前一次成功的请求复用了同一个 TCP 连接（体现在Wireshark 的 streamId）。
- 非预期请求： 比如一种常见的情况，应用退后台后，有些请求就没必要了，观察下自己的产品，是 否在后台真的没有发出这些请求。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
