深入理解 System.loadLibrary
本文主要讲述 Android 加载动态链接库的过程及其涉及的底层原理。
会先以一个Linux的例子描述native层加载动态链接库的过程,
再从Java层由浅入深分析System.loadLibrary
首先我们知道在Android(Java)中加载一个动态链接库非常简单,只需一行代码:
System.loadLibrary("native-lib");
事实上这是Java提供的API,对于Java层实现基本一致,但是对于不同的JVM其底层(native)实现会有所差异。本文分析的代码基于Android 6.0系统。
看过《理解JNI技术》的应该知道上述代码执行过程中会调用native层的JNI_OnLoad方法,一般用于动态注册native方法。
# Linux 系统加载动态库过程分析
Android是基于Linux系统的,那么在Linux系统下是如何加载动态链接库的呢?
如果对此不敢兴趣或者对C++比较陌生的可以先跳到后面阅读Android Java层实现部分,但是最终还是会涉及到native代码。
Linux环境下加载动态库主要包括如下函数,位于头文件#include <dlfcn.h>中:
void *dlopen(const char *filename, int flag); //打开动态链接库
char *dlerror(void); //获取错误信息
void *dlsym(void *handle, const char *symbol); //获取方法指针
int dlclose(void *handle); //关闭动态链接库
可以通过下述命令可以查看上述函数的具体使用方法:
man dlopen
如何在Linux环境下生成动态链接库,如何加载并使用动态链接库中的函数?带着问题看个例子:
下面是一个简单的C++文件,作为动态链接库包含计算相关函数:
[caculate.cpp]
extern "C"
int add(int a, int b) {
return a + b;
}
extern "C"
int mul(int a, int b) {
return a*b;
}
对于C++文件函数前的 extern “C” 不能省略,原因是C++编译之后会修改函数名,之后动态加载函数的时候会找不到该函数。加上extern “C”是告诉编译器以C的方式编译,不用修改函数名。
然后通过下述命令编译成动态链接库:
g++ -fPIC -shared caculate.cpp -o libcaculate.so
这样会在同级目录生成一个动态库文件:libcaculate.so
然后编写加载动态库并使用的代码:
[main_call.cpp]
#include <iostream>
#include <dlfcn.h>
using namespace std;
static const char * const LIB_PATH = "./libcaculate.so";
typedef int (*CACULATE_FUNC)(int, int);
int main() {
void* symAdd = nullptr;
void* symMul = nullptr;
char* errorMsg = nullptr;
dlerror();
//1.打开动态库,拿到一个动态库句柄
void* handle = dlopen(LIB_PATH, RTLD_NOW);
if(handle == nullptr) {
cout << "load error!" << endl;
return -1;
}
// 查看是否有错误
if ((errorMsg = dlerror()) != nullptr) {
cout << "errorMsg:" << errorMsg << endl;
return -1;
}
cout << "load success!" << endl;
//2.通过句柄和方法名获取方法指针地址
symAdd = dlsym(handle, "add");
if(symAdd == nullptr) {
cout << "dlsym failed!" << endl;
if ((errorMsg = dlerror()) != nullptr) {
cout << "error message:" << errorMsg << endl;
return -1;
}
}
//3.将方法地址强制类型转换成方法指针
CACULATE_FUNC addFunc = reinterpret_cast(symAdd);
//4.调用动态库中的方法
cout << "1 + 2 = " << addFunc(1, 2) << endl;
//5.通过句柄关闭动态库
dlclose(handle);
return 0;
}
主要就用了上面提到的4个函数,过程如下:
- 打开动态库,拿到一个动态库句柄
- 通过句柄和方法名获取方法指针地址
- 将方法地址强制类型转换成方法指针
- 调用动态库中的方法
- 通过句柄关闭动态库
中间会使用dlerror检测是否有错误。
有必要解释一下的是方法指针地址到方法指针的转换,为了方便这里定义了一个方法指针的别名:
typedef int (*CACULATE_FUNC)(int, int);
指明该方法接受两个int类型参数返回一个int值。
拿到地址之后强制类型转换成方法指针用于调用:
CACULATE_FUNC addFunc = reinterpret_cast(symAdd);
最后只要编译运行即可:
g++ -std=c++11 -ldl main_call.cpp -o main
.main
因为代码中使用了c++11标准新加的特性,所以编译的时候带上-std=c++11,另外使用了头文件dlfcn.h需要带上-ldl,编译生成的main文件即是二进制可执行文件,需要将动态库放在同级目录下执行。
上面就是Linux环境下创建动态库,加载并使用动态库的全部过程。
由于Android基于Linux系统,所以我们有理由猜测Android系统底层也是通过这种方式加载并使用动态库的。下面开始从Android 上层 Java 代码开始分析。
# System.loadLibrary
[System.java]
public static void loadLibrary(String libName) {
Runtime.getRuntime().loadLibrary(libName, VMStack.getCallingClassLoader());
}
此处VMStack.getCallingClassLoader()拿到的是调用者的ClassLoader,一般情况下是PathClassLoader。
[Runtime.java]
void loadLibrary(String libraryName, ClassLoader loader) {
if (loader != null) {
String filename = loader.findLibrary(libraryName);
if (filename == null) {
// It's not necessarily true that the ClassLoader used
// System.mapLibraryName, but the default setup does, and it's
// misleading to say we didn't find "libMyLibrary.so" when we
// actually searched for "liblibMyLibrary.so.so".
throw new UnsatisfiedLinkError(loader + " couldn't find \"" +
System.mapLibraryName(libraryName) + "\"");
}
String error = doLoad(filename, loader);
if (error != null) {
throw new UnsatisfiedLinkError(error);
}
return;
}
String filename = System.mapLibraryName(libraryName);
List candidates = new ArrayList();
String lastError = null;
for (String directory : mLibPaths) {
String candidate = directory + filename;
candidates.add(candidate);
if (IoUtils.canOpenReadOnly(candidate)) {
String error = doLoad(candidate, loader);
if (error == null) {
return; // We successfully loaded the library. Job done.
}
lastError = error;
}
}
if (lastError != null) {
throw new UnsatisfiedLinkError(lastError);
}
throw new UnsatisfiedLinkError("Library " + libraryName + " not found; tried " + candidates);
}
这里根据ClassLoader是否存在分了两种情况,当ClasssLoader存在的时候通过loader的findLibrary()查看目标库所在路径,当ClassLoader不存在的时候通过mLibPaths加载路径。最终都会调用doLoad加载动态库。
下面只讲ClassLoader存在的情况,不存在的情况更加简单。findLibrary位于PathClassLoader的父类BaseDexClassLoader中:
[BaseDexClassLoader.java]
@Override
public String findLibrary(String name) {
return pathList.findLibrary(name);
}
其中pathList的类型为DexPathList,它的构造方法如下:
[DexPathList.java]
public DexPathList(ClassLoader definingContext, String dexPath,
String libraryPath, File optimizedDirectory) {
// 省略其他代码
this.nativeLibraryDirectories = splitPaths(libraryPath, false);
this.systemNativeLibraryDirectories =
splitPaths(System.getProperty("java.library.path"), true);
List allNativeLibraryDirectories = new ArrayList<>(nativeLibraryDirectories);
allNativeLibraryDirectories.addAll(systemNativeLibraryDirectories);
this.nativeLibraryPathElements = makePathElements(allNativeLibraryDirectories, null,suppressedExceptions);
if (suppressedExceptions.size() > 0) {
this.dexElementsSuppressedExceptions =
suppressedExceptions.toArray(new IOException[suppressedExceptions.size()]);
} else {
dexElementsSuppressedExceptions = null;
}
}
这里收集了apk的so目录,一般位于:/data/app/${package-name}/lib/arm/
还有系统的so目录:System.getProperty(“java.library.path”),可以打印看一下它的值:/vendor/lib:/system/lib,其实就是前后两个目录,事实上64位系统是/vendor/lib64:/system/lib64。
最终查找so文件的时候就会在这三个路径中查找,优先查找apk目录。
[DexPathList.java]
public String findLibrary(String libraryName) {
String fileName = System.mapLibraryName(libraryName);
for (Element element : nativeLibraryPathElements) {
String path = element.findNativeLibrary(fileName);
if (path != null) {
return path;
}
}
return null;
}
String fileName = System.mapLibraryName(libraryName)的实现很简单:
[System.java]
public static String mapLibraryName(String nickname) {
if (nickname == null) {
throw new NullPointerException("nickname == null");
}
return "lib" + nickname + ".so";
}
也就是为什么动态库的命名必须以lib开头了。
然后会遍历nativeLibraryPathElements查找某个目录下是否有改文件,有的话就返回:
[DexPathList.java]
public String findNativeLibrary(String name) {
maybeInit();
if (isDirectory) {
String path = new File(dir, name).getPath();
if (IoUtils.canOpenReadOnly(path)) {
return path;
}
} else if (zipFile != null) {
String entryName = new File(dir, name).getPath();
if (isZipEntryExistsAndStored(zipFile, entryName)) {
return zip.getPath() + zipSeparator + entryName;
}
}
return null;
}
回到Runtime的loadLibrary方法,通过ClassLoader找到目标文件之后会调用doLoad方法:
[Runtime.java]
private String doLoad(String name, ClassLoader loader) {
String ldLibraryPath = null;
String dexPath = null;
if (loader == null) {
ldLibraryPath = System.getProperty("java.library.path");
} else if (loader instanceof BaseDexClassLoader) {
BaseDexClassLoader dexClassLoader = (BaseDexClassLoader) loader;
ldLibraryPath = dexClassLoader.getLdLibraryPath();
}
synchronized (this) {
return nativeLoad(name, loader, ldLibraryPath);
}
}
这里的ldLibraryPath和之前所述类似,loader为空时使用系统目录,否则使用ClassLoader提供的目录,ClassLoader提供的目录中包括apk目录和系统目录。
最后调用native代码:
[java_lang_Runtime.cc]
static jstring Runtime_nativeLoad(JNIEnv* env, jclass, jstring javaFilename, jobject javaLoader,jstring javaLdLibraryPathJstr) {
ScopedUtfChars filename(env, javaFilename);
if (filename.c_str() == nullptr) {
return nullptr;
}
SetLdLibraryPath(env, javaLdLibraryPathJstr);
std::string error_msg;
{
JavaVMExt* vm = Runtime::Current()->GetJavaVM();
bool success = vm->LoadNativeLibrary(env, filename.c_str(), javaLoader, &error_msg);
if (success) {
return nullptr;
}
}
// Don't let a pending exception from JNI_OnLoad cause a CheckJNI issue with NewStringUTF.
env->ExceptionClear();
return env->NewStringUTF(error_msg.c_str());
}
继续调用JavaVMExt对象的LoadNativeLibrary方法:
[java_vm_ext.cc]
bool JavaVMExt::LoadNativeLibrary(JNIEnv* env, const std::string& path, jobject class_loader,std::string* error_msg) {
error_msg->clear();
SharedLibrary* library;
Thread* self = Thread::Current();
{
MutexLock mu(self, *Locks::jni_libraries_lock_);
library = libraries_->Get(path);
}
if (library != nullptr) {
if (env->IsSameObject(library->GetClassLoader(), class_loader) == JNI_FALSE) {
StringAppendF(error_msg, "Shared library \"{936b63963a8c9f2b24063da536a495a32039ff9ed9d82cacc18dd4741407c351}s\" already opened by "
"ClassLoader {936b63963a8c9f2b24063da536a495a32039ff9ed9d82cacc18dd4741407c351}p; can't open in ClassLoader {936b63963a8c9f2b24063da536a495a32039ff9ed9d82cacc18dd4741407c351}p",
path.c_str(), library->GetClassLoader(), class_loader);
LOG(WARNING) << error_msg;
return false;
}
if (!library->CheckOnLoadResult()) {
StringAppendF(error_msg, "JNI_OnLoad failed on a previous attempt "
"to load \"{936b63963a8c9f2b24063da536a495a32039ff9ed9d82cacc18dd4741407c351}s\"", path.c_str());
return false;
}
return true;
}
Locks::mutator_lock_->AssertNotHeld(self);
const char* path_str = path.empty() ? nullptr : path.c_str();
//1.打开动态链接库
void* handle = dlopen(path_str, RTLD_NOW);
bool needs_native_bridge = false;
if (handle == nullptr) {
if (android::NativeBridgeIsSupported(path_str)) {
handle = android::NativeBridgeLoadLibrary(path_str, RTLD_NOW);
needs_native_bridge = true;
}
}
if (handle == nullptr) {
//检查错误信息
*error_msg = dlerror();
VLOG(jni) << "dlopen(\"" << path << "\", RTLD_NOW) failed: " << *error_msg; return false; } if (env->ExceptionCheck() == JNI_TRUE) {
LOG(ERROR) << "Unexpected exception:"; env->ExceptionDescribe();
env->ExceptionClear();
}
bool created_library = false;
{
std::unique_ptr new_library(new SharedLibrary(env, self, path, handle, class_loader));
MutexLock mu(self, *Locks::jni_libraries_lock_);
library = libraries_->Get(path);
if (library == nullptr) { // We won race to get libraries_lock.
library = new_library.release();
libraries_->Put(path, library);
created_library = true;
}
}
if (!created_library) {
return library->CheckOnLoadResult();
}
bool was_successful = false;
void* sym;
if (needs_native_bridge) { library->SetNeedsNativeBridge();
sym = library->FindSymbolWithNativeBridge("JNI_OnLoad", nullptr);
} else {
//2.获取方法地址
sym = dlsym(handle, "JNI_OnLoad");
}
if (sym == nullptr) {
VLOG(jni) << "[No JNI_OnLoad found in \"" << path << "\"]";
was_successful = true;
} else {
ScopedLocalRef old_class_loader(env, env->NewLocalRef(self->GetClassLoaderOverride()));
self->SetClassLoaderOverride(class_loader);
typedef int (*JNI_OnLoadFn)(JavaVM*, void*);
//3.强制类型转换成函数指针
JNI_OnLoadFn jni_on_load = reinterpret_cast(sym);
//4.调用函数
int version = (*jni_on_load)(this, nullptr);
if (runtime_->GetTargetSdkVersion() != 0 && runtime_->GetTargetSdkVersion() <= 21) { fault_manager.EnsureArtActionInFrontOfSignalChain(); } self->SetClassLoaderOverride(old_class_loader.get());
if (version == JNI_ERR) {
StringAppendF(error_msg, "JNI_ERR returned from JNI_OnLoad in \"{936b63963a8c9f2b24063da536a495a32039ff9ed9d82cacc18dd4741407c351}s\"", path.c_str());
} else if (IsBadJniVersion(version)) {
StringAppendF(error_msg, "Bad JNI version returned from JNI_OnLoad in \"{936b63963a8c9f2b24063da536a495a32039ff9ed9d82cacc18dd4741407c351}s\": {936b63963a8c9f2b24063da536a495a32039ff9ed9d82cacc18dd4741407c351}d",
path.c_str(), version);
} else {
was_successful = true;
}
return was_successful;
}
这个函数有点长,重点都用注释标注了。
开始的时候会去缓存查看是否已经加载过动态库,如果已经加载过会判断上次加载的ClassLoader和这次加载的ClassLoader是否一致,如果不一致则加载失败,如果一致则返回上次加载的结果,换句话说就是不允许不同的ClassLoader加载同一个动态库。为什么这么做值得推敲。
之后会通过dlopen打开动态共享库。然后会获取动态库中的JNI_OnLoad方法,如果有的话调用之。最后会通过JNI_OnLoad的返回值确定是否加载成功:
static bool IsBadJniVersion(int version) {
// We don't support JNI_VERSION_1_1. These are the only other valid versions.
return version != JNI_VERSION_1_2 && version != JNI_VERSION_1_4 && version != JNI_VERSION_1_6;
}
这也是为什么在JNI_OnLoad函数中必须正确返回的原因。
可以看到最终没有调用dlclose,当然也不能调用,这里只是加载,真正的函数调用还没有开始,之后就会使用dlopen拿到的句柄来访问动态库中的方法了。
看完这篇文章我们明确了几点:
- System.loadLibrary会优先查找apk中的so目录,再查找系统目录,系统目录包括:/vendor/lib(64),/system/lib(64)
- 不能使用不同的ClassLoader加载同一个动态库
- System.loadLibrary加载过程中会调用目标库的JNI_OnLoad方法,我们可以在动态库中加一个JNI_OnLoad方法用于动态注册
- 如果加了JNI_OnLoad方法,其的返回值为JNI_VERSION_1_2 ,JNI_VERSION_1_4, JNI_VERSION_1_6其一。我们一般使用JNI_VERSION_1_4即可
- Android动态库的加载与Linux一致使用dlopen系列函数,通过动态库的句柄和函数名称来调用动态库的函数
>> 转载请注明来源:深入理解 System.loadLibrary
免费分享,随意打赏
开发者头条
感谢分享!已推荐到《开发者头条》:https://toutiao.io/posts/nuq2bs 欢迎点赞支持!
欢迎订阅《pqpo》https://toutiao.io/subject/55960
Neway
谢谢楼主分享
pqpo
看了你的博客也很不错
谈小龙
“`不能使用不同的ClassLoader加载同一个动态库“` 应该跟java的类加载机制有关
pqpo
看文章中的 LoadNativeLibrary 函数,可以得出这个结论:不允许使用不同的 ClassLoader 加载同一个动态库。至于为什么这么做,我之前也没详细思考过,可以仔细谈谈吗?
谈小龙
https://www.ibm.com/developerworks/cn/java/j-lo-classloader/index.html
这篇文章里面有说明:
Java 虚拟机是如何判定两个 Java 类是相同的。Java 虚拟机不仅要看类的全名是否相同,还要看加载此类的类加载器是否一样。只有两者都相同的情况,才认为两个类是相同的。即便是同样的字节代码,被不同的类加载器加载之后所得到的类,也是不同的。
pqpo
这个我知道,但是两个 ClassLoader 加载同一份字节码创建两个不同的类类型为什么就不能加载同一个动态链接库呢?