# 本demo实现原理来自
https://github.com/dodola/HotFix
https://zhuanlan.zhihu.com/p/20308548
# Anti类功能,及其原理
如上图,A,B,C是三个class,它们在生成apk文件时,被打包入同一个dex文件中,当apk发布出去运行一段时间发现A类有个bug,现在使用上面链接中的修复方案修复bug。如文中所说,如果直接将A类重写,并使用运行时动态地将修复后的A类所在的dex文件加载并插入到加载链前,则A便可以修复。但是因为在优化的过程中,如果dex文件中的class都不依赖外部文件,则dex文件内部的class会被打一个CLASS_ISPREVERIFIED标签,这样当B类再使用修复后的A类时,因它在另一个dex文件中,则会报运行时错误。所以在B类中,添加一行代码使得它依赖另外一个dex中的Anti类,这样B就不会被打标签。值得注意的是,apk运行的真实环境中,因并不确定哪一(哪几)个类将来会出现问题,所以为了将来可以修复它(它们),上面的A,B,C类都应该被加上引用Anti的代码;另外,因为Anti所在的dex是在Application类的onCreate方法中被加载,所以Application类的onCreate方法前不该引用到Anti类。
# anti_dex.jar 和bug_dex.jar的制作
主要过程:java -> class -> dex
java -> class, 可以使用ide如AS,或者直接命令行使用jdk提供的编译工具
javac -source 1.7 -target 1.7 –cp . –d . <MAIN_CLASS>,该命令需要在包的同一级目录下执行,且MAIN_CLASS包含包路径名。
class -> dex, 可以使用dx工具,形如
dx --dex --output=classes_dex.jar <CLASS_PATH>
# 测试代码编写
@Override public void onCreate() { super.onCreate(); File dexPath = new File(getDir("dex", Context.MODE_PRIVATE), "anti_dex.jar"); Utils.prepareDex(this.getApplicationContext(), dexPath, "anti_dex.jar"); HotFix.patch(this, dexPath.getAbsolutePath(), "hotfix.test.com.example.didi.applicationtesthotfix.Anti"); dexPath = new File(getDir("dex", Context.MODE_PRIVATE), "bug_dex.jar"); Utils.prepareDex(getApplicationContext(), dexPath, "bug_dex.jar"); HotFix.patch(getApplicationContext(), dexPath.getAbsolutePath(), "hotfix.test.com.example.didi.applicationtesthotfix.BugClass"); try { Class<?> clazz = Class.forName("hotfix.test.com.example.didi.applicationtesthotfix.Anti"); equalLoader(clazz); Log.e("Ruby", "Anti ‘s classloader‘ hashCode " + clazz.getClassLoader().hashCode() + " , " + clazz.getClassLoader().getClass().getName()); Class<?> cla = Class.forName("hotfix.test.com.example.didi.applicationtesthotfix.BugClass"); equalLoader(cla); Log.e("Ruby", "BugClass ‘s classloader‘ hashCode " + cla.getClassLoader().hashCode() + " , " + cla.getClassLoader().getClass().getName()); } catch (Exception e) { } }
# 剔除Anti的编译脚本
因为Anti.class不能被使用AS一起打包入dex文件中,所以,在编译后打包工程的class文件成dex时,需要先将Anti.class删除,然后借助AS已近编译后的class文件和打包后的资源文件包自己命令行打包成apk文件。
# 打包class文件生成dex 文件 dx=/Users/didi/Library/Android/sdk/build-tools/23.0.3/dx classes=build/intermediates/classes/release/ $dx --dex --output=classes.dex $classes # 打包res/ assets/ 文件成 resources-release.ap_ 文件 (AS已完成) # 打包 resources-release.ap_ 和 classes.dex文件成 Hotfix-unsign.apk sdklib=/Users/didi/Library/Android/sdk/tools/lib/sdklib.jar apk=com.android.sdklib.build.ApkBuilderMain app/build/intermediates/res resources=build/intermediates/res/resources-release.ap_ java -classpath $sdklib $apk Hotfix-unsign.apk -u -z $resources -f classes.dex # 签名 keystore=/Users/didi/Documents/DidiChuxing/driver/lulei.keystore alia=lulei psw=demodebug jarsigner=/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/jarsigner $jarsigner -digestalg SHA1 -sigalg MD5withRSA -keystore $keystore -storepass $psw -keypass $psw -signedjar Hotfix-sign.apk Hotfix-unsign.apk $alia
# 运行时,动态热修复不行的原因
protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException { Class<?> clazz = findLoadedClass(className); if (clazz == null) { ClassNotFoundException suppressed = null; try { clazz = parent.loadClass(className, false); } catch (ClassNotFoundException e) { suppressed = e; } if (clazz == null) { try { clazz = findClass(className); } catch (ClassNotFoundException e) { e.addSuppressed(suppressed); throw e; } } } return clazz; }
从上面的ClassLoader源码中,可以看到,查找一个类时,先查看内存中该类是否加载,所以如果在加载修复后的类文件A前,已经使用了A类,则该方案就失败,所以该方案要在Application的onCreate方法中将A所在的dex预先load。
# “字节码修改”和 “编译依赖”方案的区别
原则上没有任何区别!
# google 分包方案,是什么鬼,分包策略是什么?
I still don’t know!
# 华为i7-ATH-AL00 android版本5.1.1 为什么不插入Anti代码也可以?
What? Fuck!!!
# 反思
虽然使用了自定义的DexClassLoader将修复后的class文件从文件中重新加载到内存中了,但是因为方案中是将DexClassLoader(的父类)的DexFile通过反射赋值给了PathClassLoader(的父类BaseClassLoader 的pathLists成员),所以查看修复后类的classLoader,仍然显示为系统的pathClassLoader。
demo 代码请参考 github地址