Python+Appium自动化测试实战：头条视频自动播放脚本开发指南

1. 项目概述：从手动刷视频到自动化脚本的跃迁

刷短视频，尤其是像头条这类信息流平台，已经成了很多人日常的“电子榨菜”。但如果你是一个测试工程师，或者是一个想研究App交互逻辑的开发者，手动一遍遍刷视频、看广告、点关注，不仅枯燥乏味，效率也极其低下。更别提那些需要验证视频流连续播放稳定性、广告加载策略或者用户行为分析的场景了。这时候，一个能模拟真人操作，自动在头条App里刷视频、点赞、评论的脚本，就成了刚需。

这个项目的核心，就是利用Python和Appium这套黄金组合，打造一个能接管你手机，在头条App里自动执行预设动作的“数字员工”。Appium作为一款开源的移动端自动化测试框架，它的强大之处在于支持原生、混合和Web应用，并且不限制编程语言。我们选择Python，是因为它语法简洁、生态丰富，写起自动化脚本来事半功倍。你不需要再手动点点点，脚本会像一只无形的手，精准地找到屏幕上的视频卡片，触发播放，滑动到下一个，甚至完成更复杂的交互。

这不仅仅是“偷懒”。对于测试同学来说，这是构建UI自动化回归测试用例的基础，能极大提升客户端功能的测试覆盖率和效率。对于数据或策略分析师，可以通过脚本批量收集前端交互数据。对于初学者，这是一个绝佳的、有明确目标的实战项目，能串联起Python基础、Appium环境搭建、元素定位、手势模拟等一整套移动端自动化技能链。接下来，我会带你从零开始，拆解这个“头条视频自动播放”脚本的每一个技术环节，并分享我趟过的坑和积累的经验。

2. 环境搭建与核心工具链解析

工欲善其事，必先利其器。在开始写代码之前，一个稳定、正确的环境是成功的基石。这一部分往往劝退最多的人，因为涉及多个软件和配置的联动。别担心，我会把每一步的原理和避坑点都讲清楚。

2.1 Python环境与IDE选择：为什么是PyCharm？

首先，你需要一个Python环境。直接从官网下载安装即可，建议选择3.8或3.9版本，稳定性最好。安装时务必勾选“Add Python to PATH”，这是为了能在命令行里直接调用python和pip命令。

接下来是开发工具。我强烈推荐使用PyCharm，特别是它的专业版（社区版也足够用）。原因有三点：第一，它对Python的支持是“亲生儿子”级别的，代码提示、调试、虚拟环境管理都非常顺手。第二，它能很好地集成终端，方便你随时运行命令行指令。第三，对于Appium脚本开发，经常需要查看复杂的元素层级结构，PyCharm的代码折叠和结构视图能帮你保持思路清晰。当然，如果你习惯用VSCode，配合Python插件也能获得不错的体验，但初期配置会稍微繁琐一点。

安装好PyCharm后，第一件事是创建一个新的项目，并为这个项目创建一个独立的虚拟环境（Virtual Environment）。这能隔离项目依赖，避免不同项目间的包版本冲突。在PyCharm创建项目时，直接勾选“New environment using Virtualenv”即可。

2.2 Appium Server与客户端的角色关系

这是很多新手容易混淆的概念。Appium的架构分为Server和Client两部分，它们通过网络通信（默认端口4723）协同工作。

Appium Server：它是一个独立的服务程序，你可以把它想象成一个“翻译官”和“指挥中心”。它接收我们从Python脚本（Client端）发过来的指令（比如“点击”、“滑动”），然后将这些指令“翻译”成手机操作系统（Android/iOS）能够理解的原生命令，并通过USB或网络调试协议发送给连接的真实设备或模拟器。最后，它再把设备的响应结果“翻译”回给我们的Python脚本。你需要从Appium官网或通过Node.js的npm命令（npm install -g appium）来安装它。现在更推荐使用图形化的Appium Desktop，它集成了Server和元素检查器（Inspector），对新手更友好。

