【第22期】观点:IT 行业加班,到底有没有价值?

Android热修复分析

原创 2016年06月01日 10:08:23

针对app线上修复技术,目前有好几种解决方案,开源界往往一个方案会有好几种实现。重复的实现会有造轮子之嫌,但分析解决方案在技术上的探索和衍变,这轮子还是值得去推动的

关于Hot Fix技术

Hot Fix技术,简单来说就是针对线上已发布app出现了bug,在不推送新版本的情况下通过发布修复补丁进行修复。通常是刚上线的app,需要快速线上修复bug,类似的技术就叫做热修复或热补丁。

现在有两种热修复解决方案:

1、JNI Hook方式解决方案 : c++动态修改方法指针,安装补丁后立刻生效;

2、classloader类加载极致:程序启动过程加载,安装补丁之后需要重新启动才能生效;

热修复技术能带来什么

  • 让app具有了上线后被修复的可能性,增加事故风险可控性;
  • 避免为修复bug而快速增发新版本,让用户“无感”,提升体验;
  • 推送新版本app修复时,用户升级覆盖面无法保证;
  • 避免增发修复版本的复杂流程,减少发布新版本app成本;

现有的技术方案

目前,从技术解决方案上来说,有以下几种思路: 

Dexposed :JNI Hook

来自阿里手淘团队,白衣(花名)基于Xposed实现了Dexposed,在此基础上手淘团队推出了HotPatch二方库。 
AndFix :JNI Hook
出自阿里支付宝技术团队,同样是对方法的hook,但未基于Dexposed去实现,避免了在art上运行时存在兼容性问题。 
基于ClassLoader 
QQ空间终端开发团队提供了技术思路,目前基于此实现的热门的开源项目有Nuwa,HotFix,DroidFix,这三种方案的原理却徊然不同,各有优缺点。

关于三者技术的介绍,这里推荐一篇文章:各大热补丁方案分析和比较,这里不做细说。

技术调研

热修复 == 动态替换 == 动态加载

得出上面的等式,是因为热修复一般来说就是增发patch文件,避免用户调用错误代码,并不是直接修改了原来的代码。这相当于是对问题文件做了动态替换,而要实现动态替换就是避免默认的加载,改变成动态地加载替换文件。 
动态加载的基础是ClassLoader,Java程序在运行时加载对应的类是通过ClassLoader来实现的, Java 类可以被动态加载到 Java 虚拟机中并执行。所以ClassLoader所做的工作实质就是把类文件从硬盘读取到内存中。 

Java中ClassLoader的基本概念

类加载器的树状结构:在JVM中,所有类加载器实例按树状结构组织,根结点为引导类加载器。除根结点外的所有类加载器都有一个非空的父类加载器,从而构成树状结构; 
双亲委托(代理)模型:当类加载器收到加载类或资源的请求时,通常都是先委托给父类加载器加载,也就是说只有当父类加载器找不到指定类或资源时,自身才会执行实际的类加载过程;

代理模式是为了保证 Java 核心库的类型安全。通过代理模式,对于 Java 核心库的类的加载工作由bootClassLoader来统一完成,保证了 Java 应用所使用的都是同一个版本的 Java 核心库的类,是互相兼容的。

  • 类的判等:即使类完全相同(名称相同、字节码相同),不同类加载器实例加载的类对象也是不相等的;

    这条规则是Java类加载机制中非常核心的规则,它保证了类加载机制实现“类隔离”、“保护JDK中的基础类”等目标。

  • 类的垃圾回收:只有当类加载器可被作为垃圾回收的前提下,其加载的类才有可能被回收;

源码分析ClassLoader机制

Android的classLoader机制

Android的Dalvik/ART虚拟机如同标准JAVA的JVM虚拟机一样,在运行程序时首先需要将对应的类加载到内存中。因此可以利用这一点,在程序运行时手动加载Class,从而达到代码中动态加载可执行文件的目的。

在Android系统启动的时候会创建一个Boot类型的ClassLoader实例,用于加载一些系统Framework层级需要的类。由于Android应用里也需要用到一些系统的类,所以APP启动的时候也会把这个Boot类型的ClassLoader传进来。

