React Native实践有感

Thoughtworks思特沃克中国

于 2021-11-24 19:00:58 发布

阅读量1.5k

点赞数

分类专栏：技术雷达文章标签：技术雷达前端

本文链接：https://blog.csdn.net/toafu/article/details/121522290

版权

本文分享了React Native（RN）的实践经验和注意事项，包括技术选型、依赖库升级维护、跨平台局限性、性能优化及开发建议。RN虽有性能差距，但丰富的生态和社区资源使其在特定场景下仍具优势。在项目实践中，应适时升级第三方库，处理好原生平台依赖，关注性能优化，合理使用类型检查工具，以提升开发效率和应用质量。

摘要由CSDN通过智能技术生成

React Native（简称RN）是Facebook于2015年开源的移动端跨平台开发框架。RN从开源以来已经有6个年头了，有着十分丰富的社区资源和生态，时至今日依然有很多移动端项目都使用RN来开发。本文主要通过以往的项目实践来谈谈在选择RN开发app可能需要注意的一些点，也算是自己的一个踩坑经验总结。

1. 技术选型 - 是否该用RN？

跨平台开发框架都是有局限性的，这一点RN也不例外，RN本身还是要使用原生API来实现UI的绘制，JS bridge的创建和与原生平台的通信都需要消耗资源，基于这样的前提，RN开发的应用相对于原生平台来说往往会占用更多的内存和CPU，因此而出现的卡顿、掉帧的概率也会更高，进而对用户体验造成较大的影响。

那么问题来了，RN真的很差、不适合工程实践吗？

这个问题就涉及到技术选型了，是否应该用RN？什么样的情况下适合使用RN作为首选开发技术？

我个人认为需要从以下几个方面考虑：

产品类型和市场定位

面向C端的产品一般最好还是使用原生开发技术，性能稳定性相对会更加可靠一些，尤其是这款产品的市场期望比较高，对用户和市场规模增长有比较大的期待时。性能更好、更加稳定可靠的技术应当是首选，这样会带来更好的用户体验。当然如果用户数量比较少，app应用场景比较单一的情况不太需要这样的考虑，比如功能并不复杂的工具类应用。
业务需要

很多app都使用原生与H5的Hybrid模式开发，但是H5的体验跟原生相比差距较大，RN的体验比H5就要好很多，而且RN还具有热更新的能力，这对于需要频繁更新内容的业务来说是一个不错的选择。比如像图书、漫画这种内容上新比较频繁或者UI排版更迭频繁的更适合用RN，像以音视频播放为主这种追求性能稳定的就不太合适了。
团队规模和开发周期

团队规模比较小，开发周期短的情况下尽量选择熟悉的技术栈，能够节省时间。
技术储备

这一点需要考虑到团队是否有相应的技术，比如如果团队没有Android或iOS原生开发的技术，都只有web前端开发，又需要做app，那么可以考虑RN，尤其是有React技术储备的情况。
后期维护成本

这一点一般来说考虑的优先级是最低的，开发团队可能很少会考虑维护的问题，因为交付之后项目谁维护、要不要维护都是个问题。作为跨平台开发框架来说，RN通常可能需要维护Android和iOS两端，尤其是app应用场景和功能比较复杂的情况下，与原生交互的部分就少不了，对于纯web前端开发来说是个不小的挑战，需要一个人负责两个平台的维护工作。总之，RN一个开发者维护的情况下，那么对开发者的要求是需要兼顾Android和iOS两个平台，这也是为什么说学了RN迟早安卓和iOS都要学🤣。如果是原生开发，可能需要两个人维护，一人一个平台，就会提高维护成本。

综上，RN到底适不适合在项目中实践，最好按实际情况考虑。我个人觉得RN还是不错的，性能表现由于先天性的架构设计问题与原生有差距是正常的，但是也没有差到无法用的地步，这一点不能人云亦云。

2. 依赖库的升级维护

RN项目中经常会用到很多第三方库，比如路由框架react-navigation、数据存储AsyncStorage、状态管理react-redux等等。在项目维护时我们可能会面临第三方库的升级带来的一系列问题、某些library没人维护了，但是我们出于某些原因还需要继续使用等等，针对这些情况谈谈我的理解。

第三方库适时升级

适时升级的意思就是第三方库有新版本的时候，在保持app稳定性、不引起regression问题的情况下尽可能的升级第三方库。在app的迭代中把第三方库的升级维护考虑进去是很有必要的，以我所在的项目为例：

我们项目中使用的react-navigation版本非常老旧了，还停留在v2版本，而最新的react-navigation实际已经到了v5版本，并且v5版本中对核心功能组件进行了拆分，意味着v5以后需要安装react-navigation的多个依赖包。react-navigation一直都是一个API变动非常大的router库，每一个大版本的迭代都可能导致原来的路由用法发生改变。对比老旧的v2版本来说，升级到新版本是更好的选择，功能和性能更强、路由灵活性更高，但是在我接手项目之前react-navigation一直都没升级过，直接升级到最新版本变动太大了，风险太高，容易引起功能上的bug。如果在之前的迭代中能把这块升级的工作考虑进去，随着每个迭代一起去做，改动会相对较小，就能平稳过渡到新版本。