正文

service集成monkey自动化测试实战解决内存泄漏与ANR卡顿提升App稳定性

/0 浏览量
0725

咱们今天不聊那些虚头巴脑的理论，直接切入正题。作为一名在移动端摸爬滚打多年的“老码农”，我见过太多App因为偶尔的内存泄漏或者主线程卡顿，导致用户投诉、应用商店评分暴跌。很多时候，问题不是出在核心逻辑上，而是出在那些不起眼的Service里，或者是Service与Activity/Fragment交互的缝隙中。

Monkey测试，这个听起来有点“暴力”的名字，其实是检验App稳定性的试金石。但传统的Monkey只是随机点击，它像是一个喝醉了的测试员，虽然能撞出不少Bug，但你很难精准定位是哪个Service导致了崩溃，也很难量化“卡顿”到底严重到了什么程度。

所以，今天的主题非常明确：如何让Monkey不仅仅是一个“随机点击器”，而是一个带着“听诊器”和“显微镜”的智能诊断专家。 我们将深入探讨如何结合Android原生工具（如StrictMode, TraceView, Systrace）以及自定义脚本，来监控Service运行时的内存变化和ANR（Application Not Responding）风险，从而彻底提升App的稳定性。

为什么要盯着Service不放？

很多开发者有个误区，觉得只要UI不卡就行。大错特错。在现代Android架构中，Service（尤其是前台Service或后台绑定Service）承担着大量关键任务：数据同步、文件下载、位置监听、蓝牙通信等。

  1. 内存泄漏的重灾区：Service生命周期长，如果内部持有Activity Context或者静态变量引用不当，随着Monkey疯狂切换页面，这些引用无法释放，内存曲线会像过山车一样飙升，最终OOM（Out Of Memory）。
  2. ANR的隐形杀手：如果在Service中执行了耗时操作且没有正确异步处理，或者通过Binder与主线程通信时阻塞了主线程，ANR就会悄然而至。
  3. 资源竞争：多个Service同时启动，或者Service与UI线程争夺CPU资源，会导致界面掉帧，用户体验极差。

传统的Monkey测试往往只记录崩溃日志（Crash Log），但对于“慢半拍”的卡顿或者缓慢增长的内存泄漏，它无能为力。我们需要的是可观测性。

第一步：搭建“带感官”的Monkey环境

要解决内存和卡顿问题，首先得让Monkey“看”得到、“感”觉得到。我们不能只跑一个adb shell monkey ...就完事了，我们需要定制化的参数和前置准备。

1.1 启用StrictMode检测

StrictMode是Android提供的一个开发工具，它可以检测线程策略违规，比如在主线程进行磁盘访问或网络请求。这对于发现潜在的ANR诱因至关重要。

在你的Application类或者基类Activity中初始化StrictMode：

public class MyApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        
        // 仅在Debug模式下开启，避免影响Release性能
        if (BuildConfig.DEBUG) {
            StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                    .detectDiskReads()      // 检测磁盘读取
                    .detectDiskWrites()    // 检测磁盘写入
                    .detectNetwork()       // 检测网络访问
                    .penaltyLog()          // 将违规信息打印到Logcat
                    .penaltyDeath()        // 可选：严重违规时崩溃（测试阶段慎用）
                    .build());
            
            StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                    .detectLeakedSqlLiteObjects() // 检测SQLite对象泄露
                    .detectLeakedClosableObjects()// 检测未关闭的资源
                    .penaltyLog()
                    .build());
        }
    }
}

当Monkey运行时，如果某个Service在主线程做了IO操作，Logcat里会立刻出现红色警告。这就是我们定位问题的第一线索。

1.2 自定义Monkey脚本与事件过滤

标准的Monkey随机性太强，为了针对性地测试Service相关的逻辑，我们可以编写自定义的事件序列。例如，模拟用户快速切换Tab（触发Service绑定/解绑），或者模拟长时间停留（触发后台保活机制）。

创建一个文本文件 custom_monkey.txt：

type: user
count: 1000
speed: 1.0
start
wait 500

