jnienv 必须每次调用时重新获取，因其是线程局部的；javavm 可全局缓存，但 jnienv* 跨线程复用会导致崩溃；正确做法是通过 getenv 或 attachcurrentthread 获取，并在 native 线程结束时 detach。
为什么 JNIEnv* 必须在每个 JNI 函数调用中重新获取，不能跨线程缓存？
Android 的 JNI 环境（JNIEnv*）是线程局部的，不是全局可复用的指针。很多开发者误以为在 Java_com_example_NativeLib_init 中保存一次 JNIEnv*，后续就能直接用——这会导致崩溃或随机内存错误，尤其在回调、异步线程或 onDraw 频繁调用场景下。
正确做法是：每次进入 JNI 函数时，通过 JavaVM->GetEnv() 或 AttachCurrentThread() 获取当前线程有效的 JNIEnv*。如果线程未附加（如 native 线程刚创建），必须先 AttachCurrentThread；用完后，若该线程由 native 创建，建议显式 DetachCurrentThread（避免线程资源泄漏）。
-
JavaVM*可安全全局缓存（在JNI_OnLoad中获取并存为静态变量） - 不要在 C++ 成员变量或 static 指针中长期持有
JNIEnv* - Android 12+ 对未 detach 的线程更敏感，可能触发 ANR 或
java.lang.OutOfMemoryError: pthread_create failed
如何避免频繁 FindClass 和 GetMethodID 导致的性能瓶颈？
FindClass 是 JNI 中开销最大的操作之一，它要遍历类路径、解析字节码、触发类加载——在循环或高频回调（如音频处理、传感器采样）中反复调用，会显著拖慢吞吐量，甚至引发 GC 压力。
解决方案是「缓存 class 引用和方法 ID」，但必须注意生命周期管理：
立即学习“Java免费学习笔记（深入）”；
- 使用
GetObjectClass或FindClass+NewGlobalRef缓存jclass（否则类卸载后引用失效） -
GetMethodID/GetFieldID结果是纯数值，可直接缓存为 static const，无需 global ref - 缓存时机放在
JNI_OnLoad或首次调用时（加锁保护），而非每次函数入口 - 避免缓存
java.lang.String等系统类——它们不会被卸载，FindClass结果可直接复用，但加NewGlobalRef更稳妥
static jclass g_StringClass = nullptr;
static jmethodID g_StringInit = nullptr;
<p>JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM<em> vm, void</em> reserved) {
JNIEnv* env;
if (vm->GetEnv(reinterpret_cast<void**>(&env), JNI_VERSION_1_6) != JNI_OK) {
return JNI_ERR;
}
jclass localClass = env->FindClass("java/lang/String");
if (localClass == nullptr) return JNI_ERR;
g_StringClass = reinterpret_cast<jclass>(env->NewGlobalRef(localClass));
g_StringInit = env->GetMethodID(g_StringClass, "<init>", "([BLjava/nio/charset/Charset;)V");
env->DeleteLocalRef(localClass);
return JNI_VERSION_1_6;
}</p>如何用 GetDirectBufferAddress 替代 GetByteArrayElements 避免内存拷贝？
当 Java 层传入 ByteBuffer.allocateDirect() 时，底层是 native 内存；而 GetByteArrayElements 总是触发 JVM 内部拷贝（即使传的是 direct buffer），在图像处理、音视频编解码等大数据量场景下，每帧多一次 memcpy 就是几十 MB/s 的浪费。
关键判断逻辑：只对 direct buffer 使用 GetDirectBufferAddress，且必须配合 GetDirectBufferCapacity 校验长度。普通 heap byte array 仍需走 GetByteArrayRegion 或 GetByteArrayElements（后者需记得 ReleaseByteArrayElements）。
- 用
IsDirect判断是否为 direct buffer -
GetDirectBufferAddress返回void*，不增加引用计数，无需释放 - 切勿对非 direct buffer 调用该函数——返回
nullptr，解引用即 crash - Android 8.0+ 上，direct buffer 的地址可安全用于 DMA 或 GPU 映射（如 Vulkan
VK_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_BIT_ANDROID）
JNIEXPORT void JNICALL Java_com_example_NativeLib_processDirectBuffer(JNIEnv* env, jobject thiz, jobject buffer) {
if (!env->IsDirect(buffer)) {
jclass ex = env->FindClass("java/lang/IllegalArgumentException");
env->ThrowNew(ex, "buffer must be a direct ByteBuffer");
return;
}
void* addr = env->GetDirectBufferAddress(buffer);
jlong capacity = env->GetDirectBufferCapacity(buffer);
if (addr == nullptr || capacity <= 0) return;
// 直接操作 addr，无拷贝
process_image_data(static_cast<uint8_t*>(addr), static_cast<size_t>(capacity));
}
NDK 中启用 -O3 -flto -march=armv8-a+simd 后为何部分设备闪退？
高级优化标志能提升浮点密集型计算（如 FFT、卷积）30%+ 性能，但会破坏 ABI 兼容性：例如 -march=armv8-a+simd 生成的指令在不支持 NEON 的旧设备（如部分 ARM Cortex-A7）上非法，直接 SIGILL；-flto 可能导致符号重排，与 Java 层 native 方法名映射失败（UnsatisfiedLinkError）。
安全做法是分档构建 + 运行时检测：
- ABI 分离：为
arm64-v8a启用 SIMD，armeabi-v7a仅用-O2+-mfpu=neon - 运行时 CPU 特性检测：用
android_getCpuFeatures()（需android/ndk-version.h）判断是否支持ANDROID_CPU_ARM_FEATURE_NEON，再 dispatch 到不同实现 -
-flto必须配套full LTO链接（CMake 中设set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON)），否则函数内联不生效，还可能因弱符号问题导致崩溃 - 禁用
-fstack-protector-strong在某些低端芯片上引发栈对齐异常（尤其 inline asm 场景）
最易忽略的一点：所有 JNI 函数签名必须声明为 extern "C"，否则 -flto 可能因 C++ name mangling 导致 Java 找不到 native 方法。
