熱修復技術
APP提早發出去的包，如果出現客戶端的問題，實在是乾着急，覆水難收。因此線上修復方案迫在眉睫。
概述
基於Xposed中的思想，通過修改c層的Method實例描述，來實現更改與之對應的java方法的行爲，從而達到修復的目的。
Xposed
誕生於XDA論壇，類似一個應用平臺，不同的是其提供諸多系統級的應用。可實現許多神奇的功能。Xposed需要以越獄爲前提，像是iOS中的cydia。
Xposed可以修改任何程序的任何java方法（需root），github上提供了XposedInstaller，是一個android app。提供很多framework層，應用層級的程序。開發者可以爲其開發一些系統或應用方面的插件，自定義android系統，它甚至可以做動態權限管理（XposedMods）。
Android系統啓動與應用啓動
Zygote進程是Android手機系統啓動後，常駐的一個名爲‘受精卵’的進程。
- zygote的啓動實現腳本在/init.rc文件中
- 啓動過程中執行的二進制文件在/system/bin/app_process
任何應用程序啓動時，會從zygote進程fork出一個新的進程。並裝載一些必要的class，invoke一些初始化方法。這其中包括像：
- ActivityThread
- ServiceThread
- ApplicationPackageManager
等應用啓動中必要的類，觸發必要的方法，比如：handleBindApplication，將此進程與對應的應用綁定的初始化方法；同時，會將zygote進程中的dalvik虛擬機實例複製一份，因此每個應用程序進程都有自己的dalvik虛擬機實例；會將已有Java運行時加載到進程中；會註冊一些android核心類的jni方法到虛擬機中，支撐從c到java的啓動過程。
Xposed做了手腳
Xposed在這個過程改寫了app_process(源碼在Xposed : a modified app_process binary)，替換/system/bin/app_process這個二進制文件。然後做了兩個事：
- 通過Xposed的hook技術，在上述過程中，對上面提到的那些加載的類的方法hook。
- 加載XposedBridge.jar
這時hook必要的方法是爲了方便開發者爲它開發插件，加載XposedBridge.jar是爲動態hook提供了基礎。在這個時候加載它意味着，所有的程序在啓動時，都可以加載這個jar（因爲上面提到的fork過程）。結合hook技術，從而達到了控制所有程序的所有方法。
爲獲得/system/bin/目錄的讀寫權限，因而需要以root爲前提。
Xposed的hook思想
那麼Xposed是怎麼hook java方法的呢？要從XposedBridge看起，重點在
XposedBridge.hookmethod(原方法的Member對象，含有新方法的XC_MethodHook對象)；，這裏會調到
private native synchronized static void hookMethodNative(Member method, Class<?> declaringClass, int slot, Object additionalInfo);這個native的方法，通過這個方法，可以讓所hook的方法，轉向native層的一個c方法。如何做到？
When a transmit from java to native occurs, dvm sets up a native stack.
In dvmCallJNIMethod(), dvmPlatformInvoke is used to call the native method(signature in Method.insns).在jni這個中間世界裏，類型數據由jni表來溝通java和c的世界；方法由c++指針結合DVM*系(如dvmSlotToMethod,dvmDecodeIndirectRef等方法)的api方法，操作虛擬機，從而實現java方法與c方法的世界。
那麼hook的過程是這樣：首先通過dexclassload來load所要hook的方法，分析類後，進c層，見代碼XposedBridge_hookMethodNative方法，拿到要hook的Method類，然後通過dvmslotTomethod方法獲取Method*指針，
Method* method = dvmSlotToMethod(declaredClass, slot);declaredClass就是所hook方法所在的類，對應的jobject。slot是Method類中，描述此java對象在vm中的索引；那麼通過這個方法，我們就獲取了c層的Method指針,通過
SET_METHOD_FLAG(method, ACC_NATIVE);將該方法標記爲一個native方法，然後通過
method->nativeFunc = &hookedMethodCallback;定向c層方法到hookedMethodCallback，這樣當被hook的java方法執行時，就會調到c層的hookedMethodCallback方法。
通過meth->nativeFunc重定向MethodCallBridge到hookedMethodCallback這個方法上，控制這個c++指針是無視java的private的。
另外，在method結構體中有
method->insns = (const u2*) hookInfo;用insns指向替換成爲的方法，以便hookedMethodCallback可以獲取真正期望執行的java方法。
現在所有被hook的方法，都指向了hookedMethodCallbackc方法中，然後在此方法中實現調用替換成爲的java方法。
從Xposed提煉精髓
回顧Xposed，以root爲必要條件，在app_process加載XposedBidge.jar，從而實現有hook所有應用的所有方法的能力；而後續動態hook應用內的方法，其實只是load了從zypote進程複製出來的運行時的這個XposedBidge.jar，然後hook而已。因此，若在一個應用範圍內的hook，root不是必須的，只是單純的加載hook的實現方法，即可修改本應用的方法。
業界內也不乏通過「修改BaseDexClassLoader中的pathList，來動態加載dex」方式實現熱修復。後者純java實現，但需要hack類的優化流程，將打CLASS_ISPREVERIFIED標籤的類，去除此標籤，以解決類與類引用不在一個dex中的異常問題。這會放棄dex optimize對啓動運行速度的優化。原則上，這對於方法數沒有大到需要multidex的應用，損失更明顯。而前者不觸犯原有的優化流程，只點殺需要hook的方法，更爲純粹、有效。