从源码角度讲讲我对Android和Unity的热更so的理解

版权声明：本文为博主Atany原创文章，未经博主允许不得转载。博客地址：http://blog.csdn.net/yang8456211 https://blog.csdn.net/yang8456211/article/details/78572362

一、前言

---

因为有一些功能的修改动到了Unity的源码，需要放到现网去调试，但是通过发包的方式进行测试实在是太重度了，因此特意的研究了一下Unity的加载So的过程，实现对libunity.so和libmono.so两个库文件的热更，方便在现网进行调试。
底层的东西只是浅尝辄止，如果有写的不对的地方欢迎留言指正（Atany）

二、Android是怎么读取So的

基于Android 5.1，因为之前查bugly的一个崩溃用的这个版本就直接看了，对比了部分Android O的代码，对于So的读取这块有点差别，但是不影响原理。

2.1 系统API

读取任何的So文件都是通过System类的两个系统API实现

• System.load(name)

  Loads the native library specified by the filename argument. The filename argument must be an absolute path name.

• System.loadLibrary(name)

  Loads the native library specified by the libname argument. The libname argument must not contain any platform specific prefix, file extension or path.

两个API的差别是：
1）System.load 是读取一个绝对路径的参数，需要传入So的完整路径；
2）System.loadLibrary 是读取的相对路径，只用传入So的名称即可（例如想要读取libmain.so，传入main即可），在读取So的过程中，会有一个mapLibraryName方法去添加前缀和后缀（main => libmain.so）

2.2 System.load 实现

开始分别讲一讲两个API的实现：

• System.java

    /**
     * See {@link Runtime#load}.
     */
    public static void load(String pathName) {
        Runtime.getRuntime().load(pathName, VMStack.getCallingClassLoader());
    }

1）直接调用Runtime.java里面的load方法，并添加了一个参数VMStack.getCallingClassLoader()，这里获取的是当前加载此类的ClassLoader，在Android里面为PathClassLoader。
2）Runtime.java主要是在处理运行时的一些东西，例如Gc。
3）读取So的路径有一套机制叫做双亲委托，可自行Google。

继续看load方法：

• Runtime.java

    /*
     * Loads the given shared library using the given ClassLoader.
     */
    void load(String absolutePath, ClassLoader loader) {
        if (absolutePath == null) {
            throw new NullPointerException("absolutePath == null");
        }
        String error = doLoad(absolutePath, loader);
        if (error != null) {
            throw new UnsatisfiedLinkError(error);
        }
    }

这里就很明显了，当绝对路径为空的时候抛出异常，否则就调用doLoad的方法进行加载。（doLoad放在后面讲）

2.3 System.loadLibrary 实现

同System.Load一样，调用Runtime类里面的LoadLibrary方法

• System.java

    /**
     * See {@link Runtime#loadLibrary}.
     */
    public static void loadLibrary(String libName) {
        Runtime.getRuntime().loadLibrary(libName, VMStack.getCallingClassLoader());
    }

• Runtime.Java

/*
     * Searches for and loads the given shared library using the given ClassLoader.
     */
    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<String> candidates = new ArrayList<String>();
        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是否存在分了两种情况：

1）当ClasssLoader存在的时候，通过loader的findLibrary()查看目标库所在路径。

2）当ClassLoader不存在的时候，通过mLibPaths加载路径。最终都会调用doLoad加载动态库。

2.3.1 ClassLoader 不存在的情况

