杂谈
最近在研究gradle ,插件化~自己碰到的坑很多.今天先总结一下
以下这三个都研究过,原理都是一样的,区别就在于用哪个更方便.
在这里我会讲述一下,这里面的原理和自己爬的坑,以便大家理解,还有少爬坑~~
原理是需要懂得~
不然,你遇到错误不会解决,并且你始终会是初级工程师~
首先,按照顺序,介绍下目前三种热修复的方式:
1.Nuwa (基于gradle写的脚本,操作起来比较麻烦,需要拷贝和运行命令行~)
https://github.com/jasonross/Nuwa
2.andfix (看过~)
https://github.com/alibaba/AndFix
3.基于Nuwa和andfix升级的RocooFix(上线项目正在用)
有两种模式 静态修复某种情况下需要重启应用。2动态修复，无需重启应用即可生效。
https://github.com/dodola/RocooFix
一.热修复原理
Android 插件化技术
插件化其实就是class动态加载技术
其中,热修复就是讲dex,进行分包,然后让虚拟机先加载第一个dex,的过程.
当然,说永远比做简单,对,这就是我现在还不能像这些大师一样,动手写点为人民服务的东西,自己会努力的~~ ps(鸡汤):程序员靠手吃饭,而不是靠嘴~~
原理第一步:理解CassLoader,
Android 中有三个 ClassLoader, 分别为URLClassLoader、PathClassLoader、DexClassLoader。其中
URLClassLoader 只能用于加载jar文件，但是由于 dalvik 不能直接识别jar，所以在 Android 中无法使用这个加载器。
PathClassLoader 它只能加载已经安装的apk。
DexClassLoader 在虚拟机上加载 dex上面的类
DexClassLoader 包含有一个dex数组Element[] dexElements，其中每个dex文件是一个Element，当需要加载类的时候会遍历 dexElements，如果找到类则加载，如果找不到从下一个 dex 文件继续查找。
BaseDexClassLoader源码(大家可以自行研究):
http://androidxref.com/4.0.4/xref/libcore/dalvik/src/main/java/dalvik/system/BaseDexClassLoader.java
原理第二步:防止被打上CLASS_ISPREVERIFIED.
当dalvik在加载android程序时候,其实不是读的class文件,
而是首先对dex进行优化,生成Odex(Optimized dex )文件(为了适配不同硬件平台),
虚拟机在启动优化的时候，会有一个选项就是 verify 选项，当 verify 选项被打开的时候，就会执行一次校验，校验的目的是为了判断，这个类是否有引用其他 dex 中的类，如果没有，那么这个类会被打上一个 CLASS_ISPREVERIFIED 的标志。一旦被打上这个标志，就无法再从其他 dex 中替换这个类了。而这个选项开启，则是由虚拟机控制的。(引自张涛-开源实验室)
二.代码实现
RocooFix代码实现之app如何动态加载更新:合并dex:
实现原理和Nuwa一样~,只不过它对sdk进行了适配.
都是分别获取主应用和补丁的dex中的PathList.dexElements,然后将两者进行拼接(补丁包在最前面即, newEles[0] = element;),形成新的array,然后返回给classLoader.
private static final class V24 {
private static void install(ClassLoader loader, List<File> additionalClassPathEntries,
File optimizedDirectory)
throws IllegalArgumentException, IllegalAccessException,
NoSuchFieldException, InvocationTargetException, NoSuchMethodException, InstantiationException, ClassNotFoundException {
//寻找pathList,并且将私有变为可访问
Field pathListField = findField(loader, "pathList");
Object dexPathList = pathListField.get(loader);
//寻找寻找pathList的dexElements,并且将私有变为可访问
Field dexElement = findField(dexPathList, "dexElements");
Class<?> elementType = dexElement.getType().getComponentType();
Method loadDex = findMethod(dexPathList, "loadDexFile", File.class, File.class, ClassLoader.class, dexElement.getType());
loadDex.setAccessible(true);
//利用反射调用类中的方法
Object dex = loadDex.invoke(null, additionalClassPathEntries.get(0), optimizedDirectory, loader, dexElement.get(dexPathList));
Constructor<?> constructor = elementType.getConstructor(File.class, boolean.class, File.class, DexFile.class);
constructor.setAccessible(true);
Object element = constructor.newInstance(new File(""), false, additionalClassPathEntries.get(0), dex);
//将将两者进行拼接(补丁包在最前面即, newEles[0] = element;)
Object[] newEles = new Object[1];
newEles[0] = element;
expandFieldArray(dexPathList, "dexElements", newEles);
}
}
RocooFix代码实现之如何编译生成补丁包,强大的grooxy脚本构建项目:
如何逃过 虚拟机打上CLASS_ISPREVERIFIED ?
在RocooFixPlugin中作者采用了nuwa的字节码的方法
HotFixProcessors.processClass() 来避免这个问题.有兴趣的大家可 以研究一下
如何判定那个文件进行了改变?
在 project.task(rocooClassBeforeDex) 中
NuwaProcessor.processJar(hashFile, inputFile, patchDir, h ashMap, includePackage, excludeClass)
循环遍历工程中的全部类对每个类计算hash值,并写入到hashFile文件中.通过比较hashFile文件与原工程的hashFile(即这里的hashMap参数) ,得到所有修改过的类生成这些类的class文件,以及所有修改过的class文件的集合jar文件。
def path = inputFile.absolutePath
//借用nvwa的代码,就是找出哪些类是发生了改变，应该生成对应的补丁。
//如果不是support包或者引入的依赖库,则开始生成代码修改部分的hotfix包
if (NuwaProcessor.shouldProcessPreDexJar(path)) {
NuwaProcessor.processJar(hashFile, inputFile, patchDir, hashMap, includePackage, excludeClass)
}
/*循环遍历循环遍历工程中的全部类对每个类计算hash值,并写入到hashFile文件中.通过比较hashFile文件与原工程的hashFile(即这里的classHashMap参数) ,得到所有修改过的类生成这些类的class文件,以及所有修改过的class文件的集合jar文件。
*/ NuwaProcessor.processClasses(inputFile, includePackage, excludeClass, dirName, hashMap, patchDir)
def path = inputFile.absolutePath
if (path.endsWith(".class") && !path.contains("/R\$") && !path.endsWith("/R.class") && !path.endsWith("/BuildConfig.class")) {
if (NuwaSetUtils.isIncluded(path, includePackage)) {
if (!NuwaSetUtils.isExcluded(path, excludeClass)) {
//写入字节吗,防止被打上class_prevertified
def bytes = NuwaProcessor.processClass(inputFile)
path = path.split("${dirName}/")[1]
def hash = DigestUtils.shaHex(bytes)
hashFile.append(RocooUtils.format(path, hash))
if (RocooUtils.notSame(hashMap, path, hash)) {
def file = new File("${patchDir}/${path}")
file.getParentFile().mkdirs()
if (!file.exists()) {
file.createNewFile()
}
FileUtils.writeByteArrayToFile(file, bytes)
}
}
}
}
三.项目实践(具体项目请看我的github)
配置roccofix简单配置 请到https://github.com/dodola/RocooFix,
Use
public class RocooApplication extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
//打补丁
RocooFix.init(this);
}
}
//方案1：静态启用，一般在Application里加载补丁
/**
* 从Assets里取出补丁，一般用于测试
*
* @param context
* @param assetName
*/
RocooFix.initPathFromAssets(Context context, String assetName);
/**
* 从指定目录加载补丁
* @param context
* @param dexPath
*/
RocooFix.applyPatch(Context context, String dexPath);
//方案2：动态打补丁，立即生效，有性能问题，适用于补丁方法数较少的情况，建议在ART虚拟机里启用该模式
/**
* 从Asset里加载补丁，一般用于本地测试
* @param context
* @param assetName
*/
RocooFix.initPathFromAssetsRuntime(Context context, String assetName) ;
/**
* 从指定目录加载补丁
* @param context
* @param dexPath
*/
RocooFix.applyPatchRuntime(Context context, String dexPath) ;
Configuration
- 在root的
build.gradle增加如下内容：
repositories {
jcenter()
maven {
url "http://dl.bintray.com/dodola/maven"
}
}
dependencies {
classpath 'com.dodola:rocoofix:1.1’
}
- 在你项目的
build.gradle文件里添加如下配置
apply plugin: 'com.dodola.rocoofix'
repositories {
maven {
url "http://dl.bintray.com/dodola/maven"
}
}
rocoo_fix {
includePackage = ['com/dodola/rocoofix']//限制需要制作补丁的package
excludeClass = ['BaseApplication.class']//将不需要加到patch里的类写在这里
preVersionPath = '1'//注意：此项属性只在需要制作补丁的时候才需开启！！如果不需要制作补丁则需要去掉此项
enable = true//注意：关掉此项会无法生成Hash.txt文件
scanref=true//默认为 false，开启这个选项会将与补丁 class 相引用的 class 都打入包中来解决 ART 虚拟机崩溃问题，功能 Beta 中
}
dependencies {
compile 'com.dodola:rocoo:1.0'
}
这里主要介绍一下preVersionPath这个属性的作用。
rocoo_fix将制作补丁的步骤透明化，用户无需手动备份hash.txt文件，插件会自动根据当前的versionCode生成hash.txt和mapping.txt文件到指定目录，比如：
上一个版本发布的时候版本号是1，那么生成的文件会放在app源码目录/rocooFix/version1/[debug]|[release]的目录下，如果需要制作补丁那么在配置里指定preVersionPath 属性，它的值是上一个版本的版本号，这里的值是1，
然后将build.gradle的versionCode的号码修改，这里修改成2，只要和之前的版本不同就可以，没有具体值的要求
Proguard
-keep class com.dodola.rocoofix.** {*;}
-keep class com.lody.legend.** {*;}
Build Patch
下面演示一下使用项目demo生成补丁的制作过程
- 假如我们需要打补丁的文件是
package com.dodola.rocoosample;
public class HelloHack {
public String showHello() {
return "hello world";
}
}
此时build.gradle里的VersionCode是1
[图片上传失败...(image-592607-1530696731690)]
- 运行一次应用，这时会在
app的目录下生成如下文件：
[图片上传失败...(image-d0b3c9-1530696731691)]
这里可以看做是我们已经发布版本的hash.txt
- 假设我们需要修复步骤1 里的
showHello方法，修改如下：
package com.dodola.rocoosample;
public class HelloHack {
public String showHello() {
return "hello Hack";//此处修复，补丁加载后该方法返回hello hack
}
}
- 修改build.gradle 文件里
rocoo_fix项，让其执行patch 的task，配置如下
rocoo_fix {
preVersionPath = '1'//注意：这里指定的是需要打补丁的VersionCode
enable = true
}
- 修改当前项目的
versionCode为2，说明这个是一个升级fix版本。
[图片上传失败...(image-b29f96-1530696731691)]
- 正常发布应用，此时会在下图所示的路径中生成补丁文件：
[图片上传失败...(image-5f477e-1530696731691)]
- 我们可以反编译一下来确认补丁是否正常
[图片上传失败...(image-460fc5-1530696731691)]
四.注意
这边说几点注意事项:
1.注意代码混淆配置,如果项目第三方比较多,就比较蛋疼了...,
对于不会进行 proguard-rules的同学
1.Warning: can't find referenced field/method '...' in library class (or: can't find referenced classes..)
2.Warning: library class ... depends on program class ...
3.Warning: class file ... unexpectedly contains class ...
4. Warning:Ignoring InnerClasses attribute for an anonymous inner class
报错情况1,3:
大概意思是程序里面用到了库里的类，但库里没有这些类。所以警告了，同时，可以用命令来忽略这些警告。
只是忽略警告的话，实际上还是没有解决问题，后来查找了一些资料，发现是proguard在混淆的时候，把库里的jar包也混淆了，导致程序找不到这些类。于是解决方法就简单了，只需要在proguard.conf配置中用keep命令保留报警的类就行了。但是通常报警的类有成百上千个，不可能一个个保留，有一个简单的方法是只要类的路径前面有相同的根，就可以保留一个总的达到保留下面所有类的目的。比如：
解决办法:
1.-dontwarn org.springframework.** //报错的包路径
2.-keep class org.springframework.** { *;} //报错的包路径
报错情况2: 第2个问题与第一个类似，也是保留相应的类就可以了。 大概意思是类文件的目录名跟类的包名不一致导致了警报，需要确保目录和包名一样才行。特别是WEB-INF/classes目录下的文件需要打成jar包放到WEB-INF/lib 目录下。
我的这个问题正是出在WEB-INF/classes/....目录这儿，然后我把classes下的类打包放到了lib下，结果然并卵。后来又试了试，发现因为proguard会同时读取classes下的类和lib下的jar包，jar包像上面说的一样是没有问题的，但是classes下的类目录必然要带着classes，然而类名却不是以WEB-INF.classes开头，所以这个警报不可避免会出现。最后消除警报是在-injars里面添加过滤把classes下的类都过滤掉，还有别忘了把jar包添加到lib里。
解决办法:
-injars D:/OrbitService/target/OrbitService.war(!WEB-INF/classes/**)
报错情况4 : 出现这个问题的愿意很简单。
就是android sdk tools版本过低，升级一下就可以了
2.生成patch.jar的步骤
3.混淆一定要开.
至于没什么,因为涉及到hash和mapping,还有源码的脚本中
4.在实际项目中运用
进入app 请求服务器,看是否有补丁,以及补丁的版本,然后根据版本进行判断, 下载 调用 RocooFix.applyPatch(context, dexPath); , 同时 记录版本信息, 保存到 sharepreference, 然后悄悄的进行,下次启动再请求网络,得到数据,根据数据判断补丁版本是否对应, 然后进行上述操作~,
5.android热修复,原理是一样的,有些错误不认识,注意查看 message
![[译][Google工程师] 刚刚发布了 Fragment 的新特性 “Fragment 间传递数据的新方式” 以及源码分析](https://ucc.alicdn.com/pic/developer-ecology/b096da8ea89f40f9b79c5c95a9810390.png?x-oss-process=image/resize,h_160,m_lfit)
![[译][Google工程师] 详解 FragmentFactory 如何优雅使用 Koin 以及部分源码分析](https://ucc.alicdn.com/pic/developer-ecology/96102e1e00d44e8e85fd3a5d642f338d.png?x-oss-process=image/resize,h_160,m_lfit)
