基于.NET与Avalonia打造快速跨平台图片查看器的技术实践

做了这么多年开发，我对图片查看器一直挺挑。系统自带的要么功能太弱，要么打开慢，第三方看图工具又经常夹带广告弹窗和“全家桶”安装包。后来因为工作需要在 Windows、Linux 和 macOS 三套环境里来回切换，我越发想要一款真正开源免费、快速、跨平台的图片查看器。找了一圈没有特别顺手的，干脆基于 .NET 自己动手写了一个。这个项目做下来，也让我把图片解码、内存优化、跨平台 UI 那套东西彻底摸了一遍。这篇博客想把整个技术选型、核心设计、关键实现和踩过的坑都完整梳理出来，给同样想折腾图片工具的朋友一份可参考的方案。

1. 整体设计思路：为什么选择 .NET 做图片查看器

1.1 现有图片查看器的痛点在哪里

先说需求背景。我要的不是 Photoshop 那种重型工具，而是日常看图：打开一个文件夹，快速翻看几十上百张照片，偶尔放大看一下细节，偶尔批量整理一下。但恰恰是这种“简单”场景，很多工具做不好。

Windows 自带查看器的问题不少：启动慢，来回切换图片有黑屏等待，动辄出现“预览不可用”的占位图。很多第三方看图软件功能很全，但安装完却发现带了一堆额外服务，甚至在右键菜单里塞满推广入口。跨平台方面更麻烦，Windows 上顺手的工具到了 Linux 或 macOS 下就没有对应版本，或体验差异极大。

我一度怀疑是不是自己要求太高了。后来分析了一下，看图工具的核心难点其实不在“显示图片”这个动作上，而在三点：解码速度、内存管理、跨平台 UI 渲染。图片格式太多，每种格式的解码器质量参差不齐；大图解码一次可能占几十 MB 内存；不同平台的窗口和图像渲染接口又是各干各的。这些因素叠加起来，导致市面上的工具很难做到“既轻又快又全平台”。

1.2 技术方案对比：.NET 凭什么更合适

既然要自己写，首先就得定技术栈。我对比了几条常见路线：C++ 原生方案、Electron 方案、Python 方案、Java 方案，最后落在了 .NET 上。选型理由不复杂，我从性能、开发效率、发布体积三个方面说。

.NET 被我选中的原因有几个。一是运行时性能已经非常能打，JIT 带来的原生级执行效率，配合Span<T>、ArrayPool这类现代 API，可以写出接近 C++ 的底层操作；二是有 SkiaSharp、ImageSharp 这类成熟的图像处理库，不需要自己从零写 JPEG 解码器；三是从项目结构上看，.NET 的跨平台发布非常克制，不像 Electron 那样带一个几百 MB 的运行时，发布出来就是一个小体积可执行文件。

这里多说一句，.NET 常被人误解为“只适合做后端服务”或“只适合 Windows”，这是老黄历了。从 .NET 5 开始，运行时和 SDK 已经是大一统的跨平台实现，Linux 和 macOS 上跑 .NET 应用和 Windows 上几乎没有差异。而且 .NET 6 之后支持 Native AOT 发布，可以把托管代码直接编译成原生二进制，启动速度和内存占用还能再上一个台阶。

1.3 跨平台 UI 框架的取舍

技术栈确定后，UI 框架是另一个关键决策。如果只看 Windows，WPF 是顺理成章的选择，毕竟是微软亲儿子，XAML 生态成熟，数据绑定也舒服。但我要的是三平台统一，WPF 在 Linux 和 macOS 下跑不了，直接排除。

MAUI 也考虑过，它是 .NET 官方的跨平台 UI 方案，但当时对 Linux 的支持还不完整，而且整体处于快速迭代期，接口变化频繁，拿来维护一个有长期规划的工具不太合适。最后我选择了 Avalonia。

Avalonia 常被称为“跨平台 WPF”，因为它沿用 XAML 语言，数据绑定、样式、模板这些概念和 WPF 几乎一致。如果你写过 WPF，切过去上手成本极低。更重要的是，Avalonia 的渲染管线是自绘的，不依赖系统原生控件，这意味着同一套界面在三套系统上呈现效果完全一致，不会出现字体、间距、边距各不相同的尴尬情况。

