诚实比万能更重要
支持矩阵是公开的"不做承诺"
很多转换器的广告文案会说"支持 1000+ 格式""万能格式互转"——但你点开详情页，每个格式后面都有一堆小字注释，实际用的时候经常遇到"这个格式那个编解码器不支持""这个格式只能转不能从它转出来"。
ZenConverter 不走这条路。仓库里有一个公开的、自动跟随代码更新的文件叫 formats/support-matrix.md，它用五个状态标签来明确每个路线的可靠程度：
| 状态标签 | 含义 |
|---|---|
Stable | 已在真机测试过真实文件和大文件，稳定可用 |
Beta | 能用，但边界条件下可能出问题 |
Experimental | 隐藏或明确标注的实验性功能 |
Planned | 已规划但未实现 |
Unsupported | 明确不支持，附理由 |
比如 Any → Any 这一行的状态就是 Planned，引擎是 None，注释写着"不要暗示通用支持"——直接在矩阵里告诉你：ZenConverter 不做这个。
为什么不做"万能转换器"
原因有三个。
1. 每条路线都需要真机验证
一个转换路线不是"FFmpeg 有这个 codec"就完事了。它需要：
- 在 arm64 真机上跑通真实文件；
- 大文件（几 GB 级视频）不 OOM；
- 输出容器里的元数据（封面、ID3、歌词）正确；
- 已知的边界条件（比如 Opus 只支持 48kHz 倍数采样率）在文档里写清楚。
这些工作的成本很高。每加一个新格式路线，都要重复一遍这个验证流程。 如果宣称"支持 1000+ 格式"，要么是偷工减料不验证，要么是把云端转存当本地转换。
ZenConverter 目前覆盖的格式路线，每一条都有真机测试的痕迹。
2. arm64-only 是有意的选择
APK 只打包 arm64-v8a 原生库。为什么不打包 32 位 ARM？因为：
- 现代 Android 设备几乎都是 64 位的；
- 原生库（FFmpeg、PDFBox-Android、woff2、office2pdf、NCNN Vulkan）打包多架构会显著增大 APK 体积；
- NCNN Vulkan GPU 加速只在 arm64 路径上做了适配。
32 位 ARM 设备不在 V1 目标里——技术路线文档 Phase 5 写的是"不做中国内地应用商店，不需要覆盖低端设备"。如果你用的是 32 位 ARM 手机，这个应用装不上，这是已知的、故意接受的边界。
3. 已知失败要比意外失败好
ZenConverter 的很多路线都明确写出了已知的不兼容场景：
| 路线 | 已知边界 |
|---|---|
| MP4 → MP4 | 字幕、附件、额外轨道不保留 |
| Video → MP3/M4A/WAV | 只提取第一个音轨，多音轨视频只取主声轨 |
| Office → PDF | 不承诺版式完全保真，源文件上限 64 MiB |
| HEIC → PNG/JPG | 依赖系统 HEIC 解码器，某些旧设备会直接失败 |
| WOFF2 → TTF | arm64-v8a only，32 位设备不走这条 |
| AI 超分 | 依赖设备 GPU 的 Vulkan 支持，部分芯片不兼容 |
ZenConverter 的态度是：与其让用户满心期待地上传一个复杂 Office 文档然后拿到一个排版全乱的 PDF，不如在 support-matrix 里写清楚"这条路线是 Beta，版式可能不对"。
版本演进的诚实
看 GitHub Releases 页面上的版本日志也能发现这个风格：每个 commit 标题都是简洁的、不带营销修饰的改动说明。比如：
fix(contact-sheet): resolve rotation distortion and 4K frame extraction failuresfeat(webm): add WebM output with VP9/VP8 encoding and Opus audiorefactor(ui): decouple OLED dark mode from theme modeperf(esrgan): use dynamic thread count, enable memory pooling, enlarge tiles
没有"重磅发布"、"革命性更新"、"完美支持"这类词。每个版本告诉你实际上改了什么、修了什么、加了什么。
这种诚实对你有什么好处
作为用户，你拿到的是一个能力边界清楚的工具：
- 不会因为某个"万能"功能在这个格式上翻车而浪费时间；
- 知道哪些场景它能稳、哪些要谨慎；
- 真出问题的时候，support-matrix 和 commit 历史是排查线索，而不是让你在模糊的"支持/不支持"之间猜。
