APP-热修复都懂了那你会-SDK-热修复吗？最全的方案在这里！(1)，android高级面试framework

1. 反射消耗性能；
2. jar 包如果体积大，整个下载就很不友好；
3. 确定改动的代码范围繁琐，维护麻烦。

方案一改进：子 JAR 替换

步骤

针对 jar 包体积大的情况，我们可以考虑对 sdk 项目进行拆包（拆module），分成小的 jar 包和主包

主包负责反射加载，如果需要热修，下发子 jar 即可，比较轻量。

优缺点

优点：

1. 只下发子包，轻量

缺点：

1. 比较适合主包变动小的情况；
2. 主包和子包耦合性强；
3. 还是需要用到反射。

方案二：插件化

步骤

将SDK分包，宿主包仅提供 API 和加载核心实现的插件包，插件包就可以热更了。

优缺点

优点：

1. 灵活

缺点：

1. 对主项目工程的依赖太大，往往一些基本配置需要依赖于主工程的项目源码；
2. 使用接入成本高，配置麻烦，而 SDK 的业务接入方需要的是快速接入；
3. 插件化框架可能会对系统原生代码的运行造成不可预估的影响；
4. 不得不依赖很多不需要的插件化框架功能。

方案三：业务方热更

走投无路之下，我想起，诶！很多 app 热更方案不是说支持 lib 热更吗！那先作为一个保底方案吧。

步骤

通过业务方 app 热更 lib 包。

优缺点

优点：

1. 热更权把控在业务方手中，对业务方透明

缺点：

1. lib 包太大时，下载还是很耗流量的
2. diff 算法无法计算新旧 lib 的差异，只能整个替换掉
3. 步骤相当繁琐，如下图：

方案四：改造现有 APP 热修复方案

1. 那在选择热修复方案时考虑点有哪些？

1. 热更项目的需求

• 只需要简单的方法级别 Bug 修复？
• 需要资源及 so 库的修复？
• 需要 Native 的修复？
• 对平台兼容性要求及成功率要求？
• 是否需要对补丁包进行管理？
• 公司资源是否支持商业付费？

2. 学习及使用成本

• 集成难度和复杂度
• 代码侵入性
• 调试维护

3. 选择框架的关注点

• 尽量大厂
• 性能过关
• 有专人维护
• 热度高，开源社区活跃

2. 总结出需要热更的 SDK 特点

1. 主要是代码热更，无so库、资源更新需求；
2. 实时性要求高，因为一旦出问题，对业务方的影响极大；
3. 兼容性要求高，你无法预料到业务方的活跃用户都有啥机型。

3. 那我们赶紧来看下，现有的 APP 热修复方案都有哪些？

3.1 综合优化的产物 —— Sophix（弃）

Sophix 功能完善、开发简单透明，可惜没开源，无法改造。

3.2 底层替换方案（弃）

底层替换方案不可避免地存在兼容问题，弃之。

3.3 类加载方案 —— Tinker

优点：

1. 用户多
2. 更新时间新，相比之下，其他有在Github上开源的框架，star数都是7000以下，上次更新时间都在1年前，甚至2年前。

缺点：

1. dex合成占用ROM较大
2. 不够实时
3. 需要改造Application，业务方有感知。（也可以参考 InstantRun 做到不修改 Application 达到替换 Application 的效果，但该方案大量 hook 系统 api，不够稳定，大概有 1/1w 的概率会出现替换失败，所以Tinker最终还是没有使用InstantRun的方式）

还有两个问题，留给大家去思考：

1. 会不会影响业务方加固？
2. 和业务方是否冲突？

• 方案参考：
  基于Tinker的SDK全局热更新方案（全网唯一）
• 扩展：
  InstantRun 如何动态替换 Application，总结起来就两步：

1. 打包时替换 Application 标签，插入BootstrapApplication
2. 运行时 hook 系统api，将 BootstrapApplication 换回 MyApplication

3.4 插桩 —— 美团 Robust

Robust 的原理可以简单描述为：

1. 打基础包时插桩，在每个方法前插入一段 if(changeQuickRedirect==null)-else 的逻辑；
2. 加载补丁时，从补丁包中读取要替换的类及具体替换的方法实现，新建 ClassLoader 加载补丁 dex，当目标方法被执行时，此时 changeQuickRedirect != null，方法逻辑流程被改变，而替换掉之前的旧逻辑，达到 fix 的目的。

优点：

1. 兼容性最优，兼容加固
2. 实时生效
3. 粒度细，支持方法级别的修复
4. 高稳定性，修复成功率高达99.9%

缺点：

1. 在编译阶段插件侵入了产品代码，对运行效率、方法数、包体积还是产生了一些副作用。（支持指定某些class无需插入）
2. so和资源的替换目前暂未实现
3. 无法新增变量
4. 没有补丁管理和安全校验，需要开发者自行实现

思考：

1. 和其他的插桩插件混用是否有冲突？

三、实现

就在我美滋滋地接入 Robust 时，问题来了！

Robust 需要是 Application 才能插桩和打补丁，要用在 SDK 上，还是需要一轮改造的。

如何改造？我将在下篇博文中详解，同时将推出封装好的库，让 SDK 开发者只需 5 分钟即可让自己的 SDK 拥有热修复的能力，敬请期待。

四、除了热更技术本身，我们还应该关心的

当然，我们的焦点并不局限在技术实现上，还有很多值得我们去考虑的：

我们怎么对分发进行控制？对监控数据进行统计？如果补丁引起了崩溃，我们怎么第一时间补救？
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

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

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

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

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

《960全网最全Android开发笔记》

《379页Android开发面试宝典》

《507页Android开发相关源码解析》

因为文件太多，全部展示会影响篇幅，暂时就先列举这些部分截图

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

开发相关源码解析》**

[外链图片转存中…(img-RgsvwOMu-1712451044464)]

因为文件太多，全部展示会影响篇幅，暂时就先列举这些部分截图

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！