Android热修复技术——Tinker方案解析

相关阅读：

吊炸天！74款APP完整源码！

最全Android学习路线总结，绝对干货

Android-6步教会你自定义View，自定义View就是这么简单

一

摘要： 传统的app开发模式下，线上出现bug，必须通过发布新版本，用户手动更新后才能修复线上bug。那么是否存在一种方案可以在不发版的前提下修复线上bug？有！而且不只一种。今天首先来看下腾讯的Tinker方案

传统的app开发模式下，线上出现bug，必须通过发布新版本，用户手动更新后才能修复线上bug。随着app的业务越来越复杂，代码量爆发式增长，出现bug的机率也随之上升。如果单纯靠发版修复线上bug，其较长的新版覆盖期无疑会对业务造成巨大的伤害，更不要说大型app开发通常涉及多个团队协作，发版排期必须多方协调。

那么是否存在一种方案可以在不发版的前提下修复线上bug？有！而且不只一种，业界各家大厂都针对这一问题拿出了自家的解决方案，较为著名的有腾讯的Tinker和阿里的Andfix。网上对上述方案有很多介绍性文章，不过大多不全面，中间略过很多细节。笔者在学习的过程中也遇到很多麻烦。所以笔者将通过接下来几篇博客对上述两种方案进行介绍，力求不放过每一个细节。首先来看下Tinker方案。

1. Dex分包机制

大家都知道，我们开发的代码在被编译成class文件后会被打包成一个dex文件。但是dex文件有一个限制，由于方法id是一个short类型，所以导致了一个dex文件最多只能存放65536个方法。随着现今App的开发日益复杂，导致方法数早已超过了这个上限。为了解决这个问题，Google提出了multidex方案，即一个apk文件可以包含多个dex文件。

不过值得注意的是，除了第一个dex文件以外，其他的dex文件都是以资源的形式被加载的，换句话说就是在Application.onCreate()方法中被注入到系统的ClassLoader中的。这也就为热修复提供了一种可能：将修复后的代码达成补丁包，然后发送到客户端，客户端在启动的时候到指定路径下加载对应dex文件即可。

根据Android虚拟机的类加载机制，同一个类只会被加载一次，所以要让修复后的类替换原有的类就必须让补丁包的类被优先加载。接下来看下Android虚拟机的类加载机制。

2. 类加载机制

Android的类加载机制和jvm加载机制类似，都是通过ClassLoader来完成，只是具体的类不同而已：

Android系统通过PathClassLoader来加载系统类和主dex中的类。而DexClassLoader则用于加载其他dex文件中的类。上述两个类都是继承自BaseDexClassLoader，具体的加载方法是findClass:

public class BaseDexClassLoader extends ClassLoader {    
        private final DexPathList pathList;    
     /**
     * Constructs an instance.
     *
     * @param dexPath the list of jar/apk files containing classes and
     * resources, delimited by {@code File.pathSeparator}, which
     * defaults to {@code ":"} on Android
     * @param optimizedDirectory directory where optimized dex files
     * should be written; may be {@code null}
     * @param libraryPath the list of directories containing native
     * libraries, delimited by {@code File.pathSeparator}; may be
     * {@code null}
     * @param parent the parent class loader
     */
    public BaseDexClassLoader(String dexPath, File optimizedDirectory,
            String libraryPath, ClassLoader parent) {        
         super(parent);        
         this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
    }   
          
    @Override
    protected Class> findClass(String name) throws ClassNotFoundException {
        List suppressedExceptions = new ArrayList();
        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;
    }
}

从代码中可以看到加载类的工作转移到了pathList中，pathList是一个DexPathList类型，从变量名和类型名就可以看出这是一个维护Dex的容器：

