别让错误的参数毁了你的测试结果
做客户端性能测试，很多人一上来就点“开始”，等结果出来才发现数据不对劲。内存占用突然飙高？帧率波动像过山车？网络请求时间忽长忽短？问题可能不在代码，而在测试参数没设对。
线程数不是越多越好
模拟用户行为时，很多人习惯把线程数拉满，觉得这样才能压出极限。但手机不是服务器，CPU 核心有限，线程太多反而引发资源争抢，测出来的卡顿可能是测试工具自己造成的。
比如在安卓端测试一个电商 App 的商品页加载，用 50 个线程并发请求，结果主线程频繁被抢占，页面渲染延迟严重。换成 5~8 个线程，数据反而更贴近真实用户场景。
思考时间（Think Time）不能忽略
真实用户操作是有停顿的。点击按钮后会看一眼结果，滑动列表会停留几秒。如果测试脚本一口气跑完所有动作，那测的是“机器人操作”，不是“人”。
设置合理的思考时间能让测试更真实。比如在登录流程中，在输入密码和点击登录之间加 1~2 秒延迟：
// 模拟用户输入后的停顿
Thread.sleep(1500); // 毫秒采样频率影响数据精度
性能数据采集太频繁，本身就会消耗资源。比如每 10ms 取一次内存快照，短时间内生成大量日志，设备 I/O 压力上升，反而拖慢应用。
一般建议：内存和 CPU 每 500ms 采样一次，帧率每秒记录 2~3 次就够了。既能看到趋势，又不会干扰系统。
网络环境要模拟真实场景
办公室 Wi-Fi 测出来流畅，不代表用户在地铁里也能这么顺。测试时得考虑弱网情况。
用 Charles 或者 Android 的 Network Profiler 模拟 3G、弱信号 Wi-Fi 等环境，观察加载超时、重试机制是否合理。比如设置网络延迟为 400ms，丢包率 5%：
adb shell settings put global netstats_poll_period_ms 60000
adb shell cmd connectivity restrict_background_set_limit mobile 51200设备状态要统一
测试前清后台、关自动亮度、连同一型号充电器，这些细节都会影响结果。上次测的时候电量只剩 20%，这次满电，CPU 调频策略不同，数据没法比。
最好固定测试设备，并在每次运行前执行一遍初始化脚本：
adb shell am force-stop com.example.app
adb shell dumpsys battery set status 2
adb shell settings put system screen_brightness 100监控指标要有重点
别一股脑全监控。用户最在意什么？启动慢？滑动卡？图片加载久？根据场景选关键指标。
比如社交类 App，重点关注冷启动时间、消息列表滑动帧率、图片解码耗时；工具类 App 则更关注 CPU 占用率和后台服务耗电。
别忘了测试循环次数
只跑一次测试？数据偶然性太大。同一批参数至少跑 5 次，去掉最高最低值，取平均才有参考意义。
曾经有个团队因为只测了一次，发现内存持续上涨，以为是泄漏，后来多跑几次发现是缓存预热过程，第三轮就稳定了。