方案一：JAR 替换
步骤
从服务端下载 jar -> 通过反射，加载jar -> 创建相关对象并且操作之。
优缺点
优点：
- 无兼容问题
缺点：
-
反射消耗性能；
-
jar 包如果体积大，整个下载就很不友好；
-
确定改动的代码范围繁琐，维护麻烦。
方案一改进：子 JAR 替换
步骤
针对 jar 包体积大的情况，我们可以考虑对 sdk 项目进行拆包（拆module），分成小的 jar 包和主包
主包负责反射加载，如果需要热修，下发子 jar 即可，比较轻量。
优缺点
优点：
- 只下发子包，轻量
缺点：
-
比较适合主包变动小的情况；
-
主包和子包耦合性强；
-
还是需要用到反射。
方案二：插件化
步骤
将SDK分包，宿主包仅提供 API 和加载核心实现的插件包，插件包就可以热更了。
优缺点
优点：
- 灵活
缺点：
-
对主项目工程的依赖太大，往往一些基本配置需要依赖于主工程的项目源码；
-
使用接入成本高，配置麻烦，而 SDK 的业务接入方需要的是快速接入；
-
插件化框架可能会对系统原生代码的运行造成不可预估的影响；
-
不得不依赖很多不需要的插件化框架功能。
方案三：业务方热更
走投无路之下，我想起，诶！很多 app 热更方案不是说支持 lib 热更吗！那先作为一个保底方案吧。
步骤
通过业务方 app 热更 lib 包。
优缺点
优点：
- 热更权把控在业务方手中，对业务方透明
缺点：
-
lib 包太大时，下载还是很耗流量的
-
diff 算法无法计算新旧 lib 的差异，只能整个替换掉
-
步骤相当繁琐，如下图：
业务方会杀了你的！
方案四：改造现有 APP 热修复方案
1. 那在选择热修复方案时考虑点有哪些？
1. 热更项目的需求
-
只需要简单的方法级别 Bug 修复？
-
需要资源及 so 库的修复？
-
需要 Native 的修复？
-
对平台兼容性要求及成功率要求？
-
是否需要对补丁包进行管理？
-
公司资源是否支持商业付费？
2. 学习及使用成本
-
集成难度和复杂度
-
代码侵入性
-
调试维护
3. 选择框架的关注点
-
尽量大厂
-
性能过关
-
有专人维护
-
热度高，开源社区活跃
2. 总结出需要热更的 SDK 特点
-
主要是代码热更，无so库、资源更新需求；
-
实时性要求高，因为一旦出问题，对业务方的影响极大；
-
兼容性要求高，你无法预料到业务方的活跃用户都有啥机型。
3. 那我们赶紧来看下，现有的 APP 热修复方案都有哪些？
3.1 综合优化的产物 —— Sophix（弃）
Sophix 功能完善、开发简单透明，可惜没开源，无法改造。
3.2 底层替换方案（弃）
底层替换方案不可避免地存在兼容问题，弃之。
3.3 类加载方案 —— Tinker
优点：
-
用户多
-
更新时间新，相比之下，其他有在Github上开源的框架，star数都是7000以下，上次更新时间都在1年前，甚至2年前。
缺点：
-
dex合成占用ROM较大
-
不够实时
-
需要改造Application，业务方有感知。（也可以参考 InstantRun 做到不修改 Application 达到替换 Application 的效果，但该方案大量 hook 系统 api，不够稳定，大概有 1/1w 的概率会出现替换失败，所以Tinker最终还是没有使用InstantRun的方式）
还有两个问题，留给大家去思考：
- 会不会影响业务方加固？
尾声
最后，我再重复一次，如果你想成为一个优秀的 Android 开发人员，请集中精力，对基础和重要的事情做深度研究。
对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。 整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。
这里，笔者分享一份从架构哲学的层面来剖析的视频及资料分享给大家梳理了多年的架构经验，筹备近6个月最新录制的，相信这份视频能给你带来不一样的启发、收获。
Android进阶学习资料库
一共十个专题，包括了Android进阶所有学习资料，Android进阶视频，Flutter，java基础，kotlin，NDK模块，计算机网络，数据结构与算法，微信小程序，面试题解析，framework源码！
-
自行下载直达领取链接：点击这里前往GitHub
了Android进阶所有学习资料，Android进阶视频，Flutter，java基础，kotlin，NDK模块，计算机网络，数据结构与算法，微信小程序，面试题解析，framework源码！
[外链图片转存中…(img-4qJim9s7-1647445917535)]
-
自行下载直达领取链接：点击这里前往GitHub
