RN的启动机制是将JS代码打包成为一资源文件，App启动时加载这个bundle从而启动RN项目。基于这一点，可以利用对这个bundle文件的下载合成从而实现热更新。
这样做的优点有：
1.JS方面的代码可以跳过发布版本来进行更新，如果应用结构足够好，理论上界面相关的改变都可以通过热更新实现。
2.部分bug可以实时修复。
3.没有热修复原生部分代码，不会被苹果审核拒掉。（关于苹果为什么会拒部分热更新库请自行了解）
缺点是：
1.原生部分改动及bug还需要依赖于发布版本。
下面是干货：
首先，因为会存在不得不发布appstore版本的情况，所以我们可以利用这一点来减少版本管理的难度。每次发布appstore版本进行原生更新时，我们称之为大版本更新，此时工程内保留的jsbundle为当前最新版本。当需要热更新时，我们称之为小版本更新，通过增量包与大版本更新时留在本地的jsbundle合成为最新版本。
然后，我们需要明确版本管理机制。因为客户端的当前版本是未知的，我们需要知道客户端应该下载哪一个版本的包来更新到最新版本。这里有两种做法：
1.根据客户端的版本请求服务端，服务端通过比对当前客户端版本及最新版本生成增量包来让客户端下载，客户端利用本地版本和下载的增量包合成最新版本。
2.客户端保留两个bundle文件，一个bundle是当前加载使用的版本，一个bundle是用于合成最新版的最低版本。服务端保留基于最低版本生成的增量包，客户端只需要请求最新版本的增量包即可与最低版本合成最新版。
这两种做法的优缺点也很明显，我们举例说明。假设我们当前大版本下有10个小版本。
第一种做法服务端会生成 10基于9的增量包，10基于8的增量包，10-7，10-6....10-1,9-8，9-7...2-1个增量包。
而第二种做法会生成10-1，9-1，8-1...2-1个增量包。
虽然当发布了最新版本之后，之前不需要的可以删除（即第一种做法服务端保留的版本只会是10-9到10-1共9个版本），但是就消耗的资源来说第一种要比第二种多出生成时的消耗及删除时的消耗。
而第二种做法客户端是基于最低版本来更新的，所以第二种客户端包会大一点，服务端保留的增量包体积会大一点。
明确了版本管理的原则后，根据业务需要我们就可以完成这个生成patch包及下载合成最新版本的流程了。
在进行热更新有一点需要额外注意的地方，增量包合成之后时候，可能会出现bug导致直接闪退，此时需要增加一项版本回滚的功能保证客户端的正常使用。思路是利用JS正常启动时通知原生部分，来确认是否正常启动，未正常启动的时候进行回滚即可。
PS：涉及到图片等资源的热更新，可以利用更改引入路径来解决，这里不再详述。（曾经面试时傻得说的太过详细，后来发现人家是来我这里套方案的- -累觉不爱）
如果能帮助到你，麻烦点个赞哦！
下面与正文无关，纯粹一点个人感想，不感兴趣可跳过。。。
在iOS这一行干了三年之后，发现技术处于一个不上不下的地方。一方面，接触过的东西非常多，可以说常见App能用到的东西都使用过，但是问题也是接触了太多东西，对技术不够深入，很多东西都停留在使用阶段，知其然不知其所以然。甚至很多都是模糊的，不够明确的。另一方面，近段时间找工作的经历也让我认清自身技术上没有特别亮眼的长处。
重新开始更新博客即有利于知识结构的重建，也有利于对知识进行一个总结回顾。希望能坚持下来，找准不足，发展特长。也愿所有与我一样处于瓶颈期的道友们同样能找到自身发展的道路并能坚持走下去。
PS：如果有公司缺iOS的，对我感兴趣的帮忙内推一下哦，万分感谢！联系方式微信 woaicccrrrfff
