native方法通过jni命名规则（java_包名_类名_方法名）绑定c函数，需用jni类型、预加载so库、正确处理jnienv*线程安全及string编码转换。
Native方法怎么绑定到C函数
Java里声明一个native方法，只是告诉JVM“这个方法的实现不在Java里”，但JVM完全不知道它该去哪找、怎么调用。真正建立连接靠的是JNI（Java Native Interface）的命名规则和动态链接过程。
常见错误现象：UnsatisfiedLinkError: No implementation found for ...——不是C代码没写，而是函数名没对上，或者so/dll没加载。
- JNI要求C函数名严格遵循
Java_<em>包名_类名_方法名</em>格式，包名中.要替换成_，且所有非字母数字字符需转义（比如$变成_00024） - 必须用
jstring、jint等JNI类型作参数和返回值，不能直接用char*或int - 加载so库必须在调用任何
native方法前完成，通常写在static块里：System.loadLibrary("mylib")（注意不含lib前缀和.so后缀） - Android上路径和ABI匹配很关键：
arm64-v8a目录下的libmylib.so不会被armeabi-v7a设备加载
JNIEnv指针到底有什么用
JNIEnv*是每个本地函数第一个隐式参数，它不是全局句柄，而是线程私有的JNI接口表指针。几乎所有JNI操作（创建对象、调用方法、访问字段）都依赖它。
容易踩的坑：JNIEnv*不能跨线程缓存或传递——在子线程里直接用主线程传来的JNIEnv*会崩溃，因为JVM为每个线程维护独立的JNI环境。
立即学习“Java免费学习笔记（深入）”；
- 在新线程里必须先调用
AttachCurrentThread()获取当前线程有效的JNIEnv*，用完再DetachCurrentThread() -
JNIEnv*只在当前本地方法执行期间有效；回调Java方法时传入的JNIEnv*也仅限该回调栈帧内安全 - 不要试图把
JNIEnv*保存成全局变量，也不要用static修饰它
为什么String传到C里经常乱码或崩溃
Java的String是UTF-16编码的不可变对象，而C习惯处理char*（通常是UTF-8或系统本地编码）。JNI不自动做编码转换，直接用GetStringUTFChars()看似简单，实则埋雷。
典型错误：GetStringUTFChars()返回的是修改过的UTF-8（非标准，不支持BMP外字符），且必须配对调用ReleaseStringUTFChars()，否则内存泄漏；更糟的是，如果C代码把它当普通UTF-8用，遇到代理对就会解码错乱。
- 推荐方案：用
GetStringCritical()+ReleaseStringCritical()获取原始UTF-16指针（零拷贝，但会暂停GC，必须快进快出） - 若需UTF-8，用
GetStringUTFRegion()把指定范围转成目标缓冲区，自己管理内存 - 永远检查返回值是否为
NULL——JNI调用失败时很多函数返回NULL而非抛异常
Android上so加载失败的排查顺序
Android比桌面JVM更敏感：ABI、NDK版本、minSdkVersion、压缩方式都会导致loadLibrary静默失败或报UnsatisfiedLinkError。
最常被忽略的一点：APK里的so如果被zip压缩（默认行为），某些旧版本Android会拒绝加载——必须在build.gradle里显式禁用：android { packagingOptions { doNotStrip "**/*.so" } }，并确认packagingOptions { pickFirst "**/*.so" }没误删多ABI版本。
- 先用
adb shell ls /data/data/<pkg>/lib/</pkg>确认so是否真的被解压到了设备上 - 用
file libxxx.so检查文件架构是否匹配设备CPU（ARM aarch64vsARM aarch32） - 用
readelf -d libxxx.so | grep NEEDED看是否依赖了不存在的系统库（如libc++_shared.so未打包） - NDK r21+默认使用
libc++，老项目若混用libstdc++会链接失败
底层链接不是“写了native就自动通”，而是每一步都有契约约束：命名、线程、内存、ABI、编码——漏掉任意一环，JVM就只能给你一个冷冰冰的UnsatisfiedLinkError。
