直接回答
本地模型是某个功能的依赖，不应成为整个应用外壳绘制的前置条件。Android 官方建议避免在主线程执行昂贵工作，因为阻塞会让界面无法响应。LiteRT-LM 的 Kotlin 入门资料也说明引擎初始化可能耗时，建议放在后台执行。实际设计应先显示有用且诚实的应用外壳，再把模型就绪作为独立状态，由明确的所有者控制。“应用打开”“找到了模型文件”“引擎完成初始化”和“任务能够开始”是不同条件；若最后一个必要条件尚未满足就显示完全就绪按钮，用户会在点击后遇到难以理解的失败。 先定义不依赖推理的首屏内容。它可以展示导航、功能说明、空状态和模型状态卡，但不能暗示一个尚未就绪的能力。状态可以包括检查存储、校验选中的模型、初始化引擎、已就绪、被阻止、失败和已取消。每种状态都应绑定明确的模型制品身份及操作 ID。不能以加载动画消失来推断可用。由进程级或功能级协调器串行执行初始化并发布状态；Composable 应观察状态，而不是在每次重新组合时创建 Engine。 将加载放在完整的用户旅程中测试，而不只是看秒表。分别在模型不存在、已存在、不完整和不可访问的环境安装应用；在初始化期间进入功能、旋转屏幕、按产品规则尝试取消，并注入可控的初始化错误。确认模型不可用时首屏仍能响应，只有依赖推理的操作被禁用。加载失败应保留重试路径，并且不能破坏无关导航。只有在准确界定事件边界并使用合适的基准工具时才记录时间；本文不宣称任何设备的启动或推理耗时。 最重要的转换是“就绪”变成“未就绪”。模型文件可能被移除、验证失败或被替换；引擎也可能因为明确的生命周期事件关闭。每项推理任务开始前，协调器应确认当前制品和 runtime 满足任务前置条件。如果初始化已在进行，其他界面应观察现有过程，而不是创建第二个引擎。如果应用进入后台或进程被重建，应根据持久状态显示界面，并在需要时重建 native 状态；不能把保存下来的布尔值当成仍然存活的引擎。 可访问性和错误状态也是首屏契约的一部分。应说明正在检查模型、模型不可用、需要用户操作或初始化失败，并给出简短下一步；不要暴露私人提示内容或本地文件路径。如果应用没有经核实的公开下载渠道，缺少模型时不能暗示 Cove 有可下载文件。现有事实只支持显式 ModelManager 生命周期的测试方法，不能证明每个产品都有统一安装流程。因此本文是设计和验证方式，不是 Cove 发布状态或兼容性的声明。 界面就绪与模型性能分析必须分开。Macrobenchmark 可以测量用户可感知的应用流程；模型本身的计时则需明确模型文件验证、引擎初始化、请求提交和首个有效输出等边界。先绘制外壳能改善界面连续感，却不会因此改变推理速度。反过来，首屏迅速出现也不能证明模型能加载或完成任务。版本说明和监控面板应分开表达这些结论。 模型尚未就绪时，降级行为要真实。若文字输入可以安全保存成草稿而无需推理，可以保留该入口；如果没有可执行的图像任务，相机按钮就不该看起来已经可以完成分析。被阻止的任务要解释缺少什么条件；除非用户知情，不要悄悄排队等待未来运行。前置条件变化后，由 runtime owner 更新状态，再由用户启动操作。这样既避免重复任务，也使加载状态在没有性能宣传时依然易懂。 也要测试连续状态变化。如果用户在模型初始化过程中离开页面又返回，第二个界面应订阅相同的状态源；它不应重复占用 native 资源。如果校验发现制品被替换，应让旧版本的就绪状态失效，并显示新的校验流程。展示层最好显示用户可理解的类别，而不是异常堆栈。日志可以留操作阶段、错误类型和制品 ID，但不得在未经必要性评估的情况下写入用户文档或音频内容。 验收报告至少分开陈述首屏交互、模型文件检查、引擎初始化和某个具体任务是否成功。没有原始测量记录时，不给出耗时数字，也不把一次成功扩展成“所有设备都支持”。对于暂时不能推理的情形，说明用户能继续浏览还是必须等待；对无法恢复的情况，说明何时需要显式重试。一个边界清楚的状态机比单一“加载中”标签更能帮助用户判断发生了什么。
应用已打开，但本地模型尚不可用
用户首次启动离线图片助手。导航外壳已可见，但模型文件校验和 native 引擎初始化尚未完成；用户马上点击相机分析。
决策
立即显示导航与真实就绪状态，只在相关前置条件确认后启用依赖推理的操作。
预期结果
界面保持清楚和可响应，且不会对不存在或未初始化的 runtime 发起任务。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- COVE-LIFECYCLE-01：事实卡记录显式 ModelManager 生命周期状态；不证明每个产品的安装和初始化流程。
- BENCHMARK-01：基准结论需绑定明确任务、软件和原始测量边界；首屏渲染不能替代推理证据。
只有记录了模型身份、构建配置、实际后端、任务样例和失败情况，运行时比较才可复核。
实施流程
- 定义首屏可独立提供的功能. 列出不依赖模型即可展示的导航、说明、草稿和状态。只禁用确实缺少推理前置条件的操作，不让整个应用等待模型。
- 将模型就绪拆成明确状态. 分别定义检查存储、验证制品、引擎初始化、就绪、被阻止、失败和取消状态，并绑定制品身份及 runtime owner，而非依靠动画或持久布尔值。
- 让专属所有者在后台初始化. 由应用或功能协调器在非主线程执行初始化。界面组合只观察状态；不能把 native Engine 创建或初始化作为 Composable 副作用。
- 覆盖缺失和失败前置条件. 测试缺失、不完整、不可访问和替换的模型，以及可控初始化失败。导航继续可用，任务操作解释阻塞原因，重试不产生重复引擎。
- 把就绪证据与时间指标分开. 记录完成了哪种状态转换以及制品/runtime 身份。若发布耗时，必须命名起止事件并使用合适基准；首帧不证明模型已就绪或推理快。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 首屏区分应用外壳、模型文件、引擎初始化与任务就绪。
- 模型初始化不在 Compose 重组中执行，也不阻塞主线程。
- 缺少或失败的模型条件不隐藏无关导航，并解释推理操作所需的下一步。
- 每个任务都验证当前 runtime 状态；陈旧布尔标志不能代表已关闭或已替换的引擎。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 应用外壳可绘制但没有模型 | 显示外壳与不可用状态 | 导航可继续使用，不暗示推理已准备好。 |
| 文件存在但引擎正在初始化 | 显示初始化状态并暂缓任务入口 | 模型文件存在不等于 runtime 已加载。 |
| 引擎满足某项任务条件 | 启用该任务并绑定当前制品 | 就绪是具体操作的前置条件，不是所有任务的普遍保证。 |
需要避免的失败模式
- 模型未加载就显示功能完全可用，或因模型初始化阻塞整个应用首屏。
- 把文件存在、引擎初始化和任务可运行当成同一状态，或将首帧速度宣传成推理速度。
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
首屏是否应等待模型初始化完成？
通常不应。先绘制应用外壳，并单独报告模型状态；只有真实前置条件满足后，才启用依赖推理的入口，并保留失败重试说明。
看见模型文件就代表功能准备好了么？
不代表。文件校验、runtime 初始化和任务配置可能仍未完成。就绪状态应由界面组合之外的明确所有者管理，并在每次任务前确认。
首屏很快出现能说模型更快吗？
不能。首帧响应和推理耗时是不同指标。必须说明测量边界，不能用界面外壳先绘制推断模型速度、兼容性、任务可用性或运行成功状态。