UIAutomation内存问题 [英] UIAutomation Memory Issue

查看:301
本文介绍了UIAutomation内存问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有,只是有没有事件处理逻辑的一个按钮一个简单的WPF程序。然后我用UIAutomation框架,单击该按钮多次在一排。最后,我看着由WPF程序使用的内存,它似乎不断地成长。

I have a simple WPF program that just has a single button with no event handling logic. I then use the UIAutomation framework to click that button many times in a row. Finally, I look at the memory used by the WPF program and it seems to grow and grow.

任何人都知道为什么是这样的话,我怎么能防止这种情况发生?

Anyone know why this is the case and how I can prevent this from happening?

下面是一个简单的WPF程序(没有在后面的代码):

Here is the simple WPF program (nothing in the code behind):

<Window x:Class="SimpleApplication.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Simple Application"
        AutomationProperties.AutomationId="Simple Application"
        Height="350" Width="525">
    <Grid>
        <Button AutomationProperties.AutomationId="button" Height="50" Width="100">Click Me</Button>
    </Grid>
</Window>

下面是UIAutomation测试程序:

Here is the UIAutomation test program:

class Program
{
    static void Main(string[] args)
    {
        string appPath = @"..\..\..\SimpleApplication\bin\Debug\SimpleApplication.exe";
        string winAutoId = "Simple Application";
        string buttonAutoId = "button";

        using (Process process = Process.Start(new ProcessStartInfo(appPath)))
        {
            Thread.Sleep(TimeSpan.FromSeconds(1));

            AutomationElement winElement = AutomationElement.RootElement.FindFirst(TreeScope.Children, new PropertyCondition(AutomationElement.AutomationIdProperty, winAutoId));

            for (int i = 0; i < 1001; i++)
            {
                AutomationElement buttonElement = winElement.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, buttonAutoId));

                InvokePattern invokePattern = (InvokePattern)buttonElement.GetCurrentPattern(InvokePattern.Pattern);
                invokePattern.Invoke();

                process.Refresh();
                long totalMemory = process.WorkingSet64 + process.PagedMemorySize64;

                if (i % 100 == 0)
                {
                    Console.WriteLine("Memory = {0} MB", ((double)totalMemory) / (1024 * 1024));
                }
            }

            WindowPattern windowPattern = (WindowPattern)winElement.GetCurrentPattern(WindowPattern.Pattern);
            windowPattern.Close();
        }

        Console.WriteLine();
        Console.WriteLine("Press Enter to Continue...");
        Console.ReadLine();
    }
}

下面是从我的机器上的程序的结果:

Here are the results from the program on my machine:

Memory = 38.20703125 MB
Memory = 42.9296875 MB
Memory = 45.00390625 MB
Memory = 47.04296875 MB
Memory = 51.9296875 MB
Memory = 52.2890625 MB
Memory = 52.41015625 MB
Memory = 55.70703125 MB
Memory = 55.70703125 MB
Memory = 57.21484375 MB
Memory = 59.09375 MB

看着它在.NET内存分析器,新对象那些出现在WPF应用程序从System.Threading命名空间。当我本身运行WPF程序,并单击这些对象都没有出现鼠标按钮

Looking at it with the .NET Memory Profiler, the new objects that are appearing in the WPF application are from the System.Threading namespace. When I run the WPF program by itself and click the button with the mouse these objects do no appear.

更新:

我想这样做使用Visual Studio的CodedUI一个类似的测试,和相同的8个对象出现在这种情况下泄漏为好。出现泄漏的对象包括:

I tried doing a similar test using Visual Studio's CodedUI, and the same 8 objects appeared to leak in that situation as well. The objects that appear to leak are:

System.Threading.CancellationTokenSource
System.Threading.TimerQueueTimer
System.Threading.SparselyPopulatedArray<CancellationCallbackInfo>[]
System.Threading.Timer
System.Threading.TimerHolder
System.Threading.SparselyPopulatedArray<CancellationCallbackInfo>
System.Threading.SparselyPopulatedArrayFragment<CancellationCallbackInfo>
System.Threading.CancellationCallbackInfo[]



我也提交给微软一个错误:

I have also submitted a bug to Microsoft:

的http://连接。 microsoft.com/VisualStudio/feedback/details/801209/uiautomation-memory-issue

推荐答案

交谈后,微软客户的支持,我们找到了答案的问题。在内部,WPF本身提供了三分钟就到UI自动化事件作出响应。要做到这一点,它开始了一个计时器。看来,即使该事件立即作出反应,定时器不会消失,直到后三分钟结束了。

After talking to Microsoft customer support, we found the answer to the problem. Internally, WPF gives itself three minutes to respond to a UI Automation event. To do this, it starts off a timer. It appears that even if the event is responded to immediately, the timer does not go away until after the three minutes are up.

所以,解决方法的问题是等到计时器到期,然后做一个GC.Collect的。那么内存问题会自行消失。不是一个伟大的修复,但它适用于我们的情况。

So, the workaround to the problem is to wait until the timer expires and then do a GC.Collect. Then the memory issue will go away. Not a great fix, but it works for our situation.

这篇关于UIAutomation内存问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