首页 >业界动态

Airbnb: React Native 从选择到放弃

2018-07-05 10:26 编辑: 游星啊 分类:业界动态 来源:banxi

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

对于字多不看的同学,可以简单看一下我下面的小结。

当初为什么选择 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 的丰富。

作者:banxi

链接:https://juejin.im/post/5b2a5368f265da595c0cf6d5

搜索CocoaChina微信公众号:CocoaChina
微信扫一扫
订阅每日移动开发及APP推广热点资讯
公众号:
CocoaChina
我要投稿   收藏文章
上一篇:CC招募微信群主啦,想玩儿权限现在就是机会!
下一篇:韩法院禁止三星前员工跳槽中国公司 否则每天赔5.9万
我来说两句
发表评论
您还没有登录!请登录注册
所有评论(0

综合评论

相关帖子

sina weixin mail 回到顶部