热修复/插件化/组件化-Andfix/Tinker源码简单解读及相关知识剖析笔记

一、知识详解模块
1.dex/class深入讲解
2.jvm/dvm/art三个虚拟机的深入讲解
3.class Loader类加载器的深入讲解
二、热修复应用模块
1.热修复原理深入讲解
2.如何合理的接入开源的热修复框架
3.开源框架的原理及版本发布控制
三、插件化应用模块
1.插件化原理以及组件化的区别
2.如何将应用插件化
3.插件化能为我们带来那些好处

一、知识详解模块
1.Class文件结构深入解析(生成、执行)
2.dex文件结构深入解析(生成、执行)
3.Class与Dex的对比

Class文件是什么?如何生成、作用以及文件格式详解
其是能够被JVM虚拟机识别加载并执行的文件格式
(1)IDE编译器--build生成
(2)javac命令生成
(3)通过java命令去执行class文件 javac -target 1.6 -source 1.6 Hello.java
记录一个类文件的所有信息
Class文件结构解析:
(1)一种8字节的二进制流文件
(2)各个数据按顺序紧密的排列、无间隙
(3)每一个类或接口都独自占据一个class文件
http://blog.csdn.net/linzhuowei0775/article/details/49556621 Class类文件的结构   
u4 magic;  它的唯一作用是用于确定这个文件是否为一个能被虚拟机接受的Class文件
u2 minor_version;  次版本号
u2 major_version;  主版本号(java版本)
u2 constant_pool_count;  常量池的数量(这个容量计数是从1而不是从0开始)
cp_info constant_pool[constant_pool_count-1];  表类型数据集合,即常量池中每一项常量都是一个表,共有11种结构各不相同的表结构数据
u2 access_flags;  ----------------------------作用域
u2 this_class;  ------------------------------JVM生成的本类对象
u2 super_class;  -----------------------------JVM生成的父类对象
u2 interfaces_count;  ------------------------接口
u2 interfaces[interfaces_count];  
u2 fields_count;  ----------------------------变量
field_info fields[fields_count];  
u2 methods_count;  ---------------------------方法
method_info methods[methods_count];  
u2 attributes_count;  ------------------------属性
attribute_info attributes[attributes_count]; 

Class文件的弊端:
(1)内存占用大,不适合移动端
(2)JVM采用堆栈加载模式,加载速度慢
(3)文件IO操作多,类查找慢

Dex文件是什么?如何生成、作用、文件格式详解
其是一个能够被DVM识别,加载并执行的文件格式
(1)通过IDE自动--build生成
(2)通过DX命令生成dex文件 dx --dex --output Hello.dex Hello.class
(3)手动运行dex文件到手机 dalvikvm -cp /scard/Hello.dex Hello
记录整个工程中所有类文件的信息
Dex文件结构解析:
(1)一个8字节二进制流文件
(2)各个数据按照顺序紧密排列无缝隙
(3)整个应用中的所有Java源文件都放在一个Dex文件中
http://blog.csdn.net/feglass/article/details/51761902 Android Dex文件结构解析
主要分为三部分:文件头、索引区、数据区
header---文件头
         索引区
string_ids--字符串的索引 
type_ids ---类型索引
proto_ids --方法原型的索引
field_ids ----域的索引
method_ids ---方法的索引
数据区
class_def -----类的定义区
data -----------数据区
link_data -------链接数据区

Class与Dex的区别
(1)本质上两者是一样的,dex是从class文件演变过来的 dx --dex --output xx.dex xx.class
(2)class文件存在很多的冗余信息,dex会去除冗余并合并
(3)结构不一样

第二章 
1.JVM虚拟机结构解析
2.Dalvik与JVM的不同
3.ART与Dalvik相比有哪些优势


1.JVM虚拟机结构解析
(1)JVM整体结构讲解
(2)Java代码的编译和执行过程
(3)内存管理和垃圾回收

JAVA虚拟机、Dalvik虚拟机和ART虚拟机简要对比:
JVM:Java的跨平台性是由JVM来实现的,就是把平台无关的.class字节码翻译成平台相关的机器码,来实现的跨平台;
JVM在把描述类的数据从class文件加载到内存时,需要对数据进行校验、转换解析和初始化,最终才形成可以被虚拟机直接使用的JAVA类型,因为大量的冗余信息,会严重影响虚拟机解析文件的效率
DVM:为了减小执行文件的体积,安卓使用Dalvik虚拟机,SDK中有个dx工具负责将JAVA字节码转换为Dalvik字节码,dx工具对JAVA类文件重新排列,将所有JAVA类文件中的常量池分解,消除其中的冗余信息,重新组合形成一个常量池,所有的类文件共享同一个常量池,使得相同的字符串、常量在DEX文件中只出现一次,从而减小了文件的体积.
Dalvik执行的是dex字节码,依靠JIT编译器去解释执行,运行时动态地将执行频率很高的dex字节码翻译成本地机器码,然后在执行,但是将dex字节码翻译成本地机器码是发生在应用程序的运行过程中,并且应用程序每一次重新运行的时候,都要重新做这个翻译工作,因此,及时采用了JIT,Dalvik虚拟机的总体性能还是不能与直接执行本地机器码的ART虚拟机相比

ART:
Dalvik虚拟机执行的是dex字节码,ART虚拟机执行的是本地机器码
安卓运行时从Dalvik虚拟机替换成ART虚拟机,并不要求开发者重新将自己的应用直接编译成目标机器码,也就是说,应用程序仍然是一个包含dex字节码的apk文件。所以在安装应用的时候,dex中的字节码将被编译成本地机器码,之后每次打开应用,执行的都是本地机器码
JIT与AOT两种编译模式
JIT:即时编译技术,JIT会在运行时分析应用程序的代码,识别哪些方法可以归类为热方法,这些方法会被JIT编译器编译成对应的汇编代码,然后存储到代码缓存中,以后调用这些方法时就不用解释执行了,可以直接使用代码缓存中已编译好的汇编代码。这能显著提升应用程序的执行效率
AOT:
ART优点:
①系统性能显著提升
②应用启动更快、运行更快、体验更流畅、触感反馈更及时
③续航能力提升
④支持更低的硬件
ART缺点
①更大的存储空间占用,可能增加10%-20%
②更长的应用安装时间
总的来说ART就是“空间换时间”

JVM与DVM的对比:
(1)JAVA虚拟机运行的是JAVA字节码,Dalvik虚拟机运行的是Dalvik字节码
(2)Dalvik可执行文件体积更小
(3)JVM基于栈,DVM基于寄存器

注意:
在DVM虚拟机中,总是在运行时通过JIT把字节码文件编译成机器码,因此程序跑起来就比较慢,所以在ART模式(4.0引入,5.0设置为默认解决方案)上,就改为AOT预编译,也就是在安装应用或者OTA系统升级时提前把字节码编译成机器码,这样就可以直接运行了,提高了运行的效率。但是AOT的缺点,每次执行的时间都太长,且ROM空间占用有比较大,所以在Android N上google做了混合编译,即同时支持JIT+AOT。
简单来讲:安装的时候不做编译,而是JIT解释字节码,以便能够快速启动,在运行的时候分析运行过程中的代码以及区分“热代码”,这样就可以在机器空闲的时候对通过dex2aot这部分热代码采用AOT进行编译存储为base.art文件然后在下次启动的时候一次性把app image加载进来到缓存,预先加载代替用时查找以提升应用的性能,并且同一个应用可以编译数次,以找到“热”的代码路径或者对已经编译的代码进行新的优化。