我当时做了一个简单对比测试：在同样一台 Linux 机器上，Avalonia 应用冷启动时间大约 300ms，而 Electron 应用起步就要一秒钟。对于图片查看器来说，这个差距直接决定了用户是“双击打开立刻看图”还是“双击后盯着转圈发呆”。

2. 核心架构拆解：一个图像工具的分层逻辑

2.1 四层架构：解码、缓存、渲染、交互

确定技术栈之后，我没有直接开始堆代码，而是先把整个查看器的架构在纸上画了一遍。做工具类软件最忌讳的就是“什么都往窗口代码里塞”，一开始图省事，后面加功能就会痛不欲生。

我把整个项目分成四层：解码层、缓存层、渲染层、交互层。

• 解码层负责把任意格式的图片文件转换成统一的像素数据，屏蔽格式差异。
• 缓存层负责管理内存中的位图对象和磁盘上的缩略图文件，决定哪些数据应该保留、哪些应该淘汰。
• 渲染层负责把像素数据绘制到界面上，包括缩放、平移、旋转等操作。
• 交互层负责键盘、鼠标、拖拽、文件关联等用户输入，以及目录浏览、缩略图列表等业务逻辑。

层与层之间通过接口通信。比如解码层只暴露一个DecodeAsync(path, targetSize)的方法，至于内部是调用 SkiaSharp 还是 ImageSharp，上层完全不用关心。这样做的直接好处是，后续如果想换成其他解码器，或者给某些特殊格式写定制解码流程，只需要替换解码层的实现，不会影响其他模块。

2.2 解码层设计：为什么最终选了 SkiaSharp

图像格式兼容性是图片查看器最基础也最要命的问题。JPEG、PNG、GIF、WebP、BMP、TIFF，这些是常见的，但现实世界里的图片格式远不止这些。某些相机拍出来的 RAW 文件，某些设计软件导出的特殊格式，如果解码层不支持，工具瞬间失去了一半价值。

图像解码库我对比过两个主流选择：SkiaSharp 和 ImageSharp。

SkiaSharp 是 Google Skia 图形引擎的 .NET 绑定。Skia 本身就是 Chrome、Android 的底层图形库，解码性能和格式支持都有保障。它支持 JPEG、PNG、WebP、GIF、BMP、ICO 等常见格式，还能通过SKCodec做渐进式解码和降采样解码。此外，SkiaSharp 的渲染能力也强，绘制矢量图形、特效滤镜时可以用同一套 API，不需要引入第二个图形库。

ImageSharp 是纯托管的图像处理库，优点是没有原生依赖，部署时不需要带一堆.so或.dll文件；缺点是纯托管实现的解码器性能天花板比 Skia 低一些，在超大图片上有差距。

我最终选择了 SkiaSharp 作为主力解码和渲染引擎，ImageSharp 作为补充，用来处理 EXIF 方向修正、格式探测这些辅助任务。实际用下来，SkiaSharp 的解码速度非常稳，一个 24MB 的 JPEG 文件解码到全尺寸位图大约 150ms，配合降采样解码还能更快。需要提醒的是，SkiaSharp 依赖原生库，发布时需要特别注意对应平台的 native assets 文件。

2.3 缓存层：LRU 策略与双缓存机制

图片查看器最怕的一件事就是内存无限上涨。如果每翻一张图就把解码后的全尺寸位图保存在内存里，碰到一个几百张图片的目录，内存很快就会耗尽。缓存层的设计目标是：控制内存上限，同时保证高频访问的图片能快速响应。

我采用的是“内存缓存 + 磁盘缓存”的双层结构。

内存缓存负责最近使用的位图对象，底层是一个按访问时间排序的字典，本质是 LRU（Least Recently Used）淘汰策略。每个位图对象记录自己的像素尺寸和内存大小，当总内存超过阈值时，从最久未访问的对象开始释放。阈值我设成了系统物理内存的 25%，笔记本 16GB 内存的设备上大概是 4GB，足够放下几十张全尺寸图片，又不会挤压其他应用的内存空间。

