本文深入探讨了 AI 驱动人机交互的技术前沿，重点关注基于无障碍服务的 UI 自动化方案。文章首先介绍了无障碍服务的本质和原理，阐述了其在 UI 自动化中的优势，包括确定性高、性能优越、稳定可靠和信息丰富等特性。接着，文章分析了 AccessKit.dev 和 Droidrun.ai 等通用 UI 访问层的设计与实现，并探讨了 mobile-mcp 作为 MCP Server 的实验性实践。最后，文章展望了 AG-UI 协议的革命性作用以及三技术融合构建下一代智能交互生态的可能性。

📌 无障碍服务不仅是为残障人士设计的辅助功能，它也是一个完整的 UI 语义层，为自动化测试和 AI 交互提供了理想的技术基础。开发者往往低估了其作为技术金矿的价值。

🖥️ 不同操作系统实现无障碍服务的方式存在显著差异，如 Windows 的 UI Automation API、macOS/iOS 的 NSAccessibility 协议、Linux/Unix 的 AT-SPI 协议和 Android 的 AccessibilityService API。这种碎片化给跨平台应用开发带来了巨大挑战。

🔍 基于无障碍服务的 UI 自动化方案相比基于图像识别的方案具有以下优势：确定性高、性能优越、稳定可靠、信息丰富，且维护成本低。无障碍服务的 UI 树结构天然适合自动化场景，避免了图像处理的计算开销和视觉歧义问题。

🌐 AccessKit.dev 提出了一个根本性的问题：为什么不能像设计图形渲染管道一样，为无障碍功能设计一个通用的抽象层？它建立了更高层次的抽象，能够表达现代 UI 的复杂性，并映射到各种平台 API 的特定要求上。

🔄 AccessKit 采用推送式架构，UI 工具包主动将完整的辅助功能树信息和后续的增量更新推送给平台适配器，而不是等待适配器按需拉取。这种设计避免了复杂的同步问题，减少了进程间通信的开销，并保证了状态的一致性。

原创 张汉东 2025-08-31 21:48 河北

这是你用当前世界上最好的 Deep Research AI 工具都做不到的系统前沿又保持深度细节的报告。

大会购票通道已开启，早鸟票限量发售中！立即扫码或打开链接抢购：

 https://hangzhou2025.gosim.org/tickets/

前言

随着 AI Agent 技术的逐步成熟，AI 驱动的 UI 自动化测试与交互技术也逐步崭露头角。

我在今年四月份也写过 《AgentKit：基于 Rust 构建通用 AI 自动化人机交互的技术构想》 ，并在今年 7 月的 COC 大会上分享过我之前的一些 PoC 实验结果。

我对这一切的兴趣点始于 Accesskit.dev 和 Droidrun 这两个项目。这周又听闻 Droidrn.ai 这家公司融资融到了 200 万欧元[1]，顿感这项技术是一个非常值得研究的领域，于是就有了这篇文章。

本文会从 Accessbility 无障碍服务讲起，然后再分析 Acesskit.dev 和 Droidrun 的技术栈，先讲清楚实现原理，然后再引出 mobile-mcp 这样的 mcp server ，以及我对它的实验结果。

在写这份报告的时候，适逢阿里开源了其GUI Agent第三代框架：Mobile-Agent-v3[2]，据说在 10+GUI 基准测试中取得了 SOTA 性能。

“这是你用当前世界上最好的 Deep Research AI 工具都做不到的系统前沿又保持深度细节的报告。

大纲：

从无障碍到自动化：Accessbility 服务的原理与应用

Accesskit.dev：通用 UI 访问层的设计与实现

Droidrun.ai：基于无障碍的移动端自动化探索与现状

mobile-mcp：作为 MCP Server 的实验性实现与实践结果

AG-UI：重新定义 AI 驱动人机交互的协议革命

三技术融合畅想：构建下一代智能交互生态

阿里 GUI Agent第三代框架：Mobile-Agent-v3

总结

一、从无障碍到自动化：Accessibility 服务的原理与应用

1.1 无障碍服务的本质：一个被低估的技术金矿无障碍服务（Accessibility Service）最初是为了帮助视觉、听觉或运动能力受限的用户而设计的系统级服务。它通过暴露应用程序的 UI 结构信息，让辅助技术（如屏幕阅读器）能够理解并操作界面。

但很多开发者认为无障碍服务只是为残障人士设计的辅助功能。这就是陷入一个误区了。

这套系统其实是操作系统提供的一个完整的 UI 语义层，它就像是应用界面的"源代码"——不是你看到的渲染结果，而是描述"这是什么"和"能做什么"的结构化数据。

在技术层面，无障碍服务的核心是构建了一个语义化的 UI 树（Accessibility Tree）。这个树结构包含了界面上每个元素的：

角色（Role）：按钮、文本框、列表等

状态（State）：选中、禁用、展开等

属性（Properties）：标签、描述、值等

动作（Actions）：点击、滚动、输入等

