引言：为何需要分析.so文件？

在Android开发或Linux系统编程中，动态链接库（.so文件）承载着核心的本地代码实现。

尤其是使用JNI（Ja va Native Interface）技术时，我们经常需要确认：库中到底导出了哪些可供Ja va/Kotlin调用的本地方法？方法签名是否准确无误？有没有出现符号冲突或者缺失的情况？

本文从实战角度出发，梳理几种查看.so文件内方法的工具和技巧，帮助你在排查UnsatisfiedLinkError、验证跨语言调用时快速找到方向。

一、三大核心工具对比

objdump — 全能分析器

# 查看动态符号表（推荐）
objdump -T libnative.so

# 反汇编查看代码逻辑
objdump -d libnative.so

# 组合使用：快速定位JNI方法
objdump -T libnative.so | grep "Ja va_"

• 功能最全面，符号表、反汇编、段信息一应俱全。
• 系统自带，通常无需额外安装。
• 输出信息很详细，但有时会显得冗长。

nm — 简洁符号查看器

# 查看动态符号
nm -D libnative.so

# 显示所有符号（包括未导出）
nm libnative.so

# 按类型过滤（T=代码段，U=未定义）
nm -D libnative.so | grep " T "

• 输出简洁直观。
• 可以快速过滤符号类型。
• 适合写脚本做批量处理。

readelf — ELF专业分析器

# 详细符号表信息
readelf -Ws libnative.so

# 查看动态段信息
readelf -d libnative.so

• 专门解析ELF格式，信息更权威。
• 可以展示符号的绑定类型、可见性等细节。
• 适合做深度分析。

二、实战：定位JNI方法的四种姿势

场景：分析 libnative-lib.so 中的JNI方法。

方法1：直接过滤法（最常用）

# 使用任何工具配合grep过滤"Ja va_"前缀
objdump -T libnative-lib.so | grep "Ja va_"
# 输出示例：
# 000000000001234 g    DF .text  00068  Base  Ja va_com_example_app_MainActivity_stringFromJNI

方法2：格式化输出法

# 按列格式化输出，便于阅读
readelf -Ws libnative-lib.so | awk '/Ja va_/ {printf "%-40s %-20sn", $8, $4}'

方法3：完整分析脚本

#!/bin/bash
# analyze_jni.sh
LIB=$1

echo "=== JNI Methods in $LIB ==="
echo "Tool      | Count | Sample Method"
echo "----------|-------|--------------"

# 使用objdump
COUNT1=$(objdump -T "$LIB" | grep -c "Ja va_")
SAMPLE1=$(objdump -T "$LIB" | grep "Ja va_" | head -1 | awk '{print $NF}')
echo "objdump   | $COUNT1 | $SAMPLE1"

# 使用nm
COUNT2=$(nm -D "$LIB" | grep -c "Ja va_")
SAMPLE2=$(nm -D "$LIB" | grep "Ja va_" | head -1 | awk '{print $3}')
echo "nm        | $COUNT2 | $SAMPLE2"

# 使用readelf
COUNT3=$(readelf -Ws "$LIB" | grep -c "Ja va_")
SAMPLE3=$(readelf -Ws "$LIB" | grep "Ja va_" | head -1 | awk '{print $8}')
echo "readelf   | $COUNT3 | $SAMPLE3"

方法4：Android NDK工具链版

# 使用NDK提供的交叉编译版本（Android专属）
$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-objdump -T libnative-lib.so

三、进阶：处理特殊场景

符号被剥离的情况

如果.so发布时被strip处理过，动态符号表可能已被清空。

这时可以尝试反汇编，搜索JNIEnv指针的使用模式，比如x0寄存器传递。

objdump -d stripped_lib.so | less

C++符号修饰问题

C++编译器会对符号进行修饰（mangling），直接查看时通常会看到一堆难以辨认的名字。

可以使用c++filt还原为可读名称：

nm libnative.so | c++filt | grep "Ja va_"

批量分析多个库

如果需要一次性检查当前目录所有.so文件的JNI方法，可以直接使用下面这行脚本：

for lib in *.so; do
    echo "=== $lib ==="
    nm -D "$lib" | grep "Ja va_" | wc -l
done

四、技巧与避坑指南

技巧1：理解JNI命名规则

Ja va_包名_类名_方法名
↓
Ja va_com_example_app_MainActivity_onCreate
  │    │         │          │
 固定  包名      类名       方法名
（点替换为下划线）

技巧2：查看方法签名

如果库包含调试信息，可以通过重定位表查看详细签名：

objdump -R libnative.so | grep Ja va_

技巧3：验证方法是否存在

在Ja va/Kotlin端加载库后，可以主动捕获UnsatisfiedLinkError，确认方法是否被正确导出：

static {
    try {
        System.loadLibrary("native-lib");
        Log.d("JNI", "Library loaded successfully");
    } catch (UnsatisfiedLinkError e) {
        Log.e("JNI", "Method not found: " + e.getMessage());
    }
}

五、工具选择决策树

需要分析.so文件？
    ├── 只需快速查看JNI方法 → `nm -D lib.so | grep "Ja va_"`
    ├── 需要详细反汇编信息 → `objdump -d lib.so`
    ├── 分析ELF结构细节 → `readelf -Ws lib.so`
    └── 处理Android库 → 使用NDK交叉编译版objdump

总结

掌握.so文件的分析方法，能直接帮助开发者解决实际问题。

• 快速定位JNI方法，搞定UnsatisfiedLinkError。
• 验证符号导出，确保跨语言调用畅通无阻。
• 调试Native崩溃时，能够读懂底层调用栈。
• 优化库体积时，也能识别出不必要的导出符号。

无论是日常开发还是性能调优，这些技能都算得上是Native开发者的标配工具。