热修复原理2：so库

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即可