/*package*/ final class DexPathList {    
    private static final String DEX_SUFFIX = ".dex";    
    private static final String JAR_SUFFIX = ".jar";    
    private static final String ZIP_SUFFIX = ".zip";    
    private static final String APK_SUFFIX = ".apk";    
    /** class definition context */
    private final ClassLoader definingContext;    
    /**
     * List of dex/resource (class path) elements.
     * Should be called pathElements, but the Facebook app uses reflection
     * to modify 'dexElements' (http://b/7726934).
     */
    private final Element[] dexElements;    
    /**
     * Finds the named class in one of the dex files pointed at by
     * this instance. This will find the one in the earliest listed
     * path element. If the class is found but has not yet been
     * defined, then this method will define it in the defining
     * context that this instance was constructed with.
     *
     * @param name of class to find
     * @param suppressed exceptions encountered whilst finding the class
     * @return the named class or {@code null} if the class is not
     * found in any of the dex files
     */
    public Class findClass(String name, List 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;
    }
}




    

DexPathList的findClass也很简单，dexElements是维护dex文件的数组，每一个item对应一个dex文件。DexPathList遍历dexElements，从每一个dex文件中查找目标类，在找到后即返回并停止遍历。所以要想达到热修复的目的就必须让补丁dex在dexElements中的位置先于原有dex：

这就是Tinker方案的基本思路，接下来的博文笔者将以一个实际的例子详述Tinker热修复的过程

二

摘要： Android热修复Tinker方案实战篇。本篇博客我们将介绍1）如何打包补丁包； 2）如何将通过ClassLoader加载补丁包；3）如何将补丁包的dex插入到`dexElements`的前面

接下来我会用一个真实的demo来介绍如何实现热修复。具体的内容包括：

• 如何打包补丁包

• 如何将通过ClassLoader加载补丁包

1. 创建Demo

demo很简单，创建一个只有一个Activity的demo：

package com.biyan.demo
public class MainActivity extends Activity {    
    private Calculator mCal;    @Override
    protected void onCreate(Bundle savedInstanceState) {        
    super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mCal = new Calculator();
    }
    
    public void click(View view) {        
        Toast.makeText(this, String.valueOf(mCal.calculate()),Toast.LENGTH_SHORT).show();
    }
}

Public class Caculoator {    
    public float calculate() {        
        return 1 / 0;
    }
}

demo的代码很简单，运行会出什么bug也很清楚了，在此就不演示了。

2.创建补丁包

首先修复Calculator的bug。

package com.biyan.demo
Public class Caculoator {    
    public float calculate() {        
        return 1 / 1;
    }
}

重新编译项目，在build目录下找到Calculator.class文件,将其拷出来，准备打包。放置在于Calculator包名相同的路径下。

将其打成jar包：

jar -cvf patch.jar com

然后再将对应的jar包打成dex包：

dx --dex --output=patch_dex.jar patch.jar

dx是讲jar包打成dex包的工具，安装在path-android-sdk/build-tools/version(如24.0.0)/dx。

patch_dex.jar就是补丁包，接下来将其安装在sdCard中，接下来应用从sdCard上加载该补丁包。

3. 加载补丁

根据上一篇博客的介绍，加载补丁的思路如下：

• 在Application的onCreate()方法中获取应用本身的BaseDexClassLoader,然后通过反射得到对应的dexElements

• 创建一个新的DexClassLoader实例，然后加载sdCard上的补丁包，然后通过同样的方法得到对应的dexElements

• 将两个dexElements合并，然后再利用反射将合并后的dexElements赋值给应用本身的BaseDexClassLoader

接下来看下具体代码：

package com.hotpatch.demo;
import android.app.Application;
import android.os.Environment;
import android.util.Log;
import java.io.File;
import java.lang.reflect.Array;
import java.lang.reflect.Field;
import dalvik.system.DexClassLoader;
/**
 * Created by hp on 2016/4/6.
 */

public class HotPatchApplication extends Application {

