[Android Pro] so 动态加载—解决sdk过大问题

原文地址:　https://blog.csdn.net/Rong_L/article/details/75212472

前言

相信Android 开发中大家或多或少都会集成一些第三方sdk, 而其中难免要会使用到他们的so文件。但有时，你会发现这些so文件过多，对于一些需要经常更新的应用来说，这将会大大浪费用户的流量。而有些sdk的集成仅仅是只为了一个不是必须的功能，我们完全有充足的理由用一些技术的手段来解决因这部分sdk集成带来的安装包大小问题。

so目录

观察发现，很多sdk的大小主要集中在so文件上。为了尽可能多的适应不同cup，sdk通常会提供不同二进制文件，这些文件被分门别类地放在armeabi,x86,mips等目录下。这里我们有必要了解下这些目录的含义。

目录 cpu类型
armeabi ARM 通用cpu
armeabi-v7a 支持浮点运算ARM cpu，向下兼容armeabi
arm64-v8a ARM 64位cpu, 向下兼容armeabi-v7a
x86 x86通用型cpu
x86_64 x86 64位cpu
不同cpu在apk应用安装时，会查找对应的目录，比如，arm64位机子，会优先查看apk中是否有arm64-v8a目录，如果有，则采用该目录下的so文件，如果没有，则会查找兼容的目录。一旦确定下目录之后，其他的目录便不会再去管了。（日后如果在确定的目录下没有找到对应的so文件，也不会去其他目录中找到）

目前市面上大部分手机都兼容armeabi-v7a，哪怕x86的cpu也会兼容（性能会有损耗）。所以armeabi-v7a目录建议一定配置，其相比armeabi在性能上有很大的提升。

动态加载so

再次回到前言中的问题，我们有没有什么办法能够减少so的大小，从而减少apk安装包的大小呢？
1. 如果不太在意性能的损耗，那么我们完全可以只适配armeabi-v7a包和x86包，让64位机器运行32位的so文件。
2. 单独出arm版本和x86版本，这样也可以减少一半的so大小。

可如果你觉得这样包还是太大，比如我们现在用的crosswalk浏览器内核，单个so文件就达到了27M,同时适配x86的话，会达到58M, 这是我们所无法接受的事情！

于是乎开始想有没有什么办法能把so文件与apk文件分离开来，在程序运行的时候来把so文件下载下来，并引导程序去加载。从而实现动态加载so文件的目的。

System.load 与 System.loadLibrary

google出的结果直接导向了System.load和System.loadLibrary这两个方法。
system.load 参数中加载的so的路径，比如：system.load(“/data/data/com.codemao.android/libs/libcrosswalk.so”)
system.loadLibrary参数中传入的是so的名称，比如system.loadLibrary(“crosswalk”), 系统会自动根据名称与机器的cpu型号，找到对应的so目录，并加载对应的lib crosswalk.so文件。
（两者文件都只能在app的私有目录下）

那这样子的话，是不是我们从远程下载完so文件之后，解压到app私有目录下，在调用sdk的地方调用system.load主动加载so之后，就可以实现动态加载so文件了呢？

同学，你真是太天真啦！我们回想下自己写的so文件是如何调用的？是不是在需要使用的类里主动调了system.loadLibrary呢？sdk也一样，sdk在自己的代码里主动调用了system.loadLibrary。而这时，我们so文件因为没有随着apk安装到手机上，并不在它的寻找范围之内，最后的结果是你即使调用了system.load加载了so文件，理论是可以找到相应的native方法了，但是sdk在调用system.loadLibrary时会抛出找不到对应的so文件的错误。

插件化如何处理so

这该如何处理sdk内部调用loadLibrary抛出的异常信息呢？apk内的so文件最终被放到了/data/app/com.codemao.android/lib/下面，我们总不能把远程下载下来的so文件放入这里吧，可/data/app这个目录下面的文件我们是没有权限去执行读写操作的。

