Jetpack Compose实现裸眼3D：传感器驱动+视差多层位移全攻略

最近在某房产App上看到头部banner的裸眼3D效果，第一反应是这里用了“视差滚动+传感器驱动”的组合玩法。这个效果在原生Android端有过不少实现，但在Jetpack Compose里怎么落地，网上完整资料并不多。我花了一个周末把仿自如裸眼3D效果的Compose版本跑通，这里把整个方案的思路、核心代码和踩坑经历都整理出来，如果你正打算在Compose项目里做类似的多层视差、传感器交互效果，这篇可以直接参考。

先说清楚这个效果到底是什么：当你拿着手机轻微倾斜或转动时，画面里的前景物体像悬浮在屏幕上方，和背景产生明显的层次位移，视觉上形成一种“裸眼3D”的立体感。它不是真正的三维渲染，而是通过传感器数据驱动多个图层做不同速度、不同方向的位移，利用视差欺骗人眼。整条链路拆开看其实只有三件事：传感器数据的采集与平滑、传感器数值到UI偏移量的映射、多个图层各自的位移计算。难点不在某一个环节，而是如何让三者配合得足够顺滑，以及怎么在Compose的声明式模型里不把性能拖垮。

1. 效果拆解与整体技术方案设计

1.1 裸眼3D效果的视觉本质

先说视觉原理，这决定了后续所有参数怎么调。人眼判断距离靠的是双眼视差，而单屏设备做不到真正的双目视差，所以这类App用的是“运动视差”——手机倾斜时，近处物体在视野中移动得快、幅度大，远处物体移动得慢、幅度小，大脑会把这个相对位移解读为深度信息。

具体到UI表现，前景层（比如人物、家具、车）偏移量大，背景层（比如墙体、天空、小区环境）偏移量小且方向相反，中间层（比如阳台、树木）介于两者之间。层数越多，立体感越强，但层数超过五层后收益递减，而且图片切层成本高。实际项目里三层就够用：背景、中景、前景，比例大约在1:2:4左右，具体数值后面说。

1.2 为什么选择传感器驱动而不是手势驱动

实现裸眼3D效果有两种主流驱动方式。

手势驱动是用手指在图片上拖动或滑动来切换视角，优点是逻辑简单、不依赖硬件，缺点是不够“自动”——用户必须主动操作，而且触摸和位移之间存在延迟，手感调不好会觉得很僵。

传感器驱动则是读取加速度计或旋转矢量传感器的数据，手机倾斜多少，画面就跟着偏移多少，用户不需要任何操作，体验更接近“活”的页面。自如App的banner用的就是传感器方案，因为这种“跟随感”强调的就是真实物理反馈。

我在实际开发中测试了两种方案的融合：主驱动用传感器，手势做辅助微调。单独只用传感器时，手机平放在桌面上效果会消失，因为加速度计此时没有有效重力分量；而加入手势滑动后，在静态场景中依然能手动查看画面细节，体验完整很多。不过手势和传感器同时生效时需要做叠加，优先级要处理好——手势优先级高于传感器，传感器恢复零位后手势偏移保留。

1.3 Compose技术栈下的整体架构

Compose实现这个效果，整体架构分三层：

数据层负责传感器监听、数据平滑、偏移量计算，不感知UI；状态层暴露三个核心状态：水平偏移量、垂直偏移量、当前倾斜角度（部分效果需要旋转）；UI层根据状态对多层图片分别做graphicsLayer变换。

选择Compose而不是传统View，主要原因有三个：

第一，Compose的graphicsLayer可以直接修改translationX、translationY、rotationZ等属性，并且只触发绘制阶段，不触发重组，非常适合高频传感器回调。

第二，声明式UI天然适合做“状态驱动位移”：传感器回调里更新状态，UI层自动响应，不需要像View体系那样手动invalidate()或拿Handler发消息。