    @Override    
    public void onCreate() {        
        super.onCreate();        // 获取补丁，如果存在就执行注入操作
        String dexPath = Environment.getExternalStorageDirectory().getAbsolutePath().concat("/patch_dex.jar");
        File file = new File(dexPath);        
        if (file.exists()) {
            inject(dexPath);
        } else {
            Log.e("BugFixApplication", dexPath + "不存在");
        }
    }    
    /**
     * 要注入的dex的路径
     *
     * @param path
     */
    private void inject(String path) {       
        try {            // 获取classes的dexElements
            Class> cl =Class.forName("dalvik.system.BaseDexClassLoader");            
        Object pathList = getField(cl, "pathList", getClassLoader());              Object baseElements = getField(pathList.getClass(), "dexElements", pathList);            
        // 获取patch_dex的dexElements（需要先加载dex）
        String dexopt = getDir("dexopt", 0).getAbsolutePath();
        DexClassLoader dexClassLoader = new DexClassLoader(path, dexopt, dexopt, getClassLoader());            
        Object obj = getField(cl, "pathList", dexClassLoader);            
        Object dexElements = getField(obj.getClass(), "dexElements", obj);            // 合并两个Elements
        Object combineElements = combineArray(dexElements, baseElements);            // 将合并后的Element数组重新赋值给app的classLoader
        setField(pathList.getClass(), "dexElements", pathList, combineElements);            //======== 以下是测试是否成功注入 =================
        Object object = getField(pathList.getClass(), "dexElements", pathList);            
        int length = Array.getLength(object);
        Log.e("BugFixApplication", "length = " + length);

        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
        }
    }    
    /**
     * 通过反射获取对象的属性值
     */
    private Object getField(Class> cl, String fieldName, Object object) throws NoSuchFieldException, IllegalAccessException {
        Field field = cl.getDeclaredField(fieldName);
        field.setAccessible(true);        
        return field.get(object);
    }    
    /**
     * 通过反射设置对象的属性值
     */
    private void setField(Class> cl, String fieldName, Object object, Object value) throws NoSuchFieldException, IllegalAccessException {
        Field field = cl.getDeclaredField(fieldName);
        field.setAccessible(true);
        field.set(object, value);
    }    
    /**
     * 通过反射合并两个数组
     */
    private Object combineArray(Object firstArr, Object secondArr) {              int firstLength = Array.getLength(firstArr);        
        int secondLength = Array.getLength(secondArr);        
        int length = firstLength + secondLength;

        Class> componentType = firstArr.getClass().getComponentType();          Object newArr = Array.newInstance(componentType, length);        
        for (int i = 0; i < length; i++) {           
            if (i < firstLength) {                
                    Array.set(newArr, i, Array.get(firstArr, i));
            } else {                
                    Array.set(newArr, i, Array.get(secondArr, i - firstLength));
            }
        }        
        return newArr;
    }

}

核心代码就这么多，接下来运行一下程序。程序还是Crash了。。。

原因是类预校验问题引起的：

• 在apk安装的时候系统会将dex文件优化成odex文件，在优化的过程中会涉及一个预校验的过程

• 如果一个类的static方法，private方法，override方法以及构造函数中引用了其他类，而且这些类都属于同一个dex文件，此时该类就会被打上CLASS_ISPREVERIFIED

• 如果在运行时被打上CLASS_ISPREVERIFIED的类引用了其他dex的类，就会报错

• 所以MainActivity的onCreate()方法中引用另一个dex的类就会出现上文中的问题

• 正常的分包方案会保证相关类被打入同一个dex文件

• 想要使得patch可以被正常加载，就必须保证类不会被打上CLASS_ISPREVERIFIED标记。而要实现这个目的就必须要在分完包后的class中植入对其他dex文件中类的引用

• 要在已经编译完成后的类中植入对其他类的引用，就需要操作字节码，惯用的方案是插桩。常见的工具有javaassist，asm等。

其实Tinker方案的关键就在于字节码的注入而不是dex的注入。下一篇博客将会介绍字节码注入的相关细节。

三

摘要： 要想实现热更新的目的，就必须在dex分包完成之后操作字节码文件。比较常用的字节码操作工具有ASM和javaassist。另外还需要在Gradle的构建过程中完成插桩的操作

如前文所述，要想实现热更新的目的，就必须在dex分包完成之后操作字节码文件。比较常用的字节码操作工具有ASM和javaassist。相比之下ASM提供一系列字节码指令，效率更高但是要求使用者对字节码操作有一定了解。而javaassist虽然效率差一些但是使用门槛较低，本文选择使用javaassist。关于javaassist可以参考Java 编程的动态性， 第四部分: 用 Javassist 进行类转换

