鸿蒙版React Native底部抽屉：基于Modal的跨端弹层实现方案

做跨端开发最怕的就是同一套代码在不同平台上的观感千差万别。特别是鸿蒙版本抬上桌面之后，React Native的很多组件在Android/iOS上表现得好好的，一到鸿蒙就得重新调一轮。今天分享的这个底部抽屉（Bottom Sheet），就是我从Modal组件出发，在鸿蒙版React Native里拉通的一套实现方案。项目本身不复杂，核心就是Modal + 底部容器 + 手势，但里面涉及动画协调、安全区域、原生渲染层级这些细节，一个个弄完，整个组件就稳了。这篇内容适合正在把RN应用迁移到鸿蒙、或者需要在鸿蒙上实现弹层交互的开发者参考。

1. 从需求到方案：为什么底部抽屉偏要用Modal

1.1 底部抽屉是什么，难在哪

底部抽屉是移动端极其常见的交互模式：点一个按钮，页面底部弹出一个面板，背景半透明变暗，点击空白区域或者向下滑动可以关闭它。很多地方的称呼不一样，有人叫Bottom Sheet，有人叫半屏弹窗，在部分设计规范里还叫动作面板。不管叫法怎么变，底层需求是一致的——在不离开当前页面的情况下，提供一个可临时操作的区域，并且这个区域要具备“从底部滑入”的空间感。

放在React Native里，很多人第一反应是直接用View模拟：写一个绝对定位的容器，把它挂在页面根节点上，配合Animated控制上下位移，再弄一个全屏的黑色半透明遮罩，看起来好像就成了。数据流简单的页面可能没问题，但一旦页面本身有滚动条、有嵌套导航、有多个弹出层，这种手动方案就开始出问题。最典型的几个：

1. 页面侧滑返回、下拉刷新、WebView内部滚动这些手势会对抽屉的手势造成干扰；
2. 遮罩层和抽屉容器在Android的屏幕刷新率不同步时，会出现肉眼可见的面板掉帧；
3. 模态层和实际页面层级混乱，弹窗被导航栏或者TabBar遮挡，背景还能互相透出；
4. 多弹窗叠加时，onRequestClose事件处理不当，返回键一按把整个页面退出了。

这些问题在鸿蒙版的React Native上只会更多，不会更少。因为鸿蒙的RN运行时本身还在持续完善，某些原生行为与Android/iOS不完全一致，直接用View手搓往往修完一个bug又冒出一个新bug。与其在页面层面做对抗，不如把“模态”这件事交给系统级的Modal组件，让它在原生层处理好层级和返回键，我们用样式和手势把“底部抽屉”的形态做出来。

1.2 方案比选：Modal、绝对定位组件还是第三方库

我在动手前比较过三条路：

第一是直接用第三方底部抽屉库，这个最省事，但风险也最大。市面上成熟的库都是基于原生BottomSheet封装，在Android/iOS上效果确实不错，可到了鸿蒙上就不好说了。很多库内部依赖了原生侧滑手势识别器，或者使用了Android专属的WindowManager行为，RN鸿蒙版未必完整支持。为了少写几百行代码把整个交互框架搭在不确定的底层上，对于生产环境来说太冒险。

第二是纯View+Animated手写方案。这个方案适合单页面、交互简单、不需要考虑全局导航嵌套的场景。如果你的项目里底部抽屉只出现在一个固定页面，并且页面上没有复杂的滚动冲突，那手写其实也够用了。但现实项目里抽屉往往需要在多个页面复用，还要考虑登录态、键盘弹起、安全区等因素，手写方案的扩展成本会越来越高。

第三就是标题里说的方案：以Modal组件为壳，在其内部实现底部布局、动画和手势。Modal组件在RN里天然具备模态上下文：独立的原生模态窗口、自动处理Android返回键的onRequestClose、半透明状态栏的支持。我们只需要把Modal的透明背景打开，然后在里面铺一层半透明黑色遮罩，再接一个固定在底部的白色容器，视觉和交互就完全可控了。这个方案是把“模态能力”交给系统，“视觉与手势”留给自己，从工程角度来说是最稳的组合。

事实上，这个思路也是很多成熟组件库内部的做法——不是不用Modal，而是把Modal的能力隐藏在自己封装的API后面。所以最终我决定走第三条路，并且把鸿蒙版的适配问题一并考虑进去。

