环信李楠：美团热更新方案ASM实践

从《Android热更新方案 Robust》一文可知，美团热更新使用的是 Instant Run 的方案。本文将着重于分享美团热更新方案中没讲到的部分，包含以下几个方面：

作为云服务提供厂商，需要提供给客户 SDK，SDK 发布后同样要考虑 Bug 修复问题。此处将介绍作为 SDK 发布者的热更新方案选型，即为什么使用美团方案&Instant Run 方案。

美团方案实现的大致结构;

ASM 插桩的过程，字节码导读，以及遇到的各种坑。

方案选择

我们公司提供即时通讯服务，同时需要提供给用户方便集成的即时通讯 SDK，每次 SDK 发布的同时也面临 SDK 发布后紧急 Bug 的修复问题。现在市面上的热更新方案普遍不适用 SDK 提供方使用。以阿里的 AndFix 和微信的 Tinker 为例，都是直接修改并合成新的 Apk。这样做对于普通 App 没有问题，但是对于 SDK 提供方是不可以的，SDK 发布者不能够直接修改 Apk，这个事情只能由 App 开发者来进行。

Tinker 方案如图：

女娲(Nuwa)方案，由大众点评 Jason Ross 实现并开源，其在 classLoader 过程中，将自己的修改后的 patch 类所在的dex, 插入到 dex 队列前面，这样在 classloader 按照类名字加载的时候会优先加载 patch 类。

女娲方案如图：

Nuwa 方案有一个条件约束，就是每个类都要插桩，插入一个类的引用，并且这个被引用类需要打包到单独的 dex 文件中，这样保证每个类都没有被打上 CLASS_ISPREVERIFIED 标志。

具体详细描述在早期的 hotpatch 方案：《Android App 热补丁动态修复技术介绍》。

作为 SDK 提供者，只能提供 jar 包给用户，无法约束用户的 dex 生成过程，所以 Nuwa 方案无法直接应用。女娲方案是开源的，而且其中提供了 ASM 插桩示例，对于后面应用美团方案有很好参考意义。

美团& Instant Run 方案

美团方案也就是 Instant Run 的方案基本思路就是在每个函数都插桩，如果一个类存在 Bug，需要修复，就将插桩点类的changeRedirect 字段从 null 值变成 patch 类。基本原理在美团方案中有讲述，但是美团文中没有讲最重要的一个问题，就是如何在每一个函数前面插桩，下面会详细讲一下。Patch 应用部分，这里忽略，因为是 Java 代码，大家可以反编译 Instant Run.jar，看一下大致思路，基本都能写出来。

插桩

插桩的动作就是在每一个函数前面都插入 PatchProxy.isSupport...PatchProxy.accessDisPatch 这一系列代码(参看美团方案)。插桩工作直接修改 class 文件，因为这样不影响正常代码逻辑，只有最后打包发布的时候才进行插桩。

插桩最常用的是 asm.jar。接下来的部分需要用户先了解 asm.jar 的大致使用流程。了解这个过程最好是找个实例实践一下，光看介绍文章是看不懂的。

ASM 有两种方式解析 class 文件，一种是 core API, “provides an event based representation of classes”，类似解析 XML 的 SAX 的事件触发方式、遍历类以及类的字段，类中的方法，在遍历的过程中会依次触发相应的函数，比如遍历类函数时，触发 visitMethod(name, signature...)，用户可以在这个方法中修改函数实现。

另外一种是 tree API, “provides an object based representation”，类似解析 XML 中的 DOM 树方式。本文中，这里使用了 core API 方式。asm.jar 有对应的 manual asm4-guide.pdf，需要仔细研读，了解其用法。

使用 asm.jar 把 java class 反编译为字节码

反编译为字节码对应的命令是

java -classpath "asm-all.jar" org.jetbrains.org.objectweb.asm.util.ASMifier State.class

这个地方有一个坑，官方版本 asm.jar 在执行 ASMifier 命令的时候总是报错，后来在 Android Stuidio 的目录下面找一个 asm-all.jar 替换再执行就不出问题了。但是用 asm.jar 插桩的过程，仍然使用官方提供的 asm.jar。

插入前代码：

class State {

long getIndex(int val) { return 100;

}

}

ASMifier 反编译后字节码如下：

mv = cw.visitMethod(0, "getIndex", "(I)J", null, null);mv.visitCode();mv.visitLdcInsn(new Long(100L));mv.visitInsn(LRETURN);mv.visitMaxs(2, 2);mv.visitEnd();

插桩后代码：