Appium Client：这就是我们要用Python写的部分。它实际上是一个客户端库，封装了与Appium Server通信的协议。我们通过pip install Appium-Python-Client来安装这个库。在脚本里，我们导入webdriver模块（对，就是Selenium那个webdriver，因为Appium遵循了W3C WebDriver协议），然后使用它提供的方法来编写自动化逻辑。所以，你的代码（Client）负责发号施令，Appium Server负责传达和执行，手机设备是最终的动作执行者。

2.3 安卓开发工具与设备连接

既然我们的目标是安卓版的头条App，就需要准备好安卓的调试环境。

1. 安装Android SDK：最省事的方法是直接安装Android Studio。在安装过程中，它会自动包含SDK。我们主要需要的是SDK里的adb（Android Debug Bridge）工具。adb是连接电脑和手机的桥梁，负责安装应用、传输文件、获取设备信息等。安装完成后，请将SDK的platform-tools目录（里面包含adb.exe）路径添加到系统的环境变量PATH中。这样你才能在命令行任何位置直接使用adb命令。

2. 准备测试设备：你可以使用真机，也可以使用模拟器（如Android Studio自带的AVD）。强烈建议新手先从模拟器开始，避免真机上的各种厂商定制系统带来的兼容性问题。

   • 真机：用USB线连接电脑，在手机上开启“开发者选项”（通常是在关于手机里连续点击版本号），然后在开发者选项中开启“USB调试”。
   • 模拟器：在Android Studio中创建一个AVD并启动它。确保模拟器的系统版本不要太老。

3. 验证连接：打开命令行，输入adb devices。如果看到设备列表中出现你的设备或模拟器序列号，后面跟着device字样，说明连接成功。这是后续所有工作的前提。

注意：有时候adb devices找不到设备，可能是驱动问题（真机）、adb服务冲突或端口占用。可以尝试重启adb服务：adb kill-server然后adb start-server。对于模拟器，确保Android Studio内的AVD已经完全启动进入主界面。

2.4 必备的辅助工具：Appium Inspector

Appium Inspector是定位App元素的“眼睛”，没有它，自动化就是盲人摸象。它内置于Appium Desktop中。它的工作原理是：启动Inspector会话时，它会向Appium Server发送一个请求，Server会控制当前连接的设备，并获取当前屏幕的UI层级结构（一个XML文件）和截图，然后回传给Inspector显示出来。

使用Inspector的关键步骤是配置Desired Capabilities。这是一组发送给Appium Server的键值对，用于告诉Server你想要如何启动和测试你的应用。对于头条自动化，一个最基本的配置如下（需要在Inspector中填入）：

{ "platformName": "Android", "platformVersion": "11", // 你的设备系统版本 "deviceName": "emulator-5554", // 通过`adb devices`获取的设备名 "appPackage": "com.ss.android.article.news", // 头条的包名 "appActivity": ".activity.MainActivity", // 头条的主Activity "automationName": "UiAutomator2", // Android推荐使用的驱动 "noReset": true // 不重置应用数据，避免每次重新登录 }

• 如何获取appPackage和appActivity？有几种方法：1) 问开发；2) 使用adb命令：先打开头条App到主界面，然后执行adb shell dumpsys window | findstr mCurrentFocus（Windows）或adb shell dumpsys window | grep mCurrentFocus（Mac/Linux），输出结果中com.ss.android.article.news就是包名，/.activity.MainActivity就是Activity。
• automationName：对于Android，一定要用UiAutomator2，这是目前最稳定、功能最全的驱动。旧版的UiAutomator1已经废弃。

配置好之后，点击“Start Session”，你就能在Inspector里看到手机当前界面的元素树了。你可以点击屏幕上的元素，右侧会显示其详细的属性，如resource-id,text,class,content-desc等。这些属性就是我们后续写脚本时用来定位元素的“坐标”。

3. 自动化脚本核心架构与设计思路