# 模拟高频点击首页，触发可能的Service心跳
tap: 50%,50%
wait 100
tap: 50%,50%
wait 100
tap: 50%,50%

# 模拟切换到设置页，可能涉及Service解绑
tap: 80%,20%
wait 200

# 模拟下拉刷新，触发网络Service
swipe: 50%,20% 50%,80%
wait 300

# 随机事件混合
random

执行命令：

adb shell monkey -f /sdcard/custom_monkey.txt -p com.your.package.name --throttle 100 -v -v -v > monkey_log.txt

注意 -v -v -v 参数，它会输出最详细的日志，包括每个事件的坐标和时间戳，这对后续分析至关重要。

第二步：内存泄漏的自动化捕获与分析

内存泄漏是Service最大的敌人。Monkey跑几小时，如果内存持续增长且不回落，那就是泄漏的铁证。

2.1 使用MAT (Memory Analyzer Tool) 进行快照对比

单纯看DDMS或Profiler的曲线是不够的。我们需要在Monkey测试前后，甚至中途，抓取Heap Dump（堆转储文件）。

实战技巧：自动抓取Heap Dump

你可以写一个简单的Shell脚本，配合Monkey一起运行。脚本每隔5分钟抓取一次内存快照，并计算总内存占用。

#!/bin/bash
PACKAGE_NAME="com.your.package.name"
MONKEY_LOG="monkey_output.log"
HEAP_DIR="./heap_dumps"
mkdir -p $HEAP_DIR

# 启动Monkey后台运行
adb shell monkey -p $PACKAGE_NAME --ignore-timeouts --ignore-crashes --ignore-security-exceptions 50000 > $MONKEY_LOG &
MONKEY_PID=$!

echo "Monkey started with PID: $MONKEY_PID"

# 循环监控内存
while kill -0 $MONKEY_PID 2>/dev/null; do
    TIMESTAMP=$(date +%Y%m%d_%H%M%S)
    
    # 获取当前进程ID
    APP_PID=$(adb shell ps | grep $PACKAGE_NAME | awk '{print $2}')
    
    if [ ! -z "$APP_PID" ]; then
        # 抓取heap dump
        adb shell am dumpheap $APP_PID $HEAP_DIR/dump_${TIMESTAMP}.hprof
        echo "Dumped heap at ${TIMESTAMP}"
        
        # 可选：检查RSS内存大小
        MEM_SIZE=$(adb shell ps | grep $PACKAGE_NAME | awk '{print $6}')
        echo "Current RSS Memory: ${MEM_SIZE} KB"
    fi
    
    sleep 300 # 每5分钟抓一次
done

# 等待Monkey结束
wait $MONKEY_PID
echo "Monkey finished."

拿到 .hprof 文件后，导入Eclipse MAT或Android Studio Profiler。重点查看：

  1. Dominator Tree：按大小排序，看哪些对象占据了最大内存。
  2. Histogram：搜索特定的Service类或Context子类，看实例数量是否异常增多。
  3. GC Roots：点击可疑对象，选择 “Path to GC Roots” -> “Exclude weak/soft references”。如果有一条路径指向了静态变量或者未销毁的Activity，那就是泄漏点。

常见Service内存泄漏场景及修复示例：

  • 场景：Service中启动了Handler，但未在onDestroy中移除回调。

    // ❌ 错误示范
public class LeakyService extends Service {
    private Handler handler = new Handler(Looper.getMainLooper()) {
        @Override
        public void handleMessage(Message msg) {
            // 执行任务
        }
    };


    @Override
    public void onStartCommand(Intent intent, int flags, int startId) {
        handler.sendEmptyMessageDelayed(1, 1000);
        return START_STICKY;
    }


    // 忘记在onDestroy中 handler.removeCallbacksAndMessages(null);
}

  • 修复：

    @Override
public void onDestroy() {
    super.onDestroy();
    if (handler != null) {
        handler.removeCallbacksAndMessages(null);
    }
}

第三步：ANR与卡顿的深度诊断

ANR的本质是主线程在5秒内（Activity为5秒，BroadcastReceiver为10秒，Service为20秒）没有响应输入事件或广播。Monkey的高频操作极易触发ANR。