这里我们想到了另一个问题，插件化可以运行另一个apk，而apk里面难免会有so,那宿主程序又是如何处理插件的so文件呢？
查询之后发现:原文地址

有时候我们在开发插件的时候，可能会调用so文件，一般来说有两种方案:
一种是在加载插件的时候，先把插件中的so文件释放到本地目录，然后在把目录设置到DexClassLoader类加载器的nativeLib中。
一种在插件初始化的时候，释放插件中的so文件到本地目录，然后使用System.load方法去全路径加载so文件
这两种方式的区别在于，
第一种方式的代码逻辑放在了宿主工程中，同时so文件可以放在插件的任意目录中，然后在解压插件文件找到这个so文件释放即可。
第二种方式的代码逻辑是放在了插件中，同时so文件只能放在插件的assets目录中，然后通过把插件文件设置到程序的AssetManager中，最后通过访问assets中的so文件进行释放。

我们自己apk使用的classloader是pathclassloader, 那我们是不是只要把so所在的目录加入到pathclassloader的nativeLib之中就好了呢？ 
让我们再次来看下system.loadLibrary:

public static void loadLibrary(String libname) {  
    Runtime.getRuntime().loadLibrary0(VMStack.getCallingClassLoader(), libname);  
} 

Runtime.java

synchronized void loadLibrary0(ClassLoader loader, String libname) {  
    if (libname.indexOf((int)File.separatorChar) != -1) {  
        throw new UnsatisfiedLinkError(  
"Directory separator should not appear in library name: " + libname);  
    }  
    String libraryName = libname;  
    //loader这里传入的是pathclassloader, 不为空
    if (loader != null) {  
        //调用findLibrary找到so路径
        String filename = loader.findLibrary(libraryName);  
        if (filename == null) {    
            throw new UnsatisfiedLinkError(loader + " couldn't find "" +  
                                           System.mapLibraryName(libraryName) + """);  
        }  
        //调用doLoad加载找到的so文件
        String error = doLoad(filename, loader);  
        if (error != null) {  
            throw new UnsatisfiedLinkError(error);  
        }  
        return;  
    }
    ...//以下逻辑我们可以暂且忽略
    }

好的，这里我们看到加载的过程主要两步： 
1. 调用pathclassloader.findLibrary,先找到对应的so文件 
2. 调用doLoad加入找到的so文件

那我们来看下classloader.findLibrary是如何找到对应so文件的：

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

pathList 是BaseDexClassLoader 里的DexPathList对象(注意6.0 开始nativeLibraryDirectories放的不在是File, 不过加载逻辑是一样的, 要注意适配。)

public String findLibrary(String libraryName) {
        String fileName = System.mapLibraryName(libraryName);
        for (File directory : nativeLibraryDirectories) {
            File file = new File(directory, fileName);
            if (file.exists() && file.isFile() && file.canRead()) {
                return file.getPath();
            }
        }
        return null;
    }

这里主要做的事：
1. 调用system.mapLibraryName, 补全名称， 如比libraryName=crosswalk, 补全之后会是lib crosswalk.so
2. 遍历nativeLibraryDirectories，看下目录下面有对应的文件吗

哈哈，到这里，机会来了，我们只要把远程下载so的目录通过反射的方式放入nativeLibraryDirectories中就ok啦，真是太激动啦！！！

适配与实现方案

为了尽量减少性能损耗，我们先根据cpu的类型确定自己要下载的so文件，之后再用反射的方式把so的目录加入到classloader中，这样便可以解决so过大而引起apk包过大的问题。

但我们前面说过，6.0之后的DexPathList与6.0之前的DexPathList不一样,这里要注意适配的问题，

6.0之后findLibrary 变为了：

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

6.0和之前的:

public String findLibrary(String libraryName) {
        String fileName = System.mapLibraryName(libraryName);
        for (File directory : nativeLibraryDirectories) {
            File file = new File(directory, fileName);
            if (file.exists() && file.isFile() && file.canRead()) {
                return file.getPath();
            }
        }
        return null;
    }

Element 中的代码如下：

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

所以我这里直接给出适配好的关键代码，供大家参考

/**
* 将 so所在的目录放入PathClassLoader里的nativeLibraryDirectories中
*
* @param context
*/
public void installSoDir(Context context) {

    //安卓4.0以下不维护
    if(Build.VERSION.SDK_INT < Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
        return ;
    }
    File soDirFile = context.getDir(soDir, Context.MODE_PRIVATE);
    if(!soDirFile.exists()) {
        soDirFile.mkdirs();
    }
    if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
        v23Install(soDirFile, context);
    } else {
        v14Install(soDirFile, context);
    }
}

private void v14Install(File soDirFile, Context context) {
        PathClassLoader pathClassLoader = (PathClassLoader) context.getClassLoader();
        Object pathList = getPathList(pathClassLoader);
        if(pathList != null) {
            //获取当前类的属性
            try {
                Field nativeLibraryDirectoriesField = pathList.getClass().getDeclaredField("nativeLibraryDirectories");
                nativeLibraryDirectoriesField.setAccessible(true);
                Object list = nativeLibraryDirectoriesField.get(pathList);
                if(list instanceof List) {
                    ((List) list).add(soDirFile);
                } else if(list instanceof File[]) {
                    File[] newList = new File[((File[]) list).length + 1];
                    System.arraycopy(list, 0 , newList, 0, ((File[]) list).length);
                    newList[((File[]) list).length] = soDirFile;
                    nativeLibraryDirectoriesField.set(pathList, newList);
                }
            } catch (NoSuchFieldException e) {
                e.printStackTrace();
            } catch (IllegalAccessException e) {
                e.printStackTrace();
            }
        }
    }

private void v23Install(File soDirFile, Context context) {
        PathClassLoader pathClassLoader = (PathClassLoader) context.getClassLoader();
        Object pathList = getPathList(pathClassLoader);
        if(pathList != null) {
            //获取当前类的属性
            try {
                Field nativeLibraryPathField = pathList.getClass().getDeclaredField("nativeLibraryPathElements");
                nativeLibraryPathField.setAccessible(true);
                Object list = nativeLibraryPathField.get(pathList);
                Class<?> elementType = nativeLibraryPathField.getType().getComponentType();
                Constructor<?> constructor = elementType.getConstructor(File.class, boolean.class, File.class, DexFile.class);
                constructor.setAccessible(true);
                Object element = constructor.newInstance(soDirFile, true, null, null);
                if(list instanceof List) {
                    ((List) list).add(element);
                } else if(list instanceof Object[]) {
                    Object[] newList = new File[((Object[]) list).length + 1];
                    System.arraycopy(list, 0 , newList, 0, ((Object[]) list).length);
                    newList[((Object[]) list).length] = element;
                    nativeLibraryPathField.set(pathList, newList);
                }
            } catch (NoSuchFieldException e) {
                e.printStackTrace();
            } catch (IllegalAccessException e) {
                e.printStackTrace();
            } catch (NoSuchMethodException e) {
                e.printStackTrace();
            } catch (InstantiationException e) {
                e.printStackTrace();
            } catch (InvocationTargetException e) {
                e.printStackTrace();
            }
        }
    }
private Object getPathList(Object classLoader) {
        Class cls = null;
        String pathListName = "pathList";
        try {
            cls = Class.forName("dalvik.system.BaseDexClassLoader");
            Field declaredField = cls.getDeclaredField(pathListName);
            declaredField.setAccessible(true);
            return declaredField.get(classLoader);
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
        return null;
    }

参考文章

Android中so使用知识和问题总结以及插件开发过程中加载so的方案解析
Android项目针对libs(armeabi,armeabi-v7a,x86)进行平台兼容
Android JNI之System.loadLibrary()流程