深入探索 Android Native 开发中的 NewString 和 NewStringUtf 解析

2023-12-03 21:47:28

Android Native 开发中，经常需要在 C++ 代码和 Java Native Interface (JNI) 层之间交换字符串。为此，Android 提供了 NewString 和 NewStringUtf 函数来实现这种转换。然而，对于这些函数的底层原理和最佳实践，许多开发人员却知之甚少。本文将通过一个真实的 Native 崩溃分析，带领大家深入了解 NewString 和 NewStringUtf，帮助大家避免潜在的崩溃和性能问题。

NewString 和 NewStringUtf 的差异

NewString 和 NewStringUtf 都是用来将 C++ 字符串转换为 JNI 字符串对象的函数。但是，它们之间存在一个关键差异：

NewString： 将 C++ 字符串以 UTF-16 编码转换为 JNI 字符串对象。
NewStringUtf： 将 C++ 字符串以 UTF-8 编码转换为 JNI 字符串对象。

在 Android 中，Java 字符串是使用 UTF-16 编码存储的，而 C++ 字符串通常使用 UTF-8 编码。因此，在将 C++ 字符串传递给 JNI 层之前，需要进行适当的编码转换。如果使用错误的编码方式，就会导致数据损坏和潜在的崩溃。

Native 崩溃分析

最近，我们在一个 Android 应用程序中遇到了一个 Native 崩溃。崩溃发生在以下代码行：

jstring jcs = env->NewString(c_str);

其中，c_str 是一个 C++ 字符串，env 是 JNIEnv 指针。

崩溃堆栈跟踪显示：

Fatal signal 6 (SIGABRT), code -6 (SI_TKILL)
...
00  pc 00000000001e225c  /system/lib64/libart.so (android::JDWP::JdwpRequestHandler::JniMethodStart+112)
01  pc 000000000005a5b4  /system/framework/arm64/boot.oat (offset 0x595b4) (Java_com_example_myapplication_MainActivity_onNativeCrash+76)
02  pc 0000000000060b4c  /system/framework/arm64/boot.oat (offset 0x60b4c) (Java_com_example_myapplication_MainActivity_MainActivity+56)
03  pc 0000000000061444  /system/framework/arm64/boot.oat (offset 0x61444) (Java_com_example_myapplication_MainActivity_onCreate+72)
...

崩溃原因分析

分析崩溃堆栈跟踪，我们发现崩溃发生在 NewString 函数调用处。进一步调查发现，c_str 是一个包含非 ASCII 字符的 UTF-8 编码字符串。由于 NewString 函数将 C++ 字符串以 UTF-16 编码转换为 JNI 字符串对象，因此它无法正确处理非 ASCII 字符，从而导致了崩溃。

解决方案

为了解决此问题，我们需要使用正确的编码转换方式。在我们的例子中，我们应该使用 NewStringUtf 函数，它将 c_str 以 UTF-8 编码转换为 JNI 字符串对象。

jstring jcs = env->NewStringUtf(c_str);

最佳实践

为了避免类似的崩溃和其他性能问题，在使用 NewString 和 NewStringUtf 函数时应遵循以下最佳实践：

始终根据数据编码选择正确的函数： 对于 UTF-8 编码的 C++ 字符串，请使用 NewStringUtf。对于 UTF-16 编码的字符串，请使用 NewString。
在 JNI 层释放 JNI 字符串对象： 在将 JNI 字符串对象传递回 C++ 代码之前，请使用 env->ReleaseString 释放它。这将防止内存泄漏。
避免在 C++ 代码中修改 JNI 字符串对象： JNI 字符串对象是不可变的。在 C++ 代码中修改它们会产生未定义的行为。
了解 JNI 字符串对象的内部表示： JNI 字符串对象由一个 UTF-16 字符数组和一个长度字段组成。在直接操作 JNI 字符串对象时，需要了解这一点。