Memoria 开发记录 15：从编译开关到运行时设置——端侧 AI 能力如何真正交给用户
前言
端侧 AI 应用经常用编译参数控制功能，例如构建时决定是否启用 OCR、是否执行人脸分析、选择哪个推理后端。这种方式对开发测试很方便，却不适合真正的产品：普通用户不会为了关闭 OCR 重新安装一个 APK，也无法根据电量、隐私偏好和设备性能动态调整分析能力。
Memoria 后续将 OCR、人脸、自动分析、自动恢复和推理后端逐步迁移为运行时设置。这个过程表面上是增加几个开关，实际涉及任务调度、服务初始化、状态持久化和 UI 反馈的统一。
编译时配置为什么会失控
编译时开关通常来自 dart-define、环境变量或条件编译。它们适合控制密钥、调试入口和环境差异，但不适合用户可理解的业务行为。
以 OCR 为例，用户是否愿意分析图片文字，可能取决于隐私考虑；人脸分析则可能增加耗时和功耗。如果这些能力只能在构建时决定，就会产生多个功能不同的安装包，并让测试矩阵迅速扩大。
运行时设置的目标是：
用户修改设置-> 设置持久化-> 新任务读取最新设置-> 已运行任务按明确策略继续或重启-> UI 展示真实生效状态
设置服务必须成为唯一事实来源
提交 9fd2a6d 将 OCR 和人脸设置迁移到运行时，并新增 AiSettingsService。随后 644a121 进一步引入 AppAiSettingsService，将媒体访问、分析行为和推理选项收拢。
设置服务的价值不是封装 SharedPreferences，而是建立明确边界：
- 页面只负责展示和修改；
- 扫描或 Worker 在任务开始时读取快照；
- OCR、人脸和推理服务不再自行读取零散环境变量；
- 默认值、迁移和兼容逻辑只存在一处。
若每个服务分别读取设置，就可能出现页面显示已关闭 OCR，但后台 Worker 仍按旧值执行的状态分裂。
自动分析与自动恢复是两种不同承诺
提交 965558b 增加“自动续跑”和“自动分析新照片”。两者看似相近，实际语义不同：
- 自动恢复：应用重启后继续尚未完成的任务；
- 自动分析新照片：启动或刷新时主动发现并处理新增资产。
自动恢复强调任务连续性；自动分析强调主动性和资源消耗。用户可能愿意让已启动任务完成，却不愿每次打开应用都扫描新照片。因此设置模型必须分别表达，不能合并成一个“后台 AI”开关。
推理后端也应该可观测
提交 ca87ba8 修复 AI 推理设置和 Worker 流程，并扩展 LiteRT 会话配置。后端选择不仅要能改，还要能解释实际生效结果。
例如用户选择 GPU，但设备不支持相应 delegate，系统可能回退 XNNPACK 或 CPU。设置页若仍显示“GPU”，就会造成误导。更合理的展示应区分：
用户偏好：GPU 优先
实际后端：XNNPACK
回退原因：GPU delegate 创建失败
这类可观测性对端侧 AI 尤其重要，因为硬件和驱动差异无法仅靠开发机覆盖。
设置变更如何影响正在运行的任务
运行时配置最容易忽略的是生效时机。如果用户在分析过程中关闭人脸识别，系统应该立刻中断当前步骤，还是从下一张照片开始生效？
稳定策略通常是任务快照：
- 任务启动时读取一次设置；
- 当前任务按快照执行，避免同一批结果含义不一致；
- UI 提示设置将在下次任务生效；
- 对必须立即生效的停止类设置，走独立控制通道。
这样可以避免分析到一半时字段定义发生变化，也更容易复现问题。
总结
把 AI 功能从编译时迁移到运行时，是从技术演示走向产品能力的重要一步。它要求设置不仅“能保存”，还要与任务生命周期、实际后端和用户预期一致。
最终经验包括：
- 用户可调整的能力不应依赖重新构建；
- 设置服务必须成为唯一事实来源；
- 自动恢复与自动发现是不同产品承诺；
- 推理偏好和实际执行后端要分别展示；
- 长任务应使用设置快照，明确变更生效时机；
- 设置项必须对应真实执行步骤，不能只存在于 UI。
对应提交：9fd2a6d、644a121、965558b、ca87ba8、d9df02a。