3.1 利用Trace文件定位主线程阻塞

当Monkey触发ANR时，系统会在 /data/anr/ 目录下生成 trace.txt 文件。我们可以编写脚本自动拉取这些文件。

# 拉取最新的trace文件
adb pull /data/anr/traces.txt ./anr_traces/

打开 traces.txt，你会看到类似这样的结构：

----- pid 12345 at 2023-10-27 10:00:00 -----
Cmd line: com.your.package.name

JNI: CheckJNI is off; workarounds are available; use vm:jni-check for more info.

"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x72a9c1e0 self=0xb4000073d0000000
  | sysTid=12345 nice=-10 cgrp=default sched=0/0 handle=0x72a9c1e0
  | state=S schedstat=( 123456789 123456789 123 ) utm=10 stm=2 core=0 HZ=100
  | stack=0x7ffd12345678-0x7ffd12347678 stackSize=8MB
  | held mutexes=
  kernel: (couldn't read /proc/self/taskstatus)
  native: #00 pc 000000000001a2b8  /system/lib64/libc.so (syscall+28)
  native: #01 pc 00000000002b9c34  /system/lib64/libart.so (art::ConditionVariable::WaitHoldingLocks(art::Thread*)+144)
  native: #02 pc 00000000003c1d56  /system/framework/arm64/boot-framework.oat (Java_android_os_MessageQueue_nativePollOnce__JI+114)
  at android.os.MessageQueue.nativePollOnce(Native method)
  at android.os.MessageQueue.next(MessageQueue.java:326)
  at android.os.Looper.loop(Looper.java:160)
  at android.app.ActivityThread.main(ActivityThread.java:6669)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:544)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:826)

关键分析点：

  1. 状态为 S (Sleeping)：说明主线程在等待某事，通常是I/O操作、锁竞争或 Binder 调用。
  2. 栈顶方法：如果栈顶是 MessageQueue.nativePollOnce，说明主线程空闲，正在等待消息。但如果此时有 BLOCKED 状态的其他线程持有锁，而主线程也在尝试获取该锁，那就是死锁或锁竞争导致的ANR。
  3. Service相关调用：如果在栈中看到 android.app.ActivityManager.getServiceConnectionLocked 或者你的Service类名，说明问题出在服务连接或通信上。

3.2 使用Systrace进行可视化分析

对于非ANR但感觉“卡顿”的情况，Systrace是神器。它可以记录CPU调度、GPU绘制、I/O操作等。

python systrace.py -o trace.html -t 60 sched freq idle am wm gfx view binder_driver hal dalvik res input

在生成的HTML报告中，你可以直观地看到：

  • Jank：UI线程是否有超过16ms的空白区间。
  • Binder调用：Service与Activity之间的跨进程调用是否过于频繁或耗时过长。
  • GC停顿：垃圾回收是否发生在UI绘制期间，导致掉帧。

实战案例：Service轮询导致的UI卡顿

假设有一个Service每秒轮询一次服务器状态，并通过Handler通知UI更新。在Systrace中，你可能会看到每隔1秒，UI线程就被唤醒一次，打断当前的绘制流程，导致帧率波动。

解决方案：

  1. 减少频率：改为事件驱动，只有数据真正变化时才通知UI。
  2. 批量更新：如果必须高频更新，合并多次更新请求，使用 Choreographer.getInstance().postFrameCallback 在下一帧绘制前统一更新UI，而不是立即更新。

第四步：构建自动化闭环测试平台

手动跑Monkey、看Log、导Heap Dump太累了。我们需要将其自动化。这里提供一个基于Python的简单框架思路，用于解析Monkey日志并关联ANR/Crash。

import re
import subprocess
import os

