主目錄見：Android高級進階知識（這是總目錄索引）
框架地址：AndFix
在線源碼查看：AndroidXRef
?我們前面講了插件化的框架，今天我們來講講我們的熱修復框架，首先在選熱修復框架的時候有猶豫過，到底是要講美團的robust，微信的Tinker，還是阿里的AndFix等等那么這里用一張圖來做一個開始：
熱修復框架對比
這里是缺少了美團的robust，還有阿里的最新熱修復框架Sophix（這個框架也有借鑒了AndFix的思想）的對比，但是我們來想想，熱修復最可能出現的時候應該是方法邏輯的修復，而且修復包要盡量小且能即時生效，同時AndFix用C++中的指針思想來做方法的替換，這個代價也是非常小的。在這幾個方面來看看，AndFix還是很理想的。
一.AndFix的使用
怎么使用我們其實可以從GitHub的[AndFix]開源地址獲取，但是這里還是列舉一下：
1.增加dependency依賴
dependencies {
compile 'com.alipay.euler:andfix:0.5.0@aar'
}
2.初始化PatchManager
patchManager = new PatchManager(context);
patchManager.init(appversion);//current version
3.加載補丁包
patchManager.loadPatch();
框架推薦你要盡可能早地加載補丁包，最好是在應用的初始化階段例如
Application.onCreate())
4.添加補丁包
patchManager.addPatch(path);//path of the patch file that was downloaded
當一個新的補丁包下載下來，通過addPath方法可以即時生效
5.補丁包生成
AndFix框架提供了一個補丁包生成工具apkpatch,可以到這里下載apkpatch。
使用的時候要準備兩個apk文件，其中一個是修復過的，然后生成.patch補丁文件：
usage: apkpatch -f <new> -t <old> -o <output> -k <keystore> -p <***> -a <alias> -e <***>
-a,--alias <alias> keystore entry alias.
-e,--epassword <***> keystore entry password.
-f,--from <loc> new Apk file path.
-k,--keystore <loc> keystore path.
-n,--name <name> patch name.
-o,--out <dir> output dir.
-p,--kpassword <***> keystore password.
-t,--to <loc> old Apk file path.
然后就可以把這個補丁包分發給客戶端了。
有時候團隊的成員會修復各自的bug，會生成不止一個補丁包，這樣我們可以合并這多個補丁包：
usage: apkpatch -m <apatch_path...> -o <output> -k <keystore> -p <***> -a <alias> -e <***>
-a,--alias <alias> keystore entry alias.
-e,--epassword <***> keystore entry password.
-k,--keystore <loc> keystore path.
-m,--merge <loc...> path of .apatch files.
-n,--name <name> patch name.
-o,--out <dir> output dir.
-p,--kpassword <***> keystore password.
好啦，使用起來并不是很難，我們接下來就從使用來分析源碼了。
二.AndFix框架源碼解析
從使用我們知道，我們的程序會首先初始化PatchManager，所以我們看看初始化做了啥：
public PatchManager(Context context) {
mContext = context;
//初始化AndFixManager
mAndFixManager = new AndFixManager(mContext);
//初始化存放patch補丁文件的目錄
mPatchDir = new File(mContext.getFilesDir(), DIR);
//初始化存在Patch類的集合
mPatchs = new ConcurrentSkipListSet<Patch>();
//初始化存放類對應的類加載器集合
mLoaders = new ConcurrentHashMap<String, ClassLoader>();
}
這里面有個比較重要的類AndFixManager，我們來看看它的構造函數：
public AndFixManager(Context context) {
mContext = context;
//兼容性判斷，判斷AndFix是否適用
mSupport = Compat.isSupport();
if (mSupport) {
//主要是對補丁包的安全檢測
mSecurityChecker = new SecurityChecker(mContext);
//初始化補丁包的路徑
mOptDir = new File(mContext.getFilesDir(), DIR);
if (!mOptDir.exists() && !mOptDir.mkdirs()) {// make directory fail
//如果不定目錄不存在則把支持標志設為false
mSupport = false;
Log.e(TAG, "opt dir create error.");
} else if (!mOptDir.isDirectory()) {// not directory
//如果不是目錄則標志設置為false
mOptDir.delete();
mSupport = false;
}
}
}
這個類構造函數做的工作很簡單，就是Android系統兼容性的檢查，然后就是對補丁包安全性和路徑的檢驗。接著我們看看兼容性判斷源碼：
public static synchronized boolean isSupport() {
if (isChecked)
return isSupport;
isChecked = true;
// not support alibaba's YunOs
//寫的很清楚，這里不支持阿里的YunOs,且會判斷Davilk還是art虛擬機，來注冊native方法
if (!isYunOS() && AndFix.setup() && isSupportSDKVersion()) {
isSupport = true;
}
//是否在黑名單中，默認是返回false
if (inBlackList()) {
isSupport = false;
}
return isSupport;
}
判斷是不是YunOs系統和支持的Sdk版本這兩個方法比較簡單，這里不深究，重點來看AndFix.setup()方法：
public static boolean setup() {
try {
final String vmVersion = System.getProperty("java.vm.version");
boolean isArt = vmVersion != null && vmVersion.startsWith("2");
int apilevel = Build.VERSION.SDK_INT;
return setup(isArt, apilevel);
} catch (Exception e) {
Log.e(TAG, "setup", e);
return false;
}
}
這個方法也是很簡單，判斷vm的版本是不是以2開頭，如果是就是art虛擬機，然后將isArt和api的版本傳給了native的setup方法，這個方法在jni目錄的AndFix.cpp下面：
static jboolean setup(JNIEnv* env, jclass clazz, jboolean isart,
jint apilevel) {
isArt = isart;
LOGD("vm is: %s , apilevel is: %i", (isArt ? "art" : "dalvik"),
(int )apilevel);
if (isArt) {
return art_setup(env, (int) apilevel);
} else {
return dalvik_setup(env, (int) apilevel);
}
}
可以看到方法里面根據isArt這個標志來調用不同的方法，首先我們看下art_setup方法：
extern jboolean __attribute__ ((visibility ("hidden"))) art_setup(JNIEnv* env,
int level) {
apilevel = level;
return JNI_TRUE;
}
可以看出這個方法就記錄了下apilevel然后直接返回了true。接著我們來看看dalvik_setup方法：
extern jboolean __attribute__ ((visibility ("hidden"))) dalvik_setup(
JNIEnv* env, int apilevel) {
//打開libdvm.so文件
void* dvm_hand = dlopen("libdvm.so", RTLD_NOW);
if (dvm_hand) {
//獲取dvmDecodeIndirectRef_fnPtr和dvmThreadSelf_fnPtr兩個函數,
//這兩個函數可以通過類對象獲取ClassObject結構體
dvmDecodeIndirectRef_fnPtr = dvm_dlsym(dvm_hand,
apilevel > 10 ?
"_Z20dvmDecodeIndirectRefP6ThreadP8_jobject" :
"dvmDecodeIndirectRef");
if (!dvmDecodeIndirectRef_fnPtr) {
return JNI_FALSE;
}
dvmThreadSelf_fnPtr = dvm_dlsym(dvm_hand,
apilevel > 10 ? "_Z13dvmThreadSelfv" : "dvmThreadSelf");
if (!dvmThreadSelf_fnPtr) {
return JNI_FALSE;
}
//這里用jni里面的方法來獲取Java層Method對象的getDeclaringClass方法
//后續會調用該方法獲取某個方法所屬的類對象
//因為Java層只傳遞了Method對象到native層
jclass clazz = env->FindClass("java/lang/reflect/Method");
jClassMethod = env->GetMethodID(clazz, "getDeclaringClass",
"()Ljava/lang/Class;");
return JNI_TRUE;
} else {
return JNI_FALSE;
}
}
這里面我們先來看看Android虛擬機初始化方面的知識圖：
Android虛擬機初始化
1.跟java虛擬機不同，Android虛擬機執行的是dex文件而不是class文件,同時在android版本4.4開始就推出了art虛擬機，所以現在android的虛擬機分為dalvik虛擬機和art虛擬機。
2.虛擬機啟動的時候會加載兩個很重要的動態庫文件libdvm.so和libart.so，這就是dalvik虛擬機和art虛擬機的動態庫文件
3.Java在虛擬機環境中執行，每個Java方法都會對應一個底層的函數指針，當Java方法被調用的時候，實質虛擬機會找到這個函數指針然后去執行底層的方法，從而Java方法被執行。
接著我們繼續來分析dalvik_setup方法，首先這個方法會判斷apilevel是不是大于10來Hook不同的系統函數，在Hook成功了之后，我們就可以調用我們自己的代碼進行替換，這就是框架github上面說的：
方法替換
替換方法我們留著后面具體說，我們接著來看PatchManager類中的init方法：
public void init(String appVersion) {
//首先判斷補丁路徑是否存在或者是不是目錄
if (!mPatchDir.exists() && !mPatchDir.mkdirs()) {// make directory fail
Log.e(TAG, "patch dir create error.");
return;
} else if (!mPatchDir.isDirectory()) {// not directory
mPatchDir.delete();
return;
}
//這里用sp來存儲補丁包的配置信息
SharedPreferences sp = mContext.getSharedPreferences(SP_NAME,
Context.MODE_PRIVATE);
String ver = sp.getString(SP_VERSION, null);
//這里首先獲取本地補丁包的版本和傳入的版本號做對比
if (ver == null || !ver.equalsIgnoreCase(appVersion)) {
//如果版本不同，說明本地的版本過久則要刪除存入新的補丁包版本
cleanPatch();
sp.edit().putString(SP_VERSION, appVersion).commit();
} else {
//相同說明本地有本地補丁包了，則初始化
initPatchs();
}
}
我們看到這里如果本地已經有補丁包且版本未更新，則初始化，我們來看這個initPatchs方法：
private void initPatchs() {
File[] files = mPatchDir.listFiles();
for (File file : files) {
addPatch(file);
}
}
這個方法很簡單，就是將補丁路徑下的所有補丁文件調用addPatch方法添加進去，我們來看看addPatch方法：
private Patch addPatch(File file) {
Patch patch = null;
if (file.getName().endsWith(SUFFIX)) {
try {
patch = new Patch(file);
mPatchs.add(patch);
} catch (IOException e) {
Log.e(TAG, "addPatch", e);
}
}
return patch;
}
我們看到這個方法主要就是判斷文件是不是以.patch結尾，如果是的話就初始化一個Patch實例,這個是添加補丁包的關鍵，我們跟進構造函數看下:
public Patch(File file) throws IOException {
mFile = file;
init();
}
@SuppressWarnings("deprecation")
private void init() throws IOException {
JarFile jarFile = null;
InputStream inputStream = null;
try {
//使用JarFile讀取Patch文件
jarFile = new JarFile(mFile);
//獲取META-INF/PATCH.MF文件
JarEntry entry = jarFile.getJarEntry(ENTRY_NAME);
inputStream = jarFile.getInputStream(entry);
Manifest manifest = new Manifest(inputStream);
Attributes main = manifest.getMainAttributes();
//因為PATCH.MF里面是以鍵值對的形式存儲的，這里是獲取鍵Patch-Name對應的值
mName = main.getValue(PATCH_NAME);
//這里是獲取創建的時間
mTime = new Date(main.getValue(CREATED_TIME));
mClassesMap = new HashMap<String, List<String>>();
Attributes.Name attrName;
String name;
List<String> strings;
for (Iterator<?> it = main.keySet().iterator(); it.hasNext();) {
attrName = (Attributes.Name) it.next();
name = attrName.toString();
//判斷name的后綴是否是-Classes，并把name對應的值加入到集合中，對應的值就是class類名的列表
if (name.endsWith(CLASSES)) {
strings = Arrays.asList(main.getValue(attrName).split(","));
if (name.equalsIgnoreCase(PATCH_CLASSES)) {
mClassesMap.put(mName, strings);
} else {
// //為了移除掉"-Classes"的后綴
mClassesMap.put(
name.trim().substring(0, name.length() - 8),// remove
// "-Classes"
strings);
}
}
}
} finally {
if (jarFile != null) {
jarFile.close();
}
if (inputStream != null) {
inputStream.close();
}
}
}
這個方法的邏輯其實就是讀取補丁.patch文件,每個修復包apatch文件其實都是一個jarFile文件，然后獲得其中META-INF/PATCH.MF文件，PATCH.MF文件中都是鍵值對的形式，獲取key是-Classes的所有的value，這些value就是所有要修復的類，他們是以“，”進行分割的，將它們放入list列表，將其存儲到一個集合中mClassesMap，list列表中存儲的就是所有要修復的類名。我們看到我們還有一個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);
}
}
這個方法里面就多了一步將指定的路徑下的文件拷貝到補丁包路徑下面，這個方法的作用是什么呢？我們知道，我們第一次app下載下來的時候，我們本地是沒有補丁包的，只有當需要補丁修復的時候，我們才會從服務器下載補丁包下來，這時候我們可以指定我們下載下來的補丁包的存放路徑，然后將它拷貝到補丁包路徑，然后進行加載。
接下來，我們來看看方法調用loadPatch()方法：
public void loadPatch() {
mLoaders.put("*", mContext.getClassLoader());// wildcard
Set<String> patchNames;
List<String> classes;
//遍歷mPatchs中的所有Patch
for (Patch patch : mPatchs) {
//遍歷補丁包中待修復的所有patch名
patchNames = patch.getPatchNames();
for (String patchName : patchNames) {
//獲取patch中的所有class
classes = patch.getClasses(patchName);
//修復bug
mAndFixManager.fix(patch.getFile(), mContext.getClassLoader(),
classes);
}
}
}
我們看到這個方法主要就是最后的fix方法：
public synchronized void fix(String patchPath) {
fix(new File(patchPath), mContext.getClassLoader(), null);
}
public synchronized void fix(File file, ClassLoader classLoader,
List<String> classes) {
if (!mSupport) {
return;
}
//檢測patch包的簽名，檢查是不是安全的
if (!mSecurityChecker.verifyApk(file)) {// security check fail
return;
}
try {
//判斷優化后的文件是否存在，如果存在則檢測optfile的安全性
File optfile = new File(mOptDir, file.getName());
boolean saveFingerprint = true;
if (optfile.exists()) {
// need to verify fingerprint when the optimize file exist,
// prevent someone attack on jailbreak device with
// Vulnerability-Parasyte.
// btw:exaggerated android Vulnerability-Parasyte
// http://secauo.com/Exaggerated-Android-Vulnerability-Parasyte.html
if (mSecurityChecker.verifyOpt(optfile)) {
saveFingerprint = false;
} else if (!optfile.delete()) {
return;
}
}
//加載補丁文件包中的dex文件
final DexFile dexFile = DexFile.loadDex(file.getAbsolutePath(),
optfile.getAbsolutePath(), Context.MODE_PRIVATE);
if (saveFingerprint) {
mSecurityChecker.saveOptSig(optfile);
}
//這里重寫了ClassLoader中的findClass方法，并且實例化它
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’s class
// not found
}
if (clazz == null) {
throw new ClassNotFoundException(className);
}
return clazz;
}
};
//遍歷dex然后加載有bug的類文件
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) {
//對有bug的文件進行替換
fixClass(clazz, classLoader);
}
}
} catch (IOException e) {
Log.e(TAG, "pacth", e);
}
}
我們看見我們為什么要用DexFile來加載補丁文件呢？這個得從補丁包.patch文件來看：
Patch包信息
我們看到我們的.patch文件實質上里面包含了兩個文件，其中一個
.dex就是我們要修復的類，META-INF文件如下：
META-INF
這個文件就是我們前面說的PATCH.MF,里面存放補丁包的一些配置信息。上面的方法就是加載dex，然后獲取到所有要修復的類，然后進行替換，所以我們接下來看fixClass()方法：
private void fixClass(Class<?> clazz, ClassLoader classLoader) {
Method[] methods = clazz.getDeclaredMethods();
MethodReplace methodReplace;
String clz;
String meth;
//遍歷要修復類中的所有方法
for (Method method : methods) {
//獲取帶有MethodReplace注解的方法
methodReplace = method.getAnnotation(MethodReplace.class);
if (methodReplace == null)
continue;
clz = methodReplace.clazz();
meth = methodReplace.method();
//獲取注解中的class信息和method信息
if (!isEmpty(clz) && !isEmpty(meth)) {
//然后調用replaceMethod方法進行替換
replaceMethod(classLoader, clz, meth, method);
}
}
}
我們看到上面方法會獲取帶有MethodReplace注解的所有方法，這是在補丁包生成的時候添加上去的，然后獲取class和method的信息之后，通過調用方法repalceMethod方法進行方法替換：
private void replaceMethod(ClassLoader classLoader, String clz,
String meth, Method method) {
try {
String key = clz + "@" + classLoader.toString();
//判斷這個類是否已經被修復了
Class<?> clazz = mFixedClass.get(key);
//如果class還沒有被類加載加載進來，則去加載
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);
//根據反射獲取到有bug的類的方法
Method src = clazz.getDeclaredMethod(meth,
method.getParameterTypes());
//src是有bug的方法，method是補丁方法
AndFix.addReplaceMethod(src, method);
}
} catch (Exception e) {
Log.e(TAG, "replaceMethod", e);
}
}
我們看到通過注解中的method信息獲取到有bug的方法，然后調用AndFix.addReplaceMethod(src, method)進行替換，這里是native來實現的，我們來看看：
static void replaceMethod(JNIEnv* env, jclass clazz, jobject src,
jobject dest) {
if (isArt) {
art_replaceMethod(env, src, dest);
} else {
dalvik_replaceMethod(env, src, dest);
}
}
我們的看到dalvik和art虛擬機的替換方法不同，我們先來看看dalvik虛擬機上面的：
extern void __attribute__ ((visibility ("hidden"))) dalvik_replaceMethod(
JNIEnv* env, jobject src, jobject dest) {
//這里通過jni獲取jobject對象
jobject clazz = env->CallObjectMethod(dest, jClassMethod);
//我們看到剛才Hook的系統的函數，通過這個系統函數我們可以獲取class的ClassObject對象指針
ClassObject* clz = (ClassObject*) dvmDecodeIndirectRef_fnPtr(
dvmThreadSelf_fnPtr(), clazz);
//更改狀態為類初始化完成的狀態
clz->status = CLASS_INITIALIZED;
//通過java層傳遞的方法對象，在native層獲得他們的結構體
Method* meth = (Method*) env->FromReflectedMethod(src);
Method* target = (Method*) env->FromReflectedMethod(dest);
LOGD("dalvikMethod: %s", meth->name);
// meth->clazz = target->clazz;
替換method結構體中的accessFlags
meth->accessFlags |= ACC_PUBLIC;
//替換method結構體中的方法的索引methodIndex
meth->methodIndex = target->methodIndex;
// 替換method結構體的緩存的JNI參數jniArgInfo
meth->jniArgInfo = target->jniArgInfo;
meth->registersSize = target->registersSize;
meth->outsSize = target->outsSize;
//替換method結構體的insSize
meth->insSize = target->insSize;
// 替換method結構體的方法原型描述prototype
meth->prototype = target->prototype;
// 替換method結構體的真實代碼insns
meth->insns = target->insns;
//替換method結構體的真實函數或者JNI橋接函數
meth->nativeFunc = target->nativeFunc;
}
我們看到這里就是指針指向了修復完的方法的結構體信息，這樣就達到了修復的目的，所以說指針還是一個非常有用的東西，這也是c和c++的精髓所在，接著我們來看看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);
}
}
這個地方還是比較蛋疼的，我們看見根據api的不同版本來做了好幾個適配，現在8.0出來了，可想而知也可能要做適配，我們先來看下4.4的這個方法：
void replace_4_4(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);
//替換 ArtMethod的class_loader指針
dmeth->declaring_class_->class_loader_ =
smeth->declaring_class_->class_loader_; //for plugin classloader
//替換ArtMethod的clinit_thread_id_指針
dmeth->declaring_class_->clinit_thread_id_ =
smeth->declaring_class_->clinit_thread_id_;
//替換ArtMethod的status_指針
dmeth->declaring_class_->status_ = smeth->declaring_class_->status_-1;
//for reflection invoke
reinterpret_cast<art::mirror::Class*>(dmeth->declaring_class_)->super_class_ = 0;
//替換ArtMethod的declaring_class_指針
smeth->declaring_class_ = dmeth->declaring_class_;
smeth->dex_cache_initialized_static_storage_ = dmeth->dex_cache_initialized_static_storage_;
//替換ArtMethod的access_flags_指針
smeth->access_flags_ = dmeth->access_flags_ | 0x0001;
smeth->dex_cache_resolved_types_ = dmeth->dex_cache_resolved_types_;
smeth->dex_cache_resolved_methods_ = dmeth->dex_cache_resolved_methods_;
smeth->dex_cache_strings_ = dmeth->dex_cache_strings_;
smeth->code_item_offset_ = dmeth->code_item_offset_;
smeth->core_spill_mask_ = dmeth->core_spill_mask_;
smeth->fp_spill_mask_ = dmeth->fp_spill_mask_;
smeth->method_dex_index_ = dmeth->method_dex_index_;
smeth->mapping_table_ = dmeth->mapping_table_;
//替換ArtMethod的method_index_指針
smeth->method_index_ = dmeth->method_index_;
smeth->gc_map_ = dmeth->gc_map_;
smeth->frame_size_in_bytes_ = dmeth->frame_size_in_bytes_;
smeth->native_method_ = dmeth->native_method_;
smeth->vmap_table_ = dmeth->vmap_table_;
smeth->entry_point_from_compiled_code_ = dmeth->entry_point_from_compiled_code_;
smeth->entry_point_from_interpreter_ = dmeth->entry_point_from_interpreter_;
smeth->method_index_ = dmeth->method_index_;
LOGD("replace_4_4: %d , %d", smeth->entry_point_from_compiled_code_,
dmeth->entry_point_from_compiled_code_);
}
我們看到這里要替換的東西還是比較多的，大家可以通過查看虛擬機中的方法結構體來查看，這里也就不詳細列出了。
總結:AndFix的源碼還是比較好理解，但是想到用這種方法還是非常fashion的有沒有，而且需要我們了解你虛擬機相關的知識，這方面我也是有欠缺，可以適當補充了，希望大家一起進步。
