您的位置:首页 > 移动开发 > Android开发

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层获取其对应的结构体信息实现完美替换新旧方法结构信息

优点和局限性

优点:从上面可以看到这个框架的优点在于轻巧便捷,集成成本低,维护性强。

局限性:从上面的代码分析可以看到这个框架的局限性还是很多的,特别是只能修复对应已经存在的方法,

比如现在想增加一个方法肯定不行的,如果想给修复方法增加参数信息也是不可以的,这个局限性就非常大了。

还有一个局限性就是只能进行代码修复,资源是无法做到的。所以从这里可以看到这个框架更偏重于方法的热修复操作。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息