OpenCV Mat 转 ImageSource，WinUI3 极致性能优化实践

OpenCVMat转ImageSourceWinUI3

|难度：普通|阅读约 33 分钟

Opencv Mat 转 ImageSource，WinUI3 极致性能版

干过WinUI3图像显示这块的兄弟应该都有同感：OpenCV里一切好说，Mat一拿，算法随便跑，可到了显示环节，突然卡住了。WinUI3的Image控件不认Mat，你没法直接把一帧BGR数据甩给Image.Source让它显示出来。网上搜到的大多是UWP时期的旧代码，换到WinUI3上各种踩坑，要么性能拉胯，要么内存暴涨，要么干脆显示不出来。

这个需求太常见了：摄像头实时预览、工业视觉检测界面、图像算法调试工具，哪个都绕不开“把OpenCV处理完的画面实时刷到界面上”。而且一旦涉及实时预览，性能就不是加分项而是刚需了——你总不希望摄像头采集30帧，界面卡成PPT，或者跑个算法内存从200MB一路涨到2GB再被系统干掉。

这篇文章我不打算东拉西扯，就专门把“Mat转ImageSource”这条链路掰开揉碎，讲讲为什么常规写法慢、怎么写出真正能用在高帧率场景下的极致性能版本。

1. 先把性能瓶颈想清楚：Mat和ImageSource之间到底隔着什么

1.1 Mat的内存结构，决定了你不能拿它在UI线程里瞎折腾

先说点基础的，这部分不搞清楚，后面代码就是抄了也不知道为什么。OpenCV的Mat本质上是cv::Mat类包装的一块连续内存，数据布局是像素按行排列，每行像素紧密挨着。常用的三通道彩色图是BGR顺序（不是RGB，这个顺序坑了无数人），单通道是灰度，四通道是BGRA。

关键点有两个：一是Mat的像素数据在内存里是连续排布的，也就是我们常说的isContinuous()为true时，整个矩阵就是一块完整的大内存；二是Mat跨行到下一行时，可能存在一个叫step（行步长）的东西，它不一定等于width * channels。OpenCV在做ROI（感兴趣区域）裁剪或者从外部数据填充时，step可能比实际的图像宽度更大，也就是行尾有“填充字节”。

这两个特性说明了什么？说明你想把这帧图像显示出来，最朴素的做法就是从Mat数据区域逐行逐像素地“扣”出来，再重新组装成WinUI3认识的图像对象。这一步所有方案都逃不掉，区别只是谁来拷、怎么拷、拷几次。

1.2 WinUI3的图像来源，本质就是个“数据交接”问题

再来看WinUI3这边。Image控件接受的Source类型是ImageSource，而实际常用到的主要有BitmapImage、WriteableBitmap、SoftwareBitmapSource这么几种。BitmapImage一般用于加载本地文件或网络URL，它内部要走一遍图片解码，性能表现一般，而且你得先把Mat编码成PNG或JPEG再喂给它——记住，编码一次、解码一次，这中间全是无效开销，一帧两帧还行，实时视频流用这个就是灾难。

WriteableBitmap稍微好一点，你可以在后台线程拿到它的像素缓冲区PixelBuffer，通过Stream方式写入数据，但是WriteableBitmap在WinUI3里受线程亲和性限制比较明显，而且它本质上是每次写完整个Buffer再整体刷新，对需要频繁更新的视频流来说也不是最优解。

SoftwareBitmapSource才是这套链路的关键。它内部持有SoftwareBitmap对象，而SoftwareBitmap是一个与具体UI控件解耦的像素容器，你可以在后台线程构造它、往里面填数据，再通过SoftwareBitmapSource.SetBitmapAsync把它交给Image控件显示。整个流程打通了一条“后台抠数据、前台只显示”的通道，这也是本篇所有性能优化的地基。

1.3 为什么“极致性能”的核心是减少拷贝次数

我把问题再翻译一下：Mat数据在CPU内存里，Image控件最终要显示的是一块系统认可的位图数据。整个过程你能优化的就是“从Mat到最终显示”这条流水线上，拷贝了几次、产生了多少临时对象、有没有在UI线程上做耗时操作。

最差的写法长什么样？每一帧都new一个BitmapImage，Mat先imencode成JPEG，再new MemoryStream塞进去，再SetSourceAsync。一次循环下来，编码、流操作、解码、UI线程等待，全齐了。30FPS的视频能给你干到8帧，CPU风扇直接起飞。

