欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Android熱修復(fù)Tinker接入及源碼解讀

 更新時(shí)間：2018年09月14日 17:01:27   投稿：wdc  
熱修復(fù)這項(xiàng)技術(shù)，基本上已經(jīng)成為項(xiàng)目比較重要的模塊了。主要因?yàn)轫?xiàng)目在上線之后，都難免會(huì)有各種問題本文講述了Android熱修復(fù)Tinker接入及源碼解讀

一、概述

熱修復(fù)這項(xiàng)技術(shù)，基本上已經(jīng)成為項(xiàng)目比較重要的模塊了。主要因?yàn)轫?xiàng)目在上線之后，都難免會(huì)有各種問題，而依靠發(fā)版去修復(fù)問題，成本太高了。

現(xiàn)在熱修復(fù)的技術(shù)基本上有阿里的AndFix、QZone的方案、美團(tuán)提出的思想方案以及騰訊的Tinker等。

其中AndFix可能接入是最簡(jiǎn)單的一個(gè)（和Tinker命令行接入方式差不多），不過兼容性還是是有一定的問題的；QZone方案對(duì)性能會(huì)有一定的影響，且在Art模式下出現(xiàn)內(nèi)存錯(cuò)亂的問題(其實(shí)這個(gè)問題我之前并不清楚，主要是tinker在MDCC上指出的);美團(tuán)提出的思想方案主要是基于Instant Run的原理，目前尚未開源，不過這個(gè)方案我還是蠻喜歡的，主要是兼容性好。

這么看來，如果選擇開源方案，tinker目前是最佳的選擇，tinker的介紹有這么一句：

Tinker已運(yùn)行在微信的數(shù)億Android設(shè)備上，那么為什么你不使用Tinker呢？

好了，說了這么多，下面來看看tinker如何接入，以及tinker的大致的原理分析。希望通過本文可以實(shí)現(xiàn)幫助大家更好的接入tinker，以及去了解tinker的一個(gè)大致的原理。

二、接入Tinker

接入tinker目前給了兩種方式，一種是基于命令行的方式，類似于AndFix的接入方式；一種就是gradle的方式。

考慮早期使用Andfix的app應(yīng)該挺多的，以及很多人對(duì)gradle的相關(guān)配置還是覺得比較繁瑣的，下面對(duì)兩種方式都介紹下。

（1）命令行接入

接入之前我們先考慮下，接入的話，正常需要的前提（開啟混淆的狀態(tài)）。

對(duì)于API

一般來說，我們接入熱修庫(kù)，會(huì)在Application#onCreate中進(jìn)行一下初始化操作。然后在某個(gè)地方去調(diào)用類似loadPatch這樣的API去加載patch文件。

對(duì)于patch的生成

簡(jiǎn)單的方式就是通過兩個(gè)apk做對(duì)比然后生成；需要注意的是：兩個(gè)apk做對(duì)比，需要的前提條件，第二次打包混淆所使用的mapping文件應(yīng)該和線上apk是一致的。

最后就是看看這個(gè)項(xiàng)目有沒有需要配置混淆；

有了大致的概念，我們就基本了解命令行接入tinker，大致需要哪些步驟了。

依賴引入

dependencies {
  // ...
  //可選，用于生成application類
  provided('com.tencent.tinker:tinker-android-anno:1.7.7')
  //tinker的核心庫(kù)
  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'
    }
  }
}

文末會(huì)有demo的下載地址，可以直接參考build.gradle文件，不用擔(dān)心這些簽名文件去哪找。

API引入

API主要就是初始化和loadPacth。

正常情況下，我們會(huì)考慮在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通過名字你可能會(huì)猜，并非是Application的子類，而是一個(gè)類似Application的類。

tinker建議編寫一個(gè)ApplicationLike的子類，你可以當(dāng)成Application去使用，注意頂部的注解：@DefaultLifeCycle，其application屬性，會(huì)在編譯期生成一個(gè)SimpleTinkerInApplication類。

所以，雖然我們這么寫了，但是實(shí)際上Application會(huì)在編譯期生成，所以AndroidManifest.xml中是這樣的：

 <application
    android:name=".SimpleTinkerInApplication"
    .../>

 

編寫如果報(bào)紅，可以build下。

這樣其實(shí)也能猜出來，這個(gè)注解背后有個(gè)Annotation Processor在做處理