• Runtime.java

        for (String directory : mLibPaths) {
            String candidate = directory + filename;
            candidates.add(candidate);

mLibPaths通过initLibPaths方法进行初始化：

    /**
     * Holds the library paths, used for native library lookup.
     */
    private final String[] mLibPaths = initLibPaths();

    private static String[] initLibPaths() {
        String javaLibraryPath = System.getProperty("java.library.path");
        if (javaLibraryPath == null) {
            return EmptyArray.STRING;
        }
        String[] paths = javaLibraryPath.split(":");
        // Add a '/' to the end of each directory so we don't have to do it every time.
        for (int i = 0; i < paths.length; ++i) {
            if (!paths[i].endsWith("/")) {
                paths[i] += "/";
            }
        }
        return paths;
    }

可以看到，其实就是读取系统的Properties，这里读取的是java.library.path这个Properties。

所以如果我们想热更自己的So文件的话，可以通过setProperties的方法修改java.library.path这个配置的路径，让系统先读取我们的目录，再读取默认的目录

把java.library.path的路径打印出来看看：

可以看出各个手机运营商的不同，会有不同的读取路径，但是都会有/system/lib和/vendor/lib 这两个目录。

2.3.1.1 system.getproperty

这里列举一下常见的properties

2.3.2 ClassLoader 存在的情况

通过loader.findLibrary来找到So的路径

首先在PathClassLoader的父类BaseDexClassLoader中找到findLibrary，发现是调用pathList的findLibrary，pathList是DexPathList的实例。

• （PathClassLoader） 父类BaseDexClassLoader.java

    @Override
    public String findLibrary(String name) {
        return pathList.findLibrary(name);
    }

• DexPathList.java

    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;
    }

通过遍历nativeLibraryDirectories继续找路径，那个这个nativeLibraryDirectories是什么呢？

• DexPathList.java

    public DexPathList(ClassLoader definingContext, String dexPath,
            String libraryPath, File optimizedDirectory) {
...//省略无关代码
        ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>();
        this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
                                           suppressedExceptions);
        if (suppressedExceptions.size() > 0) {
            this.dexElementsSuppressedExceptions =
                suppressedExceptions.toArray(new IOException[suppressedExceptions.size()]);
        } else {
            dexElementsSuppressedExceptions = null;
        }
        this.nativeLibraryDirectories = splitLibraryPath(libraryPath);

在DexPathList的构造方法中，对传入参数libraryPath进行了split，得到了nativeLibraryDirectories。

再看看splitLibraryPath方法：

    private static File[] splitLibraryPath(String path) {
        ArrayList<File> result = splitPaths(path, System.getProperty("java.library.path"), true);
        return result.toArray(new File[result.size()]);
    }

把传入的path和java.library.path进行合并，那么这个传入的libraryPath是什么呢？

• BaseDexClassLoader.java

    public BaseDexClassLoader(String dexPath, File optimizedDirectory,
            String libraryPath, ClassLoader parent) {
        super(parent);
        this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
    }

libraryPath是在BaseDexClassLoader的构造方法由上层传入的。
往上就没有找到Java层的源码了，猜测是用C调用的，在创建PathClassLoader实例的时候传入的。
打印出来看发现这个是传入的是Apk内部lib文件夹的路径。

所以Android层面System.Load方法读取So最终的路径是：
1）/data/app/${package-name}/lib/arm/
2）/vendor/lib /system/lib
64位系统也可能 /vendor/lib64 /system/lib64

2.4 doload的实现

在了解load方法找寻So文件的路径后，我们来看看真正的加载是怎么实现的。

• Runtime.Java

    private String doLoad(String name, ClassLoader loader) {
        String ldLibraryPath = null;
        if (loader != null && loader instanceof BaseDexClassLoader) {
            ldLibraryPath = ((BaseDexClassLoader) loader).getLdLibraryPath();
        }
        synchronized (this) {
            return nativeLoad(name, loader, ldLibraryPath);
        }
    }

getLdLibraryPath方法

    /**
     * @hide
     */
    public String getLdLibraryPath() {
        StringBuilder result = new StringBuilder();
        for (File directory : pathList.getNativeLibraryDirectories()) {
            if (result.length() > 0) {
                result.append(':');
            }
            result.append(directory);
        }
        return result.toString();
    }

    @Override public String toString() {
        return getClass().getName() + "[" + pathList + "]";
    }

getLdLibraryPath方法实际上也是获得nativeLibraryDirectories这个目录。

实际的调用从nativeLoad方法往下看，我在源码全局搜索了Runtime_nativeLoad方法，发现调用到java_lang_Runtime.cc里面的Runtime_nativeLoad方法

• java_lang_Runtime.cc

