System.Windows.Automation非常慢。
我执行：
element.FindAll(TreeScope.Children, Condition.TrueCondition);
在非常快的计算机上获取仅30个子元素可能需要1000毫秒。
在QT应用程序中获取Tree的子元素时，我甚至看到它永远悬空。
这是一个已知问题吗？ 谷歌搜索后我找不到任何有用的答案。
答案 0 :(得分：10)
System.Windows.Automation非常慢。
System.Windows.Automation充满了错误。它可能不会返回AutomationElement的所有子项，这是一个非常严重的错误。
除此之外，实施不是线程安全的。
System.Windows.Automation已弃用。不要用它！
在MSDN中，您会找到以下注释：
UI自动化首次在Windows XP中作为其中的一部分提供 Microsoft .NET Framework。虽然还有一个非托管的C ++ API 当时发表的客户功能的用处有限 因为互操作性问题。对于Windows 7，API已经存在 在组件对象模型（COM）中重写。 虽然在早期版本中引入了库函数 UI自动化仍然记录在案，它们不应该用于新的 应用
降低性能的解决方案是使用新的 IUIAutomationElement COM接口，而不是旧的System.Windows.Automation C＃接口。之后代码将运行闪电！
除此之外，新界面提供了更多模式，微软正在不断扩展它。在Windows 10 SDK（UIAutomationClient.h和UIAutomationCore.h）中添加了几个在.NET Automation框架中不可用的模式和属性。
U.utouto的COM版本中提供了以下模式，这些模式在System.Windows.Automation中不存在：
此外，还添加了以下控件类型：
此外，还添加了以下元素：
关于错误的问题：新的COM UIAutomation Framework设计得非常好，我在框架的客户端上找不到错误，这是一个很大的进步与System.Windows.Automation相比。但是框架的服务器端有几个缺失的功能甚至是错误。在服务器端，每个GUI框架都必须实现UIAutomation提供程序（请参阅MSDN: Interfaces for Providers）。因此，这些问题会因您自动化的应用程序类型而有所不同，因为每个GUI框架都有自己的问题：
缺少原生Windows GUI 功能：许多控件未实现应实现的模式。例如，本机工具栏中的 SplitButton 应实现Invoke模式以单击按钮和ExpandCollapse模式以打开下拉菜单。但缺少ExpandCollapse模式，这使得使用SplitButtons变得困难。如果您通过IUIAutomation->ElementFromPoint()获得工具栏SplitButton，然后请求它的父母，您将获得一个残缺的元素。并且 Pager 控件根本无法实现自动化。
同样在 WPF应用程序中，有些控件由Microsoft实施错误：例如，如果您有日历控件，则会在顶部看到两个按钮切换到下个/上个月。如果您在这些按钮上执行Invoke模式，则会出现UIA_E_NOTSUPPORTED错误。但这不是框架客户端的错误，因为对于其他按钮，Invoke模式可以正常工作。这是WPF自动化服务器中的错误。如果您使用WPF RichTextBox测试IUIAutomationTextRange，您会发现没有实现多个命令：Select()和ScrollIntoView()什么都不做。
对于 .NET Forms应用程序，Microsoft并没有付出太多努力来支持它们。 .NET 日历控件根本无法自动执行。整个控件甚至不被识别为日历。它有ControlType＆＃34; Pane＆＃34;没有儿童元素。这同样适用于 DateTimePicker 。对于像 DataGrid 和 PropertyGrid 这样的复杂控件，唯一实现的模式是LegacyIAccessible，这是一种糟糕的支持。这些控件应至少实现Table和Grid以及ScrollItem模式。
Internet Explorer 也无法自动生成，因为由于缺少坐标，无法将可见区域外的元素自动滚动到视图中。 （Bounds以空矩形形式返回）并且未实现ScrollItem模式。 （是的，我知道Internet Explorer已经被Windows 10中的Edge取代，但是自从Windows 7和Microsoft在这些年中没有在Internet Explorer中实现有用的自动化支持时，UIAutomation框架就已存在）
我甚至看到了自动化应用程序的完整崩溃。例如，如果在某个控件上执行某些自动化命令，Visual Studio和TotalCommander将崩溃。这里 - 再次 - 错误在于框架的服务器端实现。
摘要：我们有一个很有用的框架。开发新UIAutomation框架的Microsoft团队做得很好，但Microsoft的其他领域（原生GUI，WPF，.NET和Internet Explorer团队）不支持此框架。这非常令人难过，因为只需要做很少的努力就可以提供更好的功能。但似乎残障人士并不是一个有利可图的市场。