举个最简单的例子。当你看到一个购物车图标时，你的大脑会识别出"这是个按钮，点击可以查看购物车"。但对计算机来说，这只是一堆像素。而无障碍服务提供的信息是这样的：

// 来自 AccessKit 的节点定义pubstruct Node {    role: Role,  // 元素类型：按钮、文本框、列表等    actions: Vec<Action>,  // 支持的操作：点击、滚动、输入等    text_selection: Option<TextSelection>,  // 文本选择状态    bounds: Option<Rect>,  // 位置和大小    // ... 还有几十个属性}// 当你查询一个购物车按钮时，得到的不是像素，而是这样的结构化数据impl NodeWrapper<'_> {    fn class_name(&self) -> &str {        matchself.0.role() {            Role::Button => {                ifself.0.supports_toggle() {                    "android.widget.ToggleButton"// 可切换的按钮                } else {                    "android.widget.Button"// 普通按钮                }            }            Role::TextInput | Role::SearchInput => "android.widget.EditText",            Role::CheckBox => "android.widget.CheckBox",            // ... 每种 UI 元素都有明确的语义映射        }    }}

看到区别了吗？这不是图像识别，这是应用主动告诉系统的精确信息。每个 UI 元素都像是自带了一份说明书。

更有意思的是，这套机制从一开始就考虑了程序化操作。

// 不是模拟触摸，而是直接触发事件处理器impl Adapter {    fn perform_simple_action<H: ActionHandler>(        &mutself,        action_handler: &mut H,        virtual_view_id: jint,        action: jint,    ) -> Option<QueuedEvents> {        let request = match action {            ACTION_CLICK => ActionRequest {                action: {                    // 智能决策：如果元素可聚焦但未聚焦，先聚焦再点击                    let node = tree_state.node_by_id(target).unwrap();                    if node.is_focusable(&filter)                         && !node.is_focused()                         && !node.is_clickable(&filter) {                        Action::Focus                    } else {                        Action::Click                    }                },                target,                data: None,            },            // ... 其他动作的处理        };        action_handler.do_action(request);    }}

当你调用 perform_simple_action 时，系统不是在模拟触摸屏幕的物理动作，而是直接触发了按钮的点击事件处理器。这意味着即使 UI 动画还没播放完，即使按钮被其他浮层部分遮挡，操作依然能成功执行。

1.2 平台实现的深层差异：魔鬼在细节中表面上看，各平台都提供了无障碍 API，但实际用起来你会发现，这简直是完全不同的世界。

不同操作系统实现无障碍服务的方式存在显著差异：

Windows 平台：使用 UI Automation API，这是微软当前推荐的无障碍接口，替代了早期的 MSAA（Microsoft Active Accessibility）。

macOS/iOS 平台：通过 NSAccessibility 协议和 UIAccessibility 框架，Apple 构建了一套完整的无障碍体系。

Linux/Unix 平台：采用 AT-SPI（Assistive Technology Service Provider Interface）协议，通过 D-Bus 进行进程间通信。

Android 平台：基于 AccessibilityService API，提供了丰富的界面查询和操作能力。

这种碎片化给跨平台应用开发带来了巨大挑战。开发者需要针对每个平台单独实现无障碍支持，不仅增加了开发成本，还容易出现功能不一致的问题。

拿 Android 系统来说。

Android 的 AccessibilityService 可能是最强大的，但也是最混乱的。你能想象吗，不同厂商的 ROM 会有不同的行为：

// 小米 MIUI 的一个坑AccessibilityNodeInfo node = getRootInActiveWindow();// 在 MIUI 12+ 上，某些系统应用的节点信息会被"优化"掉// 你得到的可能是个残缺的树结构// 解决方案：使用多种方式交叉验证if (node.getChildCount() == 0 && !TextUtils.isEmpty(node.getClassName())) {    // 可能是 MIUI 的优化，尝试通过其他方式获取    List<AccessibilityNodeInfo> nodes = node.findAccessibilityNodeInfosByText("...");}

更糟糕的是权限管理。在 Android 10 之后，即使用户授予了无障碍权限，某些操作（比如模拟手势）还需要额外的权限。而这些权限在不同厂商的设置界面里位置都不一样。

iOS 的情况则恰好相反。

UIAccessibility 框架设计得很优雅，但苹果把它锁得死死的：

// iOS 上你只能在自己的应用内使用无障碍 API// 想要跨应用？除非你：// 1. 越狱// 2. 使用 XCUITest（仅限开发/测试环境）// 3. 通过 MDM 配置（企业场景）// 这就是为什么 iOS 上没有类似 Android 的 TalkBack 第三方实现

但 iOS 有个优势：一致性。

你为 iPhone 5s 写的无障碍代码，在 iPhone 15 Pro 上基本能无缝运行。没有厂商定制，没有碎片化，这在 Android 世界是不可想象的。

Windows 的情况最复杂。

你需要面对的不是一套 API，而是好几代技术的叠加：

