React Native 的动态列表方案探索详解.docxVIP

第

React?Native?的动态列表方案探索详解

目录背景技术方案介绍内存异常处理未来规划

背景

时至2025，精细化运营已经成为了各大App厂商的强需求，阿里的DinamicX、Tangram大家应该都很熟悉了，很多App厂商也自研了一些类似框架，基于DSL的动态化方案虽然有性能上的一些优势，但是毕竟不是图灵完备，一些需要逻辑动态下发的需求实现成本偏高，或由于DSL本身限制无法实现，针对这个问题我们使用RN进行了一下探索尝试，利用我们已经相对完善的RN基建，结合客户端列表能力低成本的实现了一套的动态化能力，同时兼顾一定的性能体验。

基于ReactNative的动态列表方案简单来说就是将ReactNative容器内嵌在RecyclerView的ViewHolder中，由于页面主体框架还是由Native开发和渲染，所以首屏加载速度得到了保证，局部的RN实现也使页面获得动态化的能力，从而在性能、完备逻辑执行的动态化能力之间取得了一个平衡点，根据我们使用经验对几种动态化方案排序如下：

整体性能体验排序：纯Native基于DSL动态化方案=ReactNative动态列表方案纯ReactNative页面H5动态能力排序：H5=纯ReactNative页面ReactNative动态列表方案基于DSL动态化方案纯Native实现能力排序：纯Native=RN动态列表方案=纯ReactNative页面H5基于DSL的动态化方案

从以上排序中可以看出ReactNative动态列表方案整体处于中等或中等偏上的一个位置，在实现能力上远胜余基于DSL动态方案，和Native能力基本对等，可以实现一些复杂的UI交互效果，并且相比于纯RN实现的页面首屏速度会有非常大的优势，另外不需要对页面整体框架进行更改就能比较方便的嵌入，在开发维护成本上RN动态列表方案相比各种基于DSL的动态化方案会有比较明显的优势，不需要额外的开发组件管理平台，排查问题时也不用去读难懂的dsl，最重要的是RN具有图灵完备的能力，所以综合来看使用RN内嵌到NativeRecyclerView来实现Native页面部分动态化的方式算是一种性价比相对较高的方式了，值得一试。

技术方案介绍

这里从Android视角分享下我们这套方案实现的一些技术细节、原理以及遇到的问题。首先我们常用的一些术语：

moduleName是RN离线包的唯一key，相当于离线包的名字；componentName是RN中registerComponent的component，对应一个RN实现的业务的执行入口；卡片指云音乐首页中每个viewholder内部的展示内容，展示的UI样式是卡片样式；RN引擎指以RNBridge为主的整个JS离线包运行时环境。

整体方案架构如下：

从图中可以看出整体方案采用数据驱动的方式，服务端通过数据中携带的类型、component、moduleName等字段来唯一指定是否是使用RN来渲染，执行RN离线包中的哪个component逻辑

整体方案上有几个细节点：

采用数据驱动的方式，接入页面无须关注具体展示数据，只需要将数据透传到RN的JS侧即可由于RN需要将离线包加载后才能执行JS生成客户端视图，在RecyclerView绑定数据时才开始加载RN的离线包势必会拖慢整个模块的展示，所以这里我们做了整个离线包的预加载首页列表中每个ViewHolder的展示元素我们叫做一个卡片，目前采取的策略是多个卡片放在一个RN的离线包中，通过同一个RN容器来分别展示，避免多个容器消耗过多的资源。

下面从数据流角度拆解整个方案，整体方案可以分为服务端数据定义和下发，容器数据透传，JS侧数据解析三个主要步骤：

服务端数据定义和下发

由于是服务端接口驱动RecyclerView中内容展示，接口下发数据中需要有type字段标识使用RN还是Native展示，可以服用Native展示样式标记字段，由于RN中具体展示的样式和运行哪些JS代码直接相关，所以服务端下发的数据中需要带上对应的moduleName和componentName，整体数据结构定义如下：

[{type:rn,

rnInfo:{

moduleName:bizDiscovery,

component:hotSong,

otherInfo:{

data:{