Tinker 热修复的优点和缺点，以及为什么选择Tinker热修复和Tinker的实现原理

热补丁方案的比较

**
 Tinker QZone AndFix(阿里) Robust(美团)
类替换 yes yes no no
So替换 yes no no no
资源替换 yes yes no no
全平台支持 yes yes yes yes
即时生效 no no yes yes
性能损耗 较小 较大 较小 较小
补丁包大小 较小 较大 一般 一般
开发透明 yes yes no no
复杂度 较低 较低 复杂 复杂
gradle支持 yes no no no
Rom体积 较大 较小 较小 较小
成功率 较高 较高 一般 最高
  1. AndFix作为native解决方案，首先面临的是稳定性与兼容性问题，更重要的是它无法实现类替换，它是需要大量额外的开发成本的；在native动态替换java层的方法，通过native层hook java层的代码。

image.png

  1. Robust(字节码插装技术)兼容性与成功率较高，但是它与AndFix一样，无法新增变量与类只能用做的bugFix方案；在对每个函数都在编译打包阶段自动的插入了一段代码，类似于代理，将方法的执行的代码重定向到其他方法中。

image.png

  1. Qzone方案可以做到发布产品功能，但是它主要问题是插桩带来Dalvik的性能问题，以及为了解决Art下内存地址问题而导致补丁包急速增大的。Qzone和Tinker的原理类似 ClassLoader的双亲委派机制（比如java.String(系统) com.String(自定义) 会加载java.String这个类，使自定义的优先于系统的这样就只会加载自定义的类 dex -> pathList的顶部 -> App）
  2. Tinker通过计算对比指定的Base Apk中的dex与修改后的Apk的dex的区别，补丁包中的内容即为两者差分，运行时将Base Apk中的dex与补丁包进行合成，重启后加载全新的合成后的dex文件(Tinker 必须要重启App后才能生效)

image.png

特别是在Android N之后，由于混合编译的inline策略修改，对于市面上的各种方案都不太容易解决。而Tinker热补丁方案不仅支持类、So以及资源的替换，它还是2.X－8.X(1.9.0以上支持8.X)的全平台支持。利用Tinker我们不仅可以用做bugfix,甚至可以替代功能的发布。

Tinker的限制