static jstring Runtime_nativeLoad(JNIEnv* env, jclass, jstring javaFilename, jobject javaLoader, jstring javaLdLibraryPath) {
  ScopedUtfChars filename(env, javaFilename);
  if (filename.c_str() == NULL) {
    return NULL;
  }

  if (javaLdLibraryPath != NULL) {
    ScopedUtfChars ldLibraryPath(env, javaLdLibraryPath);
    if (ldLibraryPath.c_str() == NULL) {
      return NULL;
    }
    void* sym = dlsym(RTLD_DEFAULT, "android_update_LD_LIBRARY_PATH");
    if (sym != NULL) {
      typedef void (*Fn)(const char*);
      Fn android_update_LD_LIBRARY_PATH = reinterpret_cast<Fn>(sym);
      (*android_update_LD_LIBRARY_PATH)(ldLibraryPath.c_str());
    } else {
      LOG(ERROR) << "android_update_LD_LIBRARY_PATH not found; .so dependencies will not work!";
    }
  }

  std::string detail;
  {
    ScopedObjectAccess soa(env);
    StackHandleScope<1> hs(soa.Self());
    Handle<mirror::ClassLoader> classLoader(
        hs.NewHandle(soa.Decode<mirror::ClassLoader*>(javaLoader)));
    JavaVMExt* vm = Runtime::Current()->GetJavaVM();
    bool success = vm->LoadNativeLibrary(filename.c_str(), classLoader, &detail);
    if (success) {
      return nullptr;
    }
  }

  // Don't let a pending exception from JNI_OnLoad cause a CheckJNI issue with NewStringUTF.
  env->ExceptionClear();
  return env->NewStringUTF(detail.c_str());
}

经过一些列的字符串转化之后，调用到了JavaVMExt对象的LoadNativeLibrary

• Jni_internal.cc(Android O for java_vm_ext.cc)

