Android应用JNI_OnUnload回调始终未触发的问题求解

1. 两种卸载回调命名的合法性说明 #

• 无后缀的JNI_OnUnload是JNI官方标准定义的回调，所有兼容JNI规范的平台（包括Android）均合法有效，完全符合规范要求。
• 带库名后缀的JNI_OnUnload_<库名>是Android平台的私有扩展机制，仅在Android环境下生效，命名要求后缀和System.loadLibrary传入的库名完全匹配（大小写敏感），你使用的JNI_OnUnload_lifecycleevents语法上是合法的。

2. JNI_OnUnload始终无法触发的核心原因 #

你对回调触发时机的理解存在偏差，官方文档描述的「类加载器被垃圾回收时触发JNI_OnUnload」的场景，在普通Android应用的默认进程模型下基本不可能出现：

• Android普通应用默认使用的PathClassLoader生命周期和应用进程完全绑定，只要进程存活，该类加载器就会被系统持有强引用，永远不会被GC回收。
• Activity的onDestroy仅代表Activity组件的销毁，既不代表类加载器被释放，也不代表应用进程终止；而Android系统销毁应用进程时是直接发送SIGKILL信号终止进程，不会给任何Native层回调执行的机会，因此你永远无法捕获到JNI_OnUnload的日志。
• 带后缀的JNI_OnUnload_<库名>回调触发前提和标准JNI_OnUnload完全一致，同样需要加载该so的类加载器被GC回收，因此也无法触发。

如果你想要验证JNI_OnUnload的逻辑正确性，可以自定义一个无parent的DexClassLoader加载so，加载完成后将该类加载器的所有引用置空，手动触发System.gc()，此时即可触发JNI_OnUnload回调。

3. 正确的处理方案 #

• 永远不要依赖JNI_OnUnload作为Native资源释放的触发时机，该回调的设计初衷是为插件化、热修复等使用自定义类加载器的场景设计的，不适合普通应用使用。
• 建议自行封装Native层的资源释放接口，在Activity.onDestroy等你需要释放资源的时机主动调用该接口即可。

内容的提问来源于stack exchange，提问作者NightFuryLxD