由于原理与系统限制，Tinker有以下已知问题：

  1. Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大组件(1.9.0支持新增非export的Activity)；
  2. 由于Google Play的开发者条款限制，不建议在GP渠道动态更新代码；
  3. 在Android N上，补丁对应用启动时间有轻微的影响；
  4. 不支持部分三星android-21机型，加载补丁时会主动抛出"TinkerRuntimeException:checkDexInstall failed"；
  5. 对于资源替换，不支持修改remoteView。例如transition动画，notification ``icon以及桌面图标。

  6. 社区人员维护的，由于开源免费，gradle最新版本不支持兼容性存在一定的问题，目前必须4.0以下的gradle才可以。集成项目中需要大量的时间去校验和验证改成错误等。

    Tinker的使用

  7. 引入插件依赖

    1. dependencies {
    2.      classpath 'com.android.tools.build:gradle:3.5.3'
    3.      classpath("com.tencent.tinker:tinker-patch-gradle-plugin:${TINKER_VERSION}")         {
    4.          changing = TINKER_VERSION?.endsWith("-SNAPSHOT")
    5.          exclude group: 'com.android.tools.build', module: 'gradle'
    6.      }
    7.  }
    8. configurations.all {
    9.      it.resolutionStrategy.cacheDynamicVersionsFor(5, 'minutes')
    10.      it.resolutionStrategy.cacheChangingModulesFor(0, 'seconds')
    11.  }

    在gradle.properties中设置tinker的版本和ID(当生成dex包时，顺序+1即可)

    1. TINKER_VERSION=1.9.14.17
    2. TINKER_ID=1063
    3. #是否开启tinker
    4. TINKER_ENABLE=true
    5. #是否是gradle 3.x的版本
    6. GRADLE_3=true

  8. 引入tinker核心库

    1.  api("com.tencent.tinker:tinker-android-lib:${TINKER_VERSION}") { changing = true }
    3.  // Maven local cannot handle transist dependencies.
    4.  implementation("com.tencent.tinker:tinker-android-loader:${TINKER_VERSION}") { changing = true }
    6.  annotationProcessor("com.tencent.tinker:tinker-android-anno:${TINKER_VERSION}") { changing = true }
    7.  compileOnly("com.tencent.tinker:tinker-android-anno:${TINKER_VERSION}") { changing = true }
    8.  compileOnly("com.tencent.tinker:tinker-android-anno-support:${TINKER_VERSION}") { changing = true }
    9.  //多分包依赖
    10.  implementation "androidx.multidex:multidex:2.0.1"

    defaultConfig 配置

    1.  defaultConfig {
    2.      ......
    3.      /**
    4.       * you can use multiDex and install it in your ApplicationLifeCycle implement
    5.       * 开启多分包
    6.       */
    7.      multiDexEnabled true
    8.      //tinker混淆情况处理
    9.      multiDexKeepProguard file("tinker_multidexkeep.pro")
    10.      /**
    11.       * buildConfig can change during patch!
    12.       * we can use the newly value when patch
    13.       * 配置patch信息
    14.       */
    15.      buildConfigField "String", "MESSAGE", "\"I am the base apk\""
    16.      /**
    17.       * client version would update with patch
    18.       * so we can get the newly git version easily!
    19.       * 配置TINKER_ID
    20.       */
    21.      buildConfigField "String", "TINKER_ID", "\"${TINKER_ID}\""
    22.      /**
    23.      * 支持全平台
    24.      */
    25.      buildConfigField "String", "PLATFORM", "\"all\""
    26.  }
    27.  //recommend 开启jumboMode
    28.  dexOptions {
    29.      jumboMode = true
    30.  }

  9. 创建ApplicationLike代理类

    1. @DefaultLifeCycle(application = "tinker.sample.android.app.SampleApplication",//自动帮助生成SampleApplication类这个类就是Application
    2.                flags = ShareConstants.TINKER_ENABLE_ALL,
    3.                loadVerifyFlag = false)
    4. public class SampleApplicationLike extends DefaultApplicationLike {
    5.  private static final String TAG = "Tinker.SampleApplicationLike";
    7.  public SampleApplicationLike(Application application, int tinkerFlags, boolean tinkerLoadVerifyFlag,
    8.                               long applicationStartElapsedTime, long applicationStartMillisTime, Intent tinkerResultIntent) {
    9.      super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);
    10.  }
    12.  @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    13.  @Override
    14.  public void onBaseContextAttached(Context base) {
    15.      super.onBaseContextAttached(base);
    16.      //you must install multiDex whatever tinker is installed!
    17.      MultiDex.install(base);
    19.      SampleApplicationContext.application = getApplication();
    20.      SampleApplicationContext.context = getApplication();
    21.  }
    23.  @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    24.  public void registerActivityLifecycleCallbacks(Application.ActivityLifecycleCallbacks callback) {
    25.      getApplication().registerActivityLifecycleCallbacks(callback);
    26.  }
    27. }

  10. 创建Tinker管理类TinkerManager，在Tinker的Demo中提供了这个类，直接拿过来即可 在这里

  11. 在ApplicationLike中的onBaseContextAttached执行TinkerManager.installedTinker(this)

    1.       TinkerManager.setTinkerApplicationLike(this);
    3.      TinkerManager.initFastCrashProtect();
    4.      //should set before tinker is installed
    5.      TinkerManager.setUpgradeRetryEnable(true);
    7.      //optional set logIml, or you can use default debug log
    8.      TinkerInstaller.setLogIml(new MyLogImp());
    10.      //installTinker after load multiDex
    11.      //or you can put com.tencent.tinker.** to main dex
    12.      TinkerManager.installTinker(this);
    13.      Tinker tinker = Tinker.with(getApplication());

  12. 配置Application,编译项目会得到一个自动生成的SampleApplication的class ```groovy public class SampleApplication extends TinkerApplication {

    public SampleApplication() {

    1.  super(15, "tinker.sample.android.app.SampleApplicationLike", "com.tencent.tinker.loader.TinkerLoader", false, false);

    }

}

  1. 然后设置到manifest中
  2. ```groovy
  3.     <application
  4.         android:name=".app.SampleApplication"
  5.         android:icon="@mipmap/ic_launcher"
  6.         android:label="@string/app_name"
  7.         android:theme="@style/AppTheme">
  8.     ......
  1. 生成基础apk包