第三，Compose的Modifier体系可以把这个效果封装成一个可复用的modifier.parallax3D()，业务方一行代码就能给任意图片或卡片加上裸眼3D效果。

提示：这个方案不需要任何三方库，官方组件就够了。如果你只是想快速看效果，直接把代码复制进一个Compose项目就能跑。

2. 核心原理：传感器数据与视差位移的计算模型

2.1 传感器类型选择与坐标系处理

Android里和姿态相关的传感器主要有三类：加速度计、陀螺仪、旋转矢量传感器。

实际效果里我推荐**旋转矢量传感器（TYPE_ROTATION_VECTOR）**作为首选，加速度计作为兜底。旋转矢量是系统把陀螺仪、加速度计、磁力计做融合后的输出，数值本身就是设备姿态的稳定表示，省掉了自己写卡尔曼滤波的麻烦。不过有些定制ROM对旋转矢量的刷新率支持不稳定，遇到这种情况再降级到加速度计。

坐标系处理是这里的第一个坑：传感器返回的数值是设备坐标系，而UI位移要的是“屏幕上的水平/垂直偏移”。需要注意，竖屏时values[0]对应设备绕X轴旋转（前后倾斜），values[1]对应绕Y轴旋转（左右倾斜）。如果直接拿这两个值当translationX/translationY，会出现方向反掉或者横竖屏不一致的问题。我写了一个小工具类做坐标映射：

fun mapSensorToUi( values: FloatArray, orientation: Int ): Pair<Float, Float> { val rawX = values[0] val rawY = values[1] return when (orientation) { Surface.ROTATION_0 -> rawX to rawY Surface.ROTATION_90 -> -rawY to rawX Surface.ROTATION_180 -> -rawX to -rawY Surface.ROTATION_270 -> rawY to -rawX else -> rawX to rawY } }

横竖屏切换时，如果坐标系不做映射，画面位移方向会完全错乱，这个问题在平板和折叠屏上尤其明显。

2.2 数据平滑与滤波处理

传感器原始数据不能直接用。加速度计输出的抖动幅度高，旋转矢量在部分设备上也有偶发的跳变，如果直接映射到位移，画面会出现明显的“呼吸感”——静止状态下图片也在小幅度晃动。

我测试下来最有效的组合是低通滤波+阈值死区。低通滤波公式很简单：

val alpha = 0.15f filteredValue = filteredValue + alpha * (rawValue - filteredValue)

alpha越小越平滑，但响应越迟钝；alpha越大响应越快，但抖动越明显。实测alpha取0.1到0.2之间，视觉效果最自然。

阈值死区解决的是“回不到中心点”的问题：倾斜很小角度时，人眼感知不到位移，但传感器仍然会输出微小数值。不加死区，画面中心点会飘。我的处理方式是：当滤波后的数值绝对值小于0.02g时，强制归零。

2.3 位移映射与图层分层逻辑

传感器数值和像素位移之间是线性映射关系，核心参数是最大偏移量。以360dp宽的图片为例，左右各留出20dp余量，水平最大偏移设为20dp；垂直方向考虑到banner高度有限，通常设为8dp到12dp。

多层图层的偏移比例是立体感的关键。我做了一组对照实验：

倍率超过2.0后会出现“穿帮”——用户能看到图层的边缘，因为前景层图片尺寸没有足够余量。所以图片资源本身要预留边距，三层的底图建议统一比显示区域宽20%到30%，保证位移时不露底。

实际计算时，用lerp插值做非线性映射效果更好。线性映射在倾斜角度大时移动过快，非线性映射（比如二次曲线）让轻微倾斜时响应柔和、大幅倾斜时响应充沛：

val normalizedX = (filteredX / MAX_ANGLE).coerceIn(-1f, 1f) val offsetX = normalizedX * normalizedX * sign(normalizedX) * maxOffsetX

这个方法保证位移方向正确，同时在小角度时更细腻。

