Airbnb 最近在 Medium 上发布了一系列文章详细描述了 Airbnb 与 React Native 从选择到放弃的整个心路历程。
对于字多不看的同学，可以简单看一下我下面的小结。
当初为什么选择 React Native
有限的开发团队满足不了日益增长的业务需求
对 React Native 的期望
快速开发
质量有保证
一次编写，多平台共享
提升开发体验
我们所怀念的
跨平台，实际上有 95% 以上的共享代码率。
统一的 DSL。根据平台也做具体的差异化实现。
React 是个好东西。组件化，简单的生命周期,声明式
开发迭代速度（热更新 hot-reloading）
我们在 RN 生态基础设施上的投资。
性能，在绝大部分页面上 RN 都表现得很流畅。（有性能问题？ shouldComponentUpdate, removeClippedSubviews, Redux 了解一下。）
Redux 是个好东西。也是个好冗长的东西。
与 Native 的桥接，可以方便的封装已有的 Native 库。
RN 的动画库不错。
JS/React 的开源生态。
与 Web 平台共享代码。
让我们沮丧的
论成熟度，稳定性，RN 比 不上iOS 和 Android 原生。
由于 RN 的 Bug，有时我们必须维护自己的一个 RN 分支。
JS缺少类型系统，Flow 太严格，TS 集成到已有项目也还有问题。
重构，重构是不可能重构的，又没有类型系统，只能挣扎着做静态分析。
JavaScriptCore 不一致性，更糟糕的是，现在都 8102年了，RN （Android）带的还是不支持 ES 6 的 JSC
RN 开源库质量参差不齐。比如在 iOS 上正常的库在 Android 上可能有意想不到的错误（因为为作者也许只熟悉 iOS 和 RN,并不熟悉 Android）
有时不得不白手起家，因为很多的基础框架中的库还没有 的RN 封装。
崩溃监控库在 RN 上表现不是特别特定，而且在 RN + Native 错误栈的跳转要不要挑战一下？
Native Bridge 的由于 JS 的弱类型造成Native 与 JS通信 中类型的不匹配，容易造成错误。（后悔没早点用 TS 生成通信代码。）
启动时间，RN框架初始化需要几秒，即使是在高端机器上。
新开页面的渲染时间，0.4秒左右页面第一次渲染费时。
APP 大小。至少增加 12M。
直到目前都无法在 Android 上支持 64位。
手势，iOS 和 Android 的手势 API 差距很大，不过喜闻react-native-gesture-handler 发布了 1.0 版本。
长列表，虽然 RN 团队很努力了，但是由于 RN 的异步通信机制，长列表的流畅渲染，目前依然无解。
React Native 升级是个坑。
RN 中的 Accessibility就是个大坑。
还有一些奇怪的 Bug，暂没有修复。
SavedInstanceState在 Android 上跨进程的坑。
不是技术问题的问题
要用好 RN 你必须同时熟悉 iOS 和 Android ，当然还有 RN 本身，这就对我们工程师提出了更多挑战。
团队的管理，责任的划分。
RN 文档及相关资源不如 iOS 和 Android 的丰富。
作者：banxi
链接：https://juejin.im/post/5b2a5368f265da595c0cf6d5
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。