溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
小編給大家分享一下Android熱修復Tinker接入的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
熱修復這項技術，基本上已經成為項目比較重要的模塊了。主要因為項目在上線之后，都難免會有各種問題，而依靠發版去修復問題，成本太高了。
現在熱修復的技術基本上有阿里的AndFix、QZone的方案、美團提出的思想方案以及騰訊的Tinker等。
其中AndFix可能接入是最簡單的一個（和Tinker命令行接入方式差不多），不過兼容性還是是有一定的問題的；QZone方案對性能會有一定的影響，且在Art模式下出現內存錯亂的問題(其實這個問題我之前并不清楚，主要是tinker在MDCC上指出的);美團提出的思想方案主要是基于Instant Run的原理，目前尚未開源，不過這個方案我還是蠻喜歡的，主要是兼容性好。
這么看來，如果選擇開源方案，tinker目前是最佳的選擇，tinker的介紹有這么一句：
Tinker已運行在微信的數億Android設備上，那么為什么你不使用Tinker呢？
好了，說了這么多，下面來看看tinker如何接入，以及tinker的大致的原理分析。希望通過本文可以實現幫助大家更好的接入tinker，以及去了解tinker的一個大致的原理。
接入tinker目前給了兩種方式，一種是基于命令行的方式，類似于AndFix的接入方式；一種就是gradle的方式。
考慮早期使用Andfix的app應該挺多的，以及很多人對gradle的相關配置還是覺得比較繁瑣的，下面對兩種方式都介紹下。
接入之前我們先考慮下，接入的話，正常需要的前提（開啟混淆的狀態）。
對于API
一般來說，我們接入熱修庫，會在Application#onCreate中進行一下初始化操作。然后在某個地方去調用類似loadPatch這樣的API去加載patch文件。
對于patch的生成
簡單的方式就是通過兩個apk做對比然后生成；需要注意的是：兩個apk做對比，需要的前提條件，第二次打包混淆所使用的mapping文件應該和線上apk是一致的。
最后就是看看這個項目有沒有需要配置混淆；
有了大致的概念，我們就基本了解命令行接入tinker，大致需要哪些步驟了。
dependencies {
// ...
//可選，用于生成application類
provided('com.tencent.tinker:tinker-android-anno:1.7.7')
//tinker的核心庫
compile('com.tencent.tinker:tinker-android-lib:1.7.7')
}順便加一下簽名的配置：
android{
//...
signingConfigs {
release { try {
storeFile file("release.keystore")
storePassword "testres"
keyAlias "testres"
keyPassword "testres"
} catch (ex) {
throw new InvalidUserDataException(ex.toString())
}
}
}
buildTypes {
release {
minifyEnabled true
signingConfig signingConfigs.release
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
debuggable true
minifyEnabled true
signingConfig signingConfigs.release
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}文末會有demo的下載地址，可以直接參考build.gradle文件，不用擔心這些簽名文件去哪找。
API主要就是初始化和loadPacth。
正常情況下，我們會考慮在Application的onCreate中去初始化，不過tinker推薦下面的寫法：
@DefaultLifeCycle(application = ".SimpleTinkerInApplication",
flags = ShareConstants.TINKER_ENABLE_ALL,
loadVerifyFlag = false)public class SimpleTinkerInApplicationLike extends ApplicationLike {
public SimpleTinkerInApplicationLike(Application application, int tinkerFlags, boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime, long applicationStartMillisTime, Intent tinkerResultIntent) { super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);
} @Override
public void onBaseContextAttached(Context base) { super.onBaseContextAttached(base);
} @Override
public void onCreate() { super.onCreate();
TinkerInstaller.install(this);
}
}ApplicationLike通過名字你可能會猜，并非是Application的子類，而是一個類似Application的類。
tinker建議編寫一個ApplicationLike的子類，你可以當成Application去使用，注意頂部的注解：@DefaultLifeCycle，其application屬性，會在編譯期生成一個SimpleTinkerInApplication類。
所以，雖然我們這么寫了，但是實際上Application會在編譯期生成，所以AndroidManifest.xml中是這樣的：
<application android:name=".SimpleTinkerInApplication" .../>
編寫如果報紅，可以build下。
這樣其實也能猜出來，這個注解背后有個Annotation Processor在做處理
通過該文會對一個編譯時注解的運行流程和基本API有一定的掌握，文中也會對tinker該部分的源碼做解析。
上述，就完成了tinker的初始化，那么調用loadPatch的時機，我們直接在Activity中添加一個Button設置：
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
} public void loadPatch(View view) {
TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(),
Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed.apk");
}
}我們會將patch文件直接push到sdcard根目錄；
所以一定要注意：添加SDCard權限，如果你是6.x以上的系統，自己添加上授權代碼，或者手動在設置頁面打開SDCard讀寫權限。
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
除以以外，有個特殊的地方就是tinker需要在AndroidManifest.xml中指定TINKER_ID。
<application> <meta-data android:name="TINKER_ID" android:value="tinker_id_6235657" /> //...</application>
到此API相關的就結束了，剩下的就是考慮patch如何生成。
tinker提供了patch生成的工具，源碼見：tinker-patch-cli，打成一個jar就可以使用，并且提供了命令行相關的參數以及文件。
命令行如下：
java -jar tinker-patch-cli-1.7.7.jar -old old.apk -new new.apk -config tinker_config.xml -out output
需要注意的就是tinker_config.xml，里面包含tinker的配置，例如簽名文件等。
這里我們直接使用tinker提供的簽名文件，所以不需要做修改，不過里面有個Application的item修改為與本例一致：
<loader value="com.zhy.tinkersimplein.SimpleTinkerInApplication"/>
大致的文件結構如下：
可以在tinker-patch-cli中提取，或者直接下載文末的例子。
上述介紹了patch生成的命令，最后需要注意的就是，在第一次打出apk的時候，保留下生成的mapping文件，在/build/outputs/mapping/release/mapping.txt。
可以copy到與proguard-rules.pro同目錄，同時在第二次打修復包的時候，在proguard-rules.pro中添加上：
-applymapping mapping.txt
保證后續的打包與線上包使用的是同一個mapping文件。
tinker本身的混淆相關配置，可以參考：
tinker_proguard.pro
如果，你對該部分描述不了解，可以直接查看源碼即可。
首先隨便生成一個apk（API、混淆相關已經按照上述引入），安裝到手機或者模擬器上。
然后，copy出mapping.txt文件，設置applymapping，修改代碼，再次打包，生成new.apk。
兩次的apk，可以通過命令行指令去生成patch文件。
如果你下載本例，命令需要在[該目錄]下執行。
最終會在output文件夾中生成產物：
我們直接將patch_signed.apk push到sdcard，點擊loadpatch，一定要觀察命令行是否成功。
本例修改了title。
點擊loadPatch，觀察log，如果成功，應用默認為重啟，然后再次啟動即可達到修復效果。
到這里命令行的方式就介紹完了，和Andfix的接入的方式基本上是一樣的。
值得注意的是:該例僅展示了基本的接入，對于tinker的各種配置信息，還是需要去讀tinker的文檔（如果你確定要使用）tinker-wiki。
gradle接入的方式應該算是主流的方式，所以tinker也直接給出了例子，單獨將該tinker-sample-android以project方式引入即可。
引入之后，可以查看其接入API的方式，以及相關配置。
在你每次build時，會在build/bakApk下生成本地打包的apk，R文件，以及mapping文件。
如果你需要生成patch文件，可以通過：
./gradlew tinkerPatchRelease // 或者 ./gradlew tinkerPatchDebug
生成。
生成目錄為:build/outputs/tinkerPatch
需要注意的是，需要在app/build.gradle中設置相比較的apk（即old.apk，本次為new.apk），
ext {
tinkerEnabled = true
//old apk file to build patch apk
tinkerOldApkPath = "${bakPath}/old.apk"
//proguard mapping file to build patch apk
tinkerApplyMappingPath = "${bakPath}/old-mapping.txt"}提供的例子，基本上展示了tinker的自定義擴展的方式，具體還可以參考：
Tinker-自定義擴展
所以，如果你使用命令行方式接入，也不要忘了學習下其支持哪些擴展。
從注釋和命名上看：
//可選，用于生成application類provided('com.tencent.tinker:tinker-android-anno:1.7.7')明顯是該庫，其結構如下：
典型的編譯時注解的項目，源碼見tinker-android-anno。
入口為com.tencent.tinker.anno.AnnotationProcessor，可以在該services/javax.annotation.processing.Processor文件中找到處理類全路徑。
再次建議，如果你不了解，簡單閱讀下Android 如何編寫基于編譯時注解的項目該文。
直接看AnnotationProcessor的process方法：
@Overridepublic boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
processDefaultLifeCycle(roundEnv.getElementsAnnotatedWith(DefaultLifeCycle.class)); return true;
}直接調用了processDefaultLifeCycle：
private void processDefaultLifeCycle(Set<? extends Element> elements) { // 被注解DefaultLifeCycle標識的對象
for (Element e : elements) { // 拿到DefaultLifeCycle注解對象
DefaultLifeCycle ca = e.getAnnotation(DefaultLifeCycle.class);
String lifeCycleClassName = ((TypeElement) e).getQualifiedName().toString();
String lifeCyclePackageName = lifeCycleClassName.substring(0, lifeCycleClassName.lastIndexOf('.'));
lifeCycleClassName = lifeCycleClassName.substring(lifeCycleClassName.lastIndexOf('.') + 1);
String applicationClassName = ca.application(); if (applicationClassName.startsWith(".")) {
applicationClassName = lifeCyclePackageName + applicationClassName;
}
String applicationPackageName = applicationClassName.substring(0, applicationClassName.lastIndexOf('.'));
applicationClassName = applicationClassName.substring(applicationClassName.lastIndexOf('.') + 1);
String loaderClassName = ca.loaderClass(); if (loaderClassName.startsWith(".")) {
loaderClassName = lifeCyclePackageName + loaderClassName;
} // /TinkerAnnoApplication.tmpl
final InputStream is = AnnotationProcessor.class.getResourceAsStream(APPLICATION_TEMPLATE_PATH); final Scanner scanner = new Scanner(is); final String template = scanner.useDelimiter("\\A").next(); final String fileContent = template
.replaceAll("%PACKAGE%", applicationPackageName)
.replaceAll("%APPLICATION%", applicationClassName)
.replaceAll("%APPLICATION_LIFE_CYCLE%", lifeCyclePackageName + "." + lifeCycleClassName)
.replaceAll("%TINKER_FLAGS%", "" + ca.flags())
.replaceAll("%TINKER_LOADER_CLASS%", "" + loaderClassName)
.replaceAll("%TINKER_LOAD_VERIFY_FLAG%", "" + ca.loadVerifyFlag());
JavaFileObject fileObject = processingEnv.getFiler().createSourceFile(applicationPackageName + "." + applicationClassName);
processingEnv.getMessager().printMessage(Diagnostic.Kind.NOTE, "Creating " + fileObject.toUri());
Writer writer = fileObject.openWriter();
PrintWriter pw = new PrintWriter(writer);
pw.print(fileContent);
pw.flush();
writer.close();
}
}代碼比較簡單，可以分三部分理解：
步驟1：首先找到被DefaultLifeCycle標識的Element(為類對象TypeElement)，得到該對象的包名，類名等信息，然后通過該對象，拿到@DefaultLifeCycle對象，獲取該注解中聲明屬性的值。
步驟2：讀取一個模板文件，讀取為字符串，將各個占位符通過步驟1中的值替代。
步驟3：通過JavaFileObject將替換完成的字符串寫文件，其實就是本例中的Application對象。
我們看一眼模板文件：
package %PACKAGE%;import com.tencent.tinker.loader.app.TinkerApplication;/**
*
* Generated application for tinker life cycle
*
*/public class %APPLICATION% extends TinkerApplication {
public %APPLICATION%() { super(%TINKER_FLAGS%, "%APPLICATION_LIFE_CYCLE%", "%TINKER_LOADER_CLASS%", %TINKER_LOAD_VERIFY_FLAG%);
}
}對應我們的SimpleTinkerInApplicationLike，
@DefaultLifeCycle(application = ".SimpleTinkerInApplication",
flags = ShareConstants.TINKER_ENABLE_ALL,
loadVerifyFlag = false)public class SimpleTinkerInApplicationLike extends ApplicationLike {}主要就幾個占位符：
包名，如果application屬性值以點開始，則同包；否則則截取
類名，application屬性值中的類名
%TINKER_FLAGS%對應flags
%APPLICATION_LIFE_CYCLE%，編寫的ApplicationLike的全路徑
“%TINKER_LOADER_CLASS%”，這個值我們沒有設置，實際上對應
@DefaultLifeCycle的loaderClass屬性，默認值為com.tencent.tinker.loader.TinkerLoader%TINKER_LOAD_VERIFY_FLAG%對應loadVerifyFlag
于是最終生成的代碼為：
/**
*
* Generated application for tinker life cycle
*
*/public class SimpleTinkerInApplication extends TinkerApplication {
public SimpleTinkerInApplication() { super(7, "com.zhy.tinkersimplein.SimpleTinkerInApplicationLike", "com.tencent.tinker.loader.TinkerLoader", false);
}
}tinker這么做的目的，文檔上是這么說的：
為了減少錯誤的出現，推薦使用Annotation生成Application類。
這樣大致了解了Application是如何生成的。
接下來我們大致看一下tinker的原理。
來源于：https://github.com/Tencent/tinker
tinker貼了一張大致的原理圖。
可以看出：
tinker將old.apk和new.apk做了diff，拿到patch.dex，然后將patch.dex與本機中apk的classes.dex做了合并，生成新的classes.dex，運行時通過反射將合并后的dex文件放置在加載的dexElements數組的前面。
運行時替代的原理，其實和Qzone的方案差不多，都是去反射修改dexElements。
兩者的差異是：Qzone是直接將patch.dex插到數組的前面；而tinker是將patch.dex與app中的classes.dex合并后的全量dex插在數組的前面。
tinker這么做的目的還是因為Qzone方案中提到的CLASS_ISPREVERIFIED的解決方案存在問題；而tinker相當于換個思路解決了該問題。
接下來我們就從代碼中去驗證該原理。
本片文章源碼分析的兩條線：
應用啟動時，從默認目錄加載合并后的classes.dex
patch下發后，合成classes.dex至目標目錄
加載的代碼實際上在生成的Application中調用的，其父類為TinkerApplication，在其attachBaseContext中輾轉會調用到loadTinker()方法，在該方法內部，反射調用了TinkerLoader的tryLoad方法。
@Overridepublic Intent tryLoad(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag) {
Intent resultIntent = new Intent(); long begin = SystemClock.elapsedRealtime();
tryLoadPatchFilesInternal(app, tinkerFlag, tinkerLoadVerifyFlag, resultIntent); long cost = SystemClock.elapsedRealtime() - begin;
ShareIntentUtil.setIntentPatchCostTime(resultIntent, cost); return resultIntent;
}tryLoadPatchFilesInternal中會調用到loadTinkerJars方法：
private void tryLoadPatchFilesInternal(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag, Intent resultIntent) { // 省略大量安全性校驗代碼
if (isEnabledForDex) { //tinker/patch.info/patch-641e634c/dex
boolean dexCheck = TinkerDexLoader.checkComplete(patchVersionDirectory, securityCheck, resultIntent); if (!dexCheck) { //file not found, do not load patch
Log.w(TAG, "tryLoadPatchFiles:dex check fail"); return;
}
} //now we can load patch jar
if (isEnabledForDex) { boolean loadTinkerJars = TinkerDexLoader.loadTinkerJars(app, tinkerLoadVerifyFlag, patchVersionDirectory, resultIntent, isSystemOTA); if (!loadTinkerJars) {
Log.w(TAG, "tryLoadPatchFiles:onPatchLoadDexesFail"); return;
}
}
}TinkerDexLoader.checkComplete主要是用于檢查下發的meta文件中記錄的dex信息（meta文件，可以查看生成patch的產物，在assets/dex-meta.txt），檢查meta文件中記錄的dex文件信息對應的dex文件是否存在，并把值存在TinkerDexLoader的靜態變量dexList中。
TinkerDexLoader.loadTinkerJars傳入四個參數，分別為application，tinkerLoadVerifyFlag（注解上聲明的值，傳入為false），patchVersionDirectory當前version的patch文件夾，intent，當前patch是否僅適用于art。
@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)public static boolean loadTinkerJars(Application application, boolean tinkerLoadVerifyFlag,
String directory, Intent intentResult, boolean isSystemOTA) {
PathClassLoader classLoader = (PathClassLoader) TinkerDexLoader.class.getClassLoader();
String dexPath = directory + "/" + DEX_PATH + "/";
File optimizeDir = new File(directory + "/" + DEX_OPTIMIZE_PATH);
ArrayList<File> legalFiles = new ArrayList<>(); final boolean isArtPlatForm = ShareTinkerInternals.isVmArt(); for (ShareDexDiffPatchInfo info : dexList) { //for dalvik, ignore art support dex
if (isJustArtSupportDex(info)) { continue;
}
String path = dexPath + info.realName;
File file = new File(path);
legalFiles.add(file);
} // just for art
if (isSystemOTA) {
parallelOTAResult = true;
parallelOTAThrowable = null;
Log.w(TAG, "systemOTA, try parallel oat dexes!!!!!");
TinkerParallelDexOptimizer.optimizeAll(
legalFiles, optimizeDir, new TinkerParallelDexOptimizer.ResultCallback() {
}
);
SystemClassLoaderAdder.installDexes(application, classLoader, optimizeDir, legalFiles); return true;
}找出僅支持art的dex，且當前patch是否僅適用于art時，并行去loadDex。
關鍵是最后的installDexes：
@SuppressLint("NewApi")public static void installDexes(Application application, PathClassLoader loader, File dexOptDir, List<File> files) throws Throwable { if (!files.isEmpty()) {
ClassLoader classLoader = loader; if (Build.VERSION.SDK_INT >= 24) {
classLoader = AndroidNClassLoader.inject(loader, application);
} //because in dalvik, if inner class is not the same classloader with it wrapper class.
//it won't fail at dex2opt
if (Build.VERSION.SDK_INT >= 23) {
V23.install(classLoader, files, dexOptDir);
} else if (Build.VERSION.SDK_INT >= 19) {
V19.install(classLoader, files, dexOptDir);
} else if (Build.VERSION.SDK_INT >= 14) {
V14.install(classLoader, files, dexOptDir);
} else {
V4.install(classLoader, files, dexOptDir);
} //install done
sPatchDexCount = files.size();
Log.i(TAG, "after loaded classloader: " + classLoader + ", dex size:" + sPatchDexCount); if (!checkDexInstall(classLoader)) { //reset patch dex
SystemClassLoaderAdder.uninstallPatchDex(classLoader); throw new TinkerRuntimeException(ShareConstants.CHECK_DEX_INSTALL_FAIL);
}
}
}這里實際上就是根據不同的系統版本，去反射處理dexElements。
我們看一下V19的實現（主要我看了下本機只有個22的源碼~）：
private static final class V19 {
private static void install(ClassLoader loader, List<File> additionalClassPathEntries,
File optimizedDirectory) throws IllegalArgumentException, IllegalAccessException,
NoSuchFieldException, InvocationTargetException, NoSuchMethodException, IOException {
Field pathListField = ShareReflectUtil.findField(loader, "pathList");
Object dexPathList = pathListField.get(loader);
ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>();
ShareReflectUtil.expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList, new ArrayList<File>(additionalClassPathEntries), optimizedDirectory,
suppressedExceptions)); if (suppressedExceptions.size() > 0) { for (IOException e : suppressedExceptions) {
Log.w(TAG, "Exception in makeDexElement", e); throw e;
}
}
}
}找到PathClassLoader（BaseDexClassLoader）對象中的pathList對象
根據pathList對象找到其中的makeDexElements方法，傳入patch相關的對應的實參，返回Element[]對象
拿到pathList對象中原本的dexElements方法
步驟2與步驟3中的Element[]數組進行合并，將patch相關的dex放在數組的前面
最后將合并后的數組，設置給pathList
這里其實和Qzone的提出的方案基本是一致的。如果你以前未了解過Qzone的方案，可以參考此文：
Android 熱補丁動態修復框架小結
這里的入口為：
TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(), Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed.apk");
上述代碼會調用DefaultPatchListener中的onPatchReceived方法:
# DefaultPatchListener@Overridepublic int onPatchReceived(String path) { int returnCode = patchCheck(path); if (returnCode == ShareConstants.ERROR_PATCH_OK) {
TinkerPatchService.runPatchService(context, path);
} else {
Tinker.with(context).getLoadReporter().onLoadPatchListenerReceiveFail(new File(path), returnCode);
} return returnCode;
}首先對tinker的相關配置（isEnable）以及patch的合法性進行檢測，如果合法，則調用TinkerPatchService.runPatchService(context, path);。
public static void runPatchService(Context context, String path) { try {
Intent intent = new Intent(context, TinkerPatchService.class);
intent.putExtra(PATCH_PATH_EXTRA, path);
intent.putExtra(RESULT_CLASS_EXTRA, resultServiceClass.getName());
context.startService(intent);
} catch (Throwable throwable) {
TinkerLog.e(TAG, "start patch service fail, exception:" + throwable);
}
}TinkerPatchService是IntentService的子類，這里通過intent設置了兩個參數，一個是patch的路徑，一個是resultServiceClass，該值是調用Tinker.install的時候設置的，默認為DefaultTinkerResultService.class。由于是IntentService，直接看onHandleIntent即可，如果你對IntentService陌生
@Overrideprotected void onHandleIntent(Intent intent) { final Context context = getApplicationContext();
Tinker tinker = Tinker.with(context);
String path = getPatchPathExtra(intent);
File patchFile = new File(path); boolean result;
increasingPriority();
PatchResult patchResult = new PatchResult();
result = upgradePatchProcessor.tryPatch(context, path, patchResult);
patchResult.isSuccess = result;
patchResult.rawPatchFilePath = path;
patchResult.costTime = cost;
patchResult.e = e;
AbstractResultService.runResultService(context, patchResult, getPatchResultExtra(intent));
}比較清晰，主要關注upgradePatchProcessor.tryPatch方法，調用的是UpgradePatch.tryPatch。ps:這里有個有意思的地方increasingPriority()，其內部實現為：
private void increasingPriority() {
TinkerLog.i(TAG, "try to increase patch process priority"); try {
Notification notification = new Notification(); if (Build.VERSION.SDK_INT < 18) {
startForeground(notificationId, notification);
} else {
startForeground(notificationId, notification); // start InnerService
startService(new Intent(this, InnerService.class));
}
} catch (Throwable e) {
TinkerLog.i(TAG, "try to increase patch process priority error:" + e);
}
}如果你對“保活”這個話題比較關注，那么對這段代碼一定不陌生，主要是利用系統的一個漏洞來啟動一個前臺Service。
下面繼續回到tryPatch方法：
# UpgradePatch@Overridepublic boolean tryPatch(Context context, String tempPatchPath, PatchResult patchResult) {
Tinker manager = Tinker.with(context); final File patchFile = new File(tempPatchPath); //it is a new patch, so we should not find a exist
SharePatchInfo oldInfo = manager.getTinkerLoadResultIfPresent().patchInfo;
String patchMd5 = SharePatchFileUtil.getMD5(patchFile); //use md5 as version
patchResult.patchVersion = patchMd5;
SharePatchInfo newInfo; //already have patch
if (oldInfo != null) {
newInfo = new SharePatchInfo(oldInfo.oldVersion, patchMd5, Build.FINGERPRINT);
} else {
newInfo = new SharePatchInfo("", patchMd5, Build.FINGERPRINT);
} //check ok, we can real recover a new patch
final String patchDirectory = manager.getPatchDirectory().getAbsolutePath(); final String patchName = SharePatchFileUtil.getPatchVersionDirectory(patchMd5); final String patchVersionDirectory = patchDirectory + "/" + patchName; //copy file
File destPatchFile = new File(patchVersionDirectory + "/" + SharePatchFileUtil.getPatchVersionFile(patchMd5)); // check md5 first
if (!patchMd5.equals(SharePatchFileUtil.getMD5(destPatchFile))) {
SharePatchFileUtil.copyFileUsingStream(patchFile, destPatchFile);
} //we use destPatchFile instead of patchFile, because patchFile may be deleted during the patch process
if (!DexDiffPatchInternal.tryRecoverDexFiles(manager, signatureCheck, context, patchVersionDirectory,
destPatchFile)) {
TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch dex failed"); return false;
} return true;
}拷貝patch文件拷貝至私有目錄，然后調用DexDiffPatchInternal.tryRecoverDexFiles：
protected static boolean tryRecoverDexFiles(Tinker manager, ShareSecurityCheck checker, Context context,
String patchVersionDirectory, File patchFile) {
String dexMeta = checker.getMetaContentMap().get(DEX_META_FILE); boolean result = patchDexExtractViaDexDiff(context, patchVersionDirectory, dexMeta, patchFile); return result;
}直接看patchDexExtractViaDexDiff
private static boolean patchDexExtractViaDexDiff(Context context, String patchVersionDirectory, String meta, final File patchFile) {
String dir = patchVersionDirectory + "/" + DEX_PATH + "/"; if (!extractDexDiffInternals(context, dir, meta, patchFile, TYPE_DEX)) {
TinkerLog.w(TAG, "patch recover, extractDiffInternals fail"); return false;
} final Tinker manager = Tinker.with(context);
File dexFiles = new File(dir);
File[] files = dexFiles.listFiles();
...files遍歷執行：DexFile.loadDex return true;
}核心代碼主要在extractDexDiffInternals中：
private static boolean extractDexDiffInternals(Context context, String dir, String meta, File patchFile, int type) { //parse meta
ArrayList<ShareDexDiffPatchInfo> patchList = new ArrayList<>();
ShareDexDiffPatchInfo.parseDexDiffPatchInfo(meta, patchList);
File directory = new File(dir); //I think it is better to extract the raw files from apk
Tinker manager = Tinker.with(context);
ZipFile apk = null;
ZipFile patch = null;
ApplicationInfo applicationInfo = context.getApplicationInfo();
String apkPath = applicationInfo.sourceDir; //base.apk
apk = new ZipFile(apkPath);
patch = new ZipFile(patchFile); for (ShareDexDiffPatchInfo info : patchList) { final String infoPath = info.path;
String patchRealPath; if (infoPath.equals("")) {
patchRealPath = info.rawName;
} else {
patchRealPath = info.path + "/" + info.rawName;
}
File extractedFile = new File(dir + info.realName);
ZipEntry patchFileEntry = patch.getEntry(patchRealPath);
ZipEntry rawApkFileEntry = apk.getEntry(patchRealPath);
patchDexFile(apk, patch, rawApkFileEntry, patchFileEntry, info, extractedFile);
} return true;
}這里的代碼比較關鍵了，可以看出首先解析了meta里面的信息，meta中包含了patch中每個dex的相關數據。然后通過Application拿到sourceDir，其實就是本機apk的路徑以及patch文件；根據mate中的信息開始遍歷，其實就是取出對應的dex文件，最后通過patchDexFile對兩個dex文件做合并。
private static void patchDexFile(
ZipFile baseApk, ZipFile patchPkg, ZipEntry oldDexEntry, ZipEntry patchFileEntry,
ShareDexDiffPatchInfo patchInfo, File patchedDexFile) throws IOException {
InputStream oldDexStream = null;
InputStream patchFileStream = null;
oldDexStream = new BufferedInputStream(baseApk.getInputStream(oldDexEntry));
patchFileStream = (patchFileEntry != null ? new BufferedInputStream(patchPkg.getInputStream(patchFileEntry)) : null); new DexPatchApplier(oldDexStream, patchFileStream).executeAndSaveTo(patchedDexFile);
}通過ZipFile拿到其內部文件的InputStream，其實就是讀取本地apk對應的dex文件，以及patch中對應dex文件，對二者的通過executeAndSaveTo方法進行合并至patchedDexFile，即patch的目標私有目錄。
以上是“Android熱修復Tinker接入的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
