c# - Android - Bitmap.CreateBitmap - 空指针异常

Question

有时，当我尝试创建模糊位图时，我会收到“空指针异常”。

发生在这段代码中(我最近开始捕捉异常，所以至少它不会使应用程序崩溃):

try
{
    using (Bitmap.Config config = Bitmap.Config.Rgb565) {
        return Bitmap.CreateBitmap (blurredBitmap, width, height, config);
    }
}
catch (Java.Lang.Exception exception)
{
    Util.Log(exception.ToString());
}

有关我传递给“CreateBitmap”方法的参数的更多详细信息，请参阅这些图片:

扩展参数如下:

完全异常:

exception {Java.Lang.NullPointerException: Exception of type 'Java.Lang.NullPointerException' was thrown. at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000b] in /Users/builder/data/lanes/2058/58099c53/source/mono/mcs/class/corlib/System.Runtime.ExceptionServices/ExceptionDispatchInfo.cs:61 at Android.Runtime.JNIEnv.CallStaticObjectMethod (IntPtr jclass, IntPtr jmethod, Android.Runtime.JValue* parms) [0x00064] in /Users/builder/data/lanes/2058/58099c53/source/monodroid/src/Mono.Android/src/Runtime/JNIEnv.g.cs:1301 at Android.Graphics.Bitmap.CreateBitmap (System.Int32[] colors, Int32 width, Int32 height, Android.Graphics.Config config) [0x00088] in /Users/builder/data/lanes/2058/58099c53/source/monodroid/src/Mono.Android/platforms/android-22/src/generated/Android.Graphics.Bitmap.cs:735 at Psonar.Apps.Droid.PayPerPlay.StackBlur.GetBlurredBitmap (Android.Graphics.Bitmap original, Int32 radius) [0x00375] in d:\Dev\psonar\Source\Psonar.Apps\Psonar.Apps.Droid\Psonar.Apps.Droid.PayPerPlay\Utilities\StackBlur.cs:123 --- End of managed exception stack trace --- java.lang.NullPointerException at android.graphics.Bitmap.createBitmap(Bitmap.java:687) at android.graphics.Bitmap.createBitmap(Bitmap.java:707) at dalvik.system.NativeStart.run(Native Method) } Java.Lang.NullPointerException

不确定这是否是 Xamarin 中的错误或传递的参数错误。

Answer 1

我从 Xamarin 团队的一位成员 Jonathan Pryor 那里得到了回复:

The NullPointerException is coming from Java code:

at android.graphics.Bitmap.createBitmap(Bitmap.java:687) at android.graphics.Bitmap.createBitmap(Bitmap.java:707) at dalvik.system.NativeStart.run(Native Method)

快速查看各种版本，Jelly Bean 可能适合:

https://github.com/android/platform_frameworks_base/blob/jb-release/graphics/java/android/graphics/Bitmap.java#L687

    return nativeCreate(colors, offset, stride, width, height,
                        config.nativeInt, false);

快速浏览一下周围的方法体就会发现 config 不检查是否为空，所以如果 null 被传递，这将导致 在 NullPointerException 中。

但是，问题在于您没有传递 null:

using (Bitmap.Config config = Bitmap.Config.Rgb565) {
    return Bitmap.CreateBitmap (blurredBitmap, width, height, config);
}

...或者你是？

我建议您删除 using block :

return Bitmap.CreateBitmap (blurredBitmap, width, height,
        Bitmap.Config.Rgb565);

这是我认为可能会发生的事情，但首先，题外话:

在 Xamarin.Android 的核心深处有一个 Java 之间的映射 对象及其相应的 C# 包装器对象。构造函数 调用、Java.Lang.Object.GetObject() 等将创建 映射； Java.lang.Object.Dispose() 将删除映射。

其中的核心部分是对象标识:当一个 Java 实例是 暴露给 C# 代码并创建 C# 包装器，相同 C# 包装器 实例应该继续被该 Java 实例重用。

一个隐含的结果是任何实例是有效的 全局，因为如果有多个代码路径/线程/等。获得同一 Java 实例的 JNI 句柄，他们将获得相同的 C# 包装器。

这让我们回到我的假设和您的代码块: Bitmap.Config 是一个 Java 枚举，意味着每个成员都是一个 Java 对象。 此外，它们是全局值，因此每个线程都可以访问 这些成员，意味着 C# Bitmap.Config.Rgb565 实例是 实际上是一个全局变量。

您正在 Dispose()ing 的全局变量。

这“很好”，因为 下 时间 Bitmap.Config.Rgb565 是 访问，将创建一个新的包装器。

问题是，如果你有多个线程访问 Bitmap.Config.Rgb565 ~同时，每个都在尝试 实例的 Dispose()。在这一点上完全有可能 这两个线程可以引用相同的包装器实例，并且 因此，一个线程中的 Dispose() 将使使用的实例无效 另一个线程。

这将导致 null 被传递给 Bitmap.createBitmap() 调用，这正是您所观察到的。

请尝试删除 using block ，看看是否有帮助。

The whole thread is accessible here.

然后我问:

Jonathan Pryor - cheers for the suggestion. My question is that if I remove the using statement, will it introduce a memory leak? Meaning if I stop disposing the new config instance?

他回答:

That's what GC's are for!

(insert coughing and laughter here.)

We can quibble quite a bit. I'll argue that it is NOT a memory leak, because the memory is well rooted and well known; constantly accessing the Bitmap.Config.Rgb565 will return the previously created instance, not constantly create new instances. There is no "leak," as such.

I'll instead argue that the instance, and the underlying GREF, is a "tax"; it's "burnt", part of the cost of doing business. While it would be "nice" to minimize these costs, it isn't practical to remove all of them (e.g. we "lose" a GREF per class via .class_ref, which is used to lookup method IDs...), at least not with the current architecture.

(I also can't think of an alternate architecture that would result in different costs/"taxes". While I do have some thoughts on allowing things to be improved for some areas, they're not huge.)

I would suggest not worrying about Bitmap.Config.Rgb565 and similar members too much, unless/until the profiler or GREF counts show otherwise.