JVM结构:
虚拟机内存区域分为:运行时数据区+(执行引擎+本地库接口+本地方法库)
运行时数据区:方法区、Java栈、Java堆、本地方法栈、程序计数器

Class文件----(通过类加载器子系统)-----加载到内存空间(方法区、JAVA堆、JAVA栈、本地方法栈)-------垃圾收集器(GC)
内存优化方案

JVM内存管理
1.JAVA栈(虚拟机栈):存储JAVA方法执行时所有的数据;存放基本型,以及对象引用。线程私有区域
其由栈帧组成,一个栈帧代表一个方法的执行,每个方法在执行的同时都会创建一个栈帧
JAVA栈帧--每个方法从调用到执行完成就对应一个栈帧在虚拟机中入栈到出栈
JAVA栈帧存储:局部变量、栈操作数、动态链接、方法出口.

2.JAVA堆:所有通过new创建的对象产生的内存都在堆中分配存放对象实例和数组,此区域也是垃圾回收器主要作用的区域。
特点:
是虚拟机中最大的一块内存,是GC要回收的部分
堆区内存:
Young generation(新创建的存储区)
Old generation(暂时用不到的,不可达的对象存储区)若是Young与Old都存储满了 就会爆出OOM异常
Permanent generation
分成两个的原因:有利于动态调整两个区域的大小
即时通信服务时调用MSG消息比较多,就可以把Young调整的大一些,这样便于内存的分配,加快对象的创建

3.本地方法栈:是专门为native方法提供服务的 虚拟机中的JIT即时编译单元负责本机系统中比如C语言或者C++语言和Java程序间的互相调用,
这个Native Method Stack就是用来存放与本线程互相调用的本机代码

4.方法区:存储被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的数据,是所有线程的共享区域。
也称为永久代(Permanent Generation)但随着Java8的到来,已放弃永久代改为采用Native Memory来实现方法区的规划。
此区域回收目标主要是针对常量池的回收和对类型的卸载

5.程序计数器:可看做是当前线程所执行的字节码的行号指示器;如果线程在执行Java方法,这个计数器记录的是正在执行的虚拟机字节码指令地址;
如果执行的是Native方法,这个计数器的值为空(Undefined)

垃圾回收:
垃圾收集算法(垃圾确认)
1.引用计数算法(JDk1.2之前提供)
优点:实现简单,判定效率高
缺点:两个不可达的对象相互引用,导致内存无法回收。
2.JDK1.2之后采用可达性算法(根搜索算法)---采用离散数学原理
从GC Roots为根节点一直向下遍历,找到下一个节点。。。。,这样找不到的就是不可达的,那这些就是垃圾,被垃圾回收器回收

引用的类型:
强引用(弱引用内存不足也不会回收,除非OOM,它是内存泄漏的主要原因之一)通常new产生的对象就是强引用
软引用(SoftReference内存充足时,保持引用,内存不足时,进行回收)
弱引用(WeakReference不管JVM的内存空间是否足够,总会回收该对象占用的内存)
虚引用

垃圾回收算发:(垃圾回收)
1.标记清除算法--
好处:不需要对象的移动,并且仅对不存活的对象进行处理
在存活对象比较多的情况下极为高效,效率问题,标记和清除两个过程的效率都不高
坏处:一般是使用单线程操作,直接回收不存活对象,会造成大量的不连续的内存碎片,从而不利于后续对一些对象的分配
2.复制算法
好处:在存活对象比较少时极为的高效,实现简单,运行高效;每次都是对整个半区进行内存回收,内存分配时也不需要考虑内存碎片等情况,只要移动堆顶指针,按顺序分配内存即可
坏处:需要一块内存空间作为交换空间
3.标记--整理算法--标记清除算法基础之上的一个算法,解决了内存碎片的问题,主要针对对象存活率高的老年代
4.分代收集算法---根据对象的存活周期的不同将内存划分为几块,一般是把Java堆分为新生代和老年代,这样就可以根据各个年代的特点采用最适当的收集算法。
在新生代中,每次垃圾收集时都会发现有大量对象死去,只有少量存活,那就选用复制算法,只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、
没有额外空间对它进行分配担保,就必须使用标记—清除算法或标记—整理算法来进行回收

垃圾回收的触发机制:(垃圾回收的时机)
java虚拟机无法再为新的对象分配内存空间了
手动调用System.gc()方法
低优先级的GC线程,被JVM启动时就会执行GC

Dalvik VM 与JVM的不同
1.执行的文件不同,一个是class的一个是dex的
2.类加载的系统与JVM区别较大
3.可以同时存在多个dvm
4.Dalvik是基于寄存器的,而JVM是基于堆栈的

Dalvik VM与ART的不同之处
DVM使用JIT(即时编译每次运行都会执行编译)来将节码转换成机器码,效率低
ART采用了AOT预编译技术,执行速度更快(JDK 1.9 代码的分段缓存技术,执行速度更快)
ART会占用更多的应用安装时间和存储空间

第三章:
Java中的ClassLoader回顾
Android中的ClassLoader的作用详解
Android中的动态加载比一般Java程序复杂在哪里

Android ClassLoader概述
Android中ClassLoader的种类
Android中ClassLoader的特点
ClassLoader源码讲解

Java中的ClassLoader回顾
BootstrapClassLoader: Load JRE\lib\rt.jar或者Xbootclasspath选项指定的jar包
ExtensionClassLoader: Load JRE\lib\ext\*.jar或者Djava.ext.dirs指定目录下的Jar包
AppClassLoader: Load CLASSPATH或者Djava.class.path所指定的目录下的类和Jar包
CustomClassLoader:通过java.lang.ClassLoader的子类自定义加载Class

Android中ClassLoader的种类
BootClassLoader:Load JRE\lib\rt.jar或者Xbootclasspath选项指定的jar包及Framework层的一些Class字节码文件
PathClassLoader:只能加载已经安装到Android系统中的apk文件(/data/app目录),是Android默认使用的类加载器。
DexClassLoader:可以加载任意目录下的dex/jar/apk/zip文件,比PathClassLoader更灵活,是实现热修复的重点。
BaseDexClassLoader:是PathClassLoader与DexClassLoader的父类

一个应用程序最少需要
BootClassLoader、PathClassLoader两个类加载器

特点及作用
双亲代理模型的特点
(先判断类是否是被当前的ClassLoader加载过,加载过则返回,没有加载过在去看其父类ClassLoader是否加载过,加载过返回,否的话,最终由其子类ClassLoader去加载)
这个特点也就意味着一个类被位于事务中的任意一个ClassLoader加载过,那么在今后的整个系统的生命周期中,该类就不会再重新被加载了,大大提高了类加载的一个效率。
类加载的共享功能(Framework里面的一些类一旦被顶层的ClassLoader加载过,就会保存在缓存里面,以后就不要重新加载了)
类加载的隔离功能(不同继承路径上的ClassLoader加载的类肯定不是同一个类,可以防止用户数据被篡改,防止自定义类冒充核心类库,以访问核心类库中的成员变量)

