【iOS逆向与安全】iOS MCP 获取 UI 节点的实现原理:为什么它比传统 WDA 更适合 AI 自动化?

如果你做过 iOS 自动化，大概率绕不开 WebDriverAgent，也就是大家熟悉的 WDA。

WDA 很经典，它把 XCTest 的能力封装成 WebDriver 接口，让 Appium 等工具可以操作 iPhone。

但到了 AI Agent 时代，需求发生了变化。

以前自动化测试关心的是：

我能不能通过 XPath / class chain 找到某个元素？

现在 AI 自动化更关心的是：

AI 能不能像人一样快速看懂当前屏幕，知道哪里可以点，然后直接执行操作？

这正是 iOS MCP 在 UI 节点获取方案上重新设计的原因。

一、先看效果：复杂 App 页面也能精准框出可操作节点

下面这张图，是 iOS MCP 对同花顺 App 多个页面获取 UI 节点后的效果。

左边是原始页面，右边是 iOS MCP 获取到的节点覆盖效果。

从图中可以看到，在「首页、行情、自选、交易、资讯、理财」等多个复杂页面中，iOS MCP 都能识别出大量可操作 UI 节点，并用矩形框标出节点范围，同时给出可点击坐标。

这类金融 App 页面非常复杂：

• 顶部 Tab 多；
• 内容区域密集；
• 列表数据多；
• 页面中存在大量文字、按钮、图标、卡片；
• 部分区域不是标准 UIKit 控件；
• 底部还有固定导航栏。

传统自动化框架面对这种页面，经常会返回一棵非常大的 XML 树，AI 需要再从复杂层级里自己推理。

而 iOS MCP 返回的是更直接的结果：

{"text": "立即开户","rect": {"x": 243,"y": 218,"width": 58,"height": 36  },"tap": {"x": 272,"y": 236  },"clickable": true}

也就是说，AI 不只是知道页面上有一个「立即开户」，还直接知道：

它在哪里，以及应该点哪个坐标。

这就是 iOS MCP UI 节点方案最核心的价值：它不是给 AI 一棵树，而是给 AI 一张可以直接执行的屏幕操作地图。

二、核心思路：不是遍历整棵树，而是生成 AI 可执行的操作地图

iOS MCP 中获取 UI 节点的工具是：

get_ui_elements

入口位于：

MCPServer.m

核心调用链大致如下：

MCPServer.m  -> executeGetUIElementsAccessibilityManager.m  -> getCompactUIElementsWithMaxElementsMCPAXRemoteContextResolver.m  -> frontmostContextMCPAXAttributeBridge.m  -> AXRuntime direct bridgeMCPAXNodeSource.m  -> compactElementsForPid

传统方案一般是：

拿到完整 UI 树 -> 递归遍历 children -> 转成 XML / JSON -> 再由上层查询

而 iOS MCP 的思路是：

先定位当前前台 App -> 直接连接 AXRuntime -> 获取系统级候选节点集合 -> 合并可见节点、语义节点、可聚焦节点、hit-test 节点 -> 输出 compact 可点击列表

它不是先生成一棵巨大的树，而是直接获取 AI 最需要的东西：

当前屏幕有哪些可见元素？哪些元素可点击？它们的文本是什么？它们的位置在哪里？推荐点击坐标是多少？

三、实现流程一：精准定位前台 App

在获取 UI 节点之前，iOS MCP 会先解析当前前台 App 的上下文。

核心类是：

MCPAXRemoteContextResolver

它会尝试从多个系统来源获取信息：

AXFrontBoardFocusedAppsAXFrontBoardFocusedAppProcessAXFrontBoardVisibleAppProcessesAXFrontBoardFocusedAppPIDSpringBoard _accessibilityFrontMostApplicationWorkspace ScenesCADisplay.mainDisplay.displayId

最终得到：

pidbundleIdprocessNamesceneIdentifiercontextIddisplayId

这一步非常关键。

因为在 iOS 上，一个 App 不只是一个进程，它还和 scene、window context、display id、Accessibility runtime 状态有关。

WDA 更多是站在 XCTest 的视角看 App；iOS MCP 则是站在 SpringBoard 和 AXRuntime 的视角看整个系统当前状态。

四、实现流程二：直接绑定 AXRuntime

iOS MCP 的底层桥接在：

