QQ空间热修复原理深入解析
来源:互联网 发布:汽车配件查询软件 编辑:程序博客网 时间:2024/05/16 01:51
一、背景
App的上线发布是我们程序猿开心的事情,证明着一段时间来成果的进步和展现。但是随着App的上线手机App市场,接下来的更新维护工作便成了”家常便饭“。尤其是在创业公司,随着业务等不稳定性因素,前期App的更新工作更为频繁,可能两天一小改,三天一大改的情况经常发生。
那么应对版本更新的同时,需要我们不断将新版本上线,并下发到用户,此时两个典型的问题发生了:
(1)发版的周期过长
(2)用户的App版本更新进度缓慢
所以,在传统App的开发模式下,需要一种手段来改变当前存在的问题。如果存在一种方案可以在不发版的前提下也可以修复线上App的Bug,那么以上两个问题就都得以解决。此时一系列的第三方库扑面而来,阿里的AndFix、腾讯的Qzone修复、以及近期开源的微信Tinker应运而生。
关于各种热更新库的使用,网上已经有很多的博文来介绍。本篇博客着重和大家分享一下关于QQ空间热更新的原理解析。
二、热修复原理
关于原理的分析,大致分为如下模块:
(1)热修复机制的产生
(2)Android类加载机制
1、热修复机制的产生
随着App业务不断叠加,以及第三方库的多种依赖,相信很多人某天运行程序突然出现如下异常:
UNEXPECTED TOP-LEVEL EXCEPTION: java.lang.IllegalArgumentException: method ID not in [0, 0xffff]: 65536 at com.android.dx.merge.DexMerger$6.updateIndex(DexMerger.java:501) at com.android.dx.merge.DexMerger$IdMerger.mergeSorted(DexMerger.java:282) at com.android.dx.merge.DexMerger.mergeMethodIds(DexMerger.java:490) at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:167) at com.android.dx.merge.DexMerger.merge(DexMerger.java:188) at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:439) at com.android.dx.command.dexer.Main.runMonoDex(Main.java:287) at com.android.dx.command.dexer.Main.run(Main.java:230) at com.android.dx.command.dexer.Main.main(Main.java:199) at com.android.dx.command.Main.main(Main.java:103)
从异常信息中,我们不难发现:method ID not in 65536。并且大致可以看出是在dex层跑出的异常。什么意思呢?我们编写的Java业务代码为.java类型文件,当我们编译运行一个完整的App项目时,系统会执行如下流程:
.Java --> .class --> dex --> (odex ) --> Apk
当class文件被打包成一个dex文件时,由于dex文件的限制,方法的ID为short型,所以一个dex文件存放的方法数最多为65536。超过了该数,系统就会抛出上面所述的异常。为了解决这个问题,Google为我们提供了multidex解决方案,即把dex文件分为主、副两类。系统只加载第一个dex文件(主dex),剩余的dex文件(副dex)在Application中的onCreate方法中,以资源的方式被加载到系统的ClassLoader。可以理解为:一个APK可以包含多个dex文件。这样就解决了65536问题的同时。也为热修复提供了实现方案:将修复后的dex文件下发到客户端(App),客户端在启动后就会加载最新的dex文件。
关于如何实现加载最新dex文件,我们还需要了解下Android Davilk虚拟机的类加载流程。
2、Android类加载机制
Android虚拟机对于类的加载机制为:同一个类只会加载一次。所以要实现热修复的前提就是:让下发到客户端的补丁包类要比之前存在bug的类优先加载。类似于一种“替换”的解决。如何实现优先加载呢?我们先来了解下Davilk虚拟机的类加载方式。
Java虚拟机JVM的类加载是:ClassLoader。同样Android系统提供了两种类加载方式:
(1)DexClassLoader
(2)PathClassLoader
libcore/dalvik/src/main/java/dalvik/system/
(1)DexClassLoader源码:
xref: /libcore/dalvik/src/main/java/dalvik/system/DexClassLoader.java17package dalvik.system;19import java.io.File;36public class DexClassLoader extends BaseDexClassLoader {37 /**38 * Creates a {@code DexClassLoader} that finds interpreted and native39 * code. Interpreted classes are found in a set of DEX files contained40 * in Jar or APK files.41 *42 * <p>The path lists are separated using the character specified by the43 * {@code path.separator} system property, which defaults to {@code :}.44 *45 * @param dexPath the list of jar/apk files containing classes and46 * resources, delimited by {@code File.pathSeparator}, which47 * defaults to {@code ":"} on Android48 * @param optimizedDirectory directory where optimized dex files49 * should be written; must not be {@code null}50 * @param libraryPath the list of directories containing native51 * libraries, delimited by {@code File.pathSeparator}; may be52 * {@code null}53 * @param parent the parent class loader54 */55 public DexClassLoader(String dexPath, String optimizedDirectory,56 String libraryPath, ClassLoader parent) {57 super(dexPath, new File(optimizedDirectory), libraryPath, parent);58 }59}60
(2)PathClassLoader:xref: /libcore/dalvik/src/main/java/dalvik/system/PathClassLoader.java25public class PathClassLoader extends BaseDexClassLoader {26 /**27 * Creates a {@code PathClassLoader} that operates on a given list of files28 * and directories. This method is equivalent to calling29 * {@link #PathClassLoader(String, String, ClassLoader)} with a30 * {@code null} value for the second argument (see description there).31 *32 * @param dexPath the list of jar/apk files containing classes and33 * resources, delimited by {@code File.pathSeparator}, which34 * defaults to {@code ":"} on Android35 * @param parent the parent class loader36 */37 public PathClassLoader(String dexPath, ClassLoader parent) {38 super(dexPath, null, null, parent);39 }4041 /**42 * Creates a {@code PathClassLoader} that operates on two given43 * lists of files and directories. The entries of the first list44 * should be one of the following:45 *46 * <ul>47 * <li>JAR/ZIP/APK files, possibly containing a "classes.dex" file as48 * well as arbitrary resources.49 * <li>Raw ".dex" files (not inside a zip file).50 * </ul>51 *52 * The entries of the second list should be directories containing53 * native library files.54 *55 * @param dexPath the list of jar/apk files containing classes and56 * resources, delimited by {@code File.pathSeparator}, which57 * defaults to {@code ":"} on Android58 * @param libraryPath the list of directories containing native59 * libraries, delimited by {@code File.pathSeparator}; may be60 * {@code null}61 * @param parent the parent class loader62 */63 public PathClassLoader(String dexPath, String libraryPath,64 ClassLoader parent) {65 super(dexPath, null, libraryPath, parent);66 }67}
从源码可以看出,DexClassLoader和PathClassLoaderr继承自BaseDexClassLoader。
(1)PathClassLoader可以操作本地文件系统的文件列表或目录中的classes。PathClassLoader负责加载系统类和主Dex中的类。
(2)DexClassLoader是一个可以从包含classes.dex实体的.jar或.apk文件中加载classes的类加载器。DexClassLoader负责加载其他dex文件(副dex)中的类。
既然是类加载器,必然存在类加载方法,继续查看源码,可以发现BaseDexClassLoader提供了findClass方法用于加载类:
(1)BaseDexClassLoader源码:
xref: /libcore/dalvik/src/main/java/dalvik/system/BaseDexClassLoader.java 17package dalvik.system;1819import java.io.File;20import java.net.URL;21import java.util.ArrayList;22import java.util.Enumeration;23import java.util.List;29public class BaseDexClassLoader extends ClassLoader {30 private final DexPathList pathList;45 public BaseDexClassLoader(String dexPath, File optimizedDirectory,46 String libraryPath, ClassLoader parent) {47 super(parent);48 this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);49 }5051 @Override52 protected Class<?> findClass(String name) throws ClassNotFoundException {53 List<Throwable> suppressedExceptions = new ArrayList<Throwable>();54 Class c = pathList.findClass(name, suppressedExceptions);55 if (c == null) {56 ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);57 for (Throwable t : suppressedExceptions) {58 cnfe.addSuppressed(t);59 }60 throw cnfe;61 }62 return c;63 }
在findClass方法中,又调用了DexPathList对象的findClass方法,DexPathList源码如下:
xref: /libcore/dalvik/src/main/java/dalvik/system/DexPathList.java17package dalvik.system;1819import java.io.File;20import java.io.IOException;21import java.net.MalformedURLException;22import java.net.URL;23import java.util.ArrayList;24import java.util.Arrays;25import java.util.Collections;26import java.util.Enumeration;27import java.util.List;28import java.util.zip.ZipFile;29import libcore.io.ErrnoException;30import libcore.io.IoUtils;31import libcore.io.Libcore;32import libcore.io.StructStat;33import static libcore.io.OsConstants.*;48/*package*/ final class DexPathList {49 private static final String DEX_SUFFIX = ".dex";50 private static final String JAR_SUFFIX = ".jar";51 private static final String ZIP_SUFFIX = ".zip";52 private static final String APK_SUFFIX = ".apk";5354 /** class definition context */55 private final ClassLoader definingContext;5657 /**58 * List of dex/resource (class path) elements.59 * Should be called pathElements, but the Facebook app uses reflection60 * to modify 'dexElements' (http://b/7726934).61 */62 private final Element[] dexElements;6364 /** List of native library directories. */65 private final File[] nativeLibraryDirectories;305 /**306 * Finds the named class in one of the dex files pointed at by307 * this instance. This will find the one in the earliest listed308 * path element. If the class is found but has not yet been309 * defined, then this method will define it in the defining310 * context that this instance was constructed with.311 *312 * @param name of class to find313 * @param suppressed exceptions encountered whilst finding the class314 * @return the named class or {@code null} if the class is not315 * found in any of the dex files316 */317 public Class findClass(String name, List<Throwable> suppressed) {318 for (Element element : dexElements) {319 DexFile dex = element.dexFile;320321 if (dex != null) {322 Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);323 if (clazz != null) {324 return clazz;325 }326 }327 }328 if (dexElementsSuppressedExceptions != null) {329 suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));330 }331 return null;332 }
Element为DexPathList的静态内部类,然后取出Element对象中的DexFile,调用DexFile的loadClassBinaryName方法,继续来看DexFile源码:
xref: /libcore/dalvik/src/main/java/dalvik/system/DexFile.java17package dalvik.system;1819import java.io.File;20import java.io.FileNotFoundException;21import java.io.IOException;22import java.util.ArrayList;23import java.util.Enumeration;24import java.util.List;25import libcore.io.ErrnoException;26import libcore.io.Libcore;27import libcore.io.StructStat;2829/**30 * Manipulates DEX files. The class is similar in principle to31 * {@link java.util.zip.ZipFile}. It is used primarily by class loaders.32 * <p>33 * Note we don't directly open and read the DEX file here. They're memory-mapped34 * read-only by the VM.35 */36public final class DexFile {37 private int mCookie;38 private final String mFileName;39 private final CloseGuard guard = CloseGuard.get();207 /**208 * See {@link #loadClass(String, ClassLoader)}.209 *210 * This takes a "binary" class name to better match ClassLoader semantics.211 *212 * @hide213 */214 public Class loadClassBinaryName(String name, ClassLoader loader, List<Throwable> suppressed) {215 return defineClass(name, loader, mCookie, suppressed);216 }218 private static Class defineClass(String name, ClassLoader loader, int cookie,219 List<Throwable> suppressed) {220 Class result = null;221 try {222 result = defineClassNative(name, loader, cookie);223 } catch (NoClassDefFoundError e) {224 if (suppressed != null) {225 suppressed.add(e);226 }227 } catch (ClassNotFoundException e) {228 if (suppressed != null) {229 suppressed.add(e);230 }231 }232 return result;233 }
DexFile类中,loadClassBinaryName方法中调用了defineClass方法,该方法直接通过defineClassNative执行Android原生层代码...到此为止,整个加载流程就走完了。所以,要实现热修复的就必须要在DexPathList中遍历Element元素时,让补丁dex在Element数组中的为止优先于原有已存在的dex。这样,当系统遍历dexElement时,就可以加载最新补丁dex,实现dex的 “替换”。
引用安卓App热补丁动态修复技术介绍历文章中的描述:
三、核心实现
(1)编写demo代码,工程名称为QQHotUpdate
/** * Created by Song on 2017/5/15. */public class Cal { public float calculate() { // 很明显,会有算数异常抛出 return 1 / 0; }}
public class MainActivity extends AppCompatActivity { private Cal cl; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); cl = new Cal(); } /** * 点击按钮测试 * @param view */ public void cal(View view) { cl.calculate(); }}
(2)打补丁包,顾名思义,就是修补问题后的包。第一步需要先修改程序,并重新rebuild。
/** * Created by Song on 2017/5/15. */public class Cal { public float calculate() { // 修改后的,不存在任何问题 return 1 / 1; }}补丁包其实是一个dex文件。dex文件的形成过程为:.class --> jar --> dex。所以,先要将class文件打包为jar。
重新编译后的class文件在app / build / intermediates / classes / debug / 包名 / ...
将目录copy到桌面,删除不必要的文件,留下Cal.class即可。然后执行如下命令:
jar -cvf pat.jar com上述命令将com目录下的文件打包为pat.jar文件。
接下来需要将jar文件打包为dex文件,我们使用SDK24.0版本下的dx.bat,进入该目录,在dos下执行:
dx --dex --output=patch_dex.jar C:/Users/Song/Desktop/pat.jar最终打包出的dex文件为patch_dex.jar。
(3)加载补丁
打开Android Device Monitor,将补丁放入SD卡根目录:
选择右上角第二个按钮,将patch_dex.jar导入到模拟器。
创建Application,在Application中加载补丁文件:
/** * Created by Song on 2017/5/15. */public class MainApplication 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()) { Log.e("-----","开始................."); inject(dexPath); } } /** * 要注入的dex的路径 */ 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); } 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; }}分析:
(1)在补丁包存在的情况下,向App的BaseDexClassLoader的dexElements下注入补丁。
(2)通过本身BaseDexClassLoader,利用反射获取classes的dexElements。
(3)加载补丁包的dexElements。
(4)合并两个补丁包,生成新的dexElements。
(5)将新的dexElements重新设置到App下的BaseDexClassLoader。
重点在合并代码上,可以发现,在合并的过程中,我们将新的补丁文件设置到了最前面。从上面原理部分我们知道,相同文件只会加载一次!当虚拟机优先加载了最前面的补丁包后,遇到相同文件就不会再重复加载。这就达到了修复的作用。
ok,执行代码,等待惊喜.... 麻蛋,又出现异常:
Class ref in pre-verified class resolved to unexpected implementation
百度后发现原来是因为类校验产生的问题:
(1)在apk安装的时候系统会将dex文件优化成odex文件,在优化的过程中会涉及一个预校验的过程。
(2)如果一个类的static方法,private方法,override方法以及构造函数中引用了其他类,而且这些类都属于同一个dex文件,此时该类就会被打上CLASS_ISPREVERIFIED。
(3)如果在运行时被打上CLASS_ISPREVERIFIED的类引用了其他dex的类,就会报错。
(4)所以MainActivity的onCreate()方法中引用另一个dex的类就会出现上文中的问题。
(5)正常的分包方案会保证相关类被打入同一个dex文件。
(6)想要使得patch可以被正常加载,就必须保证类不会被打上CLASS_ISPREVERIFIED标记。而要实现这个目的就必须要在分完包后的class中植入对其他dex文件中类的引用。
要在已经编译完成后的类中植入对其他类的引用,就需要操作字节码,惯用的方案是插桩。常见的工具有javaassist,asm等。其实QQ空间热修复也是利用的插桩的方式来实现了在apk文件安装的时候不被打上CLASS_ISPREVERIFIED标记。完成热修复工作。关于插桩此处就不再赘述了,这里推荐给大家一篇教程:Android热修复技术-插桩分析
ok,以上就是关于QQ空间热修复的内容,文笔有限还望喜欢。
- QQ空间热修复原理深入解析
- 基于QQ空间热修复原理实践
- QQ热修复原理地址
- QQ空间热修复思想学习总结
- 基于QQ空间热修复原理开发的Nuwa框架使用步骤
- Android热修复技术——QQ空间补丁方案解析(1)
- Android热修复技术——QQ空间补丁方案解析(2)
- Android热修复技术——QQ空间补丁方案解析(3)
- Android热修复之QQ空间与QFix方案
- Android 热修复原理
- Android热修复原理
- Android 热修复原理
- Android 热修复原理
- 热修复原理分析
- Android热修复原理
- Android热修复原理
- 热修复原理
- Alibaba-AndFix Bug热修复框架原理及源码解析
- MongoDB数据库设计中6条重要的经验法则3
- mysql使用uuid()函数生成主键方法(java环境)
- Git SSH Key 生成步骤
- 尾递归
- 二分法查找
- QQ空间热修复原理深入解析
- 前端js调用浏览器日志日志打印
- 极光推送工具类 java httpClient
- jsp 页面时间格式化
- Android期末复习(1)
- 4827: [Hnoi2017]礼物
- Spark SQL数据加载和保存实战
- lazy-generator JAVA代码自动生成的插件
- Makefile学习笔记<常用参数>