环境准备好后，我们进入核心的脚本设计阶段。写自动化脚本不是一行行命令的堆砌，而是需要有清晰的结构和设计模式，这样代码才易于维护、扩展和复用。

3.1 脚本基础骨架与Desired Capabilities配置

在Python中，我们通过webdriver.Remote来连接Appium Server。首先创建一个Python文件，比如toutiao_auto_play.py。

from appium import webdriver from appium.webdriver.common.appiumby import AppiumBy import time # 1. 定义Desired Capabilities desired_caps = { 'platformName': 'Android', 'platformVersion': '11', 'deviceName': 'emulator-5554', 'appPackage': 'com.ss.android.article.news', 'appActivity': '.activity.MainActivity', 'automationName': 'UiAutomator2', 'noReset': True, # 不清空缓存，避免重复登录 'newCommandTimeout': 600, # 命令超时时间设为10分钟，防止长时间操作断开 'unicodeKeyboard': True, # 使用Unicode编码方式发送字符串，支持中文输入 'resetKeyboard': True, # 在隐藏Unicode键盘后，重置键盘到原始状态 } # 2. 连接Appium Server driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps) # 隐式等待，全局设置查找元素的超时时间 driver.implicitly_wait(10) try: # 这里是主要的自动化逻辑 print("头条App已启动，开始自动化操作...") # ... 后续操作代码写在这里 finally: # 3. 无论是否发生异常，最终都退出驱动，释放资源 time.sleep(5) # 最后看一眼 driver.quit()

这是一个最基础的骨架。desired_caps字典里的配置和Inspector中的一致。webdriver.Remote的第一个参数是Appium Server的地址，默认本地运行在4723端口。implicitly_wait(10)设置了隐式等待，意思是当脚本试图查找一个元素时，如果元素没有立即出现，它会最多等待10秒，期间会不断轮询查找。这能有效解决因网络延迟或页面渲染慢导致的元素找不到的问题。

3.2 元素定位策略：八种武器与优先级选择

定位元素是自动化脚本的基石。Appium（继承自Selenium）提供了多种定位器（Locator）。根据我的经验，定位策略有一个优先级，稳定性由高到低：

1. ID (resource-id)：如果元素有唯一的resource-id，这是首选。在Android中，它通常类似于com.ss.android.article.news:id/title。定位方式：AppiumBy.ID。
2. Accessibility ID (content-desc)：这是为无障碍服务设计的描述，对于重要的按钮或图标，开发通常会设置。如果唯一，也是极好的选择。定位方式：AppiumBy.ACCESSIBILITY_ID。
3. XPath：这是最强大但也最脆弱的定位方式。它通过XML路径来定位元素。不到万不得已，不要优先使用完整的绝对路径XPath，因为UI结构一变，路径就失效了。应该使用包含关键属性（如text,resource-id）的相对路径或条件组合。例如：//android.widget.TextView[@text=\"推荐\"]。定位方式：AppiumBy.XPATH。
4. Class Name：通过控件类型定位，如android.widget.TextView。但通常一个界面上同类控件太多，需要结合其他条件或通过find_elements取列表后按索引选择。
5. Android UiAutomator (UiAutomator2)：这是Android原生提供的强大定位方式，语法灵活。例如：driver.find_element(AppiumBy.ANDROID_UIAUTOMATOR, 'new UiSelector().text(\"推荐\")')。它在处理复杂动态内容时有时比XPath更高效。

实操心得：对于头条这样的信息流App，视频卡片通常没有固定的resource-id，其结构是动态生成的。这时，最常用的策略是：

• 组合定位：使用XPath，结合class和可预测的text或index。例如，定位视频标题区域：//android.widget.FrameLayout[contains(@resource-id, \"feed_item\")]//android.widget.TextView。
• 列表操作：先用find_elements找到当前屏幕所有视频卡片的共同父容器或特征，返回一个列表，然后通过索引（如[0]）来操作第一个或第N个视频。滑动后再获取新的列表。