Tinker 脚本配置 tinker.gradle，一般我们只需要配置ext中的tinkerEnabled、tinkerOldApkPath、tinkerApplyMappingPath、tinkerApplyResourcePath、tinkerBuildFlavorDirectory这几个选项，其他的配置一般都不要改动。然后将Tinker脚本文件引入即可：apply from: 'tinker.gradle'

平时开发不用开启tinkerEnabled 设置为FALSE即可，如果需要热修复就需要开启tinkerEnabled打基准包(平时一定要做好app的版本tag，当app上线后即使打tag，以后根据tag的代码来打基准包)

  1. def bakPath = file("${buildDir}/bakApk/")
  3. ext {
  4.     //for some reason, you may want to ignore tinkerBuild, such as instant run debug build?
  5.     tinkerEnabled = true
  6.     //基准apk路径
  7.     tinkerOldApkPath = "${bakPath}/app-debug-0830-17-11-57.apk"
  8.     //未开启混淆，则不需要填写
  9.     tinkerApplyMappingPath = "${bakPath}/"
  10.     //基准apk中的R文件路径
  11.     tinkerApplyResourcePath = "${bakPath}/app-debug-0830-17-11-57-R.txt"
  12.     //如果你修复了res文件，需要指定你bug版本的R.txt文件
  13.     tinkerBuildFlavorDirectory = "${bakPath}/app-debug-0830-17-11-57-R.txt"
  15. }
  17. //获取旧版本路径
  18. def getOldApkPath() {
  19.     return hasProperty("OLD_APK") ? OLD_APK : ext.tinkerOldApkPath
  20. }
  22. //获取mapping文件路径
  23. def getApplyMappingPath() {
  24.     return hasProperty("APPLY_MAPPING") ? APPLY_MAPPING : ext.tinkerApplyMappingPath
  25. }
  27. //获取资源mapping路径
  28. def getApplyResourceMappingPath() {
  29.     return hasProperty("APPLY_RESOURCE") ? APPLY_RESOURCE : ext.tinkerApplyResourcePath
  30. }
  32. //Tinker是否可用，是否
  33. def buildWithTinker() {
  34.     return hasProperty("TINKER_ENABLE") ? TINKER_ENABLE : ext.tinkerEnabled
  35. }
  37. //获取tinker差分包目录
  38. def getTinkerBuildFlavorDirectory() {
  39.     return ext.tinkerBuildFlavorDirectory
  40. }
  44. if (buildWithTinker()) {
  45.     apply plugin: 'com.tencent.tinker.patch'
  47.     tinkerPatch {
  48.         /**
  49.          * 默认为null
  50.          * 将旧的apk和新的apk建立关联
  51.          * 从build / bakApk添加apk
  52.          */
  53.         oldApk = getOldApkPath()
  54.         /**
  55.          * 可选，默认'false'
  56.          *有些情况下我们可能会收到一些警告
  57.          *如果ignoreWarning为true，我们只是断言补丁过程
  58.          * case 1：minSdkVersion低于14，但是你使用dexMode与raw。
  59.          * case 2：在AndroidManifest.xml中新添加Android组件，
  60.          * case 3：装载器类在dex.loader {}不保留在主要的dex，
  61.          *          它必须让tinker不工作。
  62.          * case 4：在dex.loader {}中的loader类改变，
  63.          *          加载器类是加载补丁dex。改变它们是没有用的。
  64.          *          它不会崩溃，但这些更改不会影响。你可以忽略它
  65.          * case 5：resources.arsc已经改变，但是我们不使用applyResourceMapping来构建
  66.          */
  67.         ignoreWarning = true
  69.         /**
  70.          * 可选，默认为“true”
  71.          * 是否签名补丁文件
  72.          * 如果没有，你必须自己做。否则在补丁加载过程中无法检查成功
  73.          * 我们将使用sign配置与您的构建类型
  74.          */
  75.         useSign = true
  77.         /**
  78.          * 可选，默认为“true”
  79.          * 是否使用tinker构建
  80.          */
  81.         tinkerEnable = buildWithTinker()
  83.         /**
  84.          * 警告，applyMapping会影响正常的android build！
  85.          */
  86.         buildConfig {
  87.             /**
  88.              * 可选，默认为'null'
  89.              * 如果我们使用tinkerPatch构建补丁apk，你最好应用旧的
  90.              * apk映射文件如果minifyEnabled是启用！
  91.              * 警告：你必须小心，它会影响正常的组装构建！
  92.              */
  93.             applyMapping = getApplyMappingPath()
  94.             /**
  95.              * 可选，默认为'null'
  96.              * 最好保留R.txt文件中的资源id，以减少java更改
  97.              */
  98.             applyResourceMapping = getApplyResourceMappingPath()
  100.             /**
  101.              * 必需，默认'null'
  102.              * 因为我们不想检查基地apk与md5在运行时（它是慢）
  103.              * tinkerId用于在试图应用补丁时标识唯一的基本apk。
  104.              * 我们可以使用git rev，svn rev或者简单的versionCode。
  105.              * 我们将在您的清单中自动生成tinkerId
  106.              */
  107.             tinkerId = TINKER_ID.toInteger()
  109.             /**
  110.              * 如果keepDexApply为true，则表示dex指向旧apk的类。
  111.              * 打开这可以减少dex diff文件大小。
  112.              */
  113.             keepDexApply = false
  115.             /**
  116.              * optional, default 'false'
  117.              * Whether tinker should treat the base apk as the one being protected by app
  118.              * protection tools.
  119.              * If this attribute is true, the generated patch package will contain a
  120.              * dex including all changed classes instead of any dexdiff patch-info files.
  121.              */
  122.             isProtectedApp = false
  124.             /**
  125.              * optional, default 'false'
  126.              * Whether tinker should support component hotplug (add new component dynamically).
  127.              * If this attribute is true, the component added in new apk will be available after
  128.              * patch is successfully loaded. Otherwise an error would be announced when generating patch
  129.              * on compile-time.
  130.              *
  131.              * <b>Notice that currently this feature is incubating and only support NON-EXPORTED Activity</b>
  132.              */
  133.             supportHotplugComponent = false
  134.         }
  136.         dex {
  137.             /**
  138.              * 可选，默认'jar'
  139.              * 只能是'raw'或'jar'。对于原始，我们将保持其原始格式
  140.              * 对于jar，我们将使用zip格式重新包装dexes。
  141.              * 如果你想支持下面14，你必须使用jar
  142.              * 或者你想保存rom或检查更快，你也可以使用原始模式
  143.              */
  144.             dexMode = "jar"
  146.             /**
  147.              * 必需，默认'[]'
  148.              * apk中的dexes应该处理tinkerPatch
  149.              * 它支持*或？模式。
  150.              */
  151.             pattern = ["classes*.dex",
  152.                        "assets/secondary-dex-?.jar"]
  153.             /**
  154.              * 必需，默认'[]'
  155.              * 警告，这是非常非常重要的，加载类不能随补丁改变。
  156.              * 因此，它们将从补丁程序中删除。
  157.              * 你必须把下面的类放到主要的dex。
  158.              * 简单地说，你应该添加自己的应用程序{@code tinker.sample.android.SampleApplication}
  159.              * 自己的tinkerLoader，和你使用的类
  160.              */
  161.             loader = [
  162.                     //use sample, let BaseBuildInfo unchangeable with tinker
  163.                     "tinker.sample.android.app.BaseBuildInfo"
  164.             ]
  165.         }
  167.         lib {
  168.             /**
  169.              * 可选，默认'[]'
  170.              * apk中的图书馆应该处理tinkerPatch
  171.              * 它支持*或？模式。
  172.              * 对于资源库，我们只是在补丁目录中恢复它们
  173.              * 你可以得到他们在TinkerLoadResult与Tinker
  174.              */
  175.             pattern = ["lib/*/*.so"]
  176.         }
  178.         res {
  179.             /**
  180.              * 可选，默认'[]'
  181.              * apk中的什么资源应该处理tinkerPatch
  182.              * 它支持*或？模式。
  183.              * 你必须包括你在这里的所有资源，
  184.              * 否则，他们不会重新包装在新的apk资源。
  185.              */
  186.             pattern = ["res/*", "assets/*", "resources.arsc", "AndroidManifest.xml"]
  188.             /**
  189.              *  可选，默认'[]'
  190.              *  资源文件排除模式，忽略添加，删除或修改资源更改
  191.              * *它支持*或？模式。
  192.              * *警告，我们只能使用文件没有relative与resources.arsc
  193.              */
  194.             ignoreChange = ["assets/sample_meta.txt"]
  196.             /**
  197.              *  默认100kb
  198.              * *对于修改资源，如果它大于'largeModSize'
  199.              * *我们想使用bsdiff算法来减少补丁文件的大小
  200.              */
  201.             largeModSize = 100
  202.         }
  204.         packageConfig {
  205.             /**
  206.              *可选，默认'TINKER_ID，TINKER_ID_VALUE'，'NEW_TINKER_ID，NEW_TINKER_ID_VALUE'
  207.              * 包元文件gen。路径是修补程序文件中的assets / package_meta.txt
  208.              * 你可以在您自己的PackageCheck方法中使用securityCheck.getPackageProperties（）
  209.              * 或TinkerLoadResult.getPackageConfigByName
  210.              * 我们将从旧的apk清单为您自动获取TINKER_ID，
  211.              * 其他配置文件（如下面的patchMessage）不是必需的
  212.              */
  213.             configField("patchMessage", "tinker is sample to use")
  214.             /**
  215.              *只是一个例子，你可以使用如sdkVersion，品牌，渠道...
  216.              * 你可以在SamplePatchListener中解析它。
  217.              * 然后你可以使用补丁条件！
  218.              */
  219.             configField("platform", "all")
  220.             /**
  221.              * 补丁版本通过packageConfig
  222.              */
  223.             configField("patchVersion", "1.0.2")
  224.         }
  225.         //或者您可以添加外部的配置文件，或从旧apk获取元值
  226.         //project.tinkerPatch.packageConfig.configField("test1", project.tinkerPatch.packageConfig.getMetaDataFromOldApk("Test"))
  227.         //project.tinkerPatch.packageConfig.configField("test2", "sample")
  229.         /**
  230.          * 如果你不使用zipArtifact或者path，我们只是使用7za来试试
  231.          */
  232.         sevenZip {
  233.             /**
  234.              * 可选，默认'7za'
  235.              * 7zip工件路径，它将使用正确的7za与您的平台
  236.              */
  237.             zipArtifact = "com.tencent.mm:SevenZip:1.1.10"
  238.             /**
  239.              * 可选，默认'7za'
  240.              * 你可以自己指定7za路径，它将覆盖zipArtifact值
  241.              */
  242. //        path = "/usr/local/bin/7za"
  243.         }
  244.     }
  246.     List<String> flavors = new ArrayList<>();
  247.     project.android.productFlavors.each { flavor ->
  248.         flavors.add(flavor.name)
  249.     }
  250.     boolean hasFlavors = flavors.size() > 0
  251.     def date = new Date().format("MMdd-HH-mm-ss")
  253.     /**
  254.      * bak apk and mapping
  255.      */
  256.     android.applicationVariants.all { variant ->
  257.         /**
  258.          * task type, you want to bak
  259.          */
  260.         def taskName = variant.name
  262.         tasks.all {
  263.             if ("assemble${taskName.capitalize()}".equalsIgnoreCase(it.name)) {
  265.                 it.doLast {
  266.                     copy {
  267.                         def fileNamePrefix = "${project.name}-${variant.baseName}"
  268.                         def newFileNamePrefix = hasFlavors ? "${fileNamePrefix}" : "${fileNamePrefix}-${date}"
  270.                         def destPath = hasFlavors ? file("${bakPath}/${project.name}-${date}/${variant.flavorName}") : bakPath
  272.                         if (variant.metaClass.hasProperty(variant, 'packageApplicationProvider')) {
  273.                             def packageAndroidArtifact = variant.packageApplicationProvider.get()
  274.                             if (packageAndroidArtifact != null) {
  275.                                 try {
  276.                                     from new File(packageAndroidArtifact.outputDirectory.getAsFile().get(), variant.outputs.first().apkData.outputFileName)
  277.                                 } catch (Exception e) {
  278.                                     from new File(packageAndroidArtifact.outputDirectory, variant.outputs.first().apkData.outputFileName)
  279.                                 }
  280.                             } else {
  281.                                 from variant.outputs.first().mainOutputFile.outputFile
  282.                             }
  283.                         } else {
  284.                             from variant.outputs.first().outputFile
  285.                         }
  287.                         into destPath
  288.                         rename { String fileName ->
  289.                             fileName.replace("${fileNamePrefix}.apk", "${newFileNamePrefix}.apk")
  290.                         }
  292.                         from "${buildDir}/outputs/mapping/${variant.dirName}/mapping.txt"
  293.                         into destPath
  294.                         rename { String fileName ->
  295.                             fileName.replace("mapping.txt", "${newFileNamePrefix}-mapping.txt")
  296.                         }
  298.                         from "${buildDir}/intermediates/symbols/${variant.dirName}/R.txt"
  299.                         from "${buildDir}/intermediates/symbol_list/${variant.dirName}/R.txt"
  300.                         from "${buildDir}/intermediates/runtime_symbol_list/${variant.dirName}/R.txt"
  301.                         into destPath
  302.                         rename { String fileName ->
  303.                             fileName.replace("R.txt", "${newFileNamePrefix}-R.txt")
  304.                         }
  305.                     }
  306.                 }
  307.             }
  308.         }
  309.     }
  310.     project.afterEvaluate {
  311.         //sample use for build all flavor for one time
  312.         if (hasFlavors) {
  313.             task(tinkerPatchAllFlavorRelease) {
  314.                 group = 'tinker'
  315.                 def originOldPath = getTinkerBuildFlavorDirectory()
  316.                 for (String flavor : flavors) {
  317.                     def tinkerTask = tasks.getByName("tinkerPatch${flavor.capitalize()}Release")
  318.                     dependsOn tinkerTask
  319.                     def preAssembleTask = tasks.getByName("process${flavor.capitalize()}ReleaseManifest")
  320.                     preAssembleTask.doFirst {
  321.                         String flavorName = preAssembleTask.name.substring(7, 8).toLowerCase() + preAssembleTask.name.substring(8, preAssembleTask.name.length() - 15)
  322.                         project.tinkerPatch.oldApk = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-release.apk"
  323.                         project.tinkerPatch.buildConfig.applyMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-release-mapping.txt"
  324.                         project.tinkerPatch.buildConfig.applyResourceMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-release-R.txt"
  326.                     }
  328.                 }
  329.             }
  331.             task(tinkerPatchAllFlavorDebug) {
  332.                 group = 'tinker'
  333.                 def originOldPath = getTinkerBuildFlavorDirectory()
  334.                 for (String flavor : flavors) {
  335.                     def tinkerTask = tasks.getByName("tinkerPatch${flavor.capitalize()}Debug")
  336.                     dependsOn tinkerTask
  337.                     def preAssembleTask = tasks.getByName("process${flavor.capitalize()}DebugManifest")
  338.                     preAssembleTask.doFirst {
  339.                         String flavorName = preAssembleTask.name.substring(7, 8).toLowerCase() + preAssembleTask.name.substring(8, preAssembleTask.name.length() - 13)
  340.                         project.tinkerPatch.oldApk = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-debug.apk"
  341.                         project.tinkerPatch.buildConfig.applyMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-debug-mapping.txt"
  342.                         project.tinkerPatch.buildConfig.applyResourceMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-debug-R.txt"
  343.                     }
  345.                 }
  346.             }
  347.         }
  348.     }
  349. }

