1. ADB事件模拟：从基础命令到实战脚本
如果你正在和安卓设备打交道，无论是做自动化测试、批量操作，还是远程控制，ADB（Android Debug Bridge）绝对是你绕不开的瑞士军刀。它最核心的魅力之一，就是能模拟几乎所有的物理交互事件：点击、滑动、按键、输入文字。这听起来像是自动化脚本的基石，但很多朋友在实际操作时，往往止步于几个零散的adb shell input命令，遇到复杂场景就无从下手。
我处理过大量需要批量操作手机的场景，从简单的应用安装卸载，到复杂的UI自动化流程编排。我发现，真正高效地使用ADB事件模拟，远不止记住几个命令那么简单。它涉及到对设备坐标系的精准理解、对事件序列的合理编排、对异常情况的稳定处理，以及如何将零散命令组织成可维护的脚本。今天，我就结合自己的实战经验，把这套“组合拳”拆解清楚，让你不仅能“点”得准，还能“动”得稳，最终构建出健壮的自动化流程。
2. 核心原理与基础命令全解析
在深入实战之前，我们必须先理解ADB事件模拟的底层逻辑。ADB本身是一个客户端-服务器架构的工具，我们通过电脑上的命令行发送指令，ADB服务器与设备上的ADB守护进程通信，最终由系统层面的input服务来执行模拟操作。这整个过程，核心都围绕着adb shell input这个命令展开。
2.1 Input命令：一切模拟的源头
input命令是安卓系统内部的一个工具，ADB通过shell调用它。它的功能可以概括为向系统注入各种输入事件。其基本语法结构是：
adb shell input [source] <command> [arg...]其中[source]可以指定输入源（如触摸屏、键盘、鼠标），但通常省略，使用默认值。我们最需要掌握的是以下几个<command>：
tap <x> <y>: 模拟在屏幕坐标(x, y)处的一次触摸点击。这是最常用的操作。swipe <x1> <y1> <x2> <y2> [duration(ms)]: 模拟从点(x1, y1)滑动到点(x2, y2)。可选的duration参数表示滑动过程的耗时（毫秒），默认值因系统而异，明确指定可以控制滑动的速度。keyevent <keycode>: 模拟按下物理按键。每个按键都有一个唯一的键值码，例如KEYCODE_HOME对应3，KEYCODE_BACK对应4。text <string>: 模拟输入文本。注意，它直接将字符串注入到当前焦点所在输入框，不能用于输入非ASCII字符（如中文）或某些特殊符号，除非设备已切换到对应的输入法。
2.2 坐标系统：精准操作的基石
所有触摸事件（tap,swipe）都依赖于屏幕坐标。这里有一个关键陷阱：input命令使用的坐标是基于设备物理屏幕分辨率的绝对坐标，与当前屏幕旋转方向无关。
例如，一台手机屏幕分辨率为1080x2340（竖屏）。在竖屏状态下，坐标原点(0,0)在屏幕左上角，(1079, 2339)在右下角。当你将手机旋转为横屏时，系统UI会自适应，但adb shell input tap 100 200依然会点击物理屏幕上(100, 200)的位置，这个位置在横屏UI上可能完全不对应你想要的按钮。
重要提示：在进行任何触摸操作前，务必先通过
adb shell wm size命令获取设备的物理分辨率。你的所有坐标计算都应基于这个值。UI自动化框架（如UIAutomator）提供的基于控件的坐标通常是稳定的，但纯ADB操作需要自己处理坐标转换。
2.3 键值码与文本输入的局限
keyevent命令非常强大，可以模拟电源键、音量键、Home键、返回键等。常用的键值码可以通过adb shell input keyevent命令查询，或者查阅安卓官方文档。例如，adb shell input keyevent 26是电源键，66是回车键。
text命令的局限性需要特别注意。它相当于快速输入一串字符，但不触发输入法候选词选择。对于中文输入，通常的作法是：先用tap点击输入框获取焦点，然后用keyevent切换输入法到英文状态（如果需要），最后用text输入。复杂的文本可能需要拆解成多次text输入和keyevent事件（如空格、回车）。
3. 实战进阶：从单次命令到复杂脚本
掌握了基础命令，就像拿到了乐高积木的零件。接下来，我们要搭建出有用的结构。直接写一长串adb shell命令效率低下且难以维护，我们需要脚本化。
3.1 Shell脚本封装：实现可复用的操作模块
将常用的操作序列封装成Shell函数或脚本，是提升效率的第一步。下面是一个简单的Bash脚本示例，它定义了基本操作函数：
#!/bin/bash # 定义设备序列号，多设备时有用 DEVICE_SERIAL="" ADB_CMD="adb" if [ -n "$DEVICE_SERIAL" ]; then ADB_CMD="adb -s $DEVICE_SERIAL" fi # 函数：点击 function tap() { local x=$1 local y=$2 $ADB_CMD shell input tap $x $y sleep 0.5 # 操作后等待，避免UI未响应 } # 函数：滑动 function swipe() { local x1=$1 local y1=$2 local x2=$3 local y2=$4 local duration=${5:-500} # 默认滑动500毫秒 $ADB_CMD shell input swipe $x1 $y1 $x2 $y2 $duration sleep 0.8 } # 函数：按键 function keyevent() { local code=$1 $ADB_CMD shell input keyevent $code sleep 0.3 } # 函数：输入文本 function input_text() { local text=$1 $ADB_CMD shell input text "$text" sleep 0.5 } # 使用示例：解锁屏幕（假设滑动解锁） echo "正在解锁屏幕..." swipe 500 1500 500 500 1000 # 从底部中间滑到顶部中间 sleep 1 tap 540 1200 # 点击输入密码区域（示例坐标） input_text "123456" keyevent 66 # 回车键确认这个脚本提供了几个关键实践：
- 设备序列号管理：支持多设备连接时指定目标。
- 操作后等待（Sleep）：这是自动化稳定的生命线。UI响应需要时间，立即执行下一条命令很可能失败。等待时间需要根据设备性能和当前应用负载进行调试。
- 函数化：使主流程清晰可读。
3.2 坐标的动态获取：告别硬编码
硬编码坐标是脚本的“死刑”。设备分辨率一变，脚本就废了。我们需要动态获取坐标。有两种常见思路：
思路一：结合UIAutomator Dump虽然纯ADB不直接提供元素定位，但我们可以用adb shell uiautomator dump获取当前窗口的UI层级XML，然后解析出目标元素的bounds属性（[x1,y1][x2,y2]），计算中心点坐标。
# 获取UI dump到设备 adb shell uiautomator dump /sdcard/window_dump.xml # 拉取到电脑 adb pull /sdcard/window_dump.xml . # 然后使用grep、awk或Python/XML解析器来查找元素并计算坐标这个过程可以封装成一个函数，根据元素文本或resource-id来查找坐标。这更适合于知道UI结构的自动化测试。
思路二：手动录制与校准对于固定流程的简单任务，可以手动录制坐标。
- 开启开发者选项中的“指针位置”。
- 手动操作一遍流程，记录下每个点击和滑动位置的坐标。
- 将这些坐标按比例转换为脚本中的变量。例如，基于
wm size获取的分辨率，计算坐标百分比。
SCREEN_WIDTH=1080 SCREEN_HEIGHT=2340 # 假设“确定”按钮在屏幕(80%, 90%)的位置 TAP_OK_X=$(($SCREEN_WIDTH * 80 / 100)) TAP_OK_Y=$(($SCREEN_HEIGHT * 90 / 100)) tap $TAP_OK_X $TAP_OK_Y这种方式在应用UI布局稳定时非常有效。
3.3 复杂交互序列：以自动化登录为例
让我们设计一个自动化登录某应用的脚本。假设流程是：点击登录按钮 -> 输入用户名 -> 输入密码 -> 勾选协议 -> 点击登录。
#!/bin/bash source ./adb_functions.sh # 引入前面定义的基础函数库 # 步骤1: 启动应用 (假设已知主Activity) $ADB_CMD shell am start -n com.example.app/.MainActivity sleep 3 # 等待应用启动 # 步骤2: 点击“登录”入口 (坐标需预先获取或解析) tap 900 200 sleep 2 # 步骤3: 输入用户名 tap 200 600 sleep 1 input_text "my_username" sleep 1 # 步骤4: 切换到密码输入框 (可以按TAB键，或直接点击坐标) keyevent 61 # KEYCODE_TAB sleep 1 input_text "MyPassw0rd!" sleep 1 # 步骤5: 点击“同意协议”复选框 (可能是一个小的点击区域) tap 100 850 sleep 1 # 步骤6: 点击最终的“登录”按钮 tap 540 1000 sleep 5 # 等待登录网络请求完成 echo “登录流程执行完毕。”这个脚本体现了操作链和等待策略。每个关键操作后都有sleep，等待时间根据实际响应调整。对于网络请求等不确定时长的步骤，等待时间要更长，或者加入简单的循环检测（例如，检测屏幕是否出现“登录成功”的特定元素或颜色）。
4. 高级技巧与稳定性优化
当脚本从实验室走向真实环境，你会遇到各种意外。稳定性优化至关重要。
4.1 错误处理与重试机制
基本的Shell脚本缺乏异常处理。我们可以为关键操作添加重试逻辑。
function tap_with_retry() { local x=$1 local y=$2 local max_retry=3 local retry_count=0 while [ $retry_count -lt $max_retry ]; do tap $x $y sleep 2 # 这里可以加入一个验证步骤，例如检查是否跳转到预期页面 # 如果验证成功，break跳出循环 # 假设我们用一个简单的检查：判断屏幕是否出现某个特征像素颜色（需借助adb shell screencap和dd） # 这里简化处理，仅作为示例逻辑 if [ $? -eq 0 ]; then # 假设tap命令总是成功，实际应验证操作效果 echo "点击成功！" return 0 fi echo "点击未达到预期，第$((retry_count+1))次重试..." ((retry_count++)) done echo "点击失败，已达最大重试次数。" return 1 }更高级的做法是，结合adb shell getevent或screencap进行结果验证。
4.2 状态检测与条件执行
优秀的脚本不是机械执行命令，而是能感知设备状态。
- 检测屏幕状态：
adb shell dumpsys power | grep "mScreenOn"可以判断屏幕是否点亮。 - 检测当前应用：
adb shell dumpsys window | grep mCurrentFocus可以获取当前前台应用的Activity。 - 检测网络：
adb shell ping -c 1 8.8.8.8可以检查网络连通性。
根据这些状态，决定脚本的执行路径。例如，如果屏幕关闭，先执行keyevent 26点亮屏幕，再执行滑动解锁。
4.3 性能与兼容性考量
- 操作间隔：
sleep时间是双刃剑。太短导致失败，太长降低效率。对于不同性能的设备（千元机 vs 旗舰机），需要不同的等待策略。可以考虑动态等待，例如在点击后，循环检测直到某个条件满足（如图标出现），最多等待N秒。 - 分辨率适配：如果你的脚本需要在不同分辨率的设备上运行，必须将所有坐标转换为比例。在脚本开头获取
wm size，然后所有坐标都基于此比例计算。 - ADB连接稳定性：长时间运行脚本，ADB连接可能断开。脚本开头可以加入连接检查
adb devices，并尝试重新连接。
5. 常见问题排查与实战心得
即使准备充分，坑还是少不了。下面是一些典型问题和我总结的排查思路。
5.1 命令执行无反应或报错
| 问题现象 | 可能原因 | 排查步骤 |
|---|---|---|
adb shell input命令执行后无任何效果 | 1. 屏幕未点亮。 2. 坐标超出屏幕范围。 3. 当前应用不响应输入事件（如锁屏界面特殊处理）。 | 1. 检查屏幕状态并点亮。 2. 使用 adb shell getevent -l监听触摸事件，手动点击屏幕，看输出的坐标范围，验证你的坐标是否有效。3. 尝试先切换到主界面 ( keyevent 3) 再操作。 |
报错error: device offline或device not found | ADB连接断开或设备未授权。 | 1. 执行adb devices查看设备状态。2. 重新插拔USB线或重启ADB服务 ( adb kill-server && adb start-server)。3. 检查设备屏幕是否弹出“允许USB调试”的授权框。 |
input text输入内容乱码或失败 | 1. 输入法问题。 2. 文本包含Shell特殊字符。 | 1. 先切换输入法到英文状态（可能需要多次keyevent 62切换）。2. 对于复杂文本，用单引号包裹 input text 'my_text$'，或将文本写入文件再用adb shell input text "$(cat file.txt)"。 |
swipe滑动速度过快或过慢 | 未指定duration参数，使用系统默认值。 | 明确指定duration参数（单位毫秒）。例如快速滑动用100ms，慢速精细滑动用2000ms。 |
5.2 坐标不准的深度排查
这是最常见的问题。除了之前提到的分辨率问题，还有两个“隐形杀手”：
- 屏幕密度与导航栏：有些设备的坐标系统可能包含了虚拟导航栏或状态栏的区域。确保你获取的
wm size是可用显示区域。可以尝试获取wm size和wm density综合判断。 - 多点触控干扰：极少数情况下，系统可能误触发了多点触控。确保你的脚本是串行执行，没有并发发送触摸事件。
终极调试大法：在脚本中插入screencap命令，将关键步骤前后的屏幕截图拉取到电脑查看，直观判断点击位置是否正确。
adb exec-out screencap -p > step1_before_tap.png adb shell input tap 500 500 sleep 1 adb exec-out screencap -p > step2_after_tap.png5.3 实战心得与建议
- 从简单到复杂：不要一开始就写上百行的复杂脚本。先验证单个命令（如
tap）是否工作，然后组合两三个命令，逐步扩展。 - 日志是生命线：在脚本中大量使用
echo输出当前执行到的步骤和关键变量（如坐标）。这能在失败时快速定位问题点。 - 准备“逃生舱”：在脚本开头或循环中，监听一个特定的按键组合（如电脑上按
Ctrl+C），以便随时中断可能出错的自动化流程。可以在脚本中检查一个标志文件是否存在来实现。 - 考虑使用更专业的工具：如果项目复杂度高，频繁需要元素定位、图像识别、逻辑判断，纯ADB Shell脚本会变得难以维护。此时应考虑使用Auto.js（基于JavaScript，可在设备端运行）、Appium（功能全面，生态好）或Python + uiautomator2等更专业的UI自动化框架。ADB事件模拟可以作为这些框架底层能力的补充，或在轻量级场景下独立使用。
ADB的输入事件模拟是一个“入门易，精通难”的技能。它要求你对设备交互有微观层面的理解，又要有宏观层面的流程设计能力。希望这篇从原理到实战、从命令到脚本、从操作到排错的长文，能帮你把这套工具用得更加得心应手。记住，稳定可靠的自动化，永远建立在细致的异常处理和充分的状态验证之上。
