为本地 AI 应用设计重复启动失败恢复

直接回答

崩溃循环恢复处理的是跨多次启动的重复失败，不是单次推理错误。持久保存一份最小且不含隐私的启动尝试记录，包括应用构建、选定制品身份、失败阶段以及可获得的终止原因。下次启动时，根据保守规则比较近期失败；若重复失败与模型初始化阶段有关，应先暂停重复加载同一候选，让用户能进入修复界面。提供范围明确的选项，例如查看状态、改选已知可用变体、在获准且用户同意时删除指定候选，或打开脱敏诊断。不能把“清除全部应用数据”作为首选恢复。 当前 ModelManager 明确维护模型状态，并在 loadModel 初始化失败时释放运行状态、删除当前模型文件，再返回未下载状态。这是本地源码事实，提示需要审计恢复边界；它不证明应用存在启动崩溃循环检测器、安全模式或真实的重复用户崩溃报告。进程可能在应用捕获异常之前就终止，因此单靠 try/catch 不能检测循环。除非代码有证据，不要说 Cove 当前已经提供安全启动。 在支持的 Android 版本上，ApplicationExitInfo 可以提供之前进程退出的信息和原因类别，但它不一定能识别模型是否导致退出，且不同平台版本的支持/上报也可能不同。结合可用的进程退出信息和应用自有启动标记、阶段转换，同时保留不确定性。不能把一次 low-memory 或 crash 原因当成模型制品有缺陷的证据。错误配置、运行时不兼容、存储路径缺失或无关启动异常都可能造成相似症状。 循环检测器应保守。昂贵的模型启动前写入一个尝试标记；只有应用达到明确稳定状态，才清除或推进该标记。若进程在启动中终止，下次可看见未完成尝试，但不能把用户强制停止或应用升级一律算作崩溃。记录应用版本、运行时版本、制品修订和阶段；若这几项在失败后已经变化，不应把它算成同一尝试。阈值策略必须明确且经过测试，不能发明一个适用于所有应用的通用次数。即使证据不足，也应保留人工进入恢复界面的路径。 安全启动必须避开失败组件。将模型加载延后到用户能进入设置或修复页面之后；否则应用可能在显示恢复选项前再次崩溃。架构允许时，让历史数据库可在模型未加载时单独打开。若提供清理功能，要指出确切候选文件并说明能否重新下载；不能顺带删除会话、转写、照片或偏好。如果用户改选模型或运行时，应作为另一项独立状态转换，并在策略允许时保留之前已知可用身份。 测试序列应注入各种失败：模型文件缺失、解析器拒绝、引擎初始化失败、空间不足、权限或路径不可用、启动标记前后终止、两次尝试之间应用升级，以及修复后成功启动。验证单次失败不会过早触发安全模式，重复失败不会形成无限循环，新的制品或构建版本会重置或重新分类旧尝试。保留最小诊断记录，不含提示词、模型输出、个人文件路径或凭据。恢复成功后只记录采取的操作及当前状态，不声称整体可靠性普遍提高。 ### 操作步骤 1. 定义“启动开始”和“启动稳定”的边界。保存最小标记，记录应用、运行时、制品身份和阶段，不保存用户任务内容。 2. 重启时将标记与可用的 ApplicationExitInfo 和当前版本核对。缺失或模糊的退出原因标为未知，不视为模型故障证明。 3. 达到已测试的重复失败策略时，先进入安全启动界面，再决定是否重试同一模型。架构允许时，使数据库历史独立于模型初始化。 4. 提供窄范围恢复操作，说明具体制品移除或变体变更，并保留用户记录及可用旧制品。 5. 注入单次失败、重复失败、应用升级、制品变化、存储不可用及修复成功，核对循环分类与诊断脱敏。 ### 验收标准 - 单次普通错误不会被当成重复启动崩溃循环，尝试身份包含相关应用/运行时/模型版本。 - 再次尝试相同失败加载前，用户可先进入安全启动和修复选项。 - 清理只针对准确候选且有明确用户同意，不静默删除历史。 - 未知系统退出原因保持未知，日志不含私密内容，循环检测不会无限重试。 ### 对照 | 信号 | 可支持的解释 | 仍不能得出的结论 | |---|---|---| | 单次模型加载异常 | 一次初始化失败 | 应用已经进入启动循环 | | 多次未完成启动标记 | 值得进入安全恢复评估的重复模式 | 所有退出都由模型导致 | | ApplicationExitInfo 原因 | 有此信息时的系统进程退出上下文 | 完整根因或所有 Android 版本均支持 | ### 常见问题 **一次模型初始化失败就算崩溃循环吗？**不算。崩溃循环是跨启动的重复失败。要追踪阶段与版本，并在原因不确定时保留人工恢复界面，避免误删用户数据。 **ApplicationExitInfo 能证明模型造成进程退出吗？**不能。它在受支持系统上提供进程退出上下文。要把原因关联到模型加载，还需应用阶段记录、受控复现及版本核验。 **安全模式是否应该清空应用数据？**不应该。恢复要针对明确制品或设置，并经用户同意；保护对话、笔记、录音和其他用户创建记录，不做整库清除。 **应用每次启动都该重试同一个模型吗？**重复失败且状态未变时不应如此。应限制重试、先显示修复入口，并仅在相关版本或状态变化后重新分类。

应用连续启动并在模型初始化阶段失败

用户经历一次启动失败后重新打开离线 AI 应用。选中的模型文件可能缺失、不兼容，也可能与进程退出无关。若应用每次立刻重复同一加载流程，用户可能永远到不了设置或历史界面。

决策

用阶段标记和可用的进程退出信息识别重复模式，并先展示安全启动修复界面，避免立即重试同一候选。

预期结果

用户可以查看历史并选择范围明确的恢复操作；原因不确定时保持未知，不影响无关数据。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• 启动尝试标记和应用/模型版本
• 平台进程退出上下文
• 安全启动、修复和用户数据保留测试

收到完整字节流还不够；最终落盘、完整性、运行时加载和恢复路径也必须验证。

实施流程

1. 记录最小启动尝试. 在模型初始化前记录应用构建、运行时修订、选定制品身份、当前阶段及唯一尝试标记，不保存提示词或生成内容。
2. 下次启动时核对. 检查上次尝试是否到达稳定标记，比较应用版本，并读取可用的 ApplicationExitInfo。未上报或未知原因不能标为模型损坏。
3. 重试前进入安全启动. 达到经过测试的重复失败策略后先暂停同一模型加载，让用户可进入设置、历史和恢复控制，并查看最近一次失败阶段。
4. 提供范围有限的修复. 指出要修复的准确候选或设置；保留用户历史，说明制品能否重下，不把清空应用数据作为自动回退。
5. 测试状态变化后的恢复. 注入单次失败、多次失败、应用升级、模型变化、存储路径丢失及修复成功，确认只有相关变化才会重置失败分类。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 尝试状态区分单次加载失败和重复启动失败，并记录相关版本。
• 同一模型再次加载前，用户能够进入安全启动界面。
• 修复只针对明确制品且尽量可逆，不擦除用户历史。
• 系统上报的未知退出原因保持未知，重试有上限且日志脱敏。

决策对照表

需要避免的失败模式

• 把单次异常当成崩溃循环
• 重新启动时无条件重复加载同一坏候选
• 把清空应用数据作为第一种恢复方式

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• Android ApplicationExitInfo 进程退出信息
• Android Activity 生命周期
• Android 进程生命周期

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题