react native 是用复杂的技术解决跨平台的问题（rn 比 android 或 ios 复杂），如果某个场景下使用 rn 新增复杂度的成本大于跨平台的收益，很难讲用 rn 是合适的选择；作为对比，flutter 则是用“简单”的技术解决跨平台的问题（flutter 等价于 android 或 ios），当然 flutter 自身和生态还不够成熟。跨端场景下暂时没有完美的技术，我们要做的是因地制宜，在业务实现域匹配合适的技术。

react 框架的意义

react 确实提升了 ui 开发的效率，认识到 react 提效的原因，来指导前台开发，更有意义：

• FP 范式实践：出发点是 fp 代替 oo 的观点，可以参考Out of the Tar Pit：其认为软件复杂度主要原因是 state，通过 FRP（functional relational programing）解决 state 的问题，react 是对这个观点的 FP 范式实践。个人对这个观点存疑，其可能适用前台开发，需要继续观察。

• 标准化：mvc、mvp、mvvm 等 mv*模式，由于存在贫血模型、充血模型，model 和 controller 的边界不清楚，模块粒度粗等，导致不同开发者使用 mv*模式实现的代码风格、逻辑“杂乱无章”。而 react 则通过框架更细粒度的标准化了程序的结构和关系，对应 state、props、render、redux，最终保证了业务代码实现的规整统一，大大减少了团队协同因为代码实现风格、逻辑、模式不一致产生的认知负荷，从而提升协作效率。我认为这是 react 团队说的 react 比 mv*框架 scale 好的原因。

react native 优缺点

优点

• 节约一端的研发成本：包括开发、测试、bugfix、运维

• react 框架开发效率较高

• 动态性

缺点

• 新增复杂度和协同成本。框架自身引入了新的复杂度，导致系统整体复杂度的增加；跨技术栈的协同成本和复杂度急剧升高，依赖高水平的研发人员解决引入的复杂度（比如抽象泄漏场景下的方案设计、bugfix，典型的案例是...more 组件，从方案设计到 bugfix、后期维护的复杂度都非常高，投入了非常大工作量，而纯 native 实现则不存在这些问题）。

• 协同成本：rn 和 native 的联调成本；rn 和 native 协作模式不标准、没有达到共识，出现一些灰色地带。比如 native 是否提供逻辑还是只提供能力，如果既要 native 提供能力，某些 case 下又提供逻辑，则会出现 react 和 native 的逻辑出现冲突（时序不一致、或者没有考虑到对方的逻辑）导致出现隐藏的 bug，这种 bug 需要协同定位，修复成本高。类似多线程同步，存在逻辑同步的问题。（典型案例是 native 播放器组件要不要提供状态恢复机制、要不要处理前后台切换，各有各的道理，没有判断标准和共识）

• 性能比原生差，且性能问题基本无解：性能提升最终是靠硬件的性能提升，但终端硬件与 pc 的硬件发展逻辑不一样，不能用 pc“web 替代原生”的经验套在无线终端。因为终端设备追求能耗比（电池限制）且单线程摩尔定律基本失效，设备的性能不会出现 pc 一样的快速提升。

总结

• rn 对比原生动态性好、性能差是显而易见的。

• 研发效率上 rn 不一定比原生高。因为 rn 虽然减少了一端的研发成本，但额外增加了整个工程的复杂度和协同成本（rn 不适合的场景）。

根据 rn 的以上特点分析，使用 rn 等跨平台框架的原则是因地制宜：根据产品、技术、组织特点选择合适的技术。另外，rn 的使用需要标准化（比如用 rn 替代原生要有明确的判断依据、native 只提供能力不提供逻辑）来高效的使用 rn 技术。

rn 的标准化

• 即 rn 的小程序化：rn 运行环境即 native 提供的能力标准化，关闭扩展能力，避免 rn 与 native 的协同成本。如果一个新场景 rn 需要 native 提供新的能力，则需要认真思考判断：该场景是否适合使用 rn，若适合，如果是 native 的能力不完善，那么 native 去完善能力来支撑 rn 的业务实现；否则使用原生开发可能是更好的选择。

一些思考

今天不管是后端还是前台，软件都在往通用性、扩展性方向发展，抽象过度，框架越来越重。如果技术的目标是解决一类问题，而不是简单精准的解决问题，那么必然会增加系统的整体复杂度。从这个角度讲，补齐原生开发的能力也许更有意义，业务标准框架 + kotlin multiplatform 也许是更好的组合。

btw，一家之言，欢迎留言指正、探讨。