常规的写法是用SoftwareBitmap配合CopyFromBufferAsync，每一帧创建一个Buffer，再调用一次异步拷贝。这个方法性能可接受，但依然存在每帧重新分配内存的问题，长时间运行会带来明显的GC压力。

极致的写法，核心就一句话——复用一切能复用的对象。SoftwareBitmap提前创建好，Buffer底层内存只分配一次，每帧把Mat数据直接拷过去；颜色转换、步长修正这些活干一次就缓存结果；UI线程只负责一次轻量级的位图绑定。这套搞完，4K分辨率的视频流在WinUI3里跑满60帧基本是轻松的事。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 从Mat到SoftwareBitmap：核心转换链路的完整实现

2.1 像素格式对齐：BGR和BGRA的坑，踩一次就长记性

先说一个最常见也最坑的问题：OpenCV三通道图像默认是BGR布局，而Windows的位图格式大多数是BGRA或BGR，虽然两个都是“B在最前”，但WinUI3对BitmapPixelFormat.Bgra8的支持最完整，性能也最好。所以正确的姿势不是直接拿三通道Mat去转换，而是先把Mat转成四通道BGRA。

具体做法是：

cpp复制cv::Mat bgraMat;
cv::cvtColor(bgrMat, bgraMat, cv::COLOR_BGR2BGRA);

这里有几个细节要留意：

如果你的Mat本身就是四通道BGRA（比如从某些摄像头驱动或GPU拿到的数据），就不要做这步转换了，直接走，省一次拷贝。
如果Mat是灰度图，也不能直接转，要做COLOR_GRAY2BGRA，否则显示出来只有蓝色通道有内容，画面整体发蓝发暗。
颜色转换本身是有CPU开销的，所以如果算法流程允许，最好在图像源头就统一成BGRA四通道，让整个管线从头到尾只维护一种格式，能省不少事。

2.2 stride对齐和行拷贝：为什么直接memcpy会花屏

我见过不少新手的写法是拿到Mat的data指针，然后对着SoftwareBitmap一整块缓冲区直接memcpy，结果显示出来图像是斜着的，或者有绿色条纹。原因就是stride不匹配。

SoftwareBitmap的缓冲区要求每行数据对齐到4字节（width * 4），而Mat的step（行跨度）不一定是width * 4。比如你在1280x720的图像上截取了一个ROI，cols变成640了，但step可能还是原来图像的行跨度5120字节，而不是640*4=2560字节。这时候直接整块拷贝，每一行数据都错位，显示出来自然就是花的。

正确的做法是逐行拷贝，用Mat的step作为源行跨度，用目标缓冲区每行固定长度作为目的行跨度：

cpp复制uchar* srcData = bgraMat.data;
size_t srcStep = bgraMat.step;
size_t dstStep = width * 4; // Bgra8格式固定每像素4字节

for (int row = 0; row < height; row++)
{
    memcpy(dstPtr + row * dstStep, srcData + row * srcStep, dstStep);
}

SoftwareBitmap的CopyToBuffer或者buffer.CopyFrom这些API会处理一部分对齐逻辑，但要真正做到高效还是推荐走底层的IMemoryBufferByteAccess接口，直接拿到底层字节指针来操作，这样既能做整块拷贝（步长一致时），也能精确控制逐行拷贝。

2.3 一套可以直接抄的Mat转SoftwareBitmap完整代码

下面这套代码是我在实际项目里验证过的，核心逻辑就是先做颜色转换，再拿到SoftwareBitmap的底层内存指针，逐行拷贝数据。为了拿到指针需要使用COM接口，代码需要开启AllowUnsafeBlocks。

先在项目里定义COM互操作接口：

csharp复制[ComImport]
[Guid("5B0D3235-4DBA-4D44-865E-8F1D0E4FD04D")]
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
unsafe interface IMemoryBufferByteAccess
{
    void GetBuffer(out byte* buffer, out uint capacity);
}

再写核心转换方法：

