背景

当一个App发布之后,突然发现了一个严重bug需要进行紧急修复,这时候公司各方就会忙得焦头烂额:重新打包App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装。有时候仅仅是为了修改了一行代码,也要付出巨大的成本进行换包和重新发布。

这时候就提出一个问题:有没有办法以补丁的方式动态修复紧急Bug,不再需要重新发布App,不再需要用户重新下载,覆盖安装?

解决方案

该方案基于的是android dex分包方案的,关于dex分包方案,网上有几篇解释了,所以这里就不再赘述。

简单的概括一下,就是把多个dex文件塞入到app的classloader之中,但是android dex拆包方案中的类是没有重复的,如果classes.dex和classes1.dex中有重复的类,当用到这个重复的类的时候,系统会选择哪个类进行加载呢?

让我们来看看类加载的代码:

  1. public Class findClass(String name, List<Throwable> suppressed) {
  2. for (Element element : dexElements) {  //每个Element就是一个dex文件
  3. DexFile dex = element.dexFile;
  4. if (dex != null) {
  5. Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
  6. if (clazz != null) {
  7. return clazz;
  8. }
  9. }
  10. }
  11. if (dexElementsSuppressedExceptions != null) {
  12. suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
  13. }
  14. return null;
  15. }

复制代码

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

理论上,如果在不同的dex中有相同的类存在,那么会优先选择排在前面的dex文件的类,如下图:

在此基础上,我们构想了热补丁的方案,把有问题的类打包到一个dex(patch.dex)中去,然后把这个dex插入到Elements的最前面,如下图

好,该方案基于第二个拆分dex的方案,方案实现如果懂拆分dex的原理的话,大家应该很快就会实现该方案,如果没有拆分dex的项目的话,可以参考一下谷歌的multidex方案实现。然后在插入数组的时候,把补丁包插入到最前面去。

好,看似问题很简单,轻松的搞定了,让我们来试验一下,修改某个类,然后打包成dex,插入到classloader,当加载类的时候出现了(本例中是ActivityManager要被替换):

为什么会出现以上问题呢?

从log的意思上来讲,ModuleManager引用了ActivityManager,但是发现这这两个类所在的dex不在一起,其中:

1. ModuleManager在classes.dex中

2. ActivityManager在patch.dex中

结果发生了错误。

这里有个问题,拆分dex的很多类都不是在同一个dex内的,怎么没有问题?

让我们搜索一下抛出错误的代码所在,嘿咻嘿咻,找到了一下代码:

从代码上来看,如果两个相关联的类在不同的dex中就会报错,但是拆分dex没有报错这是为什么,原来这个校验的前提是:

如果引用者(也就是ModuleManager)这个类被打上了CLASS_ISPREVERIFIED标志,那么就会进行dex的校验。那么这个标志是什么时候被打上去的?

让我们在继续搜索一下代码,嘿咻嘿咻~~,在DexPrepare.cpp找到了一下代码:

这段代码是dex转化成odex(dexopt)的代码中的一段,我们知道当一个apk在安装的时候,apk中的classes.dex会被虚拟机(dexopt)优化成odex文件,然后才会拿去执行。

虚拟机在启动的时候,会有许多的启动参数,其中一项就是verify选项,当verify选项被打开的时候,上面doVerify变量为true,那么就会执行dvmVerifyClass进行类的校验,如果dvmVerifyClass校验类成功,那么手机号卖号平台这个类会被打上CLASS_ISPREVERIFIED的标志,那么具体的校验过程是什么样子的呢?

此代码在DexVerify.cpp中,如下:

1. 验证clazz->directMethods方法,directMethods包含了以下方法:

1. static方法

?2. private方法

?3. 构造函数

2.?clazz->virtualMethods

1. 虚函数=override方法?

概括一下就是如果以上方法中直接引用到的类(第一层级关系,不会进行递归搜索)和clazz都在同一个dex中的话,那么这个类就会被打上CLASS_ISPREVERIFIED标志

所以为了实现补丁方案,所以必须从这些方法中入手,防止类被打上CLASS_ISPREVERIFIED标志。

最终空间的方案是往所有类的构造函数里面插入了一段代码,代码如下:

  1. if (ClassVerifier.PREVENT_VERIFY) {
  2. System.out.println(AntilazyLoad.class);
  3. }

复制代码

其中AntilazyLoad类会被打包成单独的hack.dex,这样当安装apk的时候,classes.dex内的类都会引用一个在不相同dex中的AntilazyLoad类,这样就防止了类被打上CLASS_ISPREVERIFIED的标志了。只要没被打上这个标志的类都可以进行打补丁操作。

然后在应用启动的时候加载进来.AntilazyLoad类所在的dex包必须被先加载进来,不然AntilazyLoad类会被标记为不存在,即使后续加载了hack.dex包,那么他也是不存在的,这样屏幕就会出现茫茫多的类AntilazyLoad找不到的log。

所以Application作为应用的入口不能插入这段代码。(因为载入hack.dex的代码是在Application中onCreate中执行的,如果在Application的构造函数里面插入了这段代码,那么就是在hack.dex加载之前就使用该类,该类一次找不到,会被永远的打上找不到的标志)

其中:

  1. class ClassVerifier {
  2. public static boolean PREVENT_VERIFY = false;//false防止代码被执行,提高性能
  3. }

复制代码

