转载

RN开发笔记-背景和思考

同步自我的 github

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

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

项目背景

为什么要做这次改造

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

项目设计问题，只有一个 js 包，100K+，在一些较为低端的安卓机里首屏很慢，即使我们用了离线包的机制，有的安卓机任然需要2-3s花在js的 parse 上
native 开发人手不够，我们只有两个客户端的开发人员，如果用原生开发的话没法进行快速的开发迭代，而且我们的迭代很快，客户端的发版频率已经完全不能满足我们的需求了
体验很不 native ，有一部分性能问题，安卓下的 iScroll ，动画等等会丢帧；对于原生的掌控很弱，比如我想设置状态栏，获取一些设备信息，都是需要 native 的同事做一些桥的开发，导致两边都有开发成本

为什么选择RN

之前有过一个简单的 RN 项目的经验，总的来说我觉得不论是开发效率还是体验上都是可以接受的（当然这次的项目比上次的复杂许多，证明我还是太天真了）。
客户端人员不够，没法进行快速的开发迭代。
之前 hybrid 的是用 react + redux 进行的开发，组内讨论过觉得客户复用大部分的逻辑，可以尽可能快的迭代上线。
公司的平台部门已经帮我们做好了打包构建的流程并且已经做了一些优化，会将 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 ，包括优化。

后续我会根据我这次遇到的一些问题做一些深入的分析与梳理

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

正文到此结束