csharp复制public static SoftwareBitmap MatToSoftwareBitmap(Mat mat, BitmapPixelFormat format = BitmapPixelFormat.Bgra8)
{
    // 统一转成 BGRA 四通道
    Mat bgra;
    if (mat.Channels() == 4 && mat.Type() == MatType.CV_8UC4)
    {
        bgra = mat;
    }
    else if (mat.Channels() == 3)
    {
        bgra = new Mat();
        Cv2.CvtColor(mat, bgra, ColorConversionCodes.BGR2BGRA);
    }
    else if (mat.Channels() == 1)
    {
        bgra = new Mat();
        Cv2.CvtColor(mat, bgra, ColorConversionCodes.GRAY2BGRA);
    }
    else
    {
        throw new NotSupportedException($"不支持的Mat通道数: {mat.Channels()}");
    }

    int width = bgra.Cols;
    int height = bgra.Rows;
    uint dstStep = (uint)(width * 4);

    // 直接创建 SoftwareBitmap，指定 BGRA8 格式
    var softwareBitmap = new SoftwareBitmap(
        BitmapPixelFormat.Bgra8,
        width,
        height,
        BitmapAlphaMode.Ignore);

    using (var buffer = softwareBitmap.LockBuffer(BitmapBufferAccessMode.Write))
    using (var reference = buffer.CreateReference())
    {
        unsafe
        {
            byte* dstPtr;
            uint capacity;
            ((IMemoryBufferByteAccess)reference).GetBuffer(out dstPtr, out capacity);

            if (bgra.IsContinuous())
            {
                // ROI 情况可能 step != dstStep，直接判断是否紧凑
                if (bgra.Step() == dstStep)
                {
                    // 最理想情况：连续且行跨度一致，直接整块拷
                    Buffer.MemoryCopy(
                        (void*)bgra.DataPointer,
                        dstPtr,
                        capacity,
                        (long)bgra.Step() * height);
                }
                else
                {
                    // 行跨度不一致，但内存连续，逐行拷
                    for (int row = 0; row < height; row++)
                    {
                        Buffer.MemoryCopy(
                            (void*)(bgra.DataPointer + row * bgra.Step()),
                            dstPtr + row * dstStep,
                            dstStep,
                            dstStep);
                    }
                }
            }
            else
            {
                // 非连续内存，逐行拷最保险
                for (int row = 0; row < height; row++)
                {
                    Buffer.MemoryCopy(
                        (void*)(bgra.DataPointer + row * bgra.Step()),
                        dstPtr + row * dstStep,
                        dstStep,
                        dstStep);
                }
            }
        }
    }

    // 如果 cvtColor 创建了临时对象，及时释放
    if (!ReferenceEquals(bgra, mat))
    {
        bgra.Dispose();
    }

    return softwareBitmap;
}

这段代码的核心逻辑，先是按通道数分类处理，统一转到BGRA；然后在拷贝阶段，判断Mat是否连续、行跨度是否和Bitmap完全对齐，尽量用整块拷贝，省掉不必要的逐行操作；最后记得释放cvtColor产生的临时Mat，避免非托管内存泄漏。

注意：Buffer.MemoryCopy要求启用unsafe代码。在.csproj里加<AllowUnsafeBlocks>true</AllowUnsafeBlocks>即可。另外x64环境下指针操作没问题，如果项目跑x86，要注意内存分配上限，别超了2GB。

3. 极致性能的三板斧：对象复用 + 异步转码 + 帧率控制

3.1 第一板斧：SoftwareBitmap和底层Buffer的复用

如果按上面的代码每帧新建一个SoftwareBitmap，性能已经比BitmapImage方案好很多了，但仍然不够极致。为什么？因为每帧都会在托管堆上分配一个SoftwareBitmap，而且LockBuffer拿到的底层内存也会跟着一起分配释放，时间一长，GC压力会逐渐显现，帧率会越来越不稳定。

极致的做法是：在启动阶段就把SoftwareBitmap建好，之后的每一帧只往它内部的内存块里拷数据，最理想的情况下连LockBuffer都不需要每帧都做。

可以把循环外的东西都提出来，做成一个专门的类：

