直接回答
“内存不足”并不是一种单一诊断。托管堆分配异常、原生缓冲区分配失败、操作系统结束后台进程、运行时拒绝某个模型文件、任务超时，都可能让用户感觉应用消失或停止响应。先识别实际失败阶段并保存测试配置。Android Studio Memory Profiler 和 heap dump 可以显示某个采样时点仍被保留的托管对象；进程级或原生内存问题可能需要其他工具。单份 heap dump 不能完整覆盖 GPU、原生或系统内存。 要把文件存储和运行时工作内存分开。模型文件字节数无法预测应用峰值内存；运行时缓冲、缓存、token 上下文、解码后的图像或音频、Compose 状态以及操作系统预留都会产生影响。没有精确应用、模型、运行时、后端和任务的证据，就不能发布通用 RAM 门槛。短文字提示能加载模型，不代表图像任务或长会话也能完成。冷启动和代表性任务也应分别记录。 恢复要从非破坏性动作开始。释放资源前保存可恢复任务所需的最少状态；若运行时支持则取消推理；按文档顺序关闭会话；并告诉用户结果已保存、部分完成还是丢失。如果应用的 ModelManager 在加载失败后会删除模型文件，应清楚说明并确认这种行为不会删除用户内容。不能自动删除笔记、录音、图片或其他文件来腾出空间。如果用户需要卸载或重新下载大型模型，应在产品界面确认并说明存储后果。 用同一模型文件和任务复现，每次只改变一个内存相关因素：提示长度/上下文、图像尺寸、音频片段、并发数、重复运行次数或上一引擎是否关闭。采集基线、加载后、任务峰值、取消后和关闭后的观测值。指标定义必须在不同运行间保持一致。若进程被系统结束而不是抛出异常，应记录系统证据和生命周期状态，不能凭空写一个应用异常。 用户体验要提供诚实的恢复路径：只有应用实现后才允许尝试较小任务；不完整结果明确标成不完整；可以让用户有意卸载模型；并提供隐私安全的诊断摘要。不能声称缩小输入就一定成功。备选路径要诚实，例如手动输入或非 AI 方式，不要静默把私人内容转发到云服务。 本文描述诊断和恢复设计，不是 Cove 的性能限制。Cove 尚无可以支撑通用内存预算的设备原始基准记录。任何发布结论都需要有版本的测试记录。执行时先按证据分类停止原因，再用匹配工具采样；随后释放明确归应用所有的会话，保留用户输入和完整结果；每次只改一个工作负载变量重跑。安全恢复的标准是用户数据保留、资源释放、状态清楚、下一步已验证，而不只是屏幕重新打开。
模型加载后，照片分析任务导致应用重启
审核者能打开本地 AI 应用并完成短文字提示，但代表性图片任务后进程重启。团队没有记录证明这是托管堆异常、原生分配、系统回收还是其他崩溃。
决策
保留测试配置，先分类故障，再决定是否修改模型或删除资源；使用匹配的内存证据重复一项受控任务。
预期结果
应用要么完成任务，要么显示真实失败状态，同时保留用户输入和安全恢复操作。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- 异常或进程生命周期证据
- 基线、加载、任务峰值和关闭记录
- 保存与删除边界
设备兼容结论须绑定具体设备、系统、模型、运行时、后端和工作负载，不能靠参数量推测。
实施流程
- 先分类故障再恢复. 记录应用和系统版本、模型与后端、按大小描述而非记录私密内容的任务输入、最后可见状态、异常类别和进程生命周期。区分程序抛出的分配异常与进程在没有托管异常时被移除。
- 测量匹配的内存层. 用堆快照检查仍被保留的托管对象，用对应的分析器或系统诊断检查进程内存。分别记录基线、模型加载、代表任务峰值、取消后和关闭后；不能把 Java heap 与 RSS 当成同一指标比较。
- 释放资源并保留用户任务. 取消受支持的工作，通过所有者关闭对话和引擎，仅保存可恢复任务元数据和完成结果，并遵循原有用户内容保留规则。不能为了清理模型空间删除无关用户数据。
- 每次只改一个工作负载因素. 单独调整图像尺寸、上下文、音频片段、并发或重复会话等因素之一，重跑固定测试，并明确说明这是已验证缓解、临时诊断还是未验证建议。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 故障标签依据观察到的阶段和证据，不依据猜测的异常或机型兼容结论。
- 取消或失败会释放引擎资源，并保留持久化用户输入与已完成结果。
- 用户下一步清楚，且不会静默上传私人内容或删除无关数据。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 托管堆增长 | Heap dump 与对象保留分析 | 适用于 Java/Kotlin 对象；不覆盖所有原生或 GPU 分配。 |
| 原生或进程内存压力 | 进程级与运行时诊断 | 需要进程指标和事件记录，不能与 Java 堆大小互换。 |
| 没有应用异常的进程终止 | 生命周期和系统证据 | 只观察到进程重建时，不要虚构 OutOfMemoryError。 |
需要避免的失败模式
- 从模型文件大小推算 RAM
- 把进程被杀称为同一种异常
- 为释放空间删除用户内容
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
- Android Memory Profiler
- Android Developers — 捕获堆转储
- Android Developers — Activity 生命周期和进程死亡
- Android Developers — 内存分析器
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
模型下载大小能告诉我最低 RAM 吗？
不能。运行时缓冲、缓存、上下文、解码媒体、分配器行为和系统余量都会影响内存。应测量准确制品和代表任务，不要把文件字节转换成 RAM 要求。
加载失败后应用要删除模型吗？
只有当这是针对确切故障的明确恢复策略时才考虑。把用户内容与模型分开；删除大文件前告知用户，并确认新状态不会导致数据丢失。
进程被系统结束等于捕获到 OutOfMemoryError 吗？
不等同。Android 可能为回收资源终止后台进程，而不走相同的托管异常路径。要用生命周期与系统证据分类。