双亲委派机制的描述:
当某个特定的类加载器在接到类加载的请求时,首先将加载任务委托给父类加载器,依次递归,如果父类加载器可以完成类的加载任务,就成功返回;
只有父类加载器无法完成加载任务时,自己才去加载。
意义:防止内存中出现多份同样的字节码;例如:
比如两个类A和类B都要加载System类:
如果不用委托而是自己加载自己的,那么类A就会加载一份System字节码,然后类B又会加载一份System字节码,这样内存中就出现了两份System字节码。
如果使用委托机制,会递归的向父类查找,也就是首选用Bootstrap尝试加载,如果找不到再向下。这里的System就能在Bootstrap中找到然后加载,
如果此时类B也要加载System,也从Bootstrap开始,此时Bootstrap发现已经加载过了System那么直接返回内存中的System即可而不需要重新加载,这样内存中就只有一份System的字节码了

双亲委派机制也就是热修复在技术上可以实现的根本依据,即:多个dex文件组成一个数组Element[],按照顺序加载,对于一个已经加载的Class是不会再次加载的。

同一个ClassLoader加载过的类可以称之为同一个类(还要有相同的包名、类名)

Android ClassLoader加载顺序:
ClassLoader.java中 loadClass()方法,在该方法中判断是否是被加载过,若没有主要用到了findClass()方法,而在ClassLoader.java中,findClass()是一个空实现,于是到PathClassLoader,DexClassLoader中查看
发现两者都是共同父类BaseDexClassLoader中实现的,此时调用到了DexPathList对象的findClass()方法,而DexPathList对象实在BaseDexClassLoader的构造方法中通过new实现的,于是找到
DexPathList类的构造方法中找到makeDexElements()方法,该方法返回一个Element[]数组,在该方法makeDexElements()中遍历所有的Dex文件,调用loaddexFile()方法,在该方法中
返回了DexFile对象,并最终存到Element[]数组中。此时,再来看DexPathList对象的findClass()方法中遍历Element[]数组,对数组中的每一个Element元素(DexFile)调用DexFile对象的
loadClassBinaryName()方法返回一个Class对象,而loadClassBinaryName()最终调用的是Native方法defineClassNative()该方法是C与C++实现的。

Android动态加载的难点:
1.有许多组件类需要注册之后才能使用
2.资源的动态加载很复杂
3.Android程序运行时需要一个上下文环境

第四章热修复详解:
热修复的基本概念讲解
当前市面上比较流行的几种热修复技术
方案对比及技术选型

什么是热修复?
动态修复、动态更新
热修复有哪些好处
热修复的流行技术:

QQ空间的超级补丁方案
微信的Tinker
阿里的AndFix,dexposed(最新版本Sophix 3.2.0)
美团的Robust,饿了吗的migo,百度的hotfix

第五章 本章概述
AndFix的基本介绍
AndFix执行流程及核心原理
使用AndFix完成线上bug修复
AndFix源码讲解

https://www.cnblogs.com/wetest/p/7595958.html
https://segmentfault.com/a/1190000011365008
http://blog.csdn.net/lostinai/article/details/54694959


AndFix修复即时生效的原理:
腾讯系的方案为什么不能及时运行?
腾讯系的方案是基于类加载机制采用全量替换的原理完成的,由于类加载的双亲代理特点,已加载到内存中的Class是不会再次加载的。
因此,采用腾旭系方案,不会及时生效,不重启则原来的类还在虚拟机中,就无法加载新类,当再次启动的时候,去加载新合成的dex文件,以完成增量更新。
这样Tinker将新旧两个DEx的差异放在补丁包中,下发到移动端,在本地采用反射的原理修改dexElements数组,合成完整的dex文件。
但是全量替换会造成补丁包体积过大,因此,采用了Dexdiff算法,大大优化下发差异包的大小。
在Android N中完全废弃掉PathClassloader,而采用一个新建Classloader来加载后续的所有类,即可达到将cache无用化的效果。

AndFix的方案采用底层替换方案,即:通过修改一个方法包括方法入口地址在内的每一项数据,使之指向一个新的方法。
具体来讲就是:
通过反射机制得到所要替换的Method对象所对应的object,进而找到这个方法底层Java函数所对应ArtMethod的真实地址,把旧函数的所有变量都替换为新函数的
因为,每一个java方法在DVM/ART中都对应着一个底层Java函数,在Art模式中是:ArtMethod,ArtMethod记录了这个Java方法的所有信息,包括所属类、访问权限、代码执行地址等等。
通过env->FromReflectedMethod,可以由Method对象得到这个方法对应的ArtMethod的真正起始地址。然后就可以把它强转为ArtMethod指针,从而对其所有成员进行修改。
这样全部替换完之后就完成了热修复逻辑。以后调用这个方法时就会直接走到新方法的实现中了

AndFix兼容性的根源所在:
采用的Native替换方案:都是写死了ArtMethod结构体(Andfix是把底层结构强转为了art::mirror::ArtMethod),AndFix里面的ArtMethod是遵照android虚拟机art源码里面的ArtMethod构建的。
由于Android是开源的,各个手机厂商都可以对代码进行改造,而Andfix里ArtMethod的结构是根据公开的Android源码中的结构写死的,若是厂商对开源的ArtMethod结构体进行了修改,
和源码里面的结构体不一致,替换则出现了问题。

优化策略:
直接替换ArtMethod而不是直接替换,以解决兼容性问题,
即时生效带来的限制:只能是方法级别的替换,不能添加新的字段,不能增加方法,以防止在计算sizeOf()时出现差错。

AndFix支持从2.3到7.0的Android版本,包括ARM和X86架构,Dalvik和ART运行时,32位和64位
AndFix的实现原理是方法的替换,使得有Bug的方法永远都不会被执行到。(是阿里的热修复开源版本)当前最新的
热修复版本是阿里HotFix 3.0(Sophix 3.2.0)
https://help.aliyun.com/document_detail/61082.html?spm=a2c4g.11186623.6.547.3I5XDy Sophix 3.2.0的稳健接入
 
dexposed和andfix是alibaba的开源项目,都是apk增量更新的实现框架,目前dexposed的兼容性较差,只有2.3,4.0~4.4兼容,
其他Android版本不兼容或未测试,详细可以去dexposed的github项目主页查看,而andfix则兼容2.3~6.0,所以就拿这个项目来实现增量更新吧。

AndFix的集成阶段
Gradle添加依赖 compile 'com.alipay.euler:andfix:0.5.0@aar'
1.https://github.com/hanfengzqh/AndFix AndFix的GitHub地址
1.AndFix的 PatchManager 的初始化
mPatchManager = new PatchManager(context);
mPatchManager.init(Utils.getVersionName(context));//
//进行热修复之后,为了将SortedSet mPatchs中的Patch每一个文件取出调用mAndFixManager.fix();
mPatchManager.loadPatch();

2.加载我们的patch文件
if (mPatchManager != null) {
//网络有热修复文件(.apatch)时调用,将.apatch补丁文件,复制到包内/apatch/文件夹下,并将
//包内文件夹下的.apatch文件Patch文件,转换为调用loadPatch(Patch)方法
mPatchManager.addPatch(path);
}
AndFix的准备阶段
1.build一个有bug的old apk并安装到手机上
2.分析问题解决bug后,build一个new apk
补丁会生成一个以.apatch结尾的文件

AndFix bug修复的常用两条指令:
usage: apkpatch -f -t -o -k -p <***> -a -e <***> 新建
 -a,--alias     keystore entry alias.
 -e,--epassword <***>   keystore entry password.
 -f,--from        new Apk file path.
 -k,--keystore    keystore path.
 -n,--name       patch name.
 -o,--out         output dir.
 -p,--kpassword <***>   keystore password.
 -t,--to          old Apk file path.

