提起版本更新，是每个app和开发者最熟悉的东西，但是频繁的更新会让用户反感，但是不更新的话在发现了bug怎么办呢？在用户体验和版本稳定性的碰撞下，热修复出来了，热修复就不用多说了，常见热修复分为冷启动修复和实时修复，这里不多介绍，感兴趣的朋友可以了解各大平台的热修复原理，这次由于公司有用到Bugly的热修复，所以记录下来。
1.引入依赖及签名配置
首先在我们app目录下的build.gradle文件中引入：
implementation 'com.tencent.bugly:crashreport_upgrade:latest.release'
implementation 'com.tencent.bugly:nativecrashreport:latest.release'
implementation 'com.tencent.tinker:tinker-android-lib:1.9.9'
这里的latest.release代表最新版本的意思，然后我们在Project的build.gradle文件中引入
classpath "com.tencent.bugly:tinker-support:1.1.5"
回到我们app目录下的build.gradle文件，在顶部加入
apply from: 'tinker-support.gradle'
然后配置好签名，为什么要配置签名呢？因为在我们等下自动打包的时候会用上，在app目录下的build.gradle文件中android节点下加入
signingConfigs {
release {
keyAlias '签名文件别名'
keyPassword '密码'
storeFile file('签名文件路径')
storePassword '签名文件密码'
}
}
配置好后，我们还要在 buildTypes 的节点中设置：
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release//在这里设置配置的签名
}
}
以上我们就完成了自动打包的签名配置，接下来接入和初始化，需要在清单文件中先配置：
provider文件主要是为了支持andorid N以上访问共享路径的文件，如果你的项目中有其他第三方库也配置了，可以继承FileProvider类来解决合并冲突的问题：
然后我们需要在res目录新建xml文件夹，创建provider_paths.xml文件如下：
这样我们就完事具备，只欠东风，在Application中初始化：
Beta.autoInit = true;
Beta.canShowUpgradeActs.add(MainActivity.class);
Beta.installTinker();
Bugly.init(this, "appId", true);
Beta类作为Bugly的初始化扩展，通过Beta类可以修改升级的检测时机，界面元素以及自定义升级行为，详情可以查看官方文档Beat拓展类,在这里呢，我就不多说了，由于自动检测更新我觉得有延迟，所以可以在主页面调用Beta.checkUpgrade(isManual ,isSilence )；方法来检测更新
参数1：isManual 用户手动点击检查，非用户点击操作请传false
参数2：isSilence 是否显示弹窗等交互，[true:没有弹窗和toast] [false:有弹窗或toast]
然后打包上传一气呵成，这里提交后要稍等几分钟才能生效，然后关掉app，打开就会有更新提示了。
更新完成后，到我们的重头戏热更了。
2.热更新配置
首先我们要在app的目录下创建tinker-support.gradle，然后拷入代码：
apply plugin: 'com.tencent.bugly.tinker-support'
def bakPath = file("${buildDir}/bakApk/")
/**
* 此处填写每次构建生成的基准包目录
*/
def baseApkDir = "app-0523-11-17-07"
/**
* 对于插件各参数的详细解析请参考
*/
tinkerSupport {
// 开启tinker-support插件，默认值true
enable = true
// 指定归档目录，默认值当前module的子目录tinker
autoBackupApkDir = "${bakPath}"
// 是否启用覆盖tinkerPatch配置功能，默认值false
// 开启后tinkerPatch配置不生效，即无需添加tinkerPatch
overrideTinkerPatchConfiguration = true
// 编译补丁包时，必需指定基线版本的apk，默认值为空
// 如果为空，则表示不是进行补丁包的编译
// @{link tinkerPatch.oldApk }
baseApk = "${bakPath}/${baseApkDir}/app-release.apk"
// 对应tinker插件applyMapping
baseApkProguardMapping = "${bakPath}/${baseApkDir}/app-release-mapping.txt"
// 对应tinker插件applyResourceMapping
baseApkResourceMapping = "${bakPath}/${baseApkDir}/app-release-R.txt"
// 构建基准包和补丁包都要指定不同的tinkerId，并且必须保证唯一性
tinkerId = "0.0.39.2-pasth"
//tinkerId = "0.0.39.1-app"
// 构建多渠道补丁时使用
// buildAllFlavorsDir = "${bakPath}/${baseApkDir}"
// 是否启用加固模式，默认为false.(tinker-spport 1.0.7起支持）
// isProtectedApp = true
// 是否开启反射Application模式
enableProxyApplication = true
// 是否支持新增非export的Activity（注意：设置为true才能修改AndroidManifest文件）
supportHotplugComponent = true
}
/**
* 一般来说,我们无需对下面的参数做任何的修改
* 对于各参数的详细介绍请参考:
* https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97
*/
tinkerPatch {
//oldApk ="${bakPath}/${appName}/app-release.apk"
ignoreWarning = false
useSign = true
dex {
dexMode = "jar"
pattern = ["classes*.dex"]
loader = []
}
lib {
pattern = ["lib/*/*.so"]
}
res {
pattern = ["res/*", "r/*", "assets/*", "resources.arsc", "AndroidManifest.xml"]
ignoreChange = []
largeModSize = 100
}
packageConfig {
}
sevenZip {
zipArtifact = "com.tencent.mm:SevenZip:1.1.10"
// path = "/usr/local/bin/7za"
}
buildConfig {
keepDexApply = false
//tinkerId = "1.0.1-base"
//applyMapping = "${bakPath}/${appName}/app-release-mapping.txt" // 可选，设置mapping文件，建议保持旧apk的proguard混淆方式
//applyResourceMapping = "${bakPath}/${appName}/app-release-R.txt" // 可选，设置R.txt文件，通过旧apk文件保持ResId的分配
}
}
大多数配置不用修改，在这里注意
baseApkDir
tinkerId
baseApkProguardMapping
这三个参数，第一个呢暂时不用管，是打补丁包时的基准包目录，第二个时标识符，可以随意明明，但是注意唯一性，第三个参数如果项目没有启用混淆，可以屏蔽掉，由于我们配置好了签名，先修改tinkerId的参数，随意命名（最好用版本号加项目名），然后打开anroid studio的Gradle菜单：
如图打基准包的箭头所指，双击，等待控制台日志如下图：
出现BUILE SUCCESSFUL字样，表示编译成功，然后我们在以下目录可以看到生成的基准包：
基准包有了，我们先修改一下app的内容，修改完后，将tinker-support.gradle文件中的baseApkDir修改为编译生成的基准包的目录名，如上图的app-0523-16-28-51，然后记得修改tinkerId，之后点击Gradle菜单中的buildTinkerPatchRelease，等待日志出现BUILD SUCCESSFUL的字样，在如下路径中找到补丁包：
箭头所指就是我们的补丁包，打工告成，记住，上传补丁包前请先安装基准包并打开，否则会报找不到版本的错误。
等待十几分钟后，重新打开app会发现修复成功。
总结
热更新的配置不是很麻烦，熟悉了以后就很快了，关键是Bugly生效时间慢，一开始配置成功见没生效还以为没弄好，这是个坑，希望能帮到配置Bugly热更的大家。