APP 热修复都懂了,你会 SDK 热修复吗?最全方案在这里!(1)

可是我都拍胸脯向老大夸口了,焉有退缩的道理?!

加上万一以后手抖,出了个什么大 bug 或者兼容问题,我的职业生涯不就要终结了!?

我滴乖乖,保命要紧!还是赶紧做个保底方案吧。

一、背景和目的


我们想实现的效果很简单,如下场景三:

二、技术方案


先说明下,方案没有最好,只有最合适。虽然我最终选定了方案四,但如果各位小伙伴的团队有资源、有其他方案的经验、SDK的热更需求更丰富,可以自行选择其他方案。

方案一:JAR 替换

步骤

从服务端下载 jar -> 通过反射,加载jar -> 创建相关对象并且操作之。

方案参考:

Android SDK热修复机制简析以实现

优缺点

优点:

  1. 无兼容问题

缺点:

  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全局热更新方案(全网唯一)
  • 扩展:

写在最后

今天关于面试的分享就到这里,还是那句话,有些东西你不仅要懂,而且要能够很好地表达出来,能够让面试官认可你的理解,例如Handler机制,这个是面试必问之题。有些晦涩的点,或许它只活在面试当中,实际工作当中你压根不会用到它,但是你要知道它是什么东西。

最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司的面试题,把技术点整理成了视频和PDF(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节,由于篇幅有限,这里以图片的形式给大家展示一部分。

还有 高级架构技术进阶脑图、Android开发面试专题资料,高级进阶架构资料 帮助大家学习提升进阶,也节省大家在网上搜索资料的时间来学习,也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档,BAT大厂面试真题解析】

【算法合集】

【延伸Android必备知识点】

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》点击传送门,即可获取!
节**,由于篇幅有限,这里以图片的形式给大家展示一部分。

还有 高级架构技术进阶脑图、Android开发面试专题资料,高级进阶架构资料 帮助大家学习提升进阶,也节省大家在网上搜索资料的时间来学习,也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档,BAT大厂面试真题解析】

[外链图片转存中…(img-3y5mQ6C8-1714792868603)]

【算法合集】

[外链图片转存中…(img-ojjyVeYM-1714792868604)]

【延伸Android必备知识点】

[外链图片转存中…(img-tI0vnd47-1714792868605)]

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》点击传送门,即可获取!

  • 25
    点赞
  • 27
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值