bool JavaVMExt::LoadNativeLibrary(const std::string& path,
                                  Handle<mirror::ClassLoader> class_loader,
                                  std::string* detail) {
  detail->clear();

  // See if we've already loaded this library.  If we have, and the class loader
  // matches, return successfully without doing anything.
  // TODO: for better results we should canonicalize the pathname (or even compare
  // inodes). This implementation is fine if everybody is using System.loadLibrary.
  SharedLibrary* library;
  Thread* self = Thread::Current();
  {
    // TODO: move the locking (and more of this logic) into Libraries.
    MutexLock mu(self, libraries_lock);
    library = libraries->Get(path);
  }
  if (library != nullptr) {
    if (library->GetClassLoader() != class_loader.Get()) {
      // The library will be associated with class_loader. The JNI
      // spec says we can't load the same library into more than one
      // class loader.
      StringAppendF(detail, "Shared library \"%s\" already opened by "
          "ClassLoader %p; can't open in ClassLoader %p",
          path.c_str(), library->GetClassLoader(), class_loader.Get());
      LOG(WARNING) << detail;
      return false;
    }
    VLOG(jni) << "[Shared library \"" << path << "\" already loaded in "
              << "ClassLoader " << class_loader.Get() << "]";
    if (!library->CheckOnLoadResult()) {
      StringAppendF(detail, "JNI_OnLoad failed on a previous attempt "
          "to load \"%s\"", path.c_str());
      return false;
    }
    return true;
  }

  // Open the shared library.  Because we're using a full path, the system
  // doesn't have to search through LD_LIBRARY_PATH.  (It may do so to
  // resolve this library's dependencies though.)

  // Failures here are expected when java.library.path has several entries
  // and we have to hunt for the lib.

  // Below we dlopen but there is no paired dlclose, this would be necessary if we supported
  // class unloading. Libraries will only be unloaded when the reference count (incremented by
  // dlopen) becomes zero from dlclose.

  // This can execute slowly for a large library on a busy system, so we
  // want to switch from kRunnable while it executes.  This allows the GC to ignore us.
  self->TransitionFromRunnableToSuspended(kWaitingForJniOnLoad);
  const char* path_str = path.empty() ? nullptr : path.c_str();
  void* handle = dlopen(path_str, RTLD_LAZY);
  bool needs_native_bridge = false;
  if (handle == nullptr) {
    if (android::NativeBridgeIsSupported(path_str)) {
      handle = android::NativeBridgeLoadLibrary(path_str, RTLD_LAZY);
      needs_native_bridge = true;
    }
  }
  self->TransitionFromSuspendedToRunnable();

  VLOG(jni) << "[Call to dlopen(\"" << path << "\", RTLD_LAZY) returned " << handle << "]";

  if (handle == nullptr) {
    *detail = dlerror();
    LOG(ERROR) << "dlopen(\"" << path << "\", RTLD_LAZY) failed: " << *detail;
    return false;
  }

  // Create a new entry.
  // TODO: move the locking (and more of this logic) into Libraries.
  bool created_library = false;
  {
    MutexLock mu(self, libraries_lock);
    library = libraries->Get(path);
    if (library == nullptr) {  // We won race to get libraries_lock
      library = new SharedLibrary(path, handle, class_loader.Get());
      libraries->Put(path, library);
      created_library = true;
    }
  }
  if (!created_library) {
    LOG(INFO) << "WOW: we lost a race to add shared library: "
        << "\"" << path << "\" ClassLoader=" << class_loader.Get();
    return library->CheckOnLoadResult();
  }

  VLOG(jni) << "[Added shared library \"" << path << "\" for ClassLoader " << class_loader.Get()
      << "]";

  bool was_successful = false;
  void* sym = nullptr;
  if (UNLIKELY(needs_native_bridge)) {
    library->SetNeedsNativeBridge();
    sym = library->FindSymbolWithNativeBridge("JNI_OnLoad", nullptr);
  } else {
    sym = dlsym(handle, "JNI_OnLoad");
  }

  if (sym == nullptr) {
    VLOG(jni) << "[No JNI_OnLoad found in \"" << path << "\"]";
    was_successful = true;
  } else {
    // Call JNI_OnLoad.  We have to override the current class
    // loader, which will always be "null" since the stuff at the
    // top of the stack is around Runtime.loadLibrary().  (See
    // the comments in the JNI FindClass function.)
    typedef int (*JNI_OnLoadFn)(JavaVM*, void*);
    JNI_OnLoadFn jni_on_load = reinterpret_cast<JNI_OnLoadFn>(sym);
    StackHandleScope<1> hs(self);
    Handle<mirror::ClassLoader> old_class_loader(hs.NewHandle(self->GetClassLoaderOverride()));
    self->SetClassLoaderOverride(class_loader.Get());

    int version = 0;
    {
      ScopedThreadStateChange tsc(self, kNative);
      VLOG(jni) << "[Calling JNI_OnLoad in \"" << path << "\"]";
      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(detail, "JNI_ERR returned from JNI_OnLoad in \"%s\"", path.c_str());
    } else if (IsBadJniVersion(version)) {
      StringAppendF(detail, "Bad JNI version returned from JNI_OnLoad in \"%s\": %d",
                    path.c_str(), version);
      // It's unwise to call dlclose() here, but we can mark it
      // as bad and ensure that future load attempts will fail.
      // We don't know how far JNI_OnLoad got, so there could
      // be some partially-initialized stuff accessible through
      // newly-registered native method calls.  We could try to
      // unregister them, but that doesn't seem worthwhile.
    } else {
      was_successful = true;
    }
    VLOG(jni) << "[Returned " << (was_successful ? "successfully" : "failure")
              << " from JNI_OnLoad in \"" << path << "\"]";
  }

  library->SetResult(was_successful);
  return was_successful;
}

1）开始的时候会去缓存查看是否已经加载过动态库，如果已经加载过会判断上次加载的ClassLoader和这次加载的ClassLoader是否一致，如果不一致则加载失败，就是说不允许不同的ClassLoader加载同一个动态库。


2）之后会通过dlopen打开动态共享库。然后会获取动态库中的JNI_OnLoad方法，如果有的话调用之。最后会通过JNI_OnLoad的返回值确定是否加载成功。

