安卓应用市场常用热修复腾讯的Tinker，阿里的Andfix（总结，对比，接入）
本文字数：3545字
预计阅读时间：11分钟
一旦发布版本 用户手中的app就无法控制了
所以就产生了热修复的库或者说第三方
1，首先，你需要了解一下热修复的原理：
2，然后再去看看市场上的热修复对比，如何接入
3，后面会对tinker和tinkerpatch以及Andfix着重讲解。
热修复就可以解决：
修复方案：替换方法，方法抛异常（修修补补，哪里坏了修哪里，定点修理）class -- method AndFix.so修复的包apk崩溃抛异常--等下版本升级修复线上bug，后台兼容处理从服务器下载包。
热修复技术要解决的问题
1.刚发布了应用就发现了比较严重的BUG
2.有一些小功能需要及时的推送给用户使用（支付宝每到节日都有小的变化）
热修复技术不会对我们应用有结构上的改变
主要目的
1.热用这些热门技术时要注意的问题
2.引入这些热门技术后的代码及版本发布的管理
3.热门框架的原理讲解，源码阅读，知其所以然
首先要了解知识详解模块
1.dex/class
2.classload深入讲解（javacalssloadandroidclassload）了解类是如何被加载到虚拟机中的
然后在看热修复
1.热修复原理深入讲解
2.如何合理的接入开源的热修复框架
3.开源框架的原理讲解及版本发布控制
classes文件与dex文件解析
每个android开发人员每天要面对的文件格式我们平时看到的是Java语言文件ide和安卓操作系统已经帮我们完成了dex与class的生成
1.class文件结构深入解析
2.dex文件结构深入解析
3.dex与class文件对比
必须对class和dex文件的概念有一定的了解
class文件详解
1.什么是class文件
2.如何生成一个class文件
3.class文件的作用
4.class文件格式详解
class文件是能够被JVM识别，加载并且执行的文件格式（如Mp4，rmvb等一种格式）
class字节码文件只有java原代码能生成吗？不是的
上面这几种语言均可生成class文件 被jvm识别并且执行
如何生成的?
ide（eclispse，AndroidStudio，IntelliJ IDEA等等）会自动帮我们build生成（就是通过Javac）
build生成（就是通过Javac）
通过java命令去执行class文件（在ide直接run）
首先编写一个java类 hello.java
javac 编译生成class字节码文件
java命令运行class字节码文件
打印出来：hello，android！
class 文件的作用
记录一个类文件中的所有信息，记住是所有！
（类的名称，方法，变量等远远多于java源代码能看到的信息）
例如：为何我们在类中没有定义this supper这样的关键字，但是我们却可以使用这些关键字来调用我们父类的方法。
或者当前类的变量因为生成class字节码文件的时候，java虚拟机帮我们记录了当前类this关键字和父类supper关键字，所以我们才可以这样去使用。所以从这个答案中可以看出，class记录的信息远远多于java源代码。
class 文件结构
1.一种八字节的二进制流文件（）
2.各个数据按照顺序紧密排列，无间隙（可以减少class文件体积让我们的jvm加载class文件更加快速，有些文件是每多少字节就换行，让jvm加载class文件能更加的快速）
3.每个类或接口或枚举单独占据一个class文件，无需相互交叉
class文件弊端：
内存占用大，不适合移动端（class文件多）
堆栈的加载模式，加载速度慢
文件IO操作多，类查找慢（每个class类只存储了一个java源文件信息， 每次加载一个新的class文件都要去执行加载，寻找）所以不适用与移动端
那怎么办呢？dex文件出来了...
dex文件
什么是dex文件
如何生成一个dex文件
dex文件的作用
dex文件格式详解
能够被DVM识别，加载并执行的文件格式（用来存储文件代码 ）
与class文件一样，是能够被jvm识别的
dex是不是只能由java源文件生成？
不是的，也可以通过 C 和C++生成dex文件
表明安卓编程也可以用C和C++开发安卓应用程序
生成dex 文件
ide自动帮助我们生成（解压apk文件就可以看到）
手动通过dx命令去生成dex文件
手机运行dex文件至手机
dex文件作用：
记录整个工程中所有类文件信息，记住整个工程
下面简单看看dex如何手动生成的
生成dex文件（运行需要在手机中运行）
push到手机
在手机运行dex文件
/Users/zhangyan/Library/Android/sdk/build-tools/29.0.1
打印出内容：hello，android！！！
class与dex对比
两者异同
本质上他们都是一样的，都是从java源文件演变而来，dex文件是从class文件演变而来
class文件存在许多冗余信息，一个类就要有一个常量池
dex会去除冗余并整合 ，所有的源文件中所有的数据是存在一个数据区的，可以减少体积
class 包含多个 Header，Field，Method，Attributes
dex 只有一个Header，Fields，Method，Data
Java中的classLoad
Android中的classLoader
加载流程
动态加载 难点
有许多组件类需要注册才能使用（Activity,service注册以后才可以使用）
资源的动态加载很复杂（安卓把资源用对应的ID注册好，新类就不会添加进去 就会找不到资源，适配上很复杂）
安卓程序运行需要一个上下文环境
bug一般会出现在某个类的某个方法地方。如果我们能够动态地将客户手机里面的apk里面的某个类给替换成我们已经修复好的类。dex分包。
mutildex如何实现呢？实现的原理？
从Java的类加载机制来入手的。
classLoader安卓是如何加载classes.dex文件，启动程序。
public class PathClassLoader extends BaseDexClassLoader {用来加载应用程序的dex
public class DexClassLoader extends BaseDexClassLoader {可以加载指定的某个dex文件。（限制：必须要在应用程序的目录下面）
修复方案：搞多个dex。
第一个版本：classes.dex
修复后的补丁包：classes2.dex（包涵了我们修复xxx.class）
这种实现方式也可以用于插件开发。
2.如果可以解决这个问题：把两个dex合并---将修复的class替换原来出bug的class.
通过BaseDexClassLoader调用findClass(className)
Class findClass(String name)将修复好的dex插入到dexElements的集合，位置：出现bug的xxx.class所在的dex的前面。List of dex/resource (class path)
elements.Element[] dexElements;存储的是dex的集合最本质的实现原理：类加载器去加载某个类的时候，是去dexElements里面从头往下查找的。
fixed.dex,classes1.dex,classes2.dex,classes3.dex1
`BaseDexClassLoader类{ DexPathList pathList；}
`DexPathList类{ Element[] dexElements;}`
安卓源码链接 androidxref，自己可以去看看：
http://androidxref.com/4.4.2_r1/xref/libcore/dalvik/src/main/java/dalvik/system/BaseDexClassLoader.java
pathList
http://androidxref.com/4.4.2_r1/xref/libcore/dalvik/src/main/java/dalvik/system/DexPathList.java
Element[] dexElements;
原来的Element[] dexElements2;
合并以后的
1.找到MyTestClass.classdn_fix_ricky_as\app\build\intermediates\bin\MyTestClass.class
2.配置dx.bat的环境变量Android\sdk\build-tools\23.0.3\dx.bat
3.命令dx --dex --output=D:\Users\ricky\Desktop\dex\classes2.dex D:\Users\ricky\Desktop\
dex命令解释： output=D:\Users\ricky\Desktop\dex\classes2.dex
指定输出路径 ：
D:\Users\ricky\Desktop\dex最后指定去打包哪个目录下面的class字节文件(注意要包括全路径的文件夹，也可以有多个class)
有代表性的几个应用：
阿里系的解决方案：优酷和支付宝
腾讯系的解决方案： 微信
各有优劣各有所长，当前最流行的两种热修复的解决方案
/Users/zhangyan/Library/Android/sdk
1.阿里系：DeXposed andfix
从底层C的二进制来入手的。
2.腾讯系：tinker
Java类加载机制来入手的。
什么是热修复？
动态更新和修复app的行为
一般的bug修复，都是等下一个版本解决，然后发布新的apk。
热修复：可以直接在客户已经安装的程序当中修复bug。刚上线用户才更新完，又来了一个强制更新很容易让用户发火而流失热修复是一个亡羊补牢的做法，和发布版本高质量的版本和热修复完美搭配流行技术：
QQ控件的超级补丁方案
微信的Tinker
阿里的Andfix， dexposed
美团的robust ，ele的migo
百度的hotfix...
其中 qq和andfix是比较早的andfix是最简单的
andFix的局限性
不支持YunOS无法添加新类和新的字段需要使用加固前的apk制作补丁，但是补丁文件很容易被反编译，也就是修改过的类源码容易泄露。
使用加固平台可能会使热补丁功能失效。
微信的tinker是功能比较完善的;使用起来也是最复杂的。
tinker是最齐全的,其他都有一些缺陷如何选择：
1.需求是什么？需求是衡量一切的标准（技术咩有好坏，看能不能满足我们的需求）
2.能满足需求的情况下，开发成本低的
3.开发成本一样的情况下，优先选择大公司的方案（经得起市场的考验 一般都会有专门的人维护）
tinker （framwork java 替换dex包）
dex 分包 dex2（修复好的）用户下载dex2进行插队，加载class 是class1234进行加载的
（http://www.tinkerpatch.com/Docs/intro）
什么是 Tinker？
Tinker 是一个开源项目(Github链接)，它是微信官方的 Android 热补丁解决方案，它支持动态下发代码、So 库以及资源，让应用能够在不需要重新安装的情况下实现更新。
为什么使用 Tinker？
当前市面的热补丁方案有很多，其中比较出名的有阿里的 AndFix、美团的 Robust 以及 QZone 的超级补丁方案。但它们都存在无法解决的问题，这也是正是我们推出 Tinker 的原因。
Tinker |
QZone |
AndFix |
Robust |
|
类替换 |
yes |
yes |
no |
no |
SO替换 |
yes |
no |
no |
no |
资源替换 |
yes |
yes |
no |
no |
全平台支持 |
yes |
yes |
no |
yes |
即时生效 |
no |
no |
yes |
yes |
性能损耗 |
较小 |
较大 |
较大 |
较大 |
补丁包大小 |
较小 |
较大 |
一般 |
一般 |
开发透明 |
yes |
yes |
no |
no |
复杂度 |
较低 |
较低 |
复杂 |
复杂 |
Rom体积 |
Dalvik较大 |
较小 |
较小 |
较小 |
成功率 |
较高 |
较高 |
一般 |
最高 |
Tinker热补丁方案不仅支持类、So 以及资源的替换，它还是2.X－7.X的全平台支持。利用Tinker我们不仅可以用做 bugfix,甚至可以替代功能的发布。
Tinker 已运行在微信的数亿 Android 设备上，那么为什么你不使用 Tinker 呢？
什么是 TinkerPatch 平台？
Tinker 需要使用者有一个后台可以下发和管理补丁包，并且需要处理传输安全等部署工作，TinkerPatch 平台帮你做了这些工作，提供了补丁后台托管，版本管理，保证传输安全等功能，让你无需搭建一个后台，无需关心部署操作，只需引入一个 SDK 即可立即使用 Tinker。
此外，通过深入研究 Tinker 源码，TinkerTinkerPatch 平台在 Tinker的基础上加入了以下特性：
一键傻瓜式接入；无需理解复杂的热修复原理，一行代码即可接入热修复。实现了自动反射 Appliction 与 Library，使用者无需对自己的项目做任何的改动；
补丁管理；实现了热补丁的版本管理，补丁的自动重试与异常时自动回退等功能。同时我们可以简单实现条件下发补丁，在出现异常情况时，我们也可以快速回滚补丁；
编译优化；简化了 Tinker 的编译复杂度，实现了备份路径选择，功能开关等功能。
TinkerPatch 平台在 Github 为大家提供了各种各样的 Sample，大家可点击前往 [TinkerPatch Github].
为什么使用 TinkerPatch 平台？
市面上可能还有其他的一些热补丁服务，为什么我们需要选择TinkerPatch 平台呢？
研发实力雄厚；Tinker 在微信的数亿用户上得到验证，它的稳定性与性能值得信赖。TinkerPatch 平台作为 Tinker 项目贡献者与管理者之一，在 Tinker 基础上开发了许多方便使用者的特性；
服务全面快速；TinkerPatch 平台客户关于热修复使用过程的所有问题在工作日内一个小时内响应，提供您满意的服务；
稳定可靠；TinkerPatch 平台上传的补丁文件都会保存在七牛云存储上，客户端 APP 只跟七牛服务器通讯，支持高并发，CDN分布全国，速度和稳定性有保证。
也许你还想看
（▼点击文章标题或封面查看）
AndroidQ强制黑暗(ForceDark)模式实践
2020-01-02
干货！混合式架构App当中的通信安全
2019-10-17
ViewHolder的MVVM实现
2020-01-23
加入搜狐技术作者天团
千元稿费等你来！
戳这里！☛
您对本文有什么疑问吗？
点我写留言
▼▼▼
