企业官网建设流程全解析

先说结论：在 OpenHarmony 上跑 React Native 的 ScrollView 滚动动画，思路和 Android/iOS 上一致，但实践下来坑不少。这个标题拆开看，就是“跨端框架 + 国产系统 + 最常用的列表容器 + 视觉反馈”，组合起来却是一个很典型的落地场景。我前段时间刚好在 RK3568 的 OpenHarmony 设备上完整做过一轮 ScrollView 动画改造，从环境搭建到真机调优都踩了一遍，这篇就把它拆成可复现的步骤和经验，重点讲三件事：OpenHarmony 下 RN 环境怎么搭、ScrollView 滚动动画的核心写法是什么、以及真机调试时那些让人抓狂的坑到底怎么排查。

1. 为什么要在 OpenHarmony 上动 ScrollView 这块骨头

1.1 这个需求的由来

很多团队接手 OpenHarmony 应用开发时，第一反应是用 ArkUI 重写界面。但现实往往是：业务团队已经有一套成熟的 React Native 代码，短时间内不可能全部推翻。于是“React Native 跑在 OpenHarmony 上”这件事就变得很实际。ScrollView 又是几乎所有业务首页、列表页、详情页都用得到的容器，滚动动画则是让页面“活”起来的关键手段。

打开任意一个主流 App，你可以观察一下：顶部标题栏在列表往下滚时慢慢变小、背景图在滚动过程中产生视差、Tab 吸顶、下拉刷新时出现弹性效果……这些都是 ScrollView 滚动动画的常见形态。说白了，滚动动画就是把用户的滚动行为转化成视觉反馈，滚动多少、视觉变化多少、加速度怎么映射，这些参数决定了交互手感。在 OpenHarmony 上做这件事，难点反而不在动画本身，而在环境适配和设备差异。

1.2 先搞清楚你跑在什么设备上：RK3568 设备树怎么选

拿到 OpenHarmony 设备时，第一件让人懵的事就是“设备树到底咋选”。网上搜 RK3568 相关的内容，会看到一堆 dtb 文件名：rk3568-evb1-ddr3-v10.dtb、rk3568-evb2-lp3-v10.dtb、rk3568-evb4-lp3-v10.dtb……有人照着教程编译完烧进去，发现触摸屏没反应、WiFi 打不开，甚至起不来系统，十有八九是设备树选错了。

设备树（Device Tree）本质上是一份“硬件清单”，告诉内核：这块板子上有哪些外设、内存多大、用的是哪个屏幕、触摸 IC 是什么型号。OpenHarmony 的标准镜像里会预编译多个 dtb，选择的关键不是文件名，而是实际板子的硬件配置。我当时的操作路径是：

1. 先看板子丝印和文档，确认具体型号，比如 RK3568 的 EVB1、EVB2 还是第三方核心板；
2. 用串口或者 ADB 进入系统后，执行cat /proc/device-tree/model查看当前加载的硬件模型；
3. 对比当前模型和编译配置里的 product 定义，找到对应关系。

提示：第三方 RK3568 核心板（比如某些国产工控板）往往不自带 dtb，需要找厂商要适配文件。如果买的是官方开发套件，优先用出厂镜像里默认的 dtb，不要随便改。

如果你只是在应用层做 RN 开发，设备树的影响并没有想象中那么大——它更影响系统能不能跑起来、触摸和显示是否正常。真正要关心的是：系统跑起来之后，RN 的 JS 引擎能否正常调度、渲染线程是否流畅、GPU 是否支持硬件加速。所以设备树选择这块，我的建议是“能用出厂默认就别折腾”。

1.3 OpenHarmony 的 x86 版本值不值得试

还有一个热词是“电脑版 x86 OpenHarmony”。很多开发者想在 PC 的虚拟机上先跑起来，简单验证 RN 逻辑。我试过 x86 版 OpenHarmony 跑 RN 应用，说实话，做纯 JS 层的调试可以，做渲染和动画评估基本没用。