一定要通过 gradle的命令打基础包
image.png
在bakApk生成三个文件:

  1. apk 文件就是基准包
  2. mapping.txt 是开启混淆后，混淆的映射文件
  3. R.txt 是资源的映射文件

image.png

  1. 生成差异apk文件的Gradle脚本

修改tinker执行脚本

  1.     tinkerOldApkPath = "${bakPath}/app-release-0906-17-18-35.apk"
  2.     tinkerApplyMappingPath = "${bakPath}/app-release-0906-18-18-35-mapping.txt"
  3.     tinkerApplyResourcePath = "${bakPath}/app-release-0906-18-18-35-R.txt"

执行tinkerPatchRelease/tinkerPatchDebug一个是打debug环境的patch，一个是打release环境的patch
image.png
生成如下的patch包：一般都是用patch_signed_7zip.apk,将这个文件上传服务器即可
image.png

Tinker的原理

  • 服务端：补丁包管理
  • 用户端：执行热修复
  • 开发端：生成补丁包

热修复要解决的问题：

  1. 补丁包是什么
  2. 如何生成补丁包？
  3. 开启混淆后会有什么影响？
  4. 手动生成的补丁包对比自动生成补丁包(Gradle自动生成的补丁包)
  5. 什么时候执行热修复？
  6. 怎么执行热修复使用补丁包？
  7. Android版本兼容的问题

    ClassLoader的机制

    双亲委托机制：某个类加载器在加载类时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务或者没有父类加载器时，才自己加载。

    1. 避免重复加载，当父加载器已经加载了该类的时候，就没有必要子ClassLoader再加载一次
    2. 安全性考虑，防止核心库的API被随意篡改

