企业官网建设流程全解析

Reanimated 3 出来也有一段时间了，我陆陆续续在几个项目里把它和 Gesture Handler 搭配着用，说实话，用过之后很难再退回老方案。以前写 React Native 动画，最痛苦的事情就是怎么调都差那么点意思，掉帧、卡顿、手势跟手度不够，总是能被用户一眼看穿"这是个 JS 写的应用"。但换成 Reanimated 3 之后，很多以前需要原生代码才能做到的交互，现在纯 JS/TS 层面就能搞定，而且流畅度可以做到和原生几乎无差别。这篇文章不打算讲 API 文档，文档自己去看就行，我主要想聊聊这套组合拳背后的运行机制、我在实际项目中踩过的坑，以及一些能直接套用的优化思路。

1. 为什么 React Native 动画以前总是"卡"，问题出在哪

先说一个很多新手容易忽略的底层事实：React Native 应用的 JS 代码是运行在 JavaScript Core（Android 上可能是 V8 或 Hermes）里的，而界面渲染是在原生 UI 线程完成的。老版本的 Animated 库处理动画的方式，本质上还是靠 JS 线程不停地往原生侧发指令：每来一帧，JS 算好当前动画值，然后通过 bridge 告诉原生"你现在把这个 View 的 transform 改成这个值"。

这里就有两个致命瓶颈。第一个是 bridge 通信本身是异步且串行的，JS 线程把指令丢给 bridge，原生侧什么时候处理完、能不能在这一帧内处理完，JS 这边根本控制不了。第二个是 JS 线程本身还要处理业务逻辑、事件响应、状态更新，一旦某个环节稍微忙一点，动画帧就会被延误。所以当你在低端 Android 设备上跑一个复杂一点的缩放动画，立刻就会看到肉眼可见的掉帧，这就是典型的"JS 线程忙不过来了"。

我的理解是，Reanimated 3 解决的核心问题不是"把动画值算得更快"，而是彻底绕过 JS 线程——把动画逻辑直接搬到 UI 线程上去执行。UI 线程就是原生负责绘制的那条线程，动画计算和界面渲染在同一条线程上完成，省掉了 bridge 的来回通信，自然就丝滑了。

当然，Reanimated 1 和 2 也试图解决这个问题，但多少有点绕。1 代的做法是在原生侧声明式地描述动画，不灵活；2 代引入了 worklet 的概念，能把 JS 函数序列化后跑到 UI 线程，灵活性上来了，但搭建和调试体验还不够完善。Reanimated 3 在这个基础上做了一次大版本重构，核心架构更干净，和 React Native 新架构（Fabric/TurboModule）的配合也更紧密。如果你是新项目，直接上 Reanimated 3 基本没悬念。

1.1 一眼看懂 Reanimated 3 的线程模型

Reanimated 3 的模型理解起来并不复杂：它把所有动画逻辑分为两个世界，一个是 JS 世界，一个是 UI 世界。

在 UI 世界里，Reanimated 会维护自己的一个"影子节点树"，这棵树的节点对应着你界面上需要做动画的那些 View 的原生实例。你在 JS 里通过useSharedValue创建的一个值，实际上在内存中对应着两个存储位置：一个是 JS 线程这边的包装对象，一个是 UI 线程这边的真实数值存储。两个位置靠 Reanimated 内部的机制保持同步，但动画过程只在 UI 线程侧执行。

具体到执行流程，可以这样拆解：

1. 你在组件里调用withTiming或withSpring，告诉共享值"你要从当前值动画到某个目标值"。
2. Reanimated 立刻在 UI 线程启动一个动画驱动循环（Core Animation 的 display link 驱动，每帧回调一次）。
3. 每一帧的回调里，UI 线程直接算出当前动画值、更新原生 View 的样式属性，整个过程 JS 线程完全不用参与。
4. 只有当你需要在动画进行中读取当前值、或者动画结束要通知 JS 时，Reanimated 才会通过异步通道把值同步回 JS 侧。

关键在于第 3 步。这一步是纯原生的，没有 bridge 往返，没有 JS 参与，每一帧都有确定性的计算，不会因为 JS 线程忙而丢帧。

1.2 worklet 到底是什么，它凭什么能在 UI 线程跑

既然动画逻辑要搬到 UI 线程，那你怎么把"动画逻辑"传过去？比如你在 JS 里写的一个缓动函数、一个根据手势位移计算旋转角度的函数，这些逻辑怎么能在 UI 线程执行？

