Bugly Android热更新总结篇

• 资源

这三个东西Tinker都是完全支持的，类和资源在实际开发中最有可能需要通过热更新来修复，而So库场景可能会相对少一点。

那么Tinker不支持你修改什么？

• AndroidManifest文件

• 新增四大组件

关于Tinker的能力，大家可以移步看下Tinker Wiki。

开发者为什么这么热衷于热更新？

---

热更新解决了开发者的一个痛点就是程序逻辑出现bug了，导致业务逻辑混乱或者导致程序崩溃，但这些bug不会导致App完全不可用，如果通过发版来解决问题的话周期又太长，那么通过热更新下发补丁能够帮助产品及时修复问题，而不需要等待版本更新。这也是为什么国内稍微大一点的产品都有自己的热更新方案，通过避免频繁发版来保证产品的稳定性。不过热更新能力对于一些开发者来说可能更多是一种事后救火的行为，对产品质量不够信心，才想着有这么一个东西就算出现问题也不需要太大的担心，有这样想法的同学是非常危险的。

开发者最好不要依赖热更新来保证产品质量，建议在产品需要紧急修复问题的情况下才应该考虑热更新。

Bugly跟Tinker有什么不同？

---

有很多开发者问，Bugly跟Tinker有什么不同，它们之间有什么关系呢？这里正式把这个问题说清楚：

Tinker是一个开源框架，而Bugly热更新SDK是基于这套框架进行的能力封装，提供接口方便开发者能够快速实现热更新能力。而Tinker只是开源了客户端代码，并没有开源补丁管理后台，我们Bugly也提供了补丁管理后台，所以开发者只需要接入我们SDK就无需自己搭建补丁管理后台。所以说Bugly提供的是一整套热更新能力解决方案，而不仅仅是客户端的能力。

这里还需要提及一些技术实现，Tinker补丁的生成是通过Gradle插件来实现的，整个打补丁的过程对开发者来说是透明的，Bugly在Tinker插件基础上开发了TinkerSupport插件来生成符合我们平台规则的补丁，主要就是在TinkerPatch插件生成的补丁插入一个配置文件-YAPATCH.MF。

如何在实际开发中使用热更新能力

---

很多开发者在使用热更新能力的时候，测试的时候还好，但一到正式使用但时候就有点蒙圈，这也是对热更新不够理解的一种表现，下面笔者针对一些需要开发者去理解的概念。

基线版本vs补丁版本

在使用插件打补丁的时候需要我们去指定基线版本，那么我们需要怎么去理解这个概念呢，简单来说就是你已经上线版本的apk，而这个apk能打补丁的前提是已经集成过热更新SDK。

无论使用什么热更新方案，都是基于某一个版本进行打补丁，而被打补丁的版本就是基线版本。

在使用tinker-support插件进行打补丁我们需要配置以下几个内容：

• 基线版本Apk

• 基线版本的mapping文件

• 基线版本的R文件

最佳实践就是你通过持续集成系统发版前编译生成以上几个文件，然后对代码版本库进行打tag，如果线上版本出现问题就通过tag来拉取代码，将持续集成系统生成对基线版本对应的三个文件下载放到工程的某个目录，然后对插件进行参数配置，接着就是通过插件进行打补丁包，最后将补丁包上传到Bugly平台进行下发。

补丁版本就没啥好说的，就是针对基线版本修复问题到版本，它也是需要走编译打包流程的，因为基线版本需要跟补丁版本进行比较才能差分生成补丁包。

关于tinker-support打补丁配置如下图所示：

tinkerId到底有什么作用，每次打补丁都需要修改？

前面说到打补丁的时候会在补丁基础上插入一个配置文件— YAPATCH.MF，里面有两个配置参数：

From：表示你是基于某个基线版本打的补丁包

To: 表示的是你当前打补丁的版本

为什么要这么设计？ 主要是因为每次编译会通过插件在AndroidManifest文件插入TINKER_ID的meta-data，用来唯一标识当前版本，所以你每次打包的时候都是需要修改tinkerId，我们在运行基线版本时会将tinkerId与当前版本号进行一个关联一起上报到我们后台，打补丁的时候插件会读取基线版本的tinkerId写到From字段，当前版本写到To字段，上传补丁到管理后台的时候前端会通过解析配置文件读取From字段，然后去后台匹配tinkerId对应的版本，这也是为什么如果你上传补丁From字段的tinkerId没有上报过联网就匹配不到具体版本。

为什么需要重启补丁才能够生效？

有很多同学对Tinker热更新方案为什么要重启两次才能够生效，这里需要大家先了解一下Tinker关于合成补丁的原理，Tinker采用的是ClassLoader方案，这种方案具有具有较高的稳定性和兼容性。我们先看下面这张图：

可以看到补丁包是基线版本和补丁版本差分的结果，但合成补丁包的时候跟Qzone方案是有区别的，tinker是采用全量合成dex来实现热更新，前者会将补丁包单独做成一个dex插入到dexElements最前面，而后者是全量合成dex插入到dexElements最前面。熟悉ClassLoader机制的同学应该知道，加载类的时候会去遍历dex文件，并且会优先加载排在前面的dex，应用启动的时候加载的就是已经修复问题的dex文件。这里有个潜规则就是：

如果已经被加载过的类，就不会重复被加载，这就解释了为什么要杀掉进程重启app才能够修复问题。

那为什么Bugly热更新有时候需要重启两次才能够生效呢，因为这里涉及到请求策略，下载补丁的过程，如果应用启动的时候没有检测到补丁存在就不会下载补丁，我们并不会实时去检测补丁的存在，所以只有重启的时候才会去检查补丁，检查到补丁就会下载并自动合成，合成补丁之后还需要再次重启才会生效，这也就是为什么需要重启两次。

渠道包怎么使用热更新？

多渠道热更新是一个坑，很多同学在接入Bugly热更新之后就会问，怎么支持到多渠道？这里有两种情况，一种是通过productFlavors来打渠道包，这种方式没有办法做到一个补丁修复所有渠道，因为它打出来的包dex的crc值都是不一致的，所以只能一个渠道一个补丁对应修复问题，但这个对于需要打很多渠道包的app开发者来说就是一个灾难，因为需要忍受漫长的打包过程还要逐个上传补丁包。这个肯定是不符合我们的需求的，所以我们推荐通过多渠道工具来打渠道包，具体参考笔者之前的一篇文章：Bugly多渠道热更新解决方案。

这里要提一点，要基于tinker插件打出来的基准包来打渠道。

加固包怎么使用热更新？

加固可以说是一个巨坑，tinker 1.7.5版本及以前是支持回退QZone方案来支持加固，但因为市面上没有统一的加固方案会引入一些更加严重的问题，所以后面tinker官方将加固支持去掉了，但很多产品都接入了加固，如果用了加固就不能再使用热更新，所以后面Tinker重新对市面上的加固方案重新做了兼容，但需要在1.7.8版本以上才支持。

实际应用你需要做以下操作：

1. 开启加固模式，将isProtectedApp设置为true

2. 将打出来的基线版本上传到加固平台进行加固并重签名

3. 打补丁是基于非加固的基线版本进行的

用一张图解释Bugly热更新

---

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门**

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！