csharp复制public sealed class MatToImageSourceConverter : IDisposable
{
    private SoftwareBitmap _bitmap;
    private SoftwareBitmapSource _source;
    private IMemoryBufferByteAccess _access;
    private int _width;
    private int _height;
    private BitmapPlane _plane;

    public SoftwareBitmapSource Source => _source;

    public MatToImageSourceConverter(int width, int height)
    {
        _width = width;
        _height = height;
        
        // 预创建，一次性分配
        _bitmap = new SoftwareBitmap(BitmapPixelFormat.Bgra8, width, height, BitmapAlphaMode.Ignore);
        _source = new SoftwareBitmapSource();

        var buffer = _bitmap.LockBuffer(BitmapBufferAccessMode.Write);
        var reference = buffer.CreateReference();
        _access = (IMemoryBufferByteAccess)reference;
        _plane = buffer.GetPlaneDescription(0);
    }

    public async Task UpdateAsync(Mat mat)
    {
        // 这里假设mat已经转到BGRA格式
        unsafe
        {
            byte* dstPtr;
            uint capacity;
            _access.GetBuffer(out dstPtr, out capacity);

            // 判断mat和目标平面是否对齐
            if (mat.IsContinuous() && mat.Step() == _plane.StartIndex || mat.Step() == _plane.Stride)
            {
                // 快速路径
            }
            else
            {
                // 逐行拷贝
            }
        }
        
        await _source.SetBitmapAsync(_bitmap);
    }

    public void Dispose()
    {
        _bitmap?.Dispose();
    }
}

这个预创建方案，把LockBuffer、CreateReference、GetPlaneDescription全部提到构造函数里做一次，后续每帧更新只需要数据拷贝和SetBitmapAsync两步，整个开销降到了最低。

需要注意的一点是，_bitmap.LockBuffer返回的BitmapBuffer对象要保留引用，不能让它被GC回收，否则后续GetBuffer拿到的指针可能会不稳定。我在实际项目里就吃过这个亏，一开始只保存了指针，没有保存BitmapBuffer引用，运行一段时间后指针失效，图像花屏或直接崩溃。

3.2 第二板斧：图像处理放后台线程，UI线程只做绑定

WinUI3的UI线程非常娇贵，你哪怕在UI线程里做一个大点的for循环，界面都会有心跳停止的感觉。更别提OpenCV的cvtColor、resize这种重型操作了，放在UI线程就是自寻死路。

所以正确的架构是拉一条专门的工作线程/任务来处理图像帧。以摄像头为例：

csharp复制// 后台线程里干重活
Task.Run(() =>
{
    while (_isRunning)
    {
        Mat frame = _capture.RetrieveMat();
        
        // 各种OpenCV处理...
        Mat bgra = new Mat();
        Cv2.CvtColor(frame, bgra, ColorConversionCodes.BGR2BGRA);
        
        // 回UI线程更新
        _dispatcherQueue.TryEnqueue(async () =>
        {
            await _converter.UpdateAsync(bgra);
        });
        
        bgra.Dispose();
        frame.Dispose();
    }
});

这里有个细节：DispatcherQueue.TryEnqueue的回调里不能再做耗时操作，它应该只负责数据绑定。如果摄像机帧率高于屏幕刷新率，你甚至可以做丢帧处理——上一帧还没显示完，这一帧的数据就直接丢弃，界面永远显示最新的一帧，保证延迟最小。

至于能不能直接在后台线程调用SetBitmapAsync，我实验下来的结论是：SoftwareBitmapSource.SetBitmapAsync在WinUI3里需要在UI线程调用。你别看它是个异步方法，它的内部实现会触碰UI相关的核心组件，在后台线程调用大概率会抛异常或者行为诡异。踩过坑之后我就老老实实回UI线程了，实测下来性能损失很小，因为SetBitmapAsync本身的开销微乎其微，大头还是在数据拷贝和颜色转换上。

3.3 第三板斧：放弃“每帧都转”，用帧率控制和缓冲池保平稳

极端性能优化到后面，瓶颈往往不在CPU算力，而在内存分配和GC。每帧new Mat、每帧new byte[]、每帧cvtColor分配的临时内存，都会成为GC的“催命符”。

对这个问题，我常用三个策略：

第一个是循环复用Mat对象。在摄像头采集循环外创建好固定的Mat，每帧采集直接cap.Read(mat)，避免每帧创建新Mat对象。OpenCV的VideoCapture.Read会自己处理内部缓冲，传入已有的Mat它就复用底层的分配，不会频繁做大块内存的malloc/free。