// 老应用可能还在用 MSAAIAccessible* pAcc;AccessibleObjectFromWindow(hwnd, OBJID_CLIENT, IID_IAccessible, (void**)&pAcc);// 新应用用 UI AutomationIUIAutomation* pAutomation;pAutomation->ElementFromHandle(hwnd, &pElement);// WPF 应用有自己的实现// UWP/WinUI 又是另一套// Electron 应用... 算了，那是个 Chromium

最要命的是，很多 Windows 应用根本没实现无障碍接口。你经常会遇到这种情况：整个窗口在无障碍树里就是一个巨大的空白节点。这时候你只能退回到基于坐标的点击，然后祈祷用户别改分辨率。

1.3 真实世界的技术决策：为什么无障碍优于视觉识别无障碍服务的 UI 树结构天然适合自动化场景。相比基于图像识别的方案，它具有以下优势：

确定性高：直接获取 UI 元素的结构化数据，无需处理视觉歧义

性能优越：避免了图像处理的计算开销

稳定可靠：UI 更新时，只要元素的语义不变，自动化脚本就能继续工作

信息丰富：包含了元素的完整上下文信息，便于智能决策

正是这些特性，让无障碍服务成为了 AI 驱动 UI 自动化的理想技术基础。

我见过太多项目一开始选择了计算机视觉方案，然后在实际部署时被各种边缘情况折磨得死去活来。（请读者记住这句话，后文实践部分会呼应这里）

性能对比

# 基于视觉的方案def find_button_by_image(screenshot, template):    # OpenCV 模板匹配    result = cv2.matchTemplate(screenshot, template, cv2.TM_CCOEFF_NORMED)    # 平均耗时：150-300ms（取决于图像大小）    # 准确率：85-95%（受光照、分辨率、主题影响）# 基于无障碍的方案  def find_button_by_accessibility(root_node, identifier):    # 遍历节点树    node = root_node.findAccessibilityNodeInfosByViewId(identifier)    # 平均耗时：5-20ms    # 准确率：99.9%（除非应用崩溃）

但这还不是关键。真正的问题在于维护成本。

维护噩梦 vs 一劳永逸

基于视觉的方案，每次 UI 改版你都得重新录制模板图片。暗色模式？重录。高分辨率屏幕？重录。换了个图标？重录。我曾经维护过一个基于图像识别的自动化系统，光是模板图片就有 2000 多张，分别对应不同的设备、分辨率、主题。每次应用更新都是一场灾难。

而基于无障碍的方案呢？只要开发者没有改变元素的 resource-id 或 accessibility identifier，你的代码就能继续工作。即使改了，通常也能通过其他属性组合定位到。

// 灵活的定位策略AccessibilityNodeInfo findNode(AccessibilityNodeInfo root) {    // 优先使用 resource-id    List<AccessibilityNodeInfo> nodes = root.findAccessibilityNodeInfosByViewId("com.app:id/submit_button");        if (nodes.isEmpty()) {        // 退而求其次，使用文本        nodes = root.findAccessibilityNodeInfosByText("提交");    }        if (nodes.isEmpty()) {        // 最后的手段，使用结构特征        // 比如"第三个可点击的按钮"        nodes = findByStructure(root,             node -> node.isClickable() &&                     "android.widget.Button".equals(node.getClassName()),            3);    }        return nodes.isEmpty() ? null : nodes.get(0);}

隐藏信息的获取

这是个经常被忽视的优势。无障碍树包含了很多视觉上看不到的信息：

impl NodeWrapper<'_> {    // 获取完整的语义信息，包括不可见的    fn content_description(&self) -> Option<String> {        self.0.label()  // 可能包含完整的订单号、状态等    }        pub(crate) fn text_selection(&self) -> Option<(usize, usize)> {        // 获取精确的文本选择范围        if !self.is_focused() {            returnNone;        }        self.0.text_selection().map(|range| {            (                range.start().to_global_utf16_index(),                range.end().to_global_utf16_index(),            )        })    }        // 滚动位置信息 - 视觉识别几乎不可能准确获取    pub(crate) fn scroll_x(&self) -> Option<jint> {        self.0.scroll_x()            .map(|value| (value - self.0.scroll_x_min().unwrap_or(0.0)) as jint)    }}

这些额外信息对自动化测试极其宝贵。你不需要 OCR 识别订单号，不需要解析金额格式，所有信息都已经结构化了。

无障碍服务不仅仅是为视障用户准备的——它是自动化测试和 AI 交互的最佳技术基础。只是大多数开发者还没意识到这个宝藏的存在。

二、AccessKit.dev：通用 UI 访问层的设计与实现

2.1 重新思考无障碍基础设施当我们回顾现代 UI 开发的演进历程时，会发现一个有趣的现象：虽然跨平台 UI 框架层出不穷，但无障碍功能的实现往往成为最后的拦路虎。传统的解决方案要么是每个平台单独实现，要么是简单粗暴地包装系统 API。

