PicMe 性能基线报告合集

文档类型: 性能报告 (Performance Baseline Report) 最后更新: 2026-07-08 维护者: [QA] 质量专家

本文档合并了 PicMe 项目的历史性能采集报告，保留原始数据表格供趋势分析使用。

📋 目录

1. 0.8B vs 1.7B 本地 LLM
2. ASR + NCNN 人脸检测 + 美颜（高性能手机）
3. 开启本地 LLM 前后对比

1. 性能对比诊断报告：0.8B vs 1.7B 本地 LLM（ASR + NCNN人脸检测 + 美颜）

2026-06 模型升级：默认模型已从 Qwen3-1.7B 升级至 Qwen3.5-2B。 本文档为 0.8B vs 1.7B 的历史基线数据，保留供性能趋势参考。 Qwen3.5-2B 对应指标待后续采集更新。

采集时间：2026-06-06 设备：51912a5c（高性能手机） 场景A（1.7B）：ASR + NCNN 人脸检测 + 美颜 + Qwen3-1.7B 场景B（0.8B）：ASR + NCNN 人脸检测 + 美颜 + Qwen3.5-0.8B

1. 核心指标对比

2. 内存详细对比

关键发现

• Native Heap 减少 500MB：0.8B 模型 weight 470MB vs 1.7B 的 1.2GB，但运行时差距小于预期
• Swap PSS 从 2.33GB 降至 448KB：系统不再大量换页，内存压力解除
• 总 PSS 从 6.24GB 降至 3.48GB：应用不再被 LMK 杀死，稳定运行

3. 渲染性能对比

关键发现

• Legacy janky frames 从 18.42% 降至 11.12%：卡顿减少，但仍高于基线（0.89%）
• 99th 渲染延迟从 22ms 恶化到 31ms：部分帧严重掉帧，可能与模型加载后的初始化开销有关
• GPU 延迟反而改善，说明 GPU 不再受内存竞争影响

4. 温度对比

关键发现

• GPU 温度从 ~81°C 降至 ~72°C：0.8B 模型推理负载更低
• CPU 温度同步下降：整体热负载减轻
• 电池温度仍 40.1°C，略高于无 LLM 的 36.1°C

5. CPU 占用分析

关键发现

• CPU 占用从 49% 暴跌到 2.6%：0.8B 模型推理开销极低
• 2.6% 的 CPU 占用与无 LLM 场景（约 2-3%）接近
• 说明 0.8B 模型的推理几乎不消耗 CPU 资源

6. 稳定性对比

关键发现

• 0.8B 模型应用未被杀死：总 PSS 3.48GB 在设备安全范围内
• Swap 几乎为零：系统无需换页，内存充足
• 这是从「不可用」到「可用」的质变

7. 综合评估

7.1 改善项

7.2 仍存问题

8. 根因分析

8.1 为什么 0.8B 能稳定运行？

1. 模型权重减少：470MB vs 1.2GB（-61%）
2. 运行时内存减少：~2.5GB vs ~3.5GB（-29%）
3. 总 PSS 3.48GB < LMK 阈值：系统不杀进程
4. Swap 几乎为零：无换页开销

8.2 为什么仍有卡顿？

1. Native Heap 3.11GB 仍偏高：0.8B 模型 + 相机美颜管线叠加
2. 渲染 99th 31ms：可能 LLM 推理与渲染线程竞争 GPU/CPU
3. Legacy janky 11.12%：虽然比 1.7B 好，但仍高于基线

9. 结论

0.8B 模型是从「不可用」到「可用」的关键切换。

但仍需进一步优化才能达到「流畅」： - 动态加载/卸载可释放 2.5GB 内存 - GPU 后端可进一步降低 CPU 占用 - 预览分辨率降低可减少渲染竞争

11. 发热后追加测试（关键发现）

用户反馈「已经开始发烫」后，立即执行追加采集。 此时设备已持续运行 0.8B 模型约 20 分钟。

