Appium+Mitmproxy实战：高效稳定采集小红书数据的自动化方案-尧图网络科技

1. 项目概述与核心价值

最近在做一个关于内容社区趋势分析的项目，需要从几个主流平台获取公开数据。其中，小红书的数据因其独特的社区生态和用户画像，成为了分析的关键一环。但做过数据采集的朋友都知道，面对这类动态加载、交互复杂的移动端应用，传统的爬虫方法往往力不从心。直接请求API？接口参数加密且变动频繁。模拟请求？登录态和风控策略是两道难以逾越的坎。经过一番折腾和对比，我最终敲定了一套组合拳：Appium + Mitmproxy。这套方案的核心思路很清晰：用Appium模拟真人操作手机App，绕过复杂的接口加密；用Mitmproxy作为中间人代理，在数据流经时进行无感抓取。这听起来像是“杀鸡用牛刀”，但实测下来，对于小红书这类反爬策略日益成熟的App，这反而是最稳定、最接近“合规”边缘的高效方案。它特别适合需要采集列表、详情、评论、用户信息等结构化数据的场景，无论是做竞品分析、舆情监控还是内容研究，都能提供一个相对可靠的自动化数据入口。

2. 方案选型与核心思路拆解

2.1 为什么是Appium + Mitmproxy？

在数据采集领域，技术选型直接决定了项目的成败和维护成本。面对小红书App，我主要评估过以下几种常见方案：

逆向工程与协议分析：直接反编译App，分析其网络通信协议。这是最根本的方法，能获得最高的效率和灵活性。但门槛极高，需要深厚的逆向功底，且小红书作为大厂产品，其代码混淆、加密策略非常完善，投入产出比对于大多数数据分析师或普通开发者来说太低。更重要的是，此举存在较高的法律风险。
纯模拟请求（如requests库）：尝试模拟登录后的API请求。这需要破解签名算法、处理动态token、应对滑块验证等风控手段。小红书的接口参数（如x-sign）生成逻辑复杂且经常更新，维护成本巨大，一个微小的改动就可能导致整个采集链路失效。
无头浏览器（如Puppeteer for Mobile）：模拟浏览器环境。对于Web端很有效，但对于原生App则无能为力。
基于设备自动化的抓取（本文方案）：通过自动化测试工具（如Appium）真实操控App，所有操作与真人无异。网络请求则通过设置系统代理，经由抓包工具（如Mitmproxy）流出，从而被拦截和解析。

最终选择Appium+Mitmproxy，是基于以下几个核心考量：

高拟真度，低风控风险：Appium驱动的是真实的手机系统（或模拟器）和App应用，所有点击、滑动、输入行为都与真人操作在系统层面无异，极大降低了被服务端基于行为特征识别为机器的风险。
绕过前端加密：由于操作发生在应用层，我们完全不用关心API请求的签名是如何生成的。App发出的是什么请求，Mitmproxy看到的就是什么请求，签名、加密等过程都由App本身完成，我们只是“旁观者”。
数据流完整可见：Mitmproxy作为中间人，可以捕获到包括HTTPS在内的所有HTTP(S)请求和响应，不仅能看到API接口，还能看到图片、字体等资源请求，为数据分析提供了完整上下文。
技术栈友好：两者都支持Python，能够很好地集成到数据采集Pipeline中，方便进行任务调度、数据解析和持久化。

这套方案的核心思路可以概括为：“真人操作，旁路抓包”。Appium负责扮演“手指”和“眼睛”，完成浏览、点击等交互任务；Mitmproxy扮演“监听者”，在设备网络流量的必经之路上设置检查点，悄无声息地复制并解析我们感兴趣的数据。

2.2 关键组件与工具准备

工欲善其事，必先利其器。在开始编码之前，需要准备好以下环境和工具，这里以Android平台为例进行说明：

测试设备：一部安卓真机或性能足够的模拟器（如Android Studio自带的AVD）。推荐使用真机，更稳定且能避免模拟器指纹可能带来的风控问题。确保开启“开发者选项”和“USB调试”。
Appium Server：负责接收我们的自动化脚本指令，并将其转化为设备可识别的操作。通过Node.js安装即可。
Appium Client (Python库)：即appium-python-client，这是我们编写自动化脚本的主要工具库。
Mitmproxy：核心抓包工具。推荐直接使用mitmproxy的Python库，它可以作为一个Python模块嵌入到我们的脚本中，实现动态控制。
小红书App：从官方应用市场下载目标版本，避免使用修改版。
CA证书：为了让设备信任Mitmproxy代理，从而解密HTTPS流量，必须在设备上安装Mitmproxy的CA证书。