原因很简单：x86 模拟器里的 GPU 加速、合成器、渲染管线都和真机差异很大。动画卡不卡、滚动跟不跟手，这些感知型指标必须在真机上测。x86 版本更适合的场景是验证业务逻辑、排查 JS 层面的报错、跑单元测试。你要是想在电脑上看动画效果，不如直接在电脑上搭一个普通的 React Native Android 环境预览，动画逻辑用同一套代码，视觉效果不会差太多。

2. 先把地基打好：OpenHarmony 上 RN 环境搭建的关键细节

2.1 OpenHarmony 对 React Native 的支持模式

OpenHarmony 并不是原生支持 React Native 的，需要依赖社区移植的方案。目前用得比较多的是 OpenHarmony SIG 维护的react-native-harmony仓库，它通过桥接层把 RN 的 View、ScrollView、Text 等核心组件映射到 ArkUI 的对应组件上。

这个方案的设计思路是“双层映射”：

• JS 层：RN 的渲染指令通过 Bridge（老架构）或 JSI（新架构）传递给 C++ 层；
• C++ 层：通过实现 RN 的UIManager和组件宿主接口，把指令转成 ArkUI 的组件树；
• ArkUI 层：最终由 OpenHarmony 的图形栈绘制出来。

理解了这条链路，你就明白为什么滚动动画在 OpenHarmony 上会有额外的性能损耗：每一次滚动事件都要从 ArkUI 的滚动容器反馈到 RN 的 JS 线程，再通过 JSI 或 Bridge 回传。事件链路比 Android 上更长，如果代码写得粗糙，掉帧几乎是必然的。

2.2 环境搭建的五个步骤

环境搭建的细节不多说，但关键步骤值得记录，尤其是一些容易忽略的配置：

1. 拉取 react-native-harmony 仓库，注意版本必须和你的 OpenHarmony SDK 版本匹配。我用的是一套 4.1 版本的 SDK，对应的 RN 版本是 0.72。
2. 配置 OpenHarmony SDK 路径，在local.properties里写清楚 SDK 位置，否则 Gradle 无法识别。
3. 同步依赖，这一步在第一次执行时会特别慢，需要耐心等待。
4. 准备 entry 模块，把 RN 的 bundle 路径配置到 HarmonyOS 工程里。
5. 连接 Metro，OpenHarmony 设备同样支持 Metro 热更新，但需要手动把 Metro 地址配置到 native 层。

注意：如果你用的是新版 DevEco Studio，默认会启用 API 版本校验。RN 的 native 工程可能和目标 API 版本有冲突，需要在build-profile.json5里调整 compatibleSdkVersion 才能过编译。

2.3 启动白屏到底卡在哪儿

“React Native 启动白屏”是搜索热词，OpenHarmony 上加倍明显。我排查过几次，绝大多数白屏的原因是bundle 没有正确加载，而不是 RN 本身跑不起来。

OpenHarmony 上加载 RN bundle 有两种方式：

• Debug 模式：从 Metro 服务器拉取 bundle，此时需要保证设备的 Metro 网络可达。如果设备是通过 USB 连接，要用adb reverse tcp:8081 tcp:8081把端口反转过来；
• Release 模式：从本地 assets 目录读取打包好的 bundle，此时要确认 bundle 是否被打进了应用资源目录。

白屏的排查路径很固定：先看 Logcat 里有没有“Loading from Metro”或“Reading bundle from assets”的日志，判断 bundle 来源；再看有没有 JS 报错，比如Unable to load script或模块解析失败；最后检查应用是否有存储权限——有些版本需要手动授予存储权限才能读取本地 bundle。

这里有一个很隐蔽的细节：OpenHarmony 的权限模型和 Android 不完全一样，存储权限需要在应用配置文件里显式声明，否则 Release 模式读取 assets 会失败，但错误提示通常很模糊。

3. ScrollView 滚动机制与动画实现的核心原理

3.1 滚动事件在 RN 里是怎么流转的

