c# - 在 C# 中使不安全代码变得安全

Question

我最近正在阅读一篇关于image processing in C#的文章

其中有一些我不太喜欢的代码，因为它不安全，我想知道是否可以使其安全:

public static bool Invert(Bitmap b)
{
    // GDI+ still lies to us - the return format is BGR, NOT RGB. 
    BitmapData bmData = b.LockBits(new Rectangle(0, 0, b.Width, b.Height), 
        ImageLockMode.ReadWrite, PixelFormat.Format24bppRgb); 
    int stride = bmData.Stride; 
    System.IntPtr Scan0 = bmData.Scan0; 
    unsafe 
    { 
        byte * p = (byte *)(void *)Scan0;
        int nOffset = stride - b.Width*3; 
        int nWidth = b.Width * 3;
        for(int y=0;y < b.Height;++y)
        {
            for(int x=0; x < nWidth; ++x )
            {
                p[0] = (byte)(255-p[0]);
                ++p;
            }
            p += nOffset;
        }
    }

    b.UnlockBits(bmData);

    return true;
}

行 byte* p = (byte*)(void*)Scan0; 看起来像是罪魁祸首，但我不得不说我真的不明白它在做什么，或者它是如何做到的确保安全。

有人可以解释一下吗？

Answer 1

使用不安全代码主要是出于性能原因。基本思想是逐字节地处理图像数据，并手动翻转每个字节(尽管有更有效、更简单的方法来处理相同的事情)。

底层图像由 GDI+ 处理，这是非托管代码。因此，当您直接使用图像字节时，您必须操作非托管内存。这实际上是多么安全或不安全，很难确定——这在很大程度上取决于非托管内存最初是如何分配的。考虑到您正在使用托管代码，并且您可能从文件或某个流加载位图，实际上很可能它并不是真正不安全 - 例如，您无法意外覆盖托管内存。 unsafe关键字的名称并不是因为本质上是危险的 - 它来自允许您做非常不安全的事情。例如，如果您在自己的托管堆栈上为位图分配了内存，则可能会将事情搞砸。

总的来说，如果您能够真正证明值得付出代价，那么只使用不安全的代码是一个很好的做法。在图像处理中，这通常是一个很好的权衡 - 您正在处理大量简单数据，例如开销边界检查可能很重要，尽管很容易只验证一次，而不是在循环的每次迭代中验证它们。

如果你想摆脱这个不安全的代码，一种方法是分配你自己的 byte[] (托管)，使用Marshal.Copy将图像数据复制到此byte[] ，在托管数组中进行修改，然后使用 Marshal.Copy 将结果复制回来再次。问题是，这意味着分配 byte[]与原始图像一样大，然后将其复制两次(在这种情况下，边界检查可以忽略不计 - .NET JIT 编译器会将其优化掉)。最后，在使用 Marshal.Copy 时仍然可能犯错误。这会给你带来与 unsafe 相同的问题(不完全是这样，但这将是一个更长的谈话)。

对我来说，迄今为止最有值(value)的部分是 unsafe作为关键字，它允许您本地化您正在做的不安全的事情。虽然典型的非托管应用程序是彻头彻尾不安全的，但 C# 只允许您在代码中专门标记的部分中不安全。虽然这些仍然会影响代码的其余部分(这是您只能在 FullTrust 环境中使用 unsafe 的原因之一)，但它使它们更容易调试和控制。一如既往，这是一种权衡。

但是，该代码实际上以一种非常不同的方式不安全 - UnlockBits如果代码中间出现异常，调用可能永远不会发生。你真的应该使用 finally确保正确清理非托管资源的子句。

最后一点，如果您想要“真正”的性能，无论安全还是不安全，您可能都不会在 CPU 上进行图像处理。如今，通常可以安全地假设您正在运行的计算机具有 GPU，可以更快、更轻松地完成工作，并且与计算机本身实际运行的代码完全隔离。