AccessKit[3] 的出现打破了这种局面，它提出了一个根本性的问题：为什么不能像我们设计图形渲染管道一样，为无障碍功能设计一个通用的抽象层？

这个问题的答案并不简单。

就像前文描述的那样，无障碍 API 在不同平台上差异巨大：Windows 的 UI Automation 基于 COM 对象模型，macOS 的 NSAccessibility 围绕 Objective-C 协议设计，而 Linux 的 AT-SPI 则采用了 D-Bus 消息传递机制。更复杂的是，这些 API 的语义模型也不完全一致——同样是一个按钮，在不同平台上可能需要暴露不同的属性和行为。

AccessKit 的创新在于它没有试图寻找这些 API 的最小公约数，而是建立了一个更高层次的抽象。这个抽象足够丰富，能够表达现代 UI 的复杂性，同时又足够灵活，能够映射到各种平台 API 的特定要求上。

这样的抽象完全是基于 Rust 语言特性，这就是为什么 Accesskit 选择使用 Rust 语言实现。

// accesskit/src/lib.rs - 核心数据模型// 注意：这不是各平台的交集，而是超集#[derive(Clone, Debug, PartialEq)]pubstruct Node {    // 基础属性 - 所有平台都有    role: Role,    bounds: Option<Rect>,        // 富文本支持 - 并非所有平台都原生支持    text_selection: Option<TextSelection>,    text_direction: TextDirection,        // 高级交互 - 某些平台需要模拟实现    custom_actions: Vec<CustomAction>,        // Web 特有但其他平台也可能用到    auto_complete: Option<AutoComplete>,    has_popup: Option<HasPopup>,        // 数值控制 - 不是所有平台都有原生支持    numeric_value: Option<f64>,    min_numeric_value: Option<f64>,    max_numeric_value: Option<f64>,    numeric_value_step: Option<f64>,    numeric_value_jump: Option<f64>,        // 表格支持 - 需要复杂映射    table_row_count: Option<usize>,    table_column_count: Option<usize>,    row_index: Option<usize>,    column_index: Option<usize>,        // 关系属性 - 超越简单的父子关系    controls: Vec<NodeId>,    details: Vec<NodeId>,    described_by: Vec<NodeId>,    flow_to: Vec<NodeId>,    labelled_by: Vec<NodeId>,        // ... 还有 50+ 个属性}

看到了吗？AccessKit 定义了一个超集，包含了所有平台可能需要的属性，而不是找它们的公共部分。

// 不是找最简单的通用角色，而是定义完整的语义体系#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]pubenum Role {    // 基础角色 - 所有平台都有    Button,    CheckBox,    Image,    Link,        // ARIA 角色 - 主要来自 Web    Article,    Banner,    Complementary,    ContentInfo,    Feed,    Figure,    Form,    Main,    Navigation,    Region,    Search,        // 桌面应用特有    TitleBar,    MenuBar,    ScrollBar,        // 移动端特有      Switch,  // iOS 的 UISwitch        // 文档结构 - 来自多个来源    DocAbstract,    DocAcknowledgements,    DocAfterword,    DocAppendix,    DocBackLink,    DocBiblioEntry,    DocBibliography,    DocBiblioRef,    // ... 30+ 文档相关角色        // 数学内容 - 来自 MathML    MathRoot,    MathSquareRoot,    MathFraction,        // 总共 100+ 种角色}

每个平台适配器负责将这个丰富的抽象映射到平台特定的 API：

// platforms/windows/src/adapter.rsimpl NodeWrapper {    // Windows UI Automation 的映射    fn control_type(&self) -> ControlType {        matchself.role() {            // 直接映射            Role::Button => ControlType::Button,            Role::CheckBox => ControlType::CheckBox,                        // 智能映射 - 多个 AccessKit 角色映射到一个 Windows 控件类型            Role::Article | Role::Section | Role::Region => ControlType::Group,                        // 复杂映射 - 根据上下文决定            Role::TextInput => {                ifself.is_multiline() {                    ControlType::Edit  // 多行文本框                } elseifself.is_password() {                    ControlType::Edit  // 密码框（通过其他属性区分）                } else {                    ControlType::Edit  // 单行文本框                }            }                        // 模拟映射 - Windows 没有对应的控件类型            Role::Feed => ControlType::List,  // 用列表模拟 Feed            Role::Math => ControlType::Text,   // 数学内容降级为文本                        // 默认处理            _ => ControlType::Custom,        }    }}// platforms/android/src/node.rs  impl NodeWrapper<'_> {    // Android 的类名映射 - 完全不同的映射策略    fn class_name(&self) -> &str {        matchself.0.role() {            // Android 有 EditText 的各种变体            Role::TextInput | Role::MultilineTextInput => "android.widget.EditText",            Role::SearchInput => "android.widget.SearchView",                        // Android 特有的映射            Role::Slider => "android.widget.SeekBar",            Role::Switch => "android.widget.Switch",                        // 降级处理 - Android 没有对应的控件            Role::DocBibliography | Role::DocEndnotes => "android.view.View",                        // 组合映射 - 用多个 Android 属性表达一个 AccessKit 角色            Role::ToggleButton => {                // 通过额外的属性来区分                "android.widget.ToggleButton"            }                        _ => "android.view.View",        }    }}// platforms/macos/src/adapter.rsimpl NodeWrapper {    // macOS 的角色映射 - 又是另一套体系    fn ax_role(&self) -> CFString {        matchself.role() {            // macOS 特有的角色            Role::Window => unsafe { AXRoleWindow },            Role::Sheet => unsafe { AXRoleSheet },            Role::Drawer => unsafe { AXRoleDrawer },                        // 子角色机制 - macOS 用角色+子角色的组合            Role::List => {                ifself.is_menu() {                    unsafe { AXRoleMenu }                } else {                    unsafe { AXRoleList }                }            }                        // 找不到对应时的创造性映射            Role::Feed => unsafe { AXRoleGroup },  // 用 Group + 描述来表达 Feed                        _ => unsafe { AXRoleUnknown },        }    }}

