Airbnb: React Native 从选择到放弃

Airbnb 最近在 Medium 上发布了一系列文章详细描述了 Airbnb 与 React Native 从选择到放弃的整个心路历程。

1. React Native at Airbnb
2. The Technology
3. Building a Cross-Platform Mobile Team
4. Making a Decision on React Native
5. What's Next for Mobile

对于字多不看的同窗，能够简单看一下我下面的小结。

当初为何选择 React Native

有限的开发团队知足不了日益增加的业务需求

对 React Native 的指望

1. 快速开发
2. 质量有保证
3. 一次编写，多平台共享
4. 提高开发体验

咱们所怀念的

1. 跨平台，实际上有 95% 以上的共享代码率。
2. 统一的 DSL。根据平台也作具体的差别化实现。
3. React 是个好东西。组件化，简单的生命周期,声明式
4. 开发迭代速度（热更新 hot-reloading）
5. 咱们在 RN 生态基础设施上的投资。
6. 性能，在绝大部分页面上 RN 都表现得很流畅。（有性能问题？ shouldComponentUpdate, removeClippedSubviews, Redux 了解一下。）
7. Redux 是个好东西。也是个好冗长的东西。
8. 与 Native 的桥接，能够方便的封装已有的 Native 库。
9. 静态分析，从 ESLint 到 prettier
10. RN 的动画库不错。
11. JS/React 的开源生态。
12. Flexbox
13. 与 Web 平台共享代码。

让咱们沮丧的

1. 论成熟度，稳定性，RN 比 不上iOS 和 Android 原生。
2. 因为 RN 的 Bug，有时咱们必须维护本身的一个 RN 分支。
3. JS缺乏类型系统，Flow 太严格，TS 集成到已有项目也还有问题。
4. 重构，重构是不可能重构的，又没有类型系统，只能挣扎着作静态分析。
5. JavaScriptCore 不一致性，更糟糕的是，如今都 8102年了，RN （Android）带的仍是不支持 ES 6 的 JSC
6. RN 开源库质量良莠不齐。好比在 iOS 上正常的库在 Android 上可能有意想不到的错误（由于为做者也许只熟悉 iOS 和 RN,并不熟悉 Android）
7. 有时不得不白手起家，由于不少的基础框架中的库尚未 的RN 封装。
8. 崩溃监控库在 RN 上表现不是特别特定，并且在 RN + Native 错误栈的跳转要不要挑战一下？
9. Native Bridge 的因为 JS 的弱类型形成Native 与 JS通讯 中类型的不匹配，容易形成错误。（后悔没早点用 TS 生成通讯代码。）
10. 启动时间，RN框架初始化须要几秒，即便是在高端机器上。
11. 新开页面的渲染时间，0.4秒左右页面第一次渲染费时。
12. APP 大小。至少增长 12M。
13. 直到目前都没法在 Android 上支持 64位。
14. 手势，iOS 和 Android 的手势 API 差距很大，不过喜闻react-native-gesture-handler 发布了 1.0 版本。
15. 长列表，虽然 RN 团队很努力了，可是因为 RN 的异步通讯机制，长列表的流畅渲染，目前依然无解。
16. React Native 升级是个坑。
17. RN 中的 Accessibility就是个大坑。
18. 还有一些奇怪的 Bug，暂没有修复。
19. SavedInstanceState 在 Android 上跨进程的坑。

不是技术问题的问题

1. 要用好 RN 你必须同时熟悉 iOS 和 Android ，固然还有 RN 自己，这就对咱们工程师提出了更多挑战。
2. 团队的管理，责任的划分。
3. RN 文档及相关资源不如 iOS 和 Android 的丰富。