usage: apkpatch -m -o -k -p <***> -a -e <***> 合并
 -a,--alias     keystore entry alias.
 -e,--epassword <***>   keystore entry password.
 -k,--keystore    keystore path.
 -m,--merge    path of .apatch files.
 -n,--name       patch name.
 -o,--out         output dir.
 -p,--kpassword <***>   keystore password.

Patch安装阶段:
1.将apatch 文件通过adb push 到手机上
2.使用户已经安装的应用load我们的apatch文件
3.load成功后验证我们的bug是否被修复

AndFix优劣:
1.原理简单,集成简单,使用简单,即时生效(Andfix采用的方法是,在已经加载了的类中直接在native层替换掉原有方法,是在原来类的基础上进行修改的)
2.只能修复方法级别的bug,极大限制了使用场景
http://blog.csdn.net/cocoooooa/article/details/51096613 Android 热修补方案(AndFix)源码解析 涉及到JNI层
https://yq.aliyun.com/articles/74598?spm=a2c4g.11186623.2.33.DpP3QL Android热修复升级探索——追寻极致的代码热替换

AndFix劣势补充:https://www.cnblogs.com/aimqqroad-13/p/5965683.html AndFix的限制因素
1.不支持YunOS在线推送。
2.不支持添加新的类和新的字段,(官网)不支持构造方法、参数数目大于8或者参数包括long,double,float基本类型的方法。
3.需要使用加固前的apk制作补丁,但是补丁文件很容易被反编译,也就是修改过的类源码很容易暴露
4.使用有些加固平台可能会使热补丁功能失效(亲测:360加固不存在该问题,是在dex外侧加一层壳)
5.andfix不支持布局资源等的修改(即:在热修复时新旧apk的版本号不可更改,只能一致,否则“.apatch”补丁包 无法生成)
6.潜在问题:加载一次补丁之后,out.apatch文件会copy到getFileDir目录下的/apatch文件夹中,
在下次补丁更新时,会检测补丁是否已经添加在apatch文件夹下,若是存在就不会复制加载sdcard的out.apatch
7.AndFix并没有提供多次修复的解决方案,需要自己封装
(1)https://www.jianshu.com/p/58fc4c2cb65a andfix 多次修改同一个方法报错的解决 Gradle引入方式
(2)https://yq.aliyun.com/articles/63774?spm=5176.10695662.1996646101.searchclickresult.49db6001ZX2cgM android 热修补之andfix实践(多次修复) Module
(2.1)有新补丁.apatch文件,调用mPatchManager.addPatch(patchPath)之后,将SD卡下下载的.apatch补丁文件删除掉,以避免启动都会复制加载一次。
(2.2)在addPatch()内部判断包内apatch/文件夹下存在的.apatch文件删除掉,以便放入新的.patch补丁文件
8.无安全机制

AndFix源码解析:
1.PatchManager是一个典型的外观模式,把api封装在其内部,只留下初始化init()/loadPatch()/addPatch()等方法
PatcthManager内部几个重要的成员变量:
AndFixManager 主要的修复工具类(譬如:removeOptFile()移除文件)
SortedSet mPatchs;里面放置了所有的patch补丁文件
在PatchManager构造方法里面就是各主要成员变量的初始化操作,以及创建 apatch与apatch_opt文件夹

2.init(appVersion)初始化操作过程中,完成对Patch文件的添加与删除操作集合mPatchs。
(1)若是版本号不同(即:版本升级了)就会把包内目录下的apatch与apatch_opt文件夹下的.apatch文件删掉
(2)若是版本号相同就把所有的.apatch文件转化为Patch文件添加到mPatchs里面,以便loadPatch()加载使用。

3.loadPatch()方法加载,调用loadPatch(Patch)最终调用mAndFixManager.fix()方法,
在该方法(存在于AndFixManager类里面)里面验证签名,若是签名验证通过则将Patch中的File转化为DexFile,
在while循环里面遍历DexFile文件,通过dexFile.loadClass()方法查找我们真正需要的Class
然后再调用fixClass()方法,在该方法内部通过反射获取有 MethodReplace.class 注解标记的方法
在调用 replaceMethod()完成方法替换,在该方法中调用AndFix.addReplaceMethod(src, dest);
最终调用native 方法 replaceMethod(),最终完成方法替换。
@AndFix/src/com/alipay/euler/andfix/AndFix.java
private static native void replaceMethod(Method src, Method dest);
src 需要被替换的原有方法;
dest 对应的就是新方法

4.addPatch(patchPath)最终也是调用了loadPatch(Patch)也是调用mAndFixManager.fix()方法
JNI层:
@AndFix/src/com/alipay/euler/andfix/AndFix.java
private static native void replaceMethod(Method src, Method dest);

@AndFix/jni/andfix.cpp
static void replaceMethod(JNIEnv* env, jclass clazz, jobject src,
        jobject dest) {
    if (isArt) {
        art_replaceMethod(env, src, dest);
    } else {
        dalvik_replaceMethod(env, src, dest);
    }
}

最终根据Method对象找到底层Java函数对应的ArtMethod的真实地址,完成方法的替换

必知必会:
AndFix的原理及执行流程
AndFix的集成及基本用法
AndFix组件化的思路和代码实现

第六章 Tinker的相关学习
1.Tinker的基本介绍
2.Tinker的执行原理及流程
3.使用Tinker完成线上bud修复
4.Tinker源码讲解

1.Tinker基本介绍:
开源项目,微信官方的Android热补丁解决方案,支持动态下发代码、so、资源,在不需要重新安装的情况下实现更新。
支持2.x-7.x版本

Tinker主要包含以下三个部分:
1.gradle编译插件:tinker-patch-gradle-plugin
2.核心SDK:tinker-android-lib
3.非gradle编译用户的命令行版本:tinker-patch-cli-1.9.1.jar

Tinker的核心原理
基于Android原生的ClassLoader,开发了自己的ClassLoader
基于Android原生的AAPT,开发了自己的AAPT
微信团队基于Dex文件格式,研发了自己的DexDiff算法

Tinker的优劣:
(1)Tinker不支持修改 AndroidManifest.xml,Tinker不支持新增四大组件
(2)由于Google Play的开发者条款限制,不建议在GP渠道动态更新代码
(3)在Android N上,补丁对应用的启动时间有轻微的影响
(4)不支持部分三星android-21机型
(5)对于资源替换,不支持修改 remoteView。例如transition动画,notification icon以及桌面图标。
https://github.com/Tencent/tinker/wiki  Tinker -- 微信Android热补丁方案

若出现资源变更,我们需要使用applyResourceMapping方式编译,这样不仅可以减少补丁包大小,同时防止remote view id变更造成的异常情况

Tinker集成阶段:
Gradle中添加Tinker依赖
在代码中完成对Tinker的初始化

因为Tinker需要监听Application的生命周期,在ApplicationLike委托对象里面可以完成Tinker对Application生命周期的监听。
通过ApplicationLike完成Tinker的初始化操作

准备阶段
1.build一个old.apk并安装到手机
2.修改一些功能之后,build一个new.apk

patch文件的生成:
1.命令行的方式完成patch的生成
各个文件的作用及命令参数讲解
通过使用tinker-patch命令生成patch文件
2.利用Gradle插件的方式完成patch包的生成