ScrollView 的滚动动画，核心是监听滚动位置并驱动视图变化。RN 的标准做法是Animated.event绑定onScroll，把滚动事件映射到 Animated.Value 上，然后再让其他视图的属性跟随这个 Value 变化。

事件流转路径是这样的：

• 用户在屏幕上滑动，ArkUI 的 Scroll 组件产生滚动回调；
• RN 的 ScrollView 组件把这个回调包装成 JS 事件；
• Animated.event把事件里的contentOffset.y取出，写入 Animated.Value；
• Animated.Value 通过插值器（interpolate）计算输出值；
• 输出值驱动绑定视图的transform、opacity、height等属性变化。

这个过程必须在 JS 线程完成。你可能会问：Android 上不是可以用useNativeDriver: true让动画在 UI 线程跑吗？OpenHarmony 这边目前对原生驱动的支持还不完整，强行开启会报警告甚至直接失败。所以一般情况下我用的是useNativeDriver: false，也就是 JS 驱动模式。这也意味着你写的动画代码必须“轻”——一旦某个回调里有重逻辑，立刻卡顿。

3.2 滚动动画最常见的三种形态

锚定了事件链路，再看具体能做什么效果。结合日常业务，我梳理了三个最有代表性的滚动动画：

1. 头部缩放/淡出：当 ScrollView 向下滚动时，顶部大图的高度逐渐变小、透明度逐渐降低，露出后面的标题栏。这种效果适合详情页、文章页。
2. 视差效果：背景层和前景内容的滚动速度不同，比如背景滚动慢、内容滚动快，制造出立体感。它不需要真的改变布局，只需要把背景层的 transform translateY 设置成滚动位置的 0.3 倍或 0.5 倍。
3. Tab 吸顶：Tab 栏滚动到顶部后固定住。严格说吸顶不依赖 Animated，而是通过onScroll判断滚动距离，然后切换position: sticky或绝对定位。但要在 OpenHarmony 上做得平滑，需要配合动画过渡，否则“跳变感”很明显。

3.3 关键参数：scrollEventThrottle 和插值器

真正影响代码成败的是两组参数。

第一组是scrollEventThrottle。它表示“多少毫秒最多触发一次 onScroll 事件”，单位是毫秒。默认值是 0，但在 OpenHarmony 上，值为 0 时事件触发频率可能过高，导致 JS 线程被打满；设得太大（比如 100），又会让动画明显掉帧、手感发木。我实测下来16ms 左右是比较合理的值，大约对齐 60fps 的刷新频率。代码里这样写：

<ScrollView onScroll={Animated.event( [{ nativeEvent: { contentOffset: { y: scrollY } } }], { useNativeDriver: false, listener: (e) => handleScroll(e) } )} scrollEventThrottle={16} >

第二组是插值器的inputRange与outputRange。这里的核心是“映射比例”。比如我希望图片高度在滚动 120px 内从 260 缩到 100，透明度从 1 降到 0：

const headerHeight = scrollY.interpolate({ inputRange: [0, 120], outputRange: [260, 100], extrapolate: 'clamp', }); const headerOpacity = scrollY.interpolate({ inputRange: [0, 80], outputRange: [1, 0], extrapolate: 'clamp', });

关于插值器，最重要的心得是：一定要设置extrapolate: 'clamp'。如果不设置，当滚动距离超出 inputRange 时，输出值会继续向正负无穷延伸，导致图片高度变成负数或元素位置跑飞。OpenHarmony 上跑飞的效果比 Android 上还要夸张，因为 ArkUI 对负值 transform 的处理更容易引发布局异常。

4. 完整实现：一个“列表 + 头部收缩 + 吸顶”的复合滚动页面

4.1 页面结构设计

纸上谈兵讲完了，给一个可以直接抄作业的完整案例。这个案例同时包含头部图片收缩、标题栏淡入、Tab 吸顶三个效果，基本覆盖了大部分业务场景。

先定义一下页面结构：