3.3 常用手势操作封装：滑动、点击与等待

自动刷视频的核心动作就是“滑动”。Appium提供了TouchAction和W3C Actions两种方式。现在更推荐使用W3C Actions，它是标准协议。

from appium.webdriver.common.touch_action import TouchAction # 但更推荐使用以下方式实现滑动（基于W3C Actions）： def swipe_up(driver, duration_ms=800): """模拟向上滑动屏幕""" size = driver.get_window_size() start_x = size['width'] * 0.5 start_y = size['height'] * 0.8 end_x = size['width'] * 0.5 end_y = size['height'] * 0.2 # W3C Actions 方式 driver.execute_script('mobile: swipeGesture', { 'left': start_x, 'top': start_y, 'width': end_x-start_x, 'height': end_y-start_y, 'direction': 'up', 'percent': 0.75, # 滑动距离为屏幕高度的75% 'speed': 1500 # 速度，值越大越慢 }) time.sleep(2) # 滑动后等待新内容加载 def tap_element(driver, element): """点击一个元素""" action = TouchAction(driver) action.tap(element).perform()

为什么是get_window_size和比例坐标？因为不同手机分辨率不同，使用绝对坐标（如(500, 1500)）的脚本完全无法复用。通过获取屏幕尺寸后乘以一个比例（如从80%高度滑到20%高度），可以保证在任何分辨率的设备上，滑动的“幅度”是相对一致的。

等待的艺术：除了隐式等待，在关键操作后必须加入time.sleep或使用显式等待（WebDriverWait）。显式等待更智能，它等待某个条件成立（如元素出现、元素可点击）后才继续，而不是死等固定时间。

from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC # 等待“推荐”标签出现，最多等15秒 recommend_tab = WebDriverWait(driver, 15).until( EC.presence_of_element_located((AppiumBy.XPATH, '//*[@text=\"推荐\"]')) )

4. 实现头条视频自动播放的核心逻辑

有了前面的基础，我们现在来组装“自动播放”这个核心功能。我们的目标是：启动头条App，自动进入视频流，然后持续地滑动播放视频。

4.1 启动App与进入视频频道

头条App启动后，默认可能是图文信息流。我们需要找到并切换到“视频”频道。

def enter_video_channel(driver): """启动后尝试进入视频频道""" print("尝试寻找并点击视频频道...") try: # 方法1：尝试点击底部的“视频”导航栏 video_tab = driver.find_element(AppiumBy.XPATH, '//*[@text=\"视频\"]') video_tab.click() print("已通过底部导航栏进入视频频道。") except Exception as e1: print(f"底部导航栏未找到‘视频’标签，尝试方法2: {e1}") try: # 方法2：有些版本顶部有频道栏，滑动找到“视频” # 先获取顶部频道栏的元素（可能是一个HorizontalScrollView） channel_bar = driver.find_element(AppiumBy.ID, 'com.ss.android.article.news:id/channel_id') # 如果“视频”不在当前视野，需要横向滑动频道栏。这里简化处理，直接找元素点击。 # 更健壮的做法是滑动查找，但作为示例我们先尝试直接定位 video_tab_top = driver.find_element(AppiumBy.ANDROID_UIAUTOMATOR, 'new UiSelector().textContains(\"视频\")') video_tab_top.click() print("已通过顶部频道栏进入视频频道。") except Exception as e2: print(f"进入视频频道失败，将在当前页面开始操作: {e2}") # 如果都找不到，可能当前已经是视频流，或者版本差异大，记录日志后继续 time.sleep(3) # 等待频道切换加载

这个函数展示了防御性编程的思路。UI可能会变，所以我们准备了备选方案（try...except）。先尝试最可能的方式（底部导航），失败了再尝试另一种（顶部频道栏）。如果都失败了，至少不会让脚本崩溃，而是记录日志并尝试继续。

4.2 定位视频卡片与触发播放

进入视频流后，我们需要找到当前屏幕上的视频卡片。视频卡片通常是一个包含播放按钮、标题、作者信息的容器。

