2. apply插件（这里可以只配置apply plugin: 'com.tencent.bugly.tinker-support'）
3. 集成SDK
- 集成远程SDK仓库
- 重新自定义Application、ApplicationLike
- AndroidManifest配置
- 混淆配置
- 测试验证
- 打基准包安装并上报联网（注：填写唯一的tinkerId）
- 对基准包的bug修复（可以是Java代码变更，资源的变更）
- 修改基准包路径、填写补丁包tinkerId、mapping文件路径、resId文件路径
- 执行tinkerPatchRelease打Release版本补丁包
- 选择app/build/outputs/patch目录下的补丁包并上传（注：不要选择tinkerPatch目录下的补丁包，不然上传会有问题）
- 编辑下发补丁规则，点击立即下发
- 重启基准包，请求补丁策略（SDK会自动下载补丁并合成）
- 再次重启基准包，检验补丁应用结果
以上是应用补丁的流程，有同学可能会问，如果我想撤回怎么办？这里先解释下我们补丁的几种状态：
- 下发中
- 生效中、下发停止
- 撤回中
下发中：表示你上传一个补丁后，点击立即下发之后的状态，表示后台正在下发补丁策略，补丁包对应的基线版本是可以收到对应的策略的。
生效中、下发停止：表示你已经下发过这个补丁，但因为你上传了新补丁，这个补丁下发会被停止，要注意一个目标版本只运行下发一个补丁。
撤回中：表示你不再下发这个补丁，这个操作是不可逆的，点击撤回，基线版本将不会再收到这个补丁策略。
以上就是Bugly热更新SDK的集成方式一些说明啦，如果还有疑问直接找Bugly-kirito咨询。
一些大家比较关注的问题
Q：Bugly热更新会收费么？
A：大家可以放心，我们热更新服务目前是完全免费的。
Q：之前使用Tinker，怎么切换过来使用Bugly？
A： 你只需在dependencies中配置一句代码：
compile “com.tencent.bugly:crashreport_upgrade:1.2.0”注释掉以前的配置：
// 可选，用于生成application类
//provided(‘com.tencent.tinker:tinker-android-anno:1.7.5’)
// tinker的核心库
// compile(‘com.tencent.tinker:tinker-android-lib:1.7.5’)插件配置不需要更改，只需要加上我们Bugly额外的tinker-support插件即可：
// tinker gradle插件
classpath (‘com.tencent.tinker:tinker-patch-gradle-plugin:1.7.5’)
// tinkersupport插件
classpath “com.tencent.bugly:tinker-support:1.0.1”这里建议您不要随便更改插件版本，避免因为插件的更新导致您无法正常生成我们需要的补丁包。
Q：如果我配置了升级策略，又配置了补丁策略，会是怎样的效果？
A：升级策略优先级会高于补丁策略，后台会优先下发升级策略。毕竟你都要升级了，热更新只是帮助你修复bug而已。
Q：我只想使用热更新，不想使用升级？
A：热更新是包含在升级SDK里面的，你可以不配置任何升级策略，只需按照热更新文档集成即可。
Q：是否支持加固模式？
A：tinker是支持加固模式的，但需要你回退到Qzone方案
，将usePreGeneratedPatchDex设置为true。
但要注意Tinker官方的提示：
是否提前生成dex，而非合成的方式。这套方案即回退成Qzone的方案，对于需要使用加固或者多flavor打包(建议使用其他方式生成渠道包)的用户可使用。但是这套方案需要插桩，会造成Dalvik下性能损耗以及Art补丁包可能过大的问题，务必谨慎使用。另外一方面，这种方案在Android N之后可能会产生问题，建议过滤N之后的用户。
Q：是否支持打多Flavor的patch包
A：支持的。你需要配置productFlavor（示例）：
productFlavors {这套方案需要插桩，会造成Dalvik下性能损耗以及Art补丁包可能过大的问题，务必谨慎使用。另外一方面，这种方案在Android N之后可能会产生问题，建议过滤N之后的用户。
Q：是否支持打多Flavor的patch包
A：支持的。你需要配置productFlavor（示例）：
productFlavors {
