8、光线传感器实战：环境光检测、自动亮度调节实现、光线传感器在AR中的应用、多场景适配
光线传感器，说白了就是手机那颗「感光小眼睛」。它藏在屏幕上方，默默感知周围的光线强度。我最早接触它是在做一款阅读App的时候，那时候才发现——原来这个小小的传感器，能玩出这么多花样。
今天咱们就把它彻底聊透。从最基础的环境光检测，到自动亮度调节的坑，再到AR场景里的骚操作，最后聊聊多场景适配的那些破事儿。
8.1 环境光检测：从拿到数据开始
先看最基础的操作。获取光线传感器的数据，其实就三步：
// 获取传感器管理器
SensorManager sensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);
// 获取光线传感器
Sensor lightSensor = sensorManager.getDefaultSensor(Sensor.TYPE_LIGHT);
// 注册监听器
sensorManager.registerListener(lightSensorListener, lightSensor, SensorManager.SENSOR_DELAY_NORMAL);嗯，这里要注意——getDefaultSensor 可能返回 null。我遇到过一台低端平板，光线传感器直接被砍掉了。所以一定要判空：
if (lightSensor == null) {
// 没有光线传感器，走降级方案
// 比如直接用摄像头测光，或者干脆给个默认值
}监听器里拿到的 event.values[0] 就是光照强度，单位是 lux。这个值大概什么概念？我整理了一张表：
| 场景 | 光照强度 (lux) |
|---|---|
| 深夜室内 | 1 - 10 |
| 普通室内灯光 | 100 - 500 |
| 办公室日光灯 | 300 - 800 |
| 阴天室外 | 1000 - 5000 |
| 晴天室外 | 10000 - 100000 |
我个人习惯拿到原始数据后，先做一次平滑滤波。因为光线传感器的原始数据跳得很厉害，尤其是你在灯光下晃一下手机，数值能瞬间翻倍。用个简单的滑动平均就行：
private float smoothLightValue(float newValue) {
// 维护一个长度为5的队列
if (lightHistory.size() >= 5) {
lightHistory.poll();
}
lightHistory.offer(newValue);
float sum = 0;
for (float v : lightHistory) {
sum += v;
}
return sum / lightHistory.size();
}SENSOR_DELAY_UI 这个采样率。太快了反而没用，因为用户肉眼根本感知不到毫秒级的变化。
8.2 自动亮度调节：别让用户骂娘
自动亮度调节，听起来简单——光线暗就降亮度，光线亮就提亮度。但实际做起来，坑多到你怀疑人生。
我曾经做过一个自动亮度方案，上线第一天就被用户喷成筛子。问题出在哪？
- 变化太突兀： 从室内走到室外，亮度瞬间拉满，用户眼睛被闪瞎
- 来回震荡： 在窗户旁边，光线忽明忽暗，屏幕跟着忽亮忽暗，像抽风一样
- 忽略用户手动调节： 用户手动调了亮度，系统又给改回去了
怎么解决？我总结了一套「三段式」策略：
第一段：死区处理
光线变化在一定范围内，不做任何响应。比如变化幅度小于20%，直接忽略。这能过滤掉大部分噪声。
if (Math.abs(newLux - currentLux) / currentLux < 0.2f) {
return; // 变化太小，忽略
}第二段：缓动曲线
不要直接跳到目标亮度。用插值的方式，花个几百毫秒慢慢过渡。我习惯用 ValueAnimator：
ValueAnimator animator = ValueAnimator.ofFloat(currentBrightness, targetBrightness);
animator.setDuration(500); // 500ms过渡
animator.addUpdateListener(animation -> {
float value = (float) animation.getAnimatedValue();
setScreenBrightness(value);
});
animator.start();第三段：用户优先级
如果用户手动调节了亮度，系统自动调节应该暂停一段时间。我一般设个30秒的冷却期：
// 用户手动调节时，记录时间戳
private long lastManualAdjustTime = 0;
public void onUserAdjustBrightness(float brightness) {
lastManualAdjustTime = System.currentTimeMillis();
setScreenBrightness(brightness);
}
// 自动调节前检查
if (System.currentTimeMillis() - lastManualAdjustTime < 30_000) {
return; // 用户刚调过，别捣乱
}Settings.System.SCREEN_BRIGHTNESS 的写入，需要 WRITE_SETTINGS 权限。而且从 Android 9 开始，系统对自动亮度的干预越来越多，第三方App的调节效果可能被系统覆盖。我的建议是——只调节自己App内的亮度，别碰系统亮度。
8.3 光线传感器在AR中的应用
AR场景里，光线传感器的作用被很多人低估了。你想想看——AR是把虚拟物体叠加到现实画面上。如果现实环境很暗，虚拟物体却亮得刺眼，那画面就假得没法看。
我参与过一个AR家居App，用户把虚拟沙发放到客厅里。问题来了：
- 白天阳光充足，虚拟沙发看起来太暗，像蒙了一层灰
- 晚上开灯，虚拟沙发又太亮，跟环境格格不入
解决方案其实不复杂——根据环境光动态调整虚拟物体的亮度、阴影和反射强度。
// 根据环境光调整虚拟物体的亮度
float ambientLightLux = event.values[0];
// 映射到0.3 - 1.0的范围
float brightnessFactor = clamp(ambientLightLux / 10000f, 0.3f, 1.0f);
// 应用到AR物体的材质上
arObject.setAmbientLightIntensity(brightnessFactor);
arObject.setShadowOpacity(brightnessFactor * 0.8f);还有一个骚操作——用光线传感器判断「用户是否在室内」。室外光线通常 > 10000 lux，室内通常 < 1000 lux。这个判断可以用来切换AR的渲染模式：
| 环境 | 渲染策略 |
|---|---|
| 室内 ( < 1000 lux ) | 使用柔和光照，开启环境光遮蔽 |
| 室外 ( > 10000 lux ) | 使用高动态范围光照，增强阴影对比 |
| 过渡区 | 线性插值，平滑切换 |
8.4 多场景适配：别让代码跑崩了
最后聊聊适配。光线传感器在不同设备上的表现，差异大得离谱。
我踩过最大的坑——某款国产手机的光线传感器，采样频率只有1Hz。你这边注册了 SENSOR_DELAY_FASTEST，它那边一秒才给你一个值。代码里如果没做超时处理，整个自动亮度逻辑就废了。
我的适配清单：
- 传感器不存在： 必须判空，准备降级方案。比如用摄像头测光，或者直接给个默认值
- 采样率不一致： 不要依赖固定的采样间隔。用时间戳自己算，或者用
onSensorChanged的timestamp字段 - 数值范围差异： 有些传感器的最大值是 10000 lux，有些能到 100000 lux。做映射时别写死
- 屏幕遮挡： 手机贴脸打电话时，光线传感器被遮挡，数值会骤降到接近0。自动亮度调节要识别这种场景，别傻乎乎地把屏幕调暗
// 检测是否被遮挡（比如打电话）
private boolean isProximityBlocked(float lux) {
// 光线突然降到 5 lux 以下，且持续超过 2 秒
if (lux < 5f) {
if (blockedStartTime == 0) {
blockedStartTime = System.currentTimeMillis();
} else if (System.currentTimeMillis() - blockedStartTime > 2000) {
return true;
}
} else {
blockedStartTime = 0;
}
return false;
}还有一个容易被忽略的点——传感器校准。有些设备用久了，光线传感器的读数会漂移。我见过一台平板，放在暗房里还显示 200 lux。这种情况，要么引导用户校准，要么在代码里加个偏移量补偿。
好了，光线传感器这块，能聊的差不多就这些。从拿到原始数据，到做自动亮度，再到AR里的光影匹配，最后到多设备适配——每一步都有坑，但也都有解法。你动手做一遍，比我在这说十遍都管用。