UI 自动化和 Active Accessibility
Microsoft Active Accessibility 是 Windows 95 中引入的旧 API,旨在使 Windows 应用程序易于访问。 Microsoft UI 自动化是 Windows 的新辅助功能模型,旨在满足对辅助技术产品和自动测试工具的需求。 UI 自动化在 Microsoft Active Accessibility 的基础上提供了许多改进。 本主题介绍这两种技术之间的差异。
本主题包含以下各节:
编程语言
Microsoft Active Accessibility 基于组件对象模型 (COM),支持双重接口,因此可以用 C/C++ 和脚本语言进行编程。
引入 UI 自动化时,客户端 API 仅限于托管代码,而提供程序 API 同时包括托管和非托管实现。 通过 Windows 7,引入了一个新的基于 COM 的客户端 API,使用 C/C++ 编写 UI 自动化客户端应用程序变得更容易。
服务器和客户端
在 Microsoft Active Accessibility 中,服务器和客户端直接通信,主要通过 IAccessible 接口的服务器实现。
在 UI 自动化中,核心服务位于服务器(提供程序)和客户端之间。 核心服务对由提供程序实现的接口进行调用并提供其他服务,例如,为 UI 元素生成唯一的运行时标识符。 客户端应用程序通过创建 CUIAutomation 对象来访问此核心服务。 此对象支持一组与提供程序接口分离的客户端接口。 有关详细信息,请参阅创建 CUIAutomation 对象。
UI 自动化提供程序可以向 Microsoft Active Accessibility 客户端提供信息;而 Microsoft Active Accessibility 服务器可以向 UI 自动化客户端应用程序提供信息。 但是,由于 Microsoft Active Accessibility 没有公开同 UI 自动化一样多的信息,因此两个模型并不完全兼容。
UI 元素
Microsoft Active Accessibility 将 UI 元素显示为与子标识符配对的 IAccessible 接口。 很难比较两个IAccessible 指针来确定它们是否引用同一元素。
在 UI 自动化中,每个元素都表示为一个对象,该对象向客户端公开 IUIAutomationElement 接口。 元素可以通过运行时标识符进行比较,这些标识符是使用 IUIAutomationElement::GetRuntimeId 检索的。
树视图和导航
屏幕上的 UI 元素可以被视为树状结构,桌面作为根、应用程序窗口作为直接子项,而应用程序中的元素作为继承子项。
在 Microsoft Active Accessibility 中,许多与最终用户无关的 UI 元素都显示在树结构中。 客户端应用程序必须检查树中的所有元素,以确定哪些元素是有意义的。
UI 自动化客户端应用程序通过筛选视图查看 UI。 该视图仅包含向用户提供信息或用户可以与之交互的元素。 还提供了只包含控件元素和只包含内容元素的预定义视图,客户端应用程序可以定义自定义视图。 UI 自动化使向用户描述 UI 变得更加容易,并帮助用户与应用程序交互。
在 Microsoft Active Accessibility 中,元素之间的导航可以是空间导航(例如,移动到存在于屏幕左侧的元素)、逻辑导航(例如,移动到下一菜单项或对话框中 Tab 键顺序的下一项)或分层导航(例如,移动到容器中的第一个子元素,或者从子元素移动到其父元素)。 分层导航非常复杂,因为子元素并不总是实现 IAccessible 的对象。
在 UI 自动化中,所有 UI 元素都是 COM 对象,它们公开了 IUIAutomationElement 接口,并支持相同的基本功能。 从提供程序的角度来看,COM 对象实现从 IRawElementProviderSimple 继承的接口。 导航主要是分层的;也就是说,从父级到子级,从一个同级到另一个同级。 但是,同级之间的导航具有逻辑元素,因为它可能遵循 Tab 键顺序。 客户端可以使用 IUIAutomationTreeWalker 使用树的任何筛选视图从任何起点导航。 客户端还可以使用 IUIAutomationElement::FindFirst 和 IUIAutomationElement::FindAll 导航到特定的子级或后代。 例如,很容易检索对话框中支持指定控件模式的所有元素。
UI 自动化中的导航比 Microsoft Active Accessibility 中的导航更一致。 某些元素(例如下拉列表和弹出窗口)在 Microsoft Active Accessibility 树中出现两次,从这些元素进行导航可能会产生意外结果。 对于 rebar 控件,很难正确实现 Microsoft Active Accessibility。 UI 自动化能够重排根目录并进行重新布置,因此可以在树的任何位置放置元素,不必考虑窗口所有者构建的层次结构。
角色和控件类型
Microsoft Active Accessibility 使用 accRole 属性 (IAccessible::get_accRole) 检索 UI 中元素角色的说明,例如 ROLE_SYSTEM_SLIDER 或 ROLE_SYSTEM_MENUITEM。 元素的角色是确定其可用功能的主要线索。 与控件的交互是通过使用固定方法实现的,例如 IAccessible::accSelect 和 IAccessible::accDoDefaultAction。 客户端应用程序和 UI 之间的交互仅限于可通过 IAccessible 完成的交互。
相比之下,UI 自动化将 IUIAutomationElement::CurrentControlType(或 IUIAutomationElement::CachedControlType)属性描述的元素的控件类型与预期功能分离。 功能由通过实现其特殊化接口的提供程序支持的控件模式来确定。 可以结合控件模式来描述特定 UI 元素支持的完整功能集。 某些提供程序需要支持特定控件模式。 例如,复选框的提供程序必须支持切换控件模式。 其他提供程序需要支持一组控件模式中的一个或多个。 例如,按钮必须支持“切换”或调用控件模式。 还有一些支持无控件模式。 例如,无法移动、调整大小或停靠的窗格没有控件模式。
UI 自动化支持自定义控件,这些控件由 UIA_CustomControlTypeId 常量标识,可以用 IUIAutomationElement::CurrentLocalizedControlType(或 IUIAutomationElement::CachedLocalizedControlType)属性描述。
下表将 Microsoft Active Accessibility 对象角色映射到 UI 自动化控件类型。
状态和属性
Microsoft Active Accessibility 元素支持一组常见的属性。 某些属性(如 accState)必须根据元素角色描述不同的条件。 服务器必须实现可返回属性的 IAccessible 的所有方法,返回的属性甚至与该元素不相关。
UI 自动化定义其他属性,其中一些属性对应于 Microsoft Active Accessibility 中的状态。 某些属性是所有元素共有的,但其他属性特定于控件类型和控件模式。 UI 自动化提供程序不需要实现不相关的属性,而可以只返回任何其不支持的属性的 null 值。 UI 自动化核心服务可以从默认窗口提供程序获取一些属性,并且这些属性与提供程序显式实现的属性相合并。
除了支持更多属性外,UI 自动化还允许缓存属性来提高性能。
下表显示了两个模型中某些属性之间的对应关系。 有关 UI 自动化属性 ID 的说明,请参阅自动化元件属性标识符。
Active Accessibility 属性访问器 | UI 自动化属性 ID | 注解 |
---|---|---|
get_accKeyboardShortcut | UIA_AccessKeyPropertyId 或 UIA_AcceleratorKeyPropertyId | 如果两者都存在,则 UIA_AccessKeyPropertyId 优先。 |
get_accName | UIA_NamePropertyId | |
get_accRole | UIA_ControlTypePropertyId | 请参阅上表,了解角色到控件类型的映射。 |
get_accValue | UIA_ValueValuePropertyId 或 UIA_RangeValueValuePropertyId | 仅适用于支持 IUIAutomationValuePattern 或 IUIAutomationRangeValuePattern 的控件类型。 范围值规范化为 0-100,与 Microsoft Active Accessibility 行为保持一致。 值表示为字符串。 |
get_accHelp | UIA_HelpTextPropertyId | |
accLocation | UIA_BoundingRectanglePropertyId | |
get_accDescription | 不支持。 | accDescription 在 Microsoft Active Accessibility 中没有明确的规范,这导致服务器将不同的信息片段放置在此属性中。 |
get_accHelpTopic | 不支持。 |
下表显示了与 Microsoft Active Accessibility 对象状态常量对应的 UI 自动化属性 ID。
有关属性 ID 的完整列表,请参阅属性标识符。
事件
不同于 Microsoft Active Accessibility,UI 自动化中的事件机制不依赖于 Windows 事件路由(使用窗口句柄紧密连接)且不需要客户端应用程序来设置挂钩。 对事件的订阅可以针对树的特定部分进行微调,而不仅仅是针对特定事件。 通过跟踪所侦听的事件,提供程序也可微调其事件的引发。
对于客户端来说检索引发事件的元素也很简单,因为这些事件会被直接传递到事件回调。 如果在客户端订阅事件时提供了缓存请求,则会自动预提取元素的属性。
下表显示了 Microsoft Active Accessibility 事件常量和 UI 自动化事件 ID 的对应关系。
从 UI 自动化访问 Active Accessibility 属性和对象
Microsoft Active Accessibility 中不可用的 UI 自动化的一个关键功能是能够提取具有单个跨进程操作的多个属性。
现有 Microsoft Active Accessibility 客户端可以使用 IUIAutomationLegacyIAccessiblePattern 接口来利用此功能。 此接口表示在 UI 元素上公开 Microsoft Active Accessibility 属性和方法的控件模式。 检索元素时,应用程序可以请求缓存此控件模式及其属性。
IUIAutomationLegacyIAccessiblePattern 还使客户端能够从对 IAccessible没有本机支持的元素中获取 Microsoft Active Accessibility 属性。
IUIAutomationLegacyIAccessiblePattern 的属性更改不会引发 UI 自动化事件。