磁盘缓存主要存两样东西：目录缩略图和已经解码过的全尺寸位图缓存文件。缩略图缓存的收益最明显：第一次打开一个目录时生成缩略图，第二次打开同一目录时可以直接从磁盘读取，速度能提升好几倍。磁盘缓存的存储位置我放在了系统的临时目录下，并且按目录路径哈希后分层存放，避免单个目录下文件太多导致文件系统变慢。

2.4 渲染层与交互层：虚拟化列表和响应式界面

渲染层在 Avalonia 里主要通过 XAML 控件树实现。主界面是一个左右布局：左侧是文件列表（缩略图流），右侧是当前图片预览区。缩略图列表使用虚拟化容器，只实例化可视区域内的项目，否则几百个图片项同时创建 UI 控件，界面会卡到无法操作。

虚拟化的关键是ItemsControl配合自定义面板，或者使用ListBox的默认虚拟化。我在项目里直接用了ListBox并设置VirtualizingPanel.IsVirtualizing="True"，然后在ItemTemplate里绑定缩略图异步加载逻辑。这样窗口滚动时，只有进入可视区域的项才会触发图片加载任务，离开可视区域后控件会被回收。

交互层更简单，但细节多。键盘左右键切换图片、鼠标滚轮缩放、双击全屏、拖拽文件到窗口打开，这些功能看似基础，但每个都需要考虑和异步加载的配合。例如快速连按右键切换图片时，上一次加载还在进行中，如果不取消，就会出现“图片闪一下又被覆盖”的竞态问题。我通过在 ViewModel 中维护一个加载序号，只接受最新一次加载结果，旧任务完成后直接丢弃，彻底解决了这个问题。

3. 关键实现与性能优化细节

3.1 启动提速：预加载与延迟加载的配合

图片查看器的“快”分为两个维度：启动快和切换快。启动快的关键是不做多余的事。

很多看图工具启动慢，问题出在初始化流程里做了太多同步操作。比如启动时扫描磁盘、加载配置、初始化日志系统，这些都要等界面显示完成之后再做。我采用的策略是：主窗口先显示，后台线程再慢慢做其余初始化。

具体来说，程序启动时先实例化渲染窗口，然后立刻加载“最近打开的目录”或“启动参数指定的图片文件”，其余像文件类型关联检查、缩略图数据库扫描、版本更新检测之类的工作，全部放到后台任务里。实测同一台机器上，冷启动到第一张图片显示出来大约 400ms，基本做到了双击文件图标就出图的体验。

3.2 快速切换图片：预取队列和双缓冲渲染

快速翻图是最考验性能的场景。用户按住右键不放，一秒内要切换好几张图片，如果每张图都是“点击后才开始加载”，人眼能明显感知到卡顿。

解决方案是预取队列。我在 ViewModel 中维护一个环形预取逻辑：当前图片显示后，立刻在后台线程启动下一个图片的解码任务，同时保留上一个图片的位图对象。因为本地文件解码的速度通常在几十到几百毫秒，预取任务足够在用户下一次按键前完成解码。用户按右键时，新图片已经躺在内存缓存里了，界面只需要做一次位图绑定，几乎零延迟。

双缓冲渲染解决的是“闪烁”问题。默认情况下，每次替换图片都会清空当前画布再绘制新图，中间会闪一下白屏或黑屏。我在渲染层用两个WriteableBitmap交替绘制，新图绘制完成后再整体替换到界面上，从视觉上完全消除了闪烁。这个处理对连续翻图的体验提升非常明显。

3.3 内存控制：降采样解码与智能释放

内存爆炸是图片查看器的头号问题，尤其是遇到超高分辨率图片时。一张 8000x6000 像素的照片，解码成未压缩的 BGRA 位图后占用约 192MB 内存（8000 x 6000 x 4 字节）。如果同时加载几张这样的图片，内存直接见底。