第二个是Mat对象池。如果你的算法流程里需要好几层中间结果（比如先转灰度、再模糊、再边缘检测），每一层都用同一个Mat反复写，而不是每帧新建。这里要记住C#里Mat是引用类型，如果你把mat传给另一个函数并在里面create，它可能重新分配内存，所以尽量用copyTo而不是直接传引用等它内部重新分配。

第三个是使用帧率限制。不是所有场景都需要全帧率跑，比如做模型推理预览，30帧的输入但有10帧的显示反而看得更清楚，因为界面不会闪烁。用一个简单的滑动窗口做限流：

csharp复制// 每100ms最多刷新一次界面，也就是最高10fps
if (stopwatch.ElapsedMilliseconds - _lastUpdateMs >= 100)
{
    await _converter.UpdateAsync(bgra);
    _lastUpdateMs = stopwatch.ElapsedMilliseconds;
}

这三板斧组合下来，我实际测过一个1080p分辨率的工业检测界面，OpenCV做高斯模糊加轮廓查找，WinUI3界面上实时预览，CPU占用率从最初写法的35%降到了8%左右，内存从波动50MB变成了稳定线。稳定性带来的体验提升比帧率数字本身重要得多。

4. 常见翻车现场与排查技巧实录

4.1 图像颜色不对，整个画面发绿或者蓝得发黑

这是Mat转ImageSource最经典的颜色问题。根本原因就一句话：OpenCV的默认三通道顺序是BGR，而你在给SoftwareBitmap填数据时把它当成了RGB。

你如果用了cvtColor(mat, mat, ColorConversionCodes.BGR2RGB)再填进去，颜色会正常，但速度慢；你要是直接用CopyToBuffer，那画面一定是发蓝发暗的。正确做法前面已经讲了，统一用COLOR_BGR2BGRA转成四通道，然后让SoftwareBitmap也用Bgra8格式，这样就不存在通道顺序错乱的余地了。

如果你是在做灰度图显示，别忘了COLOR_GRAY2BGRA这步。而且BitmapAlphaMode要设置成Ignore，否则有的控件会去解析Alpha值，遇到没有初始化Alpha的像素值就会表现出随机透明，界面看起来跟马赛克一样。

4.2 画面有斜条纹或者整体错位，像歪了45度

这个基本就是stride没对齐。不管你是用SoftwareBitmap还是WriteableBitmap，每行数据都有固定的字节数要求。你拿着Mat的data直接整块memcpy到Bitmap的缓冲区，数据是按Mat的步长排列的，显示却按Bitmap的步长去读，一个错位，全图歪。

排查方法很简单：打印出Mat的Step()和Bitmap的Stride，对比一下数值。如果Mat的Step()是20480，Bitmap的Stride是4096，说明Mat的行长和Bitmap的行宽差了好几倍，这时候要么逐行拷贝，要么用CopyTo重新layout。

4.3 内存持续上涨，跑几分钟就飙到2GB

内存上涨有几种情况，我几乎都遇过。

第一种是Mat泄漏。OpenCV的C#封装OpenCvSharp里Mat虽然实现了IDisposable，但只要还有引用未被释放，非托管内存就不会返还系统。你在循环里每帧new Mat却只Dispose一部分，内存就会涨。排查方法是在循环里定期调用GC.GetTotalMemory(true)和Process.GetCurrentProcess().WorkingSet64，对比趋势；更狠的办法是用OpenCvSharp自带的MatMemoryManager之类的工具做追踪。

第二种是SoftwareBitmap泄漏。SoftwareBitmapSource每帧都SetBitmapAsync到一个新创建的SoftwareBitmap上，旧的SoftwareBitmap如果没有释放，它占用的CPU/GPU内存也会一直堆积。你要做的是要么复用同一个SoftwareBitmap，要么在替换时主动Dispose掉旧的。

第三种是每帧创建Stream/Buffer对象，MemoryStream用完没关，缓冲区数组留在LOH（大对象堆）里反复晋升。LOH的对象不是马上回收的，累积到一定量会触发Full GC，让你感觉界面周期性地卡顿。这个问题的终极解法还是对象复用，把byte[]和MemoryStream都提出来循环用。

4.4 帧率上限卡在30，调了半天上不去

WinUI3使用SoftwareBitmapSource时，默认的VSync和合成器机制会让显示频率和屏幕刷新率绑定。如果你在60Hz屏幕上只能稳定30帧，解释只有两个：要么你实际每帧耗时超过了33ms，要么你用了垂直同步但屏幕只支持30Hz。

