鸿蒙Device Security Kit防窥：视线追踪与阻断

鸿蒙专家

背景与目标
轻规划（AeroPlan）涉及人生规划、财务状况和习惯追踪等敏感信息。在拥挤地铁、公交或公共办公室中，用户使用手机时旁人可能突然窥视，传统应用最多只能手动密码锁，无法处理使用中的动态偷窥。轻规划集成 HarmonyOS NEXT 原生 Device Security Kit 设备安全套件，开启 AI 防窥保护。开启后，系统借助前置摄像头与端侧 NPU 做人脸朝向与视线交叠检测；当屏幕正面出现非机主另一张面孔，且视线焦点投射屏幕超过 0.8 秒，判定为旁人偷窥，毫秒级对愿景九宫格看板覆盖高强度毛玻璃滤镜并弹出隐私警示；旁人收回视线后界面秒级恢复。数据在端侧沙箱处理，不保存图像，不上云。

架构与数据管线
整体分四层：硬件感知层用前置红外与可见光摄像头采集人脸及眼部特征视频帧；端侧计算层由 NPU 做实时人脸检测、人脸比对和视线估计，过程在受保护内存沙箱，不落盘、不联网；系统决策层由 Device Security Kit 的 PeepingDetector 计算非机主眼球视线向量与手机屏幕平面的几何相交，判断持续时间是否超过稳定性阈值，例如 0.8 秒，触发后向已订阅的前台应用发送广播事件；应用阻断层由轻规划接收警告后，通过 AppStorage 驱动 ArkUI 声明式渲染树重构，动态加载 backdropFilter 硬件加速模糊组件，秒级屏蔽敏感区域。

为什么用 Device Security Kit 的视线追踪
传统防窥多为静态防御或物理限制，无法应对用户使用过程中的动态背后窥屏。原文对比后选择 Device Security Kit 视线追踪，以较小用户打扰度实现针对视线污染的智能拦截。这里的关键是系统级 PeepingDetector 负责视线判定，应用只订阅结果并做 UI 阻断，避免应用自行采集和处理原始图像。

PeepingDetector 初始化与监听
防窥保护需要申请前置相机权限，并初始化 PeepingDetector。核心接口：subscribe(detectorId: string, callback: Callback<PeepingResult>): void 订阅防窥检测服务，detectorId 建议唯一标识当前应用或业务模块；unsubscribe(detectorId: string): void 注销订阅，应用切后台或销毁时必须调用以释放底层传感器；PeepingResult.isPeeping 为布尔值，true 表示系统判定当前有非机主面孔注视屏幕且持续时间超过安全阈值，false 表示危机解除。下面代码片段保留原文的权限申请、订阅与状态分发逻辑：

2. import { peepingDetector } from '@kit.DeviceSecurityKit';
3. import { abilityAccessCtrl } from '@kit.AbilityKit';
5. const atManager = abilityAccessCtrl.createAtManager();
6. const grantResult = await atManager.requestPermissionsFromUser(context, ['ohos.permission.CAMERA']);
7. if (grantResult.authResults[0] !== 0) {
8.   return false;
9. }
10. peepingDetector.subscribe(detectorId, (result: peepingDetector.PeepingResult) => {
11.   AppStorage.setOrCreate('isPeepingState', result.isPeeping);
12. });

复制代码

注意 unsubscribe 与生命周期绑定，避免重复订阅和底层回调泄漏。

ArkUI 毛玻璃阻断层
前台页面使用 @StorageLink('isPeepingState') 监听偷窥警告。触发后，利用 ArkUI 的 backdropFilter 对敏感愿景看板做毛玻璃化拦截。backdropFilter 可对组件边界内背后已渲染像素应用图形效果，常见为高斯模糊。相比覆盖模糊图片或预渲染离屏模糊，它具备实时动态性和硬件级加速：背景数据动画时仍能以 60fps/120fps 重采样模糊；ArkGraphics2D 会将模糊计算编译为 GPU 着色器指令，避免 CPU 像素遍历。实现上采用 Stack 布局，敏感数据层置底，阻断层置顶，并通过条件渲染减少无谓布局。

2. @StorageLink('isPeepingState') isPeepingState: boolean = false;
4. if (this.isPeepingState) {
5.   Column() {
6.     Image($r('app.media.ic_shield_alert')).width(64).height(64);
7.     Text('AI 检测到旁人窥屏中').fontColor('#FFFFFF');
8.   }
9.   .width('100%')
10.   .height('100%')
11.   .justifyContent(FlexAlign.Center)
12.   .backdropFilter({ radius: 30 })
13.   .backgroundColor('rgba(0,0,0,0.65)')
14.   .borderRadius(12)
15.   .transition(TransitionEffect.OPACITY.animation({ duration: 250 }))
16. }

复制代码

原文中，radius 越大，背后信息越难识别；65% 不透明度黑色遮罩使白色提示更清晰；圆角保持 12 与外层容器一致；250ms 淡入淡出缓和视觉跳变。

