我为何暂时放弃了React Native

同步自个人博客

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

背景

咱们首页迁移RN主要有如下几个缘由

1. 公司的架构组对RN的支持度比较高，有一个比较完整的解决方案，包括打包体积的优化，封装了redux和路由，方便业务方的开发

2. 咱们的前端代码优化力度不够，bundle的体积很大，首屏会比较慢，在Android的WebView里尤为明显，并且代码时间也比较久，想要拆包优化也须要大量的时间去测试，而后以前作的RN项目几乎是秒开，给了咱们很大的诱惑力。

3. 前端的框架是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住一些场景等等，而不是由于它很火选择它。