class MonkeyAnalyzer:
    def __init__(self, package_name):
        self.package_name = package_name
        self.monkey_log_path = "monkey_full.log"
        self.anr_dir = "/data/anr/"

    def run_monkey(self, count=10000):
        cmd = [
            "adb", "shell", "monkey",
            "-p", self.package_name,
            "--ignore-timeouts",
            "--ignore-crashes",
            "--ignore-security-exceptions",
            str(count)
        ]
        print(f"Running Monkey: {' '.join(cmd)}")
        # 实际项目中应使用 subprocess.Popen 并实时重定向输出到文件
        result = subprocess.run(cmd, capture_output=True, text=True)
        with open(self.monkey_log_path, 'w') as f:
            f.write(result.stdout)
            f.write(result.stderr)
        print("Monkey finished.")

    def parse_anr(self):
        """解析monkey日志中的ANR关键字"""
        anrs = []
        with open(self.monkey_log_path, 'r') as f:
            lines = f.readlines()
            for i, line in enumerate(lines):
                if "ANR" in line or "Timeout" in line:
                    # 提取上下文
                    context = "".join(lines[max(0, i-5):min(len(lines), i+10)])
                    anrs.append(context)
        return anrs

    def pull_latest_trace(self):
        """拉取最新的trace文件"""
        # 需要先确保设备有权限访问/data/anr
        try:
            subprocess.run(["adb", "pull", f"{self.anr_dir}traces.txt", "./"])
            return True
        except Exception as e:
            print(f"Failed to pull trace: {e}")
            return False

    def analyze(self):
        anr_list = self.parse_anr()
        if anr_list:
            print(f"Found {len(anr_list)} potential ANRs/Crashes:")
            for i, anr in enumerate(anr_list):
                print(f"--- ANR/Crash Sample {i+1} ---")
                print(anr)
            
            if self.pull_latest_trace():
                print("Please check ./traces.txt for detailed stack trace.")
        else:
            print("No obvious ANRs found in Monkey log. Check memory manually.")

if __name__ == "__main__":
    analyzer = MonkeyAnalyzer("com.your.package.name")
    analyzer.run_monkey(5000)
    analyzer.analyze()

第五步：给小朋友也能听懂的总结（最佳实践清单）

好了，技术细节讲完了。为了让我们的团队，包括新入职的实习生（或者家里的小朋友想学编程的大朋友），都能记住这些要点，我把这些复杂的操作简化成几条“黄金法则”：

  1. 不要相信“看起来没问题”：Monkey跑了一小时没崩，不代表明天不会崩。内存泄漏是累积的，就像房间里慢慢堆积的灰尘，平时看不见，大扫除时才吓你一跳。所以，定期抓Heap Dump，看看内存是不是在“只增不减”。

  2. Service要“干净利落”：Service启动时拿到了什么资源（文件句柄、网络连接、Context），结束时一定要还回去。就像去图书馆借书，看完了一定要还，不然图书馆（系统内存）就会爆满。

  3. 主线程是“VIP通道”：主线程只能做快速的事情（画界面、处理点击）。任何耗时的操作（下载、查数据库）都要交给子线程。如果子线程要把结果告诉主线程，要用Handler或LiveData，别直接去碰主线程的UI，否则主线程会被堵死，产生ANR。

  4. 日志是你的朋友：开启StrictMode，开启Verbose日志。当问题发生时，日志会告诉你“谁”在“什么时候”做了“什么事”。不要只盯着崩溃那一行，要看崩溃前的几十行日志，那里藏着线索。

  5. 自动化胜过人工：人眼看不出内存的微小增长，但脚本可以。把Monkey、Heap Dump、Trace分析串成一个自动化流水线，每次代码提交都跑一遍。这才是现代工程化的样子。

结语

集成Monkey进行自动化测试，不仅仅是为了找Bug，更是为了建立一种质量意识。通过监控内存和ANR，我们迫使自己在开发阶段就考虑到生命周期管理、线程调度和资源释放。

这套方案并非一劳永逸，但它提供了一个强大的起点。每一次Monkey的“暴走”，都是对App健壮性的一次压力测试。当你能够从容地解读Heap Dump中的对象引用链，能够从Systrace的波形图中看出UI线程的喘息声时，你就真正掌握了提升App稳定性的钥匙。

现在，拿起你的键盘，配置好StrictMode，启动你的第一个定制化Monkey脚本吧。祝你的App，稳如泰山。

-- 展开阅读全文 --