之所以选择构造函数是因为他不增加方法数,一个类即使没有显式的构造函数,也会有一个隐式的默认构造函数。

空间使用的是在字节码插入代码,而不是源代码插入,使用的是javaassist库来进行字节码插入的。

隐患:

虚拟机在安装期间为类打上CLASS_ISPREVERIFIED标志是为了提高性能的,我们强制防止类被打上标志是否会影响性能?这里我们会做一下更加详细的性能测试。

但是在大项目中拆分dex的问题已经比较严重,很多类都没有被打上这个标志。

如何打包补丁包:

1.空间在正式版本发布的时候,会生成一份缓存文件,里面记录了所有class文件的md5.还有一份mapping混淆文件。

2.在后续的版本中使用-applymapping选项,应用正式版本的mapping文件,然后计算编译完成后的class文件的md5和正式版本进行比较,把不相同的class文件打包成补丁包。

备注:该方案现在也应用到我们的编译过程当中,编译不需要重新打包dex,只需要把修改过的类的class文件打包成patch dex,然后放到sdcard下,那么就会让改变的代码生效。

安卓App热补丁动态修复技术:让App像Web一样发布新版本相关推荐

  1. App热补丁动态修复技术介绍

    安卓App热补丁动态修复技术介绍 来自qq空间团队:微信号qzonemobiledev QQ空间终端开发团队 1.背景 当一个App发布之后,突然发现了一个严重bug需要进行紧急修复,这时候公司各方就 ...

  2. Android热补丁动态修复技术

    Android热补丁动态修复技术(一):从Dex分包原理到热补丁 一.参考 博文:安卓App热补丁动态修复技术介绍--by QQ空间终端开发团队  博文:Android dex分包方案--by 猫的午 ...

  3. Android热补丁动态修复实践

    前言 好几个月之前关于Android App热补丁修复火了一把,源于QQ空间团队的一篇文章安卓App热补丁动态修复技术介绍,然后各大厂的开源项目都出来了,本文的实践基于HotFix,也就是QQ空间技术 ...

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

    Android 热补丁动态修复框架小结 转载于:https://www.cnblogs.com/zhujiabin/p/7923233.html

  5. Android 热补丁动态修复总结 eclipse版

    参考文章 1. http://blog.csdn.net/lmj623565791/article/details/49883661  鸿翔博客 2. https://mp.weixin.qq.com ...

  6. Android AndFix热补丁动态修复框架使用教程

    简介 已经上线的项目发现BUG,紧急修复BUG发布新版本?No,也许你需要AndFix. AndFix 是阿里巴巴开源的 Android 应用热修复工具,帮助 Anroid 开发者修复应用的线上问题. ...

  7. Android热补丁动态更新实践

    前言 好几个月之前关于Android App热补丁修复火了一把,源于QQ空间团队的一篇文章安卓App热补丁动态修复技术介绍,然后各大厂的开源项目都出来了,本文的实践基于HotFix,也就是QQ空间技术 ...

  8. 【新技能get】让App像Web一样发布新版本

    背景 当一个App发布之后,突然发现了一个严重bug需要进行紧急修复,这时候公司各方就会忙得焦头烂额:重新打包App.测试.向各个应用市场和渠道换包.提示用户升级.用户下载.覆盖安装.有时候仅仅是为了 ...

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

    前言 今年真是热补丁框架的洪荒之力爆发的一年,短短几个月内,已经出现了好几个热修复的框架了,基本上都是大同小异,这里我就不过多的去评论这些框架.只有自己真正的去经历过,你才会发现其中的 大写的坑 事实 ...

最新文章

  1. Xenapp安装后手动更改XML Service端口,以便使用不同于 IIS 的端口
  2. 能识别nvme的pe启动_PE系统纯净(可以识别nvme固态)
  3. vmware中装的ubuntu上不了网
  4. 使用spring集成的kafka收发消息
  5. Visual C#中父窗口和子窗口之间实现控件互操作
  6. html cdn不缓存,【前端开发日常 - 6】七牛CDN上的网页缓存问题及HTML禁止缓存(续)...
  7. python 获取foobar2000官网全部插件
  8. 毕业设计不要再做 XX 管理系统了
  9. c# 免费版pdf转word尝试
  10. python爬虫基础爬取用户头像实战
  11. VBA 获取最大行数和最大列数
  12. 智慧小区智慧物业管理系统一体化解决方案
  13. java和以太坊交互_Android怎么和以太坊智能合约交互
  14. duffing matlab,duffing方程matlab
  15. 解析两周期货投机过程中的心理端倪
  16. 用python证明采样定理_如何理解 Nyquist 采样定理?
  17. Android 自带的返回键功能
  18. 计算机组成原理中J1J3是什么,计算机组成原理第一次实验报告.doc
  19. java反编译工具(class转java)
  20. 因子模型:协方差矩阵

热门文章

  1. 未能分析从服务器收到的消息,WebSocket Javascript客户端未收到来自服务器的消息...
  2. python ipaddress_Python3标准库:ipaddress Internet地址
  3. php留言板实战,PHP留言本,非常适合新手实战操作!
  4. 实现单服务器响应多客户机,对等网与客户机/服务器网络
  5. Python学习,装饰器,元类
  6. HNOI2018酱油记
  7. laravel5.5事件系统
  8. Mysql基础知识:索引
  9. 如何测试一个网页登陆界面
  10. 屠龙之路_坚持就是胜利_NinthDay