def find_and_play_video(driver): """在当前屏幕查找并尝试播放第一个视频""" print("正在查找视频卡片...") # 尝试多种定位策略来获取视频卡片列表 video_cards = [] try: # 策略1：通过可能的公共resource-id部分定位 video_cards = driver.find_elements(AppiumBy.XPATH, '//*[contains(@resource-id, \"feed\") or contains(@resource-id, \"video\")]') except: pass if not video_cards: try: # 策略2：通过特定的布局类定位（视频卡片常用FrameLayout或RelativeLayout包裹） video_cards = driver.find_elements(AppiumBy.CLASS_NAME, 'android.widget.FrameLayout') # 进一步过滤：通常视频卡片比较大，我们可以通过尺寸简单过滤（这是一个粗略方法） video_cards = [card for card in video_cards if card.size['height'] > 300 and card.size['width'] > 300] except: pass if video_cards: first_card = video_cards[0] print(f"找到 {len(video_cards)} 个可能的视频卡片，操作第一个。") # 点击卡片中央区域来触发播放 location = first_card.location size = first_card.size center_x = location['x'] + size['width'] / 2 center_y = location['y'] + size['height'] / 2 driver.execute_script('mobile: tap', {'x': center_x, 'y': center_y}) print("已点击视频卡片，尝试播放。") time.sleep(5) # 等待视频开始播放 # 播放后，可能全屏，这里可以加入检测播放状态的逻辑（如查找暂停按钮） try: pause_btn = driver.find_element(AppiumBy.ID, 'com.ss.android.article.news:id/pause_button') print("视频播放中，检测到暂停按钮。") except: print("未检测到明确播放状态，继续流程。") else: print("未找到明确的视频卡片，可能页面布局不同。")

关键点：直接定位“播放按钮”往往很困难，因为它可能在视频加载后才出现，或者其resource-id是动态的。更通用的做法是定位整个视频卡片容器，然后点击其中心区域。这模拟了用户点击视频区域进行播放的行为。

4.3 循环滑动与连续播放逻辑

单个视频播放不是目的，我们要实现连续自动播放。逻辑是：播放当前视频一段时间（或检测播放结束）-> 上滑切换到下一个视频 -> 重复。

def auto_swipe_and_play(driver, max_swipes=20, watch_seconds=10): """自动滑动并播放视频""" swipe_count = 0 while swipe_count < max_swipes: print(f"\n--- 第 {swipe_count + 1} 次循环 ---") # 1. 确保当前有视频在播放（或触发播放） find_and_play_video(driver) # 2. 观看一段时间（这里简单用sleep模拟，实际可检测播放进度） print(f"观看视频约 {watch_seconds} 秒...") time.sleep(watch_seconds) # 3. 向上滑动到下一个视频 print("向上滑动到下一个视频。") swipe_up(driver, duration_ms=1000) # 滑动速度可以调慢一点，确保加载 # 4. 滑动后等待新内容稳定 time.sleep(3) swipe_count += 1 print(f"\n已完成 {max_swipes} 次滑动播放。")

这个循环结构清晰。max_swipes控制刷多少条，watch_seconds控制每条视频看多久。你可以根据需要调整。在真实场景中，watch_seconds可以替换为更智能的逻辑，比如：检测视频播放结束的标志（如“重新播放”按钮出现），或者随机一个观看时长以模拟更真实的人类行为。

4.4 增强健壮性：异常处理与日志记录

自动化脚本在长时间运行中会遇到各种意外：网络波动、弹窗广告、页面加载失败、元素定位失败等。一个健壮的脚本必须能处理这些异常。