然后是统一行为的抽象

// 核心动作定义 - 语义层面#[derive(Clone, Copy, Debug, PartialEq, Eq)]pubenum Action {    Click,  // 语义：激活元素    Focus,  // 语义：获取键盘焦点        // 滚动动作 - 不同平台实现方式完全不同    ScrollUp,    ScrollDown,    ScrollLeft,    ScrollRight,    ScrollToPoint,        // 文本动作 - 需要复杂的平台映射    SetTextSelection,    ReplaceSelectedText,        // 自定义动作 - 超越平台限制    CustomAction,}// Android 平台的动作映射impl Adapter {    fn perform_simple_action(&mutself, action: jint) -> Option<QueuedEvents> {        let request = match action {            // Android 的 SCROLL_FORWARD 可能是向右或向下            ACTION_SCROLL_FORWARD => {                let node = tree_state.node_by_id(target).unwrap();                ifletSome(orientation) = node.orientation() {                    match orientation {                        Orientation::Horizontal => Action::ScrollRight,                        Orientation::Vertical => Action::ScrollDown,                    }                } else {                    // 智能推断滚动方向                    if node.supports_action(Action::ScrollDown, &filter) {                        Action::ScrollDown                    } else {                        Action::ScrollRight                    }                }            }            // ... 其他 Android 特定动作的映射        }    }}

最关键是 增量更新 抽象：

// 不是找最简单的更新方式，而是设计最优的更新模型pubstruct TreeUpdate {    pub nodes: Vec<(NodeId, NodeData)>,  // 变更的节点    pub tree: Option<Tree>,              // 可选的树结构更新    pub focus: NodeId,                   // 焦点变化}// 每个平台用自己的方式处理这个统一模型impl Tree {    pubfn update_and_process_changes(        &mutself,        update: TreeUpdate,        handler: &mutdyn TreeChangeHandler,    ) {        // 统一的更新处理逻辑        let changes = self.compute_changes(&update);                // 平台特定的处理器        #[cfg(target_os = "windows")]        handler.handle_uia_changes(&changes);                #[cfg(target_os = "android")]        handler.handle_android_events(&changes);                #[cfg(target_os = "macos")]        handler.handle_ax_notifications(&changes);    }}

最后，AccessKit 能够优雅地支持多平台的秘密，是通过精心设计的少量关键 trait 和 Rust 的强类型系统 。

最关键的两个 trait：ActivationHandler 和 TreeChangeHandler

// accesskit/src/handler.rs// 这是平台与应用之间的核心契约/// 激活处理器 - 应用必须实现这个 traitpubtrait ActivationHandler {    /// 请求初始的无障碍树    fn request_initial_tree(&mutself) -> Option<TreeUpdate> {        None    }        /// 当平台激活无障碍功能时调用    fn activate(&mutself, _updater: TreeUpdater) {}        /// 当平台停用无障碍功能时调用    fn deactivate(&mutself, _updater: TreeUpdater) {}}/// 动作处理器 - 应用必须实现来响应用户操作pubtrait ActionHandler {    /// 执行请求的动作    fn do_action(&mutself, request: ActionRequest);}// accesskit_consumer/src/tree.rs/// 平台适配器必须实现这个 trait 来处理树的变化pubtrait TreeChangeHandler {    fn node_added(&mutself, node: &Node);        fn node_updated(&mutself, old_node: &Node, new_node: &Node);        fn node_removed(&mutself, node: &Node);        fn focus_moved(&mutself, old_node: Option<&Node>, new_node: Option<&Node>);}// Android 平台的实现impl TreeChangeHandler for AdapterChangeHandler<'_> {    fn node_updated(&mutself, old_node: &Node, new_node: &Node) {        // Android 特定：生成 Android 事件        if old_text != new_text {            self.events.push(QueuedEvent::TextChanged {                virtual_view_id: id,                old: old_text.unwrap_or_else(String::new),                new: new_text.clone().unwrap_or_else(String::new),            });        }    }}// Windows 平台会有完全不同的实现// macOS 平台也会有自己的实现