解决思路是“按需解码”。图片显示时永远不应该把整个图片解成全尺寸位图。

我的方案分两步。第一步，首次打开图片时，解码器先读图片文件的头部信息，拿到原始宽度和高度，然后根据当前界面显示区域的尺寸和缩放比例，计算出实际需要的像素大小。第二步，使用SKCodec的缩放解码能力，直接在解码阶段把图片降采样到目标尺寸。比如一张 8000x6000 的照片在界面上只需要 1920x1080 的区域显示，那我解码时就只解 1920x1080，内存占用只有原来的三分之一左右。

用户放大图片查看细节时，再针对需要查看的局部区域做高分辨率解码。这样即使打开几百 MB 的超大图，内存也能稳定控制在一定范围内。

3.4 高 DPI 与多显示器适配

跨平台应用逃不开高 DPI 适配。不同系统的高分屏缩放逻辑不一致，Windows 推荐 150% 或 200% 缩放，macOS 的 Retina 屏使用 2 倍逻辑像素，Linux 桌面环境则千奇百怪。如果应用不做适配，图片显示会发虚，字体和控件大小也会失调。

Avalonia 的渲染管线本身对高 DPI 处理得较好，按逻辑像素布局，再由后端渲染到物理像素。我额外做了两件事：第一，图片显示时以物理像素为单位解码，避免在 Retina 屏上显示 1 倍图导致模糊；第二，监听窗口的ScalingChanged事件，在缩放比例变化时重新计算预览区尺寸并触发重新解码。多显示器场景下，用户把窗口从 100% 缩放的屏幕拖到 200% 缩放的屏幕，图片会自动重新适配清晰度，不再需要手动操作。

4. 实操过程：从零搭建一个最小可用的图片查看器

4.1 环境准备与项目初始化

如果你也想自己试一遍，我从项目初始化开始完整走一遍流程。首先需要安装 .NET SDK 8.0 或更高版本，然后安装 Avalonia 的项目模板。

dotnet new install Avalonia.Templates dotnet new avalonia.app -n QuickImageViewer cd QuickImageViewer

项目创建完成后，需要添加 NuGet 包。我使用的包清单如下。

dotnet add package Avalonia dotnet add package Avalonia.Desktop dotnet add package Avalonia.Themes.Fluent dotnet add package SkiaSharp dotnet add package SkiaSharp.NativeAssets.Linux.NoDependencies dotnet add package SkiaSharp.NativeAssets.Win32 dotnet add package SkiaSharp.NativeAssets.macOS

注意SkiaSharp.NativeAssets.*这组包必须按目标平台分别引用。它们体积不大，但决定了 SkiaSharp 在不同操作系统上能否正常工作。如果发布时漏掉某个平台的 native 包，对应系统上运行就会抛出 DllNotFoundException。

4.2 核心代码实现：目录加载与异步解码

项目结构上，我采用了 MVVM 模式，MainWindowViewModel负责目录加载和图片输出，MainWindow负责键盘事件和控件绑定。核心逻辑集中在 ViewModel 中。

首先是目录加载和图片集合的构建。代码逻辑并不复杂，关键是过滤文件时不要用File.Exists再判断一次，直接用枚举器过滤扩展名即可，大数据量下性能差距明显。

public class MainWindowViewModel : ReactiveObject { public ObservableCollection<ImageItem> Images { get; } = new(); private ImageItem _currentImage; public ImageItem CurrentImage { get => _currentImage; set => this.RaiseAndSetIfChanged(ref _currentImage, value); } public void LoadFolder(string folderPath) { Images.Clear(); var extensions = new HashSet<string> { ".jpg", ".jpeg", ".png", ".bmp", ".gif", ".webp", ".tiff" }; foreach (var file in Directory.EnumerateFiles(folderPath)) { if (extensions.Contains(Path.GetExtension(file).ToLowerInvariant())) { Images.Add(new ImageItem(file)); } } if (Images.Count > 0) CurrentImage = Images[0]; } }

