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

  • 4种React Native热更新方案的比较已关闭评论
  • 189 次浏览
  • A+
所属分类:Web前端
摘要

转载自:https://www.jianshu.com/p/8f423e52b5d1最近刚完成了一个产品的热更新功能,颇有感慨。趁着有点时间写点东西,希望能对其他开发者有点帮助吧。

转载自: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疼的。你能保障服务的稳健性么?能承受多少用户同时更新?。。。。。然后吧啦吧啦说了一大推,说得我直冒冷汗,感觉老大是感觉我太闲了。~_^
后来想想,确实如此。先不说网上那些开源项目是否经历过商业产品的验证,以及代码质量如何,就算这些都没问题,也不是放到服务器上跑起来就行的。保障服务的稳健和大访问量的可靠性也是一项专门的运维技术活。
开发成本、时间成本、运维成本、带宽成本,这些都是开发中需要重点考虑的。
有些人(比如我们老大)下意识就能想到这些,而有些人(比如我)却不一定。或许这就是一个开发人员成熟度的体现吧。