Android 热修复 Tinker接入及源码浅析

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在做处理，如果你没了解过，可以看下：

• Android 如何编写基于编译时注解的项目

通过该文会对一个编译时注解的运行流程和基本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读写权限。

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

<meta-data

android:name=“TINKER_ID”

android:value=“tinker_id_6235657” />

//…

到此API相关的就结束了，剩下的就是考虑patch如何生成。

patch生成

tinker提供了patch生成的工具，源码见：tinker-patch-cli收录**

ild/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修改为与本例一致：

大致的文件结构如下：

可以在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。

（2）gradle接入

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是如何编译时生成的

---

从注释和命名上看：

//可选，用于生成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方法：

@Override

public 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至目标目录

五、源码分析

---

（1）加载patch

加载的代码实际上在生成的Application中调用的，其父类为TinkerApplication，在其attachBaseContext中辗转会调用到loadTinker()方法，在该方法内部，反射调用了TinkerLoader的tryLoad方法。

@Override

public 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 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 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 additionalClassPathEntries,

File optimizedDirectory)

throws IllegalArgumentException, IllegalAccessException,

NoSuchFieldException, InvocationTargetException, NoSuchMethodException, IOException {

Field pathListField = ShareReflectUtil.findField(loader, “pathList”);

Object dexPathList = pathListField.get(loader);

ArrayList suppressedExceptions = new ArrayList();

ShareReflectUtil.expandFieldArray(dexPathList, “dexElements”, makeDexElements(dexPathList,

new ArrayList(additionalClassPathEntries), optimizedDirectory,

suppressedExceptions));

if (suppressedExceptions.size() > 0) {

for (IOException e : suppressedExceptions) {

Log.w(TAG, “Exception in makeDexElement”, e);

throw e;

}

}

}

}

1. 找到PathClassLoader（BaseDexClassLoader）对象中的pathList对象

2. 根据pathList对象找到其中的makeDexElements方法，传入patch相关的对应的实参，返回Element[]对象

3. 拿到pathList对象中原本的dexElements方法

4. 步骤2与步骤3中的Element[]数组进行合并，将patch相关的dex放在数组的前面

5. 最后将合并后的数组，设置给pathList

这里其实和Qzone的提出的方案基本是一致的。如果你以前未了解过Qzone的方案，可以参考此文：

• Android 热补丁动态修复框架小结

（2）合成patch

这里的入口为：

TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(),

Environment.getExternalStorageDirectory().getAbsolutePath() + “/patch_signed.apk”);

上述代码会调用DefaultPatchListener中的onPatchReceived方法:

DefaultPatchListener

@Override

public 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陌生，可以查看此文：[Android IntentService完全解析 当Service遇到Handler

](https://docs.qq.com/doc/DSkNLaERkbnFoS0ZF)。

@Override

protected 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。如果有兴趣，可以参考此文：关于 Android 进程保活，你所需要知道的一切。

下面继续回到tryPatch方法：

UpgradePatch

@Override

public boolean tryPatch(Context context, String tempPatchPath, PatchResult patchResult) {

最后，面试前该准备哪些资源复习？

其实客户端开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。

这里再分享一下我面试期间的复习路线：（以下体系的复习资料是我从各路大佬收集整理好的）

《Android开发七大模块核心知识笔记》

《960全网最全Android开发笔记》

《379页Android开发面试宝典》

历时半年，我们整理了这份市面上最全面的安卓面试题解析大全
包含了腾讯、百度、小米、阿里、乐视、美团、58、猎豹、360、新浪、搜狐等一线互联网公司面试被问到的题目。熟悉本文中列出的知识点会大大增加通过前两轮技术面试的几率。

《507页Android开发相关源码解析》

只要是程序员，不管是Java还是Android，如果不去阅读源码，只看API文档，那就只是停留于皮毛，这对我们知识体系的建立和完备以及实战技术的提升都是不利的。

真正最能锻炼能力的便是直接去阅读源码，不仅限于阅读各大系统源码，还包括各种优秀的开源库。

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。如果有兴趣，可以参考此文：关于 Android 进程保活，你所需要知道的一切。

下面继续回到tryPatch方法：

UpgradePatch

@Override

public boolean tryPatch(Context context, String tempPatchPath, PatchResult patchResult) {

最后，面试前该准备哪些资源复习？

其实客户端开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。

这里再分享一下我面试期间的复习路线：（以下体系的复习资料是我从各路大佬收集整理好的）

《Android开发七大模块核心知识笔记》

[外链图片转存中…(img-ZcWX3neL-1723372498349)]

[外链图片转存中…(img-tPJRahSF-1723372498350)]

《960全网最全Android开发笔记》

[外链图片转存中…(img-Mg0uVhbm-1723372498350)]

《379页Android开发面试宝典》

历时半年，我们整理了这份市面上最全面的安卓面试题解析大全
包含了腾讯、百度、小米、阿里、乐视、美团、58、猎豹、360、新浪、搜狐等一线互联网公司面试被问到的题目。熟悉本文中列出的知识点会大大增加通过前两轮技术面试的几率。

《507页Android开发相关源码解析》

只要是程序员，不管是Java还是Android，如果不去阅读源码，只看API文档，那就只是停留于皮毛，这对我们知识体系的建立和完备以及实战技术的提升都是不利的。

真正最能锻炼能力的便是直接去阅读源码，不仅限于阅读各大系统源码，还包括各种优秀的开源库。

本文已被CODING开源项目：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》收录