Android项目复用其他项目.so文件遇UnsatisfiedLinkError问题求助

这种问题我之前帮同行排查过好多次，虽然你说方法签名和原APK一致，但还是有不少容易忽略的细节，给你列几个最可能的排查方向和解决办法：

• 核对类的全限定名是否完全一致
  Native方法绑定的是完整的类路径（包名+类名），哪怕是大小写、下划线或者包名层级的细微差别都会导致绑定失败。建议用jadx这类工具反编译原APK的Java代码，把你的类的全路径和原APK里的类做逐字符对比，确保完全匹配。

• 仔细校验Native方法的签名细节
  你提到的错误签名是Decode:([BI[B)I，对应的Java方法应该是public native int decode(byte[] arg1, int arg2, byte[] arg3)，这里要注意：

  • 参数顺序有没有搞反？
  • 是不是误用了包装类型（比如Integer代替int）？Native方法只识别基本数据类型，包装类会导致签名不匹配。
  • 数组类型是否正确？比如byte[]对应的签名是[B，别写成[Ljava/lang/Byte;这种对象数组的签名。

• 检查SO文件的导出符号
  可以用工具查看SO里的导出函数名：

  • Linux/macOS下用nm -D your.so
  • Windows下用dumpbin /exports your.so
    正常情况下，Native方法对应的符号应该是Java_com_xxx_xxx_YourClass_Decode这样的格式（注意类名和方法名的大小写要和你的Java类完全对应）。如果导出的符号和你的类路径+方法名对不上，那肯定会找不到方法。

• 排查混淆导致的不匹配
  原签名APK大概率开启了混淆，如果你复制的SO是混淆后的版本，但自己的项目没开混淆或者混淆规则不一致，就会出现问题。比如原APK里的类名被混淆成了a.b.c.d，而你的类还是原来的全名，SO里的符号是混淆后的，自然匹配不上。如果能拿到原APK的混淆映射文件，就把你的类和方法名改成混淆后的；如果拿不到，也可以尝试调整自己的混淆规则，让类和方法名的混淆结果和SO里的符号一致。

• 确认ABI兼容性问题
  虽然库加载成功，但有可能你运行设备的ABI和存放SO的目录不匹配。比如你把SO放在armeabi-v7a，但设备是arm64-v8a，系统虽然会加载兼容的SO，但偶尔会出现奇怪的绑定问题。可以试试把SO放到对应设备的ABI目录，或者在代码里打印Build.CPU_ABI确认设备使用的ABI。

• 检查类加载器一致性
  如果你的Java类是用自定义类加载器加载的，而SO是被系统类加载器加载的，也可能导致Native方法找不到。可以尝试在加载SO的时候，使用和加载Java类相同的类加载器，或者确保两者的类加载器一致。

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