Reanimated 3 的方案是 worklet。worklet 本质上是一段被标记了的 JavaScript 函数，写法上就是在函数开头加一个'worklet'指令。在编译阶段，Reanimated 的 babel 插件会把这个函数体转换成一段可序列化的代码，然后在运行时通过 JS 引擎的 API（JavaScriptCore 的evaluateScript或者 Hermes 的类似能力）把它注入到 UI 线程的 JS 运行时中。

这里有个容易混淆的点：UI 线程上其实也有一个 JavaScript 运行时，它和 JS 主线程的运行时是独立的。worklet 函数被注入到这个 UI 运行时里，所以它能直接访问共享值、能直接修改原生 View 的样式。你在 worklet 里写的 JavaScript 代码，不用经过 bridge，直接在 UI 线程本地执行。

那什么样的代码能放进 worklet？原则上是任何不依赖外部 JS 闭包变量的纯逻辑。你不能在 worklet 里直接调用一个普通 JS 函数（除非这个函数也被标记为 worklet），也不能在 worklet 里使用useState这类 React 钩子。但你可以读取useSharedValue的值、调用 Reanimated 提供的动画函数、访问gesture对象上的一些属性（Gesture Handler 的手势事件处理函数默认就是 worklet 环境）。写多了你自然会有手感，哪些能写哪些不能写，边界其实很清楚。

2. Reanimated 3 的核心 API 是怎么帮我们实现"丝滑"的

我理解 Reanimated 3 的"丝滑感"主要来自三件套：共享值、动画函数、以及样式绑定。这仨配合起来，才构成了"UI 线程闭环"。

2.1 共享值：动画状态的最小单位

useSharedValue创建的共享值，就是你在 JS 和 UI 线程之间共享的动画状态。它和useState最大的区别是：修改共享值不会触发 React 重新渲染。这一点在做高频动画时非常关键——如果你用useState来存动画的当前进度，那每帧都要触发一次 React reconciliation，几十帧下来肯定卡死。而共享值是在 UI 线程上直接修改，React 组件不需要重新渲染，代价接近于零。

我在项目里的习惯是：所有和动画相关的中间状态，一律放共享值，不碰useState。只有动画结束后的最终状态（比如"当前展开还是收起"）需要给 React 层做逻辑判断时才用useState同步一次。

2.2 动画函数：把"过程"交给 UI 线程

withTiming和withSpring是 Reanimated 3 里最常用的两个动画函数。withTiming适合做线性、可预期的位移动画，比如抽屉滑入、弹窗出现；withSpring适合做带弹性效果的交互反馈，比如按钮按下、卡片被打飞。

从底层实现来看，withTiming在 UI 线程上创建一个基于时间的插值器，每一帧根据缓动函数（默认是 ease-in-out）算出插入值。withSpring的实现更有意思，它是在 UI 线程上跑一个弹簧物理模拟器，每一帧根据当前位移、速度、目标值和弹簧刚度（stiffness）、阻尼（damping）来迭代计算下一帧的值。因为弹簧是连续模拟的，所以动画永远不会"突兀地停"，观感上非常连贯。

用的时候有几个小细节很容易被忽略。比如withSpring的overshootClamping参数，默认是false，也就是说弹簧会越过目标值再弹回来。如果你不想让动画出现明显的过冲（比如一个进度条填充到尽头），可以设成true。再比如restDisplacementThreshold和restSpeedThreshold，它们控制弹簧什么时候判定为"到达终点"——默认情况下动画会在无限接近目标值时停止，但在某些场景下可能停得比较磨叽，适当调大这两个阈值可以让动画干脆利落地结束。

2.3 useAnimatedStyle：把共享值变成原生样式

useAnimatedStyle是连接共享值和原生 View 的桥梁。它接收一个 worklet 函数，函数内部可以读取多个共享值，并返回一个样式对象。这个函数会在每次相关共享值变化时在 UI 线程上重新执行，然后 Reanimated 直接把返回的样式对象应用到原生 View 上。

有一个很容易踩的坑是：在useAnimatedStyle里不要创建新对象，也不要做重的计算。因为这个函数每帧都会执行，而且是在 UI 线程的 JS 运行时里跑，如果计算量太大，还是会拖慢渲染。典型的问题是在 style 里做transform: [{ rotate: ... }]时频繁拼接字符串，或者用Array.map处理数据。尽量把可以预计算的东西提前算好，worklet 里只做最精简的运算。

