WPF 临时显示冻结
我有一个在 .NET 3.5 上运行的独立 WPF 应用程序。有时，显示屏会冻结几秒钟。这在经常更新内容的屏幕上最为明显。 这里有一个视频显示了该问题。
当显示冻结时，界面仍保持响应（视频）。
我遇到过一些其他有类似问题的帖子，他们将其归因于软件/硬件渲染问题。为了安全起见，我完全禁用了硬件渲染，但问题仍然存在。
我在冻结期间运行了文件监视器，以查看是否有一些异常的文件访问或活动正在进行，但没有任何异常。
最后说明：目标平台是小型触摸屏平板电脑，没有太多内存或马力（512 MB）。我只在目标上看到这个问题，从来没有在我的开发 PC 上看到过这个问题，因为我的开发 PC 拥有更多的资源。
更新
我以为我已经通过删除一些动画代码解决了这个问题，但它不起作用。我仍然遇到这个问题，而且我已经束手无策了。
以下是我尝试过的其他一些操作：
- 升级到 .NET 4.0。同样的行为。
- 向可通过 DispatcherTimer（在 UI 线程上调用）调用的所有方法添加了调试代码，以确保它们都不会阻塞 UI。
我真的被难住了，并添加了赏金。正如我所提到的，该问题仅发生在目标 PC 上（链接） 。
I have a standalone WPF application running on .NET 3.5. Every so often, the display simply freezes up for several seconds. This is most noticeable on screens where something is being updated often. Here is a video showing the problem.
While the display is frozen, the interface remains responsive (video).
I've come across some other posts with similar problems who attributed it to a SW/HW rendering issue. To be safe, I disabled HW rendering altogether, but still have the problem.
I ran a file monitor during the freezes to see if there is some extraordinary file access or activity going on, but nothing is out of the ordinary.
Final note: The target platform is a small touch-screen panel PC without much memory or horsepower (512 MB). I only see this issue on the target, never on my development PC, which has much more in the way of resources.
UPDATE
I thought I had fixed the issue by removing some animation code, but it did not work. I am still encountering the problem and I'm at the end of my rope.
Here's some more things I've tried:
- Upgraded to .NET 4.0. Same behavior.
- Added debug code to all methods that may be invoked via DispatcherTimer (which are called on the UI thread) to make sure none of them are holding up the UI.
I'm really stumped here and have added a bounty. As I mentioned, the problem only occurs on the target PC (link).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当出现这种行为时，我倾向于怀疑 .NET GC 或操作系统交换文件。
对于前者，您可以尝试使用 .NET 性能计数器来监视可疑活动。
如果设备有交换文件，您可以禁用它并查看行为是否发生变化。
正如其他人所说，探查器（或者隔离导致延迟的条件的某种东西 - 甚至只是在发生延迟时附加和中断调试器）将是获取更多信息的好方法。
I tend to suspect either .NET GC or the OS swapfile when this kind of behavior shows up.
For the former, you could try the .NET performance counters to monitor for suspect activity.
If the device has a swap file, you can disable it and see if the behavior changes.
As others have said, a profiler (or some what of isolating what condition is inducing the delay - even just attaching and breaking the debugger when it occurs) would be a good way to get more information.
您是否尝试在测试的系统上分析该应用程序？使用内存和/或性能分析器？
您可以从此类测试中获得一些有用的信息：一些 .Net 分析器
这是 WPF 的一个： 来自 microsoft 的 WPF 分析器
Did you tried to profile the application on the tested system? Using a memory and/or performance profiler?
You could get some good informations out of this type of test : some .Net profilers
And here's one for WPF : WPF profiler from microsoft
罪魁祸首是以下方法调用：
将其添加到我的应用程序中是因为它修复了 .NET 3.5 中的内存泄漏问题。此解决方法可以在此处< /a>.如果我删除此调用，渲染问题就会消失。
我取出了调用并以另一种方式修复了内存泄漏（删除故事板动画并改为使用后面的代码）
The culprit was the following method call:
This was added to my application because it patched a memory leak problem in .NET 3.5. This work-around can be found here. If I remove this call, the rendering issues go away.
I took out the call and fixed the memory leak in another way (removing storyboard animation and using code behind instead)