• 最外层是一个 Animated.ScrollView；
• 滚动内容的顶部是一张高度 260 的大图，带视差背景；
• 大图下面是一个可吸顶的 Tab 栏；
• Tab 栏下方是若干个竖向的卡片列表。

页面状态设计：只需要一个scrollY的 Animated.Value，其余全部由它派生。

4.2 核心代码实现

代码是用 React Hooks 写的，重点逻辑集中在useRef和interpolate上。先创建动画值：

import React, { useRef } from 'react'; import { Animated, ScrollView, View, Text, StyleSheet, StatusBar, } from 'react-native'; const HEADER_HEIGHT = 260; const TAB_HEIGHT = 48; const AnimatedScrollView = Animated.ScrollView; const Demo = () => { const scrollY = useRef(new Animated.Value(0)).current; // 头部图片高度和透明度 const headerHeight = scrollY.interpolate({ inputRange: [0, 120], outputRange: [HEADER_HEIGHT, 60], extrapolate: 'clamp', }); const headerOpacity = scrollY.interpolate({ inputRange: [0, 80, 120], outputRange: [1, 0.4, 0], extrapolate: 'clamp', }); // 背景层视差 const bgTranslateY = scrollY.interpolate({ inputRange: [0, 120], outputRange: [0, 40], extrapolate: 'clamp', }); // 标题栏淡入 const navOpacity = scrollY.interpolate({ inputRange: [0, 100, 160], outputRange: [0, 0.2, 1], extrapolate: 'clamp', }); let tabFixed = false; // 这个变量在组件里不能直接同步滚动状态，下面会改成 Animated 方案 // ... };

注意上面代码里我留了一个坑：tabFixed这个变量没法在渲染过程里根据scrollY实时变化。正确做法是让 Tab 本身也用动画驱动。一个比较稳妥的思路是：把整个 ScrollView 的 contentContainer 设计成上大下小，Tab 的位置用 transform 计算。但这样做会牵扯到复杂的手动计算，更简单的方案是在 ScrollView 外层套一个容器，把 Tab 放在 ScrollView 外面，这样 Tab 天然吸顶，只是需要判断“什么时候点亮吸顶样式”。

判断逻辑用onScroll的 listener 来完成。注意 listener 里不要直接调用setState，否则高频率 setState 会让整个列表卡到起飞。最佳实践是把“是否吸顶”也变成一个 Animated.Value，用插值器控制样式变化，这样整个过程都是声明式的：

const tabElevation = scrollY.interpolate({ inputRange: [0, 120], outputRange: [0, 4], extrapolate: 'clamp', });

然后在 Tab 容器上绑定阴影和背景色：

<View style={[ styles.tabWrap, { shadowOpacity: tabElevation.interpolate({ inputRange: [0, 4], outputRange: [0, 0.12], }), borderBottomWidth: tabElevation.interpolate({ inputRange: [0, 4], outputRange: 0, }), }, ]} > <Text style={styles.tabItem}>推荐</Text> <Text style={styles.tabItem}>热门</Text> <Text style={styles.tabItem}>关注</Text> </View>

听起来有点绕，但核心思想是：不要让状态参与视觉反馈，让 Animated.Value 直接参与视觉反馈。状态只用于和渲染无关的逻辑，比如埋点上报。

4.3 完整渲染部分

接下来是 ScrollView 内部的布局。头部区域的高度、透明度、背景位移都由动画值驱动，注意 Animated.View 的嵌套层级：

<View style={styles.container}> <AnimatedScrollView onScroll={Animated.event( [{ nativeEvent: { contentOffset: { y: scrollY } } }], { useNativeDriver: false } )} scrollEventThrottle={16} contentContainerStyle={styles.scrollContent} > <Animated.View style={[styles.cover, { height: headerHeight }]}> <Animated.View style={[styles.coverBg, { transform: [{ translateY: bgTranslateY }] }]} /> <Animated.Text style={[styles.coverTitle, { opacity: headerOpacity }]}> 城市漫游指南 </Animated.Text> </Animated.View> <View style={styles.body}> {Array.from({ length: 12 }).map((_, i) => ( <View key={i} style={styles.card}> <Text style={styles.cardTitle}>内容区块 {i + 1}</Text> <Text style={styles.cardDesc}> 这是用于测试滚动性能的占位内容，渲染足够多的节点， 才能暴露出 OpenHarmony 上 ScrollView 的真实帧率表现。 </Text> </View> ))} </View> </AnimatedScrollView> <View style={styles.tabWrap}> <Text style={styles.tabItem}>推荐</Text> <Text style={styles.tabItem}>热门</Text> <Text style={styles.tabItem}>关注</Text> </View> <Animated.View style={[styles.navBar, { opacity: navOpacity }]}> <Text style={styles.navTitle}>城市漫游指南</Text> </Animated.View> </View>

这里有个关键细节：Tab 放在 ScrollView 外部，意味着它天然吸顶。这是实现吸顶最不容易出 Bug 的方式。如果你把 Tab 放在 ScrollView 内部，想靠监听滚动距离改样式，会面临“一瞬间的滚动事件没触发导致 Tab 位置闪烁”的问题。外部容器的方案则完全避免了这个情况。

4.4 样式部分

样式文件比较常规，但有几个点值得注意。背景图用overflow: hidden裁剪，避免背景位移时溢出封面区域；封面标题设置绝对定位，让它浮在背景上；卡片列表加一点圆角和阴影，视觉上更像真实列表页：

const styles = StyleSheet.create({ container: { flex: 1, backgroundColor: '#f5f5f9' }, scrollContent: { paddingBottom: 40 }, cover: { justifyContent: 'flex-end', backgroundColor: '#333', overflow: 'hidden', }, coverBg: { position: 'absolute', left: 0, right: 0, top: 0, bottom: -60, backgroundColor: '#3a7bd5', }, coverTitle: { margin: 16, fontSize: 28, fontWeight: '700', color: '#ffffff', zIndex: 2, }, body: { paddingHorizontal: 12 }, card: { backgroundColor: '#ffffff', marginTop: 12, padding: 16, borderRadius: 10, shadowColor: '#000', shadowOpacity: 0.05, shadowRadius: 8, shadowOffset: { width: 0, height: 2 }, elevation: 2, }, cardTitle: { fontSize: 16, fontWeight: '600', color: '#1a1a1a' }, cardDesc: { fontSize: 13, color: '#666', marginTop: 6, lineHeight: 20 }, tabWrap: { flexDirection: 'row', backgroundColor: '#fff', borderTopWidth: StyleSheet.hairlineWidth, borderTopColor: '#e5e5e5', height: 48, }, tabItem: { flex: 1, textAlign: 'center', lineHeight: 48, fontSize: 15, color: '#333', }, navBar: { position: 'absolute', top: 0, left: 0, right: 0, height: 56, backgroundColor: '#fff', justifyContent: 'flex-end', alignItems: 'center', paddingBottom: 8, }, navTitle: { fontSize: 17, fontWeight: '600', color: '#1a1a1a' }, });

注意：elevation: 2只对 Android 生效，OpenHarmony 上阴影渲染依赖shadowColor、shadowOpacity等属性组合。如果发现卡片没有阴影，不用纠结，这是渲染差异，不影响功能。

4.5 为什么 useNativeDriver 只能用 false

这个点上值得多说一句。在 React Native Web、Android、iOS 上，useNativeDriver: true会把动画交给我原生动画驱动模块，在 UI 线程执行，避免 JS 线程的性能瓶颈。但在 react-native-harmony 的现状下，原生驱动模块还没有完整覆盖所有动画属性，尤其transform和opacity之外的那些属性。强行开启会在启动时报类似这样的警告：

useNativeDriver is not supported because the native animated module is missing

即使不报错，动画也可能不生效。我在 OpenHarmony 上统一用false，配合前面说的“插值器 + clamp + 轻量回调”，帧率体验勉强能接受。如果你的业务里动画特别复杂，可以考虑把部分动画逻辑下沉到 ArkUI 侧的原生组件，但这已经超出 RN 的范畴了。

5. 常见问题与排查技巧实录

5.1 问题速查表

把我在 OpenHarmony 上跑 ScrollView 动画遇到过的典型问题整理成了一张表，方便你直接对照。

5.2 启动白屏：OpenHarmony 上比 Android 难查十倍

很多人在 OpenHarmony 上遇到的第一个拦路虎就是白屏。白屏的原因其实分几类，但 OpenHarmony 上的报错不像 Android 那么完整，经常只给你一段“Script loading failure”就没了下文。

我的排查路径是：

1. 先跑一次 Debug 模式，看 Metro 列表里有没有设备连上来。如果 Metro 没有响应，多半是端口没通；
2. 确认端口通了，再看 Logcat 里有没有 JS 报错。OpenHarmony 的日志 tag 通常不是ReactNativeJS，而是 ArkTS 层的日志，需要全局搜React关键词；
3. 如果是 Release 模式，检查 bundle 文件大小，如果只有几百字节，说明打包失败或资源读取失败；
4. 最后确认文件路径。react-native-harmony要求 bundle 放在特定目录，放错了就是白屏。

还有一个容易忽略的问题：权限。在 OpenHarmony 的module.json5里如果没有声明ohos.permission.READ_USER_STORAGE之类的权限，Release 模式读取 bundle 时会被系统拒绝，但错误日志不会直接告诉你“权限不足”。我当时在这上面卡了半天，最后手动加了权限才正常。

5.3 动画卡顿：OpenHarmony 上 JS 线程比你想的更脆弱

OpenHarmony 设备（尤其是 RK3568）的 CPU 性能比主流 Android 手机弱不少。所以同样的动画代码，Android 上能跑 60 帧，OpenHarmony 上可能只有 30 帧甚至更低。这不是 React Native 的锅，也不是动画写错，纯粹是硬件性能差异。

排查动画卡顿，我习惯开帧率监控。OpenHarmony 的开发者工具里有 GPU 和 CPU 的 Profiler，可以直接看渲染管线的耗时。实际操作中，我发现瓶颈往往不在 JS 线程，而在渲染层：当 ScrollView 里的视图数量超过 30 个时，帧率会明显下降。这时候最有效的优化是减少视图层级和数量：

• 扁平化 View 嵌套，能用 Text 组合的不要包多层 View；
• 对长列表使用windowSize参数控制预渲染距离；
• 卡片样式尽量简单，阴影和复杂背景色会显著增加合成压力。

windowSize的用法如下：

<AnimatedScrollView windowSize={5} initialNumToRender={6} maxToRenderPerBatch={6} ... >

windowSize默认是 21（表示渲染可视区域上下各 10 屏的内容），在 OpenHarmony 上我调成了 5，渲染压力小了很多，滚动也明显变顺滑。另一个技巧是关掉removeClippedSubviews，在 OpenHarmony 上这个属性开启后反而可能会导致闪块问题。

5.4 滚动事件不触发：别被默认值忽悠了

scrollEventThrottle这个属性如果不设置，默认是 0。在 Android 和 iOS 上，0 意味着“尽可能频繁地触发事件”，通常也不会有什么问题。但在 OpenHarmony 上，设置为 0 时，事件系统可能会把事件节流到极低的频率，甚至某些版本直接不触发。

我从踩坑中总结出的结论是：任何 OpenHarmony 上依赖 onScroll 的动画，都要显式设置scrollEventThrottle，不要再依赖默认值。16 是个好的起点，如果滚动动画还不够细腻，可以往下降到 8；如果卡顿明显，就升高到 24 或 32。这个值需要结合具体设备和动画复杂度来调。

6. 滚动动画的性能调优：OpenHarmony 上必须多做的几件事

6.1 用 transform 代替布局属性

OpenHarmony 的 ArkUI 渲染引擎对 transform 和 opacity 的处理是走合成器的，速度最快；而 width、height、top、left 这类布局属性一旦变化，会触发重新测量和布局，性能消耗大得多。

所以，能改 transform 就不要改宽高。比如头部收缩效果，我第一版是直接改height，确实会卡；改成transform: [{ scaleY: ratio }]后流畅了不少。不过要注意，缩放 transform 会导致子元素也跟着缩放，视觉上会“变形”。更聪明的做法是让头部容器高度不变，把内部图片的高度改小，外部只做 translateY 位移。这样既省了布局计算，又不会让文字变形。

这就是为什么前面示例代码里的封面用了height驱动，但在实际项目里我更推荐把“封面高度变化”改成“封面内部图片做 translateY + scale”。具体取舍要看效果需求，但性能排序永远是transform > opacity > 布局属性。

6.2 减少 JS 线程的无效工作

React Native 在 OpenHarmony 上的 JS 线程承载能力有限，所以能不在 JS 线程做的事就不要放进来。最常见的无效工作是：

• 滚动事件回调里执行复杂计算或 JSON 解析；
• 滚动事件回调里调用console.log，这在 Debug 模式下会严重拖垮性能；
• 滚动事件回调里每次都创建新对象，比如contentOffset: { y: scrollY }这种写法，其实每次事件都会 new 一个对象，累积多了就是内存和 GC 压力。

我自己会用一个固定的对象引用，避免每次滚动事件都重新创建对象。虽然 Animated.event 内部会自动处理，但要写自定义 listener 时，我会把回调函数用useRef包一层，确保每次渲染都是同一个引用。

6.3 实战：Profile 工具看瓶颈

最后再分享一个很实用的操作。如果动画卡顿，不要猜，直接用 OpenHarmony 的 SmartPerf Host 分析。操作路径是：

1. 打开 SmartPerf Host，连接设备；
2. 采集一段滚动操作的 Trace；
3. 查看主线程和渲染线程的耗时分布。

我做过一次分析，发现卡顿的根源竟然是图片加载：每张卡片都加载了大尺寸网络图，导致合成器每帧都要处理多张图。优化方式很简单：缩略图使用Image的尺寸裁剪能力，压缩到卡片实际显示大小；列表滚动时暂停图片加载，停止滚动后再继续加载。

这个经验在与 RN 结合时也成立。ScrollView 内部的图片组件，尽量设置固定的width和height，避免图片加载完再回调布局变化。固定的宽高能让渲染引擎提前布局，减少滚动时的“跳动”现象。

7. 一些碎碎念：这个方案能走多远

OpenHarmony 上跑 React Native，注定是一条“带点实验性质”的路。如果你问我值不值得做，我的看法是：如果团队已经有成熟的 RN 代码库，迁移成本远小于用 ArkUI 重写，那就值得。但如果是从零开始的新项目，建议优先考虑 ArkUI，毕竟原生方案的性能和生态支持都要好得多。

ScrollView 滚动动画只是这条路上的一个点，但它的价值在于验证了整条链路：RN 组件到 ArkUI 的映射、事件系统的联通、JS 线程和渲染线程的协作。把这个点吃透了，后面做 FlatList 虚拟列表、做图片懒加载、做自定义原生组件，都会顺利很多。

设备树选择这件事也不用害怕。回到开头的问题：如果你用的是标准 RK3568 开发板，出厂镜像里默认的 dtb 就是最靠谱的选择；如果你用的是第三方板子，别自己瞎编 dtb，直接联系板卡厂商要适配资源。系统层的问题尽量少花时间，把精力留在业务层才是正经事。

最后的最后，分享一个操作习惯：每次调 ScrollView 动画参数时，我会把scrollEventThrottle、windowSize、插值器这三个字段单独抽到一个配置常量里，方便反复调试。你永远不会知道自己调了多少轮参数才能找到那组“刚刚好”的值，但有一个集中的配置项，会让你对这个过程不那么烦躁。