然后是异步解码方法。这里我故意把“解码到目标尺寸”和“显示全尺寸”分开处理。默认情况下只加载适合当前界面的尺寸，用户双击或按 Z 键时才加载全尺寸细节。

public async Task<SKBitmap> DecodeAsync(string path, int targetWidth, int targetHeight) { using var stream = File.OpenRead(path); using var codec = SKCodec.Create(stream); var info = codec.Info; var scale = Math.Min((double)targetWidth / info.Width, (double)targetHeight / info.Height); var scaledWidth = Math.Max(1, (int)(info.Width * scale)); var scaledHeight = Math.Max(1, (int)(info.Height * scale)); var bitmap = new SKBitmap(scaledWidth, scaledHeight, SKColorType.Bgra8888, SKAlphaType.Premul); var result = codec.GetPixels(bitmap.Info, bitmap.GetPixels()); return result == SKCodecResult.Success ? bitmap : null; }

这里有一个关键细节，我一开始没注意到：SKCodec.GetPixels时可以传入一个已经调整好尺寸的目标SKBitmap，解码器会自动完成降采样，不需要先解全尺寸再缩放，这对内存和 CPU 的节省非常大。

接下来，缩略图列表的绑定需要用到异步加载。我在ImageItem中暴露一个Thumbnail属性，首次请求时发起后台加载，加载完成后触发属性变更通知，缩略图控件就会自动更新。

public class ImageItem : ReactiveObject { public string Path { get; } public string Name => System.IO.Path.GetFileName(Path); private SKBitmap _thumbnail; public SKBitmap Thumbnail { get { if (_thumbnail == null) _ = LoadThumbnailAsync(); return _thumbnail; } private set => this.RaiseAndSetIfChanged(ref _thumbnail, value); } private async Task LoadThumbnailAsync() { var bitmap = await DecodeAsync(Path, 256, 256); Thumbnail = bitmap; } }

需要注意，这种“get 时触发异步加载”的写法依赖属性绑定机制。Avalonia 绑定到Thumbnail时会读取一次 getter，getter 里启动后台任务，任务完成后通过RaiseAndSetIfChanged通知界面刷新。实际跑起来滚动缩略图列表时，加载任务往往密集触发，所以这个属性内部始终要保证同一时间只有一个加载任务在执行，否则会重复解码同一个文件，我直接用属性判空来做了防重。

键盘左键/右键切换图片的逻辑比较简单，但做了可见性校验，列表为空时按键不处理任何逻辑。

private void OnKeyDown(object sender, KeyEventArgs e) { if (Images.Count == 0) return; var index = Images.IndexOf(CurrentImage); if (e.Key == Key.Right && index < Images.Count - 1) CurrentImage = Images[index + 1]; else if (e.Key == Key.Left && index > 0) CurrentImage = Images[index - 1]; }

4.3 跨平台发布与单文件打包

开发调试完成后，发布是最容易翻车的环节。SkiaSharp 原生库的存在让发布流程比普通 .NET 应用复杂一点点，但只要配置好 RuntimeIdentifier，问题不大。我整理了三个平台的发布命令。

dotnet publish -c Release -r win-x64 --self-contained -p:PublishSingleFile=true dotnet publish -c Release -r linux-x64 --self-contained -p:PublishSingleFile=true dotnet publish -c Release -r osx-x64 --self-contained -p:PublishSingleFile=true

--self-contained参数会把 .NET 运行时和你的应用打包在一起，这样目标机器上不需要安装 .NET 运行时。代价是发布体积会增加到 60MB 左右，但对工具软件来说可以接受，毕竟换来的是“拷过去就能跑”的便利。

有一点要特别提醒：单文件发布时，SkiaSharp 的原生库会被嵌入到单文件内部，首次运行时 .NET 会把它们解压到临时目录。如果杀毒软件对解压行为敏感，可能拖慢首次启动速度，或者弹出拦截。遇到这种问题时不用和杀毒软件硬刚，改成“非单文件 + 各自平台的原生库”发布即可，体积大一点，但兼容性更好。

4.4 UI 布局实现细节

