搭建React Native热更新平台的详细过程.docxVIP

第

搭建React?Native热更新平台的详细过程

目录一，什么是热更新二，热更新方案三，热更新原理四，CDN热更新方案五，纯CDN方案的弊端六，线上方案七、整体方案梳理八，总结

一，什么是热更新

所谓热更新，也叫做动态更新，一种类似Web的更新方式。相对于App的发版更新而言，热更新能及时的修复线上存在的问题，大幅的提升业务迭代效率。我们都知道，互联网业务讲究兵贵神速，如果业务能够通过热更新来快速发版和迭代，这就相当于在产品和用户之间搭建了一座能够随时通行的桥梁，代替了原来好几周才能有一次迭代的问题。

那么，热更新和发版更新有什么不同呢？为什么热更新比发版更新快这么多呢？下面是这两种更新方式的原理对比图。

发版更新，指的是你把ReactNativeApp，当作AndroidApp和iOSApp，按照Android、iOS上架流程，通过各自的应用商店进行更新。通常每个NativeApp都会有一个自己的上架节奏，可能是两周，也可能是4周。此外，从提交应用商店到审核通过，也需要等上几天时间。甚至，即便新版本上架了，用户更新到最新版本也需要一个过程，可能需要一个月的时间，新版本才能覆盖到90%的用户。

所以说，如果你的ReactNativeApp选择发版更新，就会受到发版节奏、审核耗时和版本覆盖耗时的影响，这些都会导致业务迭代速度变慢。

不过，ReactNative的热更新就可以绕过应用商店直接进行更新。只要你的是集成热更新功能的ReactNativeApp，在应用商店上架过一次之后，后续你的业务都可以走你自己的热更新流程，再也不用依赖应用商店发版。这样你的业务就能随时上线，随时更新了。

二，热更新方案

虽然官方没有提供标准的热更新方案，不过能够支持常见热更新方案有pushy、CodePush、Expo和自研。

不过，由于国内网络环境的原因，访问国外的云服务速度比较慢，所以我不太推荐直接使用CodePush和Expo。Codepush是微软AppCenter的服务之一，它底层用的是微软自家的Azure云服务；Expo使用的是亚马逊的AWS和GoogleCloud云服务。

不过，大家也可以基于CodePush或Expo自行搭建热更新服务。如果你嫌自己搭建太麻烦，你也可以看看ReactNative中文网提供的Pushy热更新方案。它使用的是国内的阿里云服务，且有比前两者更省流量的差量更新方案，应该是国内目前市面上唯一可以直接使用的开源热更新方案了。

三，热更新原理

说到自研热更新平台，如果你没有接触过，可能会认为很难，但事实上并非如此。其实，自研热更新平台的难度主要体现在如何大规模应用上，还有到达率上。对于规模小的应用来说，搭建一个自研热更新平台本身并不是很难。总的来说，一个自研热更新平台，主要包括这两个部分：

打包服务：BundleServer；静态资源服务：StaticServer。

所谓的打包服务，是将ReactNative项目中的所有JavaScript代码打包成一个Bundle文件的服务。而所谓的静态资源服务，是将Bundle文件分发给客户端的服务；当客户端拿到Bundle代码后，执行加载Bundle文件就能渲染ReactNative页面了。

其实，这和我们本地的npmstart的流程是一样的。即我们在本地通过npmstart启动的Metro服务时，Metro服务就同时具备了打包和静态资源下发两种功能，再配合框架默认的代码加载功能就完成了热更新。

也就是说，找台服务器把ReactNative代码放上去，然后运行npmstart命令，然后在客户端配置对应的ip和端口号，并把相关的调试开关给关了，接着访问服务器就能把ReactNative页面渲染出来。

当然，这个最简单的热更新流程是不能跑在线上的，毕竟npmstart的本意是用于调试的，它的首次加载耗时太长，扛不住高并发，而且服务可用性也是问题。

四，CDN热更新方案

不过，使用npmstart的热更新方案不太靠谱，那有没有靠谱点的热更新方案呢？有，那接下来我们看另一种比较简单的热更新方案：CDN热更新方案。

在npmstart方案中，MetorServer提供了代码打包和Bundle下发的功能。而在CDN方案中，代码打包是通过react-nativebundle命令提供的，Bundl