long getIndex(int a) { if ($patch != null) { if (PatchProxy.isSupport(new Object[0], this, $patch, false)) { return ((Long) com.hyphenate.patch.PatchProxy.accessDispatch(new Object[] {a}, this, $patch, false)).longValue();

}

} return 100;

}

ASMifier 反编译后代码如下：

mv = cw.visitMethod(ACC_PUBLIC, "getIndex", "(I)J", null, null);mv.visitCode();mv.visitFieldInsn(GETSTATIC, "com/hyphenate/State", "$patch", "Lcom/hyphenate/patch/PatchReDirection;");Label l0 = new Label();mv.visitJumpInsn(IFNULL, l0);mv.visitInsn(ICONST_0);mv.visitTypeInsn(ANEWARRAY, "java/lang/Object");mv.visitVarInsn(ALOAD, 0);mv.visitFieldInsn(GETSTATIC, "com/hyphenate/State", "$patch", "Lcom/hyphenate/patch/PatchReDirection;");mv.visitInsn(ICONST_0);mv.visitMethodInsn(INVOKESTATIC, "com/hyphenate/patch/PatchProxy", "isSupport", "([Ljava/lang/Object;Ljava/lang/Object;Lcom/hyphenate/patch/PatchReDirection;Z)Z", false);mv.visitJumpInsn(IFEQ, l0);mv.visitIntInsn(BIPUSH, 1);mv.visitTypeInsn(ANEWARRAY, "java/lang/Object");mv.visitInsn(DUP);mv.visitIntInsn(BIPUSH, 0);mv.visitVarInsn(ILOAD, 1);mv.visitMethodInsn(INVOKESTATIC, "java/lang/Integer", "valueOf", "(I)Ljava/lang/Integer;", false);mv.visitInsn(AASTORE);mv.visitVarInsn(ALOAD, 0);mv.visitFieldInsn(GETSTATIC, "com/hyphenate/State", "$patch", "Lcom/hyphenate/patch/PatchReDirection;");mv.visitInsn(ICONST_0);mv.visitMethodInsn(INVOKESTATIC, "com/hyphenate/patch/PatchProxy", "accessDispatch", "([Ljava/lang/Object;Ljava/lang/Object;Lcom/hyphenate/patch/PatchReDirection;Z)Ljava/lang/Object;", false);mv.visitTypeInsn(CHECKCAST, "java/lang/Long");mv.visitMethodInsn(INVOKEVIRTUAL, "java/lang/Long", "longValue", "()J", false);mv.visitInsn(LRETURN);mv.visitLabel(l0);mv.visitFrame(Opcodes.F_SAME, 0, null, 0, null);mv.visitLdcInsn(new Long(100L));mv.visitInsn(LRETURN);mv.visitMaxs(4, 2);mv.visitEnd();

对于插桩程序来说，需要做的就是把差异部分插桩到代码中。

需要将全部入参传递给 patch 方法，插入的代码因此会根据入參进行调整，同时也要处理返回值.

可以观察上面代码，上面的例子显示了一个 int 型入参 a，装箱变成 Integer，放在一个 Object[] 数组中，先后调用isSupport 和 accessDispatch，传递给 patch 类的对应方法，patch 返回类型是 Long，然后调用 longValue，拆箱变成 long 类型。

对于普通的 Java 对象，因为均派生自 Object，所以对象的引用直接放在数组中;对于 primitive 类型(包括 int, long, float….)的处理，需要先调用 Integer, Boolean, Float 等 Java 对象的构造函数，将 primitive 类型装箱后作为 object 对象放在数组中。

如果原来函数返回结果的是 primitive 类型，需要插桩代码将其转化为 primitive 类型。还要处理数组类型，和 void 类型。Java 的 primitive 类型在 Java Virtual Machine Specification 中有定义。

这个插入过程有两个关键问题，一个是函数 signature 的解析，另外一个是适配这个参数变化插入代码。下面详细解释下：