主窗口的 XAML 布局我精简一下贴出来。顶部是工具栏，左侧缩略图列表面板，右侧预览区域。缩略图列表使用虚拟化，预览区图片的Stretch设置为 Uniform，保证图片等比缩放。

<Window xmlns="https://github.com/avaloniaui" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Width="1200" Height="800"> <DockPanel> <Menu DockPanel.Dock="Top"> <MenuItem Header="文件"> <MenuItem Header="打开文件夹" Command="{Binding OpenFolderCommand}"/> </MenuItem> </Menu> <Grid> <Grid.ColumnDefinitions> <ColumnDefinition Width="280"/> <ColumnDefinition Width="*"/> </Grid.ColumnDefinitions> <ListBox Grid.Column="0" ItemsSource="{Binding Images}" SelectedItem="{Binding CurrentImage}" VirtualizingPanel.IsVirtualizing="True" VirtualizingPanel.VirtualizationMode="Recycling"> <ListBox.ItemTemplate> <DataTemplate> <StackPanel Orientation="Horizontal"> <Image Width="64" Height="64" Stretch="Uniform" Source="{Binding Thumbnail}"/> <TextBlock Text="{Binding Name}" VerticalAlignment="Center"/> </StackPanel> </DataTemplate> </ListBox.ItemTemplate> </ListBox> <Border Grid.Column="1" Background="#1E1E1E"> <Image Source="{Binding CurrentImage.FullImage}" Stretch="Uniform"/> </Border> </Grid> </DockPanel> </Window>

界面实现中使用的CurrentImage.FullImage属性，同样采用异步加载模式，加载时先显示一个低分辨率占位图，全尺寸解码完成后替换。这样用户看到的始终是“有图”，而不是一片空白等待区。

5. 常见问题与排查技巧实录

5.1 图片在界面上显示模糊

排除原始图片本身分辨率低的因素后，模糊通常出在“解码尺寸和显示尺寸不匹配”上。尤其在高 DPI 屏幕上，如果解码时不考虑物理像素比例，界面会为了提高清晰度请求更大的图像区域，而解码结果依然停留在逻辑像素大小，就会出现发虚。

解决办法是计算解码尺寸时乘上VisualTreeHelper.GetDpi(window).PixelsPerDip系数。另一个常见原因是没有启用布局舍入。XAML 布局有时会把控件定位到小数像素位置（比如 x=10.5），导致图像采样错位，界面表现为轻微模糊。给Window设置UseLayoutRounding="True"能缓解这个问题。

5.2 内存占用持续增长，甚至崩溃

这个问题的根源绝大多数是“位图对象没有释放”。Skia 的SKBitmap底层是非托管内存，虽然SKBitmap实现了IDisposable，但如果你只依赖 GC 自动回收，托管堆压力一大，GC 迟迟不触发终结器，原生内存早就爆了。

我的排查思路分三步。第一步，用dotnet-counters监控进程的 GC Heap Size 和 Native Memory 指标，判断内存涨在托管堆还是原生堆。第二步，检查所有解码路径是否套用了using语句，尤其是SKBitmap、SKImage、SKCodec这三种对象。第三步，在缩略图列表中启用虚拟化回收模式，让离开可视区域的图片项被回收时立刻调用Dispose()释放位图。

实际代码里，我在ImageItem的析构逻辑中统一释放了Thumbnail，同时在图片切换时通过IDisposable管理旧位图的生命周期。有一类特殊情况需要留心：SKBitmap作为Image.Source绑定时，控件层面可能会保持引用，如果释放太早会出现“图片画到一半原生内存已经被回收”导致的崩溃。稳妥做法是先将源从控件上解除绑定，再释放位图。

5.3 大图加载时界面卡死

大图卡死几乎都是因为解码发生在 UI 线程。SKCodec的GetPixels是同步阻塞方法，调用一次可能耗时几百毫秒甚至几秒，放在 UI 线程里必然卡界面。

我的处理原则是：任何可能超过 50ms 的操作全部走后台任务。包括文件流读取、解码、降采样计算。代码上统一用Task.Run或者async/await承载，只有最后把SKBitmap赋给Image.Source时才回到 UI 线程。