注意：整个环境搭建，尤其是Mitmproxy证书的安装，是第一个容易卡住的点。很多教程语焉不详，导致手机App无法抓到HTTPS包。其根本原理是，Mitmproxy作为中间人，需要“伪装”成目标服务器与客户端（手机）通信，这就要求客户端必须信任Mitmproxy自己颁发的CA证书。

3. 环境搭建与核心配置实战

3.1 Appium环境配置与设备连接

首先安装Appium Server。如果你已经安装了Node.js，可以通过npm全局安装：

npm install -g appium

安装完成后，可以在终端启动Appium Server，默认监听4723端口。更常用的方式是在脚本中通过appium.webdriver模块来启动。

接下来是Python客户端环境：

pip install appium-python-client

连接设备是关键一步。确保手机通过USB连接电脑，并已开启USB调试。在命令行使用adb devices命令，应该能看到你的设备序列号。

编写一个最简单的连接脚本appium_test.py来验证环境：

from appium import webdriver from appium.options.android import UiAutomator2Options # 定义设备能力配置 capabilities = { “platformName”: “Android”, “appium:platformVersion”: “13”, # 你的安卓版本 “appium:deviceName”: “your_device_serial”, # adb devices 看到的序列号 “appium:automationName”: “UiAutomator2”, “appium:appPackage”: “com.xingin.xhs”, # 小红书包名 “appium:appActivity”: “.activity.SplashActivity”, # 启动Activity，不同版本可能不同 “appium:noReset”: True, # 不重置应用状态，避免每次重新登录 “appium:newCommandTimeout”: 600, “appium:udid”: “your_device_serial” # 再次指定设备序列号 } # 将配置转换为Appium Options对象 appium_options = UiAutomator2Options().load_capabilities(capabilities) # 连接Appium Server driver = webdriver.Remote(‘http://localhost:4723’, options=appium_options) # 如果成功，这里会启动小红书App print(“连接成功，App已启动！”) # 后续操作... # driver.quit() # 记得退出

实操心得1：appPackage和appActivity的获取，可以使用adb shell命令。先打开小红书App，然后执行adb shell dumpsys window | grep mCurrentFocus，输出结果中com.xingin.xhs后面的部分就是当前的Activity。noReset选项非常重要，设为True可以保持App的登录状态，避免每次脚本运行都要处理登录。

3.2 Mitmproxy安装与CA证书配置

安装Mitmproxy的Python库：

pip install mitmproxy

安装后，系统会多出mitmproxy，mitmdump，mitmweb三个命令。我们主要使用mitmdump，因为它可以无头运行，方便集成到Python脚本。

最关键的步骤——安装CA证书到安卓设备：

启动Mitmproxy代理：在电脑上找一个端口（如8080）启动代理。
```
mitmdump -s your_script.py -p 8080
```
这里的-s参数指定一个Python脚本（后续我们的抓包逻辑会写在这里），先不用管，可以暂时不加-s。
配置手机代理：确保手机和电脑在同一个局域网。在手机的Wi-Fi设置中，修改当前网络，代理选择“手动”，服务器主机名填写电脑的IP地址，端口填写8080。
安装证书：在手机浏览器中访问http://mitm.it。这是一个Mitmproxy提供的专属页面，会根据访问的设备类型提供对应的证书安装指引。对于安卓，你需要下载一个.cer或.pem文件，然后进入系统设置 -> 安全 -> 加密与凭据 -> 安装证书 -> CA证书，找到下载的文件进行安装。
- 对于安卓高版本（7.0+）的额外步骤：系统默认不再信任用户安装的CA证书。你需要将证书安装到系统级，这通常需要root权限。一个折中的方案是，将Mitmproxy的证书打包进一个自定义的Android CA证书包，或者使用像VirtualXposed、平行空间这类应用，在应用内部安装证书。这是最常见的坑点！如果安装后仍抓不到小红书App的HTTPS包，大概率是证书没被App信任。
验证抓包：配置好代理并安装证书后，用手机浏览器访问任意HTTPS网站（如https://example.com），在运行mitmdump的终端里应该能看到相应的请求日志。

3.3 集成配置：让Appium驱动设备走Mitmproxy代理