11.1 发热前后对比

11.2 关键发现

发热后 0.8B 模型表现接近 1.7B 初始状态：

• CPU 从 2.6% 暴涨到 157%：温度升高触发 CPU 降频，推理速度下降，需要更多 CPU 周期完成相同任务
• Swap PSS 从 448KB 暴涨到 4.47GB：系统可用内存因温度/压力减少，被迫大量换页
• 总 PSS 从 3.48GB 涨到 6.86GB：接近 1.7B 模型的 6.24GB
• Native Heap 反而下降到 1.98GB：系统内存压力下触发 Native GC，但 Swap 膨胀掩盖了真实内存需求
• Legacy janky 从 11.12% 涨到 19.35%：接近 1.7B 的 18.42%

11.3 根因分析

温度 → 降频 → 恶性循环：

1. 温度上升（40.1°C → 45.1°C） → CPU/GPU 触发温控降频
2. 降频后推理变慢 → 相同任务消耗更多 CPU 时间
3. CPU 占用从 2.6% 涨到 157% → 系统调度压力增大
4. 系统内存紧张 → ZRAM/Swap 膨胀（4.47GB）
5. Swap 换页开销 → 进一步增加 CPU 负载
6. 渲染线程被抢占 → janky frames 从 11% 涨到 19%

11.4 结论修正

0.8B 模型并非「安全」选择，只是延迟了崩溃时间。

持续运行 20 分钟后，0.8B 模型的内存和 CPU 表现已接近 1.7B 模型初始状态。如果不实施动态加载/卸载或温控策略，0.8B 模型最终同样会被 OOM Kill。

11.5 紧急建议

1. 立即：相机预览页卸载 LLM 模型（释放 2.5GB+ 内存）
2. 短期：温度 > 42°C 时自动切换到远程 LLM
3. 中期：实现 LLM 推理与相机预览互斥（不能同时运行）
4. 长期：INT4 量化或模型分片加载

10. 附录

10.1 Trace 文件

• 1.7B：/tmp/picme_trace_llm.perfetto-trace（98MB）
• 0.8B：/tmp/picme_trace_0_8b.perfetto-trace（86MB）

10.2 0.8B 模型配置

{
    "llm_model": "llm.mnn",
    "llm_weight": "llm.mnn.weight",
    "backend_type": "cpu",
    "thread_num": 4,
    "precision": "low",
    "memory": "low",
    "max_new_tokens": 8192,
    "sampler_type": "mixed",
    "temperature": 1.0,
    "topP": 0.95,
    "topK": 20,
    "min_p": 0
}

10.3 模型文件对比

2. 性能诊断报告：ASR + NCNN人脸检测 + 美颜（高性能手机）

采集时间：2026-06-06 20:05 设备：51912a5c（高性能手机） 场景：同时开启 ASR、NCNN 人脸检测、美颜 Trace 文件：/tmp/picme_trace_new.perfetto-trace（128MB）

1. 设备信息

2. 核心性能指标

3. 线程分析

关键线程列表（共 75 线程）：

发现

• 没有显式的 ncnn、mnn 或 mediapipe 命名线程
• NCNN 推理可能运行在 PicMe-CameraAna 或匿名线程中
• pool-*-thread-1 各仅1线程，比之前 MediaPipe 的线程爆炸（10+）好很多

4. 内存分析

Native Heap 1.72GB 是主要内存消耗，推测来自： - NCNN 模型加载（人脸检测模型） - CameraX ImageReader 缓冲池（1280×720 × 多帧） - GPU 纹理/Framebuffer（美颜渲染管线）

5. 温度监控

温度正常，未触发降频。

6. 瓶颈定位

6.1 CPU 占用 49% — 主要瓶颈

• 主进程消耗了整机 49% 的 CPU（整机 24%）
• 用户态 40% + 内核态 9.5%，说明计算密集型任务主导