@Overridepublic MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions) {

这个函数是 asm.jar 访问类函数时触发的事件，desc 变量对应 Java jni 中的 signature，比如这里是'(I)J', 需要解析并转换成 primitive 类型、类、数组、void。这部分代码参考了 Android 底层的源码libcore/luni/src/main/java/libcore/reflect，和 Sun Java 的 SignatureParser.java，都有反映了这个遍历过程。

关于 Java 字节码的理解，汇编指令主要是看 Java bytecode instruction listings。

理解 Java 字节码，需要理解 JVM 中的栈的结构。JVM 是一个基于栈的架构。方法执行的时候(包括 main 方法)，在栈上会分配一个新的帧，这个栈帧包含一组局部变量。这组局部变量包含了方法运行过程中用到的所有变量，包括 this 引用，所有的方法参数，以及其它局部定义的变量。对于类方法(也就是 static 方法)来说，方法参数是从第 0 个位置开始的，而对于实例方法来说，第 0 个位置上的变量是 this 指针。(引自：Java 字节码浅析)

分析中间部分字节码实现：

com.hyphenate.patch.PatchProxy.accessDispatch(new Object[] {a}, this, $patch, false))

对应字节码如下，请对照 Java bytecode instruction listings 中每条指令观察对应栈帧的变化，下面注释中'[]'中表示栈帧中的内容。

mv.visitIntInsn(BIPUSH, 1); # 数字 1 入栈，对应 new Object[1]数组长度 1。 栈:[1]mv.visitTypeInsn(ANEWARRAY, "java/lang/Object"); # ANEWARRY:count(1) → arrayref, 栈:[arr_ref]mv.visitInsn(DUP); # 栈:[arr_ref, arr_ref]mv.visitIntInsn(BIPUSH, 0); # 栈:[arr_ref, arr_ref, 0]mv.visitVarInsn(ILOAD, 1); # 局部变量位置 1 的内容入栈， 栈:[arr_ref, arr_ref, 0, a]mv.visitMethodInsn(INVOKESTATIC, "java/lang/Integer", "valueOf", "(I)Ljava/lang/Integer;", false); # 调用 Integer.valueOf, INVOKESTATIC: [arg1, arg2, ...] → result, 栈:[arr_ref, arr_ref, 0, integerObjectOf_a]mv.visitInsn(AASTORE); # store a reference into array: arrayref, index, value →, 栈:[arr_ref]mv.visitVarInsn(ALOAD, 0); # this 入栈，栈:[arr_ref, this]mv.visitFieldInsn(GETSTATIC, "com/hyphenate/State", "$patch", "Lcom/hyphenate/patch/PatchReDirection;"); #$patch 入栈，栈:[arr_ref, this, $patch]mv.visitInsn(ICONST_0); #false 入栈， # 栈:[arr_ref, this, $patch, false]mv.visitMethodInsn(INVOKESTATIC, "com/hyphenate/patch/PatchProxy", "accessDispatch", "([Ljava/lang/Object;Ljava/lang/Object;Lcom/hyphenate/patch/PatchReDirection;Z)Ljava/lang/Object;", false); # 调用 accessDispatch, 栈包含返回结果，栈:[longObject]

熟悉上面的字节码以及对应的栈帧变化，也就掌握了插桩过程。

坑

ClassVisitor.visitMethod()中 access 如果是 ACC_SYNTHETIC 或者 ACC_BRIDGE，插桩后无法正常运行。ACC_SYNTHETIC 表示函数由 JAVAC 自动生成的，enum 类型就会产生这种类型的方法，不需要插桩，直接略过。因为观察到模版类也会产生 ACC_SYNTHETIC，所以插桩过程跳过了模版类。

ClassVisitor.visit()函数对应遍历到类触发的事件，access 如果是 ACC_INTERFACE 或者 ACC_ENUM，无需插桩。简单说就是接口和 enum 不涉及方法修改，无需插桩。

静态方法的实现和普通类成员函数略有出入，对于汇编程序来说，本地栈的第一个位置，如果是普通方法，会存储 this 引用，static 方法没有 this，这里稍微调整一下就可以实现的。

不定参数由于要求连续输入的参数类型相同，被编译器直接变成了数组，所以对本程序没有造成影响。

大小

插桩因为对每个函数都插桩，反编译后看实际上增加了大量代码，甚至可以说插入的代码比原有的代码还要多。但是实际上最终生成的 jar 包增长了大概 20% 多一点，并没有想的那么多，在可接受范围内。因为 class 所占的空间不止是代码部分，还包括类描述、字段描述、方法描述、const-pool 等，代码段只占其中的不到一半。可以参考 The class File Format。

讨论

前面代码插桩的部分和美团热更文章中保持一致，实际上还有些细节还可以调整。isSupport 这个函数的参数可以调整如下：

if (PatchProxy.isSupport(“getIndex”, "(I)J", false)) {

这样能减小插桩部分代码，而且可以区分名字相同的函数。

PatchProxy.isSupport 最后一个参数表示是普通类函数还是 static 函数，这个是方便 Java 应用 patch 的时候处理。