juejin.cn
Open in
urlscan Pro
163.181.92.232
Public Scan
URL:
https://juejin.cn/post/7312176750591934516?searchid=202312271550553d4420395f41dbd043e2
Submission: On December 27 via api from US — Scanned from DE
Submission: On December 27 via api from US — Scanned from DE
Form analysis 1 forms found in the DOM
<form role="search" class="search-form isResourceVisible" data-v-925171a8=""><input type="search" maxlength="64" placeholder="探索稀土掘金" value="" class="search-input isResourceVisible" data-v-925171a8="">
<div class="seach-icon-container" data-v-925171a8=""><svg width="18" height="18" viewBox="0 0 18 18" fill="none" xmlns="http://www.w3.org/2000/svg" class="search-icon" data-v-925171a8="">
<path
d="M12.4008 12.4008C14.744 10.0577 14.744 6.25871 12.4008 3.91556C10.0577 1.57242 6.25871 1.57242 3.91556 3.91556C1.57242 6.25871 1.57242 10.0577 3.91556 12.4008C6.25871 14.744 10.0577 14.744 12.4008 12.4008ZM12.4008 12.4008L15.5828 15.5828"
stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round" data-v-925171a8=""></path>
</svg></div> <!---->
<div class="typehead" style="display:none;" data-v-925171a8="">
<div data-v-925171a8="" class="search-annual"><img data-v-925171a8="" src="https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/51be23201be642f598107c904526a390~tplv-k3u1fbpfcp-zoom-1.image" alt="" class="search-annual-img"> <span data-v-925171a8=""
class="search-annual-txt"> 2023人气创作者榜单 </span></div>
<div class="title" data-v-925171a8=""><span data-v-925171a8="">搜索历史</span> <span class="clear" data-v-925171a8=""> 清空 </span></div>
<div class="list" data-v-925171a8=""></div>
</div>
</form>Text Content
* 首页
* 首页
* 沸点
* 课程
* 直播
* 活动
* 竞赛
商城
APP
插件
*
* * 2023人气创作者榜单
搜索历史 清空
* 创作者中心
* 写文章
* 发沸点
* 写笔记
* 写代码
* 草稿箱
创作灵感 查看更多
* 会员
* 登录
注册
首次登录 / 注册免费领取
* 7天会员
* 小册7折券
* 5万矿石
免费试学课程 · 收藏优质内容 · 提升成长等级 登录 / 注册
网易云音乐 RN 新架构升级实践
网易云音乐技术团队
2023-12-14 7,972 阅读18分钟
关注
> 本文作者：王永亮
本文介绍了从 RN 新架构源码实现角度出发，介绍了如何升级适配，以及网易云音乐在升级适配时遇到的问题及解决方案。
一、背景
网易云音乐从 ReactNative 0.33 版本开始接入，在 2019 年时开始把 RN 作为主要跨端方案进行建设，并从 0.33 升级到了 0.60，升级
0.60 时还只有十几个页面使用 RN 开发，时至 2022 年底已经有 100+ 业务模块使用 RN 开发，对应 100+ RN 项目，P0
级别项目占比超过四分之一。云音乐 RN
已经拥有完善的组件库和自定义协议库，并且建设了从开发脚手架、一站式开发平台、分发服务、端侧定制容器以及监控体系等一系列的配套设施。
虽然使用 RN 开发的页面越来越多，但受限于 JS 的解释执行速度以及 RN 的多线程通信架构等问题，RN
页面在启动性能和某些交互体验上和纯原生仍有一些差距，特别是核心场景，业务对页面打开效率和使用体验特别的敏感，这也导致跨端使用场景进一步扩大受阻。为了突破性能瓶颈，我们在横向对比了业界各主流
App 上使用的动态化跨端方案，同时考虑基于当前 RN 版本进行改造和引擎替换等方案，最终结合云音乐自身的特点和已有基建情况我们选选择了 ReactNative
新架构升级方案。本文主要介绍网易云音乐升级 RN 新架构遇到的一些问题和解决方案，希望给想要升级的同学提供一些可参考的信息。
二、项目思路和方案
新架构调研
升级前我们首先使用 Demo 对新老版本从性能、Bundle 包大小、客户端包大小、内存占用等多角度进行了详细的数据对比，测试机型为 iOS iPhone 6
iOS 12.5、iPhone 12 iOS 16.1，Android 小米8 SE 和红米 Note 9 Pro，测试环境为 RN 0.60 版本 +
JavaScriptCore 引擎和 RN 0.70 版本 + Hermes + 字节码预编译，详细对比信息如下：
性能对比
经过对比，使用新架构 + Hermes 引擎 + 预编译后 Android 小米8 SE 首帧提升 71.5%，LCP 提升 40.1%；红米 Note 9
pro 首帧提升 77.3%，LCP 提升 41.9%；iPhone 6 首帧耗时提升 63%，iPhone 12 提升 42%；LCP iPhone 6 提升
48.5%，iPhone 12 提升 18.3%，详细数据如下表：
首帧时间：
版本iPhone 6iPhone 12小米 8 SE红米 Note 9 proRN 0.601563.66ms189.66ms987.2ms743.4msRN
0.70578.66ms110ms281ms168.4ms
LCP 时间：
版本iPhone 6iPhone 12小米 8 SE红米 Note 9 proRN 0.602482.2ms886.5ms1720ms1358.6msRN
0.701276.6ms724.25ms1030.2ms788.4ms
离线包大小影响
Hermes 引擎的一大优势是预编译和字节码执行能力，但是将 JS 文本编译成字节码是有额外成本的，编译后相比编译前 demo 的 bundle
包的大小压缩前增加 18.1%，ZIP 压缩后相比于非字节码 ZIP 后增加了 57.6%，根据我们后续实际打字节码包的经验，JS Bundle
在字节码预编译后 ZIP 包会有 40% ~ 100% 不等的增加，在网络状态差的情况对离线包的到达会有一定的影响，需要采取一些优化措施， demo
详细数据如下：
是否压缩bundle大小bundle（bytecode）大小ZIP前2.7M3.3MZIP后623kb1.4M
客户端包大小影响
iOS新版本不引入 hermes.framework 时 IPA 包大小为 1.1MB，引入后为 3.1MB，增加了 2MB 包大小。
Android新版本依赖大小 6.12M，老版本 6.14M，影响较小
内存占用影响
使用 Demo 验证在内存（包含 App 本身的内存使用）使用上，RN 0.70 也比 RN 0.60 也有明显优化，iOS 新版本相比老版本内存占用减少了
50% 左右，Android 小米8 SE 内存占用减少 33.2%，红米 Note 9 Pro 内存占用减少31%，具体数据如下：
* iOS
版本iPhone 6iPhone 12RN 0.6042.2MB47.4MBRN 0.7021.4MB25.7MB
* Android
版本小米 8 SE红米 Note 9 ProRN 0.60208.4MB223.1MBRN 0.70139MB153.9MB
其他影响
我们对通信耗时、长列表场景帧率和页面交互能力等场景也进行了 demo 验证，使用 TurboModule、FabricComponent 后通信性能有了 50%
以上的提升，长列表场景帧率无明显变化，页面交互能力和 Native 基本持平。
综上调研结果，RN 0.70 新架构 + Hermes 引擎 + 字节码预编译开启在各个方面上表现都要优于云音乐之前使用的 RN 0.60 +
JavaScriptCore 引擎。
新架构适配
RN 新架构的核心主要有三方面的优化 —— Fabric、TurboModule 和
Hermes，分别对应组件渲染、信息通信和执行引擎，三项优化都可以独立开启和关闭，接入复杂度上 Hermes 接入适配成本相对最低；Fabric 和
TurboModule 都需要进行代码改造适配后才能启用，TurboModule 开启后 NativeModule 仍然可以使用，改造成本适中，Fabric
的开启最为复杂，由于 Fabric 开启后只支持渲染 FabricComponent，所以需要将原来的 NativeComponent 全部改造为
FabricComponent 才能使用，Fabric 在三者中适配成本最高。
这里从 Android 端的角度介绍下新架构的基本原理和适配:
HERMES 升级适配
Hermes 在 0.70 版本时开始被作为双端默认的 JavaScript 引擎，Hermes
引擎最大的优势是支持预编译能力，预编译将原本在端上解释执行时进行的抽象语法树解析、词法解析、以及各种编译优化放到了打包时，直接输出执行效率更高的字节码，具体原理可以参考官方图：
Hermes 支持执行纯文本 JS Bundle 和 JS Bundle 预编译后的字节码文件（HBC
文件），纯文本执行性能相比于其他引擎性能降低明显，但是执行预编译后的二进制文件时性能可以说有了质的提升，尤其是在 Android 系统上，比较直观的体现是 JS
Bundle 预编译成字节码后页面首屏渲染速度的显著提升。 但是也带来了一些副作用，首先是 JS Bundle 预编译为二进制后体积增加 50%
以上，另外一个问题是 JS Bundle 预编译为字节码后使用 bsdiff 打出的差量包的大小相比于原来纯文本的 diff 包增加了 80% 以上，从几
kb、几十 kb 增加到了上百 kb，在一些弱网等场景包大小的增大可能会直接带来离线包下载失败率的提升。对于 diff
包增大的问题经过排查我们发现在打字节码包时增加 -base-bytecode 指令可以降低 diff 包的大小，指令如下：
csharp
复制代码hermes -emit-binary -out bundle.hbc -base-bytecode bundle.hbc
原理可以参考 hermes 的 issue，这里不得不吐槽下 Hermes 官方文档实在是内容太少了，没有对这方面内容的说明。
对于打字节码后包增大的问题，虽然对大部分场景用户都可以通过差量包进行升级，但是对于新用户和刚刚升级到 RN 0.70
的用户还是需要全量拉取的，为了解决这个问题我们对字节码离线包进行了剪裁和引入了新的压缩算法。
使用 Hermes 引擎后 JS 代码打包时会经过混淆、压缩和预编译等步骤，在之前文本打包的基础上，字节码预编译后会生成 HBC SourceMap
来关联字节码和 JS SourceMap，HBC SourceMap 大小在非 ZIP 情况下可以占到 HBC 包大小的 30% 左右，HBC
SourceMap 主要作用是字节码执行出现异常时将字节码堆栈还原为纯文本堆栈，在运行时不需要使用，所以我们在打包时把 HBC SourceMap 从 HBC
包中移除并上传到了云存储，在异常监控平台解析堆栈使用时直接从云存储获取，通过 HBC 包的剪裁压缩后包大小可以缩小 10% ~ 20%。
另外经过调研和对比还引入了 XZ 压缩算法，XZ 压缩算法有更高的压缩比，相比于 gzip 压缩比提升 10%
以上，但是压缩时间和解压缩时间都增加了几十倍，压缩由于发生在打包时时长增加可以忽略不计，在中低端手机上测试解压缩时间从原来的 0.0x
毫秒上升到了几毫秒，时间增加完全可以接受。
经过两项优化后离线包整体大小缩小 30% 以上。
TURBOMODULE 升级适配
TurboModule 提供了 JS 同步调用客户端代码的能力，原理上是以 C++ 代码作为桥梁实现不同语言间的通信，通过 JSI 和 JNI
实现跨语言的通信，代码中利用 JSI 能力在 C++ 代码中向 JSRuntime 注入了 “__turboModuleProxy”，通过
”__turboModuleProxy“ JS 可以直接调用到 C++，C++ 则通过框架初始化时使用 JNI 注入的 TurboModuleManager
Java 对象的引用获取 TurboModule Java 层实现，最后通过 Java 层获取到 C++ 层方法映射完成 TurboModule 的获取。
TurboModule 需要通过 Codegen 来生成，具体方法可以参考官方文档，使用 Codegen 生成的 TurboModule 包含 Java 代码和
C++ 代码两部分，C++ 代码中维护了当前 TurboModule JS 到 C++ 方法的映射，以及对实际实现 TurboModule 的 Java
对象的引用，最终调用 Java 层 TurboModule 方法时则通过 JavaTurboModule 的 invokeJavaMethod 统一中转到
Java 层，这里需要注意的是如果 TurboModule 中定义的方法如果返回值是 void 类型，则会自动转为异步调用方式，相关代码如下：
css
复制代码```
case VoidKind: {
TMPL::asyncMethodCallArgConversionEnd(moduleName, methodName);
TMPL::asyncMethodCallDispatch(moduleName, methodName);
nativeInvoker_->invokeAsync(
// 具体方法实现
);
TMPL::asyncMethodCallEnd(moduleName, methodName);
return jsi::Value::undefined();
}
```
改造为 TurboModule 后，如果需要使用同步方法，则函数定义的返回值也需要改为非 Void。在 RN 新架构中虽然新增了
TurboModule，但是之前的 NativeModule 也还是可以使用的，并且新增的 TurboModule
也是向前兼容的，所以云音乐的做法是先将频繁使用的 NativeModule 改造为 TurboModule，降低改造成本和前端适配的成本。
FABRIC 升级适配
Fabric 对渲染系统进行了重构，重构后渲染系统分为渲染、提交、挂载三个阶段，渲染阶段主要是运行 JS 渲染逻辑，为每个通过 React Fiber
框架计算生成的 Element 节点创建对应的 C++ 影子树节点（shadowNode），提交阶段使用 Yoga
引擎对前一阶段生成的影子树（ShadowTree）进行布局计算，挂载阶段在客户端 UI 线程中将计算好的布局信息和来自于 JS
的样式信息解析为客户端的视图树。新的渲染系统将影子树逻辑和相对应的 Yoga 布局计算直接放在了 C++ 中，优化掉了原来 Java 代码中的影子树和不必要的
YogaJNI 调用，提升了数据传输的效率，整体架构如下图：
Fabric 的适配成本相对来说还是比较高的，和 TurboModule 不同，由于代码中 UIManager 和 FabricUIManager
只能二选一，所以在一个 RN 应用中开启 Fabric 需要将这个 RN 应用依赖的所有 NativeComponent 都改造为
FabricComponent，否则在页面上使用该组件的位置会展示一个未实现组件的提示，FabricComponent 需要使用官方提供的 Codegen
工具生成，这里除了自研组件需要适配，依赖的社区开源的组件也需要升级和改造，这里依赖组件过多改造成本高的话也可以选择分页面逐步迁移以降低开发成本。
前端代码适配
RN 升级除了客户端 RN SDK 升级、NativeModule、NativeComponent 的改造外，前端的兼容适配也有比较大的工作量，首先要解决的是
RN 本身迭代导致的变更，跨越 0.60、0.70 版本不少改动和优化需要适配，另外就是新架构的 API 变更，开启 Fabric 后一些老的 API (如
findNodeHandle、setNativeProps 等) 已无法使用，API 迁移可以参考官方文档说明，这些 API
使用非常广泛，除了业务源码中使用外、我们自己开发的二方组件、社区的三方组件都需要进行适配或者更新，部分三方常用组件还没有新架构的适配版本需要我们自行进行适配，为了尽快完成升级工作，我们选择了先临时对三方库进行私有化，在私有化基础上进行适配改造，稳定性验证完毕后可以回馈给社区，这也带来了另一个问题，常用三方库除了直接在业务代码中依赖在其他三方库中也可能被依赖，这样就造成了私有化的连锁反应，为了解决这个问题我们通过
alias 方式避免依赖膨胀，后续会有前端篇文章专门来介绍。
云音乐升级实战
对于云音乐来说，RN 新架构升级这要有两个问题：
1. 兼容成本高。 升级新架构，除了客户端之前的 NativeModule、FabricComponent 需要升级适配外，还要对在云音乐中已存在 100+
RN 应用进行逐个适配回归，这里面还包含一些营收广告之类的重要页面，回归和上线都需要格外谨慎。
2. 新架构不确定性高，稳定性风险大。 项目开始时距离 RN 0.70 版本发布只过了 3 个月的时间，还没有有关大型 App
对新架构的使用和稳定性情况的消息，另外在老架构中我们就遇到一些 JSC 相关的出现概率不低偶现 Crash，新架构担心会有相同问题。
针对以上问题我们调研制定了比较稳健的升级上线方案，主要涉及工作如下图：
其中主要工作还是围绕降低升级成本和稳定性保障两个方面：
降低升级成本
* 自动化脚本减少适配工作量
在整个 RN 升级工作中工作量占比最高的就是业务的适配和回归工作，在没有遇到疑难问题的情况下熟手适配一个应用需要 0.5d，100+
应用理想情况下预估完全适配完成可能需要 2~3
个月的时间，适配同时还需要兼顾各业务线的迭代排期，可能进一步拉长项目时间，并且已有页面还在不断的迭代中，时间越长适配成本就会越高，后期项目可能会失去掌控。
针对以上问题，我们经过分析发现除了少量 API
升级后参数出现变更，很难通过自动化改造外，大部分情况可以将改造点收敛到依赖中，升级依赖即可完成版本升级，所以针对这个特点我们实现了自动化升级脚本，大部分升级工作通过执行脚本完成，只有少量
API 改造和升级出现的 UI 适配问题需要投入人力，实际每个应用适配工作量缩短到 1h~2h 左右，整体升级成本大大降低。
* RN新架构源码改造，降低改造成本
新架构中客户端一项重要的工作就是 NativeModule 和 FabricComponent 的改造，这块在新架构适配部分也有介绍，对于
NativeModule 我们选择了对部分高频使用的 Module 进行改造，比如我们的自定义协议传输的 Module，几乎所有业务的 JS 和
客户端通信都需要通过这里，这个 Module 改造完已经解决了大部分问题，对于 FabricComponent 我们通过分析源码发现虽然新架构源码中
FabricUIManager 必须使用 FabricComponent，但是仍然可以通过修改源码进行兼容，通过 Codegen 生成的 C++
代码当前版本的主要作用是实现 Props 的类型定义，真正执行时还是会通过 TS 中的 RawProps 来操作需要变更的属性。所以最终我们通过更改
ComponentDescriptorRegistry.cpp 和 SurfaceMountingManager.java 的查找逻辑实现了兼容，重点代码如下：
ComponentDescriptorRegistry.cpp:
SurfaceMountingManager.java:
通过该更改节约了大量的自研组件升级带来的工作量。
* 新老版本一套代码、一次打包即可同时上线新老 RN 版本客户端
对于已经存在 100+ RN 项目的大型 App，RN 新架构升级这种量级的改动是无法直接线上全量的，需要通过 Android 分流、iOS AB
切换的方式逐步放量，放量时间短则一两个迭代，长则可能到一两个月，这时 RN 页面日常迭代发布就需要考虑 RN 0.60 和 RN 0.70
同时兼容的问题，对此我们设计了一套代码出双包的方案，使用该方案业务更改后，一套代码一次打包可以同时发布运行在线上使用 RN 0.60 版本的客户端，以及线上使用
RN 0.70 版本的客户端，整体方案通过自动化升级脚本和 RN 打包脚本改造实现，尽量做到具体业务最小的开发适配成本，改造后整体架构如下：
相对应的开发调试流程也需要相应的变化：
在打包发布平台上兼容模式是可配置的，RN 70 全量后，对于一些如营收相关的页面线上存量的 RN 0.60 版本客户端也非常重要，集成在 RN 0.60
版本客户端上的页面需要持续的维护，直到 RN 0.70 版本覆盖率到达到一定程度，到时才可以放弃少量的存量版本，这种情况可以一直保持 RN 0.60 版本和
RN 0.70 版本的配置，对于大部分应用在RN 0.70 全量后 RN 0.60 的兼容包就不需要再维护，则去掉打 RN 0.60 兼容包的配置即可。
稳定性保障
RN 升级需要适配页面众多，改造成本极大，新架构还带来了很多的不确定性，对此我们做了非常多的工作进行稳定性保障，RN 升级上线后做到了 0 线上问题。
* 源码改造，新增 Hermes、FabricComponent、TurboModule 降级能力
RN 新架构中 Hermes 引擎、FabricComponent 和 TurboModule 都还是比较新的东西，为避免出现线上问题，我们对
Hermes、Fabric、TurboModule 都增加了动态降级能力，通过配置的实时下发随时可以切换到降级模式，避免异常突增或某些业务突现 bug
造成诸如资损等严重问题。
* iOS 双动态库方案，实现 AB 阶梯放量
在 RN 0.70 版本中，新架构和引擎都存在非常大的不确定性，根据我们之前的 RN 使用经验，老版本中Android JavaScriptCore
引擎在开发测试期间都比较稳定，但是上线后会有一些出现概率不低的引擎侧异常，iOS 切换为 Hermes
后很可能有相同问题，所以要提前设计好上线的方式和节奏，尤其是在 iOS 系统上，由于苹果应用市场的限制，几乎不可能做到和 Android
一样的灰度和逐个应用市场放量的能力，所以为了避免风险，我们设计了 RN 0.60 和 RN 0.70 版本双动态库方案，即保证了稳定性，又为 AB
数据实验做好了准备，详细实现可以关注后续文章。
三、升级收益
* 性能提升 升级后页面线上性能数据普遍提升，首次渲染白屏有效解决，低端机提升尤其显著
升级后 RN 页面 JS 渲染执行时的 loading
展示时间已完全不可见，除了体感的提升外，我们还对线上的性能数据进行了全面的统计，统计结果中各项性能数据均显著提升，其中 Android
最大元素渲染完成时间（LCP）提升 20%~50%，iOS LCP提升 10%~20%，在 Android、iOS 低端机上提升都更加显著，RN 升级后页面
LCP 时间基本都可以做到 1s 内，做到了页面秒开。
* 稳定性提升 升级后客户端各项稳定性数据均有提升
RN 升级后 Android 端稳定性得到显著提升，JavaSriptCore 引擎偶现崩溃得以解决，Hermes
偶现万分位异常，引擎带来的稳定性问题基本已被解决，由于新架构新引擎的内存占用减低，一些内存不足引起的异常也减少很多。
> 相关链接： reactnative.dev/docs/next/n… reactnative.cn/architectur…
最后
更多岗位，可进入网易招聘官网查看 hr.163.com/
标签：
前端
评论 44
0 / 1000
标点符号、链接等不计算在有效字数内
Ctrl + Enter
发送
登录 / 注册 即可发布评论！
最热
最新
玛卡巴卡的手推车
前端开发
新版本很难用
1天前
1
评论
* 屏蔽作者：玛卡巴卡的手推车
* 举报
xw中年油腻
那个忘川 鸿蒙 怎么说呢？
3天前
点赞
评论
* 屏蔽作者：xw中年油腻
* 举报
一介农夫
Go研发工程师 @杭州电泰实业有限公司
不知道腾讯视频是用什么开发的在 mac m1max 32g 的硬件上启动得好几秒才弹出界面，真的以我的体验来说就是垃圾性能
5天前
1
评论
* 屏蔽作者：一介农夫
* 举报
查看全部 44 条评论
92
44
收藏
加个关注，精彩更新不错过~
关注
网易云音乐技术团队
@网易云音乐
作者榜No.7
优秀作者
202
文章
1.5m
阅读
20k
粉丝
加个关注，精彩更新不错过~
关注
已关注
私信
人气作者 投票中
目录
收起
* 一、背景
* 二、项目思路和方案
* 新架构调研
* 性能对比
* 离线包大小影响
* 客户端包大小影响
* 内存占用影响
* 其他影响
* 新架构适配
* Hermes 升级适配
* TurboModule 升级适配
* Fabric 升级适配
* 前端代码适配
* 云音乐升级实战
* 降低升级成本
* 稳定性保障
* 三、升级收益
* 最后
相关推荐
复刻antfu大佬的svg签名效果
2.8k阅读
·
60点赞
Linus：批评 GitHub 代码合并【毫无用处的】
6.8k阅读
·
6点赞
一文搞懂得物前端监控
1.7k阅读
·
16点赞
前端已死？别低估前端，他是互联网世界的核心！【这是一篇治愈系文章】
3.1k阅读
·
20点赞
去哪儿网架构演进之路：微服务的尽头原来是DDD……
2.8k阅读
·
13点赞
精选内容
功能问题：如何在H5中实现拍照功能？3步搞定！
程序员大澈
·
824阅读
·
5点赞
关于zustand的一些最佳实践
前端小付
·
959阅读
·
17点赞
grid布局--超炫酷的电子商务布局
叁两
·
985阅读
·
13点赞
Webpack 操练场 ③：使用 Webpack 构建 Vue 开发环境
Esun_R
·
822阅读
·
1点赞
Webpack 操练场 ②：使用 Webpack 构建 TypeScript 开发环境
Esun_R
·
774阅读
·
1点赞
找对属于你的技术圈子
回复「进群」加入官方微信群
为你推荐
云音乐 React Native 体系建设与发展
17 年 3 月份，为了解决商城性能和用户体验问题，云音乐技术团队组建了一只 4 人 ReactNative 开发小分队：我负责 RN 前端开发，安卓和 iOS
两位开发负责在云音乐 App 里面嵌入 RN Native SDK，还有一位 Java 开发来负责部署平台工作。 商…
* 网易云音乐技术团队
* 3年前
* 8.2k
*
138
* 51
*
React Native
去中心化的 React Native 架构探索
我们探索了去中心化的 RN 架构，并结合该模型自研了系统（Code Push Platform，简称 CPP）和客户端
SDK，覆盖了多团队的开发、构建、发布、运行等一系列 RN 研发周期。
* Shopee技术团队
* 1年前
* 2.5k
*
19
* 1
*
React Native
网易云音乐机器学习平台实践
机器学习平台为算法相关工作者提供基础的开发调度环境，为机器学习各个系统提供集成与接入的能力，为各个机器学习相关子系统形成一套标准化流程提供保障。
* 网易云音乐技术团队
* 1年前
* 3.5k
*
15
* 评论
*
机器学习 云原生
React Native原理之跨端通信机制
本文讲述了安卓中 React Native 的通信原理，解释了业务中如何实现 Native 模块和 JS 模块的桥接，读者可以加深对React
Native或者其他跨端方案的通信原理的了解。
* 网易云音乐技术团队
* 1年前
* 5.5k
*
45
* 5
*
React Native
不会吧 不会吧？都2202年了，React Native IOS原生包还有人不会制作？
本文描述了 使用 react-native-builder-bob构建ReactNative
IOS原生模块的实现。以及遇到的各位坑的地方，本文实践实践2022-2-3日
* 无双_Joney
* 1年前
* 1.7k
*
9
* 评论
*
iOS React Native
RN性能优化实践
RN常用的性能优化手段，包含框架层代码优化、组件层代码优化、业务层代码优化。最后总结了常用的其他Reactnative性能优化方法。
* 川叶
* 1年前
* 2.9k
*
16
* 1
*
React Native
ReactNative与iOS原生通信原理解析-通信篇
本文将在上述两篇文章的基础上，继续深入理解 RN 与 iOS 原生通信机制。 声明: 本文所使用的 rn 版本为0.63.0。
看过前面一篇ReactNative 与 iOS 原生通信原理解析-JS 加载及执行篇 的同学应该已经清楚，在执行完成 js 代码之后，会在 JSIEx…
* MrGaoGang
* 3年前
* 1.5k
*
5
* 评论
*
React Native
去哪儿QRN兼容升级方案
1. 前言 React Native 0.63 已经发布，为我们带来了一些非常令人兴奋的新功能的同时, 也让人头疼的，因为升级它并不是那么容易.
尤其是遇到大版本更新，JavaScript、iOS 和 Android 三端的配置构建文件都有非常大的变动，有时候三者的配置文件又互…
* 去哪儿技术沙龙
* 2年前
* 676
*
8
* 6
*
React Native
构建高性能 React Native 跨端应用—引擎与渲染
React Native 目前是一个非常成熟的跨端技术方案， 目前 RN 在 Native 端的表现也是非常出色的，即便是这样，在 RN
构建的应用中，性能也是不容忽略的一部分，尤其在移动端应用...
* 我不是外星人
* 1年前
* 7.8k
*
41
* 13
*
前端 React.js React Native
爱奇艺RND框架技术探索——架构与实现
RND，全称React Node Desktop，起源于RN在爱奇艺PC端的实现，采用React JS framework +Node.js runtime +
native UI engine架构，目标是成为最轻量的JS开发桌面应用的跨平台方案。之前我们还分享了一篇关于RND的...
* 爱奇艺技术
* 2年前
* 521
*
8
* 评论
*
后端 架构
云音乐 iOS 跨端缓存库 - NEMichelinCache
在云音乐全面转跨端的时代，H5 / RN
缓存模块是非常重要的组成部分，目前云音乐使用的缓存库已经“历史悠久”，没法在现有的基础上支撑日益庞大的跨端需求，因此我们基于缓存库的可扩展架构，从问题出发，重
* 网易云音乐技术团队
* 10月前
* 13k
*
28
* 3
*
iOS
React Native入门详解--实战开发中常见的需求
本文针对实战开发中，那些常见的需求进行了汇总总结。例如应用的适配、应用路由的解决方案、渐变色的实现等....
* _光光
* 2年前
* 1.7k
*
18
* 评论
*
React Native
React-native 打包速度优化，配合webpack起飞！
前言 随着RN项目越来越大，打包速度也越来越慢，经常需要十几分钟，有的人的电脑比较垃圾，在本地打包的时候甚至需要花费半个多小时。
在发布生产的时候，时间花费并没有太大影响，如果是在测试阶段，一个简简单
* 青火_
* 1年前
* 4.5k
*
30
* 2
*
React Native Webpack
React Native 新旧架构对比
在 RN 社区的 Upgrade Helper 中可以看到，从 0.67 版本到 0.68 版本的更新中有非常显眼的字眼： 那么今天我们就来看下 RN New
Architecture 到底新在哪里。
* 龙飞_longfe
* 9月前
* 8.0k
*
54
* 20
*
前端 React.js React Native
使用SDK方式加载React Native
如何实现在低耦合，少入侵别人代码的情况下把RN项目集成到第三方App中？所以在项目开始之前我们考虑使用SDK的方式来加载RN项目。
* VisuperviReborn
* 2年前
* 2.0k
*
3
* 17
*
React Native 前端
收藏成功！
已添加到「」， 点击更改
* 微信
微信扫码分享
* 新浪微博
* QQ
APP内打开
* 下载APP
下载APP
* 微信扫一扫
微信公众号
* 新浪微博
掘金已支持深色模式
在“我的设置-通用设置”中即可配置
点击前往
温馨提示
当前操作失败，如有疑问，可点击申诉
前往申诉 我知道了
选择你感兴趣的技术方向
后端
前端
Android
iOS
人工智能
开发工具
代码人生
阅读
跳过
上一步
至少选择1个分类
确定屏蔽该用户
屏蔽后，对方将不能关注你、与你产生任何互动，无法查看你的主页
取消 确定
沉浸阅读