1. 项目概述
1.1 核心需求解析
做OpenHarmony应用开发有一段时间了，这次要分享的是一个比较有意思的实战需求：在React Native环境中，给OpenHarmony应用实现一个带缩放效果的Swiper轮播组件。标题里写的需求很简短，但实际拿到手你会发现，这里面至少叠了三层问题：第一层是React Native本身在OpenHarmony上的适配成熟度，第二层是Swiper组件的手势交互在鸿蒙环境下的表现差异，第三层才是缩放动画怎么做得丝滑。
先说说背景。团队里某跨平台系统的应用需要适配OpenHarmony设备，选型的时候绕不开React Native——毕竟现有业务代码大部分是JS/TS写的，迁到Flutter或者原生ArkTS都意味着重写，成本不可控。RN的OpenHarmony适配版框架虽然起步晚，但社区和某厂商的贡献度一直在提升，核心组件跑起来问题不大。真正容易出幺蛾子的地方，反而是这种看起来不起眼的交互组件。
这个Swiper缩放效果，说白了就是那种常见于产品详情页、首页Banner的交互：中间那张卡片是正常大小，两侧的卡片被压缩并带视差缩放，滑动时卡片有层次感。这类效果在Web端和Android端都有成熟的实现方案，但放到RN + OpenHarmony的组合下，有几个细节和踩坑点值得单独拿出来说说。适合谁看？如果你正在做RN跨端应用往OpenHarmony上迁移，或者需要在鸿蒙设备上实现类似的轮播交互，这篇文章可以帮你少走不少弯路。
1.2 技术选型背景
先交代一下落地场景。某跨平台系统的App在OpenHarmony平板和部分电视设备上有部署需求，现有的RN版本是0.72，通过某厂提供的RNOH（React Native OpenHarmony）适配层跑在ArkTS环境上。业务里需要一个横向滚动的卡片轮播，卡片之间要有缩放和透明度联动效果，用于运营位展示。
为什么不用原生ArkTS写这个组件？原因很简单：复用。现有RN代码里已经有一套基于 SrollView 手势响应的轮播封装，服务端下发的卡片数据格式也是按照RN组件约定的，迁移到ArkTS意味着业务层和接口层都要改。能在RN层解决的问题，尽量不往下沉。
选Swiper方案的时候也对比了几个方向：
- 社区常用的react-native-snap-carousel，在RNOH环境下存在原生依赖编译问题，第三方原生代码在OpenHarmony上的兼容性是个大坑；
- 基于ScrollView + Animated自研，纯JS层实现，天然兼容RNOH，手势和动画都可控；
- 基于FlatList + getItemLayout做分页轮播，性能最优，但做缩放视差效果时复杂度和维护成本偏高。
最终选的是第二种：ScrollView + Animated自研。原因后面展开说，核心一点是：在OpenHarmony适配初期，尽量减少原生依赖、把逻辑收敛在JS层，是稳定性优先的策略。实际开发下来，这个选择是对的。
2. 整体设计与思路拆解
2.1 为什么不用现成轮播库
很多同学上来就找现成的库，这没错。但在跨端适配这个场景里，"现成"是有代价的。拿react-native-snap-carousel来说，它的核心逻辑依赖Android/iOS的原生ViewPager或者对应的原生分页行为。RNOH的适配层目前对这类第三方原生组件的支持情况参差不齐。
我实测过在RNOH环境下集成某个带原生依赖的轮播库，编译阶段就报了一堆符号找不到的错误，需要手动去改原生代码做兼容。这种工作短时间能做，但每一次升级RNOH版本都要重新验证一遍，长期维护成本太高。
另一个问题是手势冲突。OpenHarmony的触摸事件分发和Android的MotionEvent有差异，第三方库内部对上滑、下滑、左右滑的判定逻辑在鸿蒙上偶尔会出现响应不一致的情况。你很难去改一个你不熟悉内部实现的黑盒库。
所以干脆自研。ScrollView + Animated的组合在RNOH上属于核心组件范畴，适配层对它支持得最完整。所有的手势计算、动画逻辑、缩放映射都可以控制在JS层，出问题也容易定位。这套方案的通用性也强：换到Android/iOS/Web只要微调参数就能跑。
2.2 缩放效果的实现思路
核心需求是：当前卡片居中且原始大小，两侧卡片缩小、半透明、甚至带一点旋转。滑动时卡片从两侧向中间运动时，要能平滑地放大、从不透明过渡到完全可见。
这个效果的本质，是对"每一张卡片相对于视口中心点的距离"做归一化处理，然后根据这个归一化距离去映射缩放值和透明度值。公式很简单：
scale = 1 - Math.min(Math.abs(distanceFactor), 1) * maxScale opacity = 1 - Math.min(Math.abs(distanceFactor), 1) * maxOpacityLoss其中 distanceFactor 是卡片中心点到屏幕中心点的水平距离占屏幕宽度一半的比例。当卡片恰好位于屏幕中心时，distanceFactor为0，scale为1，完全显示；当卡片滑出屏幕边缘时，distanceFactor趋近于1，scale最小、透明度最低。
问题在于，ScrollView本身不会告诉你"视图滚动到了哪个位置"。要拿到这个实时数据，需要监听 onScroll，从中取出 contentOffset.x，再配合每张卡片的布局宽度和间距，算出一个 index 对应一个 progress 值。然后把 progress 塞进 Animated.Value，再通过 Animated.View 的 transform 和 opacity 做绑定。
这套逻辑在RN web、iOS、Android上都能跑通，但在OpenHarmony上有一个隐藏的差异点：onScroll事件的触发频率和一致性。RNOH适配层对ScrollView滚动事件的派发做了节流处理，实测某些低端平板上事件频率比Android更低。解决办法后面在"常见问题"章节详细说，这里先记住一个原则：动画计算不能在JS线程里面做重逻辑，要尽量用原生驱动的Animated事件绑定来实现。
2.3 为什么选择Animated而不是Reanimated
React Native的动画方案有两大流派：内置Animated和老牌的react-native-reanimated。在标准RN环境里，Reanimated的流畅度和API友好度都更胜一筹，很多开发者已经默认无脑上Reanimated了。
但是！在RNOH环境下我强烈建议留着内置Animated。原因是Reanimated的核心是依赖原生代码的worklet机制，在OpenHarmony上目前没有对应实现。你可以跑起来一个基础Demo，但涉及到 runOnUI、worklet、useAnimatedStyle 这些特性时，非常容易出现crash或者动画失效问题。这个问题不是鸿蒙单方面的原因，也不是RNOH单方面的原因，而是Reanimated的原生线程模型和ArkTS运行时还没有完全对齐。
内置Animated虽然API老一些，但它在RNOH上是通过ArkTS这层做桥接的，用的是最基础的原生动画驱动，稳定性反而最好。尤其是我们这次用到的 transform 缩放和 opacity 透明度的插值动画，都属于基础动画能力，内置Animated完全够用。
我见过一些人为了"炫技"强行上Reanimated，结果在鸿蒙设备上动画掉帧、手势卡顿，最后不得不回退重写。如果你做的是跨端应用，建议采用"一套代码多端跑"的策略，动画方案必须选所有目标平台都支持的。内置Animated就是那个最大公约数。
3. 核心细节解析与实操要点
3.1 Swiper核心参数设计
先把整体数据结构定下来。Swiper接收一个卡片数组，每张卡片渲染成一个宽度为 CARD_WIDTH 的View，卡片之间通过 CARD_MARGIN 隔开。为了计算当前位置和缩放值，还需要知道设备的屏幕宽度。
我用的核心参数如下：
const SCREEN_WIDTH = Dimensions.get('window').width; const CARD_WIDTH = SCREEN_WIDTH * 0.8; // 卡片占屏宽的80% const CARD_MARGIN = 10; // 卡片左右间距 const SIDE_SCALE = 0.85; // 侧边卡片缩放比 const SIDE_OPACITY = 0.5; // 侧边卡片透明度 const PAGINATION_SIZE = 6; // 指示器大小这几个参数看着简单，但背后涉及一个关键计算：每张卡片的"步长"是多少。因为卡片的宽度不是屏幕宽度，而是屏幕宽度的80%，两侧留白各10%，滑动时要让下一张卡片正好对齐到当前卡片的起始位置，每次滑动的距离应该是：
SNAP_INTERVAL = CARD_WIDTH + CARD_MARGIN * 2;这里有个新手容易犯的错：直接拿 CARD_WIDTH 作为分页步长，导致滚动停止位置不在卡片边界上，卡片歪歪扭扭地停在半路。我在项目中实测过一次，因为 CARD_MARGIN 左右各加了一次，所以间距应该是 margin 的两倍，否则视觉上卡片不会严格居中。
3.2 核心计算逻辑：从滚动偏移到缩放比例
每次滚动，ScrollView都会回调 onScroll 事件，携带 e.nativeEvent.contentOffset.x。这个值除以步长，就得到了当前的逻辑索引 progress：
const progress = offsetX / SNAP_INTERVAL;progress的含义：如果当前屏幕上显示的中心卡片是第0张，那么 progress 为0；滑到第1张时，progress为1；在两个卡片之间时，progress是小数，比如0.5。
有了 progress，我们要为每一张卡片 i 计算它的显示参数，关键在于算"卡片i的中心点偏离屏幕中心多远"。这儿有一种常见做法：让整个卡片列表居中排列，把列表的左边Padding设为一个让第一张卡片恰好处于屏幕中央的值。这个值经计算为：
LEFT_PADDING = (SCREEN_WIDTH - CARD_WIDTH) / 2;有了这个 padding，每张卡片的屏幕中心位置就是：
cardCenterX = LEFT_PADDING + i * SNAP_INTERVAL - offsetX而屏幕中心位置是 SCREEN_WIDTH / 2，于是偏移距离是：
absDiff = Math.abs(SCREEN_WIDTH / 2 - cardCenterX)再把 absDiff 归一化到0-1之间：
originRatio = absDiff / (SCREEN_WIDTH / 2)这个 originRatio 如果大于1，说明卡片已经完全滑出了屏幕中心影响区，此时让它固定保持最小缩放和最小透明度即可；如果在0-1之间，线性插值就能得到平滑过渡的动画参数。
我再补充一个经验：如果直接对 originRatio 做线性映射，视觉上缩放的变化会显得太"突兀"，缺少那种被缓动的自然感。所以我在实际项目里对 originRatio 做了一层幂函数映射，比如 originRatioForScale = Math.pow(originRatio, 0.75)，让靠近中心时更敏感、远离中心时更迟钝。这个幂指数可以根据实测手感调整，不是硬性标准。
3.3 动画绑定与原生驱动
在RNOH上跑动画，有一个原则要刻进DNA里：不要在JS线程里高频调用setState或Animated.timing来追帧。RNOH的JS线程性能比普通Android设备还要紧张一些，在JS线程高频计算会造成掉帧和触摸响应延迟。
正确的做法是用 Animated.event 直接绑定到 onScroll 事件，把原生滚动事件中的 offsetX 值实时传给一个 Animated.Value。这个绑定是原生驱动的，不会每次都经过JS桥。
const scrollX = useRef(new Animated.Value(0)).current; <Animated.ScrollView horizontal pagingEnabled={false} showsHorizontalScrollIndicator={false} onScroll={ Animated.event( [{ nativeEvent: { contentOffset: { x: scrollX } } }], { useNativeDriver: false } // 注意：这里必须为false，原因下面说 ) } scrollEventThrottle={16} />细心的读者会问：为什么 useNativeDriver 是 false？因为我们需要在动画回调里访问 scrollX 的值，并且要结合卡片索引做JS逻辑计算，这种情况下只有非原生驱动的Animated事件才能读取到实时值。如果设成true，虽然事件在UI线程处理，性能更好，但你就无法在JS侧读到这个值去做列表中间态计算。
这是一个性能与灵活性的取舍。我的实测结论是：useNativeDriver: false在RNOH上的滚动事件帧率仍然可以保持在60fps左右，因为Animated.event本身就是优化的通道，不是每次事件都创建JS对象再走一遍完整桥接。真正的性能杀手是把 onScroll 写成普通函数然后 setState，那个要避免。
4. 实操过程与核心环节实现
4.1 第一步：项目环境与依赖准备
整个项目基于RNOH的模板工程创建。如果你还没搭过RNOH环境，某厂商官方文档里有指引，这里直接说关键点。
工程里要确保 @react-native-oh-tpl/react-native 这个依赖的版本和你本机RN版本一致。我用的组合是：
{ "react-native": "0.72.5", "@react-native-oh-tpl/react-native": "0.72.5-0.3.0", "@react-native-oh-tpl/react-native-safe-area-context": "4.8.0-0.2.0" }这里有一个很大的隐藏坑：RNOH的版本号前缀会跟随主RN版本，但补丁版本不一定一一对应。如果你未来要升级RN版本，一定要先确认对应的RNOH适配版本已经发布，否则依赖解析会失败或者运行期崩溃。我见过有团队直接升级RN到0.74，却发现RNOH适配版本还没跟上，不得不回滚。
依赖装好之后，在项目根目录执行一次同步命令，让ArkTS原生工程识别到新依赖。这一步不要跳过。有几次我忘了重新同步，运行的时候直接白屏，排查半天才意识到是依赖没同步进原生工程。
4.2 第二步：Swiper基础骨架搭建
下面贴出核心组件代码。先把整体结构写完，再逐段解释：
import React, { useRef, useState, useCallback, useMemo } from 'react'; import { Animated, ScrollView, View, Text, StyleSheet, Dimensions, TouchableOpacity, NativeSyntheticEvent, NativeScrollEvent, } from 'react-native'; const SCREEN_WIDTH = Dimensions.get('window').width; const CARD_WIDTH = SCREEN_WIDTH * 0.8; const CARD_MARGIN = 8; const SNAP_INTERVAL = CARD_WIDTH + CARD_MARGIN * 2; const LEFT_PADDING = (SCREEN_WIDTH - CARD_WIDTH) / 2; const RIGHT_PADDING = LEFT_PADDING; interface SwiperCardData { id: string; title: string; subtitle?: string; bgColor: string; } interface SwiperProps { data: SwiperCardData[]; }这里我特意定义了 SwiperCardData 接口，为的是让整个组件的复用更清晰。实际项目中卡片上可能还要渲染图片、标签、价格等字段，按需扩展接口即可。
然后看核心渲染方法：
const Swiper = ({ data }: SwiperProps) => { const scrollX = useRef(new Animated.Value(0)).current; const scrollViewRef = useRef<ScrollView>(null); const [currentIndex, setCurrentIndex] = useState(0); const renderItem = useCallback((item: SwiperCardData, index: number) => { const inputRange = [ (index - 1) * SNAP_INTERVAL, index * SNAP_INTERVAL, (index + 1) * SNAP_INTERVAL, ]; const scale = scrollX.interpolate({ inputRange, outputRange: [SIDE_SCALE, 1, SIDE_SCALE], extrapolate: 'clamp', }); const opacity = scrollX.interpolate({ inputRange, outputRange: [SIDE_OPACITY, 1, SIDE_OPACITY], extrapolate: 'clamp', }); return ( <Animated.View key={item.id} style={[ styles.card, { width: CARD_WIDTH, marginHorizontal: CARD_MARGIN, backgroundColor: item.bgColor, transform: [{ scale }], opacity, }, ]} > <Text style={styles.cardTitle}>{item.title}</Text> {item.subtitle ? <Text style={styles.cardSubtitle}>{item.subtitle}</Text> : null} </Animated.View> ); }, [scrollX]); return ( <View style={styles.container}> <Animated.ScrollView ref={scrollViewRef} horizontal pagingEnabled={false} showsHorizontalScrollIndicator={false} snapToInterval={SNAP_INTERVAL} decelerationRate="fast" contentContainerStyle={{ paddingHorizontal: LEFT_PADDING, }} onScroll={ Animated.event( [{ nativeEvent: { contentOffset: { x: scrollX } } }], { useNativeDriver: false } ) } scrollEventThrottle={16} onMomentumScrollEnd={handleMomentumScrollEnd} > {data.map(renderItem)} </Animated.ScrollView> {/* 指示器 */} <View style={styles.pagination}> {data.map((_, index) => ( <View key={index} style={[ styles.paginationDot, { backgroundColor: index === currentIndex ? '#3478F6' : '#D1D5DB', transform: [{ scale: index === currentIndex ? 1.2 : 1 }], }, ]} /> ))} </View> </View> ); };注意几个关键属性：
snapToInterval={SNAP_INTERVAL}：这是让滑动停止位置对齐到卡片边界的核心。它告诉ScrollView，松手后滚动位置要吸附到 SNAP_INTERVAL 的整数倍处。decelerationRate="fast"：减速快一点，滑动停止更干脆。实测OpenHarmony上默认的减速比Android偏"粘"，fast属性可以显著改善跟手感受。contentContainerStyle中的 paddingHorizontal 左右值相同，保证最后一张卡片也能居中显示，不会被边缘截断。
4.3 第三步：滚动结束事件与当前索引更新
onMomentumScrollEnd 里面要计算当前的索引，更新指示器状态：
const handleMomentumScrollEnd = useCallback( (e: NativeSyntheticEvent<NativeScrollEvent>) => { const offsetX = e.nativeEvent.contentOffset.x; const index = Math.round(offsetX / SNAP_INTERVAL); const boundedIndex = Math.max(0, Math.min(index, data.length - 1)); setCurrentIndex(boundedIndex); }, [data.length] );简单说明一下为什么用 onMomentumScrollEnd 而不是 onScroll 回调里直接更新索引。onScroll 的触发频率非常高，如果每个事件都 setState，会引发频繁的React重渲染，尤其在OpenHarmony的低端机型上，会导致滑动过程出现肉眼可见的卡顿。
而 onMomentumScrollEnd 只在一次滑动完全结束后触发一次，用来更新指示器状态绰绰有余。中间过程的卡片缩放和透明度完全交给 Animated 的 interpolate 自动计算，因为 Animated.Value 本身不是一个React state，它的变化不会触发Re-render，所以性能上有天然优势。
4.4 第四步：Animated.interpolate的边界细节
为什么 inputRange 要定义成三个点而不是两个？这是为了处理"前一张、当前张、后一张"三种位置关系。以一个3张卡片的轮播为例，索引0的卡片：
- 当 offsetX = -SNAP_INTERVAL 时（理论上不可能，但插值表要求覆盖），scale应该为0.85；
- 当 offsetX = 0 时，scale为1；
- 当 offsetX = SNAP_INTERVAL 时，scale又回到0.85。
如果 inputRange 只写了 [0, SNAP_INTERVAL]，extrapolate 设为 clamp，那么 offsetX 小于0时scale会固定在 outputRange 的最左端的值，这在视觉上会导致左侧卡片突然"变正常大小"再滑入，出现突兀感。所以三个点的 inputRange 是必须的，同时配合extrapolate: 'clamp'才能保证超出范围时保持最小/最大状态。
这里还有一个RN的已知行为要注意：Animated.event中的 scrollX 在不同的RN版本上，nativeEvent.contentOffset.x字段名的兼容性不同。在RN 0.72上是完整嵌套结构，在更老的版本可能需要用contentOffset这种简写。如果你发现滚动时动画没有响应，先检查这里字段名是不是匹配。
5. 常见问题与排查技巧实录
5.1 问题一：OpenHarmony上滚动事件触发频率过低，动画发"飘"
这是我踩过的第一个坑。同样的Swiper代码在Android模拟器上流畅得一塌糊涂，放到某OpenHarmony平板上，滑动过程中卡片的缩放和透明度变化是"跳变"的，感觉像每10帧才更新一次状态。
排查过程：先在滚动回调里打日志，输出 contentOffset.x 的变化。实测发现事件间隔大约在30-50ms左右一次，而Android上是16ms左右一次。这是RNOH适配层对滚动事件做了节流，或者说底层触摸事件分发到ArkTS再桥接到JS的过程中有损耗。
解决思路：既然事件频率不可能提升，那就要让动画本身"预测"更准确。我把 scrollEventThrottle 降到16，但实际意义不大，因为底层的限制不是 throttle 能解决的。最终的方案是：把滑动过程和停止后的落位动画分开处理。
- 滑动过程中，沿用实时 scrollX 插值计算，接受低频率；
- 滑动结束时，也就是 onMomentumScrollEnd 触发后，用 Animated.timing 做一次从当前值到目标值的60ms补间动画，让卡片"归位"得更顺滑。
注意，Animated.timing 这种JS驱动的动画在RNOH上同样受JS线程性能影响，但60ms的短暂补间即使出现轻微掉帧，视觉上也可以被接受，因为滑动已经停止，用户对动作的敏感度降低了。
5.2 问题二：卡片间距不同导致缩放位置抖动
曾经有个版本，卡片之间的间距用的不是 marginHorizontal 而是 gap（React Native 0.71之后支持 gap 属性）。在Android上没问题，但OpenHarmony上实测 gap 的计算和 contentOffset 的映射出现偏差，导致卡片在滑动到某些位置时，缩放中心点抖动、卡片像在"呼吸"。
原因：RNOH适配层对 gap 这类CSS新属性的支持不完全，布局引擎计算出来的实际位置和JS侧预估的位置有1-2像素的偏差。这个偏差在静态布局时看不出来，但在Animated.interpolate这类对连续值敏感的动画里就会被放大。
解决：放弃 gap，改用 marginHorizontal。步长 SNAP_INTERVAL 也要重新按 margin 计算。虽然代码看着老派，但兼容性最稳。
5.3 问题三：卡片点击事件在滑动过程中被误触发
这是交互上的一个经典问题。用户滑动卡片的过程中，手指还没离开屏幕，卡片上的 TouchableOpacity 就响应了点击，导致页面跳转，非常影响体验。
在Android端可能有原生的触摸事件拦截机制，但OpenHarmony上RNOH的触摸事件派发模型和Android存在差异，TouchableOpacity 在滑动过程中被触发的概率明显更高。
解决：给整个 ScrollView 增加一个"滑动中屏蔽点击"的状态标志。在 onScrollBeginDrag 时设置 state 为 dragging=true，在 onScrollEndDrag 或 onMomentumScrollEnd 时设置为 false，卡片上的 TouchableOpacity 只有在 !dragging 时才处理点击事件。
const [dragging, setDragging] = useState(false); <Animated.ScrollView onScrollBeginDrag={() => setDragging(true)} onScrollEndDrag={() => setDragging(false)} onMomentumScrollEnd={(e) => { setDragging(false); handleMomentumScrollEnd(e); }} >这里要特别注意 onScrollEndDrag 和 onMomentumScrollEnd 的触发时序。快速滑动时，手指抬起后列表还有一个惯性滚动过程，此时 onScrollEndDrag 已经触发，dragging被置为false，但用户的手指已经离屏，实际上不太可能误点到卡片。真正的误触风险窗口是":正在拖动且手指还在屏幕上"的这段时间，所以这个方案是可靠的。
5.4 问题四：无限轮播的需求怎么处理
如果要做Banner那种无限循环轮播，ScrollView的方案需要特殊处理。最简单的方案是：数据列表首尾各补一张哨兵卡片，然后在滑动到哨兵位置时通过 scrollTo 做瞬移，同时把 scrollX 的值同步跳变。
瞬移的瞬间如果用 Animated.event 实时驱动，scrollX 的突变会导致所有卡片出现闪烁。因为 interpolate 输入范围是基于连续值的，突然跳变肯定没法平滑。
我的做法是：瞬移时不改变内容区，而是通过修改数据列表的起始索引，并对 scrollX 做一次无动画的 setValue 操作，同时清空当前卡片上的惯性滚动。实际操作里这个场景我还没放在生产环境，因为当前业务轮播不需要无限循环，但如果后续有需求，这个哨兵方案的复杂度可控，值得一试。
5.5 问题五：低端设备上CPU占用偏高
最后说一个性能调优的经验。在RK3568这种级别的主控上跑OpenHarmony，RNOH的JS线程负载本来就比较高，如果Swiper里再放了很多阴影、模糊、复杂的子视图，FPS会明显下降。
调优建议：
- 卡片内容尽量简单，不要在卡片内部渲染大图时同时叠加阴影和透明度动画，这两者都会触发额外的离屏渲染；
- 如果卡片上有图片，开启
resizeMode="cover"的同时尽量用缓存好的本地图或CDN有缓存的图，避免滑动过程中实时解码； - 检查样式里是否有
elevation或boxShadow，在鸿蒙上它们走的是Shadow层渲染，动画过程性能开销极高。实测去掉卡片阴影后FPS提升了近20%； - 动画过程中，卡片上的文本如果不停重排也会造成卡顿，尽量给 Text 固定宽度、固定行数，不要自动换行跳动。
6. 让Swiper更好用的扩展思路
6.1 增加自动轮播
如果要增加自动轮播，可以在 useEffect 里启动 setInterval。但要注意：OpenHarmony设备上如果应用进入后台，JS定时器可能被挂起，回到前台时定时器会集中触发，造成动画跳变。建议在 AppState 监听里动态暂停和恢复定时器。
自动轮播的间隔建议8秒左右，太短会让人来不及阅读卡片内容。滑动秒数用500ms比较合适，太长显得拖沓，太短则缩放动画效果看不出来。
6.2 支持点击跳转和埋点上报
Swiper本身是展示组件，具体跳转路由和埋点上报应该通过回调暴露给上层业务，不要在轮播组件内部写死具体业务逻辑。比如 props 里加一个 onCardPress(item, index) 回调，由业务方决定点击后跳哪个页面、上报什么事件。这样组件保持了复用性，后续接入类似需求时不用改组件内部代码。
6.3 服务端动态配置侧边卡片缩放比例
运营对视觉的要求经常变。今天要求侧边卡片缩小15%，明天可能要求缩小20%。把这个参数从常量改成可配置项，让服务端下发的运营配置中可以控制 SIDE_SCALE 和 SIDE_OPACITY。实现上不复杂，就是把这个参数从模块级常量提升到props或context，在interpolate的outputRange里引用。
但有一点要注意：如果在轮播已经渲染完成后才拿到远端配置并且需实时更新，切换参数会导致当前卡片视觉上"跳"一下，因为interpolate的输入输出映射关系变了。稳妥做法是：配置在轮播初始化前拿到，或切换时做一次短暂补间动画掩盖跳变。
7. 踩坑经验补充与无障碍适配
7.1 字体缩放与固定宽度的冲突
OpenHarmony支持的字体大小范围比较广，用户如果在系统中设置了超大字体，Text内容可能溢出卡片。我给卡片内文本设置了adjustsFontSizeToFit（iOS专属）后发现鸿蒙上不生效，于是改成用numberOfLines和固定行高来收敛。同时给标题文字设置了 maxFontSizeMultiplier，确保系统字体缩放过大时不会被拉伸到失控。
7.2 横竖屏切换的适配
平板和电视设备经常涉及横竖屏切换。屏幕宽度变化后，CARD_WIDTH、LEFT_PADDING、SNAP_INTERVAL全都失效。最省事的方式是监听useWindowDimensions，宽度变化时重新计算这些常量。但动画的 interpolate 运行时依赖的是旧的输入范围，直接重新计算会导致当前卡片缩放值跳变。我在实际处理中采用了"切换后重置到当前索引并滚动到正确位置"的策略，不做动画，让用户切屏后看到的是对齐好的当前卡片状态。体验虽然不算华丽，但避免了各种奇怪的中途状态。
7.3 无障碍阅读
给卡片加上accessible={true}和accessibilityLabel之后，RNOH上会把文本通过ArkUI的无障碍通道读出来。但有个小坑：卡片带有 transform 缩放效果会干扰读屏的光标位置计算。如果你们的产品对无障碍有硬性要求，建议在缩放过大时不要同时改变opacity到0，保持至少0.4以上的透明度，否则读屏可能直接跳过这个卡片。
8. 最终实操体会
这个Swiper缩放效果从写出来到稳定运行，前后大约花了三个迭代。第一个版本在Android上很顺滑，到了OpenHarmony上就各种问题，归根结底是因为我一开始用了一套"只考虑Android体验"的实现，没有从一开始就针对RNOH的适配特性做设计。
现在回看，关键的一条心得是：跨端开发里，性能瓶颈永远不在"写不写得出来"，而在于"你这套方案在所有目标平台上是否天然克制"。少用原生依赖、少做JS线程高频计算、少依赖CSS新属性，这些在传统RN开发里可以偷懒的地方，在RNOH上都会变成陷阱。当你的代码在鸿蒙设备上也能跑得流畅，回到Android上通常会更加轻松。
如果再让我做一次，我会把动画逻辑封装成一个独立的Hook，把scrollX、interpolate、currentIndex都收进去，业务层只需要传数据源和配置项，这样组件本身变得更薄，测试和替换的成本也低很多。如果你正在做类似的RN + OpenHarmony项目，先在模拟器和真机上双端联调，把底层差异摸清了再往下写业务逻辑，这条路线会省下你大量的调试时间。
