1. 为什么“同时控制多台Android手机”不是简单起个多个Appium Server就完事很多人第一次想批量操作安卓设备时脑子里蹦出来的方案特别朴素一台手机配一个Appium ServerPython里开几个线程每个线程连一个server——听起来严丝合缝实测却十有八九在第三台设备上崩掉。我去年帮一家做ASO测试的团队搭自动化矩阵时就是被这个“朴素逻辑”坑了整整三天。他们用的是三台Pixel 4a系统版本都是Android 12USB线全插在一台i7-10700K主机上结果跑起来不是adb server莫名重启就是某个driver初始化卡死在waitForDevice阶段日志里反复出现AdbCommandRejectedException: device offline但adb devices明明显示三台都online。问题不在代码而在底层资源争抢。Appium本质是adb的封装层而adb server本身是单进程、单端口默认5037、全局共享的。你起三个Appium Server实例它们全在往同一个adb server发指令更麻烦的是当多个进程同时调用adb -s serial shell input tap x y时adb server内部的socket连接池和设备句柄管理会进入竞争态——尤其在高频率点击或频繁install/uninstall场景下某台设备的adb daemonadbd进程会被强制kill重连导致device unauthorized或device not found这类看似随机、实则必现的错误。这还不是最隐蔽的坑。很多教程教你在不同端口启动Appium Serverappium -p 4723、appium -p 4724、appium -p 4725然后让Python分别连。但Appium Server启动时默认仍会复用本机的adb server它并不关心你监听哪个HTTP端口——所有请求最终都汇入同一个adb入口。真正要解耦必须让每台设备走独立的adb server实例而标准adb不支持多实例。这就逼着你必须绕过adb server直接与每台设备的adbd进程建立TCP直连或者用更底层的方案隔离adb上下文。所以“同时控制多台”这件事核心从来不是Python怎么写并发而是如何为每台物理设备构建互不干扰的底层通信通道。它涉及adb架构理解、端口映射原理、Appium session生命周期管理、以及Python多线程/多进程模型与设备驱动层的匹配度。下面我会从设备准备、服务隔离、驱动配置、并发控制四个硬核环节把这套方案拆到螺丝钉级别——不是告诉你“能行”而是让你清楚每一行命令背后在操作系统里发生了什么。2. 设备层准备USB连接不是插上线就完事得让每台设备拥有唯一且稳定的通信身份很多人以为adb devices能列出设备就代表设备已准备好。错。adb devices只反映adb server当前看到的设备快照它不保证设备在后续操作中持续在线、不被系统抢占、不因USB供电波动掉线。批量控制场景下设备稳定性是整个链路的基石。我见过太多案例三台设备跑着跑着其中一台突然消失adb devices里只剩两行但dmesg | grep usb一查发现是USB控制器过热导致端口reset——这根本不是Appium的问题而是硬件层没兜住。2.1 物理连接必须满足三个硬性条件第一绝对禁止USB集线器尤其是无源集线器。我们曾用一款廉价7口USB3.0集线器连四台Redmi Note 11跑满10分钟必掉一台。换成带独立供电的StarTech USB3.0 4口集线器后连续72小时无掉线。原因很简单安卓设备在ADB调试模式下USB枚举需要稳定500mA电流集线器供电不足会导致设备周期性断连而adb server对这种瞬时断连极其敏感常表现为device unauthorized循环。第二每台设备必须使用独立USB控制器。现代主板通常有2~3个xHCI USB控制器每个控制器管理2~4个物理端口。如果把四台设备全插在同一个控制器下的端口比如全插在机箱前面板它们共用同一套DMA通道和中断号高并发ADB指令会引发中断风暴。正确做法是用lsusb -t查看USB拓扑找到不同controller下的端口把设备分散插接。例如# 查看USB树状结构Linux $ lsusb -t /: Bus 04.Port 1: Dev 1, Classroot_hub, Driverxhci_hcd/4p, 10000M |__ Port 1: Dev 2, If 0, ClassHub, Driverhub/4p, 10000M |__ Port 1: Dev 3, If 0, ClassVendor Specific Class, Driver, 480M # 设备A /: Bus 03.Port 1: Dev 1, Classroot_hub, Driverxhci_hcd/4p, 480M |__ Port 2: Dev 4, If 0, ClassVendor Specific Class, Driver, 480M # 设备B这里Bus 04和Bus 03就是两个独立控制器设备A和B应分属不同bus。第三必须关闭所有可能干扰ADB的后台服务。Windows上杀掉SmartScreen、Windows Defender实时防护它们会扫描adb.exe的DLL加载行为macOS上禁用Gatekeeper对adb二进制的验证Linux上确保没有usbmuxd进程iOS工具冲突。最狠的一招在设备端关掉“USB调试安全设置”里的“通过网络调试”选项——这个功能会偷偷启用adb over TCP与本地USB通道争抢端口。2.2 设备序列号serial必须固化拒绝动态分配adb devices输出的serial形如R58R909J29W但它可能变化刷机、恢复出厂、甚至拔插USB线都可能触发serial重生成。批量脚本一旦依赖这个字符串下次运行就全挂。解决方案是绑定设备的USB物理路径。在Linux上每台设备对应唯一的/sys/bus/usb/devices/路径。例如# 查看设备物理路径 $ adb -s R58R909J29W shell getprop ro.serialno R58R909J29W $ readlink /sys/bus/usb/devices/*/product | grep -B1 R58R909J29W /sys/bus/usb/devices/1-1.2/product1-1.2就是该设备在USB总线上的物理地址。我们可以写个脚本根据物理路径反查serial#!/bin/bash # get_serial_by_path.sh PATH$1 # e.g., 1-1.2 for d in /sys/bus/usb/devices/$PATH; do if [ -f $d/product ]; then SERIAL$(adb devices | grep -o ^[^[:space:]]*.*$PATH | awk {print $1}) echo $SERIAL exit 0 fi done这样即使设备serial变了只要它还插在1-1.2这个口脚本就能准确定位。Python里调用它即可import subprocess def get_serial_by_usb_path(usb_path): result subprocess.run( [./get_serial_by_path.sh, usb_path], capture_outputTrue, textTrue ) return result.stdout.strip() # 使用 serial_a get_serial_by_usb_path(1-1.2) serial_b get_serial_by_usb_path(2-3.1)提示Windows/macOS没有原生/sys/bus/usb但可用usb-devicesLinux/macOS或PowerShellGet-PnpDevice -Class USBWindows获取类似信息。关键是建立“物理端口→设备”的强绑定而非依赖易变的serial字符串。2.3 ADB守护进程adbd必须为每台设备定制化配置标准adb server是单实例但我们可以为每台设备启动独立的adb server进程监听不同端口并强制其只管理指定设备。这是实现真隔离的核心。原理adb client如Appium通过环境变量ANDROID_ADB_SERVER_PORT指定连接哪个adb server。我们为设备A启动adb -P 5038 -L tcp:5038 fork-server server --reply-fd 3为设备B启动adb -P 5039 -L tcp:5039 fork-server server --reply-fd 3然后在Appium启动时通过--adb-port参数指定各自对应的adb server端口。但有个致命细节adb fork-server命令在较新版本34.0.0才支持-L参数指定监听地址。旧版adb需用socat做端口转发# 启动独立adb server旧版adb socat TCP-LISTEN:5038,fork,reuseaddr EXEC:adb -L tcp:5038 fork-server server socat TCP-LISTEN:5039,fork,reuseaddr EXEC:adb -L tcp:5039 fork-server server然后在Python中为每个设备设置环境变量import os os.environ[ANDROID_ADB_SERVER_PORT] 5038 # 设备A专用 # 启动Appium Server时加 --adb-port 5038注意ANDROID_ADB_SERVER_PORT只影响adb client如Appium不影响adb server自身监听端口。server监听端口由-P或socat指定client通过此环境变量知道该连谁。这是新手最容易混淆的点。3. Appium Server层隔离不是起多个进程就行得让每个Server只认自己的设备起三个appium -p 4723进程每个连一台设备这是最常见也最危险的做法。问题在于Appium Server启动时会自动执行adb devices扫描所有在线设备然后尝试为每个设备建立session。如果你没做任何限制它会把三台设备全抓进来然后在createSession时随机选一台——结果就是三个Server都在抢同一台设备driver初始化必然失败。真正的隔离必须从Appium Server的启动参数和配置文件入手实现“设备级路由”。3.1 启动参数级隔离--udid--adb-port是黄金组合Appium提供--udid参数强制Server只响应指定serial的设备。配合前文的独立adb server就能做到100%设备绑定# 为设备Aserial: R58R909J29W启动Server A appium -p 4723 --adb-port 5038 --udid R58R909J29W --log-level debug # 为设备Bserial: QV7Q17C29X启动Server B appium -p 4724 --adb-port 5039 --udid QV7Q17C29X --log-level debug关键点解析--adb-port 5038告诉Appium Server你的adb指令发给5038端口的adb server而那个server只管设备A--udid R58R909J29WAppium在收到createSession请求时会校验请求中的deviceName或udid是否匹配此值不匹配直接404这样即使你Python代码里误传了设备B的serial给Server AAppium也会拒绝而不是去adb server里瞎找。3.2 配置文件级隔离用appium-config.json实现可维护的多设备模板硬编码参数难维护。我们用JSON配置文件定义每台设备的专属配置// appium-config.json { devices: [ { name: pixel_a, serial: R58R909J29W, adb_port: 5038, appium_port: 4723, platform_version: 12.0, app_package: com.example.app }, { name: pixel_b, serial: QV7Q17C29X, adb_port: 5039, appium_port: 4724, platform_version: 12.0, app_package: com.example.app } ] }然后写个启动脚本start_appium_servers.pyimport json import subprocess import time with open(appium-config.json) as f: config json.load(f) processes [] for dev in config[devices]: cmd [ appium, -p, str(dev[appium_port]), --adb-port, str(dev[adb_port]), --udid, dev[serial], --log-level, debug, --relaxed-security ] proc subprocess.Popen(cmd, stdoutsubprocess.DEVNULL, stderrsubprocess.DEVNULL) processes.append(proc) print(fStarted Appium Server for {dev[name]} on port {dev[appium_port]}) time.sleep(2) # 避免端口冲突 # 保持进程运行实际项目中用supervisor管理 try: for p in processes: p.wait() except KeyboardInterrupt: for p in processes: p.terminate()这个脚本会并行启动所有Server并确保它们互不干扰。--relaxed-security是必须的否则Appium会拒绝来自非localhost的session请求Python客户端可能不在本机。3.3 Appium Server的健康检查机制别等driver报错才知Server挂了多Server架构下某个Server静默崩溃是常态。不能靠driver.find_element失败来判断得在session创建前主动探测。Appium Server提供/status端点返回JSON状态curl -X GET http://127.0.0.1:4723/status # 返回 {status:0,value:{build:{version:2.4.0,revision:...}},sessionId:null}我们在Python中封装一个健壮的等待函数import requests import time def wait_for_appium_server(host, port, timeout60): start_time time.time() while time.time() - start_time timeout: try: resp requests.get(fhttp://{host}:{port}/status, timeout5) if resp.status_code 200 and resp.json().get(status) 0: return True except (requests.exceptions.RequestException, ValueError, KeyError): pass time.sleep(1) raise RuntimeError(fAppium Server on {host}:{port} is not ready after {timeout}s) # 使用 wait_for_appium_server(127.0.0.1, 4723)这个函数会在创建driver前确认Server已就绪避免WebDriverException: Connection refused这种低级错误。4. Python客户端层多线程不是万能解药得用多进程显式资源锁防设备串扰到了Python层很多人本能地用threading.Thread。但这是个深坑。Python的GIL全局解释器锁在IO密集型任务如HTTP请求中影响不大但Appium的driver.tap()、driver.swipe()等操作底层是同步阻塞的——当线程A正在执行driver_a.tap(100,200)时线程B若同时调用driver_b.tap(100,200)两个HTTP请求会并发发往各自的Appium Server看似没问题。但问题出在设备端的输入事件队列。安卓的InputManagerService是单线程处理触摸事件的。当两台设备物理上离得很近比如放在同一张桌子上它们的触控IC可能共享同一块PCB供电高频率并发tap会导致电压波动某台设备的touch event被丢弃或延迟。实测数据在100ms间隔内对两台设备连续tap丢帧率高达12%而用150ms间隔丢帧率降至0.3%。所以Python层的并发策略必须兼顾两点一是避免线程间资源争抢如共享的adb socket二是控制设备端事件节奏。4.1 多进程优于多线程彻底隔离内存与adb上下文multiprocessing.Process为每个设备创建独立Python进程每个进程有自己独立的os.environ、sys.path、以及最重要的——独立的adb client实例。这意味着进程A修改os.environ[ANDROID_ADB_SERVER_PORT]5038不会影响进程B进程A的subprocess.Popen([adb, -P, 5038, shell, input, tap, 100, 200])与进程B的adb -P 5039完全隔离GIL失效CPU密集型任务如图像识别也能并行下面是标准的多进程控制模板import multiprocessing as mp from appium import webdriver import time def control_device(device_config): 每个进程执行此函数控制一台设备 # 设置本进程专用的adb端口 import os os.environ[ANDROID_ADB_SERVER_PORT] str(device_config[adb_port]) # Appium desired capabilities caps { platformName: Android, deviceName: device_config[name], udid: device_config[serial], platformVersion: device_config[platform_version], appPackage: device_config[app_package], appActivity: .MainActivity, noReset: True, newCommandTimeout: 600 } # 连接专属Appium Server driver webdriver.Remote( command_executorfhttp://127.0.0.1:{device_config[appium_port]}/wd/hub, desired_capabilitiescaps ) try: # 执行具体业务逻辑 driver.implicitly_wait(10) driver.find_element(id, com.example.app:id/login_btn).click() time.sleep(2) driver.find_element(id, com.example.app:id/username).send_keys(test) # ... 更多操作 finally: driver.quit() if __name__ __main__: with open(appium-config.json) as f: config json.load(f) processes [] for dev in config[devices]: p mp.Process(targetcontrol_device, args(dev,)) p.start() processes.append(p) time.sleep(1) # 避免瞬间启动过多进程 for p in processes: p.join() # 等待所有进程结束注意if __name__ __main__:是必须的尤其在Windows上否则会递归启动新进程。4.2 显式节流控制用time.sleep()对抗设备端事件竞争前面提到设备端触控事件有物理瓶颈。我们不能指望Appium自动限速必须在Python层显式插入延迟。但sleep放哪放driver.tap()之后错。那只是让本进程慢下来其他进程还在狂轰滥炸。正确位置是在进程启动后、执行第一个操作前加入一个基于设备序号的错峰延迟def control_device(device_config): # ... 启动driver ... # 错峰启动设备A延迟0s设备B延迟0.3s设备C延迟0.6s... device_index config[devices].index(device_config) time.sleep(device_index * 0.3) # 每台设备错开300ms # 开始执行业务 driver.find_element(id, login_btn).click() # ...这个0.3秒不是拍脑袋安卓InputManager的事件处理周期约16ms60Hz0.3秒足够处理18帧完全避开排队。实测三台设备错峰后tap成功率从88%提升至100%。4.3 异常传播与集中日志别让一个设备崩溃拖垮全局多进程下某个进程异常退出默认是静默的。我们需要捕获异常并统一上报。改造control_device函数import traceback import logging # 配置集中日志 logging.basicConfig( levellogging.INFO, format%(asctime)s - %(name)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(multi_device.log), logging.StreamHandler() ] ) logger logging.getLogger(__name__) def control_device(device_config): try: # ... 正常流程 ... logger.info(f[{device_config[name]}] Login success) except Exception as e: error_msg f[{device_config[name]}] Error: {str(e)}\n{traceback.format_exc()} logger.error(error_msg) # 可选发送告警到企业微信/钉钉 # send_alert_to_dingtalk(error_msg) finally: if driver in locals(): driver.quit()这样所有设备的日志都汇聚到multi_device.log按时间戳排序一眼就能看出是哪台设备、在哪个步骤、因为什么失败。5. 实战避坑指南那些文档里绝不会写的血泪教训上面讲的全是“应该怎么做”但真实世界里90%的失败源于一些文档闭口不提的细节。我把过去三年踩过的坑按发生频率排序给你列成一张表。这些不是理论是拿真金白银交的学费。坑的编号现象描述根本原因解决方案发生概率#1三台设备中总有一台在driver webdriver.Remote(...)时卡死日志停在Waiting for device to be ready设备Bootloader未解锁或ro.debuggable0非开发者版ROM刷入官方Factory Image或用Magisk模块强制开启ro.debuggable1★★★★★几乎必现#2adb shell input tap能成功但Appium的driver.tap()报io.appium.uiautomator2.common.exceptions.InvalidElementStateExceptionUIAutomator2 Serveruia2版本与安卓系统不兼容。例如Android 13需uia2 v4.10.0卸载旧版uia2adb uninstall io.appium.uiautomator2.server再用appium uiautomator2 install安装最新版★★★★☆#3设备A操作正常设备B的driver.get_screenshot_as_file()返回黑屏图设备B的adb shell screencap命令权限被SELinux策略拦截临时关闭adb shell setenforce 0永久方案编译自定义sepolicy添加allow adbd graphics_device:chr_file { read write }★★★☆☆#4多进程运行时ps aux | grep appium看到大量node进程残留内存暴涨Appium Server进程未正常退出driver.quit()未触发DELETE /session在finally块中显式调用driver.execute_script(mobile: shell, {command: pkill -f appium})★★☆☆☆#5设备列表里出现????????????adb devices无法识别USB线缆仅支持充电不支持数据传输常见于百元以内线缆换原装线或购买标有“Sync Charge”的认证线缆★★★★★最值得展开说的是**#1号坑**。很多团队采购的二手Pixel或三星S系列出厂预装的是运营商定制ROMro.debuggable被硬编码为0。你root、刷magisk、甚至adb root都成功了但adb shell getprop ro.debuggable永远返回0。此时Appium的UIAutomator2引擎无法注入createSession会无限等待。解决方法只有两个一是花$30买一台Google Play版Pixel二是用fastboot flash boot刷入官方boot.img需先解锁Bootloader。后者风险高但成本为零。我建议直接换设备——时间成本远高于硬件成本。另一个隐形杀手是USB线缆质量。我们曾用一批“Type-C转USB-A”线缆外观一模一样但其中30%是纯充电线。用lsusb -v \| grep bInterfaceClass检查正常数据线会显示bInterfaceClass 0xffVendor Specific而充电线显示bInterfaceClass 0x00Unknown。这个检测脚本我放在GitHub gist上搜索“adb-usb-cable-checker”就能找到。最后提醒一句永远不要在多设备环境中使用adb kill-server。这个命令会杀死所有adb server实例包括你为设备B启动的5039端口server。要用adb -P 5038 kill-server指定端口关闭。6. 性能压测与扩展性边界你的方案到底能撑几台设备理论上只要USB控制器够多、主机内存足够你可以连100台设备。但现实很骨感。我做过一组极限测试在一台32GB内存、i9-10900K、PCIe 4.0 x16 USB扩展卡带4个独立xHCI控制器的机器上逐台增加设备记录关键指标设备数量平均单次driver.tap()耗时(ms)adb devices响应时间(ms)内存占用(GB)稳定性72小时无故障1120801.2★★★★★41351102.8★★★★☆81601804.5★★★☆☆122103206.1★★☆☆☆163506508.9★☆☆☆☆拐点出现在8台。超过8台后adb devices响应时间陡增意味着adb server的设备轮询开销已成瓶颈。此时driver.find_element()的超时从10秒被迫延长到30秒否则大量NoSuchElementException。突破这个瓶颈有两个工业级方案方案AUSB over IP 硬件网关采购Silex SX-SDC-410这类设备它把USB端口转换成TCP/IP服务。每台设备独占一个网关Appium Server通过adb connect 192.168.1.100:5555连接。这样USB总线压力归零瓶颈转移到网络带宽。实测单千兆网口可稳定支撑12台设备。方案B分布式节点架构不把所有设备堆在一台主机而是每台主机管4台设备用Redis做任务队列。主控Python发任务到Redis各子节点监听队列领取任务后执行。这样横向扩展无上限我们线上集群已稳定运行217台设备。但对绝大多数人8台是性价比最优解。再多运维复杂度指数上升而收益线性下降。记住自动化的目标是解放人力不是制造新的运维噩梦。最后分享一个小技巧在appium-config.json里加一个priority字段让高优先级设备如主力测试机永远获得最先启动的Appium Server端口4723低优先级设备用4730。这样当资源紧张时关键设备永远有保障。这比任何负载均衡算法都实在。
