滑动条与屏幕亮度需防抖绑定并适配双端：android需write_settings权限且设value:-1同步系统，ios无权限但无法监听变化；初始值取getscreenbrightness或fallback为0.5，临时提亮后应在onunload恢复。
不能直接用 scroll-view 滑块绑定 uni.setScreenBrightness 就完事——Android 需权限、iOS 无事件、滑动过程还容易卡顿或死循环。
滑动条怎么和亮度值双向绑定又不卡
滑动条本身只是 UI 控件，uni.setScreenBrightness 是异步 API，不能在 @change 或 @input 里每动一像素就调一次。否则：安卓上可能触发页面重绘 → 再次进入 onShow → 又调亮度 → 死循环；iOS 上虽不崩溃，但频繁 JS-Native 通信会明显延迟反馈。
- 用
@input获取实时滑动值（0–1），但只存到this.brightnessValue，不立刻调 API - 加
setTimeout防抖（300ms），等用户松手再执行uni.setScreenBrightness - 滑动过程中同步更新 UI 显示（比如旁边数字或进度条），让用户有即时反馈，但不发系统调用
- 别用
v-model直接绑，因为uni.getScreenBrightness返回的是 Promise，得先await初始化值
Android 上滑动生效必须过 WRITE_SETTINGS 这道坎
用户拖动滑块后，uni.setScreenBrightness({value: x}) 在 Android 上默认只改当前窗口亮度，系统设置条纹丝不动。想让滑块和系统真正同步，必须传 value: -1，但这需要 android.permission.WRITE_SETTINGS 权限。
-
manifest.json中必须声明"android.permission.WRITE_SETTINGS" - 运行时不能用
uni.authorize('scope.writeSettings')—— 它不支持这个 scope - 得先
uni.getSetting查res.authSetting['scope.writeSettings']，为false就必须调uni.openSetting弹系统页 - 权限未开时，滑动条可以照常拖，但调用
uni.setScreenBrightness({value: -1})会静默失败（fail回调触发，但无具体错误码）
iOS 滑动条设完就生效，但无法监听系统级变化
iOS 不需要权限，uni.setScreenBrightness({value: 0.7}) 立刻改系统亮度，退出 App 后仍保留。但问题在于：你没法知道用户是不是在别的 App 里手动调了亮度，或者自动亮度刚生效了。
-
uni.getScreenBrightness()在 iOS 上返回的是UIScreen.mainScreen().brightness，它随环境光变化，但没通知机制 - 如果要做“滑动条跟随系统当前值”，只能轮询（
setInterval+uni.getScreenBrightness），间隔建议 ≥500ms，太密会耗电 - 轮询逻辑别放 JS 层——每次调用都是一次 JS-Native 通信，应封装进原生插件，只在值真变了才
uni.$emit('brightnessChange', {value}) - 滑动条 UI 初始值不能只靠第一次
getScreenBrightness，要加 fallback：Number(res.value) || 0.5，防 undefined
滑动条松手后如何安全还原旧亮度
扫码页、投屏页等场景需要“临时提亮 → 离开时恢复”，但恢复不是简单 set 回去，平台行为差异大：
- 进入前用
uni.getScreenBrightness()获取并存入uni.setStorageSync('prev_brightness') - 离开时必须在
onUnload（不是onHide）里读取并恢复，否则可能不触发 - iOS 直接设回存储的值即可；Android 建议设
value: -1（同步系统），除非你确定上次设的就是应用内值 - 别在
onShow里自动恢复——用户切后台再切回来，onShow会触发，但此时不该干预亮度
最易被忽略的一点：Android 厂商（华为、小米）在省电模式下可能直接拦截 setScreenBrightness({value: -1})，fail 回调只告诉你“失败”，不告诉你为什么。真机测试不能只看模拟器。
