文章目录 概述: 一、底层方法替换 原理: 二、类加载 原理: 1、java类加载机制 2、Android类加载机制 3、热修复实现原理 二、主流热更新框架介绍 1、Tinker 3、AndFix 4、 Nuwa 参考1 概述: 热修复有两种方式:一方面是阿里系为代表的底层方法替换,另一方面是以腾讯系为代表的类加载方案。 前者支持立即生效,但是限制比较多;后者必须冷启动生效,相对较稳定,修复范围广。之前分析过微信的热修复框架 Tinker 即属于后者, 《Tinker 接入及源码分析》。 本篇文章主要分析以 AndFix 为代表的底层方法替换方案,并且实现了《深入探索 Android 热修复技术原理》中提到的方法替换新方案。 一、底层方法替换 原理: 参考 方法替换是 AndFix 的热修复方案的关键,虚拟机在加载一个类的时候会将类中方法解析成 ArtMethod 结构体,结构体中保存着一些运行时的必要信息以及需要执行的指令指针地址
以下是 ** 原文链接有兴趣的还可以看下大佬博客 ** # 工作原理分析 要实现热修复其实原理就是我们可以动态的修改代码,在方法前、中、后插入自己想要的东西或者代码。 综上所述打到热修复整套流程所需的技术如下: Runtime: 可以在本站搜索 Runtime 关键字找到 Runtime 相关资料 与服务器交互: 现在大部分 APP 都具有于服务端交互的能力,就是我们常说的网络请求 # 配置工程 用实际代码来证明下,这是我 Controller 中的一个代码,很明显会产生数组越界的 Crash,假如我们在上线后才发现了这个问题,这时候需要修复 #import "ViewController.h
前言 刚开始要做 SDK 热修复,我是拒绝的 ~ 某日,解决完一个线上 bug 后,我冒出了一个念头:让我们的 SDK 也具有热修复的能力呗! 方案参考: Android SDK热修复机制简析以实现 优缺点 优点: 无兼容问题 缺点: 反射消耗性能; jar 包如果体积大,整个下载就很不友好; 确定改动的代码范围繁琐,维护麻烦。 方案三:业务方热更 走投无路之下,我想起,诶!很多 app 热更方案不是说支持 lib 热更吗!那先作为一个保底方案吧。 步骤 通过业务方 app 热更 lib 包。 方案四:改造现有 APP 热修复方案 1. 那在选择热修复方案时考虑点有哪些? 1. 热更项目的需求 * 只需要简单的方法级别 Bug 修复? * 需要资源及 so 库的修复? 那我们赶紧来看下,现有的 APP 热修复方案都有哪些? 3.1 综合优化的产物 —— Sophix(弃) Sophix 功能完善、开发简单透明,可惜没开源,无法改造。
前言 刚开始要做 SDK 热修复,我是拒绝的 ~ 某日,解决完一个线上 bug 后,我冒出了一个念头:让我们的 SDK 也具有热修复的能力呗! 但是查了查,网上资料少、很多热修复方案只针对app…… 可是我都拍胸脯向老大夸口了,焉有退缩的道理?! 加上万一以后手抖,出了个什么大 bug 或者兼容问题,我的职业生涯不就要终结了!? 方案三:业务方热更 走投无路之下,我想起,诶!很多 app 热更方案不是说支持 lib 热更吗!那先作为一个保底方案吧。 步骤 通过业务方 app 热更 lib 包。 方案四:改造现有 APP 热修复方案 1. 那在选择热修复方案时考虑点有哪些? 1. 热更项目的需求 只需要简单的方法级别 Bug 修复? 需要资源及 so 库的修复? 那我们赶紧来看下,现有的 APP 热修复方案都有哪些? 3.1 综合优化的产物 —— Sophix(弃) Sophix 功能完善、开发简单透明,可惜没开源,无法改造。
如果只是会这些热修复框架的使用那意义并不大,我们还需要了解它们的原理,这样不管热修复框架如何变化,只要基本原理不变,我们就可以很快的掌握它们。 ,分别是代码修复、资源修复和动态链接库修复,其中每个核心技术又有很多不同的技术方案,每个技术方案又有不同的实现,另外这些热修复框架仍在不断的更新迭代中,可见热修复框架的技术实现是繁多可变的。 作为开发需需要了解这些技术方案的基本原理,这样就可以以不变应万变。 部分热修复框架的对比如下表所示。 类加载方案需要重启App后让ClassLoader重新加载新的类,为什么需要重启呢?这是因为类是无法被卸载的,因此要想重新加载新的类就需要重启App,因此采用类加载方案的热修复框架是不能即时生效的。 3.3 Instant Run方案 除了资源修复,代码修复同样也可以借鉴Instant Run的原理, 可以说Instant Run的出现推动了热修复框架的发展。
文章目录 一、Android 热修复系统组成 二、热修复工作流程 三、热修复使用到的技术 四、热修复框架选择注意事项 一、Android 热修复系统组成 ---- Android 热修复系统组成 : 手机端 是一个 Java / .NET / PHP 开发的 Web 应用 ; 二、热修复工作流程 ---- 热修复工作流程 : 首先 , 开发者发现 BUG , 使用 Gradle 插件生成 修复包 ; 然后 , 开发者 将修复包上传到 服务器端 , 由服务器对热修复的修复包进行统一的管理 ; 最后 , 手机端的 SDK 每次启动都会到 服务器端 检查是否有最新的修复包 , 如果有则下载最新的修复包 , 并在本地配置该修复包 , 每次启动都加载并执行该修复包数据 ; 三、热修复使用到的技术 ---- 热修复使用到的技术 : DexClassLoader 动态加载技术 : 主要是使用 自定义 DexClassLoader 类加载器 ; NDK 相关技术 : 需要 编译生成 so 动态库 ; 四、热修复框架选择注意事项 ---- 挑选热修复框架时 , 一定要要选择一直保持更新的框架 ; 凡是使用到 插件化 , 热修复 , 加固 等需要
Android热修复技术无疑是Android领域近年来最火热的技术之一,同时也涌现了各种层出不穷的实现方案,如QQ空间补丁方案、阿里AndFix以及微信Tinker等等,从本篇博客开始,计划写一个系列博客专门介绍热修复的相关内容 ,本系列博客将一一介绍这些框架的原理和源码分析,作为本系列的开篇,本篇博客将对热修复技术进行一个概述,并对以上几种方案进行对比。 为什么会出现热修复? 简单来说,以前出现bug的时候,都要重新发包对bug进行修复,这样带来的缺点是明显的,需要用户重新升级app,覆盖率太慢,成本太高。 热修复框架简单对比 接下来先对几个热修复框架进行简单的介绍,后续将分别单独开一篇博客对其进行详细分析。 1.QQ空间热修复补丁技术 QQ空间热修复的方案是基于dex分包方案的基础之上,简单来说就是把BUG方法修复以后,重新生成一个dex,从服务器下载之后,将其插入到dexElements数组的最前面,
热修复主要用来修复代码、修复bug、添加独立的功能,他的原理主要是操作PathClassLoader、DexClassLoader。 那么这样的话,就可以在这个dexElements中去做一些事情,比如,在这个数组的第一个元素放置我们的patch.jar,里面包含修复过的类,这样的话,当遍历findClass的时候,我们修复的类就会被查找到 优点: 重大bug,需要紧急修复 可以下次迭代修复的bug 影响用户体验的行为 无需重启 缺点: 无法添加新类(内部类也不行)和新的字段、新的方法? 资源文件无法替换 试了下换原有的图片可以,但是新增的不行 不能修改xml布局文件 不能 加固后的包补丁无法使用,如果要加固,需要加固前的包来生成补丁,不过这样生成的补丁也很容易破解 不能对同一个方法修复两次
5 热修复和插件化 插件化和热修复的原理,都是动态加载 dex/apk 中的类/资源,两者的目的不同。插件化目标在于加载 activity 等组件,达到动态下发组件的功能,热修复目标在修复已有的问题。 其中最重要的是方法和类的替换,所以有不少热修复框架只做了方法和类的替换,而没有对资源和 so 进行处理。 9 主流的热修复框架对比 这里选取几个比较主流的热修复框架进行对比 ? Aceso 全量替换 dex Tinker 混合方案 Sophix 下面对这几种热修复的方案进行详细分析。 10 dex 热修复方案 10.1 native hook 替换 ArtMethod 内容 原理 在解释 native hook 原理之前,先介绍一下虚拟机的一些简单实现。 优缺点 优点: 使用 java 实现,开发方便 兼容性好 补丁实时生效 缺点: 代码是侵入比较高,需要在原有代码中新增逻辑,而且需要对方法进行插桩,将这里逻辑自动化处理 增大包体积 11 资源热修复方案
文章目录 一、 热修复框架简介 1、类替换 2、so 替换 3、资源替换 4、全平台支持 5、生效时间 6、性能损耗 7、总结 二、 将 Java 字节码文件打包到 Dex 文件 一、 热修复框架简介 ---- 热修复框架 : 热修复框架有很多 , 只选择几个典型的进行对比研究 ; Tinker : 微信 ; QZone : Q 空间 ; AndFix : 阿里 ; Robust : 美团 ; 下面从几个方面的功能及性能分析上述四个热修复框架 ; Tinker , QZone 是以 Java 层作为修复的对象 ; AndFix , Robust 热修复框架不支持类替换 , 使用的是定点替换修复的机制 ; AndFix , Robust 是以 , 即时生效 ; 6、性能损耗 Tinker , AndFix , Robust 性能损耗较小 ; QZone 性能损耗较大 ; 7、总结 开源的热修复框架中 , 综合所有的要素 , 推荐使用 Tinker 热修复框架 , 除了即时生效的时效性之外 , 其它性能参数都可以接受 ; 二、 将 Java 字节码文件打包到 Dex 文件 ---- 程序出现 BUG , 修复好之后 , 发布修复包到服务器中 ,
如果你学会了这项黑科技——热修复。 在用户使用App的时候,不知不觉,这个Bug就被修复了。 莫慌 热修复:热修复(也称热补丁、热修复补丁,英语:hotfix)是一种包含信息的独立的累积更新包,通常表现为一个或多个文件。这被用来解决软件产品的问题(例如一个程序错误)。 来自官方Github Tinker热补丁方案·不仅支持类、So以及资源的替换,它还是2.X-7.X的全平台支持。 接入 进入正题吧 ? 就这样,整个热修复的流程就完成了。 注意:一定要关闭后打开,热修复才会生效。 ? V2 Scheme的walle; 若不同渠道存在功能上的差异,建议将差异部分放于单独的dex或采用相同代码不同配置方式实现; 已通过Walle实现:【Android】Walle多渠道打包&Tinker热修复
本篇重点讲解热修复,并对当前流行的热修复技术做一个简单的总结。 热修复 什么是热修复? 简单来讲,为了修复线上问题而提出的修补方案,程序修补过程无需重新发版! 热部署解决方案 新增/减少匿名内部类对热部署是无解的,因为补丁修复工具拿到的是class文件,无法区别DexFileDemo&1和DexFileDemo&2,会导致类的顺序乱套。 热修复方案总结 代码修复有两大主要方案:一种是阿里系的底层替换方案,另一种是腾讯系的类加载方案。底层替换方案限制颇多,但时效性最好,加载轻快,立即见效。 从而达到热修复的目的。 再来看看腾讯系三大类加载方案的实现原理。QQ空间方案会侵入打包流程,并且为了hack添加一些无用的信息,实现起来很不优雅。 资源修复 在Android热修复的过程中,不仅需要对错误的代码进行修复,还需要对资源文件进行修复。目前市面上的资源热修复方案基本上都是参考Instant Run的实现。
市场上热修复有两种一种是基于multidex的更新修复(比如tinker),另外一种是native hook(比如dexposed),tinker这种是反射获取dexelements数组,修改dex加载顺序 热修复包括两个部分 从远程端下载修复好bug的补丁包 客户端安装补丁包,加载补丁包的类。 使用android�类加载器,在类没被加载到模拟器前(一般在application热修复,如果类已加载,再去记载相同的类就无效了)然后先加载补丁dex,再去加载原来的app里面的dex,因为加载过的类 不会被加载第二次,从而做到热修复。 以上就是multidex热修复的原理。
Dex修复 Dex修复分为热部署底层热替换与冷部署重启 1.1 热部署底层替换 直接在native虚拟机层替换原有方法,是在原来类的基础上进行修改。 SO库修复 3.1 SO实时生效 1.Dalvik虚拟机下动态注册的native方法需实时修复,必须对so文件改名 2.静态注册的native方法的实时修复,因为无法得知so库中哪些native方法发生了变更 ,很难做到修复 3.对于新增动态注册的native方法,需在dex中增加相应的Java方法,否则加载so文件时报NoSuchMethodError,而增加Java方法是无法做到实时生效热修复,所以so库新增动态注册的 native方法也无法做到实时生效热修复 3.2 SO冷部署重启生效 1. 反射注入方式将补丁SO插入到nativeLibraryDirectories/nativeLibraryPathElements数组的最前面,达到优先加载补丁SO的目的,从而实现SO修复。
热修复时用来指定新的dex optimizedDirectory:dex文件的输出目录(因为在加载jar/apk/zip等压缩格式的程序文件时会解压出其中的dex文件,该目录就是专门用于存放这些被解压出来的 2.热修复的实现方法 加载class会使用BaseDexClassLoader,在加载时,会遍历文件下的element,并从element中获取dex文件 方案 ,class文件在dex里面 , 找到dex 的方法是遍历数组 , 那么热修复的原理, 就是将改好bug的dex文件放进集合的头部, 这样遍历时会首先遍历修复好的dex并找到修复好的类 . 3.手撸一个热修复Demo 在了解了大致的热修复过程之后,我们要准备好以下几个东西: 带有bug的apk,并且可以获取到dex文件来修复 已修复bug的dex文件 因为修复工作是需要隐秘的进行的 , 毕竟有 至此, 在Splash界面的检测时会见到到目标的dex文件, 返回true , 会开始进行热修复(拼接Element数组)的操作, 再次进入到主界面当然就不会报错了.
是核心库 , 一些工具类放在该库中 ; 对应构建脚本的 com.tencent.tinker:tinker-android-lib:1.9.1 依赖 ; tinker-android-loader 热修复中
主要是研究如何使用HotPatcher打包和热修复。 打包完成之后就可以将打出来的.pak文件放到release版本的目录下实现手动热更: UE在启动后会自动挂载这个路径的pak。除了这个路径还有另外几个路径,但是优先级不一样。 . /LuaProto.exe -log运行游戏,可以在命令行看到修改Lua脚本后打印出来的内容,同时可以看到地图的修改: 参考 UE4 资源热更打包工具 HotPatcher UE4热更新:HotPatcher
主流的热修复方案: 1. 底层替换 - AndFix 在运行时替换掉底层有Bug的方法的地址,将他们的指针指向修复之后的方法的内存地址,从而实现热修复的功能。 类加载方案 - Tinker、QZone 利用Android中类加载机制中的dexElements,将修复之后的dex文件放置到dexElements前面,屏蔽掉有问题的dex文件的加载,从而实现热修复的功能 类加载方案时效性较差,因为Java的双亲委派机制的原因,首次打开不会重复加载类,需要再次打开才能生效,修复范围广,实现简单,易于控制。 动态加载dex实现热修复 ? ,从而实现dex热修复。 Tinker热修复原理 ? 热修复的实现过程: 1. 使用bsdiff对新旧apk做差异化分析,获得差异化产物patch.apk补丁文件。
一、运行时 热修复的基本原理就是Runtime运行时的方法替换,主要是下列几个方法 class_replaceMethod:方法替换 method_exchangeImplementations:IMP swizzledMethod); } }); 二、Javascriptcore Javascriptcore是一个iOS原生框架,用于javascript与Objecive C语言进行相互调用,而我们热修改需要用到的就是 javascript可以调用OC方法 三、热修复
是阿里开源的一个Android热补丁框架,允许APP在不重新发布版本的情况下修复线上的bug。支持Android 2.3 到 6.0。 通过jadx查看一下源码,里面就是被修复的代码所在的类文件,这些更改过的类都加上了一个_CF的后缀,并且变动的方法都被加上了一个叫@MethodReplace的annotation,通过clazz和method