企业官网建设流程全解析

WPF UI 内存越跑越多？wpfui 图像缓存与资源释放完整指南

【免费下载链接】wpfuiWPF UI provides the Fluent experience in your known and loved WPF framework. Intuitive design, themes, navigation and new immersive controls. All natively and effortlessly.项目地址: https://gitcode.com/GitHub_Trending/wp/wpfui

如果你的 WPF 应用用了 wpfui 控件库，运行一两天后任务管理器里的私有内存只涨不跌，原因多半不在深层架构，而是三件具体的事：图片反复解码、解码结果没冻结、窗口关了事件没摘。这篇文章按启动、运行、关闭三个阶段把图像缓存策略和资源释放的落点讲清楚，读完你能把内存曲线从持续上涨压回平台期。

启动期：先量出基线，确认增长不是错觉

谈优化之前，先确认增长真的存在。打开任务管理器，展开应用进程，记录刚启动时的私有字节数；再手动跑一遍你的典型流程——切换 10 次页面、把图片列表滚几遍——记录第二次读数。两次读数一致，就没有泄漏，不用动任何代码。

如果确有增长，用 Visual Studio 内存分析器在流程前后各拍一张快照，看差值里哪个类型涨得最多。图像多的应用里，BitmapSource/BitmapImage通常是大头。数量级可以心算：一张 1920×1080 的图解码成 BGRA 后占 1920×1080×4 ≈ 8.3MB，连续翻 100 张大图，半小时后私有内存从 240MB 涨到 1.1GB（示例数据，具体数值随机器而定）。如果你的曲线是这种形态，直接进入下面的缓存部分。

运行期一：给频繁换图的 Image 垫一层 LRU 缓存

这一节解决翻页换图造成的重复解码。用户在页面间来回切换，每次ui:Image的 Source 都重新走一遍文件读取和解码，旧图像对象要等 GC 才回收，但峰值内存已经产生。

wpfui 的 Image 控件（src/Wpf.Ui/Controls/）里 Source 只是一个依赖属性，没有内置缓存。解法是在它前面垫一层：按图片 URI 缓存解码好的BitmapImage，容量满了就踢掉最久没被访问的那张——"最久没用的先出局"，这就是 LRU。缓存创建时设了SizeLimit（本例 20MB），尺寸按像素量折算，缓存自身被限死在上限内：

public BitmapImage GetBitmap(Uri uri) { if (_imageCache.TryGetValue(uri, out BitmapImage? hit)) { return hit; } var image = new BitmapImage(uri) { CacheOption = BitmapCacheOption.OnLoad }; _imageCache.Set(uri, image, new MemoryCacheEntryOptions { Size = image.PixelWidth * image.PixelHeight / 256_000, SlidingExpiration = TimeSpan.FromMinutes(10) }); return image; }

SlidingExpiration是第二道保险：一张图 10 分钟没人再看，就算容量没满也会被回收。容量按用户"一次会翻多少张"定，30~50 张足够，不必缓存整个相册。

运行期二：BitmapImage 解码完就 Freeze，别让每处引用各存一份

这一节解决同一张图被多处引用时的内存翻倍。缩略图列表、预览大图、窗口图标同时用到同一张图，如果对象没冻结，WPF 可能为每个引用点各留一份解码数据，3 份 8MB 就是 24MB。

Freeze 用大白话说：给对象上锁，之后不许再改，WPF 换来保证内存里只有一份解码数据，且任何线程都能直接使用。关键动作是解码完成后立刻冻结，并且把解码放到 UI 线程之外，避免大图卡住主线程：

private static BitmapImage DecodeFreezed(Uri uri) { var image = new BitmapImage(); using var stream = File.OpenRead(uri.LocalPath); image.BeginInit(); image.CacheOption = BitmapCacheOption.OnLoad; image.StreamSource = stream; image.EndInit(); image.Freeze(); return image; }

CacheOption.OnLoad与Freeze()要配合使用：OnLoad 把文件一次性读进内存并释放流，冻结后对象可以安全地送回 UI 线程，被多个控件共享。调用方把DecodeFreezed包进Task.Run里跑，结果回到 UI 线程再赋给控件。如果配合上一节的缓存使用，就把它放进GetBitmap的加载回调中。

运行期三：长列表换虚拟化控件，别让 500 张图同时解码

这一节解决长列表一次性创建全部容器的问题。商品列表 500 项、每项一张缩略图，普通ItemsControl会给 500 项全部创建容器，触发 500 次解码，内存还没开始用就先跳一截。

虚拟化用大白话说：只创建屏幕上看得见的容器，滚出视口的容器被回收复用。wpfui 的 ListBox 默认就开着IsVirtualizing；自绘布局时，库里还有VirtualizingItemsControl控件，自带虚拟化面板，用法和普通 ItemsControl 一致：

<ui:VirtualizingItemsControl ItemsSource="{Binding Products}"> <ui:VirtualizingItemsControl.ItemTemplate> <DataTemplate> <ui:Image Source="{Binding Thumb}" CornerRadius="4" /> <TextBlock Text="{Binding Name}" /> </DataTemplate> </ui:VirtualizingItemsControl.ItemTemplate> </ui:VirtualizingItemsControl>

和前两节串起来看：Binding Thumb应返回"已冻结、已进缓存"的BitmapImage。虚拟化回收的是容器，图像对象留在缓存里不丢，滚回去不用重新解码，来回滚动内存保持平稳。

关闭期：窗口 Closing 时按顺序摘事件、清缓存

这一节解决窗口关闭后对象图释放不掉的问题。典型的写法是在构造函数里订阅了事件、没有对应退订，窗口"关了"，处理器还挂在事件上，缓存里还压着几十张图，整棵对象树无法释放，应用常驻系统托盘时内存就一直高位挂着。

修法是把清理集中到OnClosing末尾，顺序固定：先摘事件，再释放缓存，最后调基类：

protected override void OnClosing(CancelEventArgs e) { _pageChanged -= OnPageChanged; _imageCache.Dispose(); base.OnClosing(e); }

框架内有现成参照。src/Wpf.Ui.Tray/ 里的NotifyIconService把托盘图标的生命周期挂在父窗口的Closing上，收到事件即释放内部管理器；SetParentWindow换窗口时先退订旧窗口再挂新窗口，不漏也不重。src/Wpf.Ui/Win32/ 下的Utilities.SafeDispose也值得照抄其顺序：取出引用、把字段置空、再调 Dispose，既不怕二次 Dispose 报错，也不漏释放。

合入前自查：五个问题过一遍

✅ 有基线吗？量过启动后私有内存，并知道流程里涨的数从哪来？ ✅ 图片按 URI 缓存并冻结了吗？容量满时最久未访问的先出局？ ✅ 大图解码在 UI 线程上吗？解码调用包进Task.Run了吗？ ✅ 长列表虚拟化了吗？500 项会创建 500 个容器吗？ ✅ 窗口关闭时，先摘事件、再清缓存，然后才释放其他 IDisposable 吗？

五项全过，运行一段时间后内存会停在平台期；哪一项不过，哪一项就是持续上涨的元凶。想看完整用法，参考 samples/Wpf.Ui.Demo.Mvvm/ 里的示例，它用 wpfui 控件搭了三页导航结构，可以直接对照本文的缓存与关闭期清理点检查自己的项目。

【免费下载链接】wpfuiWPF UI provides the Fluent experience in your known and loved WPF framework. Intuitive design, themes, navigation and new immersive controls. All natively and effortlessly.项目地址: https://gitcode.com/GitHub_Trending/wp/wpfui