6.2 Native Heap 1.72GB — 内存瓶颈

• 远超普通相机应用（通常 200-500MB）
• 主要贡献者：NCNN 模型 + CameraX 图像缓冲 + GPU 美颜管线

6.3 线程数 75 — 潜在调度开销

• 虽然比之前的 MediaPipe 线程爆炸好很多
• 但 DefaultDispatch 线程池创建了 10+ 线程，可能存在过度并行

7. 与之前 MediaPipe 设备的对比

结论：换用 NCNN + 高性能手机后，CPU 占用和帧率稳定性大幅改善，但 Native Heap 1.72GB 仍是主要瓶颈。

8. 优化建议

8.1 Native Heap 优化（优先级 P0）

• 检查 NCNN 模型是否重复加载（多个模型实例）
• CameraX ImageReader 缓冲数量是否可精简
• 美颜渲染 FBO/纹理复用

8.2 线程池优化（优先级 P1）

• DefaultDispatch 线程池限制最大并发数
• 考虑使用 Dispatchers.IO 的 limitedParallelism

8.3 ASR 音频缓冲（优先级 P2）

• AudioRecord 线程存在，确认音频采样率/缓冲配置是否合理

9. 附录

9.1 Perfetto Trace

• 文件路径：/tmp/picme_trace_new.perfetto-trace
• 大小：128MB
• 可用 ui.perfetto.dev 打开进行火焰图分析

9.2 采集命令参考

# 设备状态检查
adb devices
adb shell dumpsys battery | grep temperature
adb shell ps | grep com.mamba.picme

# 实时性能数据
adb shell dumpsys cpuinfo | grep com.mamba.picme
adb shell dumpsys meminfo com.mamba.picme
adb shell dumpsys gfxinfo com.mamba.picme

# 温度读取
adb shell cat /sys/class/thermal/thermal_zone*/temp

# Perfetto 采集
adb shell "perfetto --txt -c /data/misc/perfetto-configs/perfetto_config.pbtxt \
  -o /data/misc/perfetto-traces/picme_trace_new.perfetto-trace --background"

3. 性能对比诊断报告：开启本地 LLM 前后（ASR + NCNN人脸检测 + 美颜）

采集时间：2026-06-06 设备：51912a5c（高性能手机） 场景A（基准）：ASR + NCNN 人脸检测 + 美颜 场景B（对比）：ASR + NCNN 人脸检测 + 美颜 + 本地 LLM

1. 核心指标对比

2. 内存详细对比

关键发现

• Native Heap 暴涨 2.89 GB：这是 LLM 模型加载的直接结果
• Swap PSS 从 54MB 暴涨到 2.33 GB：系统开始大量换页，内存压力极大
• 总 PSS 6.24 GB：已接近/超过典型 Android 设备的内存限制（8GB 手机可用约 5-6GB）

3. 渲染性能对比

关键发现

• 99th 渲染延迟从 8ms 恶化到 22ms：接近 16.6ms（60fps）阈值，已出现掉帧
• Legacy janky frames 从 0.89% 飙升到 18.42%：每 5 帧就有 1 帧卡顿
• GPU 延迟也同步恶化，说明 GPU 同样受到内存压力影响

4. 温度对比

关键发现

• GPU 温度从 ~61°C 飙升到 ~81°C：LLM 推理大量使用 GPU/NPU
• CPU 温度同步上升 13-16°C：整体热负载显著增加
• 电池温度 41.1°C：已接近用户可感知的温热阈值（>42°C 明显发热）

5. 线程分析对比

关键发现

• 线程数仅增加 3 个，线程爆炸不是主要问题
• 新增 GPU completion 线程，与 LLM GPU 推理相关
• 所有关键线程从 Running 转为 Sleeping，可能因为 内存压力导致系统调度受限

6. 瓶颈分析

6.1 内存瓶颈（P0）

