转载

我为什么暂时放弃了React Native

同步自我的博客

去年三月份，以及十一月份，我分别做了两个 React Native (下称 RN )的项目，一个是一个很简单的充值页面，发上线以后就基本不维护了，暂且不表；另一个是把我们客户端首页的技术方案由 Hybrid 迁移到了 RN ，跟进并维护了几个版本以后，又决定切换回了 Hybrid 的方案，以下记录一下我这段时间的心路历程以及我对 RN 的看法。

背景

我们首页迁移 RN 主要有以下几个原因

公司的架构组对 RN 的支持度比较高，有一个比较完整的解决方案，包括打包体积的优化，封装了 redux 和路由，方便业务方的开发
我们的前端代码优化力度不够， bundle 的体积很大，首屏会比较慢，在 Android 的 WebView 里尤其明显，而且代码时间也比较久，想要拆包优化也需要大量的时间去测试，然后之前做的 RN 项目几乎是秒开，给了我们很大的诱惑力。
前端的框架是 React ，前期调研了一下觉得切换的成本很低，这是我们最终决定迁移 RN 的原因，也是我们预估的最失败的地方，遇到的问题我在之前的博客里有提到过。

就像我之前的博客所说，我花了大概20天的时间做了这次迁移，其实真正估时的时候并没有这么久，主要是在开发上踩了一些坑，项目最终上线后的效果也很棒，首屏的渲染时间快了很多，尤其是 Android ，就当我们为此庆祝并且准备继续迁移的时候，问题慢慢展现出来了。

问题

主要的矛盾在于要维护两个工程。

咱们的首页既要服务于 Touch 端，又要服务于客户端，之前的客户端是 Hybrid 方案，矛盾并不突出，只需要在我的前端代码里对客户端做一些特殊处理即可，但是迁移 RN 以后我们就需要维护两套代码了。就像我之前说的，我们过于乐观的觉得，从 React 的代码到 RN 其实并不需要做过多的转换，甚至考虑着自己写一套转换的脚本，实现无缝对接，现实却是来了当头一棒。

比如，css无法复用, Android 下的 overflow:visible 就是不可用的，比如不支持百分比布局，比如不支持 fix ，导致我们在两边的切图还是不能使用一套方案。

又比如：加大了需求开发的成本和时间，比如PM有一个需求，单做前端可能2pd，算上 RN 可能就是3pd，对于一个创业团队会拖慢自己的进度，而且只能找有Mac的同学来做这个需求 = =。

就不说调试难，以及开发一些需求的时候需要请教客户端的同学是否支持然后去找对应的方案了。而如果是 Hybrid 的方案，只需要 web 和 native 讨论好接口，分别开发即可。

最终，在维护了几个版本的 RN 后，我又毅然的将方案改回了 Hybrid

我的看法

这是一次失败的尝试，却不是一次无用的尝试，在我看来， React Native 是一项非常棒的技术，我们不需要针对客户端开发两套代码，而且整体体验是优于 Hybrid 的。但是我还是觉得采用这项技术之前大家要考虑清楚，我个人觉得，对于大公司的大团队，业务需求不是特别紧的团队，都很适合采用这一项技术，对于我们反而是不太合适了。

经过这件事我对技术选型也有一些思考。技术选型时，应该选择根据自己的团队，自己的需求，花费很多时间调研以后再去决定，而不是选择一些火的方案。比如我们之前移动端选择使用 React ，就是觉得以后还是要做自己的客户端，用了 React 以后切换 RN 会是一件很小成本的事，结果现在还是采用的 Hybrid 方案。现在又因为 React 包体积很大，不得不对项目再做一些优化。

希望大家在选择 RN 时，也考虑清楚，我是否对 Web 的需求很低，我是否有很强的跨平台需求，我的技术人员是否可以hold住一些场景等等，而不是因为它很火选择它。

原文 https://segmentfault.com/a/1190000008401645

正文到此结束