通過該文會(huì)對(duì)一個(gè)編譯時(shí)注解的運(yùn)行流程和基本API有一定的掌握，文中也會(huì)對(duì)tinker該部分的源碼做解析。

上述，就完成了tinker的初始化，那么調(diào)用loadPatch的時(shí)機(jī)，我們直接在Activity中添加一個(gè)Button設(shè)置：

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");
  }
}

我們會(huì)將patch文件直接push到sdcard根目錄；

所以一定要注意：添加SDCard權(quán)限，如果你是6.x以上的系統(tǒng)，自己添加上授權(quán)代碼，或者手動(dòng)在設(shè)置頁(yè)面打開SDCard讀寫權(quán)限。

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

除以以外，有個(gè)特殊的地方就是tinker需要在AndroidManifest.xml中指定TINKER_ID。

<application>
 <meta-data
      android:name="TINKER_ID"
      android:value="tinker_id_6235657" />
  //...</application>

到此API相關(guān)的就結(jié)束了，剩下的就是考慮patch如何生成。

patch生成

tinker提供了patch生成的工具，源碼見：tinker-patch-cli，打成一個(gè)jar就可以使用，并且提供了命令行相關(guān)的參數(shù)以及文件。

命令行如下：

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提供的簽名文件，所以不需要做修改，不過里面有個(gè)Application的item修改為與本例一致：

<loader value="com.zhy.tinkersimplein.SimpleTinkerInApplication"/>

大致的文件結(jié)構(gòu)如下：

可以在tinker-patch-cli中提取，或者直接下載文末的例子。

上述介紹了patch生成的命令，最后需要注意的就是，在第一次打出apk的時(shí)候，保留下生成的mapping文件，在/build/outputs/mapping/release/mapping.txt。

可以copy到與proguard-rules.pro同目錄，同時(shí)在第二次打修復(fù)包的時(shí)候，在proguard-rules.pro中添加上：

-applymapping mapping.txt

保證后續(xù)的打包與線上包使用的是同一個(gè)mapping文件。

tinker本身的混淆相關(guān)配置，可以參考：

如果，你對(duì)該部分描述不了解，可以直接查看源碼即可。

測(cè)試

首先隨便生成一個(gè)apk（API、混淆相關(guān)已經(jīng)按照上述引入），安裝到手機(jī)或者模擬器上。

然后，copy出mapping.txt文件，設(shè)置applymapping，修改代碼，再次打包，生成new.apk。

兩次的apk，可以通過命令行指令去生成patch文件。

如果你下載本例，命令需要在[該目錄]下執(zhí)行。

最終會(huì)在output文件夾中生成產(chǎn)物：

我們直接將patch_signed.apk push到sdcard，點(diǎn)擊loadpatch，一定要觀察命令行是否成功。

本例修改了title。

點(diǎn)擊loadPatch，觀察log，如果成功，應(yīng)用默認(rèn)為重啟，然后再次啟動(dòng)即可達(dá)到修復(fù)效果。

到這里命令行的方式就介紹完了，和Andfix的接入的方式基本上是一樣的。

值得注意的是:該例僅展示了基本的接入，對(duì)于tinker的各種配置信息，還是需要去讀tinker的文檔（如果你確定要使用）tinker-wiki。

（2）gradle接入

gradle接入的方式應(yīng)該算是主流的方式，所以tinker也直接給出了例子，單獨(dú)將該tinker-sample-android以project方式引入即可。

引入之后，可以查看其接入API的方式，以及相關(guān)配置。

在你每次build時(shí)，會(huì)在build/bakApk下生成本地打包的apk，R文件，以及mapping文件。

如果你需要生成patch文件，可以通過：

./gradlew tinkerPatchRelease // 或者 ./gradlew tinkerPatchDebug

生成。

生成目錄為:build/outputs/tinkerPatch

需要注意的是，需要在app/build.gradle中設(shè)置相比較的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的自定義擴(kuò)展的方式，具體還可以參考：

所以，如果你使用命令行方式接入，也不要忘了學(xué)習(xí)下其支持哪些擴(kuò)展。

三、Application是如何編譯時(shí)生成的

從注釋和命名上看：

//可選，用于生成application類provided('com.tencent.tinker:tinker-android-anno:1.7.7')

明顯是該庫(kù)，其結(jié)構(gòu)如下：

典型的編譯時(shí)注解的項(xiàng)目，源碼見tinker-android-anno。

入口為com.tencent.tinker.anno.AnnotationProcessor，可以在該services/javax.annotation.processing.Processor文件中找到處理類全路徑。

