您好,登录后才能下订单哦!
这篇“Android AndFix热修复原理是什么”文章的知识点大部分人都不太理解,所以小编给大家总结了以下内容,内容详细,步骤清晰,具有一定的借鉴价值,希望大家阅读完这篇文章能有所收获,下面我们一起来看看这篇“Android AndFix热修复原理是什么”文章吧。
当我们写了一个方法,那么这个方法是如何被执行的呢?
public int add(){ int a = 10; int b = 20; return a + b; }
其实方法的本质就是arm指令,在Android当中,dalvik或者art虚拟机的执行引擎会执行arm指令
add方法是java代码,java代码编译成class文件,还需要一步转换为dex文件,才能被Android虚拟机执行,dex文件包含了app的所有代码,因此方法也是存在dex文件中,那么通过dx命令,可以查看方法被编译成的字节码指令
dx --dex --verbose --dump-to=dex_method.txt --dump-method=Method.add --verbose-dump Method.class
Android中可以通过dx命令将class文件转换为dex文件,dx.bat位于Android SDK中的build-tools文件夹下,那么可以通过dx命令将class文件翻译成arm指令集
可以看一下,打印输出的arm指令集,ART执行某个方法的时候,执行的就是这个指令集,当apk安装的时候,dex文件会被dex2oat工具翻译成本地机器码(arm指令集)保存在oat文件中,当apk运行的时候oat会被加载到内存中,存在虚拟机的方法区中
执行的时候,会构建一个栈帧压入虚拟机栈中,然后每一个方法在ART中都对应一个ArtMethod(这个后边会说),ArtMethod中的invoke函数会找到当前方法对应的本地机器码执行,执行完成之后,栈帧出栈
关注点回到指令集上,在每一行指令前有一个数字,代表程序计数器记录的行号,精简之后的指令集(只保留每个行号的最后一个)
Method.add:()I: regs: 0002; ins: 0001; outs: 0000 0000: const/16 v0, #int 30 // #001e 0002: return v0 0003: code-address debug info line_start: 4 parameters_size: 0000 0000: prologue end 0000: line 4 0000: line 6 end sequence source file: "Method.java"
另外还有一种方式获取字节码,是通过javap获取,这种跟arm指令有啥区别呢?其实都是字节码,但是javap获取的字节码是JVM执行的字节码,Android虚拟机是Dalvik或者Art虚拟机,执行的是arm指令集
public int add(); descriptor: ()I flags: ACC_PUBLIC Code: stack=2, locals=3, args_size=1 0: bipush 10 2: istore_1 3: bipush 20 5: istore_2 6: iload_2 7: iload_1 8: iadd 9: ireturn LineNumberTable: line 4: 0 line 5: 3 line 6: 6
这两者有什么区别呢?我们看同是执行 10 + 20 ,JVM是先创建一个10变量,然后再创建20 ,最后将两个相加然后返回;但是从ART机器指令中可以看到是直接计算好了,然后创建v0 = 30,直接返回,所以:Android编译器在编译的过程中会做优化,提高执行的效率(这个可以自己去试一下,javac并没有做优化处理)
当一个class类加载进来之后,class类中有方法、成员变量等,这些类的信息加载的时候是放在方法区,当Java层调用某个方法时,ART虚拟机找到该方法对应的本地机器码指令,在虚拟机栈中,该方法栈帧入栈,CPU去读取每行指令,程序计数器+1,等到方法执行完毕,栈帧出栈。
之前我们介绍过阿里的AndFix或者Sophix是通过hook native层替换已经加载的类的方法,接下来我们着重看一下,AndFix热修复是怎么实现的
Method.add:()I: regs: 0002; ins: 0001; outs: 0000 0000: const/16 v0, #int 30 // #001e 0002: return v0 0003: code-address debug info line_start: 4 parameters_size: 0000 0000: prologue end 0000: line 4 0000: line 6 end sequence source file: "Method.java"
public class Method { public int add(){ int a = 10; int b = 20; return a + b; } } //调用 Method method = new Method(); method.add();
我们看下这个方法,通过Method对象去调用,method是在堆内存中,通过对象可以拿到类信息在方法区中。
当执行这个方法时,ART执行引擎从方法区中找到方法的本地机器指令,通过CPU执行得到结果,如果add方法中抛出异常导致app崩溃,那么如何修复?
既然要做到方法替换,首先必须要了解方法在虚拟机中的形态;其实前面有提到,方法在虚拟机中对应的结构体就是ArtMethod,每个方法在ART中对应一个ArtMethod。
# Android 10.0/art/runtime/art_method.h protected: GcRoot<mirror::Class> declaring_class_; std::atomic<std::uint32_t> access_flags_; uint32_t dex_code_item_offset_; uint32_t dex_method_index_; uint16_t method_index_; union { uint16_t hotness_count_; uint16_t imt_index_; }; // Fake padding field gets inserted here. // Must be the last fields in the method. struct PtrSizedFields { // Depending on the method type, the data is // - native method: pointer to the JNI function registered to this method // or a function to resolve the JNI function, // - conflict method: ImtConflictTable, // - abstract/interface method: the single-implementation if any, // - proxy method: the original interface method or constructor, // - other methods: the profiling data. void* data_; // Method dispatch from quick compiled code invokes this pointer which may cause bridging into // the interpreter. void* entry_point_from_quick_compiled_code_; } ptr_sized_fields_;
在ArtMethod中,有一个结构体PtrSizedFields,其中一个成员变量为entry_point_from_quick_compiled_code_,这个指针指向的就是在方法区中该方法本地机器码的内存地址,也就是说,如果想要实现热修复,那么就将entry_point_from_quick_compiled_code_指向正确的方法机器码指令地址即可。
除此之外,看下其他成员变量的含义:
declaring_class_:用来标记当前方法属于哪个类
access_flags_:当前方法的访问修饰符
hotness_count_:记录当前方法被调用的次数,如果超过某个限制,那么该方法就被标记为是热方法,这个与ART的编译模式相关
对于hotness_count_,这里需要说一下ART的编译模式,Dalvik的就先不介绍了
在Android 5.0之后,Android编译器由ART代替了Dalvik,采用了全新的编译模式AOT,代替JIT;
什么是AOT?就是全量编译,在APK安装的时候,会将所有的dex文件编译成本地机器码,然后在执行方法时会直接拿到相应的机器码执行,速度非常快,但是这也带来一些问题:
(1)安装时间长
因为在安装的过程中做全量的编译,耗时非常严重;早先的Android手机我们在安装的时候,进度条一直在转但就是装不上,这种是非常差的用户体验
(2)存储空间
因为全量编译的时候,dex被编译成机器码之后,保存在.oat文件中,10M的dex翻译成的机器码内存激增4-5倍,大量的文件保存在手机中会占据内存空间
所以在Android N之后,采用了混合编译模式,AOP + 解释 + JIT
全新的混编模式不再在APK安装的时候进行全量编译,而是会解释字节码,因此安装的速度很快;此外新增了一个JIT编译器,会在App运行的时候分析代码,把结果保存在Profile中,并且在空闲时间分析并编译这些代码;
接着上面的hotness_count_,其实用来记录这个方法被调用的次数,当超过某个阈值之后,这个方法会被标记为热代码,这些热方法在设备空闲的时候做编译,并保存在名为app_image的base.art文件中,这个art文件会在类加载之前加载到内存中,意味着当调用这个方法的时候,不再需要编译为机器码,而是直接执行拿到结果。
首先创建一个C++的模块,然后C++版本可选择个人熟悉的,我对C++ 11的一些特性比较熟悉
其实AndFix实现的关键,就是找到ArtMethod,在JNI层是能够实现的,通过JNIEnv的FromReflectedMethod函数
public class AndFixManager { //native热修复方法 public static native void fix(Method wrong, Method right); }
//fix对应的JNI接口 extern "C" JNIEXPORT void JNICALL Java_com_tal_andfix_AndFixManager_fix( JNIEnv *env, jclass clazz, jobject wrong, jobject right) { //获取ArtMethod env->FromReflectedMethod(wrong); }
其实在Java层调用的时候,是需要反射获取某个方法,也就是说,在Java层反射拿到的方法其实就是ArtMethod,只不过再底层的我们看不到,那现在就能看到了!
try { Class<?> clazz = Class.forName("com.tal.demo02.FixDemo"); Method run = clazz.getDeclaredMethod("run"); AndFixManager.fix(run,run); } catch (Exception e) { e.printStackTrace(); }
之前我们看源码的时候,可以看到ArtMethod.h中存在很多系统的头文件,全部导入工程中不现实
因为我们需要的是ArtMethod的一个结构体的成员变量,所以我们只需要针对性地导入即可,art_method.h如下;
#ifndef DEMO02_ART_METHOD_H #define DEMO02_ART_METHOD_H #endif //DEMO02_ART_METHOD_H #include "stdint.h" namespace art{ namespace mirror{ class ArtMethod final { public: uint32_t declaring_class_; std::atomic<std::uint32_t> access_flags_; uint32_t dex_code_item_offset_; uint32_t dex_method_index_; uint16_t method_index_; union { uint16_t hotness_count_; uint16_t imt_index_; }; struct PtrSizedFields { void* data_; void* entry_point_from_quick_compiled_code_; } ptr_sized_fields_; }; } }
最终在Java层调用JNI方法,执行到JNI层,获取到ArtMethod
extern "C" JNIEXPORT void JNICALL Java_com_tal_andfix_AndFixManager_fix( JNIEnv *env, jclass clazz, jobject wrong, jobject right) { //获取ArtMethod ArtMethod *artMethod = reinterpret_cast<ArtMethod *>(env->FromReflectedMethod(wrong)); }
这里通过断点可以看到,ArtMethod已经拿到了,而且关键信息entry_point_from_quick_compiled_code_,也就是arm指令集的内存地址拿到了!
public class FixDemo { public void run(){ throw new IllegalArgumentException(); } }
public class FixDemo { public void run(){ Log.e("TAG","已经被修复了"); } }
现在有一个场景就是,当执行FixDemo的run方法时抛出异常导致崩溃,这种场景下,使用热修复技术怎么修复呢,就是方法替换,arm指令集替换
public class AndFixManager { public static void bugFix(){ try { Class clazz = Class.forName("com.take.andfix.FixDemo"); Method wrong = clazz.getDeclaredMethod("run"); //正确的方法 Class clazz1 = Class.forName("com.take.andfix.fox.FixDemo"); Method right = clazz1.getDeclaredMethod("run"); AndFixManager.fix(wrong, right); }catch (Exception e){ } } public static native void fix(Method wrong, Method right); }
抛出异常的类是andfix包下的,当线上需要修复时,下发patch包,然后加载fox包下的方法,调用native fix方法
extern "C" JNIEXPORT void JNICALL Java_com_tal_andfix_AndFixManager_fix(JNIEnv *env, jclass clazz, jobject wrong, jobject right) { //获取ArtMethod ArtMethod *wrongMethod = reinterpret_cast<ArtMethod *>(env->FromReflectedMethod(wrong)); ArtMethod *rightMethod = reinterpret_cast<ArtMethod *>(env->FromReflectedMethod(right)); //方法替换 wrongMethod->declaring_class_ = rightMethod->declaring_class_; wrongMethod->access_flags_ = rightMethod->access_flags_; wrongMethod->dex_code_item_offset_ = rightMethod->dex_code_item_offset_; wrongMethod->dex_method_index_ = rightMethod->dex_method_index_; wrongMethod->method_index_ = rightMethod->method_index_; wrongMethod->ptr_sized_fields_.data_ = rightMethod->ptr_sized_fields_.data_; wrongMethod->ptr_sized_fields_.entry_point_from_quick_compiled_code_ = rightMethod->ptr_sized_fields_.entry_point_from_quick_compiled_code_; }
然后再次执行run方法
binding.sampleText.setOnClickListener { AndFixManager.bugFix() val fixDemo = FixDemo() fixDemo.run() } 打印出的结果:E/TAG: 已经被修复了
其实现在阿里的AndFix和Sophix已经不维护了,但是这种热修复的思想我们是需要了解的,尤其是通过hook native底层替换方法,能够帮助我们更好地了解JVM虚拟机和Android虚拟机。
在上面简单的demo中,我们是知道那个类的哪个方法发生异常,在代码中写死的,但真正的线上环境中,其实是不知道哪个类会报错,一般我们都会使用bugly,像crash跟anr都能够实时监控到
当app某个方法抛异常之后,通过bugly上报到后台,比如com.take.andfix.FixDemo这个类中的run方法抛出了异常,那么我们需要针对这个类的方法做修复,如果做到动态化,需要使用注解修饰这个修复类
/** * 修复类需要使用这个注解 */ @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface andfix { String clazz(); String method(); }
public class FixDemo { @andfix(clazz = "com.tal.andfix.FixDemo",method = "run") public void run(){ Log.e("TAG","已经被修复了"); } }
这样在热修复时,能够知道这个修复类要修复线上环境中那个类的哪个方法
在打包dex的时候,需要把整个包名路径下的class文件一起打包,通过命令行完成dex打包
dx --dex --output fix.dex /xxxx/Desktop/dx
将打包成功的dex修复包,放到sd卡中 :
dex文件的加载,通过DexFile实现,如果不熟悉可以看下源码,art虚拟机会将dex转换为odex,因此加载dex文件的时候,需要传入一个odex文件的缓存路径。
将dex文件加载到内存之后,可以获取到dex文件中全部的类,通过DexFile.loadClass就可以将这个类通过类加载器加载。
/** * dex文件加载,将dex文件加载到内存 * @param context * @param dexFile */ private static void loadFixDex(Context context, File dexFile) { try { DexFile odex = DexFile.loadDex( dexFile.getAbsolutePath(), new File(context.getCacheDir(), "odex").getAbsolutePath(), Context.MODE_PRIVATE ); Enumeration<String> entries = odex.entries(); while (entries.hasMoreElements()){ //全类名 String clazzName = entries.nextElement(); //加载类 Class aClass = odex.loadClass(clazzName, context.getClassLoader()); //处理类 if(aClass != null){ processClass(aClass); } } } catch (Exception e) { e.printStackTrace(); } }
这里会有一个问题,就是既然拿到了全类名,为什么不能通过方式1获取,而是需要通过方式2获取?原因就是,Class.forName是从当前apk中查找这个类,但是这个类是在dex文件中,是从服务端下发的,并没有放在apk中,因此通过Class.forName是找不到的,通过DexFile.loadClass才是真正加载类到了内存中
//方式1 Class.forName("xxxxxxxxxx") //方式2 odex.loadClass(clazzName, context.getClassLoader())
拿类之后,通过反射能够拿到修复类中的方法,当然不是每个方法都是需要被修复的,我们需要判断的是,上面是否有我们自定义的注解,如果有,那么就能够通过反射,拿到抛出异常的这个方法,因为注解上有我们传入的类名和方法名,最终调用JNI的接口实现动态替换方法
private static void processClass(Class aClass) { //获取方法上的注解 Method[] methods = aClass.getMethods(); for (Method method:methods){ andfix annotation = method.getAnnotation(andfix.class); if(annotation != null){ //如果存在这个注解,那么就执行方法替换 String clazz = annotation.clazz(); String method1 = annotation.method(); //获取wrong方法 try { Class<?> wrongMethodClass = Class.forName(clazz); //这里注意,修复类的方法,要和被修复的方法,参数一致!!!!! Method wrongMethod = wrongMethodClass.getDeclaredMethod(method1,method.getParameterTypes()); //动态方法替换 fix(wrongMethod,method); } catch (Exception e) { e.printStackTrace(); } } } }
一切准备就绪之后,可以通过加载dex补丁包来修复
binding.sampleText.setOnClickListener { // AndFixManager.bugFix() AndFixManager.loadFixDex( this, File(System.getenv("EXTERNAL_STORAGE"), "fix.dex") ) val fixDemo = FixDemo() fixDemo.run() }
这里可能会碰到一些加载SD卡中文件报错的问题,比如:
No original dex files found for dex location /sdcard/fix.dex
这里需要添加文件的读写权限,才能够保证有效的热修复,除此之外,在Android 10以上的版本,需要在清单文件中添加android:requestLegacyExternalStorage属性
android:requestLegacyExternalStorage="true"
通过这种hook native底层的方式,最大的优势在于能够真正实现热修复,不需要重新启动app就能够修复,但是存在的弊端也是比较明显的,就是兼容性问题,每个Android的版本,native层都会有变化,比如art_method.h,其实每个版本都是不一样的,我这次使用的就是Android 10中的art_method头文件,有兴趣的可以看看之前Android版本的头文件,其实还是有差别的,所以在做兼容性问题的时候,需要根据版本来适配不同的头文件
以上就是关于“Android AndFix热修复原理是什么”这篇文章的内容,相信大家都有了一定的了解,希望小编分享的内容对大家有帮助,若想了解更多相关的知识内容,请关注亿速云行业资讯频道。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。