综合技术

导读《React Native at Airbnb》—— 为什么 Airbnb 放弃了 React Native?

微信扫一扫,分享到朋友圈

导读《React Native at Airbnb》—— 为什么 Airbnb 放弃了 React Native?
0

尽管原文一直在委婉地使用 “sunset”(日落)这个行话,但事实的确是:Airbnb 要放弃 React Native 了。

早上刷到Gabriel Peal 的推时,看到「两年,220 屏,12w 行 JS」,我的第一反应其实是「Airbnb 真的是投入 RN 啊」。综所周知 Airbnb 是除 FB 之外对 React 投入最多,在社区里影响力最大的公司之一了, 他们让 React 可以和 Sketch interop甚至专门收购了一家做 RN IDE 的公司 。结果看到第二行「moving away」我就觉得不对劲了。Grabriel 相信也知道公开宣布放弃 RN 的影响太大,觉得写一篇文不够,于是一连发了 5 篇来解释。


1. React Native at Airbnb

https:// medium.com/airbnb-engin eering/react-native-at-airbnb-f95aa460be1c

第一篇是一个开场,介绍了他们是为什么在 2016 年决定在 RN 上堵一把的。大家都知道 RN 理论上的一些优势,所以他们的主要目标是希望能通过 RN 做到:

  1. 大团队快速迭代(Allow us to move faster as an organization.)
  2. 原生应用质量(Maintain the quality bar set by native.)
  3. 代码跨双平台(Write product code once for mobile instead of twice .)
  4. 提升开发体验(Improve upon the developer experience .)

接下来的四篇文章则分别从不同角度展开:

2. React Native at Airbnb: The Technology

https:// medium.com/airbnb-engin eering/react-native-at-airbnb-the-technology-dafd0b43838

这篇文章着重从技术细节描述 RN 的优劣,我相信大家都比较关注这个,所以我把每一条都列出来了(更细的内容还是看原文)

他们满意的地方是:

  • 跨平台 (只有 0.2% 的平台特定代码)
  • 统一的设计语言,同时还能为不同平台提供不同设计
  • React 的 scale 很好,生命周期比原生简单,声明式很好
  • 迭代速度快(主要是 hot reloading 很快)
  • 大量基础设施的投入值得(网络、国际化、复杂动画、设备信息、用户信息等等都是通过一个桥把原生 api 暴露给 RN 的。)
    • 同时他们在这里也指出:他们并不相信在一个已有 app 上集成 RN 是一件简单事儿,必须要大量且持续地投入基础设施才行(说好的「满意的地方」呢)
  • 性能 (尽管大家都担心但是其实基本没有问题)
    • 不过首次渲染比较慢,导致不适合用作启动屏、deeplink,也增加了可交互时间(TTI),另外掉帧不好 debug(说好的「满意的地方」呢)
  • Redux(好用,虽然废话太多)
  • 背后是原生,一些曾经不确定能不能做的功能( Shared element transitions、动画库 Lottie、网络层、核心基础设施) 发现都能做
  • 静态分析(eslint,prettier,一些性能检测)
  • 动画
  • JS/React 的开源生态
  • Flexbox (via Yoga)
  • 有时候可以加上 Web 跨三端

他们不满意的地方是:

  • RN 太不成熟
  • 需要 fork RN
  • JS 不行 (JS 没有类型不 scale,flow 不好用,TS 不好集成到 babel 和 metro)
  • 不好重构(JS 没有类型无法静态分析,重构错误不能在编译时被捕捉到)
    • (咳,用 ReasonML 啊……)
  • JSCore 在 iOS / Android 上不一致 (Android 上是 RN 自己 bundle 的),很难 debug 这种坑
  • RN 的开源库质量不行(因为太少人能精通所有平台了)
  • 做功能时要回去搞基础设施(因为有的基础设施可能还没暴露给 RN)
  • 奔溃监控(业内没方案,只能自己搞)
  • 原生桥太难写,另外 JS 的类型太难预料(和强类型语言 interop 时)
  • RN 运行时的初始化太慢
  • 首次渲染时间慢(需要从 主线程 -> JS -> Yoga -> 主线程)
  • 应用体积
  • 64 位 (因为 RN 不兼容的 issue 导致他们至今没法在 android 发布 64 位应用)
  • 手势(iOS 和 Android 的手势不好统一,虽然他们搞了 react-native-gesture-handler
  • 长列表
  • 升级 RN 有的时候非常麻烦
  • Accessibility (RN 的有 bug,又要 fork)
  • 稀奇古怪的奔溃
  • 安卓上的应用实例序列化问题

hmm……真是吐槽吐到天上去了……

3. Building a Cross-Platform Mobile Team

https:// medium.com/airbnb-engin eering/building-a-cross-platform-mobile-team-3e1837b40a88

这篇主要讲述他们在组建跨平台的移动团队时所遇到的一些管理挑战。

  • RN 在内部的评论两极化,
  • 要想有好的 RN 体验或者 debug 时还是需要懂 Native,这种原生和 RN 混合对招聘、开发环境、学习成本、测试、迭代速度带来的各种负面影响。
  • 如何决定一个新功能是用原生还是 RN??
  • 怎么拆分团队?

等等,很有意思,尤其值得 Engineering Manager/Director 阅读 ;)

4. Sunsetting React Native

https:// medium.com/airbnb-engin eering/sunsetting-react-native-1868ba28e30a

面对技术与管理的双重挑战,他们认为 RN 并没有达到他们最初列出的四个目标,所以决定 sunset RN 了。

Airbnb 已经停止用 RN 一些开发新特性,并且准备在发布新设计的同时,从最主要的业务开发逐步转回 native,预计在 2019 取得一定的进展。

对于开源,他们会将一些好的 RN 项目转到 react-native-community 下面。

Airbnb 总计投入了 8w 行产品代码,220 个页面和 4w 行基础设施代码在 RN 上,同时也指出他们在 iOS/Android 上分别有 10 倍于此的代码量和 4 倍于此的页面数量。(这么多吗!?)

他们也提到 RN 在走向成熟,包括新文 State of React Native 2018 · React Native

最后他们也提到,他们放弃 RN 的举措并不是适用于所有公司的。但是由于上述痛点和资源等原因,决定 sunset RN。

5. What’s Next for Mobile at Airbnb

https:// medium.com/airbnb-engin eering/whats-next-for-mobile-at-airbnb-5e71618576ab

最后一篇介绍了 Airbnb 在移动端的未来方向:

首先,介绍了一个他们的新方向:

Server-Driven Rendering (服务端驱动渲染)

一言以蔽之,就是服务端发送某种 View 的抽象描述,然后移动端解析这种描述并渲染。

(其实阿里的 Weex 和 Facebook 内部都有类似的技术)

SDR(新词来了!)有诸多好处,详见原文吧 ;)

后面就是一些广告了,介绍了 Epoxy、MvRx、部分 build (类似 buck)技术,秀秀肌肉招招人,happy ending。

两年的 RN 投入付诸东流,我还是挺唏嘘的,一下也不知道该评论些什么。大家有什么想法,欢迎在评论里讨论吧 ;

阅读原文...


前端外刊评论

覆巢之下安有完卵?币价大跌下的矿机市场两极分化显著

上一篇

从零开始搭建一个react项目

下一篇

您也可能喜欢

评论已经被关闭。

插入图片
导读《React Native at Airbnb》—— 为什么 Airbnb 放弃了 React Native?

长按储存图像,分享给朋友