MCPAXAttributeBridge.m

它会动态绑定 AXRuntime 相关符号，例如：

AXUIElementCreateApplicationAXUIElementCreateSystemWideAXUIElementCopyAttributeValueAXUIElementCopyMultipleAttributeValuesAXUIElementCopyParameterizedAttributeValueAXUIElementCopyElementAtPositionAXUIElementCopyElementWithParametersAXUIElementCopyElementUsingContextIdAtPositionAXUIElementGetPid_AXAddAssociatedPid__AXSetRequestingClient_AXOverrideRequestingClientType

也就是说，iOS MCP 不是通过 XCTest 间接获取 UI，而是直接进入系统 AXRuntime。

它还会执行：

ensureAssociationWithRemotePid(pid)

这一步会把当前进程和目标 App 的 pid 做 AX 关联，让当前服务具备读取目标 App 无障碍节点的能力。

这也是 iOS MCP 能够在 SpringBoard 侧直接获取前台 App UI 节点的关键。

五、实现流程三：直接读取系统候选节点集合

真正厉害的地方在：

MCPAXNodeSource.m

核心方法是：

compactElementsForPid

iOS MCP 会创建目标 App 的 AX 元素：

AXUIElementCreateApplication(pid)

然后读取一组系统内部的 numeric AX attributes：

3015 visibleElements3025 elementsWithSemanticContext3022 explorerElements3029 nativeFocusableElements3031 siriContentNativeFocusableElements3032 siriContentElementsWithSemanticContext5001 children

这些属性非常关键。

它们不是普通自动化框架常用的公开 UI 树属性，而是更接近系统无障碍运行时内部的候选节点集合。

可以理解为：

iOS MCP 直接问系统：当前屏幕上有哪些元素是可见的、可语义理解的、可聚焦的、适合无障碍操作的？

这比单纯递归 children 更适合 AI。

六、实现流程四：多源融合，生成 AI 友好的节点

iOS MCP 不只读取一个来源，而是融合多类数据。

6.1 Numeric AX attributes

例如：

labelframevaluewindowContextIdwindowDisplayId

6.2 XC attributes

例如：

framelabelvaluevisibleFrameisVisiblewindowContextIdwindowDisplayId

6.3 Direct private attributes

例如：

centerPointfocusableFrameForZoomuserInputLabelsvisibleFrame

最后统一归一化成 compact element：

textrectvisible_recttapclickableindexidpath

这就是为什么效果图中可以看到大量红框精准覆盖在真实 UI 上。

iOS MCP 不只是拿到了文本，还拿到了：

节点范围可见范围推荐点击点是否可点击节点索引

这对 AI 来说非常友好。

七、实现流程五：采样 hit-test 补洞

iOS MCP 还有一个很实用的机制：

compact_numeric_candidate_arrays_sampled_hits

也就是：

候选节点数组 + 屏幕采样 hit-test 合并。

它会在屏幕上选择多个探测点，然后调用底层 hit-test：

AXUIElementCopyElementWithParametersAXUIElementCopyElementAtPositionWithParamsAXUIElementCopyElementAtPosition

如果候选数组漏掉了某些节点，采样 hit-test 可能把它补回来。

所以 iOS MCP 的节点获取不是单点依赖，而是：

App 级候选节点+ Window 级候选节点+ 采样 hit-test 节点+ 多源属性融合+ fingerprint 去重+ compact 输出

这也是它在复杂页面中表现稳定的原因。

本地抓到的同花顺首页结果中，可以看到类似信息：

{"source": "direct_ax_compact_attribute_crawl","direct_ax_strategy": "compact_numeric_candidate_arrays_sampled_hits","bundleId": "cn.com.10jqka.IHexin","root_count": 202,"serialized_candidate_count": 61,"element_count": 61}

返回的节点里直接包含：

用户861994940消息中心搜索查看所需材料立即开户同花顺热榜学投资模拟炒股

每个节点都带有可点击坐标。

对 AI Agent 来说，这就是“可执行的屏幕理解”。

八、对比 WDA：XCTest Snapshot 树 vs AXRuntime 操作地图

WDA 的 /source 实现在：

WebDriverAgentLib/Commands/FBDebugCommands.m

核心逻辑是：