image.png
常用的ClassLoader的类图：
image.png

PathClassLoader ：加载App应用程序的类。 DexClassLoader: 没有安装到app中的代码，一般通过DexClassLoader去加载外部的类,加载外部的dex文件或者apk文件。(DexClassLoader如果发现是apk文件就会解压，解压之后就会把dex文件都会加载一遍)

例如：java.lang.String.class 系统的类，假如在插件包dex中进行加载，首先会通过:
检测父类有没有加载而不是检测DexClassLoader有没有加载：

DexClassLoader -> BaseDexClassLoader -> ClassLoader (先看ClassLoader有没有加载，肯定是已经加载的String是系统的类，不会再次重新加载)

ClassLoader加载过了，将结果返回ClassLoader -> BaseDexClassLoader -> DexClassLoader

再比如：MyClass.class 在内存中没有被加载的，丢给DexClassLoader，而后检测BaseDexClassLoader有没有被加载，没有检测ClassLoader有没有加载，如果都没有丢给BootClassLoader进行加载，加载完之后在依次返回给DexClassLoader.

热修复就是基于：pathList:DexPathList 不同版本的源码有 makeXXElements 进行反射，如下dex的加载流程

image.png

热修复的流程

  1. 获取到当前应用的PathClassLoader
  2. 反射获取到DexPathList属性对象pathList
  3. 反射修改pathList的dexElements数组
    1. 把补丁包patch.dex转化为Element[] (patch)
    2. 获得pathList的dexElements属性(old)
    3. patch + dexElements合并，并反射赋值给pathList的dexElements,这样patch.dex就会在dexElements的第一个，首先会先加载Key.class,如果遇到旧的Class2.dex中的Key.class就不会在加载了，这样新的class就替换了旧的class。

image.png