网易云音乐React Native体系建设与发展

本文作者：章伟东 （网易云音乐大前端团队）

0.33 历史

17 年 3 月份，为了解决商城性能和用户体验问题，云音乐技术团队组建了一只 4 人 ReactNative 开发小分队：我负责 RN 前端开发，安卓和 iOS 两位开发负责在云音乐 App 里面嵌入 RN Native SDK，还有一位 Java 开发来负责部署平台工作。

商城 RN 应用上线后，其他团队表示有兴趣尝试，但当时 RN 项目开发没有脚手架，项目创建通过原始拷贝进行，缺少 forweb 支持，RN 预加载只接入了 iOS 一端。

种种原因，导致 RN 开发效率低下，音乐人业务原本有兴趣用 RN 来开发新应用，开发到一半改成了 H5。

从 17 年 3 月份到 19 年 9 月份，RN 版本始终为 0.33，核心开发团队人员流失一半，部署平台无人维护，项目开发缺少脚手架，缺少 forweb 支持，一共上线 RN 应用为 2.5 个（商城、音乐人、三元音箱）。

搅动历史

时间滚滚向前，新技术层出不穷。2 年半的时间对于前端发展来说，恍如隔世。 如果不出任何意外，RN 技术就会躺在历史的尘埃里，无人问津。这种尴尬的局面，直到会员收银台到达率优化项目才被打破。

会员收银台页面即下图，是云音乐会员购买页面，重要性不言而喻。这个页面最开始是一个 React 服务端渲染开发的 H5 页面。

为了能让用户更加顺利购买会员，提高用户体验和到达率，整个技术团队采用 web 通用优化技术结合云音乐自身技术设施，花了一个月对这个 H5 页面进行优化，将到达率从 72% 提高到 89%，提高了 17 个百分点。与竞品比较如下（单位是秒）。

到达率计算公式= 收银台可视埋点/客户端点击埋点

虽然优化结果喜人，但是存在几个问题：

1. 到达率目标未完成。当初技术团队定的是至少 90% 以上，差了一个百分点。
2. ROI 太差。H5 优化投入了前后端开发众多人力，花了将近一个月。如果再去优化其他页面，目前方案自动化程度低，仍需大量人工操作。
3. 0.33 RN 到达率为 93%。我们统计了商城 RN 版本的到达率，未做任何优化，轻松破 90。

此时放在团队面前有 3 条路：

1. 在 H5 页面上投入更多资源优化，突破 90% 完成任务。但这种方案耗费大量的人力物力，对优化其他页面用处不大，属于一锤子买卖。
2. 在 RN 0.33 版本上重置收银台页面。 这样虽然能达到目标，但是 RN 基础设施仍然停留在 3 年前。
3. 将 RN 基础建设补齐，升级到最新 0.6 版本，实现三端方案，构建完整的 RN 开发体系。在此基础上，基于 0.6 版本重置收银台，借助这个项目将 RN 整个技术栈更新换代。这种方案虽然收益大，但时间跨度长、困难大、复杂性高。

经过激烈讨论和痛苦抉择，团队决定向更高目标发起冲击，不满足于只完成到达率目标，而是要重建整个 RN 技术体系，为以后的开发铺平道路，一劳永逸解决整个前端开发的性能和体验问题。

自动部署

旧部署平台

原有 RN 部署平台没有实现自动部署，发布一个 RN 应用需要做以下事情

执行兼容性脚本

为了支持低版本如 iOS8，需要手动修改本地 node_modules 里面相关源码。

    sed -i -e 's/function normalizePrefix(moduleName: string)/const normalizePrefix = function(moduleName: string)/g' ./node_modules/react-native