Meta 相册自动壁纸：触发语义、预取与系统限制

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

• 先确认“每次亮屏”指交互状态还是屏幕显示状态，且用户明确启用并可暂停。Android ACTION_SCREEN_ON实际是变为interactive，不保证等同屏幕电源变化。
• 训练同步相册与本地wallpaper替换分离；不保证进程被杀后能每次亮屏立即完成。目标SDK/设备策略与动态接收器生命周期需实测。

解题路线

1. 云端相册adapter只取授权媒体与版本，后台按网络/电量预算同步缩略和候选，存本地轮播队列。删除/权限撤销从候选移除，不在触发时临时下载巨大图片。
2. 触发adapter按运行中动态注册ACTION_SCREEN_ON并管理注销；官方说明此事件不能仅靠manifest receiver接收。若要判断真实显示状态，按对应平台状态查询，不把名字当定义。
3. 事件到来先去抖与lastAppliedVersion/nextImageId检查，选已预处理本地候选；bitmap按目标分辨率decode/crop，避免原尺寸内存峰值。一次应用写持久lastUsed状态，重复事件不连续换多张。
4. WallpaperManager设置动作需要SET_WALLPAPER权限并检查系统支持/设置许可，区分home/lock目标；IO/权限失败保持旧壁纸并反馈，不无限重试。用户手动更换后的覆盖策略需尊重设置。
5. 后台持久调度负责预取与重试，不用轮询代替每次screen事件。设备策略无法满足严格触发时，应明确降级为运行期间/用户主动更新，而不承诺不存在的常驻保障。

手动走一遍

相册新增A/B，先在允许网络条件下准备裁剪候选；交互事件重复两次只应用A一次。应用进程已结束时不能靠manifest SCREEN_ON假设会被唤醒，下一次运行恢复本地状态并明确未发生的轮换。

规模与取舍

下载成本按候选数量/版本变化，图片decode内存约width×height×bytesPerPixel；应用分辨率远低于原图可显著降峰值。触发响应只读本地候选与系统调用，不把网络时延计作稳定即时体验。

易错点与追问

容易失分的边界

• 每次事件做网络请求既耗电又不可靠。
• 把SCREEN_ON等同显示屏实际亮起，或声称manifest静态接收可常驻，违背接口定义。
• 缓存私密相册图未随退出/撤销清理，会泄露后续用户。

继续深挖

• 如何避免连续轮换相同图？记录可用集合版本和最近历史，缺候选时保留当前图。
• 图片方向/裁剪与设备旋转怎样处理？保留原metadata与目标配置版本，按需重新生成本地候选。