• Native Heap 3.61 GB 是最大问题
• Swap 2.33 GB 说明系统已开始将内存换出到 ZRAM/Swap
• 换页操作导致 CPU 额外开销，形成恶性循环

6.2 渲染瓶颈（P1）

• 18.42% legacy janky frames 已影响用户体验
• 99th 延迟 22ms 意味着部分帧超过 16.6ms，出现肉眼可见的掉帧

6.3 温度瓶颈（P2）

• GPU 81°C 可能触发温控降频
• 如果持续运行，温度会继续上升

7. 根因推断

本地 LLM（MNN-LLM/Qwen）加载后：

1. 模型权重占用大量 Native Heap（~2-3 GB）
2. 推理过程中激活值/ KV Cache 持续占用内存
3. GPU/NPU 高负载导致温度上升
4. 内存压力触发系统换页，Swap PSS 暴涨
5. 换页和内存竞争导致渲染线程延迟增加

8. 优化建议

8.1 内存优化（P0）

• 量化模型：使用 INT4/INT8 量化减少模型内存占用 50-75%
• 动态加载/卸载：LLM 非对话时段卸载模型，释放内存
• 限制 KV Cache 长度：设置最大上下文长度，避免无限增长
• 内存预警：当 Native Heap > 3GB 时自动降级到远程 LLM

8.2 渲染优化（P1）

• 降低预览分辨率：从 1920×1080 降至 1280×720 或更低
• 减少 CameraX ImageReader 缓冲数
• LLM 推理与渲染错峰：避免推理高峰与渲染 vsync 冲突

8.3 温控优化（P2）

• 监控 GPU 温度：>80°C 时降低 LLM 推理频率
• CPU/GPU 频率限制：在相机预览场景限制最大频率
• 散热设计：考虑在 LLM 运行时降低美颜效果

8.4 架构优化（P3）

• 远程 LLM 回退：内存不足时自动切换到云端推理
• LLM 推理批处理：合并多个请求减少重复加载
• 模型分片加载：按需加载模型层，而非全量加载

9. 稳定性事故：应用被系统 OOM Kill

9.1 事故现象

采集结束后发现：

9.2 事故分析

• 6.24 GB PSS + 2.33 GB Swap 超过了设备的 LMK 阈值
• 当系统内存紧张时，PicMe 作为最大内存占用者成为首选 kill 目标
• 即使高性能手机（2.75GHz CPU）也无法承受这种内存压力

9.3 业务影响

核心矛盾：相机预览（2GB）+ 本地 LLM（3GB）= 5GB+ 内存需求，超过了 Android 单应用的安全内存上限（通常 3-4GB）。

10. 结论

开启本地 LLM 后，应用从「流畅」变为「被杀+卡顿+高发热+高内存压力」状态。

核心矛盾：LLM 模型内存占用（_{3GB）与相机美颜管线内存占用（}2GB）叠加，总内存需求超过设备安全上限。

本地 LLM 当前无法在相机预览场景稳定运行，必须实施量化或动态加载后才能上线。

11. 附录

11.1 Trace 文件

• 场景A（无LLM）：/tmp/picme_trace_new.perfetto-trace（128MB）
• 场景B（+LLM）：/tmp/picme_trace_llm.perfetto-trace（98MB）

11.2 采集命令参考

# 性能数据快照
adb shell dumpsys cpuinfo | grep com.mamba.picme
adb shell dumpsys meminfo com.mamba.picme
adb shell dumpsys gfxinfo com.mamba.picme
adb shell dumpsys battery | grep temperature
adb shell cat /sys/class/thermal/thermal_zone*/temp

# 线程列表
adb shell ps -T -p <PID>

# Perfetto 采集
adb shell "perfetto --txt -c /data/misc/perfetto-configs/perfetto_config.pbtxt \
  -o /data/misc/perfetto-traces/trace.perfetto-trace --background"