热更新方案调研

• 要做热更新项目的时候，必不可少的肯定是盘一下当前所有热更新项目，最后做一个合适的技术选型。
• 笔者在最初做相关对接的时候，调研的热更新方案其实也并不很多，有很多其他第三方的热更新项目也没有完全去盘过。主要是针对市面上几个大厂提出过的热更新方案做了一些简单的对比，就确定了技术选型。
• 在这里先和大家说明，我最终选择了美团的Robust方案，原因的话后面再和大家细说，我们先来聊一聊笔者调研过的热更新库。

选型要求：

选型目的：

• 我们说其实在吊炸天的三方库，也要有需求撑起来才有接入的意义。当时我们的项目需要热更新的主要目的主要是：
  • 能够稳定快速地覆盖线上问题，避免紧急发版这样的无奈做法
  • 能够对部分小需求进行一些优化补足
• 至于说需要用热更新来代替发版，这个操作其实是不太可取的，所以就不必做这种考虑了。

具体要求：

• 是否简单方法级别修复：
  • 目前从灰度发版角度、线上常见事故判断，基本属于简单方法级别Bug修复
• 是否涉及资源、so库：
  • 至少目前so库修复的情况很少，基本上用到so的情况都是第三方的so，价值意义不太大
  • 至于资源方面，其实新增资源的情况也相对较少，大部分情况可以通过代码代替（xml布局和shape基本都可以代码实现）
  • 图片可以使用网络下发代替
• 成功率要求：
  • 极高

方案罗列：

• 笔者主要调研了腾讯的Tinker、阿里的Sophix、美团的Robust三个方案，其他的就没有细盘了。

• 从上述层面来看，腾讯Tikder和阿里的Sophix都是按量收费的开源方案，有成熟的体系。不差钱的朋友可以直接用，肯定还能有稳定的技术支持。
• 尤其是值得注意的，阿里的Sophix，从技术文档上来看的话，方案是最为成熟的，而且基本是开箱即用，傻瓜操作。
• 但是鉴于笔者需要装13的程度，以及公司的money考虑，肯定不会选择前面两者
• 所以，最终我选择了Robust

Robust

• 其实Robust从原理上来说，是无侵入的方案设计，不需要Activity占坑，动态加载patch，不需要hook，兼容性、稳定性好，成功率也是最高的。
• 同时Robust还是开源免费，有什么问题，我们撸一撸源码看看能不能解决，多少能学到点东西不是。
• 好，说干就干。