Java 转 Native 前 JNI 边界划分：调用粒度、引用生命周期与异常传播审查

为何 JNI 边界划分必须从调用前审查开始

Java 调用 Native 时的边界划分不当，会直接引发调用开销急剧上升，本地引用泄漏导致内存耗尽，以及未被捕获的异常引发不可预测的崩溃。跨语言传递的每个对象都必须经历类型转换和引用生命周期管理，任意疏漏都可能成为故障点并拖垮整个应用，尤其在长时间运行或频繁调用的场景下积累风险。

调用粒度过细会使跨语言调用次数剧增，抵消原生代码带来的性能优势；粒度过粗则会让 Native 方法长期持有 Java 对象引用，阻碍垃圾回收并增加状态同步难度。因此，边界审查必须在编写 JNI 代码前就确定每个 Native 入口所承载的业务操作范围，避免后期返工。

引用生命周期在 JNI 中十分脆弱。局部引用默认最多可创建有限个数，循环内不经删除就易超出上限；全局引用若遗漏删除便成为永久泄漏。接口设计时必须明确谁创建、由谁在什么时机删除每一个引用，否则即使功能看似正确，运行时也会逐步退化直至崩溃。

调用粒度设计：每个 Native 方法封装完整业务操作

过细的调用如每个字段都跨越 JNI 边界，会因频繁的上下文切换和参数序列化消耗大量 CPU 时间。虽然 Java 侧代码可读性好，但实际运行时会在 Native 与 ART 之间反复跳转，使得本应提速的操作得不偿失，甚至在内存受限的设备上触发更严重的性能衰减。

合理粒度应当将相互依赖的数据一次性传入原生层，并在其中完成完整变换后返回结果对象或基本类型。若分步调用，多次跨越边界会增加上下文切换与状态同步成本。业务操作若必须依赖多个 Native 方法才能完成，应重新检查接口拆分，否则中间状态更难管理。计算密集型任务可直接传递像素缓冲区，而不是分别获取宽、高和格式；需要频繁回调 Java 的场景则应优先保持边界简单。接口设计记录还应标明每个数组、字符串和直接缓冲区由哪一侧创建、能持有多久、何时释放，以及异常时是否仍需回写结果。

过粗的调用可能会让原生层长期持有 Java 对象的全局引用，阻碍 GC 因分代移动对象而引发额外拷贝，甚至导致对象生命周期难以判断。当需要长时间作业时，应主动切换到 C++ 侧数据结构，仅在一进一出间使用 Java 引用，从而将跨语言边界压缩到最小。

引用生命周期：局部引用与全局引用的成对管理检查

局部引用在 JNI 函数内部默认最多可创建有限个数，若在循环中调用 FindClass 或 GetObjectArrayElement 而不释放，很容易突破上限。不同 Android 版本的平台行为可能直接崩溃或返回 NULL，但都不安全，必须在不再使用引用的第一时间调用 DeleteLocalRef 释放空间。

全局引用和弱全局引用用于在 Native 层跨函数或跨线程持有 Java 对象，如果不手动删除，这些对象将永远无法回收，造成应用内存持续膨胀。审查 JNI 边界时，每一个 NewGlobalRef 都必须能追溯到对应的 DeleteGlobalRef，并且释放操作必须发生在所有线程使用完毕之后。

检查脚本可以提示未成对的引用创建与删除操作。例如扫描 Native 源码中的 NewLocalRef 与 DeleteLocalRef 数量差异，同一函数内前者较多时列入人工复核清单。它适合作为轻量级 CI 检查，但不能理解引用是否跨函数转移，也不能单凭计数确认泄漏。

异常传播：跨语言边界的异常检查与转换机制

JNI 规范要求大多数函数在发生异常时返回一个错误码，但执行并未中断，这意味着后续的 JNI 调用可能在一个异常已挂起的上下文中运行，结果无定义。因此，每调用一个可能抛出错误的 JNI 方法后，必须立即调用 ExceptionCheck 判断状态。

典型的安全模式是：env->CallVoidMethod(...); if (env->ExceptionCheck()) { env->ExceptionClear(); /* 释放已取得引用 */ return; }。缺少 ExceptionClear 会使得异常继续传播到 Java 调用者，而缺少即时返回则会让后续代码使用无效结果，造成二次异常。

异常分支若跳过引用清理，局部引用会一直留到当前 Native 方法返回，循环中的累积还可能填满局部引用表。审查时把 ExceptionCheck 与清理路径放在一起看：确认挂起异常后，只调用规范允许的清理函数，并保证已创建的引用都有明确释放点。发现异常路径遗漏清理时，应修正控制流并增加对应测试，静态计数不能自动完成这项判断。测试可让 Java 回调连续抛出固定异常，循环执行到足够次数，再核对进程未出现 local reference table overflow，且每轮返回的异常类型与消息一致。

• 在调用可能抛出异常的函数后立即使用 ExceptionCheck 判断挂起状态。
• 检测到异常后如需清理引用或资源，应优先调用 ExceptionClear 再释放。
• 在 JNI 函数返回前确保没有未清除的异常挂起，避免影响后续 Java 调用。
• 将 Native 异常转化为 Java 异常时，检查构造新异常对象的引用，防止本地引用泄漏。

平台 API 可用性：minSdk 与动态链接的版本边界审查

当 Native 代码需要使用高于 minSdk 的 Android API 时，不能假设该函数在编译链接期已经存在。直接调用会导致在旧设备上因符号未定义而无法加载 SO，因此必须通过 dlopen 和 dlsym 获取函数指针，并在调用前检查指针有效性。