另外还有一个容易被忽视的卡顿来源：解码时如果传入的targetWidth或targetHeight为 0，某些解码器实现会退化为全尺寸解码，内存和 CPU 消耗瞬间飙升。我曾在窗口初始尺寸未确定时触发过一次解码，直接把图片解到 8000 像素宽，无谓消耗了几百 MB 内存。加一个“尺寸小于阈值时延迟解码”的判断即可避免。

5.4 快速翻图时偶尔出现图片错位

错位问题实际上是异步加载竞态导致的。用户按右键从图 1 切到图 2，紧接着又按右键切到图 3，此时图 2 的加载任务可能才刚完成。由于异步任务没有保证执行完成顺序，界面可能收到了“先加载完成图 3、后加载完成图 2”的结果，最终界面显示的图片与当前索引不一致。

解决方式在 2.4 节已经提过，我维护了一个“加载序列号”。每次切换图片时，将当前请求序号加 1。异步解码完成后，拿完成时的序号和当前序号比较，只有相等时结果才会被采纳。这样即使旧任务较晚完成，也只能默默放弃，不会再污染界面状态。

5.5 浏览中的文件被外部程序修改或删除

浏览照片时可能遇到正在用的文件被外部程序删除，或者相机存储卡尚未完全弹出等情况。如果解码前直接用File.ReadAllBytes读取文件，会遇到文件占用或文件不存在的问题。我统一采用File.OpenRead模式，先打开句柄，解码完成后立即关闭，尽量避免长时间占用文件句柄。另外对解码失败有明确的降级策略：返回一个带“无法预览”占位图的空SKBitmap，而不是抛异常让整个窗口崩溃。

6. 实测性能数据与效果对比

项目跑通以后，我找了一台普通配置的笔记本做了几组测试。硬件是某款 i5 处理器、16GB 内存、SATA 固态硬盘、Windows 11 系统，测试目录包含 500 张平均 5MB 的照片。

启动速度方面，冷启动到第一张图片显示耗时约 400ms。作为对比，某知名第三方看图软件同样环境下大约需要 900ms。连续翻图方面，按住右键快速切换，每秒大约可以切换 8-10 张图片，期间 UI 保持响应，不再出现白屏闪烁。目录首次缩略图加载耗时约 3 秒，第二次打开同一目录时因为有磁盘缓存，缩略图几乎瞬时显示。内存峰值则稳定在 600MB 以内，翻完 500 张图片后回落，没有累积性增长。

这些数据比我最初预想的要好一些，尤其是翻图流畅度，双缓冲渲染加预取队列的组合确实解决了看图工具最重要的体验问题。不同机器上结果会有差异，但相对趋势是一致的。

7. 扩展方向与后续计划

基础图片查看器已经能覆盖日常需求了，但实际使用中我仍然发现几个值得扩展的方向。第一个是格式转换和批处理功能，比如把一批 RAW 文件统一转成 JPEG，或者批量调整图片尺寸，这类需求在很多工作流中都会遇到。第二个是对 GIF 动画的播放支持，当前实现只显示首帧，要做全功能支持需要引入帧序列管理和独立的时间线控制。第三个是网络图片协议支持，例如从远程路径加载图片，这涉及流式下载和缓存过期策略，属于另一套逻辑了。

这些功能都可以在现有架构上平滑增加，因为分层设计本来就是为了给后续扩展留余地。解码层新增一个 RAW 解码器，缓存层增加磁盘配额管理，交互层加一个批处理面板，不需要改动核心渲染逻辑。

最后再分享一个小技巧：在迭代开发过程中，给每个版本做一次“打开 500 张图片并连续翻看”的冒烟测试，观察内存曲线和翻图耗时。图片查看器这种工具的性能退化是渐进的，可能某次改动只让内存上涨了几十 MB，当时察觉不到，但累积几次就变得不可用了。把性能测试脚本化，比任何代码审查都更能守得住工具的核心体验。