此外,APP也有自己的类,这些类保存在APK的dex文件里面,所以APP启动的时候,也会创建一个自己的ClassLoader实例,用于加载自己dex文件中的类。 
下面实际验证看看:

 @Override
 protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);

      ClassLoader classLoader = getClassLoader();
      Log.i("ClassLoader" , "classLoader " + classLoader.toString());

      while (classLoader.getParent() != null) {
          classLoader = classLoader.getParent();
          if (classLoader != null) {
              Log.i("ClassLoader", "classLoaderParent " + classLoader.toString());
          }
     }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

输出结果为:

I/ClassLoader: classLoader dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.sunteng.classloader-1/base.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]]
I/ClassLoader: classLoaderParent java.lang.BootClassLoader@2d0a3af7
  • 1
  • 2

可以看见有2个Classloader实例,一个是BootClassLoader(系统启动的时候创建的),另一个是PathClassLoader(应用启动时创建的,用于加载当前已安装app里面的类)。

Android经常使用的是PathClassLoader和DexClassLoader

  • PathClassLoader 

    官方注释:一个简单的ClassLoader的实现,工作在本地文件系统中的文件和目录的列表上,但不尝试从网络加载类。 Android使用这个类为它的系统类加载器和应用类加载器。


可以看出,Android是使用这个类作为其系统类和应用类的加载器。并且对于这个类呢,只能去加载已经安装到Android系统中的apk文件。
  • DexClassLoader 

    官方注释:一个ClassLoader的实现,从.jar和.apk文件内部加载classes.dex。这可以用于执行非安装程序作为已安装应用程序的一部分的代码。


也就是说可以加载比如sd目录下的dex文件,获取到不是已安装app里面的类。 Android中使用PathClassLoader类作为Android的默认的类加载器,PathClassLoade本身继承自BaseDexClassLoader,BaseDexClassLoader重写了findClass方法,该方法是ClassLoader的核心。
#BaseDexClassLoader
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
    List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
    Class c = pathList.findClass(name, suppressedExceptions);
    if (c == null) {
        ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);
        for (Throwable t : suppressedExceptions) {
            cnfe.addSuppressed(t);
        }
        throw cnfe;
    }
    return c;
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
看源码可知,BaseDexClassLoader将findClass方法委托给了pathList对象的findClass方法,pathList对象是在BaseDexClassLoader的构造函数中new出来的,它的类型是DexPathList。看下DexPathList.findClass源码是如何做的:
#DexPathList
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;
}

#DexFile 
public Class loadClassBinaryName(String name, ClassLoader loader) {
    return defineClass(name, loader, mCookie);
}
private native static Class defineClass(String name, ClassLoader loader, int cookie);
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
直接就是遍历dexElements列表,然后通过调用element.dexFile对象上的loadClassBinaryName方法来加载类,如果返回值不是null,就表示加载类成功,会将这个Class对象返回。而且dexElements对象是在DexPathList类的构造函数中完成初始化的。
this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory, suppressedExceptions);
  • 1
makeDexElements所做的事情就是遍历我们传递来的dexPath,然后一次加载每个dex文件。可以看出,BaseDexClassLoader中有个pathList对象,pathList中包含一个DexFile的集合dexElements,而对于类加载,就是遍历这个集合,通过DexFile去寻找。 这样的话,我们可以在这个dexElements中去做一些事情,比如在这个数组的第一个元素放置我们的patch.jar,里面包含修复过的类。当遍历findClass的时候,修复的类就会被查找到,从而替代有bug的类。

一个ClassLoader可以包含多个dex文件,每个dex文件是一个Element,多个dex文件排列成一个有序的数组dexElements,当找类的时候,会按顺序遍历dex文件,然后从当前遍历的dex文件中找类,如果找类则返回,如果找不到从下一个dex文件继续查找

标准JVM中,ClassLoader是用defineClass加载类的,而Android中defineClass被弃用了,改用了loadClass方法,而且加载类的过程也挪到了DexFile中,在DexFile中加载类的具体方法也叫defineClass

ClassLoader特性

使用ClassLoader的一个特点就是,当ClassLoader在成功加载某个类之后,会把得到类的实例缓存起来。下次再请求加载该类的时候,ClassLoader会直接使用缓存的类的实例,而不会尝试再次加载。也就是说,如果程序不重新启动,加载过一次的类就无法重新加载。