注意：前景层的位移方向要和背景层相反吗？不一定。我测试后认为：所有图层向同一方向位移、但速度不同，立体感更稳定；前景反向位移虽然冲击力强，但容易让眼睛疲劳，而且和页面滚动手势冲突。如果你做的是全屏沉浸式3D，可以尝试反向；但用在页面内的banner上，同向变速更稳妥。

3. 实操实现：从传感器到裸眼3D画面的完整代码

3.1 传感器监听与生命周期管理

这部分是整个功能的基础。核心注意点是：传感器注册必须跟生命周期绑定，否则页面不可见时传感器仍然在回调，浪费电且可能引发诡异bug。

我这里写了一个可复用的ViewModel，负责传感器生命周期和状态管理：

class ParallaxViewModel : ViewModel() { private val _sensorState = MutableStateFlow(SensorData()) val sensorState: StateFlow<SensorData> = _sensorState.asStateFlow() private val sensorManager: SensorManager? = null private var filteredValues = FloatArray(3) private var sensorListener: SensorEventListener? = null fun startSensor(context: Context) { val manager = context.getSystemService(Context.SENSOR_SERVICE) as SensorManager val sensor = manager.getDefaultSensor(Sensor.TYPE_ROTATION_VECTOR) ?: manager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER) val listener = object : SensorEventListener { override fun onSensorChanged(event: SensorEvent) { val values = event.values.clone() if (event.sensor.type == Sensor.TYPE_ROTATION_VECTOR) { val rotationMatrix = FloatArray(9) SensorManager.getRotationMatrixFromVector(rotationMatrix, values) val orientation = FloatArray(3) SensorManager.getOrientation(rotationMatrix, orientation) values[0] = orientation[1] // pitch values[1] = orientation[2] // roll } filteredValues = lowPassFilter(values, filteredValues, 0.15f) _sensorState.value = SensorData( x = filteredValues[0], y = filteredValues[1], timestamp = event.timestamp ) } override fun onAccuracyChanged(sensor: Sensor, accuracy: Int) {} } manager.registerListener(listener, sensor, SensorManager.SENSOR_DELAY_GAME) sensorListener = listener sensorManager = manager } fun stopSensor() { sensorListener?.let { sensorManager?.unregisterListener(it) } sensorListener = null } override fun onCleared() { stopSensor() super.onCleared() } private fun lowPassFilter(input: FloatArray, output: FloatArray, alpha: Float): FloatArray { for (i in input.indices) { output[i] = output[i] + alpha * (input[i] - output[i]) } return output } }

SENSOR_DELAY_GAME是监听频率的关键参数，大约是20ms回调一次，适合交互类效果。SENSOR_DELAY_NORMAL是200ms，做动画会明显卡顿；SENSOR_DELAY_FASTEST是硬件最高频率，对电池和性能压力太大，收益反而不明显。

getOrientation()得到的值单位是弧度，范围在-π到π之间，后续计算时需要转换成角度值并与阈值比较。

3.2 从传感器数值到UI状态的转换

传感器ViewModel暴露的是StateFlow<SensorData>，但UI层不能直接用原始弧度值。这里需要做一次“传感器空间到UI空间”的转换，包含归一化、死区、最大偏移量计算。

我建议把这段逻辑放到一个produceState或者derivedStateOf里面，避免在Composable里重复计算：

@Composable fun rememberParallaxOffsets( sensorData: StateFlow<SensorData>, maxOffsetX: Dp = 20.dp, maxOffsetY: Dp = 10.dp, maxAngle: Float = 12f ): State<Offset> { val density = LocalDensity.current val maxX = with(density) { maxOffsetX.toPx() } val maxY = with(density) { maxOffsetY.toPx() } val offsets = remember { mutableStateOf(Offset.Zero) } LaunchedEffect(maxX, maxY, maxAngle) { sensorData.collect { data -> val angleX = Math.toDegrees(data.x.toDouble()).toFloat() val angleY = Math.toDegrees(data.y.toDouble()).toFloat() val normalizedX = (angleX / maxAngle).coerceIn(-1f, 1f) val normalizedY = (angleY / maxAngle).coerceIn(-1f, 1f) val offsetX = calculateOffset(normalizedX, maxX) val offsetY = calculateOffset(normalizedY, maxY) offsets.value = Offset(offsetX, offsetY) } } return offsets } private fun calculateOffset(normalized: Float, max: Float): Float { if (abs(normalized) < 0.05f) return 0f return normalized * normalized * sign(normalized) * max }

这段代码里的derivedStateOf也可以换，核心思想是传感器的高频数据流在LaunchedEffect里收集，转换成UI需要的最终偏移状态，不让传感器回调直接触发Composable的参数变化。

coerceIn(-1f, 1f)这一步非常重要：不同的使用场景下，用户倾斜手机的角度可能很大，如果不限制范围，偏移量会不受控制地变大，画面边缘露出底图，观感很差。限制之后，即使手机倾斜90度，位移也封顶在最大偏移量。

3.3 多层图层的位移绘制

有了偏移量，接下来就是UI层的位移绘制。这里核心是用Modifier.graphicsLayer。

直接写Modifier.offset { IntOffset(x, y) }会有两个问题：第一，offset带lambda的版本虽然不触发重组，但它只影响layout阶段的放置位置，在分层的场景里不方便做旋转和缩放；第二，offset修改的是布局尺寸占位，实际显示位置变化后，滑动容器计算滚动距离时可能出现偏差。

graphicsLayer则完全在RenderNode层面做变换，不影响布局，也不参与measure/layout，性能开销最小，而且能同时设置translationX、translationY、rotationZ、scaleX、scaleY。以下是三层图片的示例：

@Composable fun Parallax3DBanner( backgroundRes: Int, midgroundRes: Int, foregroundRes: Int ) { val viewModel: ParallaxViewModel = viewModel() val offsets = rememberParallaxOffsets(viewModel.sensorState) Box( modifier = Modifier .fillMaxWidth() .height(180.dp) .clip(RoundedCornerShape(16.dp)) ) { // 背景层 Image( painter = painterResource(backgroundRes), contentDescription = null, contentScale = ContentScale.Crop, modifier = Modifier .fillMaxSize() .graphicsLayer { translationX = offsets.value.x * 0.3f translationY = offsets.value.y * 0.3f scaleX = 1.3f scaleY = 1.3f } ) // 中景层 Image( painter = painterResource(midgroundRes), contentDescription = null, contentScale = ContentScale.Crop, modifier = Modifier .fillMaxSize() .graphicsLayer { translationX = offsets.value.x translationY = offsets.value.y scaleX = 1.2f scaleY = 1.2f } ) // 前景层 Image( painter = painterResource(foregroundRes), contentDescription = null, contentScale = ContentScale.Crop, modifier = Modifier .fillMaxSize() .graphicsLayer { translationX = offsets.value.x * 1.8f translationY = offsets.value.y * 1.8f scaleX = 1.15f scaleY = 1.15f } ) } }

关键细节：三层图片都通过scaleX/scaleY放大了一些。背景层放大30%是因为它位移后需要边缘余量；前景层放大15%因为它位移倍率高，也需要边缘余量。中景层放大20%做缓冲。这些放大比例要和图片设计师沟通，最好让设计直接给出带出血位的分层图。

3.4 完整组合与页面接入

UI组件封装好之后，业务接入就很简单了。在页面的LazyRow或普通Column里直接放Parallax3DBanner，同时确保ViewModel的生命周期跟随页面。

这里有一个很容易被忽略的点：页面被嵌套在可滚动容器里时，传感器仍然在工作，但banner滑出屏幕后应该暂停位移计算。我加了可见性判定：

@Composable fun Parallax3DBanner( backgroundRes: Int, midgroundRes: Int, foregroundRes: Int, modifier: Modifier = Modifier ) { val viewModel: ParallaxViewModel = viewModel() val lifecycleOwner = LocalLifecycleOwner.current val offsets = rememberParallaxOffsets(viewModel.sensorState) // 通过LocalRect当前位置判断是否可见 val isVisible by remember { derivedStateOf { // 这里的覆码由父级scroll状态提供 true } } DisposableEffect(lifecycleOwner) { val observer = LifecycleEventObserver { _, event -> when (event) { Lifecycle.Event.ON_START -> viewModel.startSensor(context) Lifecycle.Event.ON_STOP -> viewModel.stopSensor() else -> {} } } lifecycleOwner.lifecycle.addObserver(observer) onDispose { lifecycleOwner.lifecycle.removeObserver(observer) viewModel.stopSensor() } } if (isVisible) { Box(modifier = modifier) { /* 三层图片 */ } } }

Compose里判断可见性，简单做法是让父容器传入一个isVisible布尔值，或者用rememberLazyListState拿到layoutInfo判断banner是否在可视范围内。实际项目里我用的是父容器传入的方式，可读性更好。

提示：如果你只是在列表里放一两个这样的banner，直接接入没问题。但如果你在多个列表页都放了，最好把传感器数据抽成进程级单例，避免每个banner都注册一个传感器监听。否则页面复杂时会出现数据互相干扰，而且耗电明显上升。

4. 性能优化与交互手感打磨

4.1 用graphicsLayer而不是offset：性能关键

这是这个效果性能好坏的分水岭。传感器回调频率约50Hz，如果每次回调都触发Composable重组，画面里的三层图片都会重新执行组合，即使图片本身没有变化，Image的组合成本也不低，在低端机上很容易掉帧。

用graphicsLayer的好处在于：它修改的是RenderNode的属性，Android的RenderNode有独立的绘制缓存，属性变化只触发DisplayList的更新和重绘，不走Compose的重组流程。上面代码里graphicsLayer的lambda块由Compose在快照系统中自动追踪读取到的状态，只有translationX等参数变化时才更新RenderNode属性。

我实测的结果：在同一页放三个Parallax3DBanner，用offset时低端机滑动列表明显掉帧，换成graphicsLayer后帧率稳定在55fps以上。

4.2 边界回弹与动画平滑

前面提到线性映射在小角度时手感偏“硬”，这属于映射曲线问题。还有一个实际体验问题是“回弹”：用户突然把手机放平时，位移直接从当前位置跳回原点，画面会“抖”一下。

解决思路是给位移加动画衰减。具体做法是：在LaunchedEffect里监听偏移量变化，用animateFloatAsState或者Animatable来做过渡，而不是直接把传感器数值映射到位移：

val animatable = remember { Animatable(0f, Float.VectorConverter) } LaunchedEffect(Unit) { sensorData.collect { data -> val target = calculateOffset(data) if (abs(target - animatable.value) > 2f) { animatable.animateTo( targetValue = target, animationSpec = tween( durationMillis = 80, easing = FastOutSlowInEasing ) ) } } }

动画时间控制在80ms以内最合适：太短（小于50ms）起不到平滑作用，太长（大于150ms）会让画面有“追不上手”的滞后感。不过要注意，每次animateTo都开启一个协程，高频传感器回调下协程数量会爆炸，我最终是只有偏移目标变化超过2个像素才启动动画，这个阈值刚好能滤掉大部分微小抖动。

4.3 图片资源与内存控制

多层图片叠加对内存是实打实的压力。三张图片如果是1080p分辨率，每一层解压后大约是8MB ARGB内存，三张就是24MB，一个页面还好，多个banner同时存在时就要小心了。

我用的方案是降采样：banner显示高度180dp、宽度360dp，图片分辨率控制在1080x540就够了，不需要原图2K分辨率。加载时用painterResource配合ImageDecoder做采样，或者在资源目录直接放对应尺寸的图。

另外一个技巧是复用同一张图片的不同图层：有时候中景和背景可以是同一张图，只是裁切区域不同。比如一张带天空的小区全景图，背景取天空部分作为远景，中景取地面部分做位移，这种玩法既省内存又容易做出层次感。

4.4 传感器生命周期与耗电控制

传感器监听是持续性的硬件操作，耗电影响不可忽视。除了在生命周期里注册和注销，我还在业务层做了两个优化：

第一，页面不可见时暂停传感器。在Lifecycle.Event.ON_PAUSE时注销监听，ON_RESUME时重新注册。特别是页面退到后台时，传感器不注销会持续唤醒CPU，续航测试会发现手机温度明显升高。

第二，低端机降低采样率。高端机和低端机的传感器刷新能力不同，统一用SENSOR_DELAY_GAME在低端机上可能出现传感器事件积压，导致位移突变。可以用SENSOR_DELAY_UI（60ms）在低端机上做降频处理，效果几乎无差别。

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

5.1 传感器数据跳变与画面抖动

现象：手机静止时画面偶尔突然偏一下，然后又回正。

这类问题几乎都是传感器原始数据未经滤波导致的跳变。旋转矢量传感器在设备静置时偶尔会输出一个尖刺噪声，直接映射到位移上就是一次闪跳。我用两级防护解决了：第一级是低通滤波，alpha取0.15；第二级是“位移变化速率限制”——单次回调导致的位移变化超过最大偏移量的10%时，本次变化折半处理。简单说就是不让跳变一步到位，而是让它分两步走，视觉效果上不再突兀。

5.2 画面边缘露底图

现象：大幅倾斜手机时，前景或背景图片边缘露出底下空白，特别丑。

原因很直接：图片的出血余量不够。三张底图如果都严格做成和显示区域等大，位移超过几个像素就会露边。解决方案有两个：一是给所有图层图片四周留出30%出血位；二是在Box外层包一层和背景色一致的底色，露边时至少不是白色刺眼。我两种方案都做了，底色兜底是双保险。

5.3 不同设备表现不一致

现象：同一套代码，某台设备效果顺滑，另一台设备传感器反应迟钝。

这个问题的根源在于各家手机对旋转矢量传感器的实现质量差异大。某些机器学习影像系统的机型有额外的传感器融合算法，输出延迟相对较高；部分游戏手机的传感器刷新率上限很高，反而导致数据噪声变大。

我最终的兼容策略是：运行时检测传感器上报的刷新频率。注册监听后等待3秒，统计传感器回调次数，如果超过50Hz就用更激进的滤波参数；如果低于15Hz则启用加速度计替代。这个检测逻辑单独封装在一个SensorCompatibility.kt里，核心逻辑不复杂，主要是回调计数加定时器。

兼容性检测代码大致长这样：

val callbackCount = AtomicInteger(0) val countListener = object : SensorEventListener { override fun onSensorChanged(event: SensorEvent?) { callbackCount.incrementAndGet() } override fun onAccuracyChanged(sensor: Sensor?, accuracy: Int) {} } fun detectSensorRate(sensor: Sensor?) { sensorManager.registerListener(countListener, sensor, SensorManager.SENSOR_DELAY_GAME) Handler(Looper.getMainLooper()).postDelayed({ val rate = callbackCount.get() / 3 when { rate > 50 -> alpha = 0.08f rate > 20 -> alpha = 0.15f else -> alpha = 0.25f } sensorManager.unregisterListener(countListener) }, 3000) }

5.4 横竖屏切换时效果错乱

现象：竖屏浏览正常，旋转手机后画面位移方向不对了。

这就是前面提到的坐标系问题。旋转矢量传感器输出的欧拉角依赖设备坐标系，横竖屏切换时如果不做坐标映射，画面位移的方向就会和手机倾斜方向对不上。解决办法就是本文mapSensorToUi那段代码，拿到当前Configuration的orientation后，对X/Y分量重映射。

5.5 页面滚动时裸眼3D失效

现象：banner不滚动时效果很好，列表滑动时位移变得不跟手，动画卡顿。

这里有两个原因。第一，列表滑动时主线程繁忙，传感器回调处理被延迟，位移更新跟不上画面渲染；第二，位移状态和滑动状态在同一帧里同时变化，graphicsLayer更新频率受限于传感器回调，滑动时视觉上会有“撕裂感”。

我的处理办法是：把位移状态从主线程独立出来，用Snapshot的高级特性配合withFrameNanos在每一帧直接读取最新传感器值并应用。这算是一个进阶优化，绝大部分业务场景不需要做到这个程度，如果你的列表本身就很重，可以先用SENSOR_DELAY_UI降频，有明显改善再说。

5.6 掉了-“血腥“的坑：DisposableEffect里的sensor引用

最后分享一个我调试了很久的坑：在Composable里直接写DisposableEffect注册传感器监听时，因为Compose重组导致旧的listener被注销、新的listener被注册，如果在一个高频重组区域（比如列表滚动）做这件事，会出现传感器时断时续的效果。正确做法是把传感器监听放到ViewModel或remember的实例中，Composable只做生命周期绑定，而不是每次重组都创建新的listener。这也是我上面架构里把传感器放进ViewModel的核心原因——数据层的稳定性由实例保证，和UI重组解耦。

6. 进一步扩展：手势融合与多点触控微调

如果只是做banner效果，传感器驱动已经足够。但如果你打算把这个能力复用到图片查看器、商品展示卡片或者沉浸式首页，建议加入手势融合能力。拖拽图层时传感器位移被手势位移覆盖，松手后图层回弹并重新跟随传感器。这个交互逻辑用Compose的detectDragGestures就能实现：

@Composable fun Modifier.parallaxWithGesture( sensorOffset: Offset, onManualOffsetChange: (Offset) -> Unit ): Modifier { var manualOffset by remember { mutableStateOf(Offset.Zero) } val finalOffset = Offset( x = sensorOffset.x + manualOffset.x, y = sensorOffset.y + manualOffset.y ) return this .graphicsLayer { translationX = finalOffset.x translationY = finalOffset.y } .pointerInput(Unit) { detectDragGestures { change, dragAmount -> change.consume() onManualOffsetChange(Offset( x = (manualOffset.x + dragAmount.x).coerceIn(-MAX_MANUAL_OFFSET, MAX_MANUAL_OFFSET), y = (manualOffset.y + dragAmount.y).coerceIn(-MAX_MANUAL_OFFSET, MAX_MANUAL_OFFSET) )) } } }

手势的最大手动偏移要比传感器最大偏移小一些，比如传感器允许20dp，手势只允许12dp，这样传感器仍然占主导，手势只是辅助预览。如果两者最大偏移一样，用户拖动时会遇到明显的“力反馈”边界，体验反而不好。

再进一步，可以把双指捏合缩放也加进来。缩放时同步调整各图层的scaleX/scaleY，有一种“俯视查看细节”的体验。不过这部分会牵扯到缩放中心点计算，这里不展开，感兴趣的可以在上面代码基础上自行扩展。

整体做下来，这个效果的技术难度其实不大，真正的复杂度都藏在“手感”和“性能”这些看不见的地方。传感器数据要平滑到什么程度、位移曲线怎么设计、图层边缘留多少出血位，这些参数没有标准答案，需要拿着真机一台一台调。我给的这些数值是基于主流机型的实测结果，可以作为起始参数，但发布前一定要在目标用户群体的机型分布上做一轮真机验证。如果你在调参过程中发现更合适的组合，欢迎回头来交流。