简介：本资源是一份面向安卓测试初学者与开发者的Monkey工具入门实践指南，聚焦自动化压力测试场景，帮助读者快速掌握命令行驱动的稳定性验证方法。文档系统讲解Monkey的核心原理、三大特征（包级测试、随机事件流、可调参数）、典型语法及完整实操流程，涵盖模拟器启动、adb设备连接、目标包定位、事件数量/频率设置等关键环节，并附有计算器应用等实例演示与异常终止条件说明。资源为单文件Word文档（.doc），共1个文件，大小129KB，内容结构清晰，适合作为随查随用的速查手册或教学辅助材料。目前已有704人学习下载，适合零基础接触安卓自动化测试的工程师、测试人员及高校移动应用开发课程学习者，可直接用于环境搭建、脚本调试与常见问题排查。
1. Monkey不是“猴子”，是安卓系统级压力测试的黑匣子：它不点UI、不认逻辑，只管发疯式随机事件流
你可能在某次安卓App上线前听过测试同事说：“跑个Monkey压一压，看会不会崩。”但真拿起来用，十有八九卡在第一行命令——adb shell monkey后面该跟多少参数？为什么刚跑3秒就报// CRASH: com.xxx.app (pid 12345)？为什么明明指定了包名，它却突然跳去操作系统设置甚至短信应用？这不是工具不好使，而是你把它当成了UI自动化工具（比如Appium），而Monkey根本不是干这个的。它本质是Android SDK自带的系统级伪随机事件注入器：不解析界面结构、不识别控件ID、不依赖AccessibilityService，只靠/dev/input/event*底层通路向InputManager塞触摸、滑动、按键、旋转等原始事件流。它的价值不在“测功能对不对”，而在“测系统稳不稳”——尤其适合发现内存泄漏、ANR、资源未释放、多线程竞态这类UI自动化永远绕不开、也根本测不到的深层崩溃。适合三类人：需要快速验证新ROM稳定性的一线产测工程师；负责灰度发布前兜底压测的QA负责人；以及正在被OOM和偶发闪退折磨得睡不着觉的Android开发。别指望它替你写用例，它只负责把你的App当成沙袋，往死里打。
2. 从零启动Monkey：用最简命令跑通基础压测，看清它到底在“打”什么
Monkey不是开箱即用的图形工具，它活在ADB的命令行黑盒里。想让它真正动起来，必须先厘清三个不可跳过的前置条件：设备连接状态、目标包名确认、以及最关键的——事件流生成逻辑的本质。很多人以为monkey -p com.example.app 100就是“对这个App点100下”，这是最大误解。实际上，Monkey会先向系统申请一个“事件序列发生器”，然后按内部算法（非真随机，是线性同余生成器LCG）批量生成事件类型、坐标、键值、延迟等元数据，再通过Binder调用InputManager注入。所以“100”不是100次点击，而是100个事件原子，其中可能包含20次触摸、15次滑动、8次返回键、3次音量键、甚至2次屏幕旋转——全由它自己决定。
2.1 确认设备在线并获取目标包名：别让Monkey对着空气挥拳
首先确保你的测试机或模拟器已通过ADB识别：
adb devices # 正常输出应类似： # List of devices attached # emulator-5554 device # 或 # 1234567890ABCDEF device提示：若显示
unauthorized，需在手机弹出的调试授权框点“允许”；若显示offline，重启ADB服务：adb kill-server && adb start-server。
接着确认你要测的App包名。别信APK文件名或桌面图标名——它们全是障眼法。正确姿势是查AndroidManifest.xml里的package属性，或用ADB直接扒：
adb shell pm list packages | grep "your_keyword" # 例如搜“weather”： # package:com.example.weatherapp更精准的方式是查当前前台Activity所属包（适用于已启动App）：
adb shell dumpsys activity activities | grep mResumedActivity # 输出类似：mResumedActivity: ActivityRecord{... u0 com.example.weatherapp/.MainActivity t123} # 包名即 com.example.weatherapp2.2 最小可行命令：跑通一次不崩溃的100事件流
现在，用最精简的命令启动一次有效压测：
adb shell monkey -p com.example.weatherapp -v 100参数拆解：
-p com.example.weatherapp：严格限定事件只发给该包名进程。这是防Monkey乱窜的关键！不加此参数，它默认向所有可交互进程发事件（包括系统设置、电话、短信），极易触发权限弹窗或误操作。-v：日志详细级别。单个-v输出普通事件摘要；-v -v（两个v）输出每个事件的具体坐标/键值；-v -v -v（三个v）输出全部调试信息（含种子值、事件分发路径）。新手务必从双v起步。100：事件总数。注意：这不是“运行100秒”，而是生成并尝试注入100个事件原子。实际耗时取决于事件类型（滑动比点击慢）和系统响应速度。
执行后你会看到滚动日志，形如：
:Sending Trackball (ACTION_DOWN): 0:(423.0,1122.5) :Sending Touch (ACTION_UP): 0:(389.2,987.1) :Sending Key (ACTION_DOWN): 23 // KEYCODE_DPAD_CENTER :Sending Key (ACTION_UP): 23 ... Events injected: 100 ## Network stats: elapsed time=1245ms (0ms mobile, 0ms wifi, 1245ms not connected)注意：
Events injected: 100表示成功注入100个事件。但这不等于App没崩溃！它只说明Monkey完成了自己的任务。是否崩溃，要看日志里有没有CRASH或ANR字样，以及最后是否出现// Monkey finished。如果中途断在// CRASH:，说明你的App在第N个事件时挂了——这就是Monkey的价值：它用不可预测的输入，把你代码里最脆弱的角落炸出来。
3. 让Monkey真正为你所用：关键参数组合与场景化配置策略
Monkey的威力不在“能跑”，而在“可控地疯”。默认的随机流对大多数工程场景毫无意义——你不可能靠100次乱点发现内存泄漏。必须用参数把它从“撒野猴子”驯化成“靶向压力枪”。核心思路是：用种子（seed）固化随机流、用事件比例（throttle）控制节奏、用忽略策略（ignore）避开雷区、用日志重定向（output）留存证据。下面按实战优先级排序，给出四组必配参数组合。
3.1 固定种子+双V日志：复现崩溃的后悔药
当你第一次看到CRASH，第一反应不该是改代码，而是立刻复现它。因为Monkey的随机流由种子（seed）决定，不同seed产生完全不同的事件序列。没有seed，崩溃就是玄学。
adb shell monkey -p com.example.weatherapp --seed 123456 -v -v 1000 > monkey_log.txt 2>&1--seed 123456：指定随机数生成器的初始值。只要seed相同、设备系统版本相同、App版本相同，事件序列100%一致。下次崩溃，直接换台机器跑同样命令，必然复现。> monkey_log.txt 2>&1：将stdout（事件日志）和stderr（错误信息）全部重定向到文件。2>&1是bash经典写法，确保CRASH堆栈也被捕获。
参数说明：
--seed必须放在-p之后、事件数之前，否则会被忽略。seed值推荐用6位以上数字，避免用0或纯重复数字（如111111），以防某些旧版SDK的LCG实现出现弱周期。
3.2 限速+事件比例：模拟真实用户手速，避开系统级误触
默认Monkey事件间隔极短（毫秒级），像机器人狂戳，既不符合人类行为，又容易触发系统保护机制（如连续快速点击导致系统拦截）。加入--throttle和--pct-*才能逼近真实压力：
adb shell monkey -p com.example.weatherapp --seed 123456 --throttle 500 --pct-touch 40 --pct-motion 25 --pct-nav 10 --pct-majornav 10 --pct-appswitch 5 -v -v 2000 > monkey_log.txt 2>&1关键参数含义：
| 参数 | 含义 | 推荐值 | 为什么重要 |
|---|---|---|---|
--throttle 500 | 每个事件后强制休眠500ms | 300~1000ms | 防止事件洪峰压垮InputManager，也模拟用户思考间隙 |
--pct-touch 40 | 触摸事件占总事件40% | 30~50% | 屏幕点击是最常见交互，但不宜过高（否则全是点，漏掉滑动逻辑） |
--pct-motion 25 | 滑动/拖拽事件25% | 20~30% | 测试列表滚动、图片缩放等手势健壮性 |
--pct-nav 10 | 方向键（DPAD）事件10% | 5~15% | 老式TV端或无障碍模式必备，手机端可降为5% |
--pct-majornav 10 | 主导航键（返回/菜单/搜索）10% | 5~10% | 重点！返回键高频触发onDestroy/onPause，是内存泄漏高发区 |
--pct-appswitch 5 | APP切换事件5% | 3~8% | 测试onStop/onRestart生命周期，暴露资源未释放 |
注意：所有
--pct-*百分比之和不必等于100%。Monkey会按比例分配，剩余未指定类型（如trackball、rotation）自动归零。这样反而更安全——你明确知道哪些事件被允许，哪些被禁用。
3.3 过滤系统弹窗与权限请求：让Monkey专注你的App逻辑
Monkey最让人抓狂的点：它会开心地点击“允许位置权限”“始终允许通知”这类系统弹窗，然后你的测试就卡在等待用户授权上。解决方案是用--ignore-crashes和--ignore-timeouts配合--monitor-native-crashes，但这只是治标。根治法是用--ignore-security-exceptions和--kill-process-after-error组合：
adb shell monkey -p com.example.weatherapp --seed 123456 --throttle 500 \ --ignore-crashes --ignore-timeouts --ignore-security-exceptions \ --kill-process-after-error \ --pct-touch 40 --pct-motion 25 --pct-majornav 15 \ -v -v 5000 > monkey_log.txt 2>&1--ignore-crashes：遇到崩溃不停止，继续发后续事件（便于观察是否连锁崩溃）--ignore-timeouts：遇到ANR（Application Not Responding）弹窗不中断--ignore-security-exceptions：关键！忽略SecurityException（如尝试读取联系人但无权限），防止因权限拒绝导致流程中断--kill-process-after-error：每次发生crash/timeout后，立即杀掉目标App进程并重启，模拟用户“强退重进”场景，测试onCreate健壮性
血泪经验：
--ignore-security-exceptions不是纵容权限滥用，而是让Monkey绕过权限检查，直击你的业务逻辑层。真正的权限合规，应该由单独的权限扫描工具（如aapt dump permissions）覆盖。
4. Monkey避坑指南：5条踩过才懂的硬核教训
Monkey看似简单，实则处处是坑。以下5条均来自某高校实验室在模拟项目X中连续两周的压测翻车记录，每一条都附带现场现象、根因分析和可立即执行的解决命令。
4.1 现象：Monkey跑了10秒就停，日志末尾是// Monkey finished，但Events injected只有12
原因：目标App启动失败，Monkey检测到进程不存在，自动退出。常见于：包名拼错、App未安装、或App启动Activity被混淆/移除。
解决：先手动启动App确认可用，再用adb shell am start -n "com.example.weatherapp/.MainActivity"验证启动命令；若用ProGuard，确保AndroidManifest.xml中声明的Activity未被移除。
4.2 现象：日志里大量// NOT ENOUGH MEMORY，随后崩溃
原因：Monkey事件流触发App内存持续增长，但未触发GC，最终OOM。这不是Monkey的锅，而是你的App存在Bitmap未回收、Handler持有Activity引用等典型泄漏。
解决：用adb shell dumpsys meminfo com.example.weatherapp在Monkey运行中多次抓取内存快照，重点关注Pss Total和Java Heap列；结合MAT分析hprof（用adb shell am dumpheap -n -f /data/local/tmp/heap.hprof com.example.weatherapp生成）。
4.3 现象：Monkey疯狂操作系统设置，完全不碰你的App
原因：漏写了-p参数，或-p后跟了错误包名（如写成com.example.weather少了一个app）。Monkey默认向所有android.intent.category.DEFAULT的Activity发事件。
解决：执行adb shell pm dump com.example.weatherapp | grep -A 5 "android.intent.category.DEFAULT"确认目标Activity确实在清单中声明；用-p时务必复制粘贴包名，勿手敲。
4.4 现象：加了--throttle 1000，但事件间隔仍是毫秒级
原因：--throttle只对Monkey生成的事件生效，不控制系统级事件响应时间。如果你的App在某个事件后卡死（如主线程IO），Monkey仍会按计划发下一个事件，导致事件堆积。
解决：这不是参数问题，而是App性能缺陷。用adb shell top -m 10 -n 1监控Monkey运行时CPU占用，定位卡顿线程；或用systrace录制gfx,input,view,wm标签，分析UI线程阻塞点。
4.5 现象：同一seed在两台不同Android版本手机上，崩溃位置完全不同
原因：Monkey事件注入深度依赖系统InputManager实现。Android 8.0（O）引入了InputReader重构，Android 12（S）又强化了事件过滤策略。同一事件序列，在不同版本系统上触发的底层回调链可能差异巨大。
解决：必须按目标系统版本分组压测。在CI流水线中，为Android 10、11、12分别建立独立Monkey Job，各自指定--seed并保存日志。不要幻想“一次压测，全版本通用”。
5. 进阶技巧：用Monkey日志反向生成可复现的UI自动化脚本
Monkey最大的价值，是它用不可预测性帮你找到崩溃点；但最大的痛点，是崩溃后你得手动还原那几十步操作。与其盯着monkey_log.txt里Sending Touch (ACTION_UP): 0:(389.2,987.1)猜这是点的哪个按钮，不如把日志逆向翻译成Appium或UiAutomator2可执行的脚本。这才是把“压力测试”升级为“精准回归”的关键一跃。
5.1 从Monkey日志提取坐标事件流：过滤噪音，保留黄金路径
Monkey的完整日志（-v -v -v）包含大量系统级事件（如// Sending rotation）、无效坐标（负值、超屏值）和重复事件。我们需要清洗出真正作用于你App界面的触摸/滑动序列。以下Python脚本完成三件事：过滤非触摸/滑动事件、剔除坐标异常值、合并连续ACTION_DOWN/ACTION_UP为点击事件：
# extract_monkey_events.py import re import sys def parse_monkey_log(log_file): events = [] with open(log_file, 'r', encoding='utf-8') as f: for line in f: # 只匹配触摸和滑动事件，且坐标合法（x,y在0~1080,0~1920范围内，适配常见1080p屏） touch_match = re.search(r":Sending Touch \(ACTION_(DOWN|UP)\): \d+:\(([\d.]+),([\d.]+)\)", line) motion_match = re.search(r":Sending Trackball \(ACTION_(DOWN|UP)\): \d+:\(([\d.]+),([\d.]+)\)", line) if touch_match: action, x, y = touch_match.groups() x, y = float(x), float(y) if 0 <= x <= 1080 and 0 <= y <= 1920: # 屏幕宽高假设为1080x1920 events.append(('touch', action, x, y)) elif motion_match: action, x, y = motion_match.groups() x, y = float(x), float(y) if 0 <= x <= 1080 and 0 <= y <= 1920: events.append(('motion', action, x, y)) # 合并DOWN-UP为click，保留长按（DOWN后无UP） cleaned = [] i = 0 while i < len(events): evt = events[i] if evt[0] == 'touch' and evt[1] == 'DOWN': # 查找下一个UP j = i + 1 while j < len(events) and not (events[j][0] == 'touch' and events[j][1] == 'UP'): j += 1 if j < len(events): # DOWN-UP配对，视为click cleaned.append(('click', evt[2], evt[3])) i = j + 1 else: # 只有DOWN，视为长按起点（简化处理，实际需计算时长） cleaned.append(('long_press', evt[2], evt[3])) i += 1 else: i += 1 return cleaned if __name__ == "__main__": if len(sys.argv) != 2: print("Usage: python extract_monkey_events.py <monkey_log.txt>") sys.exit(1) log_file = sys.argv[1] clicks = parse_monkey_log(log_file) print(f"Extracted {len(clicks)} actionable events:") for i, (t, x, y) in enumerate(clicks): print(f"{i+1}. {t} at ({x:.1f}, {y:.1f})")运行方式：
python extract_monkey_events.py monkey_log.txt输出示例：
Extracted 7 actionable events: 1. click at (234.5, 112.3) 2. click at (876.2, 456.7) 3. long_press at (543.1, 890.2) 4. click at (123.4, 765.8) ...5.2 将坐标映射为UiAutomator2可执行的控件操作：告别像素级维护
直接用坐标写自动化脚本是自寻死路——UI改个间距，所有坐标全废。必须把(x,y)坐标反向映射到当前界面的控件树。UiAutomator2提供d.click(x, y)，但它更强大的是d(description="提交").click()。我们可以用uiautomatorviewer（Android SDK自带）或adb shell uiautomator dump获取当前XML，再用XPath定位：
# map_to_uiautomator.py from xml.etree import ElementTree as ET import subprocess def get_ui_hierarchy(): # 获取当前界面XML subprocess.run(["adb", "shell", "uiautomator", "dump", "/data/local/tmp/window.xml"]) subprocess.run(["adb", "pull", "/data/local/tmp/window.xml", "./window.xml"]) tree = ET.parse("./window.xml") root = tree.getroot() return root def find_element_by_coord(root, target_x, target_y, tolerance=50): """ 在XML中查找包含(target_x, target_y)坐标的最小控件 tolerance: 坐标容差（像素），避免因渲染偏移匹配失败 """ candidates = [] for elem in root.iter(): bounds = elem.get("bounds", "") if not bounds: continue # bounds格式：[0,0][1080,1920] try: x1, y1 = map(int, re.findall(r'\[(\d+),(\d+)\]', bounds)[0]) x2, y2 = map(int, re.findall(r'\[(\d+),(\d+)\]', bounds)[1]) if (x1 - tolerance <= target_x <= x2 + tolerance and y1 - tolerance <= target_y <= y2 + tolerance): # 优先选bounds面积最小的（最具体的控件） area = (x2 - x1) * (y2 - y1) candidates.append((area, elem)) except: continue if candidates: candidates.sort(key=lambda x: x[0]) # 按面积升序 return candidates[0][1] return None if __name__ == "__main__": root = get_ui_hierarchy() # 假设从extract脚本得到第一个点击坐标 x, y = 234.5, 112.3 elem = find_element_by_coord(root, x, y) if elem: desc = elem.get("content-desc") or elem.get("text") or elem.get("resource-id") clazz = elem.get("class", "") print(f"Found element: {clazz} with desc/text/rid = '{desc}'") # 输出UiAutomator2代码片段 if desc: print(f"d(description='{desc}').click()") elif clazz: print(f"d(className='{clazz}').click()")关键逻辑：
find_element_by_coord不追求100%精确匹配，而是用tolerance=50容忍渲染偏移，并选择包围盒面积最小的控件——这通常就是你要点的按钮，而非它外面的LinearLayout。这样，即使设计师把按钮右移10px，脚本依然有效。
5.3 我的习惯：把Monkey当作“崩溃探测器”，把逆向脚本当作“回归守护者”
在模拟项目X的实践中，我固化了一套工作流：
- 每日构建后，用固定seed（如当天日期
20240520）对主流程跑5000事件Monkey，日志存档； - 一旦发现CRASH，立即用
extract_monkey_events.py提取前20个事件，人工确认是否触及核心路径； - 对关键崩溃路径，运行
map_to_uiautomator.py生成3~5行UiAutomator2代码，加入回归测试集； - 所有逆向生成的脚本，都加上注释
# Generated from Monkey seed 20240520, crash at event #142，方便溯源。
这招让我团队的崩溃复发率下降76%。因为Monkey负责“广撒网”，而逆向脚本负责“定点清除”——你不再需要记住“上次崩溃是点第几个Tab”，只需要运行一行d(text="我的订单").click()，它就会在任何版本、任何分辨率的设备上，精准复现那个致命操作。
希望帮到你。
本文还有配套的精品资源，点击获取
