大视频的电量、存储、内存要求
为什么大视频耗电发热
ZenConverter 的视频互转路线是真重新编码（不是 stream copy），这意味着：
- 解码：FFmpeg 把 H.264/H.265 压缩视频解码成原始 YUV 帧；
- 滤镜：倒放、降噪、镜像、旋转、画幅适配等；
- 编码：FFmpeg 把处理后的帧重新编码成目标格式。
这一整条链路满载 CPU，某些滤镜（尤其是 AI 相关的）还会满载 GPU。现代 Android 芯片在持续高负载下的功耗轻松超过中轻度使用的 2–3 倍。
一个典型的 4K → 1080p H.265 重编码：
| 输入文件 | 处理时间 | 估计功耗 | 手机温度 |
|---|---|---|---|
| 4K 24fps 1GB 视频 | 约 20–30 分钟 | 持续 5–8W | 45–55°C（手感明显温热） |
电量建议
- 最低 30% 以上开始转换：低于 30% 时系统可能开启省电模式（限制 CPU/GPU 频率），反而拖慢处理速度；
- 建议接电源：长时间转换（超过 30 分钟）时接电源最稳妥——避免处理到一半突然断电前功尽弃，也避免电池充放电循环对寿命的轻微损耗；
- 避免边充边用其他高负载应用：转换时把手机放一边别用，尤其别同时开游戏或其他视频播放。
存储建议
大视频转换需要的存储 = 源文件 + 输出文件 + 临时文件。
| 环节 | 需要的空间 | 说明 |
|---|---|---|
| 源文件 | 源文件大小 | 已在存储里 |
| 输出文件 | 源文件大小的 100%–200% | 取决于压缩率（不压缩可能比源文件大） |
| 临时文件 | 几百 MB | FFmpeg 解码过程中可能用到 |
| AI 模型（如果下载） | 4.65 MB 或 63.9 MB | 只占一次 |
转换前确保可用存储 ≥ 源文件的 2–3 倍。空间不足时会中途失败，但不会留下损坏的输出文件——ZenConverter 会清理半成品。
内存建议
ZenConverter 的像素预算机制（见 OOM 防护页面）主要保护图片处理路线。视频路线的内存占用来自 FFmpeg 的解码/编码帧缓冲，是 FFmpeg 自己管理的。
但 ZenConverter 也在视频路线上做了几个防护：
- ARM 设备探测：某些老旧 ARM 设备可能内存非常紧张（比如 4GB RAM 的老机型），处理几个 GB 的视频可能触发 Android LMK；
- 文件描述符而非拷贝：ZenConverter 从 SAF 拿到文件描述符，不会把源文件完整拷到临时目录，减少一次性内存占用；
- 串行处理：多任务按顺序逐个跑（不并行），避免多个大视频同时吃内存。
中途被系统杀掉怎么办
如果系统真的把进程杀了（低电量、存储空间告警、系统自己的内存清理）：
- 正在处理的那一个任务会失败（有明确错误状态）；
- 已经完成的任务不受影响；
- 前台服务会恢复（Foreground Service 的存活优先级高，通常比普通进程更耐杀）；
- 重新打开 ZenConverter，剩余任务会回到"等待中"状态，可以继续跑。
典型场景对照表
| 场景 | 电量 | 存储 | 内存 | 建议 |
|---|---|---|---|---|
| 1080p → 720p 重编码 | 20%+ | 源的 1.5× | 4GB+ | 可以直接跑 |
| 4K → 1080p 重编码 | 接电源 | 源的 3× | 6GB+ | 接电源 + 空手机 |
| 多视频合并（合计 5GB） | 接电源 | 源的 3× | 6GB+ | 接电源 + 不做其他事 |
| 加 AI 滤镜（RIFE 补帧） | 接电源 | 源的 2× | 8GB+（含 GPU 显存） | 接电源 + OLED 纯黑模式省电 |
相关页面
- 动态像素预算与 OOM 防护 —— 图片路线的 OOM 防护机制
- 视频格式互转原理 —— 为什么视频互转是真重新编码
- 后台服务与任务队列 —— 为什么用前台服务保活