提示：第三方库如果非要使用，至少做一个鸿蒙真机上的手势冲突和返回键测试，不要在模拟器上拍板，很多问题只在真机上暴露。

2. Modal底部抽屉的核心设计拆解

2.1 Modal的关键属性与底层行为

RN自带的Modal组件，表面上看就是一个“盖在页面上的层”，但几个关键属性决定了它能不能做成底部抽屉。

第一个是transparent。默认情况下Modal是白色不透明背景，必须设成transparent，这样Modal背后的内容才能露出来，我们才有机会在Modal里面自己画半透明遮罩。不设这个属性的话，背后页面会直接全白，等于一个破绽百出的弹层。

第二个是animationType。系统内置了slide、fade、none三种动画，slide是从底部直接滑入整个Modal视图，fade是淡入淡出。底部抽屉的“从底部滑入”，很多人觉得直接用animationType="slide"就行了，但实际这么做，整个Modal对话框的容器是从底部滑上来的，包括里面放的遮罩和面板，中间会出现一段明显的黑色背景露出过程，观感并不好，尤其是状态栏半透明的情况下更明显。所以我通常把animationType设为none，完全关掉系统动画，由自己控制的Animated来驱动抽屉面板的位移动画。代价不大，可控性却高很多。

第三个是onRequestClose。这是Android和鸿蒙返回键必须处理的事件，当用户按返回键的时候，如果这个属性没有提供或者里面没有关闭逻辑，应用会直接退出或者表现异常。使用Modal做抽屉，务必要在onRequestClose里调用关闭回调。

第四个是statusBarTranslucent。很多底部抽屉会在状态栏的区域滑动，如果这个属性不打开，抽屉面板顶到状态栏边缘时状态栏背景会和面板颜色产生割裂感，看起来像一块补丁。鸿蒙版对此属性的支持比Android稍晚一些，实测早期版本偶尔会闪一下，但新版本已经稳定了。

除了属性层面，Modal在原生层是独立的窗口或视图层，它的渲染排序高于普通页面。这意味着抽屉面板不会被页面里的overflow裁剪，也不会被导航栏盖住。这正好解决了手动方案里“层级不足”的痛点。

2.2 动画与手势：面板的位移轨迹控制

底部抽屉的面板本质是一个位于底部、尺寸受内容决定的矩形容器。它要做得自然，需要两套运动控制：进入时的滑入动画，以及手指拖动时实时跟随。

我用Animated.Value来保存面板的translateY偏移量。初始状态把偏移量设置成屏幕高度，面板就完全在可视区域外面；然后通过Animated.timing在几百毫秒内把偏移量降到0，面板就滑入到位。关闭时把偏移量重新拉回屏幕高度，动画结束之后再触发onClose。

手势部分使用PanResponder。监听手指在面板上的垂直方向移动：手指从上往下滑动时，面板跟随手指向下位移；位移超过面板高度的30%，松手就自动关闭；没超过，就回弹复位。手指从下往上滑动时，面板跟随手指向上移动，但到达0之后就不再往上（用setValue限制），这样就不会把面板推到屏幕外面去。

关键在于手势和动画的衔接。手指按住面板拖动时，要用useNativeDriver: false，因为PanResponder拿到的是JavaScript侧的坐标，如果动画被标记为原生驱动，手势断点会和动画值产生错位，导致面板“跳动”。进入和关闭的动画可以使用原生驱动，但为了统一，我在这个组件里全部用了非原生驱动，动画曲线选择Easing.out(Easing.cubic)，整体体感接近原生BottomSheet。

还要注意一个细节：抽屉里的所有可点击元素，比如按钮、列表项，潘手势和按压事件是共存的。PanResponder要在onStartShouldSetPanResponder里判断触摸点是否在面板范围内，以及是否识别为纵向滑动，否则用户在面板里竖向滚动列表时，抽屉也会跟着跑，那就是灾难了。

3. 完整代码实现与参数解释

3.1 基础版：一个可用的底部抽屉组件

先把最核心的组件代码贴出来，这个版本已经可以在鸿蒙和Android上正常运行，我在注释里把关键参数都标注清楚了。