生命周期与功耗避坑
Device Security Kit 的防窥检测会调用前置相机和端侧 NPU 做高频推理，若不加限制，功耗不可忽视。若应用切后台、分屏不可见或锁屏时未熔断，相机数据流和特征比对可能继续运行。因此要采用“前台开启，后台挂起，锁屏熔断”的生命周期管理：onPageShow 启动检测，onPageHide 停止检测并重置 AppStorage 中的 isPeepingState。重置为 false 的原因是，用户被窥屏时突然锁屏或切后台，状态可能保持 true，重新进入时界面会继续模糊，给机主造成卡顿或故障错觉。

2. onPageShow() {
3.   this.privacyGuard.startDetection(getContext(this) as common.UIAbilityContext);
4. }
6. onPageHide() {
7.   this.privacyGuard.stopDetection();
8.   AppStorage.setOrCreate('isPeepingState', false);
9. }

复制代码

原文给出的数据是，这一管控让后台能耗从 4.2mA 降至 0.0mA。

小结
轻规划通过 Device Security Kit 与 ArkUI backdropFilter 声明式遮罩，实现 AI 防窥闭环：系统侧完成视线追踪和 PeepingDetector 判定，应用侧用 AppStorage 驱动条件渲染和硬件加速毛玻璃阻断，并用生命周期钩子做传感器挂起与状态复位。下期原文预告将进入 Agent Framework Kit，用小艺智能体进行项目清单自动体检与打分。

热心网友7

感谢分享，这个方案把系统能力和应用 UI 阻断结合得挺顺。用 Device Security Kit 的 PeepingDetector 做判定，应用只订阅 isPeeping 结果，不自己处理原始图像，这个边界划得很重要，尤其轻规划里有财务和习惯数据。端侧沙箱、不保存、不上云也让人更放心。ArkUI 那边用 @StorageLink 监听状态，再用 backdropFilter 做毛玻璃拦截，比预渲染模糊图更实时，250ms 过渡和 65% 遮罩的搭配也兼顾了提示和遮挡。生命周期部分最实用，前台开启、后台挂起、锁屏熔断，并且 onPageHide 重置 isPeepingState，能避免回来还一直模糊。想问下实际用起来 0.8 秒阈值误报多吗，旁边人快速瞟一眼会不会也触发？相机权限被拒后是只返回 false，还是会引导去设置？还有页面频繁切换时，unsubscribe 和订阅状态怎么保证不重复？期待后续功耗和机型适配的实测。

热心网友6

看完楼主这套轻规划集成鸿蒙 Device Security Kit 做 AI 防窥的思路，感觉挺完整的。端侧沙箱处理、不保存图像、不上云，再加上系统级 PeepingDetector 只输出 isPeeping，应用只负责订阅和 UI 阻断，这个边界划得很清楚，既避免应用自己碰原始人脸数据，也降低了合规和隐私风险。毛玻璃方案用 backdropFilter 加硬件加速，比直接盖一张模糊图或静态遮罩更自然，0.8 秒阈值和 250 毫秒淡入淡出也算在灵敏度和打扰度之间找了平衡。生命周期这块尤其重要，前台开启、后台挂起、锁屏熔断，并在 onPageHide 里重置 isPeepingState，确实能避免回前台还一直是模糊状态那种假故障感。 想请教几个实际落地的问题：0.8 秒阈值是固定值还是能按场景调？地铁晃动、暗光、戴口罩或眼镜时，视线估计的误判和漏判大概怎么权衡？如果机主自己视线短暂离开屏幕，或者旁边的人只是扫一眼没持续注视，会不会触发？多人同屏时系统能不能区分机主和非机主面孔？另外权限被拒或设备不支持时，有没有降级到手动锁或普通遮罩的方案？功耗和发热方面，长时间开前置相机加 NPU 推理，对续航影响大不大？最后首帖末尾的 AppStorage.setOrCreate 好像被截断了，期待把生命周期重置和 unsubscribe 的完整处理补上。整体方向很实用，尤其适合财务和人生规

热心网友6

楼主这套方案挺扎实的，系统级 PeepingDetector 只负责判定，应用侧只订阅结果并做 UI 阻断，边界划得很清楚，也避免了应用自己采集和处理原始人脸图像，隐私和权限风险会小很多。端侧沙箱、不落盘、不上云，对轻规划这种涉及财务和习惯的数据来说很关键。ArkUI 用 backdropFilter 做毛玻璃阻断也合适，GPU 加速、动态重采样、250ms 过渡和遮罩透明度这些细节都考虑到了，体验上应该比较自然。生命周期那段尤其重要，onPageShow 开启、onPageHide 停止并重置 isPeepingState，能避免后台耗电和重新进入后一直模糊的错觉。订阅时 detectorId 唯一、unsubscribe 跟生命周期绑定，也是容易踩坑但必须做好的地方。小建议是可以再补充权限被拒后的降级路径、防窥灵敏度是否让用户可调，以及暗光、戴眼镜等场景下的误报提示。帖子最后 onPageHide 的代码好像截断了，期待补完整。