仅仅在手机系统设置代理，Appium启动的App不一定走这个代理。我们需要在Appium的配置项（Capabilities）中明确指定代理。

修改之前的连接脚本，增加代理配置：

capabilities = { “platformName”: “Android”, # ... 其他原有配置 ... “appium:automationName”: “UiAutomator2”, “appium:appPackage”: “com.xingin.xhs”, “appium:appActivity”: “.activity.SplashActivity”, “appium:noReset”: True, “appium:newCommandTimeout”: 600, “appium:udid”: “your_device_serial”, # 关键：配置代理到Mitmproxy “appium:proxy”: { “proxyType”: “manual”, “httpProxy”: “192.168.1.100:8080”, # 你的电脑IP和Mitmproxy端口 “sslProxy”: “192.168.1.100:8080” } }

这样，通过Appium启动的小红书App，其网络流量就会强制经过我们指定的Mitmproxy代理。

4. 核心采集逻辑设计与实现

环境打通后，就进入了核心的脚本编写阶段。我们的程序将分为两大并行的部分：自动化操作引擎（Appium）和数据抓取解析引擎（Mitmproxy）。两者通过共享状态（如队列、数据库）进行通信。

4.1 基于Appium的自动化交互设计

Appium脚本的核心任务是模拟人的浏览路径。以采集“发现页”的笔记列表为例：

from appium.webdriver.common.appiumby import AppiumBy import time def crawl_note_list(driver, scroll_times=5): “”“模拟滑动浏览笔记列表”“” notes_info = [] for i in range(scroll_times): print(f“第 {i+1} 次滑动”) # 1. 等待页面稳定，可以添加更智能的等待，如等待某个元素出现 time.sleep(2) # 2. 获取当前屏幕内的笔记元素（以小红书为例，笔记通常在一个可滑动的列表里） # 需要通过Appium Inspector或UI Automator Viewer来定位元素 # 假设笔记的根布局可以通过某个resource-id或class定位 note_elements = driver.find_elements(AppiumBy.ID, “com.xingin.xhs:id/note_item_root”) for idx, element in enumerate(note_elements): try: # 3. 提取笔记的元信息（这些信息可能在抓包时更容易获得，这里演示UI获取） # 例如：获取笔记标题（可能不在UI，而在抓包数据里） # title_element = element.find_element(AppiumBy.ID, “com.xingin.xhs:id/title”) # title = title_element.text if title_element else “” # 更常见的操作是：点击进入详情页，由Mitmproxy抓取详情数据 element.click() time.sleep(1) # 等待详情页加载 # 触发详情页请求后，后退返回列表页 driver.back() time.sleep(0.5) except Exception as e: print(f“处理第{idx}个笔记时出错：{e}”) driver.back() # 确保退回列表页 continue # 4. 模拟上滑滑动，加载更多 screen_size = driver.get_window_size() start_x = screen_size[‘width’] * 0.5 start_y = screen_size[‘height’] * 0.8 end_y = screen_size[‘height’] * 0.2 driver.swipe(start_x, start_y, start_x, end_y, duration=800) time.sleep(2) # 等待新内容加载 return notes_info

实操心得2：UI自动化最头疼的是元素定位。小红书App的UI结构可能会随版本更新而变化。不要依赖绝对的位置坐标或不变的resource-id。应该使用相对定位和模糊匹配，例如通过find_elements(AppiumBy.CLASS_NAME, “android.widget.TextView”)找到所有文本视图，再通过文本内容过滤。同时，要加入充足的等待（推荐使用WebDriverWait和expected_conditions），确保元素加载完成再操作，这是脚本稳定性的关键。

4.2 基于Mitmproxy的请求拦截与数据解析

Mitmproxy的强大之处在于，我们可以编写一个addons脚本来拦截和处理每一个HTTP请求/响应。我们创建一个文件xhs_addon.py：

from mitmproxy import http, ctx import json import re from urllib.parse import urlparse, parse_qs import threading from queue import Queue # 定义一个全局队列，用于存储抓取到的数据，供主程序或其他线程消费 data_queue = Queue() class XHSCapture: def __init__(self): self.target_hosts = [‘edith.xiaohongshu.com’, ‘www.xiaohongshu.com’] # 小红书API域名 self.note_detail_pattern = re.compile(r‘/api/sns/v\d+/note/’) # 笔记详情API路径模式 def request(self, flow: http.HTTPFlow): “”“在请求发出前可以修改请求，这里我们主要用于过滤和标记”“” # 可以在这里添加请求头，或修改参数，但需谨慎以免触发风控 pass def response(self, flow: http.HTTPFlow): “”“在收到响应后处理，这是数据抓取的核心”“” # 1. 过滤非目标域名和非目标API的流量 if flow.request.host not in self.target_hosts: return if not self.note_detail_pattern.search(flow.request.path): # 可以添加其他API的pattern，如评论列表、用户信息等 return # 2. 检查响应状态码和内容类型 if flow.response.status_code != 200: ctx.log.warn(f“请求 {flow.request.url} 失败，状态码：{flow.response.status_code}”) return if ‘application/json’ not in flow.response.headers.get(‘Content-Type’, ‘’): return # 3. 解析JSON响应 try: response_text = flow.response.text data = json.loads(response_text) except Exception as e: ctx.log.error(f“解析JSON失败: {e}, URL: {flow.request.url}”) return # 4. 提取核心数据 (以笔记详情为例) if ‘data’ in data and ‘note’ in data[‘data’]: note_data = data[‘data’][‘note’] note_id = note_data.get(‘note_id’, ‘’) title = note_data.get(‘title’, ‘’) desc = note_data.get(‘desc’, ‘’) user_info = note_data.get(‘user’, {}) likes = note_data.get(‘likes’, 0) collects = note_data.get(‘collects’, 0) comments = note_data.get(‘comments’, 0) # 5. 结构化数据，放入队列 structured_note = { “note_id”: note_id, “title”: title, “description”: desc, “user_id”: user_info.get(‘user_id’), “user_name”: user_info.get(‘nickname’), “likes”: likes, “collects”: collects, “comments”: comments, “url”: flow.request.url, “timestamp”: time.time() } ctx.log.info(f“抓到笔记: {note_id} - {title[:20]}...”) data_queue.put(structured_note) # 可以继续处理其他API，如评论列表 # elif ‘/api/sns/v1/note/comment/list’ in flow.request.path: # # 解析评论数据... # 将addon实例化 addons = [XHSCapture()]

关键点解析：response方法是我们的主战场。我们通过flow.request.host和flow.request.path来精准过滤出小红书的数据API。小红书的数据接口通常返回JSON格式，结构相对清晰。重点在于分析其响应结构，找到目标数据所在的字段。上述代码仅展示了笔记详情，实际还需要处理笔记列表、评论列表、用户信息等多个接口。

4.3 双引擎协同与数据流整合

现在我们需要将Appium的“操作”和Mitmproxy的“抓取”结合起来。一个典型的架构是使用多线程：

主线程/进程：启动Mitmproxy服务器（嵌入我们的addon）。
子线程1：运行Appium自动化脚本，执行滑动、点击等操作，触发网络请求。
子线程2（或主线程循环）：监听data_queue，将抓取到的结构化数据写入数据库（如SQLite、MySQL）或文件。

import threading from mitmproxy.tools.main import mitmdump import subprocess import time from xhs_addon import data_queue # 导入上面定义的队列 def run_mitmproxy(): “”“在一个子进程中运行mitmdump”“” # 使用subprocess调用，将addon脚本作为参数传入 args = [‘mitmdump’, ‘-s’, ‘xhs_addon.py’, ‘-p’, ‘8080’, ‘—set’, ‘block_global=false’, ‘-q’] subprocess.run(args) def run_appium_automation(): “”“运行Appium自动化脚本”“” time.sleep(5) # 等待代理服务器启动 # 这里是之前编写的Appium驱动代码，启动driver并执行crawl_note_list等函数 # ... driver = init_appium_driver() crawl_note_list(driver, scroll_times=10) driver.quit() def save_data(): “”“从队列中取出数据并保存”“” import sqlite3 conn = sqlite3.connect(‘xhs_data.db’) c = conn.cursor() # 创建表... while True: if not data_queue.empty(): item = data_queue.get() # 插入数据库 c.execute(“INSERT INTO notes VALUES (?,?,?,?,?,?,?,?,?)”, (item[‘note_id’], item[‘title’], …)) conn.commit() print(f“已保存笔记: {item[‘note_id’]}”) time.sleep(0.1) if __name__ == ‘__main__’: # 启动数据保存线程 save_thread = threading.Thread(target=save_data, daemon=True) save_thread.start() # 启动Mitmproxy（由于mitmdump会阻塞，通常放在主进程或单独进程） mitm_thread = threading.Thread(target=run_mitmproxy, daemon=True) mitm_thread.start() # 主线程运行Appium自动化 run_appium_automation()

这个架构实现了松耦合的协同：Appium只管操作，Mitmproxy只管抓包解析，数据通过队列异步传递和处理。这样做的好处是，即使某一方出现短暂异常（如Appium元素定位失败），也不影响另一方的持续运行。

5. 高级技巧与稳定性优化

一套能跑起来的脚本和一套能在生产环境稳定运行数小时甚至数天的脚本，中间隔着巨大的鸿沟。以下是提升方案稳定性和效率的关键点。

5.1 反反爬策略与人性化模拟

小红书等平台有完善的风控体系，我们的自动化脚本必须尽可能地“像人”。

随机化操作：不要在固定的时间间隔进行点击或滑动。引入随机延迟，模拟人的反应时间。
```
import random def human_delay(min_s=1, max_s=3): time.sleep(random.uniform(min_s, max_s))
```
操作轨迹模拟：Appium的swipe是直线滑动，太机械。可以尝试使用TouchAction或W3C ActionsAPI模拟带曲线的滑动轨迹。
多样化操作：不要只滑动和点击笔记。可以随机地点击一下用户头像、浏览一下个人主页、偶尔点赞（需谨慎，避免账号异常），让行为序列更自然。
设备指纹管理：如果使用模拟器，注意其设备型号、IMEI、Android ID等指纹信息是固定的。长期运行容易被识别。可以考虑定期更换模拟器镜像，或者在真机上运行。
账号管理：绝对不要用一个账号进行高强度的采集。需要准备多个账号，并设置合理的切换策略和单账号每日操作上限。账号的活跃度、注册时间、资料完整度都会影响风控等级。

5.2 错误处理与自动恢复

脚本在长时间运行中必然会遇到各种异常：网络波动、元素定位失败、App崩溃、代理断开等。健壮的脚本必须具备自我恢复能力。

异常捕获与重试：对所有可能失败的操作（如find_element，click）进行try-except包裹，并加入重试逻辑。

from selenium.common.exceptions import NoSuchElementException, StaleElementReferenceException from tenacity import retry, stop_after_attempt, wait_fixed, retry_if_exception_type @retry(stop=stop_after_attempt(3), wait=wait_fixed(2), retry=retry_if_exception_type((NoSuchElementException, StaleElementReferenceException))) def safe_click(driver, by, value): element = driver.find_element(by, value) element.click()

心跳检测与重启：定期检查Appium Server连接、Mitmproxy进程是否存活，以及小红书App是否在前台。如果发现异常，可以自动重启Driver或整个相关进程。
状态快照与断点续传：将当前采集的进度（如已翻页数、最后采集到的笔记ID）定期保存到文件或数据库。当脚本因故障重启时，可以从断点处继续，避免数据重复或遗漏。

5.3 性能优化与数据管理

当采集量增大时，效率和数据管理成为问题。

请求过滤：在Mitmproxy的addon中，尽早过滤掉不关心的请求（如图片、字体、静态资源），减少解析负担。可以通过flow.request.path或flow.request.host进行精确匹配或正则排除。
异步处理：数据解析（JSON解析、字段提取）和存储（数据库写入）可能是I/O密集型操作。考虑使用异步库（如asyncio、aiohttp虽不直接适用，但思路是使用线程池）来避免阻塞抓包主线程。
数据去重：在存储前，根据笔记ID等唯一标识进行去重。可以在内存中使用布隆过滤器（Bloom Filter）进行快速判断，再结合数据库唯一索引确保最终一致性。
分布式扩展：单设备单账号的采集能力有上限。可以设计一个主控节点，管理多个“采集Worker”（每个Worker是一台手机+一个代理+一套脚本）。主控节点分配采集任务（如不同的关键词、不同的用户列表），Worker执行并上报结果。这涉及到更复杂的任务队列（如Redis + RQ/Celery）和状态同步机制。

6. 常见问题排查与实战心得

在实际部署和运行中，我遇到了不少坑，这里总结出最典型的几个问题及其解决方案。

6.1 抓包相关问题

问题现象	可能原因	排查步骤与解决方案
手机无法访问`mitm.it`	1. 手机代理设置错误（IP或端口）。 2. 电脑防火墙阻止了8080端口。 3. Mitmproxy未正常运行。	1. 检查手机Wi-Fi代理配置，确保IP和端口正确。 2. 在电脑上关闭防火墙或为8080端口添加入站规则。 3. 在终端执行 `netstat -an
能访问`mitm.it`但安装证书后仍抓不到HTTPS包	1. CA证书未正确安装或未被App信任（安卓高版本问题）。 2. 目标App使用了证书绑定（SSL Pinning）。	1.安卓高版本：尝试将证书安装到系统分区（需Root），或使用`VirtualXposed`等容器安装证书。 2.证书绑定：小红书可能使用了SSL Pinning。需要借助`Frida`、`Xposed`等框架进行Hook，绕过证书检查。这是进阶操作，复杂度陡增。一个更简单的测试方法是：尝试抓取其他App（如浏览器）的HTTPS流量，如果成功，则很可能是目标App的证书绑定问题。
Mitmproxy日志中看到`TLS handshake failed`	客户端不信任Mitmproxy的CA证书。	确保证书已正确安装并启用。对于安卓，在“设置->安全->信任的凭据->用户”中应能看到“mitmproxy”的证书。
Appium启动的App不走代理	Appium的Capabilities中未配置代理，或配置错误。	确保在Capabilities中正确设置了`appium:proxy`字段，且IP和端口与Mitmproxy服务一致。

6.2 Appium自动化相关问题

问题现象	可能原因	排查步骤与解决方案
找不到元素（NoSuchElementException）	1. 页面未加载完成。 2. 元素定位符（如ID）已随版本更新。 3. 元素在屏幕外或存在于不同的WebView/Flutter容器中。	1. 使用`WebDriverWait`配合`expected_conditions`进行显式等待。 2. 使用更稳定的定位策略，如通过`content-desc`、`text`或`XPath`结合部分文本匹配。 3. 使用`driver.page_source`打印当前页面XML结构，重新分析。对于混合应用，可能需要切换上下文（`driver.switch_to.context`）。
点击或滑动无效	1. 坐标计算错误。 2. 元素不可点击（如被遮挡）。 3. 系统弹窗（权限申请、更新提示）干扰。	1. 使用`element.click()`代替基于坐标的点击。滑动前获取正确的屏幕尺寸。 2. 检查元素属性`clickable`和`enabled`是否为true。 3. 在关键操作前，加入检查并处理系统弹窗的逻辑。
脚本运行一段时间后Appium Server断开	`newCommandTimeout`设置过短，或网络不稳定。	在Capabilities中增加`“appium:newCommandTimeout”: 600`（单位秒）。同时，在脚本中加入对`WebDriverException`的捕获和重连机制。
小红书App闪退或卡死	1. Appium操作速度过快，触发App内部保护。 2. 手机内存不足。 3. App本身存在bug。	1. 大幅增加操作间的延迟，加入随机等待时间。 2. 定期检查并清理手机后台进程。 3. 尝试降低小红书App的版本，有时新版本反爬更强。

6.3 数据与业务逻辑问题

抓到的数据是乱码或加密的：检查Mitmproxy是否成功解密了HTTPS。如果确认证书已安装，但响应体仍是乱码，可能是数据本身经过了额外的加密（如Protobuf序列化后又进行了自定义加密）。此时需要逆向分析App，找到解密算法，这在Mitmproxy的addon中实现解码。
列表页滑动多次后，数据不再更新：可能触发了小红书的反爬机制，如请求频率限制或非正常用户行为检测。解决方案是：1) 进一步降低操作频率；2) 模拟“下拉刷新”动作；3) 切换账号或休息一段时间。
如何采集评论等需要点击“展开”的数据：这需要Appium脚本在抓取详情页后，模拟点击“展开更多评论”的操作。通常需要先定位到该按钮元素。如果按钮文本是动态的（如“展开100条回复”），可以使用XPath的contains函数进行定位：//android.widget.TextView[contains(@text, ‘展开’)]。

最后的个人体会：这套方案的本质是在“自动化测试”和“数据采集”之间找到一个平衡点。它牺牲了纯粹协议破解的效率，换来了更高的稳定性和更低的逆向门槛。维护成本主要在于应对UI变化和风控策略升级。我的经验是，将元素定位信息、API路径匹配规则等易变部分抽象成配置文件，这样当App更新时，只需更新配置，而无需重写核心代码。此外，保持对采集行为的克制，模拟真实用户的浏览节奏，是项目能够长期稳定运行的生命线。数据采集是手段而非目的，合理、合法地使用数据才能创造价值。