这两个 trait 是 Rust 反向依赖注入的精髓：平台适配器不知道应用的具体实现，只依赖这些接口。

AccessKit 源码还有很多精妙设计，这里就不再赘述。

2.2 从 Chromium 到 AccessKit：设计演进的智慧

AccessKit 的首席作者 Matt 是一位法定盲人开发者，在无障碍领域已经工作了 20 多年。

“这次九月在杭州办的 RustChinaConf 2025 本来计划邀请该团队两位核心盲人开发者都来中国演讲，但是考虑到这两位无法马上适应我国的无障碍公共设施，所以作罢。

AccessKit 在设计在很大程度上继承了 Chromium 的无障碍架构，采用 推送（Push） 模型：UI 工具包主动将完整的辅助功能树信息和后续的增量更新推送给 AccessKit 的平台适配器，而不是等待适配器按需拉取。但这种继承并非简单的移植，而是一次深思熟虑的重新设计。

Chromium 的无障碍系统经过了十多年的实战考验，处理过从简单网页到复杂 Web 应用的各种场景，其设计哲学值得深入分析。

推送式架构的深层逻辑

Chromium 采用推送模型有其历史原因。在多进程架构中，渲染进程需要将无障碍信息传递给浏览器进程，再由后者与操作系统的无障碍 API 交互。这种单向的数据流动避免了复杂的同步问题，也减少了进程间通信的开销。

AccessKit 将这一模式推广到了更广泛的场景，但其实现比表面看起来更精妙。推送模式的核心不是推送完整的树，而是应用主动推送变化，而非等待平台查询。传统的拉取模式中，平台需要逐个查询节点的属性（"这个节点有几个子节点？"、"第三个子节点是什么？"），每个查询都是一次函数调用。推送模式则相反：应用在 UI 发生变化时，主动将变化打包发送给平台。

对于即时模式 GUI（如 egui），虽然 UI 声明在每一帧都重新执行，但 AccessKit 并不会每帧推送完整的树。相反，它维护了一个持久的无障碍树状态，通过稳定的节点 ID 系统来追踪哪些元素真正发生了变化。即使按钮对象在每帧都是新创建的，只要它的逻辑身份（ID）和属性没变，就不会产生更新事件。这种设计将即时模式的便利性与增量更新的高效性完美结合。

这种设计的另一个优势是一致性保证。在传统的查询模式下，如果在查询子节点数量和获取具体子节点之间 UI 发生了更新，可能会导致索引越界或获取到不一致的数据。推送模式下，每次更新都是一个原子操作——要么全部应用，要么都不应用。平台接收到的始终是某个时间点的一致快照，虽然这个快照只包含变化的部分，但这些变化是相互协调的，不会出现部分更新的中间状态。

简而言之，推送式架构的精髓在于：控制权在应用手中，更新是增量的，状态是持久的，变化是原子的。这种设计不仅适合多进程架构，也完美契合了现代 UI 框架的各种范式。

节点属性的内存优化策略

从代码实现来看，AccessKit 在节点属性存储上采用了一个巧妙的设计。传统的面向对象设计会为每个节点分配固定大小的结构体，即使大部分字段都是空的。AccessKit 使用了一种基于索引的稀疏存储策略：

