热修复/插件化/组件化-Andfix/Tinker源码简单解读及

2018-03-24 本文已影响105人 hanfengzqh

一、知识详解模块

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

插件化：将一个应用按照宿主插件的方式改造就叫做插件化

相关知识：

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源码简单解读及

猜你喜欢

热点阅读