import React, { useRef, useState, useEffect } from 'react'; import { Modal, View, Text, TouchableOpacity, StyleSheet, Dimensions, Animated, PanResponder, Platform, StatusBar, Easing, } from 'react-native'; const { height: SCREEN_HEIGHT } = Dimensions.get('window'); const BottomSheetModal = ({ visible, onClose, children, title }) => { const [modalVisible, setModalVisible] = useState(visible); const panY = useRef(new Animated.Value(SCREEN_HEIGHT)).current; // 当visible变为false时，先播放关闭动画再卸载 useEffect(() => { if (visible) { setModalVisible(true); Animated.timing(panY, { toValue: 0, duration: 280, easing: Easing.out(Easing.cubic), useNativeDriver: false, }).start(); } else { Animated.timing(panY, { toValue: SCREEN_HEIGHT, duration: 220, easing: Easing.in(Easing.cubic), useNativeDriver: false, }).start(() => setModalVisible(false)); } }, [visible]); // 手势控制器：竖直拖拽 const panResponder = useRef( PanResponder.create({ onMoveShouldSetPanResponder: (_, gestureState) => { // 只拦截纵向位移大于8px的手势，避免和列表的横向滑动冲突 return Math.abs(gestureState.dy) > 8 && Math.abs(gestureState.dy) > Math.abs(gestureState.dx); }, onPanResponderMove: (_, gestureState) => { let newY = gestureState.dy; // 下拉时给一点阻尼，避免手指离开屏幕后面板就飞走 if (newY < 0) { newY = newY * 0.3; } panY.setValue(Math.max(0, newY)); }, onPanResponderRelease: (_, gestureState) => { if (gestureState.dy > 120 || gestureState.dy > SCREEN_HEIGHT * 0.2) { // 下滑幅度足够大，直接关闭 Animated.timing(panY, { toValue: SCREEN_HEIGHT, duration: 200, useNativeDriver: false, }).start(onClose); } else { // 幅度不够，回弹到初始位置 Animated.spring(panY, { toValue: 0, speed: 24, bounciness: 4, useNativeDriver: false, }).start(); } }, }) ).current; const translateY = panY.interpolate({ // 区间映射：面板从视口底部滑入 inputRange: [0, SCREEN_HEIGHT], outputRange: [0, SCREEN_HEIGHT], extrapolate: 'clamp', }); return ( <Modal visible={modalVisible} transparent={true} animationType="none" statusBarTranslucent={true} onRequestClose={onClose} > {/* 遮罩层 */} <View style={styles.overlay}> <TouchableOpacity activeOpacity={1} onPress={onClose} style={styles.backdrop} /> {/* 面板容器 */} <Animated.View style={[styles.sheetContainer, { transform: [{ translateY }] }]} {...panResponder.panHandlers} > {/* 顶部把手 */} <View style={styles.handleWrap}> <View style={styles.handle} /> </View> <View style={styles.contentWrap}> {title ? <Text style={styles.title}>{title}</Text> : null} {children} </View> </Animated.View> </View> </Modal> ); }; const styles = StyleSheet.create({ overlay: { flex: 1, backgroundColor: 'rgba(0, 0, 0, 0.45)', justifyContent: 'flex-end', }, backdrop: { ...StyleSheet.absoluteFillObject, }, sheetContainer: { backgroundColor: '#fff', borderTopLeftRadius: 16, borderTopRightRadius: 16, paddingBottom: Platform.OS === 'ios' ? 34 : 24, maxHeight: SCREEN_HEIGHT * 0.75, shadowColor: '#000', shadowOffset: { width: 0, height: -2 }, shadowOpacity: 0.1, shadowRadius: 12, elevation: 24, }, handleWrap: { alignItems: 'center', paddingTop: 12, paddingBottom: 4, }, handle: { width: 40, height: 4, borderRadius: 2, backgroundColor: 'rgba(0, 0, 0, 0.2)', }, contentWrap: { paddingHorizontal: 16, paddingBottom: 8, }, title: { fontSize: 16, fontWeight: '600', color: '#222', textAlign: 'center', marginBottom: 12, }, }); export default BottomSheetModal;

这个基础版组件已经可以完成核心闭环：从底部弹出、半透明遮罩、点击遮罩关闭、返回键关闭、手势下拉关闭。实际使用的时候，只需要在外层维护一个visible状态，把抽屉内容作为children传进去就行。

参数上有几个点值得展开说。SCREEN_HEIGHT用的是Dimensions.get('window')，而不是get('screen')。在Android上，window高度是可用显示区域，screen高度包含系统导航栏，如果用了screen高度，关闭动画时TranslateY会多出一段，面板还没完全移出就触发onClose，屏幕上会闪一下底部空白区域。鸿蒙版取值逻辑和Android基本一致，优先用window。

遮罩的onPress用TouchableOpacity，而不是直接给View绑定onTouchStart。因为TouchableOpacity的按压反馈和点击判定更成熟，还能避免用户快速点击穿透到背景页面。遮罩层级放在面板底下，点击遮罩只会命中遮罩，不会误触面板。

3.2 增强版：安全区域、键盘避让和列表滚动兼容

基础版够用，但到了真实项目里肯定会遇到几个绕不开的问题：iPhone的刘海屏底部安全区、鸿蒙平板等大屏设备上内容拉得很长、抽屉内部放列表时的滚动手势冲突、以及键盘弹起时抽屉被顶飞。

安全区处理最直接的方式是引入SafeAreaView，但要注意：SafeAreaView放在Modal内部时，在鸿蒙上的表现不一定和Android/iOS完全一致。我更推荐手动获取安全区边距，避免样式在不同平台上产生额外差异：

import { SafeAreaView, useSafeAreaInsets } from 'react-native-safe-area-context'; const insets = useSafeAreaInsets();

然后在面板容器里加paddingBottom: Math.max(insets.bottom, 16)。这样面板底部就不会被圆角或手势条遮挡。如果项目没有引入react-native-safe-area-context，也可以从NativeModules里取，或者干脆直接用Platform.select给不同平台写默认值，Android是24，鸿蒙是24，iOS是34。实测下来，鸿蒙对应的底部手势条区域在多数设备上是24左右，但个别平板会更大，所以用库获取是更稳的做法。

键盘避让这块比较麻烦。Modal本身有一个onShow回调，但键盘弹起会压缩整个Modal视图的高度，如果我们给面板设置了maxHeight，键盘弹起时面板会被压缩而不是上移，视觉上像被“挤扁”了。处理方式是用Keyboard.addListener监听keyboardDidShow，拿到键盘高度之后把面板整体向上平移。做法是再维护一个Animated.Value作为keyboardOffset，然后transform设置成translateY: translateY的值减去keyboardOffset。关键是要在键盘弹起的时候同时调整面板的maxHeight，避免叠加后超过可用空间。

const [keyboardHeight, setKeyboardHeight] = useState(0); useEffect(() => { const showSub = Keyboard.addListener('keyboardDidShow', (e) => { setKeyboardHeight(e.endCoordinates.height); }); const hideSub = Keyboard.addListener('keyboardDidHide', () => { setKeyboardHeight(0); }); return () => { showSub.remove(); hideSub.remove(); }; }, []);

然后在面板样式里加transform: translateY = panY - keyboardHeight，注意用Animated.Value对键盘高度做插值或者直接用Animated.add，否则面板会在键盘弹起的瞬间硬跳。

滚动兼容是另一个高频问题。抽屉里放一个ScrollView或FlatList时，手指在列表区域上下滑动，PanResponder的onMoveShouldSetPanResponder会捕获手势，导致列表完全无法滚动。解决办法是在onMoveShouldSetPanResponder里增加判断：如果触摸点落在列表区域内，并且手势起点是纵向，优先交给列表处理。实际上更简单的方式是给列表的scrollEnabled绑定一个状态：当面板处于拖拽状态时禁止列表滚动，当手势结束时恢复。但在实践中我发现更稳的逻辑是让PanResponder只在抽屉整体被拖拽时才拦截，也就是拖拽距离大于30px且拖拽方向是竖直向下，因为向下拖时列表中向下的滚动已经触顶，即便交给列表也无动画；向上拖只发生在列表已经滚到顶部时，这个判断可以在列表的onScroll回调里记录offset，然后传给PanResponder判断。

3.3 鸿蒙版适配的额外步骤

这部分是标题里的重点，我把我在鸿蒙真机调试时遇到的和绕过的都整理一遍。

第一，确认鸿蒙版React Native的运行时版本。这个细节很多人忽略：鸿蒙的RN不是第三方框架，而是基于OpenHarmony适配的版本。不同版本对Modal的transparent和animationType支持程度有差异，早期版本直接写transparent可能需要同时设置操作系统级的半透明窗口配置。如果在真机上发现Modal背景无法变透明，先确认适配版的API是否完整，不要急着改业务代码。

第二，鸿蒙的返回键行为。在Android上onRequestClose会被系统返回键触发；在鸿蒙上，由于系统底层不同，部分早期版本需要依赖页面路由的backHandler来配合。如果你的应用在鸿蒙上按返回键时，抽屉没有关闭而页面退出了，多半是Modal没有正确接收返回事件。排查方法是先确认你使用的RN鸿蒙版本是否支持Modal的onRequestClose自动转发，如果不支持，需要在页面级别注册BackHandler监听，手动调用onClose。

第三，状态栏半透明。鸿蒙版的StatusBar.currentHeight可能返回0或不准确，导致我们计算面板顶部间距时出错。我建议在抽屉弹层里直接用getStatusBarHeight这个库或者显式传入状态栏高度，而不是依赖系统值。

第四，模拟器和真机的差异。鸿蒙的Previewer模拟器在动画表现上和真机差距很大，特别是PanResponder的跟手程度。模拟器上的动画看起来流畅，真机上可能会出现掉帧，尤其是手指滑动面板时，非原生驱动模式下的JS线程开销偏大。如果真机上面板跟手有延迟，可以在onPanResponderMove里加一个requestAnimationFrame来限流，或者在面板复杂度较高时避免使用阴影样式（shadow）。

第五，鸿蒙特定分辨率下的抽屉高度。鸿蒙平板和大屏设备的屏幕高度和宽比差异很大，直接用SCREEN_HEIGHT * 0.75作为maxHeight在平板上会让抽屉变得特别矮。更好的做法是同时限制一个最小高度和一个最大宽度，在平板上抽屉宽度不应该占满全屏，通常设置为480到560。

我在代码里加上一段针对平板的适配：

const isTablet = Platform.isPad || (SCREEN_HEIGHT / SCREEN_WIDTH) < 1.6; const SHEET_MAX_HEIGHT = isTablet ? '40%' : '75%'; const SHEET_WIDTH = isTablet ? 480 : '100%';

这两个值直接用于面板样式，安卓手机上的视觉比例和鸿蒙平板上的比例就都能守住。

4. 常见问题与排查实录

4.1 问题速查表

拿Modal做底部抽屉，在鸿蒙版RN里最容易遇到的问题其实非常集中。我把这段时间踩过的和同行交流过的问题整理成一张表，各位可以直接对照排查。

4.2 几个印象深刻的debug过程

第一个问题是鸿蒙真机上的半透明失效。我最早在模拟器里跑得好好的，一切换到真机，Modal的背景直接变成纯白，抽屉没看到，先看到一块白板。排查了一圈，不是transparent的问题，是鸿蒙适配版Modal实现里没有把应用窗口的背景设置为半透明渲染模式。处理方法是检查使用版本的release note，并在onShow回调里给原生窗口配置设置一次透明度，或者升级到修复该问题的版本。如果你遇到同样的问题，先判断是开发阶段还是生产阶段，如果是开发阶段，升级运行时版本是最直接的路径，不用去动业务代码。

第二个是FlatList和抽屉手势打架。这个在实现早期特别烦人。我在抽屉里放了一个商品列表，每次手指想向上滚动列表，整个抽屉就开始跟着上下动。试过设置scrollEnabled=false再根据拖拽距离判断，发现手感很生硬。后来我在onScroll回调里维护一个isAtTop变量，只有当列表滚动位置为0且手势方向向下时，才允许PanResponder接管；列表未到顶或者手势向上时，直接把触摸事件交给列表。这样改完之后，日常滚动列表和下拉关闭抽屉就没有明显冲突了。

第三个是关闭后状态残留。我在visible从true变成false之后，如果紧接着又把visible设回true，抽屉偶尔会闪一下或者停在半空。问题出在useEffect里关闭动画还没跑完，新的打开动画就开始了，两个Animated.timing同时操作同一个panY，互相打架。解决办法是在打开动画执行前，先panY.stopAnimation()，再加一个setValue(SCREEN_HEIGHT)重置，然后再启动动画。代码量不大，但能避免一堆偶现bug。

4.3 性能与体验调优的最后一公里

底部抽屉做得能用了，和做得“好用”之间还有一段距离。以我试下来的经验，最影响体验的是三点：手势跟手度、动画帧率、状态切换的健壮性。

手势跟手度方面，建议在手势Move事件里不要做任何复杂的JS计算。此前我在onPanResponderMove里做数据格式化、判断条件等操作，真机上能明显感到拖动量跟不上手指。后来我把所有运算前置，手势回调里只保留panY.setValue(gestureState.dy)，其余逻辑全部在释放时处理，体感立刻顺了很多。

动画帧率方面，抽屉面板的子组件如果用硬件阴影，每帧的渲染开销会非常大。鸿蒙真机对阴影渲染性能和Android有差异，实测下来，原生阴影给一个宽面板带来的开销可能导致动画帧率跌破30帧。保留一个极淡的阴影，或者干脆在抽屉动画过程中隐藏阴影、动画结束后再开启，视觉差异几乎为零，帧率却稳了很多。

状态切换的健壮性关系到另一个高频bug：快速连续打开关闭。用户连点按钮时，Modal的visible在短时间内多次翻转，如果组件的useEffect里动画停靠不干净，会出现面板卡在半空或者遮罩提前消失。我在组件里加了一个isAnimatingRef标志，在动画进行期间直接忽略新的visible变化指令，动画结束后再检查最新状态。这个方法简单粗暴，但确实有效。

注意：不要尝试在一个组件里同时操作多个Animated.Value去控制同一个面板的translateY。多个动画值同时驱动会造成互相覆盖，最终表现就会随机抖动。所有位移尽可能收敛到一个动画值上，其他位置变化用插值或者animate到同一个值。

5. 这个组件后续还可以怎么扩展

底部抽屉做完之后，大多数人会把它做成一个通用组件放到项目里。这时候有几个扩展点值得提，方便你把它改造成团队的基础组件。

首先是可配置化。当前组件里硬编码的圆角、动画时长、阻尼系数、关闭阈值、背景遮罩透明度，都应该提成props，以参数对象的形式传入，这样设计同学想调整间距时就不用再翻代码了。参数多了之后要提供默认值，避免调用方漏传导致风格不统一。

其次是遮罩的过渡动画。目前遮罩是直接出现和消失的，虽然面板滑入滑出质感还可以，但遮罩的明暗切换显得生硬。可以在遮罩上套一层Animated.View，让opacity和面板的translateY联动，从0.0渐入到0.45，关闭时渐出。联动方式可以直接把透明度的插值范围映射到translateY上面。

然后是多实例场景。如果项目里存在多个抽屉互相嵌套的情况，比如一个抽屉里面还要弹另一个抽屉，这时候多个Modal同时挂载在视图树上，关闭顺序和返回键优先级需要特别处理。建议在每个抽屉实例上维护一个唯一的layerIndex，关闭时从高到低依次关闭，避免底层先关导致上层悬空。

最后是声明式状态管理。如果项目使用了状态管理库，可以把visible状态抽出来，让抽屉的开关态和动画态分离。这样业务组件不需要关心抽屉内部如何播放动画，只要设置一个openKey，组件内部根据key的变化自动弹出和收回。不仅能减少样板代码，还方便在深链接或者推送回调里直接控制抽屉开关。

6. 写在最后的实操体会

这套方案从最初一个简单的Modal封装，一步步调整到能兼容鸿蒙真机、处理键盘避让、协调列表滚动，整个过程比预期要曲折不少。我在实际编码中体会最深的一点是：当你发现某个组件在某一个平台上表现异常时，先不要急着加补丁，多花点时间搞清楚它底层是怎么实现的，往往能找到比绕来绕去的hack更干净的做法。就像这次如果一开始就放弃Modal去手写全套弹层，后面遇到的返回键、层级、状态栏问题，每一个都会比现在更难处理。

另一个小技巧是调试时把visible状态做成外部可控，在开发调试工具栏里放一个全局的“打开/关闭抽屉”按钮，配合热更新，可以在不重复走业务路径的情况下快速复现动画和手势问题，效率比打着断点一步步跑高得多。另外如果你在鸿蒙真机上遇到和模拟器表现不一致的情况，记得先看RN鸿蒙适配版的更新日志，很多底层行为修复不体现在RN上层API的变更里，但会直接影响你写的代码表现。

这个底部抽屉组件如今已经跑在我们多个业务页面上，配合统一的样式配置和手势参数，整个交互的手感保持得比较一致。以后如果再支持更多平台，这个以Modal为壳的思路应该也能平滑迁移。希望这篇拆解和代码能帮你少踩几个坑。