正常App开发过程中，编译，打包过程都是Android Studio自动完成。如无特殊需求无需人为干预，但是要实现插桩就必须在Android Studio的自动化打包流程中加入插桩的过程。

1. Gradle,Task,Transform,Plugin

Android Studio采用Gradle作为构建工具，所有有必要了解一下Gradle构建的基本概念和流程。如果不熟悉可以参考一下下列文章：

• Gradle学习系列之一——Gradle快速入门

• 深入理解Android之Gradle

Gradle的构建工程实质上是通过一系列的Task完成的，所以在构建apk的过程中就存在一个打包dex的任务。Gradle 1.5以上版本提供了一个新的API：Transform，官方文档对于Transform的描述是：

The goal of this API is to simplify injecting custom class manipulations without having to deal with tasks, and to offer more flexibility on what is manipulated. The internal code processing (jacoco, progard, multi-dex) have all moved to this new mechanism already in 1.5.0-beta1.

• 1. The Dex class is gone. You cannot access it anymore through the variant API (the getter is still there for now but will throw an exception)

• 2. Transform can only be registered globally which applies them to all the variants. We'll improve this shortly.

• 3. There's no way to control ordering of the transforms.

Transform任务一经注册就会被插入到任务执行队列中，并且其恰好在dex打包task之前。所以要想实现插桩就必须创建一个Transform类的Task。

1.1 Task

Gradle的执行脚本就是由一系列的Task完成的。Task有一个重要的概念：input的output。每一个task需要有输入input，然后对input进行处理完成后在输出output。

1.2 Plugin

Gradle的另外一个重要概念就是Plugin。整个Gradle的构建体系都是有一个一个的plugin构成的，实际Gradle只是一个框架，提供了基本task和指定标准。而具体每一个task的执行逻辑都定义在一个个的plugin中。详细的概念可以参考：Writing Custom Plugins
在Android开发中我们经常使用到的plugin有："com.android.application"，"com.android.library","java"等等。

每一个Plugin包含了一系列的task，所以执行gradle脚本的过程也就是执行目标脚本所apply的plugin所包含的task。

1.3 创建一个包含Transform任务的Plugin

• 1. 新建一个module，选择library module，module名字必须叫BuildSrc

• 2. 删除module下的所有文件，除了build.gradle，清空build.gradle中的内容

• 3. 然后新建以下目录 src-main-groovy

• 4. 修改build.gradle如下，同步

• 5. 像普通module一样新建package和类，不过这里的类是以groovy结尾，新建类的时候选择file，并且以.groovy作为后缀

• 6. 自定义Plugin：

• 8.Inject.groovy, JarZipUtil.groovy

• 9. 在app module下build.gradle文件中添加新插件：  apply plugin: com.hotpatch.plugin.Register

2. 创建hack.jar

创建一个单独的module，命名为com.hotpatch.plugin.AntilazyLoad:

package com.hotpatch.plugin
public class AntilazyLoad {}

使用上一篇博客介绍的方法打包hack.jar。然后将hack.jar复制到app module下的assets目录中。另外注意：app module不能依赖hack module。之所以要创建一个hack module，同时人为地在dex打包过程中插入对其他hack.jar中类的依赖，就是要让apk文件在安装的时候不被打上CLASS_ISPREVERIFIED标记。

另外由于hack.jar位于assets中，所以必须要在加载patch_dex之前加载hack.jar。另外由于加载其他路径的dex文件都是在Application.onCreate()方法中执行的，此时还没有加载hack.jar，所以这就是为什么在上一章节插桩的时候不能在Application中插桩的原因。

插桩的过程介绍完了，整个热修复的过程也就差不多了，读者可以参考完整的代码进行demo试用：Hotpatch Demo

原文：https://yq.aliyun.com/articles/70320?utm_campaign=wenzhang&utm_medium=article&utm_source=QQ-qun&utm_content=m_10930

Java和Android大牛频道

欢迎关注我们，一起讨论技术，扫描和长按下方的二维码可快速关注我们。或搜索微信公众号:JANiubility。

公众号：JANiubility