uni.onAccelerometerChange需先调用uni.startAccelerometer启用传感器，iOS须在manifest.json勾选“运动与健身”权限；判断摇一摇应计算加速度模长变化率，双阈值判定（模长>18且变化率>30）更可靠。
uni-app 中如何正确调用 uni.onAccelerometerChange 监听摇一摇
App 端（iOS/Android）能用，但 H5 和小程序端行为不一致甚至不可用——这是最常踩的坑。摇一摇本质是检测加速度突变，uni.onAccelerometerChange 是唯一可用的原生级接口，但它默认**不自动开启传感器**，必须先调用 uni.startAccelerometer，否则监听器完全不会触发。
实操建议：
- 务必在
onShow或用户明确触发动作（如点击“开启摇一摇”按钮）后才调用uni.startAccelerometer，避免冷启动时权限拒绝或后台被系统休眠中断 - 监听回调中不要直接做重逻辑（如跳转、弹窗），先用节流（例如 500ms 内只响应一次）防抖动误触
- iOS 真机需在
manifest.json → App SDK 配置 → iOS 模块权限中勾选「运动与健身」，否则静默失败，无错误提示
怎么判断“摇一摇”而不是普通晃动
加速度原始值（x/y/z）本身没意义，关键看变化率。单纯比较绝对值 > 2.5 或类似阈值，在不同手机、握持姿势下误判率极高。真正可靠的做法是计算**加速度矢量模长的变化斜率**。
实操建议：
- 缓存最近 3–5 帧的
Math.sqrt(x*x + y*y + z*z)值，用差分近似瞬时加速度变化率 - 设定双阈值：模长峰值 > 18（单位 m/s²，接近 1.8g）且变化率 > 30（单位 m/s³），同时满足才视为有效摇动
- Android 部分低端机采样率低（interval: 'game' 参数（需 HBuilderX 3.1.22+）提升精度：
uni.startAccelerometer({ interval: 'game' })
App 后台运行时还能监听摇一摇吗
不能。iOS 和 Android 均限制后台加速度计采集：iOS 会自动停止传感器，Android 大部分厂商（华为、小米等）在应用退至后台 10–30 秒后强制停用。这不是 uni-app 的限制，而是系统级策略。
实操建议：
- 在
onHide生命周期里主动调用uni.stopAccelerometer，避免资源泄漏和日志报错 - 不要尝试用后台静默任务（如
uni.getBackgroundAudioManager）绕过限制——加速度计无法在后台恢复 - 若需“锁屏摇一摇”，必须引导用户保持前台，或改用 NFC/蓝牙外设等替代方案
真机调试时 onAccelerometerChange 不触发的常见原因
不是代码写错了，大概率是环境或配置问题。HBuilderX 调试基座、手机系统权限、开发模式都会影响。
排查顺序：
- 确认真机已开启「体感」「运动传感器」系统权限（Android 设置 → 应用权限；iOS 设置 → 隐私 → 运动与健身）
- 检查 HBuilderX 运行的是「自定义调试基座」还是「标准基座」——标准基座可能未集成完整传感器模块，换为自定义基座再试
- 在回调里加
console.log，并打开 HBuilderX 的「真机运行日志」面板，确认是否输出了原始加速度数据；若无任何日志，说明startAccelerometer调用失败，需查fail回调 - 某些 Android 12+ 设备需额外在
android/app/src/main/AndroidManifest.xml中声明：
加速度计不是开关式 API，它依赖硬件、系统、基座三者协同。哪怕参数全对，缺一个环节就静默失效——这点比网络请求难调试得多。