排查第一步，耗时检测。在抠数据那段代码前后加Stopwatch，记录cvtColor耗时、LockBuffer耗时、memcpy耗时、SetBitmapAsync耗时。我实测下来，如果这几项加起来超过25ms，说明瓶颈还是在数据准备阶段，得继续优化前面的OpenCV处理；如果加起来不到5ms，那你已经具备跑满60帧的体质了。

排查第二步，确认是不是合成器在捣乱。WinUI3默认启用独立合成线程，你可以强制让窗口走软件渲染测试一下：

xml复制<Application.Resources>
    <ResourceDictionary>
        <XamlControlsResources />
    </ResourceDictionary>
</Application.Resources>

或者直接用注册表加DisableHWAcceleration启动应用，如果帧率反而提升了，说明是显卡驱动或者合成器兼容性问题。不过这种方案是终极临时的，根治还是要检查显卡驱动和WinUI版本更新。

4.5 SetBitmapAsync调用偶发崩溃，报“Catastrophic failure”

这个错误看着吓人，其实大部分情况就两种原因：一是SoftwareBitmap已经被Dispose了，但你还拿它去SetBitmapAsync；二是跨线程调用了没有正确同步。常见于你在后台线程里创建了SoftwareBitmap，然后在UI线程绑定。

解决方式是给转换器类加一个标志位，标记Source是否已被Dispose，在UpdateAsync里先检查。同时确保所有SoftwareBitmap.Dispose()操作都走UI线程的DispatcherQueue，避免异步过程中对象被释放。

我自己的代码里专门封装了一个SafeSetBitmapAsync：

csharp复制private bool _disposed;
private SemaphoreSlim _updateLock = new SemaphoreSlim(1, 1);

public async Task SafeSetBitmapAsync(SoftwareBitmap bitmap)
{
    if (_disposed) return;
    
    await _updateLock.WaitAsync();
    try
    {
        if (_disposed) return;
        await _source.SetBitmapAsync(bitmap);
    }
    finally
    {
        _updateLock.Release();
    }
}

这个方法能挡住大多数并发释放和重复设置造成的偶发崩溃，实测跑一个多小时不会出一次异常。

5. 再往深处走一步：忍不住想提的升级路线

如果你做到上面这些还觉得不够过瘾，想追求更极限的性能，方向就是绕开CPU拷贝，走GPU直传。WinUI3里可以用Win2D的CanvasBitmap，或者直接拿Direct3D 11纹理和OpenCV的UMat、cuda::GpuMat互操作，让图像数据从采集到显示全程不落CPU内存。

这个方案的原理是OpenCV有cv::cuda::GpuMat，你可以把GpuMat数据指针转成D3D11纹理，然后用Win2D把纹理直接画到CanvasControl上。图像数据从GPU显存到GPU显存，中间没有PCIe回读，那性能又能上一个台阶。

不过这个方案工程复杂度会高很多。D3D11纹理格式和OpenCV的通道顺序需要精确匹配，分辨率和内存对齐也要考虑，排错难度成倍上升。适合做产品化落地、帧率要求极高（如高速相机300fps）或者图像尺寸特别大（8K）的兄弟们去折腾。普通应用做到SoftwareBitmap复用方案已经非常够用了。

我自己在实际项目里用到的终极方案，是维护了一个小的SoftwareBitmapSource池，UI线程空闲时就预绑定好，采集线程只往池子里丢数据。这样既避免了SetBitmapAsync偶发的等待帧问题，又让UI线程有喘息余地，整个界面特别跟手。

最后再分享一个细节技巧：SoftwareBitmapSource.SetBitmapAsync内部会复制一份位图数据，这个开销你是能感受到的。如果你追求极致，可以改用CompositionSurfaceBrush配合Visual而不是Image控件显示，同样绑定SoftwareBitmap，渲染路径更短，但需要理解Windows.UI.Composition的坐标和变换体系，学习曲线比较陡。

到底选哪条路，取决于你的工程预算和最终性能指标。如果是给客户做演示Demo，SoftwareBitmap复用方案完全够，两三百行代码搞定；如果是量产设备或者专业软件，值得多花一周时间上GPU直传。先把这篇文章的基础方案吃透，性能问题基本就解决了一大半，剩下的都是锦上添花的事。