RN开发笔记-背景和思考

同步自个人github

最近花了大概一个月的时间，对咱们以前的一个hybrid项目进行了React Native(如下简称RN)改造，中间踩了很多坑，也学习到了很多RN的知识，准备写几篇文章记录一下这一段时间的收获，由于公司有专门的平台组作RN的打包构建以及优化，我会更侧重于业务来聊一下。

这是第一篇，想大概讲一下背景以及项目中遇到的一些问题，后续会就一些问题作深刻的分析。

项目背景

为何要作此次改造

咱们是公司内部的一个创业项目，以前的移动端页面已经稳定运行了一段时间了，最近在作本身的app，原本是先用的hybrid的方案，运行了一段时间后发现了一些问题

1. 项目设计问题，只有一个js包，100K+，在一些较为低端的安卓机里首屏很慢，即便咱们用了离线包的机制，有的安卓机任然须要2-3s花在js的parse上

2. native开发人手不够，咱们只有两个客户端的开发人员，若是用原生开发的话无法进行快速的开发迭代，并且咱们的迭代很快，客户端的发版频率已经彻底不能知足咱们的需求了

3. 体验很不native，有一部分性能问题，安卓下的iScroll，动画等等会丢帧；对于原生的掌控很弱，好比我想设置状态栏，获取一些设备信息，都是须要native的同事作一些桥的开发，致使两边都有开发成本

为何选择RN

1. 以前有过一个简单的RN项目的经验，总的来讲我以为不管是开发效率仍是体验上都是能够接受的（固然此次的项目比上次的复杂许多，证实我仍是太天真了）。

2. 客户端人员不够，无法进行快速的开发迭代。

3. 以前hybrid的是用react+redux进行的开发，组内讨论过以为客户复用大部分的逻辑，能够尽量快的迭代上线。

4. 公司的平台部门已经帮咱们作好了打包构建的流程而且已经作了一些优化，会将RN的代码统一打到客户端里，咱们只须要关注本身的业务，并且他们在RN的基础上进行了二次封装，已经帮咱们规避了一部分iOS和Android的差别性。

所以，咱们决定先用RN来先作首屏的改造，打算先看一下效果，后续再决定是否继续迁移

项目中遇到的问题

• 切图不是很习惯

RN实际上是用了一套cssLayout，虽然语法是css的而且对flex有很好的支持，可是不少属性还不支持，好比fix，好比overflow:visible在安卓下是不支持的(致使最后我真机测试的时候花了两天返工从新设计)，不支持百分比等等，其实有的时候很难用css那一套的思路去切图，最终花在切图上的时间并无想象的那么少。

• 自定义输入框和键盘的设计

由于咱们涉及到一些自定义的键盘，好比车牌的省份，好比限制一些键的录入，在RN上咱们但愿沿用这一套方案，可是由于事件系统，手势系统，一些DOM中的api在RN中没有相似的实现，致使咱们无法复用以前的那一套方案，这个我会单独写一遍去分析。

• debug困难

遇到过几回报错是在native的代码里，致使我很难定位问题，由于我没有原生开发的经验，有时候只能麻烦客户端的同窗帮忙去看是哪里的问题

• 原生组件的使用问题

好比有的组件只有Android有，有的组件只有iOS有，而后平台的同事以前又没有开发，致使我不得不给另一个平台开发一个组件；又好比像Picker，Android和iOS彻底是两种调用方式，我又不得不为了抹平个人调用差别而作一次上层的封装

总结

前先后后我大概作了20天，总的来讲没有以前想象的顺利。咱们团队内部也就RN作了一些思考。
首先，咱们以为对于开发一个native的应用，RN确实是一个很棒的方案，相比于native和hybrid来讲都有不小的优点，对于大公司来讲，若是有专门的团队来作RN的打包构建以及优化，各个部门只须要考虑本身的业务的话，很是值得尝试一下。可是对于小的团队，创业团队，若是人手不是很充足的话，我不是很建议去用RN进行开发，hybrid反而是一个最优解，毕竟RN目前还不是一个稳定的方案，须要有人去跟进RN，包括优化。

后续我会根据我此次遇到的一些问题作一些深刻的分析与梳理