Android 本地模型冷启动与热启动测量

直接回答

测量本地模型加载时，应将其拆成明确命名的事件，而不是用一个没有边界的秒表数字。“应用冷启动”描述进程和 Activity 的启动条件；“模型冷加载”还要说明模型运行时和制品是否已初始化或缓存；“热启动”也可能分别指同一进程内重建 Activity、在已打开的运行时发起第二次请求，或从系统页缓存读取文件。这些条件不能混为一谈。Android Macrobenchmark 定义应用冷、温、热启动模式，可以重复用户可见操作，但其应用启动指标不会自动成为模型就绪时间。应在应用或基准操作中增加事件，记录制品定位与校验、运行时初始化、首次请求提交、首个输出到达以及代表性任务完成的时间，并随结果公开事件定义。至少分开进程或 Activity 启动到首帧、首帧到模型页面可用、文件定位和完整性校验、原生引擎或会话初始化、首次推理到输出通过验收这几段。用户可能已经看到界面，但模型仍未准备好；引擎可能就绪，但任务仍需执行时间。不要把首帧称为 AI 就绪；如果总时长还含权限弹窗、文件选择、网络下载、界面动画或语音播报，也不要直接叫模型加载时间。比较时固定制品身份、运行时构建、应用变体、后端请求、测试提示、输出规则和设备状态。如果某次运行期间才下载模型，那是分发测试；若 Android 杀死进程，那只说明新进程，文件页仍可能留在缓存中。Macrobenchmark 冷模式会在准备和测量之间结束应用进程；温模式则在不结束进程的情况下重建 Activity。任何模式都不能保证磁盘缓存或原生库状态必然全新，因此必须写清重置和保留了什么。重复测量要保留每次结果和环境记录，使用符合工具要求的可分析构建，测量代码不得改变被测路径。“就绪”应由用户相关的验收条件定义，例如主操作已启用且固定样例完成，而不是只看引擎引用非空。初始化失败、超时、取消、回退与未完成输出都不能删除。报告应识别设备与系统构建、应用修订与变体、制品修订及字节数、运行时版本、后端请求与实际执行证据、样例、启动模式、缓存和重置方法、电量与热状态备注及工具。Cove 没有完整真实设备基准数据集，因此该页面可以发布方法，却不能宣称 Cove 手机排名、加载时长或最低设备要求。运行时初始化变慢不同于首帧延迟，也不同于 token 生成慢或输出验收失败。保存原始 trace 和逐次记录，让后续审核者能够复现比较，而不是只相信标题数字。具体顺序是先说明用户可见问题和就绪条件，确定测量应用启动、文件校验、引擎创建、首次推理还是整项任务。固定应用、运行时、制品、样例、后端请求、输出要求、设备和重置步骤，并记录解析后的版本。为各边界加入时间戳，正式测量前做一次不计入结果的排演，确认样例进入目标状态。下载和设置除非是研究主题，否则排除在外。随后按命名的 Macrobenchmark 模式或清晰描述的应用级流程执行冷、热条件，保留每个 trace、错误、取消和回退。最后确认任务和环境可比，并同时报告方法、范围、统计方法及限制。这是测量规程，不是性能结果；结论只适用于实际观察的制品、运行时、应用构建、设备、任务和状态。

首屏出现很快，但模型操作仍不可用

本地助手很快绘制首帧，却因原生模型仍在打开而禁用主要操作。同一进程再次进入时似乎更快。团队没有完整设备基准数据，需要区分应用启动、模型初始化、文件校验和热复用。

决策

分别测量界面和运行时区间，以固定制品与样例比较命名的冷、热条件，并保留所有运行，不作普遍设备结论。

预期结果

报告指出变化发生在哪一环，以及相同用户任务是否更早就绪，不会把首帧时间当成推理可用的证明。

需要收集的证据

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

• 逐项定义启动和就绪事件
• 记录冷/热状态的重置边界
• 保存每次运行、失败和回退

发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。

实施流程

1. 定义事件边界. 写清进程启动、首帧、文件定位、完整性校验、引擎初始化、首次推理与任务验收的时间点，并说明初始化是提前、由屏幕触发还是由用户请求。
2. 固定比较输入. 记录应用修订和变体、解析后的运行时版本、制品修订与长度、后端请求、测试样例、设备和系统构建及输出规则；重要输入改变时须明确标记。
3. 描述冷、热状态. 标明 Macrobenchmark 模式，并说明进程、Activity、运行时、模型会话、文件页缓存、着色器和编译状态分别重置或保留了什么。冷启动不代表所有缓存为空。
4. 保存全部结果. 保留时间戳、trace、初始化错误、未完成输出、取消和回退。用代表性任务通过验收定义就绪，而不是用界面已显示或引擎对象存在来代替。
5. 只报告实测范围. 同时报告方法、确切设备与制品、事件边界、每次结果和统计口径；不可把一次启动或加载结果转换成通用速度、RAM 或兼容性结论。

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

验收标准

• 报告区分首帧、模型就绪、首个输出和任务完成，并定义每个时间戳边界。
• 冷、热运行写明进程、运行时、文件缓存和编译条件分别重置或保留了什么。
• 每次迭代、失败、取消和回退均保留，并关联制品、运行时、样例、设备和应用构建。
• 性能或兼容结论不超出实际测试的配置和任务。

决策对照表

需要避免的失败模式

• 用首帧表示模型就绪
• 假定冷启动清空全部缓存
• 只报告成功样本或平均数

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

最小复现记录

发布检查表

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

来源与相关证据

• Cove 基准测试方法
• Android Developers — Macrobenchmark 概览与启动模式
• Android Developers — 使用 Macrobenchmark 检查性能
• Cove 基准测试原始数据要求

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

常见问题