适合谁看想判断鸿蒙防窥能力落点的人做内容型、工具型、隐私型页面设计的人不想为了展示能力而牺牲体验的人问题背景系统能力一旦接进项目大家很容易出现两个极端什么页面都不接什么页面都接真正合理的做法是让能力只出现在它真正有价值的页面。项目中的真实场景食界探味当前的防窥命名已经给了一个很强的信号// anti_peep_protection_channel.dart static Futurevoid activateCollectionProtection() async { await _invoke(activateCollectionProtection); } static Futurevoid deactivateCollectionProtection() async { await _invoke(deactivateCollectionProtection); }方法名里的Collection说明它优先面向收藏页。激活时机在app.dart的底部导航栏管理中_scheduleCollectionProtectionSync( isLoggedIn widget.navigationShell.currentIndex 2, // index 2 收藏页 );只有用户切到收藏页index 2且已登录时才激活防窥。核心实现一、适合接入防窥的页面页面为什么适合防窥价值收藏页展示用户收藏的菜品暴露个人口味偏好高心愿单页展示用户想吃的菜品暴露个人兴趣高个人资料页展示用户名、头像、个人设置中高订单/历史页展示用户消费记录高AI 对话历史展示用户和 AI 的对话内容中高这些页面的共同特点内容和个人身份、偏好、消费行为强关联。被旁人看到可能造成真实困扰。食界探味当前选择收藏页作为防窥对象原因很明确收藏页的内容 - 用户收藏了哪些菜品 → 暴露口味偏好 - 用户喜欢哪个国家的菜 → 暴露饮食习惯 - 用户收藏的频率和时间 → 暴露生活规律 被旁人看到的后果 - 你怎么收藏了这么多日料 → 尴尬 - 你居然喜欢这个 → 隐私暴露二、不适合接入防窥的页面页面为什么不适合防窥价值首页/探索页公共推荐内容和个人无关无搜索页搜索结果是公共数据无菜品详情页展示的是公共菜品信息无食材列表页公共食材数据无风味地图页公共地理数据无关于页/设置页不涉及个人数据无这些页面即使不开防窥实际风险也不高。如果强行开启反而会打断用户浏览公共内容的体验增加不必要的系统开销让用户困惑为什么看个菜谱还要防窥三、判断框架——3 个问题判断一个页面是否适合接入防窥问自己 3 个问题问题是 → 适合否 → 不适合这里展示的内容是否明显带有用户偏好适合不适合被旁人看到会不会造成真实困扰适合不适合开启防窥后会不会明显打断主要操作不适合适合三个条件需要同时满足前两个是且第三个否才值得接。用这个框架检验食界探味的收藏页问题收藏页探索页内容带有用户偏好✅ 是❌ 否被看到有困扰✅ 是❌ 否会打断操作❌ 否只是隐藏内容❌ 否结论✅ 适合❌ 不适合四、食界探味的页面分析食界探味当前的主要页面页面Tab个人数据防窥适合度探索页首页无❌ 不适合灵感页Tab 2无❌ 不适合收藏页Tab 3有收藏的菜品✅ 适合我的页Tab 4有个人资料⚠️ 可考虑AI 助手页独立页有对话历史⚠️ 可考虑搜索页独立页无❌ 不适合菜品详情页独立页无❌ 不适合食材详情页独立页无❌ 不适合当前只在收藏页激活防窥这是一个合理的起点。未来可以考虑扩展到 AI 助手页对话历史可能暴露用户兴趣。五、为什么不应该全局开启全局开启防窥的问题问题说明体验断裂用户看个菜谱都要被遮罩体验很差系统开销鸿蒙一直监听防窥事件浪费资源用户困惑为什么这个页面也要防窥误触发公共内容被遮罩用户以为 app 出 bug 了比赛扣分评委看到全局防窥会质疑产品判断力六、防窥的激活时机设计食界探味的激活时机设计// app.dart → _ScaffoldWithNavBarState void _scheduleCollectionProtectionSync(bool shouldProtect) { if (_lastCollectionProtectionTarget shouldProtect) return; _lastCollectionProtectionTarget shouldProtect; WidgetsBinding.instance.addPostFrameCallback((_) { if (!mounted) return; if (shouldProtect) { AntiPeepProtectionChannel.activateCollectionProtection(); } else { AntiPeepProtectionChannel.deactivateCollectionProtection(); } }); }调用时机用户切 Tab │ ├─ currentIndex 2收藏页→ activate ├─ currentIndex ! 2 → deactivate │ ▼ 页面退出 │ └─ dispose() → deactivate确保取消这个设计保证了只在收藏页时激活其他页面不激活切走时立即取消不残留退出时兜底取消不泄漏七、防窥和页面体验的平衡防窥保护会增加一层被监控感。所以在设计时需要平衡维度好的设计差的设计激活范围只在敏感页面全局所有页面用户感知自然无感突然出现蒙层退出处理切走即取消需要手动关闭内容处理隐藏敏感内容遮住整个屏幕系统提示不打扰用户弹窗提醒已开启防窥食界探味当前的做法是进入收藏页自动激活离开自动取消用户完全无感。这是最好的体验。八、如果要扩展到更多页面如果以后要在更多页面接入防窥建议按敏感度分级— 收藏页 AI 对话 个人资料 其他渐进式扩展— 先收藏页验证效果后再扩展保持按需激活— 永远不要全局常驻页面级控制— 每个页面自己决定是否需要防窥关键代码位置文件作用app/lib/core/platform/anti_peep_protection_channel.dart防窥通道app/lib/app.dart页面级激活/取消防窥app/ohos/entry/src/main/ets/plugins/AntiPeepProtectionPlugin.ets鸿蒙原生插件常见坑为了展示能力对所有页面全局开启— 体验断裂评委质疑只从比赛展示角度判断不从用户场景判断— 用户不需要看菜谱时防窥页面敏感度其实不高却引入了额外交互打扰— 公共内容不需要防窥没有退出页面后的关闭逻辑— 防窥残留影响后续页面没有检查用户是否已登录— 未登录时没有个人数据不需要防窥防窥和页面动画冲突— 蒙层出现时页面正在转场体验差可复用模板页面防窥判断模板判断页面是否需要防窥 □ 内容是否带有用户偏好/个人数据 □ 被旁人看到是否造成真实困扰 □ 开启后是否打断主要操作 □ 用户是否有明确的隐私预期 4 个是→ 适合 3 个是→ 考虑 2 个及以下 → 不适合页面级防窥激活模板class SensitivePage extends StatefulWidget { override StateSensitivePage createState() _SensitivePageState(); } class _SensitivePageState extends StateSensitivePage { override void initState() { super.initState(); AntiPeepProtectionChannel.activateCollectionProtection(); } override void dispose() { AntiPeepProtectionChannel.deactivateCollectionProtection(); super.dispose(); } override Widget build(BuildContext context) { return ValueListenableBuilderAntiPeepVisibilityState( valueListenable: AntiPeepProtectionChannel.visibilityState, builder: (context, state, child) { if (state AntiPeepVisibilityState.hidden) { return const SafePlaceholder(); } return child!; }, child: const SensitiveContent(), ); } }Tab 级防窥激活模板// 根据当前 Tab 决定是否激活 void syncProtection(int currentIndex) { final shouldProtect currentIndex SENSITIVE_TAB_INDEX; if (shouldProtect) { AntiPeepProtectionChannel.activateCollectionProtection(); } else { AntiPeepProtectionChannel.deactivateCollectionProtection(); } }本篇总结防窥能力应该按页面价值接入而不是按能接就接。核心判断标准内容敏感度— 是否带有用户偏好和个人数据暴露后果— 被旁人看到是否造成困扰体验影响— 开启后是否打断主要操作食界探味当前只在收藏页激活防窥是因为收藏页是整个 app 中个人数据最集中、隐私敏感度最高的页面。探索页、搜索页、详情页都是公共内容不需要防窥。对系统能力做业务筛选本身就是成熟项目的一部分。能接不代表该接选择在哪里接、不在哪里接体现的是产品判断力。