import logging from datetime import datetime # 配置日志 logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s', handlers=[logging.FileHandler('toutiao_auto.log'), logging.StreamHandler()]) def safe_find_and_click(driver, by, value, retries=2): """安全地查找并点击元素，带有重试机制""" for i in range(retries + 1): try: element = driver.find_element(by, value) element.click() logging.info(f"成功点击元素: {value}") return True except Exception as e: logging.warning(f"第{i+1}次尝试点击元素[{value}]失败: {e}") if i < retries: time.sleep(2) # 等待后重试 else: logging.error(f"重试{retries}次后仍无法点击元素[{value}]，放弃。") return False def handle_popups(driver): """尝试处理常见的弹窗（如青少年模式、升级提示、权限申请）""" popup_selectors = [ (AppiumBy.ID, 'com.ss.android.article.news:id/close'), # 通用关闭按钮ID (AppiumBy.XPATH, '//*[@text=\"我知道了\"]'), (AppiumBy.XPATH, '//*[@text=\"以后再说\"]'), (AppiumBy.XPATH, '//*[@text=\"允许\"]'), # 谨慎处理，测试环境可点 (AppiumBy.XPATH, '//*[@text=\"拒绝\"]'), ] for by, selector in popup_selectors: try: popup = driver.find_element(by, selector) popup.click() logging.info(f"检测并关闭了弹窗: {selector}") time.sleep(1) # 关闭一个后可能还有，可以递归或循环，这里简单处理 except: pass

在主循环中，可以在每次操作前先调用handle_popups清理可能的干扰。对于关键操作（如进入视频频道），使用safe_find_and_click来增加成功率。同时，将所有的print替换为logging.info，这样日志既能输出到控制台，也能保存到文件，方便后续排查问题。

5. 常见问题排查与实战经验分享

即使按照步骤操作，你也一定会遇到各种问题。这里我总结了一些高频问题和解决思路。

5.1 元素定位失败：动态ID与页面结构变化

这是最常见的问题。头条这类App的UI迭代很快，今天还能用的resource-id，明天可能就变了。

症状：脚本报错NoSuchElementException。

排查与解决：

1. 重新用Appium Inspector检查：这是第一步。打开Inspector，连接到当前运行的会话（注意appPackage和appActivity要匹配），查看目标元素的属性是否已变化。
2. 使用更宽松的定位器：
   • XPath部分匹配：如果resource-id是动态的但有一部分固定，如com.ss.android.article.news:id/abc123_title，可以用contains：//*[contains(@resource-id, \"_title\")]。
   • 结合多个属性：用and连接多个条件，增加唯一性。例如：//android.widget.Button[@clickable=\"true\" and @text=\"关注\"]。
   • 使用UiAutomator2的文本定位：driver.find_element(AppiumBy.ANDROID_UIAUTOMATOR, 'new UiSelector().text(\"推荐\")')对于文本固定的元素非常可靠。
3. 改用坐标点击（最后的手段）：如果元素确实无法通过属性定位，且位置相对固定（如底部导航栏），可以考虑使用坐标点击。但这是最不推荐的方法，因为不同分辨率设备上坐标会变。如果要用，务必基于屏幕比例计算坐标。

   # 计算屏幕底部“首页”标签的大致位置（示例，需根据实际情况调整） size = driver.get_window_size() tap_x = size['width'] * 0.2 # 假设第一个标签在20%宽度处 tap_y = size['height'] * 0.95 # 靠近底部 driver.tap([(tap_x, tap_y)])

5.2 滑动失效或误触发：手势操作精度优化

症状：swipe_up后页面没反应，或者滑过了头，甚至误点了广告。

排查与解决：

1. 调整滑动参数：swipe_up函数中的start_y（起始点）和end_y（结束点）比例是关键。起始点不要离屏幕边缘太近（避免触发系统手势），滑动距离（percent）不宜过大。可以尝试将start_y从0.8调整到0.7，end_y从0.2调整到0.3，让滑动更“轻柔”。
2. 增加滑动后的等待时间：网络慢时，新内容加载需要时间。滑动后立即查找元素可能会失败。确保swipe_up函数内部或调用后，有足够的time.sleep（如3-5秒）。更好的做法是使用显式等待，等待某个新视频卡片的特征元素出现。

   # 滑动后，等待新视频卡片出现 WebDriverWait(driver, 10).until( EC.presence_of_element_located((AppiumBy.XPATH, '//*[contains(@resource-id, \"feed\")]')) )