FBApplication *application = request.session.application ?: [FBApplication fb_activeApplication];[application fb_waitUntilSnapshotIsStable];result = [FBXPath xmlStringWithSnapshot:application.fb_lastSnapshot];

JSON 树则来自：

XCUIApplication+FBHelpers.m

核心逻辑是：

return [self.class dictionaryForElement:self.fb_lastSnapshot];

而 dictionaryForElement 本质上是递归遍历：

snapshot.children

然后输出：

typerawIdentifiernamevaluelabelrectframeisEnabledisVisiblechildren

所以 WDA 的路径可以概括为：

XCTest -> XCUIApplication -> XCElementSnapshot -> snapshot.children -> XML / JSON -> XPath 查询

而 iOS MCP 的路径是：

SpringBoard / MCP Server -> frontmost pid/context/display -> AXRuntime direct bridge -> numeric candidate arrays -> sampled hit-test -> compact actionable elements

九、为什么 iOS MCP 更适合 AI Agent？

9.1 WDA 输出的是测试树，iOS MCP 输出的是操作地图

WDA 的 XML / JSON 很适合测试脚本。

但 AI 更需要的是：

{"text": "搜索","tap": {"x": 145,"y": 42  },"clickable": true}

AI 拿到之后可以直接决策：

我要点击搜索框，坐标是 145,42。

9.2 WDA 依赖 XCTest snapshot，iOS MCP 直连 AXRuntime

WDA 的优势是 WebDriver 生态。

但 iOS MCP 更靠近系统无障碍运行时，能拿到更多系统内部候选节点，例如：

visibleElementselementsWithSemanticContextnativeFocusableElementssiriContentElementsWithSemanticContext

这让 iOS MCP 更像是在复用系统给 VoiceOver / Siri 使用的语义视图。

9.3 iOS MCP 有 contextId / displayId 感知

iOS MCP 不只知道 App 的 pid，还知道：

sceneIdentifiercontextIddisplayIdAXRuntime 状态Accessibility registrar 状态解析路径 trace

这对复杂场景非常重要。

9.4 iOS MCP 返回结果更短、更直接、更适合模型

传统 XML 很大，层级深，噪声多。

iOS MCP compact UI 节点更像这样：

index: 7text: 立即开户rect: 243,218,58,36tap: 272,236clickable: true

这对大模型来说更容易理解，也更容易执行。

十、总结：WDA 是测试时代经典，iOS MCP 是 AI Agent 时代控制层

WDA 是 iOS 自动化测试时代的经典方案。

它的核心是：

XCTest snapshot + XML/JSON tree + XPath 查询

而 iOS MCP 面向的是 AI Agent 时代。

它的核心是：

AXRuntime 直连+ 系统候选节点+ 多源属性融合+ hit-test 补洞+ compact 可点击列表+ MCP 工具协议

如果说 WDA 提供的是：

给测试脚本看的 UI 树

那么 iOS MCP 提供的是：

给 AI Agent 用的屏幕行动地图

它不只是告诉 AI 屏幕上有什么，还直接告诉 AI：

这个节点叫什么？它在哪里？是否可见？是否可点？应该点哪个坐标？属于哪个 App / pid / context / display？

这就是 iOS MCP UI 节点获取方案真正厉害的地方。

在 AI 自动化时代，UI 节点不应该只是 XML。

它应该是模型可以直接理解、直接决策、直接执行的操作地图。

而这，正是 iOS MCP 正在做的事情。

十一、开源地址

iOS MCP 已开源，欢迎 Star、Issue、PR，也欢迎一起交流 iOS 设备自动化、AI Agent 控机、AXRuntime、越狱环境下的系统能力调用等相关技术。

项目地址：

https://github.com/witchan/ios-mcp

GitHub：

https://github.com/witchan/ios-mcp

十二、社区交流

iOS MCP 已经聚集了不少开发者和用户持续交流，目前已建立多个微信交流群。

微信交流群（6群开放中）	公众号
1群：已满2群：已满3群：已满4群：已满5群：已满6群：开放中	移动端Android和iOS开发技术分享

6 群二维码如已过期，请添加微信 witchan028 或关注公众号 移动端Android和iOS开发技术分享 获取最新入群方式。

欢迎添加微信或关注公众号，获取最新动态与入群方式。

• 微信：witchan028
• 邮箱：witchan028@126.com