采用动态链接也不能保证库路径在所有 Android 链接器命名空间中可达，系统私有库尤其可能被隔离。动态加载代码必须检查 dlopen 与 dlsym 返回值，并为符号解析失败准备公开 API 回退路径；没有可用回退时，应明确结束该功能而不是继续调用空指针。目标设备若不允许访问该库，这种方式就不适用。每条动态符号路径都应在最低支持版本、主流版本和最新目标版本上验证，并保存 dlerror 原文；不要把某台设备上成功解析的私有符号写成平台保证。

版本检查代码本身也会引入新的异常路径，若 dlopen 返回 NULL 且未判断就直接调用 dlsym，会发生空指针解引用。这一部分同样需要纳入 JNI 边界的成对检查逻辑，确保每个 dlopen 都有对应的 dlclose 或在失效时安全退出。

符号可见性收敛：减少 Native 导出面以加固边界

通过编译器标志 -fvisibility=hidden 并结合版本脚本，可以将所有非 JNI 入口的内部函数隐藏，只暴露 JNI_OnLoad 和需要进行动态注册的函数。这不仅减少了符号表大小，也让逆向分析者难以直接通过符号名称锁定关键算法。

符号收敛不能等同于虚拟化或代码混淆的强度，它的主要作用是降低攻击面。例如内部加解密函数若未被导出，攻击者就必须通过分析调用链才能定位，增加了工具自动化分析的阻力。但公开的 JNI 入口仍然是必须保留的，因此边界审查需检查是否遗漏了必要的导出。

静态注册的 JNI 函数默认会导出，如果项目采用静态注册且不想暴露全部函数名，可改为动态注册，在 JNI_OnLoad 中通过 RegisterNatives 完成绑定，并隐藏除 OnLoad 外的所有符号。这种转变需要同步调整 Java 侧的加载逻辑，但能在不破坏功能的情况下有效收敛可见性。

静态诊断脚本：扫描 JNI 调用与引用管理成对完整

该脚本读取一个包含 JNI 调用序列的文本文件，通过正则匹配识别 NewLocalRef 与 DeleteLocalRef，以及 ExceptionCheck 与 ExceptionClear。它并不试图分析真实 C/C++ 语法树，而是基于行级模式匹配快速判断是否存在成对缺失。

扫描完成后，脚本对比两种调用的出现次数，若 NewLocalRef 比 DeleteLocalRef 多，则说明部分本地引用未被主动释放；若 ExceptionCheck 的次数大于 ExceptionClear，则可能存在未被清除的异常挂起。非零返回值可直接集成到 CI 流程中阻断构建。

此脚本的局限在于无法感知不同作用域内的引用转移，也不跟踪全局引用的跨函数生命周期。若引用在函数间隐式传递或延迟释放，脚本将因缺乏上下文而漏报。检查步骤需先运行扫描获取候选列表，再人工回溯调用链确认作用域边界与释放时机。失败条件包括：存在未配对的局部引用跨越函数边界，或全局引用未在模块卸载时清理。适用限制为仅支持静态代码分析，无法处理动态生成的 JNI 调用或反射场景。因此它适合作为第一道快速筛查，发现候选问题后仍需人工确认作用域和释放时机，防止误报干扰开发流程。

import sys
import re

def check_pairs(filename):
    try:
        with open(filename, 'r') as f:
            lines = f.readlines()
    except OSError:
        print('Cannot open file: ' + filename)
        return 1
    new_local = 0
    delete_local = 0
    exception_check = 0
    exception_clear = 0
    errors = []
    for i, line in enumerate(lines):
        line = line.strip()
        if re.search(r'\bNewLocalRef\b', line):
            new_local += 1
        elif re.search(r'\bDeleteLocalRef\b', line):
            delete_local += 1
        elif re.search(r'\bExceptionCheck\b', line):
            exception_check += 1
        elif re.search(r'\bExceptionClear\b', line):
            exception_clear += 1
    if new_local != delete_local:
        print(f'Unmatched NewLocalRef vs DeleteLocalRef: {new_local} vs {delete_local}')
        return 1
    if exception_check > exception_clear:
        print(f'Unmatched ExceptionCheck vs ExceptionClear: {exception_check} vs {exception_clear}')
        return 1
    return 0

if __name__ == '__main__':
    if len(sys.argv) != 2:
        print('Usage: python check_pairs.py <jni_calls.txt>')
        sys.exit(1)
    sys.exit(check_pairs(sys.argv[1]))

测试与验证：通过 instrumented test 验证 JNI 边界

在真实 Android 设备上运行 instrumented test，可以覆盖异常路径、引用压力和平台 API 缺失时的回退逻辑。这类测试依赖完整的 Android 框架与系统服务，能够发现静态扫描看不到的线程附着、类加载和链接器差异。用例应分别从主线程、线程池与由 Native 创建的线程调用边界方法，确认 JNIEnv 不跨线程缓存，AttachCurrentThread 与 DetachCurrentThread 在所有退出路径上成对出现。

JNI 边界验证绝不能仅依赖单台设备或单一 ABI，因为不同架构在字节对齐、调用约定及链接器行为上存在本质差异，加之厂商对系统库的私有修改，极易引发隐蔽崩溃。若跳过跨平台矩阵测试，将无法暴露特定环境下的内存越界或符号解析失败等致命缺陷。只有覆盖多设备组合的 instrumented test 才能确认边界划分的鲁棒性；任何单一设备通过的结论均不可推广至全量目标环境，否则将导致发布后大规模兼容性事故。

把静态扫描提示的引用或异常处理问题转成针对性设备用例。每个用例记录函数名、输入、API、ABI、异常状态和引用清理结果；两份候选产物在同一设备上执行，任何差异都回到对应 JNI 边界修正后复测。验收记录还要包含 logcat、Native 崩溃 tombstone 或 sanitizer 输出，并绑定未保护与保护产物的摘要，避免拿不同构建的结果相互比较。