Android探索之旅（第二十三篇）Android中集成Tinker热修复及所碰到的坑

实现热修复的原理这里就不再多说，当然理解原理也是很重要的，便于今后解决线上出现的问题更加轻松，这里作者只介绍接入Tinker中碰到的坑。接入的步骤这里给出Bugly Android热更新官方文档，只要按照以上文档来相信集成Tinker非常容易，而且我高度认为Bugly的文档非常棒，强于Tinker，这是我在之前使用时感悟。

为什么我要用Bugly的热更新，而不直接用Tinker呢？

最近这两天一直在研究腾讯的bugly热更新，bugly团队是基于微信的Tinker热更新方案进行的进一步封装，意在简化程序员的集成难度，于此同时还有应用升级，错误日志统计功能，比起直接接入Tinker更加方便，相信直接集成过微信Tinker的童鞋肯定深有体会！

完整接入流程（之前集成Tinker太心急，没有认真看文档，实际上关键性错误就犯在下面这几条）

• 打基准包安装并上报联网（注：填写唯一的tinkerId）
• 对基准包的bug修复（可以是Java代码变更，资源的变更）
• 修改基准包路径、修改补丁包tinkerId、mapping文件路径（如果开启了混淆需要配置）、resId文件路径
• 执行buildTinkerPatchRelease打Release版本补丁包
• 选择app/build/outputs/patch目录下的补丁包并上传（注：不要选择tinkerPatch目录下的补丁包，不然上传会有问题）
• 编辑下发补丁规则，点击立即下发
• 杀死进程并重启基准包，请求补丁策略（SDK会自动下载补丁并合成）
• 再次重启基准包，检验补丁应用结果
• 查看页面，查看激活数据的变化

1. 有很多童鞋在集成bugly的时候肯定或多或少都遇到过千辛万苦打好的patch补丁文件最后在上传至Bugly平台的时候却提示出错，如下图：

• 检察Bugly初始化的时候appID是否是本补丁想下发的应用
  

• 检察执行补丁任务是否为buildTinkerPatchRelease任务
  

• 检察要上传的补丁包是否为app/build/outputs/patch目录下的补丁包（注：不要选择apk目录中tinkerPatch目录下的补丁包，不然上传会有问题）
  

• 检察应用是否启动过，因为只有应用启动，对应在Application中Bugly的初始化工作才会开始。

2. 在接入Tinker的时候碰到的问题

经过反复检查之后才发现这个小细节

相信细心的你一定发现其中的猫腻对，是的，我们需要把tinker插件的位置放在app目录下，而不是src目录下。

紧接着就会看到安装失败的提示,在生成新的项目中还有很容易碰到该问题

出现这个问题的原因还是因为自己没按照文档规范来，可能一时匆忙，实际上按照文档规范一步步来是不会出现以上这种问题

总结

Tinker在我的项目实施的过程中暂时没有遇到不能解决的问题，目前Tinker在项目中主要还是用来修复bug使用，还没有作为new feature（新功能）发布使用，不过这样的热更效率和稳定性，作为new feature使用也是可以的，自从使用了Tinker后目前还没有遇到以前使用Andfix遇到的一些crash的问题，上了Tinker以后最大的好处就是每次发版后再也不用担心出问题后需要赶急忙慌的修bug去市场上架，再期待着用户点击更新了。

附上他人的Demo供大家学习参考