另外，useAnimatedStyle里如果依赖了普通 JS 变量（不是共享值），需要用useDerivedValue或其它方式把变量"搬"进 worklet。因为 worklet 在编译时会捕获闭包变量，但如果那个变量是 React 每次渲染都会生成的新引用，就会出问题。我建议养成一个习惯：所有动画依赖的值，一律用共享值承载，普通变量只做一次性常量。

2.4 代码示例：一个可拖拽缩放的图片卡片

说了半天理论，来一个能直接拿去改的示例。这个需求很典型：一个可以拖拽移动、双指缩放旋转的图片卡片。

import React from 'react'; import { View, Image } from 'react-native'; import { Gesture, GestureDetector } from 'react-native-gesture-handler'; import Animated, { useSharedValue, useAnimatedStyle, withTiming, } from 'react-native-reanimated'; export default function DraggableImageCard({ imageUrl }) { // 保存图片的位置、缩放比例和旋转角度 const translateX = useSharedValue(0); const translateY = useSharedValue(0); const scale = useSharedValue(1); const savedScale = useSharedValue(1); const rotation = useSharedValue(0); const savedRotation = useSharedValue(0); // 组合手势：拖拽 + 双指缩放/旋转 const gesture = Gesture.Simultaneous( // 拖拽手势 Gesture.Pan() .onChange((event) => { translateX.value += event.changeX; translateY.value += event.changeY; }), // 捏合手势 Gesture.Pinch() .onUpdate((event) => { scale.value = savedScale.value * event.scale; }) .onEnd(() => { savedScale.value = scale.value; }) .onChange((event) => { rotation.value = savedRotation.value + event.rotation; }) .onEnd(() => { savedRotation.value = rotation.value; }) ); const animatedStyle = useAnimatedStyle(() => { return { transform: [ { translateX: translateX.value }, { translateY: translateY.value }, { scale: scale.value }, { rotate: `${rotation.value}rad` }, ], }; }); return ( <GestureDetector gesture={gesture}> <Animated.View style={animatedStyle}> <Image source={{ uri: imageUrl }} style={{ width: 240, height: 320, borderRadius: 12 }} resizeMode="cover" /> </Animated.View> </GestureDetector> ); }

这个例子看起来很简单，但里面有几个点值得细讲。

第一，Gesture.Pan()的.onChange里用event.changeX做增量移动，而不是event.translationX。如果用translationX，最终移动量会因为多个手势同时触发而出现叠加漂移。changeX是每次手势事件和上一次之间的位移差，天然适合增量累积。

第二，Gesture.Simultaneous让拖拽和捏合同时生效。如果不用 Simultaneous，Pan 手势会把 Pinch 手势的触摸给"抢走"，导致双指缩放时只有一个手指生效。这是新手最容易困惑的地方。

第三，缩放和旋转在结束时要把当前值存回savedScale和savedRotation。因为在.onUpdate里，我们是基于event.scale（手势开始以来的相对值）来计算的，如果不保存"手势开始前的基准值"，每次手势中断再重新开始，数值就会跳变。这个模式我总结成一句话：在手势开始前保存基准，在手势更新中叠加偏移，在手势结束前更新基准。

3. Gesture Handler 是怎么解决"手势跟手"问题的

很多人以为 Gesture Handler 只是"让 React Native 能用原生手势"，其实它解决的是一个更微妙的问题：手势响应链。在原生世界里，UIGestureRecognizer（iOS）和TouchEvent分发（Android）有一套复杂的优先级和取消逻辑。在老版 React Native 的PanResponder和Touchable体系里，这套逻辑被简化了，导致的结果就是：一个 ScrollView 嵌套一个可拖拽元素时，手势冲突的解决非常糟糕，要么是滚动不灵敏，要么是拖拽元素"抢不过"滚动。

Gesture Handler 的做法是：把手势识别器下沉到原生层，每个手势都是一个原生手势识别器，通过GestureDetector绑定到原生 View 上。这样手势的识别、失败、取消都遵循原生的规则，JS 只在合适的时候收到事件回调。

3.1 Worklet 化的手势回调：JS 不再成为瓶颈

Gesture Handler 的onUpdate、onChange这些回调是可以直接在 UI 线程执行的。在这个上下文里，你可以直接在回调里修改共享值，比如：

Gesture.Pan().onChange((event) => { translateX.value += event.changeX; });

onChange里对translateX.value的赋值，是发生在 UI 线程的，所以手势事件的整个闭环——原生识别、回调计算、UI 更新——都在 UI 线程完成，完全没有 JS 线程介入。这就带来了"跟手"的效果：你的手指动到哪，卡片就立刻跟到哪，不会有肉眼可见的延迟。

有个对比实验我做过很多次：同一个拖拽动画，改成用Animated.event+PanResponder的老方案，延迟在高帧率相机下大概有 2~3 帧的差距，Reanimated 3 组合基本能做到零延迟。对于追求"丝滑感"的产品来说，这个差异是决定性的。

3.2 手势状态的流转机制

Gesture Handler 的手势识别器有几个状态：UNDETERMINED、FAILED、BEGAN、ACTIVE、END/ENDED等。理解这套状态机是配置复杂手势的基础。

onBegin在手势可能被识别时触发，onStart在手势正式变为ACTIVE时触发，onUpdate在ACTIVE期间的每一次移动事件都会触发，onEnd在手势结束时触发，onFinalize无论如何都会触发（即使手势失败取消）。

在写代码时，我通常的逻辑是：

• onStart：保存手势开始前的基准值（比如位置、缩放基准）。
• onUpdate：根据event.changeX、event.scale等增量数据更新共享值。
• onEnd：做"收尾"逻辑，比如回弹到原点、保存当前状态。
• onFinalize：清理临时状态，比如取消一个正在进行的高亮。

有很多 bug 都是因为把基准值保存放到了onBegin而不是onStart。onBegin时机太早，手势还没被完全确认，这时候如果另一个手势后来居上，基准值可能就保存错了。

3.3 手势冲突处理的几种典型场景

实际项目里，手势冲突远比文档示例复杂。我列几个高频场景：

ScrollView 内嵌可拖拽行：如果行可以被左滑删除，但又要保留 ScrollView 的纵向滚动，最佳方案是用Gesture.Native()保住 ScrollView 的原生手势，再用Gesture.Pan()配置合适的activateAfterLongPress（长按后激活）或者activeOffsetX（横向位移超过阈值才激活）。关键是给 Pan 设置触发阈值，让它不会一碰就开始抢手势。

两个手势的优先级：Gesture.Exclusive能让两个手势互斥，只有一个能成功识别。比如"短按弹出菜单"和"拖动改变位置"，用 Exclusive 包裹后，系统会先等短按是否成立，不成立才让拖动接手。

跨组件手势联动：比如拖拽一个列表项到某个目标区域，需要让手势处理器知道目标区域的坐标。可以在 worklet 里通过event.absoluteX/absoluteY和预先保存的目标区域 rect 做判断。但要注意，在 worklet 里直接调用measure这类原生方法要小心，Reanimated 3 提供了measure包装函数，可以在 UI 线程同步测量。

4. 工具选型：为什么 Reanimated 3 + Gesture Handler 是天生一对

可能有人会问：Reanimated 3 自己也有useAnimatedGestureHandler，为什么还要单独用 Gesture Handler？本质上，两者解决的问题不同，但又深度互补。

Reanimated 3 负责"动画值的计算和渲染"，Gesture Handler 负责"手势的识别和事件分发"。在 Reanimated 2 时代，useAnimatedGestureHandler是官方推荐的手势接入方式，它就是基于 Gesture Handler 的底层能力封装的。到了 Reanimated 3，官方干脆把这个 API 废弃了，改成了直接用GestureDetector+Gesture.Pan()这类手势对象，然后配useAnimatedStyle消费手势事件产生的共享值变化。

这套方案的好处是：

• 手势识别原生化，不必经过 JS bridge。
• 事件回调在 UI 线程执行，可以直接操作共享值。
• 组合手势语法清晰，语义化表达复杂手势逻辑。
• React Native 新架构下，RNGH 和 Reanimated 都改用了 TurboModule + Fabric 直接调用，性能上限更高。

如果你项目里还在用老式的Animated.Value加PanResponder，我强烈建议抽个时间迁过来。迁移成本没有你想象的高，但体验提升是质的飞跃。

4.1 版本配套与初始化要点

这里要注意版本配套问题。Reanimated 3 要求 React Native 0.64 以上，Gesture Handler 建议用 2.x 的最新版（2.16 以上）。如果你用了 Expo，事情更简单，npx expo install会帮你把版本全部对齐。裸 RN 项目则需要手动处理：

npm install react-native-reanimated react-native-gesture-handler cd ios && pod install

安装完成后，在入口文件（index.js）最顶端必须引入 Gesture Handler：

import 'react-native-gesture-handler';

这个引入必须在任何其他代码之前，因为它要初始化原生手势系统。漏掉这行的话，你会在运行时遇到各种奇怪的手势不生效问题。

Reanimated 3 还需要配置 babel 插件。在babel.config.js里加：

module.exports = { presets: ['module:@react-native/babel-preset'], plugins: ['react-native-reanimated/plugin'], };

注意这个插件要放在plugins数组的最后一位。因为 worklet 的转换依赖于识别'worklet'指令，如果后面还有其他转换器先处理了代码，可能会破坏 worklet 的识别逻辑。

4.2 为什么不建议用 Animated 库做新项目

老牌的 Animated 库在低版本 RN 上很稳定，API 也简单，但它的架构决定了它在复杂交互上很难做到"丝滑"。它的动画值是以 JS 为源头的，哪怕是调用useNativeDriver: true，也只是把动画值传给原生侧做一次性的驱动，一旦你需要动态读取当前值、根据手势实时调整动画，就又得回到 JS 线程。一旦回到 JS，性能就受限。

Reanimated 3 的思路是反过来的：把计算下沉到 UI 线程，让 JS 线程专注业务逻辑。这种架构才是新项目的正道。

5. 实战优化技巧与避坑指南

最后分享一些我在真实项目里踩出来的经验，这些在官方文档里不一定能找到答案。

5.1 高频更新的 UI 不要整组件重渲染

前面提到useSharedValue的变化不会触发重新渲染，但useAnimatedStyle返回的样式要应用到组件上，组件本身不能因为其他状态变化而频繁重渲染。比如你有一个列表，列表项里有动画，那列表项最好用React.memo包裹，避免父组件状态更新时带动所有列表项重新渲染。

我在实际项目里遇到过这样一个场景：一个卡片列表，每张卡片都有"收藏"按钮，收藏状态变化时要弹一个心形动画。如果收藏状态放在全局 store 里，任何卡片收藏都会触发整个列表重渲染。后来我把"心形动画播放中"这个状态封装成一个子组件，用共享值存动画进度，收藏状态变化只影响那个子组件，列表性能瞬间就上来了。

5.2 注意共享值在 JS 侧的读值时机

共享值在 JS 侧读到的值并不总是最新的。因为 UI 线程和 JS 线程是异步通信的，你在 JS 里写console.log(sharedValue.value)，拿到的可能是几帧之前的值。如果需要精确地拿到最新值，可以用runOnUI把读取逻辑放到 UI 线程去执行：

runOnUI(() => { 'worklet'; console.log(sharedValue.value); })();

这在调试和某些"需要同步状态"的场景下非常关键。比如手势结束后，你要根据最终位置判断是否触发某个业务回调，最好在onEnd的 worklet 里拿到准确值，再通过runOnJS通知 JS 线程。

5.3 动画中断与取消的正确姿势

动画进行中如果突然需要中断，不要直接改共享值到目标值，因为这样会"跳变"。正确做法是使用cancelAnimation：

cancelAnimation(sharedValue); sharedValue.value = withSpring(0);

cancelAnimation会取消当前正在进行的动画，然后你再设置新的动画函数就能从当前值开始新动画。如果直接赋值sharedValue.value = 0，会丢掉当前动画的插值进度，视觉上就是瞬移。

5.4 性能监控：如何量化"丝滑"

最后聊一下怎么判断你的动画到底丝不丝滑。不要在真机上靠感觉，用工具量化。在开发模式下，打开Perf Monitor（iOS 模拟器 Cmd+D 里的 Show Perf Monitor），关注 FPS 和 JS 线程占用。理想状态下，动画运行期间 FPS 应该稳定在 58~60，JS 线程占用不超过 40%。

另外一个经验是：Android 设备的调试模式性能远低于 Release 模式。在 Debug 下测动画，你会发现卡得不像话，但这不代表发布后也卡。一定要在 Release 模式下跑一遍，才能确认真实性能。我把这个坑踩了好几次才长记性。

5.5 常见问题速查表

我在实际项目里的体会是，Reanimated 3 和 Gesture Handler 这套组合，真正的门槛不在 API 学习，而在于思维方式的转变：你要从"JS 控制原生"切换到"原生负责手感，JS 负责逻辑"。一旦过了这个坎，React Native 的交互体验上限会被拉得很高。最后再给一个小技巧：新项目开始前，先去看看 Expo 官方模板里对 Reanimated 3 和 Gesture Handler 的封装方式，他们的工程化实践是经过大量真机验证的，比你自己摸索要靠谱得多。