1.patch命令行方式:
java -jar tinker-patch-cli-1.7.7.jar -old old.apk -new new.apk -config tinker_config.xml -out output_path
(1)修改apk前后不一样的apk,修改资源文件
(2)tinker-config.xml中更改loader标签为ApplicationLike类中注解 @DefaultLifeCycle中的自定义application全路径
(3)修改加密文件、密码及别名及密码
(4)            android:value="tinker_id_b168b32"/>

2.Gradle插件配置生成
(1)gradle中正确配置tinker参数(非常重要)
(2)在android studio中直接生成patch文件

在ApplicationLike自定义类中的onBaseContextAttached()方法中
TinkerInstaller.install(ApplicationLike);//完成tinker初始化

调用
if (Tinker.isTinkerInstalled()) {
      TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(), patch);
}
完成patch补丁文件的加载//TinkerInstaller.onReceiveUpgradePatch();

几个重要的部分:
安全校验:无论是补丁合成还是补丁加载,我们都要进行必要的安全校验
版本管理:Tinker支持补丁升级,甚至是多个补丁不停的切换。这里要保证所有进程版本的一致性
补丁加载:通过反射加载我们合成的dex,so,资源文件等
补丁合成:这些都是在单独的patch进程中完成的,这里包括dex,so,资源,主要完成补丁包的合成与升级。
监听回调:在合成与加载的过程中,出现问题及时回调。

1.https://www.jianshu.com/p/6e09f0766af3 微信热补丁Tinker -- 补丁流程
2.http://blog.csdn.net/tyk9999tyk/article/details/53391519  Tinker 常见问题 

Tinker库中有什么类是不能修改的?
Tinker库中不能修改的类一共有25个,即com.tencent.tinker.loader.*类。加上你的Appliction类,只有25个类是无法通过Tinker来修改的
Tinker多补丁版本发布:
Tinker支持对同一基准版本做多次补丁修复,在生成补丁时,oldApk依然是已经发布出去的那个版本。
即补丁版本二的oldApk不能是补丁版本一,它应该依然是用户手机上已经安装的基准版本。

Tinker的高级功能:
1.Tinker如何支持多渠道打包
2.如何自定义Tinker行为
3.tinker使用过程中需要注意到的哪些问题

1.多渠道打包
(1)命令行方式智能一个渠道一个渠道的打tpatch
(2)gradle方式则只需简单的修改一下gradle脚本即可

步骤:
(1).在AndroidManifest.xml中添加 
        android:name="MY_CHANNEL"
        android:value="${MY_CHANNEL}" />
或者其他途径
(2).在build.gradle中添加productFlavor
productFlavors {//多渠道脚本支持
xiaomi {
    manifestPlaceholders = [MY_CHANNEL: "xiaomi"]
    buildConfigField "String", "AUTO_TYPE", "\"1\""
}
baidu {
    manifestPlaceholders = [MY_CHANNEL: "baidu"]
    buildConfigField "String", "AUTO_TYPE", "\"2\""
}
_360 {
    manifestPlaceholders = [MY_CHANNEL: "_360"]
    buildConfigField "String", "AUTO_TYPE", "\"3\""
}

productFlavors.all {
    flavor -> flavor.manifestPlaceholders = [MY_CHANNEL: name]
}
    }
(3).修改tinker脚本添加多渠道的目录tinkerBuildFlavorDirectory = "${bakPath}/tinkergradle-0218-12-22-06"
最重要的是拷贝目录,完成多渠道目录的拼凑

2.Tinker的自定义行为
(1)自定义PatchListener监听patch receiver事件 ,继承于 DefaultPatchListener
   作用:DefaultPatchListener implements PatchListener
   而PatchListener中只有onPatchReceived(String path)方法,因此自定义的必须得实现
   在该方法中调用int returnCode = patchCheck(path,patchMd5);当returnCode==0校验通过,就会调用
   TinkerPatchService.runPatchService(context, path);开启一个新的后台进程进行补丁合成
   
   校验patch文件是否合法;启动service去安装patch文件

(2)自定义TinkerResultService改变patch安装成功后的行为,继承于DefaultTinkerResultService extends AbstractResultService extends IntentService
   作用:决定在patch安装完成之后的后续操作,默认实现是杀死进程
   重写onPatchResult(PatchResult result)方法,删除杀死进程的方法,提高用户体验

Tinker自定义初始化个参数:
LoadReporter loadReporter = new DefaultLoadReporter(getApplicationContext());//patch加载阶段各种异常情况的监听回调
1.回调运行在加载的进程,它有可能是各个不一样的进程。我们可以通过tinker.isMainProcess或者tinker.isPatchProcess知道当前是否是主进程,patch补丁合成进程。
2.回调发生的时机是我们调用installTinker之后,某些进程可能并不需要installTinker

PatchReporter patchReporter = new DefaultPatchReporter(getApplicationContext());//patch文件合成阶段各种异常情况的监听回调
isUpgrade:区分补丁合成的类型。是由于文件丢失而发起的RepariPatch, 还是收到新的补丁而发起的UpgradePatch
patchListener = new CustomPatchListener(getApplicationContext());//反馈
PatchListener类是用来过滤Tinker收到的补丁包的修复、升级请求,也就是决定我们是不是真的要唤起:patch进程去尝试补丁合成。我们为你提供了默认实现DefaultPatchListener.java。
一般来说, 你可以继承DefaultPatchListener并且加上自己的检查逻辑,例如SamplePatchListener.java。
若检查成功,我们会调用TinkerPatchService.runPatchService唤起:patch进程,去尝试完成补丁合成操作。反之,会回调检验失败的接口。事实上,你只需要复写patchCheck函数即可。
若检查失败,会在LoadReporter的onLoadPatchListenerReceiveFail中回调。
public int patchCheck(String path, boolean isUpgrade)

AbstractPatch  abstractPatch  = new UpgradePatch();

TinkerInstaller.install(mAppLike,
loadReporter,patchReporter,
patchListener,CustomResultService.class,
abstractPatch);//完成tinker初始化
http://blog.csdn.net/tyk9999tyk/article/details/53391525 Tinker 自定义扩展 

Tinker的源码分析:
Tinker初始化过程中:
使用到了外观模式TinkerInstaller.install()、构建者模式Tinker tinker = new Tinker.Builder()、单例模式public static Tinker with(Context context)
Tinker的patch补丁文件的加载合成过程
TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(), patch);
最核心的方法就是
TinkerPatchService.runPatchService(context, path);开启一个新的后台进程进行补丁合成
TinkerPatchService extends IntentService
最终是在 onHandleIntent(Intent intent)方法中完成patch文件的加载与合成
调用public abstract boolean tryPatch(Context context, String tempPatchPath, PatchResult patchResult);方法
在UpgradePatch extends AbstractPatch的tryPatch()方法中分别调用
 if (!DexDiffPatchInternal.tryRecoverDexFiles(manager, signatureCheck, context, patchVersionDirectory, destPatchFile)) {
    TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch dex failed");
    return false;
}
if (!BsDiffPatchInternal.tryRecoverLibraryFiles(manager, signatureCheck, context, patchVersionDirectory, destPatchFile)) {
    TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch library failed");
    return false;
}

if (!ResDiffPatchInternal.tryRecoverResourceFiles(manager, signatureCheck, context, patchVersionDirectory, destPatchFile)) {
    TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch resource failed");
    return false;
}
完成dex,res,lib加载与合并

