Androidso库的热更新问题

本来想写资源的热修复的，虽然方案差不多已经完成了，但是考虑到一些敏感问题，资源修复就不写了。那就来写写so的热修复，其原理和class的修复是一样的，但是so的热修复的需求并不高，就当做学习吧。

成都创新互联专注于网站建设|网站建设维护|优化|托管以及网络推广，积累了大量的网站设计与制作经验，为许多企业提供了网站定制设计服务，案例作品覆盖成都阳光房等行业。能根据企业所处的行业与销售的产品，结合品牌形象的塑造，量身制作品质网站。

首先来总结一下Android的ClassLoader方式的热更新，这种方式类的查找过程是通过BaseDexClassLoader来完成的，最终会通过成员变量DexPathList对象中的findClass方法来查找类，代码如下：

public Class findClass(String name, List<Throwable> suppressed) {
  for (Element element : dexElements) {
    DexFile dex = element.dexFile;
    if (dex != null) {
      Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
      if (clazz != null) {
        return clazz;
      }
    }
  }
  if (dexElementsSuppressedExceptions != null) {
    suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
  }
  return null;
}

只需将patch的class插入到dexElements最前面即可完成热更新，当然还需要防止类被打上校验的标记，做法就是在class中插入一段字节码引用其他dex中的类。

参考class的修复方式，我们可以在BaseDexClassLoader中找到加载so的逻辑。

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

最终也会调用DexPathList对象中的方法进行处理，其函数内容为

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

可以看到逻辑和class是类似的，首先会调用System.mapLibraryName函数获得so的名字，比如我传入的参数是Test（这个Test就是在调用System.loadLibrary(“Test”)时传入的），则这个函数的作用就是将其转换为类似libTest.so这样的名字，然后遍历nativeLibraryDirectories数组，这是一个File文件夹数组，看其文件夹下是否存在对应的so，并且是否可读，如果满足条件，则直接返回。

那么我们就可以将我们的patch的so所在目录插入到这个数组最前面即可完成so的修复。具体代码就不贴了，实践后得出的结论是这种方式是完全可行的，只不过Android 6.0中这部分代码逻辑发生了改变。

在Android 4.0-5.1中，只需要将文件夹目录插入到nativeLibraryDirectories数组最前面即可，这个过程直接使用反射插入patch的so所在目录到数组最前面。

/** List of native library directories. */
private final File[] nativeLibraryDirectories;

但是在Android 6.0中，查找逻辑转为了Elements查找

/** List of native library path elements. */
private final Element[] nativeLibraryPathElements;
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中需要将so的patch目录转换为Element对象，插入到nativeLibraryPathElements最前面，Element的对象可以直接用反射去实现下面的代码进行构造即可。

//伪代码,类不可见，需要用反射
Element e=new Element(fileDir, true, null, null)

当然你也可以直接反射调用makePathElements方法创建Element数组。

最后的难点就是如何将对应cpu类型的so拿到，这个过程还是十分复杂的，比如说一个so同时存在x86,armeabi-v7a,armeabi的patch，而手机cpu是armeabi-v7a的，这时候就应该加载armeabi-v7a的so。总之这种情况组合起来会十分复杂了。

手机的cpu结构类型可以通过Build.CPU_ABI和Build.CPU_ABI2拿到，后面做的事就是根据这两个值去加载对应目录下的so，其实把这两个目录都插进去就没问题了。

总结

以上所述是小编给大家介绍的Android so库的热更新问题，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对创新互联网站的支持！

名称栏目：Androidso库的热更新问题
URL标题：https://www.cdcxhl.com/article12/pdgsgc.html

成都网站建设公司_创新互联，为您提供小程序开发、电子商务、商城网站、营销型网站建设、外贸建站、全网营销推广

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容