struct Properties {    indices: PropertyIndices,  // 固定大小的索引数组    values: Vec<PropertyValue>, // 动态的值存储}

这种设计的精妙之处在于，它结合了紧凑性和类型安全。PropertyIndices 是一个固定大小的数组，每个槽位对应一种属性类型。如果某个属性没有设置，对应的索引值就是 PropertyId::Unset。只有实际设置的属性才会在 values 向量中占用空间。

这种设计在处理大型 UI 树时优势明显。在一个典型的应用中，大部分节点只设置了少数几个属性（如角色、标签、边界框），而完整的属性集合可能包含几十个字段。传统设计下，一个节点可能占用数百字节，而 AccessKit 的设计通常只需要几十字节。

2.3 跨语言互操作的工程实践AccessKit 的多语言支持不是简单的包装器，而是深度集成的结果。以 Android 适配器为例，它展示了如何在保持性能的同时实现复杂的跨语言交互。

JNI 集成的设计考量

Android 适配器的 JNI 集成是一个典型的工程挑战。Android 的无障碍 API 完全基于 Java，而 AccessKit 的核心是 Rust 代码。两者之间的桥接需要解决几个关键问题：

对象生命周期管理：Java 对象的生命周期由 GC 管理，而 Rust 对象遵循 RAII 原则。AccessKit 使用了弱引用（WeakRef）和句柄映射的组合来解决这个问题。

线程安全：Android 要求无障碍事件必须在 UI 线程上发送，而用户的代码可能运行在任意线程上。AccessKit 通过事件队列和回调机制优雅地解决了这个问题。

内存效率：频繁的 JNI 调用会带来性能开销。AccessKit 采用了批量操作和延迟执行的策略，将多个操作合并成一次 JNI 调用。

类型系统的统一抽象

更有趣的是 AccessKit 如何处理不同语言的类型系统差异。Rust 的枚举类型非常适合表达无障碍节点的各种状态和角色，但 C 语言没有类似的构造，Python 的枚举语义也不完全一致。

AccessKit 通过宏系统生成了一致的 API：

#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]#[cfg_attr(feature = "schemars", derive(JsonSchema))]#[cfg_attr(feature = "pyo3", pyclass(module = "accesskit", rename_all = "SCREAMING_SNAKE_CASE"))]#[repr(u8)]pub enum Role {    Button,    TextInput,    // ...}

这种设计保证了同一个概念在不同语言中有一致的表示，同时又能利用各语言的特性进行优化。

2.4 即时模式 GUI 的无障碍挑战egui[4] 的集成案例特别值得深入分析，因为它代表了一类全新的 UI 架构挑战。即时模式 GUI 的核心特点是 UI 结构在每一帧都重新构建，这与传统的保留模式 GUI 形成了鲜明对比。

“另一个 Rust 跨平台 UI 引擎 makepad[5] 则将保留模式和即时模式的优势都聚合了。

状态管理的哲学差异

在保留模式 GUI 中，UI 元素是持久的对象，有清晰的生命周期。无障碍功能可以为每个元素维护独立的状态，并在元素属性变化时发送增量更新。

即时模式 GUI 则完全不同。一个按钮在连续两帧中可能具有完全不同的内存地址，但在逻辑上却是同一个按钮。这种"无状态"的设计虽然简化了 UI 逻辑，但给无障碍实现带来了新的挑战：如何在动态重建的 UI 树中维护状态的连续性？

AccessKit 的解决方案是引入稳定的节点 ID 系统。UI 框架负责为每个逻辑元素分配一个稳定的 ID，这个 ID 在元素的整个生命周期内保持不变。即使底层的对象在每一帧都重新创建，AccessKit 也能正确地识别和跟踪状态变化。

性能优化的实战经验

在 60fps 的渲染环境中，无障碍树的更新频率可能非常高。如果每一帧都完整地重建和传输无障碍树，很容易成为性能瓶颈。AccessKit 在这方面做了几个关键优化：

差分算法：只有真正发生变化的节点才会被包含在更新中。这要求 UI 框架实现高效的差分逻辑，但带来的性能提升是显著的。

延迟激活：如果没有辅助技术在运行，AccessKit 可以完全跳过无障碍树的构建。这对游戏等性能敏感的应用尤其重要。

分层过滤：AccessKit 实现了多层过滤机制，可以根据平台特性和辅助技术需求动态调整树的复杂度。

2.5 Android 适配器：移动端无障碍的新范式Android 适配器的实现揭示了移动端无障碍的独特挑战。与桌面平台不同，移动设备的交互模式更加多样化，包括触摸、手势、语音等多种输入方式。

触摸探索的技术细节

Android 的触摸探索（Touch Exploration）功能允许用户通过触摸屏幕来获取 UI 元素信息。这要求无障碍系统能够准确地进行命中测试（hit testing）。AccessKit 的实现考虑了坐标变换的复杂性：

let point = Point::new(x.into(), y.into());let point = root.transform().inverse() * point;let node = root.node_at_point(point, &filter)?;

这个看似简单的操作实际上涉及了整个变换矩阵链的计算。在复杂的 UI 层次结构中，一个元素可能经过多次变换才到达最终的屏幕坐标。AccessKit 的设计保证了这个过程的准确性和效率。

事件系统的异步处理

Android 的严格线程模型要求所有 UI 操作都在主线程上执行。但用户的业务逻辑可能运行在任意线程上。AccessKit 通过一个优雅的事件队列系统解决了这个问题：

在任意线程上生成事件

将事件封装在队列中

通过 Android 的 Handler 机制投递到主线程

在主线程上批量处理事件

这种设计的巧妙之处在于它完全隐藏了线程切换的复杂性，用户代码不需要关心事件将在哪个线程上执行。

2.6  与 Bevy 游戏引擎的集成的技术突破AccessKit 在 2023 年 3 月被 Bevy 采用，成为首个集成到通用游戏引擎中的无障碍解决方案。 AccessKit 在 2022 年用 “The Intercept” 游戏的分支在 Unity 引擎做了概念验证，但该实验性工作未发展为可用插件。AccessKit 开发者承认 Unity 集成“特别具有挑战性，因为迄今为止未获得Unity官方的合作。”

AccessKit 与 Bevy 游戏引擎的集成是游戏无障碍领域的里程碑。由 Nolan Darilek 提交的 Pull Request #6874 于 2022 年 12 月启动集成工作，并于 2023 年 3 月 1 日合并。Bevy 0.10 于 2023 年 3 月 6 日发布，成为首个内置无障碍支持的通用游戏引擎。

截至 2025 年，集成仍在持续开发和维护中。Bevy 0.16使用AccessKit 0.18版本，并通过多个拉取请求定期更新。集成过程中发生了重要变更，例如在 Bevy 0.15 中移除了 AccessKit 的重导出，以减少 Bevy 的 Node 结构体与 AccessKit 的 Node 结构体之间的命名冲突。开发者现在需在 Cargo.toml 中显式添加 ‎accesskit = "0.17" 或更高版本。

技术架构以 ‎bevy_a11ycrate 为核心，提供 AccessibilityPlugin 并管理非 GUI 的无障碍 API。核心组件 ‎AccessibilityNode 包装了 ‎accesskit::Node，用于将实体暴露给平台无障碍 API。层级结构遵循实体的父子关系，如果没有可访问的父节点，则自动成为主窗口的子节点。

AccessKit 通过仿射变换系统处理 3D 到 2D 坐标映射，而非内置 3D 专用工具。架构要求开发者自行完成 3D 到 2D 投影，再将坐标传递给 AccessKit。最终变换后的坐标需相对于树容器原点，采用物理像素且y轴向下。

目前 AccessKit 与 Bevy 的示例在生态系统中仍较少。

Bevy 官方仓库包含 ‎examples/ui/scroll.rs，演示了 AccessibilityNode 在 UI 滚动系统中的基本用法。最完整的实现存在于 bevy_egui，通过 egui 的 AccessKit 支持实现了可访问的 UI，包括标签导航和可用的无障碍 UI 示例。

尚无使用 AccessKit 与 Bevy 的生产级游戏。虽然已举办六次 Bevy 游戏创作活动，但均未专注于无障碍主题。缺乏专门教程、分步实现指南和面向游戏的无障碍示例，是生态系统的一大缺口。

集成面临多平台挑战。

Linux支持仍有问题，‎accesskit_unix 特性默认禁用，因屏幕阅读器兼容性有限且 API 正在修订。Windows 和 macOS 是主要支持平台，Web 端通过 WASM 支持但有局限。开发者在集成 AccessKit 时面临较高复杂度。移除 AccessKit 重导出后需手动管理依赖，Bevy、AccessKit 和 winit 之间可能出现版本对齐问题。UI无障碍并非自动实现——开发者需为每个 UI 元素手动添加 AccessibilityNode 组件，增加了实现负担。

焦点管理尤为困难。

Bevy 的 UI 系统缺乏健全的焦点支持，需手动管理 Focus 资源，且无默认键盘导航。屏幕阅读器只能依赖对象导航模式而非标准浏览模式。节点边界计算常常不正确，因摄像机平移和 UI 缩放问题导致焦点高亮显示位置错误。

目前最实用的方案是使用 bevy_egui实现可访问界面，通过 egui 成熟的 AccessKit 支持实现无障碍。原生 Bevy UI 需开发者手动实现无障碍模式，显式添加 AccessibilityNode 组件并编程管理焦点。性能优化策略包括在帧更新间保持稳定的节点 ID，使用增量 TreeUpdate 批处理提升效率，以及为相似 UI 元素利用共享节点类。架构支持即时模式和保留模式 UI，即时模式需特别注意 ID 稳定性。

AccessKit 与 Bevy 的集成推动了游戏无障碍发展，成为首个内置无障碍支持的通用游戏引擎。技术实现虽需手动配置且受平台限制，但为无障碍游戏开发奠定了基础。

我在 7 月也尝试过使用 Claude code + accesskit + bevy 实现一个 AI 自动控制贪吃蛇游戏的 PoC demo，虽然整体 demo 运行良好，但实际上指令并未通过 accesskit 来操控，集成起来还是比较困难的。

2.7 生态系统效应与未来展望AccessKit 的影响已经超越了技术层面，它正在重塑整个 Rust GUI 生态系统的无障碍意识。

标准化的涟漪效应

当 egui 成为第一个支持完整无障碍功能的 Rust GUI 框架时，它为整个生态系统树立了新的标杆。其他框架开始意识到，无障碍功能不再是"锦上添花"的特性，而是基础功能的一部分。

这种标准化效应正在向其他语言社区扩散。C++ 开发者开始思考如何在 Qt 或 FLTK 中集成类似的抽象层，Python 社区也在探讨如何改进现有 GUI 框架的无障碍支持。

自动化测试的意外收益

虽然 AccessKit 的主要目标是支持屏幕阅读器等辅助技术，但它在 UI 自动化测试领域也展现出了巨大潜力。无障碍 API 提供了一个稳定的、语义化的接口来与 UI 交互，这正是自动化测试所需要的。

一些团队已经开始使用 AccessKit 构建更加可靠的端到端测试。与传统的基于坐标或元素选择器的方法相比，基于无障碍语义的测试更加稳定，也更容易维护。这种"一举两得"的效果可能会推动 AccessKit 在更广泛的场景中得到应用。

技术演进的方向