3）非关键的代码就没细看了，源码已贴出来，可自行阅读。

2.5 Android 读取So总结

1、System.loadLibrary会优先查找apk中的so目录，再查找系统目录，系统目录包括：/vendor/lib(64)，/system/lib(64) （不同的厂商可能有不同）

2、System.loadLibrary加载过程中会调用目标库的JNI_OnLoad方法，对相关的JNI方法进行注册。

3、Android动态库的加载使用dlopen、dlsylm、dlclose系列函数，通过动态库的句柄和函数名称来调用动态库的函数和变量。

三、Unity是怎么读取相关So的？

Unity读取So分两个部分
1）第一个部分是读取第三方的So，这个部分的读取其实跟Android读取So的过程很像，就不赘述了。
2）我想研究的是，Unity是怎么加载自身使用的So，这里主要是三个so。

• libmain.so
• libunity.so
• libmono.so

3.1 libMain.so

libmain.so这个是Unity启动的时候最开始加载的，先加载了libmain.so，才能继续加载其他相关的so。

1）在UnityNativePlayer.activity中创建了UnityPlayer的实例。（activity的名字不记得了，好像是这个- b-）
2）在UnityPlayer.java 中使用静态块加载Libmain.so

• UnityPlayer.java

    static
    {
        System.loadLibrary ("main");        // main / NativeActivity helper library
    }

3.1.1网上有个总结static块调用时机说的很详细

当一个类被主动使用时，Java虚拟机就会对其初始化，如下六种情况为主动使用：
1、当创建某个类的新实例时（如通过new或者反射，克隆，反序列化等）
2、当调用某个类的静态方法时
3、当使用某个类或接口的静态字段时
4、当调用Java API中的某些反射方法时，比如类Class中的方法，或者java.lang.reflect中的类的方法时
5、当初始化某个子类时
6、当虚拟机启动某个被标明为启动类的类（即包含main方法的那个类）

所以在第一个Activity oncreate的时候，libmain.so就加载进来了。

3.2 libunity.so、libmono.so

这两个so的加载，一度认为是使用Android的System.loadLibrary加载进来的，实际上UnityPlayer.java中确实也有这个相关的loadLibrary方法，但是最后发现其实是没有调用的。

继续寻找，发现另有地方单独编写了这两个So的加载。

• UnityPlayer.Java

在UnityPlayer的构造方法中有一个loadNative方法：

    public UnityPlayer(ContextWrapper context)
    {
        super(context);

        if (context instanceof Activity)
            currentActivity = (Activity)context;

        mSurfaceManager = new SurfaceManager(this);
        mContext = context;
        mNativeActivitySupport      = (context instanceof android.app.Activity) ? new NativeActivitySupport(context) : null;
        mSensors = new Sensors(context, this);

        parseSettings ();
        //loadNative方法
        loadNative(mContext.getApplicationInfo());

loadNative方法传入了当前的Context对象的applicationInfo。

    private static void loadNative(ApplicationInfo applicationInfo)
    {
        if (NativeLoader.load(applicationInfo.nativeLibraryDir))
            UnityPlayerState.setLibrariesLoaded();
        else
            throw new UnsatisfiedLinkError("Unable to load libraries from libmain.so");
    }

接着查看一下NativeLoader.load方法，是在libmain.so 中的ANativeActivity_onCreate.cpp方法中进行注册的。在JNI_OnLoad中注册了load和unload方法。

• ANativeActivity_onCreate.cpp

static JNINativeMethod sNativeMethods[] =
{
    { "load", "(Ljava/lang/String;)Z", (void*)Load },
    { "unload", "()Z", (void*)Unload },
};

EXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved)
{
    JNIEnv* env = 0;
    vm->AttachCurrentThread(&env, 0);

    const char* className = "com/unity3d/player/NativeLoader";
    jclass clazz = env->FindClass(className);

    const size_t num_methods = sizeof(sNativeMethods) / sizeof(sNativeMethods[0]);
    if (env->RegisterNatives(clazz, sNativeMethods, num_methods) < 0)
    {
        env->FatalError(className);
        return -1;
    }

    return JNI_VERSION_1_6;     // minimum JNI version
}

