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

Android 热修复 Tinker接入及源码浅析 一、概述 放了一个大长假，happy，先祝大家2017年笑口常开。 假期中一行代码没写，但是想着马上要上班了，赶紧写篇博客回顾下技能，于是便有了本文。 热修复这项技术，基本上已经成为项目比较重要的模块了。主要因为项目在上线之后，都难免会有各种问题，而依靠发版去修复问题，成本太高了。 现在热修复的技术基本上有阿里的AndFix、QZone的方案、美团提出的思想方案以及腾讯的Tinker等。 其中AndFix可能接入是最简单的一个（和Tinker命令行接入方式差不多），不过兼容性还是是有一定的问题的；QZone方案对性能会有一定的影响，且在Art模式下出现内存错乱的问题(其实这个问题我之前并不清楚，主要是tinker在MDCC上指出的);美团提出的思想方案主要是基于Instant Run的原理，目前尚未开源，不过这个方案我还是蛮喜欢的，主要是兼容性好。 这么看来，如果选择开源方案，tinker目前是最佳的选择，tinker的介绍有这么一句： Tinker已运行在微信的数亿Android设备上，那么为什么你不使用Tinker呢？ 好了，说了这么多，下面来看看tinker如何接入，以及tinker的大致的原理分析。希望通过本文可以实现帮助大家更好的接入tinker，以及去了解tinker的一个大致的原理。 二、接入Tinker 接入tinker目前给了两种方式，一种是基于命令行的方式，类似于AndFix的接入方式；一种就是gradle的方式。 考虑早期使用Andfix的app应该挺多的，以及很多人对gradle的相关配置还是觉得比较繁琐的，下面对两种方式都介绍下。 （1）命令行接入 接入之前我们先考虑下，接入的话，正常需要的前提（开启混淆的状态）。 对于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), } debug { debuggable true minifyEnabled true signingConfig signingConfigs.release proguardFiles getDefaultProguardFile(proguard-android.txt), } } } 文末会有demo的下载地址，可以直接参考build.grad