SO库加载原理
java提供了以下两个接口加载一个so库：
- System.loadLibrary(String libName):传入so库名称，库文件位于apk压缩文件的libs目录。
- System.load(String pathName):传入so库的完整路径，加载一个外部so库。
实际最后都调用nativeLoad这个native方法去加载so库，参数是so库在磁盘中的完整路径名。
静态、动态注册native方法：
public class MainActivity extends Activity {
static {
System.loadLibrary("jnitest");
}
public static native String stringFromJNI();
public static native void test();
}
//静态注册stringFromJNI本地方法
extern "C" jstring Java_com_test_jni_MainActivity_stringFromJNI(JNIEnv *env, jclass clazz) {
std::string hello = "jni stringFromJNI ...";
return env->NewStringUTF(hello.c_str());
}
//动态注册test方法
void test(JNIEnv *env, jclass clazz) {
LOGD("jni test ...");
}
JNINativeMethod nativeMethods[] = {
{"test", "()V", (void*)test}
};
#define JNIREG_CLASS "com/test/jni/MainActivity"
JNIEXPORT jint JNICALL JNI_Onload(JavaVM *vm, void *reserved) {
LOGD("JNI_OnLoad");
jclass clz = env->FindClass(JNIREG_CLASS);
if (env->RegisterNatives(clz, nativeMethods, sizeof(nativeMethods)/
sizeof(nativeMethods[0])) != JNI_OK) {
return JNI_ERR;
}
return JNI_VERSION_1_4;
}
native方法映射逻辑：
SO库热部署实时生效
1. 动态注册实时生效
动态注册native方法调用一次JNI_OnLoad都会重新完成一次映射，所以只要先加载原来的so库，再加载补丁so库，就能实现实时修复。
实测art下这样可以做到实时生效，但是Dalvik下做不到。
Dalvik下dlopen的实现，源码再/bionic/linker/dlfcn.cpp，方法调用链路：dlopen->do_dlopen->find_library->find_library_internal。
static soinfo* find_library_internal(const char* name) {
soinfo* si = find_loaded_library(name);
if (si != NULL) {//so库已经加载过，直接返回句柄
if (si->flags & FLAG_LINKED) {
return si;
}
DL_ERR("OOPS: recursive link to \"%s\"", si->name);
return NULL;
}
TRACE("[ '%s' has not been loaded yet. Locating...]", name);
si = load_library(name);//so库从未加载过，执行加载
if (si == NULL) {
return NULL;
}
return si;
}
看代码注释，这其实是Dalvik下的一个bug，通过basename去查找。例如传入修复后的so库路径为'/data/data/com.test.jni/files/libnative-lib.so'，此时通过basename：libnative-lib.so作为key去查找。
art下不存在这个问题，以name而不是basename作为key去查找。
解决Dalvik这个问题，可以对补丁so进行改名，比如改为libnative-lib-123.so，也能做到实时生效。
static soinfo *find_loaded_library(const char *name)
{
soinfo *si;
const char *bname;
// TODO: don't use basename only for determining libraries
// http://code.google.com/p/android/issues/detail?id=6670
bname = strrchr(name, '/');
bname = bname ? bname + 1 : name;
for (si = solist; si != NULL; si = si->next) {
if (!strcmp(bname, si->name)) {
return si;
}
}
return NULL;
}
2. 静态注册实时生效
静态注册在native方法第一次执行的时候就完成了映射，幸运的是JNI提供了解注册接口：UnregisterNatives(JNIEnv* env, jclass jclazz)。
UnregisterNatives会把jclazz所在类的所有native方法都重新指向dvmResolveNativeMethod，所以调用之后不管是静态还是动态注册的native方法，都需要重新去做映射。
实测发现，补丁so重命名的前提下，java层native方法可能映射到原so库的方法，也可能映射到补丁so库的新方法。
静态注册，解映射后，再运行该方法时执行的是dvmResolveNativeMethod函数，进一步调用lookupSharedLibMethod -> dvmHashForeach(gDvm.nativeLibs, findMethodInLib, (void*)method)。
gDvm.nativeLibs是一个全局变量，它是一个hashtable，存放着整个虚拟机加载so库的SharedLib结构指针。然后该变量作为参数传递给dvmHashForeach函数进行hashtable遍历。执行findMethodInLib函数看是否找到对应的native函数指针，如果第一个找到就直接return，不再进行下次查找。
hashtable的实现要比hashmap简单，hashmap冲突通过新增链表处理，hashtable只是简单的把指针下移到下一个空节点。hashtable的遍历实际就是数组遍历。
SO库冷部署重启生效
SO库实时生效方案，对于静态注册有一定局限性，不满足一般的通用性，采用冷部署更佳。
1. 接口调用替换方案
替换默认接口：
SoPatchManager.loadLibrary(String libName) -> 代替System.loadLibrary(String libName)
SoPatchManager.loadLibrary接口加载so库的时候，优先尝试去加载sdk指定目录下的补丁so。
这种实现虽然简单，同时不需要对不同sdk版本区分处理，但没法修复三方包的so库，同时要强制侵入接入方接口调用，不够优雅。
2. 反射注入方案
System.loadLibrary("native-lib")最终传给native方法执行的是so库在磁盘中的完整路径，比如：/data/app-lib/com.test.jni/libnative-lib.so。
so库会在DexPathList.nativeLibraryDirectories/nativeLibraryPathElements变量表示的目录下去遍历搜索。
sdk<23 DexPathList.findLibrary实现：
public String findLibrary(String libraryName) {
String fileName = System.mapLibraryName(libraryName);
for (File directory : nativeLibraryDirectories) {
String path = new File(directory, fileName).getPath();
if (IoUtils.canOpenReadOnly(path)) {
return path;
}
}
return null;
}
sdk>=23 DexPathList.findLibrary实现：
public String findLibrary(String libraryName) {
String fileName = System.mapLibraryName(libraryName);
for (NativeLibraryElement element : nativeLibraryPathElements) {
String path = element.findNativeLibrary(fileName);
if (path != null) {
return path;
}
}
return null;
}
- sdk < 23:反射注入，把补丁so库的路径插入到nativeLibraryDirectories数组的最前面，达到加载so的时候是补丁so库而不是原来so库的目录，从而达到修复目的。
- sdk>=23:反射注入，把补丁so库的完整路径作为参数构建一个Element对象，插入到nativeLibraryPathElements数组前面。
如何正确复制补丁SO库
虚拟机究竟选择哪个abis目录作为参数构建PathClassLoader对象？
- sdk>=21时，直接反射拿到ApplicationInfo对象的primaryCpuAbi即可
- sdk<21时，由于此时不支持64位，直接把Build.CPU_ABI，Build.CPU_ABI2作为primaryCpuAbi即可
