4种React Native热更新方案的比较-Toy模板网

这篇具有很好参考价值的文章主要介绍了4种React Native热更新方案的比较。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

转载自：https://www.jianshu.com/p/8f423e52b5d1

最近刚完成了一个产品的热更新功能，颇有感慨。趁着有点时间写点东西，希望能对其他开发者有点帮助吧。

为什么需要做热更新？

这个问题不是本文的重点，但既然这篇文章是关于 React Native 热更新的，就大概说一下吧。

快速发布新版本。
或许有人会说，如果不计算打包和提交的工作，一个新包提交到应用商店后，通常在两三天之内就会通过审核，慢的话通常不会超过一个星期，快的话24小时内就能通过审核，有必要去纠结这点时间么？
其实不然。很多开发者应该都遇到过类似这样的情形：一个新包刚提交或发布没多久，就发现了某个地方需要修改，或许仅仅是个样式，又或者是个小Bug。是不是很头痛？如果有了热更新，那就好解决了。
做 A/B 面的产品。
因为某些原因（或许是某些不可描述的原因），需要让应用商店的审核人员与真实的用户看到的是不一样的内容，以便快速通过审核。

综上，这就是为什么绝大部分React Native App都会做热更新的主要原因。

4种React Native热更新方案的比较

好吧，前面废话了一下。现在进入正题。
在React Native项目中，常见的有四种做热更新的方案。下面一一对其进行介绍和比较。

1. CodePush

官网：https://appcenter.ms/
由鼎鼎大名的微软出品，是App Center的一部分。如果不考虑稳定性，这绝对是不二选择。但是非常可惜，因某些不可言表的原因，其服务在中国非常不稳定。
有人说不选择CodePush的原因是因为它的服务器在海外，速度慢。其实慢与快不是考虑的重点（除非慢到极端），一个React Native App的Js bound通常只有几M，能达到20M的都是罕见的了，在如今的网络环境下，这根本就不是个事。所以考虑的重点其实是稳定性。
经本人在公司的网络环境下测试，发布新版不成功的概率超过10%，更新不成功（无法连接、中断、以及不知是何原因）的概率超过20%。这还仅仅是在一个网络环境下和某个时间段内，如果放大到全国和所有时间段，那这个概率应该还会提高。
因此，如果你的产品是面向海外用户的，那么就选择CodePush，不用考虑其它。如果是面向国内用户的，那么不建议使用。

2. 中文社区的CodePush

官网：https://code-push.cn/
由CodePush中文社区出品。其实就是微软的CodePush，将服务器改在了国内，然后在用法上进行了一些封装和简化。我们公司现在用的是这个。之所以选择它，是因为我最早测试的是微软的CodePush，然后顺理成章就选择了这个。
其特点是使用简单。虽然仍然是微软的CodePush，但经过二次封装，其用法要比微软的CodePush更简单直接。当然，之所以有这种感觉，也有可能是我在折腾微软的CodePush时是刚开始接触，而在使用中文社区的CodePush时已经有了前面的积累，所以就感觉上更简单了。

3. Pushy

官网：https://pushy.reactnative.cn/
由React Native中文社区出品。正是由于微软的CodePush在中国不稳定，所以促使中文社区的开发者们开发出了一些类似功能的服务。Pushy应该算是其中的佼佼者。
经在公司的网络环境下测试，其服务还算比较稳健。
从用法上来看，其实也能看到一些CodePush的影子。当然，热更新功能最核心的无外乎就是上传与更新，也不可能玩出朵花来。
对比中文社区的两个产品，感觉中文社区的CodePush是在微软的CodePush上做减法，而Pushy是在微软的CodePush上做加法。

4. 自建CodePush服务器

先说结论：自己玩玩可以，但如果要用在公司的产品上，强烈不建议。
还是由于微软的CodePush在中国不稳定，所以网上有些文章介绍用一些开源项目搭建自己的CodePush服务器。讲真，我还真试过。下面说说本人的一个小故事。
本人从参考网上的各种文章、自己动手尝试、到最后选定方案并实现在公司的产品中，共用了约三天时间，所有这些工作由本人一个人完成，并得到了项目老大的表扬。后来我想，既然可以用开源项目自己搭CodePush服务器，干嘛不自己搭一个呢？于是在网上搜各种文章并照着做，感觉差不多了后，兴冲冲地跑去找老大，本以为会再次得到表扬，没想到老大说：自己公司的业务都忙不过来，干嘛要花时间搞这个？干这种事的都是闲得Q疼的。你能保障服务的稳健性么？能承受多少用户同时更新？。。。。。然后吧啦吧啦说了一大推，说得我直冒冷汗，感觉老大是感觉我太闲了。~_^
后来想想，确实如此。先不说网上那些开源项目是否经历过商业产品的验证，以及代码质量如何，就算这些都没问题，也不是放到服务器上跑起来就行的。保障服务的稳健和大访问量的可靠性也是一项专门的运维技术活。
开发成本、时间成本、运维成本、带宽成本，这些都是开发中需要重点考虑的。
有些人（比如我们老大）下意识就能想到这些，而有些人（比如我）却不一定。或许这就是一个开发人员成熟度的体现吧。

文章来源地址https://www.toymoban.com/news/detail-621236.html

到了这里，关于4种React Native热更新方案的比较的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！