看看load方法的实现：

static jboolean Load(JNIEnv* env, jclass clazz, jstring nativeLibraryDir)
{
    LOGD("%s", __FUNCTION__);   
    char* libdir;
    {
        jsize str_len = env->GetStringUTFLength(nativeLibraryDir) + 1;
        libdir = (char*)malloc(str_len);
        const char* dir = env->GetStringUTFChars(nativeLibraryDir, 0);
        memcpy(libdir, dir, str_len);
        env->ReleaseStringUTFChars(nativeLibraryDir, dir);
        LOGD("nativeLibraryDir '%s' (%i)", libdir, str_len);
    }

#if UNITY_PSM
    dlload(env, libdir, "libandroid-bridge.so", &libbridge);
    dlload(env, libdir, "libmono-2.0.so", &libmono);
#else
    dlload(env, libdir, "libmono.so", &libmono);
#endif
    dlload(env, libdir, "libunity.so", &libunity);

#if UNITY_PSM && DEBUGMODE
    LOGD("Sleeping 10s - attach debugger now...");
    sleep(10);
#endif

    free(libdir);

    return libmono && libunity;
}

ok，看到这里就知道了，在UnityPlayer的构造方法中调用loadNative，会加载两个so，一个是libmono.so，另一个是libunity.so。如果是PlayStation的平台的话，还会加载另外的一个libandroid-bridge.so，这个就不是手机范围的事情咯。

继续往下看dllload

static bool dlload(JNIEnv* env, const char* libdir, const char* libname, volatile void** handle_out)
{
    LOGD("Loading '%s'", libname);

    if (*handle_out)
    {
        LOGD("Already loaded '%s'", libname);
        return true;
    }

    JavaVM* vm;
    if (env->GetJavaVM(&vm) < 0)
    {
        env->FatalError("Unable to retrieve Java VM");
        return false;
    }

    char path[2048];
    snprintf(path, sizeof(path)-1, "%s/%s", libdir, libname);
    LOGD("Path '%s'", path);
    void* handle = dlopen(path, RTLD_LAZY);
    if (!handle)
    {
        char errorStr[1024];
        snprintf(errorStr, sizeof(errorStr), "Unable to load library: %s [%s]", path, dlerror());
        env->FatalError(errorStr);
        return false;
    }

    typedef jint (*JNI_OnLoad_Func)(JavaVM* vm, void* reserved);
    JNI_OnLoad_Func OnLoad = (JNI_OnLoad_Func)dlsym(handle, "JNI_OnLoad");
    if (OnLoad)
    {
        if (OnLoad(vm, 0) > JNI_VERSION_1_6)
        {
            // we should throw an exception here...
            env->FatalError("Unsupported VM version");
            return false;
        }
    }

    if (handle_out)
        *handle_out = handle;

    return true;
}

其实同Android加载So的流程一样，最后也是通过dlopen这一系列的函数进行加载So的。当然，也不可能不一样。

四、讲讲Unity热更So的实现思路吧

4.1 Android的热更可以通过两种方法

1）使用System.load方法去读取自己目录的绝对路径的So
2）使用System.loadLibrary方法读取So的名称，通过修改java.library.path的路径实现热更。

4.2 Unity 热更So

1）存在明显的入口loadNative，可以通过在这里添加自己的目录进行热更，然后重新编译出classes.jar放到自己的项目中去。

具体的代码就不贴了，因为源码已经讲的蛮清楚了，如果能够拿到Unity的源码，是可以对Unity的原生So进行改动和热更的。当然，如果只是想热更第三方的一些So的话，和4.1中讲的Android热更就是一个套路了。

杨光（atany）原创，转载请注明博主与博文链接，未经博主允许，禁止任何商业用途。
博文地址：http://blog.csdn.net/yang8456211/article/details/78572362
博客地址：http://blog.csdn.net/yang8456211
本文遵循“署名-非商业用途-保持一致”创作公用协议