3. 处理“加载中”状态：在滑动后，页面可能出现“加载中...”的提示。可以写一个循环，持续检测这个提示是否消失，再继续后续操作。
4. 避免误点广告：广告的关闭按钮通常有固定的resource-id或text（如“跳过”、“关闭”）。可以在每次滑动播放前，先运行一个handle_popups函数来尝试关闭广告。

5.3 脚本运行不稳定：超时、断开与重连机制

症状：脚本运行一段时间后卡住、报错WebDriverException，或者直接断开连接。

排查与解决：

1. 检查Appium Server日志：运行Appium Server的命令行窗口会打印详细日志。当脚本出错时，第一时间查看这里的错误信息，通常能定位到是Server端的问题（如设备无响应）还是协议错误。
2. 设置合理的超时时间：在desired_caps中设置newCommandTimeout为一个较大的值（如600秒），防止长时间无操作被Server断开。
3. 加入心跳或重试机制：对于长时间运行的循环，可以在每次循环开始时，尝试执行一个简单的命令（如driver.current_context）来保持连接活跃。如果捕获到连接异常，可以尝试重新初始化driver。

   def check_and_reconnect(driver, desired_caps): """检查连接，如果失败则尝试重连""" try: # 尝试一个无害的操作来检测连接状态 driver.current_context return driver except Exception: logging.error("WebDriver连接丢失，尝试重连...") try: driver.quit() except: pass time.sleep(5) new_driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps) new_driver.implicitly_wait(10) logging.info("重连成功。") return new_driver # 在主循环中定期调用 if swipe_count % 10 == 0: # 每10次循环检查一次 driver = check_and_reconnect(driver, desired_caps)

4. 设备本身的问题：确保手机/模拟器不要锁屏（在开发者选项里设置“保持唤醒”）。关闭其他耗电应用，保证性能。

5.4 提升脚本的“人性化”与反检测思考

如果你希望脚本运行得更像真人，或者需要长时间运行而不被服务端轻易识别为机器人，可以考虑以下策略：

1. 随机化操作：人类的操作不是机械的定时循环。
   • 随机等待时间：用random.uniform(5, 15)代替固定的time.sleep(10)。
   • 随机滑动速度：在swipe_up函数中引入随机的duration_ms。
   • 随机操作顺序：不一定每次都要点赞或评论。可以设置一个概率，比如10%的概率去点赞，5%的概率点开评论区看一眼再关闭。
2. 模拟更复杂的交互：
   • 偶尔上滑后回滑：模拟“看漏了，滑回去”的动作。
   • 在视频播放中途暂停/播放：随机在观看期间点击屏幕中央，触发暂停，过几秒再点击播放。
   • 滑动轨迹：使用mobile: dragGesture模拟带曲线的滑动，而不是直线。
3. 处理更多样的内容形式：信息流里不只有视频，还有图文、微头条、广告。脚本需要能识别当前卡片类型并做出不同反应（如跳过图文，快速划过广告）。可以通过判断卡片内是否存在特定的元素（如播放按钮、大图、广告标识）来实现分支逻辑。

最后一点经验：自动化测试脚本不是一蹴而就的，尤其是对于UI变化频繁的App。最好的实践是将定位信息（如XPath、ID）抽取到配置文件或单独的管理类中。当UI变更时，你只需要更新配置文件，而不需要深入修改核心业务逻辑代码。同时，建立完善的日志系统，记录每一步操作和屏幕截图（driver.save_screenshot(‘error.png’)），这样当脚本在无人值守运行时出错，你也能有足够的线索来复现和修复问题。这个“头条视频自动播放”项目是一个很好的起点，掌握了它，你就掌握了移动端UI自动化的核心方法论，可以将其应用到任何App的自动化场景中。