轉自:http://qlm.pw/2017/01/07/tinker接入及源碼分析(一)/
該系列文章分析基于 Tinker1.7.6 版本
Tinker項目地址:https://github.com/Tencent/tinker
Tinker接入及源碼分析(一):簡單介紹以及如何接入
Tinker接入及源碼分析(二):加載補丁源碼分析
Tinker接入及源碼分析(三):合成補丁源碼分析
現在市面上有很多Android熱修復框架,包括開源的,未開源的和即將開源的。阿里巴巴的AndFix,美團的Robust,Qzone方案的Nuwa,阿里百川的HotFix,微信的Tinker。
下面是幾個熱修復框架的對比圖:
學習一個框架需要從使用入手,在深入其源碼,分析其原理。
先簡單的說一下Tinker框架熱修復的原理,主要是dex文件的修復,不再涉及資源文件以及so文件的修復,通過對比原dex文件(存在bug)與現dex文件(bug已修復)生成差異包,生成的差異包作為補丁包下發給客戶端,客戶端做一系列校驗之后,將下發的差異包與本應用的dex文件合并成成全量的dex文件,并進行opt優化,在應用重啟的時候,會在Tinkerapplication中加載優化過的全量dex文件,加載過程與QQ空間熱修復方案類似,將dex文件插入到DexPathList 中 dexElements的前面。
下面以官方提供的Sample簡單的說一下如何使用Tinker做熱修復,當然最好的接入文檔是官方wiki:https://github.com/Tencent/tinker/wiki
首先將自己的實現的Application改為繼承DefaultApplicationLike ,需要注意的是必須先初始化Tinker,后續關于Tinker類的操作才能正常使用,這里在onBaseContextAttached中調用了TinkerInstall.installTinker(this)來初始化Tinker,例如:
@DefaultLifeCycle(application = "tinker.sample.android.app.SampleApplication", flags = ShareConstants.TINKER_ENABLE_ALL, loadVerifyFlag = false)public class SampleApplicationLike extends DefaultApplicationLike { PRivate static final String TAG = "Tinker.SampleApplicationLike"; public SampleApplicationLike(Application application, int tinkerFlags, boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime, long applicationStartMillisTime, Intent tinkerResultIntent, Resources[] resources, ClassLoader[] classLoader, AssetManager[] assetManager) { super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent, resources, classLoader, assetManager); } /** * install multiDex before install tinker * so we don't need to put the tinker lib classes in the main dex * * @param base */ @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH) @Override public void onBaseContextAttached(Context base) { super.onBaseContextAttached(base); //you must install multiDex whatever tinker is installed! MultiDex.install(base); TinkerInstaller.installTinker(this); }}推薦通過注解處理器的方式(DefaultLifeCycle)生成Application:tinker.sample.android.app.SampleApplication;我們需要在Manifest文件中修改為這個Application,當然也可以自己實現這個Application,繼承自TinkerApplication,需要傳入我們定義的ApplicationLike,這樣真實的Application就和我們定義的代理Application(ApplicationLike)相關聯起來了。下面是真實的Application實現:
public class SampleApplication extends TinkerApplication { public SampleApplication() { super( //tinkerFlags, tinker支持的類型,dex,library,還是全部都支持! ShareConstants.TINKER_ENABLE_ALL, //ApplicationLike的實現類,只能傳遞字符串 "tinker.sample.android.app.SampleApplicationLike", //Tinker的加載器,一般來說用默認的即可 "com.tencent.tinker.loader.TinkerLoader", //tinkerLoadVerifyFlag, 運行加載時是否校驗dex與,ib與res的md5 false); } }然后通過調用下面的代碼來加載補丁文件,前提是Tinker必須初始化完成,傳入的patchLocation就是補丁文件的路徑:
TinkerInstaller.onReceiveUpgradePatch(context, patchLocation)重啟應用之后,補丁文件便會生效。
你也可以使用TinkerPatchSdk一鍵接入Tinker:http://www.tinkerpatch.com/Docs/SDK,其中包括了補丁文件獲取的部分,不需要自己再搭建補丁文件下發后臺。
這篇文章只是拋磚引玉式簡單的介紹了一下Tinker的使用,推薦大家還是好好細讀官方提供的文檔。
限于篇幅的緣故,將在下一篇文章中分析Tinker的原理。
Tinker接入及源碼分析(二)
新聞熱點
疑難解答