如果使用ClassLoader来动态升级APP或者动态修复BUG,都需要重新启动APP才能生效。

除了使用ClassLoader外,还可以使用jni hook的方式修改程序的执行代码。后者做的已经是Native层级的工作了,直接修改应用运行时的内存地址,所以使用jni hook的方式时,不用重新应用就能生效。 而阿里的dexposed和AndFix采用了jni hook方案 **Android程序比起一般Java程序在使用动态加载时麻烦在哪里** 使用ClassLoader动态加载一个外部的类是非常容易的事情,所以很容易就能实现动态加载新的可执行代码的功能,但是比起一般的Java程序,在Android程序中使用动态加载主要有两个麻烦的问题: * Android中许多组件类(如Activity、Service等)是需要在Manifest文件里面注册后才能工作的(系统会检查该组件有没有注册),所以即使动态加载了一个新的组件类进来,没有注册的话还是无法工作; * Res资源是Android开发中经常用到的,而Android是把这些资源用对应的R.id注册好,运行时通过这些ID从Resource实例中获取对应的资源。如果是运行时动态加载进来的新类,那类里面用到R.id的地方将会抛出找不到资源或者用错资源的异常,因为新类的资源ID根本和现有的Resource实例中保存的资源ID对不上; 说到底,一个Android程序和标准的Java程序最大的区别就在于他们的上下文环境(Context)不同。

Android中context可以给程序提供组件需要用到的功能,也可以提供一些主题、Res等资源,而现在的各种Android动态加载框架中,核心要解决的东西也正是如何给外部的新类提供上下文环境的问题。

希望最终的效果

能够简单地集成热修复sdk,开发者修改代码后能轻松地完成向用户发Patch操作,在用户无感知的情况下修复bug。

技术选型

  • 对开发者友好,使用热修复要简单直接,能尽快解决问题;
  • 对用户友好,尽量减少用户感知;
  • 减小bug的影响,尽量扩大修复时覆盖的用户范围。

就一个理念:只有适合当前情况的才是最好的。

插件化和热修复

前面关于Android中ClassLoader的介绍,Android使用PathClassLoader作为其类加载器,DexClassLoader可以从.jar和.apk类型的文件内部加载classes.dex文件。

如果大家对于插件化有所了解,其实Android应用的插件化,就可以利用DexClassLoader来动态加载非安装应用的类来实现,当然也就可以做到只有单用户点击相应插件模块,才会从网络获取相应插件文件,再通过DexClassLoader实现类加载。

而热修复可以利用BaseDexClassLoader中的pathList对象,pathList中包含一个DexFile的集合dexElements,我们可以在这个dexElements中去做一些事情,比如在这个数组的第一个元素放置我们的patch.jar,里面包含修复过的类。

这样的话,当遍历findClass的时候,我们修复的类就会被查找到,从而替代有bug的类。不过这样处理还存在一个CLASS_ISPREVERIFIED的问题安卓App热补丁动态修复技术介绍

热修复具体实施

上面分析了Android中的类的加载的流程,可以看出: 
* DexPathList对象中的dexElements列表是类加载的一个核心,一个类如果能被成功加载,那么它的dex一定会出现在dexElements所对应的dex文件中。 
* exElements中出现的顺序也很重要,在dexElements前面出现的dex会被优先加载,一旦Class被加载成功,就会立即返回。 
* 我们的如果想做hot fix,一定要保证我们的pacth dex文件出现在dexElements列表的前面。

要实现热修复,就需要我们在运行时去更改PathClassLoader.pathList.dexElements,由于这些属性都是private的,因此需要通过反射来修改。

另外,构造我们自己的dex文件所对应的dexElements数组的时候,我们也可以采取一个比较取巧的方式: 
* 通过构造一个DexClassLoader对象来加载我们的dex文件 
* 调用一次dexClassLoader.loadClass(dummyClassName)方法 
* 这样dexClassLoader.pathList.dexElements中就会包含我们的dex

通过把dexClassLoader.pathList.dexElements插入到系统默认的classLoader.pathList.dexElements列表前面,就可以让系统优先加载我们的dex中的类,从而可以实现热修复了。

自己的思考