再次建議，如果你不了解，簡(jiǎn)單閱讀下Android 如何編寫基于編譯時(shí)注解的項(xiàng)目該文。

直接看AnnotationProcessor的process方法：

@Overridepublic boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
  processDefaultLifeCycle(roundEnv.getElementsAnnotatedWith(DefaultLifeCycle.class));  return true;
}

直接調(diào)用了processDefaultLifeCycle：

private void processDefaultLifeCycle(Set<? extends Element> elements) {    // 被注解DefaultLifeCycle標(biāo)識(shí)的對(duì)象
    for (Element e : elements) {     // 拿到DefaultLifeCycle注解對(duì)象
      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();

    }
  }

代碼比較簡(jiǎn)單，可以分三部分理解：

  • 步驟1：首先找到被DefaultLifeCycle標(biāo)識(shí)的Element(為類對(duì)象TypeElement)，得到該對(duì)象的包名，類名等信息，然后通過該對(duì)象，拿到@DefaultLifeCycle對(duì)象，獲取該注解中聲明屬性的值。

  • 步驟2：讀取一個(gè)模板文件，讀取為字符串，將各個(gè)占位符通過步驟1中的值替代。

  • 步驟3：通過JavaFileObject將替換完成的字符串寫文件，其實(shí)就是本例中的Application對(duì)象。

我們看一眼模板文件：

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%);
  }

}

對(duì)應(yīng)我們的SimpleTinkerInApplicationLike，

@DefaultLifeCycle(application = ".SimpleTinkerInApplication",
    flags = ShareConstants.TINKER_ENABLE_ALL,
    loadVerifyFlag = false)public class SimpleTinkerInApplicationLike extends ApplicationLike {}

主要就幾個(gè)占位符：

包名，如果application屬性值以點(diǎn)開始，則同包；否則則截取

類名，application屬性值中的類名

%TINKER_FLAGS%對(duì)應(yīng)flags

%APPLICATION_LIFE_CYCLE%，編寫的ApplicationLike的全路徑

“%TINKER_LOADER_CLASS%”，這個(gè)值我們沒有設(shè)置，實(shí)際上對(duì)應(yīng)@DefaultLifeCycle的loaderClass屬性，默認(rèn)值為com.tencent.tinker.loader.TinkerLoader

%TINKER_LOAD_VERIFY_FLAG%對(duì)應(yīng)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這么做的目的，文檔上是這么說的：

為了減少錯(cuò)誤的出現(xiàn)，推薦使用Annotation生成Application類。

這樣大致了解了Application是如何生成的。

接下來我們大致看一下tinker的原理。

四、原理

來源于：https://github.com/Tencent/tinker

tinker貼了一張大致的原理圖。

可以看出：

tinker將old.apk和new.apk做了diff，拿到patch.dex，然后將patch.dex與本機(jī)中apk的classes.dex做了合并，生成新的classes.dex，運(yùn)行時(shí)通過反射將合并后的dex文件放置在加載的dexElements數(shù)組的前面。

運(yùn)行時(shí)替代的原理，其實(shí)和Qzone的方案差不多，都是去反射修改dexElements。

兩者的差異是：Qzone是直接將patch.dex插到數(shù)組的前面；而tinker是將patch.dex與app中的classes.dex合并后的全量dex插在數(shù)組的前面。

tinker這么做的目的還是因?yàn)镼zone方案中提到的CLASS_ISPREVERIFIED的解決方案存在問題；而tinker相當(dāng)于換個(gè)思路解決了該問題。

接下來我們就從代碼中去驗(yàn)證該原理。

本片文章源碼分析的兩條線：

應(yīng)用啟動(dòng)時(shí)，從默認(rèn)目錄加載合并后的classes.dex

patch下發(fā)后，合成classes.dex至目標(biāo)目錄

五、源碼分析

（1）加載patch

加載的代碼實(shí)際上在生成的Application中調(diào)用的，其父類為TinkerApplication，在其attachBaseContext中輾轉(zhuǎn)會(huì)調(diào)用到loadTinker()方法，在該方法內(nèi)部，反射調(diào)用了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中會(huì)調(diào)用到loadTinkerJars方法：

