AndFix 源码分析之二
2017-05-05 21:48
246 查看
4,PatchManager加载修复包
PatchManager的loadPatch调用流程如下,loadPatch方法如下,
public void loadPatch() { mLoaders.put("*", mContext.getClassLoader());// wildcard Set<String> patchNames; List<String> classes; for (Patch patch : mPatchs) { patchNames = patch.getPatchNames(); for (String patchName : patchNames) { classes = patch.getClasses(patchName); mAndFixManager.fix(patch.getFile(), mContext.getClassLoader(),classes); } } }
从mPatchs集合中逐个取出修复包, 然后调用AndFixManager的fix方法进行加载,
public synchronized void fix(File file, ClassLoader classLoader, List<String> classes) { if (!mSupport) { // 如果不支持热修复,直接返回 return; } if (!mSecurityChecker.verifyApk(file)) {// security check fail return; // 如果修复包校验不通过,直接返回 } try { File optfile = new File(mOptDir, file.getName()); boolean saveFingerprint = true; if (optfile.exists()) { if (mSecurityChecker.verifyOpt(optfile)) { saveFingerprint = false; } else if (!optfile.delete()) { return; } } final DexFile dexFile = DexFile.loadDex(file.getAbsolutePath(), optfile.getAbsolutePath(), Context.MODE_PRIVATE); if (saveFingerprint) { mSecurityChecker.saveOptSig(optfile); } ClassLoader patchClassLoader = new ClassLoader(classLoader) { @Override protected Class<?> findClass(String className) throws ClassNotFoundException { Class<?> clazz = dexFile.loadClass(className, this); if (clazz == null&& className.startsWith("com.alipay.euler.andfix")) { return Class.forName(className);// annotation鈥檚 class } if (clazz == null) { throw new ClassNotFoundException(className); } return clazz; } }; Enumeration<String> entrys = dexFile.entries(); Class<?> clazz = null; while (entrys.hasMoreElements()) { String entry = entrys.nextElement(); if (classes != null && !classes.contains(entry)) { continue;// skip, not need fix } clazz = dexFile.loadClass(entry, patchClassLoader); if (clazz != null) { fixClass(clazz, classLoader); } } } catch (IOException e) { Log.e(TAG, "pacth", e); } }
使用DexFile和自定义类加载器来加载修复包文件。这个其实和DexClassLoader加载原理类似,
而且DexClassLoader内部的加载逻辑也是使用了DexFile来进行操作的,而这里为什么要进行加载操作呢?
因为需要获取修复类中需要修复的方法名称,而这个方法名称是通过修复方法的注解来获取到的,
所以先进行类的加载然后获取到他的方法信息,最后通过分析注解获取方法名,这里用的是反射机制来进行操作的。
修复包中每个类加载完之后调用fixClass方法
private void fixClass(Class<?> clazz, ClassLoader classLoader) { Method[] methods = clazz.getDeclaredMethods(); MethodReplace methodReplace; String clz; String meth; for (Method method : methods) { methodReplace = method.getAnnotation(MethodReplace.class); if (methodReplace == null) continue; clz = methodReplace.clazz(); meth = methodReplace.method(); if (!isEmpty(clz) && !isEmpty(meth)) { replaceMethod(classLoader, clz, meth, method); } } }
首先利用反射获取类的所有方法,然后每个方法的注解信息,然后通过注解信息获取指定修复的方法名称,
最后调用replaceMethod替换需要修复的方法。
private void replaceMethod(ClassLoader classLoader, String clz, String meth, Method method) { try { String key = clz + "@" + classLoader.toString(); Class<?> clazz = mFixedClass.get(key); if (clazz == null) {// class not load Class<?> clzz = classLoader.loadClass(clz); // initialize target class clazz = AndFix.initTargetClass(clzz); } if (clazz != null) {// initialize class OK mFixedClass.put(key, clazz); Method src = clazz.getDeclaredMethod(meth, method.getParameterTypes()); AndFix.addReplaceMethod(src, method); } } catch (Exception e) { Log.e(TAG, "replaceMethod", e); } }
调用getDeclaredMethod获取原来的方法,然后调用AndFix的addReplaceMethod用新的方法替换原来的方法。
该方法直接传入旧的方法,新的方法。
Andfix.cpp的replaceMethod方法如下,
static void replaceMethod(JNIEnv* env, jclass clazz, jobject src, jobject dest) { if (isArt) { art_replaceMethod(env, src, dest); } else { dalvik_replaceMethod(env, src, dest); } }
和第二章节中的一样,根据android系统的不同选择不同的虚拟机。
首先看davlik虚拟机中的dalvik_replaceMethod方法, dalvik_method_replace.cpp中的dalvik_replaceMethod方法如下,
extern void __attribute__ ((visibility ("hidden"))) dalvik_replaceMethod( JNIEnv* env, jobject src, jobject dest) { jobject clazz = env->CallObjectMethod(dest, jClassMethod); ClassObject* clz = (ClassObject*) dvmDecodeIndirectRef_fnPtr( dvmThreadSelf_fnPtr(), clazz); clz->status = CLASS_INITIALIZED; Method* meth = (Method*) env->FromReflectedMethod(src); Method* target = (Method*) env->FromReflectedMethod(dest); LOGD("dalvikMethod: %s", meth->name); // meth->clazz = target->clazz; meth->accessFlags |= ACC_PUBLIC; meth->methodIndex = target->methodIndex; meth->jniArgInfo = target->jniArgInfo; meth->registersSize = target->registersSize; meth->outsSize = target->outsSize; meth->insSize = target->insSize; meth->prototype = target->prototype; meth->insns = target->insns; meth->nativeFunc = target->nativeFunc; }
整个热修复的精髓就在最后9句,用新方法的结构体信息替换旧方法中的结构体信息,这样就达到了方法的热修复目的。
ART虚拟机,art_method_replace.cpp的art_replaceMethod方法如下,
extern void __attribute__ ((visibility ("hidden"))) art_replaceMethod( JNIEnv* env, jobject src, jobject dest) { if (apilevel > 23) { replace_7_0(env, src, dest); } else if (apilevel > 22) { replace_6_0(env, src, dest); } else if (apilevel > 21) { replace_5_1(env, src, dest); } else if (apilevel > 19) { replace_5_0(env, src, dest); }else{ replace_4_4(env, src, dest); } }
根据android系统的不同调用不同的热修复方法,对于android 6.0 ,art_method_replace_6_0.cpp中的replace_6_0方法如下,
void replace_6_0(JNIEnv* env, jobject src, jobject dest) { art::mirror::ArtMethod* smeth = (art::mirror::ArtMethod*) env->FromReflectedMethod(src); art::mirror::ArtMethod* dmeth = (art::mirror::ArtMethod*) env->FromReflectedMethod(dest); reinterpret_cast<art::mirror::Class*>(dmeth->declaring_class_)->class_loader_ = reinterpret_cast<art::mirror::Class*>(smeth->declaring_class_)->class_loader_; //for plugin classloader reinterpret_cast<art::mirror::Class*>(dmeth->declaring_class_)->clinit_thread_id_ = reinterpret_cast<art::mirror::Class*>(smeth->declaring_class_)->clinit_thread_id_; reinterpret_cast<art::mirror::Class*>(dmeth->declaring_class_)->status_ = reinterpret_cast<art::mirror::Class*>(smeth->declaring_class_)->status_-1; //for reflection invoke reinterpret_cast<art::mirror::Class*>(dmeth->declaring_class_)->super_class_ = 0; smeth->declaring_class_ = dmeth->declaring_class_; smeth->dex_cache_resolved_methods_ = dmeth->dex_cache_resolved_methods_; smeth->dex_cache_resolved_types_ = dmeth->dex_cache_resolved_types_; smeth->access_flags_ = dmeth->access_flags_ | 0x0001; smeth->dex_code_item_offset_ = dmeth->dex_code_item_offset_; smeth->dex_method_index_ = dmeth->dex_method_index_; smeth->method_index_ = dmeth->method_index_; smeth->ptr_sized_fields_.entry_point_from_interpreter_ = dmeth->ptr_sized_fields_.entry_point_from_interpreter_; smeth->ptr_sized_fields_.entry_point_from_jni_ = dmeth->ptr_sized_fields_.entry_point_from_jni_; smeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_ = dmeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_; LOGD("replace_6_0: %d , %d", smeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_, dmeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_); }
和davlik虚拟机几乎完全一样,直接用新方法的结构体信息替换旧方法中的结构体信息。
5,addPatch
经过了前面几个步骤,好像已经进行热修复了。为什么还要强制调用PatchManager的addPatch方法呢?mPatchManager.addPatch(patchFileString); // 传入的是绝对路径,例如SD卡
PatchManager中带参数的addPatch方法如下,
public void addPatch(String path) throws IOException { File src = new File(path); File dest = new File(mPatchDir, src.getName()); if(!src.exists()){ throw new FileNotFoundException(path); } if (dest.exists()) { Log.d(TAG, "patch [" + path + "] has be loaded."); return; } FileUtil.copyFile(src, dest);// copy to patch's directory Patch patch = addPatch(dest); if (patch != null) { loadPatch(patch); } }
loadPatch方法如下,
private void loadPatch(Patch patch) { Set<String> patchNames = patch.getPatchNames(); ClassLoader cl; List<String> classes; for (String patchName : patchNames) { if (mLoaders.containsKey("*")) { cl = mContext.getClassLoader(); } else { cl = mLoaders.get(patchName); } if (cl != null) { classes = patch.getClasses(patchName); mAndFixManager.fix(patch.getFile(), cl, classes); } } }
addPatch这一系列方法的实质就是手动强制进行热修复。
首先将SD卡上的热修复文件复制到apk路径里,然后进行热修复。相当于第四章是自动进行热修复,这里进行强制热修复。
6,总结
源码结构如下,Java层类作用如下,
1, PatchManager负责管理多个Patch类,管理多个修复包信息。
2, Patch类负责解析每个修复包apatch文件信息,获取所有需要修复的类名
3,Compat 负责检查android系统是否支持热修复
4, AndFix类主要是和native层交互直接替换方法
5, AndFixManager类主要是负责管理AndFix类
6, SecurityChecker 主要负责安全检查。
7, FileUtil 负责复制和删除文件
8, MethodReplace 方法替换的接口
android.cpp文件对应java层的AndFix类,然后就是native层的ART和davlik虚拟机。
核心技术点:
1、使用apatch工具生成修复包文件,主要是.apatch 格式。
2、Java层传递新旧方法类型对象,到native层获取其对应的结构体信息实现完美替换新旧方法结构信息
优点和局限性
优点:从上面可以看到这个框架的优点在于轻巧便捷,集成成本低,维护性强。
局限性:从上面的代码分析可以看到这个框架的局限性还是很多的,特别是只能修复对应已经存在的方法,
比如现在想增加一个方法肯定不行的,如果想给修复方法增加参数信息也是不可以的,这个局限性就非常大了。
还有一个局限性就是只能进行代码修复,资源是无法做到的。所以从这里可以看到这个框架更偏重于方法的热修复操作。
相关文章推荐
- nhibernate源码分析之二: 会话工厂
- BT客户端源码分析之二:Storage 类
- Memcached源码分析之二
- mahout源码分析之Decision Forest 三部曲之二BuildForest(1)
- 自己动手写CSDN博客提取器源码分析之二:处理网页保存为doc文件
- Hadoop源码分析之二(RPC机制之Call处理)
- [置顶] Cocos2d-x 实例源码分析之二 小实例的主框架
- Cocos2d-x 实例源码分析之二 小实例的主框架
- 分布式搜索Elasticsearch源码分析之二------索引过程源码概要分析
- TodoMVC中的Backbone+MarionetteJS+RequireJS例子源码分析之二 数据处理
- Tracker 服务器源码分析之二:RawServer类
- [置顶] 自己动手写CSDN博客提取器源码分析之二:处理网页保存为doc文件
- nhibernate源码分析之二:会话工厂
- QEMU1.3.0源码分析之二:TCG
- nhibernate源码分析之二:会话工厂
- DEDE源码分析与学习之二: member文件结构说明
- libjingle源码分析之二:Thread和SocketServer
- [Leveldb]源码分析之二 Cache模块的实现
- libevent2源码分析之二:初始化流程
- bt客户端源码分析之二: Storage 类