通过分析三者的差异化对比,以及思考到底什么才是合适的,通过hook方法的方式实现起来确实最直接,但是问题却也很明显,首先成功覆盖率和稳定性是个问题,而且操作起来复杂性比较高。

而通过classloader考虑的是从系统动态加载的特性入手,所以理所当然以局限于系统的特性,比如由于对于已经加载的类,类加载器不会再调用loadClass方法,所以想要修复要等到下次启动程序才行。

Android项目中,动态加载技术按照加载的可执行文件的不同大致可以分为两种: 
1.动态加载so库; 
2.动态加载dex/jar/apk文件(通常都是这种)

所以理解起来就是: 
1.动态调用外部的Dex文件则是完全没有问题的。 
2.在APK文件中往往有一个或者多个Dex文件,我们写的每一句代码都会被编译到这些文件里面。 
3.Android应用运行的时候就是通过执行这些Dex文件完成应用的功能的。 
4.虽然一个APK一旦构建出来,我们是无法更换里面的Dex文件,但是我们可以通过加载外部的Dex文件来实现。

外部文件可以放在外部存储,或者从网络下载。

因此最极端的情况就是,直接把APK自身带有的Dex文件当做空壳,只是作为一个程序的入口,所有的功能都通过从服务器下载最新的Dex文件完成。 
当然,一般来说只要利用Android动态加载技术,通过动态加载新的dex的方式,完成对有bug类的“替换”,来达到避免调用存在bug的代码,这也就是所谓的Hot Fix。

总体的思路就是这样,至于具体的实现,就有很多环节需要细化的,因为Android本身也有很多自身的特性。

接下来就是考虑实际编码实现了。

版权声明:本文为博主原创文章,未经博主允许不得转载。 举报

相关文章推荐

Android 热补丁动态修复框架小结

转载请标明出处: http://blog.csdn.net/lmj623565791/article/details/49883661; 本文出自:【张鸿洋的博客】 一、概述最新githu...

Android 热修复其实很简单

android AndFix 热修复 动态加载

程序员升职加薪指南!还缺一个“证”!

CSDN出品,立即查看!

Java的ClassLoader加载机制

一、ClassLoader的概念 Java程序在运行的时候,JVM通过类加载机制(ClassLoader)把class文件加载到内存中,只有class文件被载入内存,才能被其他class引用,使程序正...

判断手机是否ROOT 代码实现+ Android 操作系统 获取Root权限 原理解析

判断手机是否具有ROOT限                                                    许多机友新购来的Android机器没有破解过Root权限,无...

Android学习笔记MVP模式框架

Android学习笔记MVP模式框架1.MVP模式介绍: 在上一次学习中,我简单的介绍了MVC构架,这次我来简单的介绍下什么是MVP。对于MVP,他其实就是MVC的一个演化版本,MVP全称Model...

Android-缓存网络图片(MVP模式)学习笔记

Android之缓存网络图片到内存中学习笔记访问网络图片是很普遍的事了,在前面的学习中,我也写过了几次异步网上请求网络图片,但是没有缓存图片,那么我们也都知道,有时候访问一些经常访问的网络图片,如果不...

Android 几种流行热修复方案整理

Android 热修复 Dexposed 基于Xposed的AOP框架,方法级粒度,可以进行AOP编程、插桩、热补丁、SDK hook等功能。 Xposed需要Root权限,是因为它...

从零开始搭建一个完善的MVP开发框架(五),通过组件化开发优化项目的结构

摘要: 在第三篇文章有位朋友留言说:如果接口的数量有一百个,那么是不是需要写一百个Presenter?答案是不一定的,因为这个问题需要根据实际的业务需求来解决。但是这种一个接口对应一个Presente...

关于 Android 程序员最近的状况

大家都知道,今年移动开发不那么火热了,完全没有了前两年Android开发那种火热的势头,如此同时,AI热火朝天,很多言论都说Android不行了。其实不光是Android,iOS也有类似的言论。 那...

Android 热补丁技术——资源的热修复

今年真是热补丁框架的洪荒之力爆发的一年,短短时间内,已经出现了好几个热修复的框架了,基本上都是大同小异,这里我就不过多的去评论这些框架。只有自己真正的去经历过,你才会发现其中的坑。事实上,现在出现的大...
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)