private void tryLoadPatchFilesInternal(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag, Intent resultIntent) {  // 省略大量安全性校驗(yàn)代碼

  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主要是用于檢查下發(fā)的meta文件中記錄的dex信息（meta文件，可以查看生成patch的產(chǎn)物，在assets/dex-meta.txt），檢查meta文件中記錄的dex文件信息對(duì)應(yīng)的dex文件是否存在，并把值存在TinkerDexLoader的靜態(tài)變量dexList中。

TinkerDexLoader.loadTinkerJars傳入四個(gè)參數(shù)，分別為application，tinkerLoadVerifyFlag（注解上聲明的值，傳入為false），patchVersionDirectory當(dāng)前version的patch文件夾，intent，當(dāng)前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，且當(dāng)前patch是否僅適用于art時(shí)，并行去loadDex。

關(guān)鍵是最后的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);
    }
  }
}

這里實(shí)際上就是根據(jù)不同的系統(tǒng)版本，去反射處理dexElements。

我們看一下V19的實(shí)現(xiàn)（主要我看了下本機(jī)只有個(gè)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）對(duì)象中的pathList對(duì)象

根據(jù)pathList對(duì)象找到其中的makeDexElements方法，傳入patch相關(guān)的對(duì)應(yīng)的實(shí)參，返回Element[]對(duì)象

拿到pathList對(duì)象中原本的dexElements方法

步驟2與步驟3中的Element[]數(shù)組進(jìn)行合并，將patch相關(guān)的dex放在數(shù)組的前面

最后將合并后的數(shù)組，設(shè)置給pathList

這里其實(shí)和Qzone的提出的方案基本是一致的。如果你以前未了解過Qzone的方案，可以參考此文：

Android 熱補(bǔ)丁動(dòng)態(tài)修復(fù)框架小結(jié)

（2）合成patch

這里的入口為：

 TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(),
        Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed.apk");

上述代碼會(huì)調(diào)用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;

}

首先對(duì)tinker的相關(guān)配置（isEnable）以及patch的合法性進(jìn)行檢測(cè)，如果合法，則調(diào)用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設(shè)置了兩個(gè)參數(shù)，一個(gè)是patch的路徑，一個(gè)是resultServiceClass，該值是調(diào)用Tinker.install的時(shí)候設(shè)置的，默認(rèn)為DefaultTinkerResultService.class。由于是IntentService，直接看onHandleIntent即可，如果你對(duì)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));

}

比較清晰，主要關(guān)注upgradePatchProcessor.tryPatch方法，調(diào)用的是UpgradePatch.tryPatch。ps:這里有個(gè)有意思的地方increasingPriority()，其內(nèi)部實(shí)現(xiàn)為：

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);
  }
}

如果你對(duì)“保活”這個(gè)話題比較關(guān)注，那么對(duì)這段代碼一定不陌生，主要是利用系統(tǒng)的一個(gè)漏洞來啟動(dòng)一個(gè)前臺(tái)Service。

下面繼續(xù)回到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文件拷貝至私有目錄，然后調(diào)用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遍歷執(zhí)行：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;
}

這里的代碼比較關(guān)鍵了，可以看出首先解析了meta里面的信息，meta中包含了patch中每個(gè)dex的相關(guān)數(shù)據(jù)。然后通過Application拿到sourceDir，其實(shí)就是本機(jī)apk的路徑以及patch文件；根據(jù)mate中的信息開始遍歷，其實(shí)就是取出對(duì)應(yīng)的dex文件，最后通過patchDexFile對(duì)兩個(gè)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拿到其內(nèi)部文件的InputStream，其實(shí)就是讀取本地apk對(duì)應(yīng)的dex文件，以及patch中對(duì)應(yīng)dex文件，對(duì)二者的通過executeAndSaveTo方法進(jìn)行合并至patchedDexFile，即patch的目標(biāo)私有目錄。

至于合并算法，這里其實(shí)才是tinker比較核心的地方，這個(gè)算法跟dex文件格式緊密關(guān)聯(lián)，如果有機(jī)會(huì)，然后我又能看懂的話，后面會(huì)單獨(dú)寫篇博客介紹。此外dodola已經(jīng)有篇博客進(jìn)行了介紹：

Tinker Dexdiff算法解析

感興趣的可以閱讀下。

好了，到此我們就大致了解了tinker熱修復(fù)的原理~~

測(cè)試demo地址：

https://github.com/WanAndroid/tinkerTest

當(dāng)然這里只分析了代碼了熱修復(fù)，后續(xù)考慮分析資源以及So的熱修、核心的diff算法、以及gradle插件等相關(guān)知識(shí)~

相關(guān)文章

最新評(píng)論