必知必会
Tinker两种集成使用方式
使用Tinker完成对应用的动态更新
如何自定义patch加载及加载完成后的行为

第七章 代码及版本发布管理
1.加入动态更新之后如何管理我们的代码分支
2.加入动态更新之后如何管理我们的发版节奏

分支管理(普通)
master分支
dev分支--开发分支
引入动态更新之后的分支管理
除了master分支和dev分支,引入hot_fix分支
hot_fix分支专门用来管理动态更新迭代

sourceTree git代码界面化管理软件
第八章 插件化讲解
1.插件化相关知识介绍
2.插件化原理与实践

1.插件化相关知识介绍
插件化产生的背景:
(1)app的体积原来越庞大,功能模块越来越多
(2)模块耦合度高,协同开发沟通成本极大
(3)方法数可能会超过65535,占用内存过大
(4)为了平行高效开发。

插件化的优点:
1)模块解耦,应用程序扩展性强
2)解除单个dex函数不能超过 65535的限制
3)动态升级,下载更新节省流量
4)高效开发(编译速度更快)

基于以上问题 如何解决?
1.将一个大的APK按照业务分割成多个小的APK
2.每一个小的APK即可以独立运行又可以作为插件运行
基于Android动态加载技术以上是可以实现的
插件化带来的优势:
业务模块基本完全解耦
高效并行开发(编译速度更快)
按需加载,内存占用更低等等

插件化的相关概念
宿主:主APP,可以加载插件,也称之为Host
插件:插件APP,被宿主加载的App,可以是与普通app一样的apk
插件化:将一个应用按照宿主插件的方式改造就叫做插件化

相关概念对比:
(与组件化对比)
组件化是一种编程思想,而插件化是一种技术
组件化是为了代码的高度复用性而出现的
插件化是为了解决应用越来越大而出现的
(与动态更新对比)
与动态更新一样,都是动态加载技术的应用
动态更新是为了解决线上bug或者小功能的更新而出现
插件化是为了解决应用越来越庞大而出现的

https://www.jianshu.com/p/1c5afe686d75 Android组件化框架设计与实践
https://segmentfault.com/a/1190000009577849 使用ARouter实现组件化
https://www.jianshu.com/p/c0eecbbf1481 谈谈App的统一跳转和ARouter
https://www.jianshu.com/p/7cb2cc9b726a [Alibaba-ARouter] 简单好用的Android页面路由框架
http://blog.csdn.net/zhaoyanjun6/article/details/76165252 Android 路由框架ARouter最佳实践   
 
组件化产生的背景:
1.代码量膨胀,不利于维护,不利于新功能的开发及测试
2.项目工程的构建速度慢
3.代码之间的耦合严重
4.做不到按需加载打包

组件化的优势:
代码简洁,冗余量少,维护方便,易扩展新功能。
提高编译速度,从而提高并行开发效率。
避免模块之间的交叉依赖,做到低耦合、高内聚。
引用的第三方库代码统一管理,避免版本统一,减少引入冗余库。
定制项目可按需加载,组件之间可以灵活组建,快速生成不同类型的定制产品。
制定相应的组件开发规范,可促成代码风格规范,写法统一。
系统级的控制力度细化到组件级的控制力度,复杂系统构建变成组件构建。
每个组件有自己独立的版本,可以独立编译、测试、打包和部署。

组件化与模块化的区别?
1.模块化关注点是功能,组件化的关注点是复用性,更加注重分离。
2.通常一个模块化包含几个组件
3.两者划分的粒度不一样,组件化粒度更小,组件化更加侧重于单一功能的内聚,偏向于解耦

组件化思路:首先就是解耦,形式就是每一个Module自己能够运行
组件分为两类:技术组件和业务组件
技术组件:合理封装,避免技术组件库过大;
业务组件:选择性依赖技术组件可以使得业务组件单独运行

组件化实施过程:
1.对于技术组件需要合理封装,减少之后可能存在的替换成本;
2.同时注意,将技术组件分为常用和非常用,可以选择自己需要的技术组件,避免一个统一的技术组件库过大;
3.将业务代码根据模块进行剥离,剥离成一个个的小模块;
4.单独的业务模块加上必要的技术组件,支撑在开发阶段的独立运行;
组件化难点:
1.技术组件的整理、抽离
2.一定要有的DisPatcher:提供隐式的跳转和模块间方法的调用能力;
3.组件的划分
4.调试及集成方式
组件化实战:构建中间层,只让组件对中间层单方面耦合,中间层不对其他模块发声耦合。

组件之间的通信问题:
通过接口+实现的结构进行组件间的通信。即:每个组件声明自己提供服务的 Service API,这些Service都是一些接口,
组件负责将这些Service 接口实现并注册到一个统一的路由Router中去。因此,如果要使用某个组件的功能,只需要向Router请求这个Service的实现。
在组件化架构设计图中 Common 组件就包含了路由服务组件,里面包括了每个组件的路由入口和跳转。

组件化的概念就类似于Binder通信

组件化下的UI跳转问题:
UI跳转也是组件通信的一种,一般通过短链的方式进行,跳转到具体的Activity。每个组件注册自己所能处理的短链Scheme和Host,并定义传输数据的格式,
然后注册到统一的 UIRouter 中,UIRouter 通过 Scheme 和 Host 的匹配关系负责分发路由。但目前比较主流的做法是通过在每个 Activity 上添加注解,
然后通过 APT 形成具体的逻辑代码。目前方式是引用阿里的 ARouter 框架,通过注解方式进行页面跳转。

动态加载技术:
动态更新/热更新/热修复
插件化

封装、设计模式----组件化

插件化相关原理讲解

相关知识:
android ClassLoader加载class文件原理
Java反射原理
android资源加载原理
四大组件加载原理
Gradle打包原理

一、插件化对Manifest清单文件的处理
宿主 ManiFest/Aar Manifest/Bundle Manifest....------(合并Merge APK Manifest)---->(解析Bundle BundleInfoList)
流程:
1.构建期进行全量Merge操作
2.Bundle的依赖单独Merge,生成Bundle的Merge manifest
3.解析各个Bundle的Merge Manifest,得到整包的BundleInfoList

二、插件化框架对插件类的加载
插件化框架为插件类提供其加载所需的ClassLoader,用来完成插件类的加载
插件化框架提供ClassLoader进行插件类加载,涉及到两个问题:
1.如何定义ClassLoader加载类文件,继承DexClassLoader
2.如何调用插件APK文件中的类
即:创建了ClassLoader并且能够加载插件中的类,才能算得上是有用的ClassLoader

三、资源加载
1.若资源只有文件名File Name,则需要AssetManager通过文件名直接加载对应的资源。
2.若资源有对应的Resource ID(譬如:图片、动画、字符串等是会生成Resource ID的)因此需要使用到
Resources这个类完成对应资源文件的加载,加载完之后再使用AssetManager完成对资源文件的读写

以上可以得知:要想完成资源的加载需要用到Resources与AssetManager两个类
而安装到系统中的APK通过Context就可以完成对这两个类的直接引用,从而完成对资源的加载
而插件类的资源文件,因为插件并没有安装,因此这些插件类就没有自己的资源相关的Resources与AssetManager,因此这两个类就需要插件化框架帮我们完成动态的去创建

