Reanimated 3 出来也有一段时间了我陆陆续续在几个项目里把它和 Gesture Handler 搭配着用说实话用过之后很难再退回老方案。以前写 React Native 动画最痛苦的事情就是怎么调都差那么点意思掉帧、卡顿、手势跟手度不够总是能被用户一眼看穿这是个 JS 写的应用。但换成 Reanimated 3 之后很多以前需要原生代码才能做到的交互现在纯 JS/TS 层面就能搞定而且流畅度可以做到和原生几乎无差别。这篇文章不打算讲 API 文档文档自己去看就行我主要想聊聊这套组合拳背后的运行机制、我在实际项目中踩过的坑以及一些能直接套用的优化思路。1. 为什么 React Native 动画以前总是卡问题出在哪先说一个很多新手容易忽略的底层事实React Native 应用的 JS 代码是运行在 JavaScript CoreAndroid 上可能是 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 线程侧执行。具体到执行流程可以这样拆解你在组件里调用withTiming或withSpring告诉共享值你要从当前值动画到某个目标值。Reanimated 立刻在 UI 线程启动一个动画驱动循环Core Animation 的 display link 驱动每帧回调一次。每一帧的回调里UI 线程直接算出当前动画值、更新原生 View 的样式属性整个过程 JS 线程完全不用参与。只有当你需要在动画进行中读取当前值、或者动画结束要通知 JS 时Reanimated 才会通过异步通道把值同步回 JS 侧。关键在于第 3 步。这一步是纯原生的没有 bridge 往返没有 JS 参与每一帧都有确定性的计算不会因为 JS 线程忙而丢帧。1.2 worklet 到底是什么它凭什么能在 UI 线程跑既然动画逻辑要搬到 UI 线程那你怎么把动画逻辑传过去比如你在 JS 里写的一个缓动函数、一个根据手势位移计算旋转角度的函数这些逻辑怎么能在 UI 线程执行Reanimated 3 的方案是 worklet。worklet 本质上是一段被标记了的 JavaScript 函数写法上就是在函数开头加一个worklet指令。在编译阶段Reanimated 的 babel 插件会把这个函数体转换成一段可序列化的代码然后在运行时通过 JS 引擎的 APIJavaScriptCore 的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 }} resizeModecover / /Animated.View /GestureDetector ); }这个例子看起来很简单但里面有几个点值得细讲。第一Gesture.Pan()的.onChange里用event.changeX做增量移动而不是event.translationX。如果用translationX最终移动量会因为多个手势同时触发而出现叠加漂移。changeX是每次手势事件和上一次之间的位移差天然适合增量累积。第二Gesture.Simultaneous让拖拽和捏合同时生效。如果不用 SimultaneousPan 手势会把 Pinch 手势的触摸给抢走导致双指缩放时只有一个手指生效。这是新手最容易困惑的地方。第三缩放和旋转在结束时要把当前值存回savedScale和savedRotation。因为在.onUpdate里我们是基于event.scale手势开始以来的相对值来计算的如果不保存手势开始前的基准值每次手势中断再重新开始数值就会跳变。这个模式我总结成一句话在手势开始前保存基准在手势更新中叠加偏移在手势结束前更新基准。3. Gesture Handler 是怎么解决手势跟手问题的很多人以为 Gesture Handler 只是让 React Native 能用原生手势其实它解决的是一个更微妙的问题手势响应链。在原生世界里UIGestureRecognizeriOS和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.eventPanResponder的老方案延迟在高帧率相机下大概有 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 废弃了改成了直接用GestureDetectorGesture.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 Handlerimport 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 动画中断与取消的正确姿势动画进行中如果突然需要中断不要直接改共享值到目标值因为这样会跳变。正确做法是使用cancelAnimationcancelAnimation(sharedValue); sharedValue.value withSpring(0);cancelAnimation会取消当前正在进行的动画然后你再设置新的动画函数就能从当前值开始新动画。如果直接赋值sharedValue.value 0会丢掉当前动画的插值进度视觉上就是瞬移。5.4 性能监控如何量化丝滑最后聊一下怎么判断你的动画到底丝不丝滑。不要在真机上靠感觉用工具量化。在开发模式下打开Perf MonitoriOS 模拟器 CmdD 里的 Show Perf Monitor关注 FPS 和 JS 线程占用。理想状态下动画运行期间 FPS 应该稳定在 58~60JS 线程占用不超过 40%。另外一个经验是Android 设备的调试模式性能远低于 Release 模式。在 Debug 下测动画你会发现卡得不像话但这不代表发布后也卡。一定要在 Release 模式下跑一遍才能确认真实性能。我把这个坑踩了好几次才长记性。5.5 常见问题速查表问题现象可能原因解决方案动画运行时 FPS 掉到 30 以下动画逻辑依赖了 JS 线程的变量或状态把所有动画中间状态迁到共享值确保useAnimatedStyle里只读共享值手势不响应或者和 ScrollView 冲突手势未设置触发阈值被系统判定为滚动配置activeOffsetX/activeOffsetY或改用Gesture.Native()嵌套双指缩放时卡片位置乱跳拖拽手势抢走了第二个手指用Gesture.Simultaneous组合 Pan 和 Pinchworklet 函数里访问外部变量报错闭包捕获了 React props 或普通函数把需要的数据先存到共享值worklet 只消费共享值动画结束瞬间出现跳变没有保存基准值导致叠加位移漂移在onStart保存基准onEnd更新基准编译报错Reanimated 3 failed to create a workletbabel 插件配置顺序错误确认react-native-reanimated/plugin在 plugins 数组最后动画在 Android Debug 下特别卡Debug 模式本身性能开销巨大用 Release 模式验证真实性能多个手势同时触发导致 UI 抖动没有把手势冲突考虑清楚明确手势之间的优先级合理使用Exclusive/Simultaneous我在实际项目里的体会是Reanimated 3 和 Gesture Handler 这套组合真正的门槛不在 API 学习而在于思维方式的转变你要从JS 控制原生切换到原生负责手感JS 负责逻辑。一旦过了这个坎React Native 的交互体验上限会被拉得很高。最后再给一个小技巧新项目开始前先去看看 Expo 官方模板里对 Reanimated 3 和 Gesture Handler 的封装方式他们的工程化实践是经过大量真机验证的比你自己摸索要靠谱得多。