当内部有大量项目时，ListView在调整大小时闪烁黑色
本文关键字：调整 小时 ListView 闪烁 黑色 内部 项目 | 更新日期: 2023-09-27 18:01:18
我有一个基于ListView的控件。这是一个文件浏览器。设置Path属性后，首先以异步方式(使用Win32 API)加载所有文件系统项。即使对于大量文件，这也是超级快的。无论如何，对于C:'Windows'System32，我没有看到任何延迟。然后将这些项目以64个批次添加到我的ListView中，等待每64个Dispatcher.Yield()之后，以显示在操作完成之前添加了什么。这再次使整个过程更快，响应更快。
然而，有一个不是很快的操作:当我第一次需要文件的图标时，我必须进行系统调用。这个调用是在getter中进行的，它很聪明，如果可用，它会尝试使用缓存。
视图的加载是一瞬间的。
然而，当我加载一个巨大的目录(没有问题，快速)-然后调整或最大化窗口-我看到一些黑色的闪烁之前，控件调整大小。
这就像首先窗口调整大小，添加的空间被涂成黑色，然后出现更大的ListView。它非常烦人，破坏了我的顺利体验。有没有办法避开这个黑色区域?
我试着设置Window背景为白色，没有帮助。我试图设置我的UserControl包含ListView背景为白色。没有快乐。
当ListView中的物品不多时，没有黑色闪光，但仍然不够光滑。
那么-如何防止看到黑色背景，而控制正在调整大小?
如果有人有ListView的性能问题-这是应该做的:
-
不要在UI线程上执行任何昂贵的操作。在我的情况下，不完全是这样，但类似。违规代码隐藏在项目构造函数中，它试图在开始时进行一些字符串转换。非常糟糕的想法，所有昂贵的操作都被转移到getter上，这只解决了一半的问题。项目构造函数应该为空。没有初始值。根本没有初始化。所有属性都应该通过getter读取。这将导致每个视图执行20个这样的操作，而不是20000个，但只有在使用UI虚拟化的情况下。
-
使用MVVM模式，因此不直接添加项，创建项源并将项添加到源。这将允许内置UI虚拟化，这在您拥有大量项目时是必不可少的。在Google中搜索"UI虚拟化ListView"了解更多细节。
-
如果填充项目源太慢，请考虑数据虚拟化。对我来说，这是不必要的。当获得所有的数据是相对便宜的-我们很好。如果没有，我们只能得到当前需要显示的数据块。
-
一个简单的控件模板可以在一些低端移动设备上略微提高应用程序的性能。
-
如果您在应用程序的任何地方使用非托管代码，请仔细检查它，我忘记调用
DestroyIcon一次，它导致非常奇怪的，意想不到的行为。所以处理掉任何可丢弃的东西，销毁未使用的句柄等等。确保它已经完成，我在调试这些东西上浪费了无数的时间。需要明确的是:未释放的资源不会导致任何性能问题，它会导致其他意想不到的行为，比如奇怪的异常、图标消失等等。问题似乎来自ListView。