当前流行的插件化框架加载资源文件,是为每一个Bundle(插件)分别创建一个AssetManager完成对应插件的加载。
在插件被调用的时候将插件的Res,So等的资源文件目录路径,通过反射的方式加入到AssetManager,这样我们的AssetManager就知道了插件res,so资源文件存放路径,因此
插件化对资源加载的核心原理是:
想办法为每一个插件创建对应的AssetManager,加载插件中的资源路径

插件化的核心技术:
1.处理所有插件Apk文件中的Manifest文件(Bundle Manifest 合并到宿主Manifest)
2.管理宿主apk中所有的插件apk信息(因为不止有一个插件)
3.为每一个插件apk创建对应的类加载器,资源管理器,以完成对插件资源的加载

第九章 插件化框架实战
市面上现有的插件化框架介绍
具体使用一种框架完成插件化改造

市面上插件化框架
360手机助手的DroidPlugin框架
百度的dynamic-load-apk框架
个人开发者林光亮的Small框架
alibaba开源的Atlas框架

使用Small对项目进行改造
集成:
1.按照规则创建对应的project
2.在创建好的project build.gradle中集成编译插件gradle-Small
文件末尾引用gradle-small插件:apply plugin: 'net.wequick.small'
用gradlew small 验证集成是否正确>
3.在工程的宿主module中初始化Smal在自定义Application中 Small.preSetUp(this);

插件创建阶段
一、以指定的规范来创建插件
Module name 以 app.* 命名的模块将被 Small 在 编译时 识别为应用插件模块。
Package name 以 app* 结尾的插件将被 Small 在 运行时 识别为应用插件
二、编译创建好的插件
(1)先编译公共库 gradlew buildlib -q (宿主是一个最基础的公共库)
(2)再编译app.main插件 gradlew buildBundle -q Dbundle.arch=arm
(3)查看编译完成的具体情况  gradlew small
至此,我们已经完成插件编译并将之内置到宿主包中去了

三、通过宿主应用启动插件应用
(1)新建assets目录,在该文件夹下创建路由配置文件 bundle.json;
(2)修改bundle.json,添加路由:
{
  "version": "1.0.0",
  "bundles": [
    {
      "uri": "main",
      "pkg": "com.example.appmain"
    }
  ]
}

这里的:
version,是 bundle.json 文件格式版本,目前始终为 1.0.0
bundles,插件数组
uri,插件唯一ID
pkg,插件包名
通过这个配置,main 将被路由向 com.example.mysmall.appmain#MainActivity

(3)回到宿主的 app > java > com.example.mysmall > MainActivity,在 onStart 方法中我们通过上述配置的 uri 来启动 app.main 插件:

@Override
protected void onStart() {
    super.onStart();
    Small.setUp(this, new Small.OnCompleteListener() {
        @Override
        public void onComplete() {
            Small.openUri("main", MainActivity.this);
        }
    });
}
(4)运行宿主
需要掌握的small集成此基础:
通过 build.gradle 集成 Small
通过 自定义Application 初始化 Small
通过 buildLib,buildBundle 编译 Small 插件
通过 bundle.json 配置插件路由
通过 Small.openUri 启动插件

业务类插件/公共库插件创建
(1)创建公共库插件模块
Lib.style
Module name: lib.style
Package name: com.example.libstyle
(2)添加公共库引用
修改 app.main/build.gradle,增加对 lib.style 的依赖:
dependencies {
    ...
    compile project(':lib.style')
}
(3)添加插件路由
修改 app/assets/bundle.json:
{
  "pkg": "com.example.libstyle"
}
(4)重新编译插件
清除公共库:
./gradlew cleanLib -q
编译公共库:
./gradlew buildLib -q -Dbundle.arch=x86
编译业务单元:
./gradlew buildBundle -q -Dbundle.arch=x86
(5)重新运行程序

Small进阶教程
公共库插件模块
公共库插件模块在 开发时 可以通过 compile project(':插件模块名')来被 应用插件模块 所引用。
同时在 编译时 (buildLib) 会被打包成为一个可独立更新的插件。
定义公共库插件模块有两种方式:

指定 Module name 为 lib.*
在 Small DSL 中显式指明 bundles lib your_module_name
要正确读取到打包的公共库插件也有两种方式:

指定 Package name 为 **.lib.* 或 **.lib*
在 bundle.json 中添加描述 "type": "lib"

应用插件模块
应用插件模块在 开发时 可以独立运行。
同时在 编译时 (buildBundle 或 :模块:aR ) 会被打包成一个可独立更新的插件。
定义应用插件模块有两种方式:
指定 Module name 为 app.*
在 Small DSL 中显式指明 bundles app your_module_name
要正确读取到打包的公共库插件也有两种方式:

指定 Package name 为 **.app.* 或 **.app*
在 bundle.json 中添加描述 "type": "app"

自定义资源ID分段
在整合插件资源的过程,为避免资源ID冲突,需要为每个插件分配一个ID段。

我们知道默认程序的ID段为 0x7f。由于系统使用了 0x00,0x01,0x02。因此插件允许的范围在 [0x03, 0x7e] 之间。

但是有些手机厂商占用了一些分段,黑名单如下:
ID 厂商
0x03 HTC
0x10 小米
为此,Small 根据哈希算法将插件的模块名散列到 [0x11, 0x7e] 区间,作为自动分配的插件资源ID段,比如:

模块名 ID
app.main 0x77
lib.style 0x79
但是,这个算法生成的ID有可能是重复的,所以必要时你可以通过以下方法自定义插件的资源ID。

修改 build.gradle

在插件模块所在的 build.gradle 脚本里,增加配置:

ext {
    packageId = 0x12
}
这里的 0x12 是16进制整型值
将把当前插件的资源ID段分配为 0x12。
或修改 gradle.properties

在插件模块所在的 gradle.properties 配置里,增加配置:
packageId=3f
properties只接收字符串值
将把当前插件的资源ID段分配为 0x3f。
http://code.wequick.net/Small/cn/home Small开发文档
必知必会
Samll的基本用法:集成、插件化生成、宿主配置
将已有项目改造成插件化架构
Samll的进阶知识,做到对Samll有一个全面的了解

Atlas框架讲解
重量级框架 非常复杂

Atlas的基本概念和作用
了解Atlas的整体结构和原理
Alibaba独立开发并开源的一种插件化技术方案,也叫动态组件化(Dynamic Bundle)框架
目前手机淘宝和优酷使用的是这种技术方案
功能强大但是使用特别复杂,适用于门户型的App,它主要提供了解耦化、组件化、动态性的支持
核心原理与Samll是完全一样的

与插件化框架不同的是,Atlas是一个组件框架,Atlas不是一个多进程的框架,他主要完成的就是在运行环境中按需地去完成各个bundle的安装,加载类和资源

Atlas的整体结构和原理
https://alibaba.github.io/atlas/principle-intro/Runtime_principle.html

框架层次:
包含四个层次
1.最下面的一层:hack工具层,主要是进行hack工具类的初始化和校验工作
2.Bundle Framework 负责bundle的安装更新以及管理整个bundle的生命周期
3.runtime层:主要包括清单管理、版本管理、系统代理三大模块,基于不同的触发点
按需执行bundle的安装和加载。从delegate层可以看到,最核心的两个代理点:
一个是DelegateClasssLoader,负责路由由class加载到各个bundle内部,
一个是DelegateResource:负责资源查找时能够找到bundle内的资源,这是bundle能够真正运行起来的的根本点。
4.对外接入层:AtlasBridgeApplication是atlas框架下apk的真正Application,在基于Atlas框架构建的过程中会替换原有manifest中的application,AtlasBridgeApplication里面除了完成了Atlas的初始化功能,同时内置了multidex的功能,这样做的原因有两个:

很多大型的app不合理的初始化导致用multidex分包逻辑拆分的时候主dex的代码就有可能方法数超过65536,AtlasBridgeApplication与业务代码完全解耦,所以拆分上面只要保证atlas框架在主dex,其他代码无论怎么拆分都不会有问题;
如果不替换Application,那么atlas的初始化就会在application里面,由于基于Atlas的动态部署实际上是类替换的机制,那么这种机制就会必然存在包括Application及其import的class等部分代码在dalvik不支持部署的情况,这个在使用过程中造成一定成本,需要小心的使用以避免dalivk内部class resolve机制导致部分class没成功,替换以后该问题得到最好的解决,除atlas本身以外,所有业务代码均可以动态部署

Bundle的生命周期:
Installed bundle被安装到storage目录
Resolved classloader被创建,assetpatch注入DelegateResoucces
Active bundle的安全校验通过;bundle的dex检测已经成功dexopt(or dex2oat),resource已经成功注入
Started bundle开始运行,bundle application的onCreate方法被调用
每一层都为上一层次提供服务

类加载机制
Atlas里面通常会创建了两种classLoader,第一个是DelegateClassLoader,他作为类查找的一个路由器而存在,本身并不负责真正类的加载;DelegateClassLoader启动时被atlas注入LoadedApk中,替换原有的PathClassLoader;第二个是BundleClassLoader,参考OSGI的实现,每个bundle resolve时会分配一个BundleClassLoader,负责该bundle的类加载。关系如下图所示: DelegateClassLoader以PathClassLoader为parent,同时在路由过程中能够找到所有bundle的classloader;

BundleClassLoader以BootClassLoader为parent,同时引用PathClassLoader,BundleClassLoader自身findClass的顺序为

1. findOwn: 查找bundle dex 自身内部的class
2. findDependency: 查找bundle依赖的bundle内的class
3. findPath: 查找主apk中的class
Bundle的Activity启动的类加载过程来帮助理解:
ActivityThread从LoadedApk中获取classloader去load Activity Class;
根据上面的classloader关系,先去parent里面加载class;
由于class在bundle里面,所以pathclassloader内查找失败,接着delegateclassloader根据bundleinfo信息查找到classloader在bundle中(假设为bundleA);
从bundleA中加载class,并且创建class;
后面在Activity起来后,如果bundleA对bundleB有依赖关系,那么如果用到了bundleB的class,又会根据bundlA的bundleClassloader的dependency去获取bundleB的classloader去加载; 

资源加载机制:
类似ClassLoader,LoadedApk中的Resources被替换成Atlas内部的DelegateResources,同时在每个Bundle安装的过程中,每个bundle的assetspath会被更新到DelegateResources的AssetsManager中;每个bundle的资源特征如图可知:

bundle构建过程中,每个bundle会被独立进行分区,packageId保证全局唯一,packageID在host的构建工程内会有个packageIdFile.properties进行统一分配;
虽然每个bundle的manifest都声明了自己的packagename,但是在aapt过程中,arsc文件里面所有bundle的packagename均被统一为hostApk的package,比如在手淘内就都是com.taobao.taobao;这样改的目的是为了解决在资源查找中一些兼容性问题;

名词解释:
Bundle
awb
host
remote bundle
动态部署
Bundle: 类似OSGI规范里面bundle(组件)的概念,每个bundle有自己的classloader,与其他bundle相隔离,同时Atlas框架下bundle有自身的资源段(PackageID,打包时AAPT指定);另外与原有OSGI所定义的service格式不同之处是Atlas里面Bundle透出所有定义在Manifest里面的component,随着service,activity的触发执行bundle的安装,运行。

awb: android wireless bundle的缩写,实际上同AAR类似,是最终构建整包前的中间产物。每个awb最终会打成一个bundle。awb与aar的唯一不同之处是awb与之对应有个packageId的定义。

host: 宿主的概念,所有的bundle可以直接调用host内的代码和资源,所以host常常集合了公共的中间件,UI资源等

基于Atlas构建后大致工程的结构:

首先有个构建整体APK工程Apk_builder,里面管理着所有的依赖(包括atlas)及其版本,Apk_builder本身可能不包含任何代码,只负责构建使用
host内部包含独立的中间件,以及一个Base的工程,里面可能包含应用的Application,应用icon等基础性内容(如果足够独立,application也可以直接放在apk_builder内);
业务层基本上以bundle为边界自上而下与host发生调用,同时bundle之间允许存在依赖关系;相对业务独立的bundle如果存在接口耦合建议封装成aidl service的方式保证自身封装性;同时某些中间件如果只存在若干bundle使用的也可以封装bundle的方式提供出来,以保证host内容精简
remote bundle: 远程bundle,远程bundle只是apk构建时并未打到apk内部,而是单独放在了云端;同时远程bundle的限制条件是第一次被触发的前提是bundle内的Activity需要被start,此时基于Atlas内的ClassNotFoundInterceptorCallback可以进行跳转的重定向,提示用户下载具体bundle,待用户确定后进行异步下载同时完成后再跳转到目标bundle(此部分代码由于涉及下载及UI展示等内容并未包含在开源仓库中,有需要可以根据ClassNotFoundInterceptorCallback自行实现)

动态部署: 基于Atlas的installorUpdate和atlas-update库及构建插件,可以生成与之前发布的apk diff生成的差异文件,在更新时拉取同时静默更新到设备上,在用户下次启动之后生效新代码,具体原理可以参考动态部署章节的解析

APK结构:
基于Atlas构建后的APK结构如下图,host与普通Apk无异,但是Manifest和assets会添加一些额外的内容,同时在armeabi目录中会增加若干个bundle构建的产物,取名为String.format(lib%s.so,packagename.replace(".","_"));packagename为bundle的AndroidManifest中的packagename,这些so都是正常的apk结构,改为so放入lib目录只是为了安装时借用系统的能力从apk中解压出来,方便后续安装

assets/bundleinfo-version.json
构建完的apk在host的assets目录下,会有个bundleinfo-verison.json的文件,其中version为manifest中的versinonname,里面记录了每个bundle大小,版本,名字以及里面所有的component信息,这些内容在构建的时候生成,基于这些信息每个bundle可以在component被触发的时候去按需的进行安装,整个过程对开发者透明(从中也可以看到默认情况下bundle对外暴露的只是基于Android原生的Activity,service,receiver等component)

AndroidManifest

运行期文件结构
/data/data/pkgname/files/bundlelisting
之前打包构建时记录的bundleinfo信息(发生动态部署收文件会进行更新)
/data/data/pkgname/files/baselineinfo
存放动态部署后的版本变化内容,以及每次部署发生更新的bundle的版本,依赖等信息
/data/data/pkgname/files/storage

storage目录是bundle安装的目录,每个bundle的安装目录以bundle的packagename为文件夹名,首次启动后会安装到version.1目录下,目录中可能含有bundle的zip文件,dex文件以及native so等内容。如果bundle发生更新,则可能会有version.2、version.3 等目录,每次加载bundle的时候选取最高可用版本进行载入。考虑bundle的回滚功能和对空间占用的影响,目前容器内最多保留两个最近可用版本。



你可能感兴趣的:(热修复/插件化/组件化-Andfix/Tinker源码简单解读及相关知识剖析笔记)