相册批量翻译实战：选图队列、后台处理与译文回贴归档

出差回来，手机相册里躺了四十多张外文菜单、路牌、说明书和展会资料的照片，一张张点开、翻译、截屏、再存回去，干到第十张的时候我就知道这事不能这么干下去了。后来我改成用相册批量翻译的路子：一次性勾选多张图丢进队列，让它在后台慢慢跑，跑完直接另存为带译文的图片，原图不动，译图单独归档。这套流程听起来只是"少点几下"，实际跑通之后差别相当大——它把一件需要你全程盯着的事，变成了一件你可以去干别的事的事。这篇就把我从选图、排队、后台处理到译文回贴、另存归档的完整链路拆开讲，包括每一步为什么这么设计、参数怎么定、哪些图会翻车。适合两类人看：一类是经常要处理外文图片资料的，另一类是想自己搭一套类似图片翻译流水线的。零基础也能照着走，因为我会把每一步的判断依据讲清楚，而不是只丢一串按钮位置。

1. 单张翻译和批量翻译，差的不是"次数"而是整条流水线

1.1 为什么逐张处理在第十张之后必然崩

很多人对批量翻译的理解就是"把单张的流程重复 N 次"，这个理解在数量小于五的时候没问题，超过十张就会暴露三个结构性缺陷。第一是上下文切换成本：每张图你都要重新判断"这张翻什么语言、翻完存哪里、叫什么名字"，这种微决策单次只有两秒，四十张就是八十秒纯浪费，而且越到后面越容易出错，命名开始乱、存错相册、漏翻几张。第二是阻塞等待：单张模式下，识别和翻译的那几秒你只能干等，因为界面被占着，你的注意力也被占着，这是最贵的成本。第三是结果散落：单张翻完的图混在相册里，跟原图、截图、聊天记录里的转发图搅在一起，一周之后你根本分不清哪张是译图哪张是原图。

批量模式解决的恰恰是这三件事：决策集中做一次（选图时统一设定语言、输出格式、保存位置），等待挪到后台（你可以锁屏、可以切去回消息），结果集中落在一个新建相册里（命名规则统一）。所以它不是"省点击"，是把一条串行的人工流水线改成了批处理的作业队列。这个视角的转变很关键，因为它决定了你后面所有的参数选择：你会开始关心吞吐、关心失败重试、关心断点续跑，而不是关心"这一张翻得准不准"。

1.2 批量任务里真正吃时间的三个环节

跑过几轮之后我拿秒表掐过，一张 1080P 的截图，端到端大概 3 到 6 秒，其中大头根本不在翻译。粗略的分布是这样的：图片解码与预处理占 15% 左右，文本检测加识别（OCR）占 50% 到 60%，翻译请求占 20% 到 25%，文本回贴渲染占 10% 左右。这个比例非常重要，因为它告诉你优化该往哪里使劲。

如果你的图很大（比如相机直出的 4000×3000），解码和缩放的耗时会直接翻倍，而且对识别精度几乎没有帮助——识别模型吃的是固定输入尺寸，你把 4000 像素的长边喂进去，它照样缩到 960 再算。所以我习惯在选图之后先做一次长边下采样，把长边压到 1600 到 2000 之间。这个区间是我实测的甜点：再小，截图里那种 10 像素高的小字就开始糊；再大，只是白白多花时间。原文里没提这个参数，这是我自己反复对比后定下来的经验值，你可以按自己图片的字号大小上下浮动。

1.3 一张图从进队列到出结果要经过什么

把链路摊开看，你才知道每一步可能在哪断掉。下面这张表是我自己整理的处理阶段对照，左边是阶段，中间是这个阶段在干什么，右边是我踩过的典型故障。

看这张表的用处是：出问题的时候你能定位到具体阶段，而不是笼统地觉得"这工具不行"。比如译图整体旋转了 90 度，那是"入队/预处理"的 EXIF 环节；比如译文全是方块，那是"回贴渲染"缺字体；比如译文语句读不通但每行都对，那是"翻译"环节按行切碎了。后面第六节我会把这几种情况逐个展开。

2. 选图阶段的四个决定：数量、来源、格式、顺序

2.1 一次选多少张才合理

批量不是越多越好。我实测下来的经验是：单批 20 到 30 张是最舒服的区间，超过 50 张收益开始递减。原因有三个。

第一个是失败重试的成本。一批 200 张里如果有 15 张失败（混合语言、模糊、超大图都可能失败），你需要在一堆缩略图里把失败的那几张重新勾出来，这个操作的心理成本比重新跑一批还高。20 到 30 张的批次，失败了直接整批重跑也不心疼。

第二个是内存与稳定性。批量处理时工具通常会把解码后的位图缓存在内存里，一张 2000 长边的 ARGB 位图大约 2000×1500×4 字节，接近 12MB。如果并发开 4 个，加上缓存队列，很容易吃到 300MB 以上。中低端机在这个量级上被系统回收的概率明显上升，表现出来就是"跑到一半应用没了"。

第三个是你能验收的上限。批量跑完是要抽检的，一批 25 张我大概会看 5 到 8 张（重点看含数字、专有名词、密集小字的那几张），这个量还能保持注意力；一批 200 张，你根本不会去看，等于放弃了质量控制。

提示：如果你的图确实很多，正确做法是拆成多批连续跑，而不是一批全塞进去。拆批的时候按"来源"或"内容类型"分组，同一批的语言和排版风格接近，抽检也更容易发现问题。

2.2 相册来源不同，预处理策略也不同

我相册里的外文图基本分三类，它们的预处理需求完全不同，混在一起批量跑是自找麻烦。

第一类是手机截图，包括聊天记录里的转发图、网页长截图、应用界面截图。这类图的特点是分辨率规整、文字水平、对比度高、字体是标准印刷体，识别成功率最高，基本 95% 以上。唯一的坑是长截图——那种一张图几屏高的滚动截图，长宽比可能到 1:8，直接缩放到长边 2000 会让文字糊成一条线。我的做法是先把长图切成 2 到 3 段再进批量，或者干脆单独处理。

第二类是翻拍的照片，比如拍菜单、拍说明书、拍展板。这类图的麻烦在透视变形和光照不均，文字可能是斜的、可能有反光。预处理阶段需要做透视校正（把四边形拉回矩形），这个动作很多工具会默认做，但如果你的图倾斜角度超过 20 度，自动校正经常失败。我的经验是翻拍时尽量正对、尽量让文字占满画面，实在不行就先在相册里裁一下再进批量。

第三类是设计稿或 PDF 导出的图，这类图可能有透明通道、可能是矢量渲染出来的细笔画字体。透明背景是最容易翻车的——很多渲染环节会把透明区域当成黑色，结果译图背景一片漆黑。遇到这种图，进批之前先确认输出格式选了带白底填充的 JPG 而不是保留透明的 PNG。

2.3 顺序决定结果页的排列，别忽略

这个细节绝大多数教程都不提，但实际用起来影响很大：批量任务的输出顺序，通常等于你的选图顺序，而不是相册里的时间顺序。多选界面里你手指点的先后，就决定了译图在结果相册里的排列。

为什么重要？因为你翻完是要读的。如果是连续几页的说明书，你肯定希望译图按页码顺序排；如果是一组展会展板，你希望按参观动线排。选图的时候手一快，顺序乱了，回头在结果相册里翻找就得多花好几分钟。

我的做法是：进批量选图前，先在相册里把这一组图按我想要的处理顺序建一个临时相册，然后再从这个临时相册里全选。这样顺序天然正确，而且中途中断了也好恢复——下次打开这个临时相册就知道跑到哪儿了。

2.4 选图前先做的一件事：筛掉不需要翻的

这一步听起来像废话，但我敢说至少三成的失败案例源于此。批量选图的时候人是麻木的，手指一路勾过去，很容易把这几类图也勾进来：

• 本来就是中文的图（截图里的中文界面、中文说明书），翻一遍等于浪费时间，还可能被识别成其他语言乱翻一通；
• 纯图片没有文字的（风景照、产品图），检测阶段会返回空，占一个队列位；
• 已经翻过的图（重复的截图），跑第二遍纯浪费；
• 带大量水印或半透明叠加文字的图，识别结果会混进水印文字，译文里莫名其妙多出几个词。

我现在养成一个习惯：选图的时候先快速滑一遍，把明显不需要的取消勾选，这一步花三十秒，能省掉后面五分钟的困惑。尤其是在相册里做"滑动多选"的时候，手指滑过的区域比你想象的大，很容易多选。

3. 后台处理：把"等"这件事从屏幕前挪走

3.1 为什么必须后台跑，前台跑会怎样

前台跑批量任务最直接的问题是你不能干别的。更隐蔽的问题是，很多系统在应用处于前台但长时间无交互时，会降频或者触发省电策略，反而让处理速度不稳定。而后台跑的核心价值不是"快"，是可中断、可恢复、不占你的注意力。

我一般的节奏是：早上出门前把一批图丢进去，锁屏放兜里，到公司掏出来已经跑完了。这个体验跟前台盯着进度条完全是两回事。当然后台跑有它自己的约束——系统会限制后台的计算资源，长时间后台任务可能被挂起，网络请求可能被限流。所以后台方案的设计重点不在于"跑得快"，而在于"断了好接上"。

3.2 队列、并发与节流：参数怎么定

如果你只是用现成工具，这部分你不需要调，但知道原理能帮你判断"为什么它跑这么慢"。如果你要自己搭，这三个参数是核心。

并发数：同时处理几张图。我的建议是 2 到 3。设成 1 太慢；设成 4 以上，收益很快被内存压力和翻译接口的速率限制吃掉。原因在于整条链路里最慢的一环是 OCR，它是计算密集的，多开只会互相抢 CPU；翻译请求虽然是 IO 密集的，但主流翻译接口都有 QPS 限制，你并发开再大也是排队。

批大小：一次提交给翻译接口的段落数。这个参数很有讲究——太小，网络往返次数多；太大，一次失败全批重来。我习惯按单张图的所有段落作为一个批次提交，因为同一张图内的文本有上下文关联，一起翻质量更好，而且失败粒度刚好是"一张图"，重试逻辑简单。

节流间隔：每张图之间插一个几百毫秒的间隔。看着像在拖慢速度，实际是在给你自己留退路——万一某一类图触发了接口的频控，均匀的请求节奏比突发请求更容易恢复。我一般设 300 到 500 毫秒。

3.3 中断与恢复：锁屏、切应用、断网的处理

这是批量翻译最容易被低估的部分。我踩过的坑按频率排是这样的：

锁屏后被挂起。安卓上如果不做前台服务声明，锁屏后几十秒任务就被冻结了；iOS 上后台时间窗口更短。表现出来就是"跑了两张就停在那儿"。解决办法是找一个会把任务状态持久化到本地的工具——每完成一张就写一条记录，恢复时从第一条未完成的开始，而不是从头再来。

断网导致的批量失败。翻译环节依赖网络，如果跑到一半地铁进隧道，后面所有图都会失败。有些工具会把失败的任务直接丢掉，这就很坑。我的做法是全程保持网络，或者干脆在家跑完再出门。如果非要移动中跑，就选那种"失败任务留在队列里可一键重试"的。

切换应用导致的资源回收。批量跑到一半你切去回消息，回来发现进度归零，这是因为进程被系统回收了。中低端机上这个现象特别明显。缓解办法是跑批量的时候别开大型应用，也别在批量进行中做相册整理（大量缩略图加载很吃内存）。

中途手动取消。有些场景你确实需要停——比如发现选错了一批图。这时候要确认工具是"取消当前张"还是"取消整批"，以及已经完成的译图有没有正常写入。我见过取消之后已完成的部分也没保存的情况，白跑。

3.4 进度怎么读才算"真进度"

进度条是最会骗人的东西。我总结下来，一个可信的进度提示应该包含四个信息：已完成张数 / 总张数、当前正在处理的第几张、已失败的张数、预计剩余时间。只有百分比是不够的，因为批量任务的耗时分布极不均匀——一张模糊的翻拍图可能比五张清晰截图还慢。

更实用的判断方法是看结果相册里的实际文件数。后台跑的时候我不看进度条，隔一会儿去目标相册刷一下，数一下新增了几张。这个数字是真实的，不会骗你。跑完的标志也很简单：连续刷新两次数量不再变化，且总数等于你勾选的数量减去失败数。

4. 译文怎么"贴"回图上：渲染环节的排版硬骨头

4.1 先判断能不能擦：覆盖 vs 重绘背景

这是整个流程里技术含量最高、也最容易毁掉观感的一步。把译文放回图上，无非两条路：擦掉原文再写新字，或者直接盖在原位置上。

擦除听起来高级，实际上很难做好。它需要先估计原文区域背后的背景（纯色气泡、渐变、纹理、照片），然后把文字像素去掉并填补。纯色背景（比如白底黑字的说明书、浅色气泡的漫画）效果好得惊人；复杂背景（照片上的文字、带纹理的菜单）就会留下明显的糊块，比不擦还难看。

直接覆盖更稳，但要注意覆盖块的样式。我见过最丑的做法是在每行文字上贴一个不透明的纯白矩形，结果深色界面的截图被贴得像打了补丁。好的做法是从原图采样背景色：取文字区域四周边框像素的中位数颜色作为填充色，文字颜色取原文字颜色的反色或高对比色。这样在深色底上填充深色块配浅色字，视觉上就自然多了。

下面这个对照表是我根据不同图型总结的选择依据：

4.2 字号自适应与行高：一个可落地的计算方式

中文译文和原文的长度差异经常把人坑到。英文翻中文通常变短（字符数少很多，但每个字更宽），日文翻中文长度接近，中文翻英文则明显变长。如果不做自适应，结果就是溢出气泡或者留一大片空白。

我的处理逻辑是这样的：先量出原文文字区域的可用宽度 W 和可用高度 H，然后按字号从大到小试，找到一个能装下的最大字号。具体做法是二分查找，初始上界设为H / 1.2（保证至少一行），下界设为 8 像素，每次取中间值，用当前字号估算排版后的总高度（行数 × 行高），如果超过 H 就把上界压低，否则抬高下界。

行高我一般取字号的 1.35 到 1.45 倍。低于 1.3 中文会挤在一起，尤其是笔画密的字（比如"翻""译"这种）；高于 1.5 又显得松散，跟原图排版风格不搭。行距这个参数没有绝对标准，但 1.4 是个很安全的默认值。

还有一个容易忽略的点：中文字符宽度基本一致，英文不是。所以按"字符数 × 平均字宽"估算宽度对中文比较准，对英文误差会大。如果译文是英文，最好用真实的字体度量（measureText 之类的接口）来算，而不是估算。

4.3 中文比原文长/短的问题

长度差异带来的不只是字号问题，还有对齐方式的问题。原文是左对齐的一段话，译文如果比原文短很多，左对齐会留出右边一大片空白，看起来像没写完；如果居中，又跟周围的排版不协调。

我的经验是按原文的排版意图来判断：如果原文是居中的标题或气泡内文字，译文也居中；如果原文是段落正文，译文保持左对齐（中文习惯）或者两端对齐；如果是按钮或标签这种极短文本，一律居中。判断依据看原文区域的文字分布——如果文字在框内左右边距接近，那就是居中；如果左边距明显小于右边距，那就是左对齐。

还有一种麻烦情况：原文一行，译文需要两行。这在气泡里特别常见，因为气泡是圆的，第二行可用宽度更小。这时候要么缩字号硬塞一行（可能小到看不清），要么老实换行并接受气泡被撑大。我倾向后者，因为可读性优先。

4.4 竖排、气泡、描边字的特殊处理

竖排文字主要出现在日文和部分繁体中文素材里。识别的难点是文字检测模型默认按横排聚类，竖排会被切成一个个孤立的字，翻译出来语序全乱。如果你的素材里有大量竖排，正确做法是在识别前先做一次 90 度旋转，把它转成横排再识别，翻完再把结果转回去。这一步手动做比指望工具自动判断靠谱得多。

气泡文字的难点在边界。气泡是圆形或椭圆形，文字区域的可用矩形其实比外接矩形小一圈。如果按外接矩形排版，译文的第一个字和最后一个字很容易压到气泡边线上。我的做法是把可用宽度打个 0.85 的折扣，宁可字号小一点也不要压边。

描边字/艺术字（常见于海报、封面、游戏截图）的难点是识别率低。这类文字往往有粗描边、渐变填充、投影，OCR 很容易识别成乱码或者干脆检测不到。遇到这种图，我的建议是别指望全自动，把这张从批量里拎出来单独处理，人工校对一遍译文再回贴。批量流程是用来处理那 80% 规整图片的，剩下 20% 老老实实手工，这才是效率最高的分配。

5. 另存为带译文的图片：命名、格式与画质取舍

5.1 三种输出形态：纯译图、对照图、叠加图

"另存为带译文的图片"这句话其实包含三种不同的产物，用之前要想清楚你要哪种。

纯译图：原文被完全替换，图上只剩译文。适合拿去分享、发给别人看、做资料存档。缺点是丢掉了原文，以后想核对原话就找不到了（除非你保留原图）。

对照图：上下或左右拼接原图和译图。适合学习场景，比如你在学一门外语，想同时看原文和译文；也适合需要核对翻译准确性的场合。缺点是图片尺寸翻倍，占空间。

叠加图：译图作为半透明图层叠在原图上，或者译文以悬浮标签的形式标在原位置旁边。适合需要"原位对照"的场景，比如看图纸、看界面截图，你需要知道每个词对应原来哪个位置。缺点是画面比较乱，不适合分享。

我日常用纯译图为主，遇到专业术语多的资料（比如设备说明书）会用对照图，方便回头查原文。选哪种形态在批量开始前就要定好，因为中途改要重跑。

5.2 格式与体积对照

输出格式这个选项很多人随手就选了默认，其实差别不小。我拿一批 25 张 1080P 截图做过对比：

关键判断点是图上还有没有小字。JPG 是有损压缩，它对付大面积色块很擅长，但对高对比度的文字边缘会产生振铃效应（文字周围出现淡淡的鬼影），字号越小越明显。如果你的译图里有 12 像素以下的小字，用 PNG；如果都是正常大小的正文，JPG 质量 90 完全够用，体积只有 PNG 的五分之一。

还有一个坑：反复保存。JPG 每保存一次都会再损失一次质量。如果你打算对译图做二次编辑（修个错字、裁个边），一定要存 PNG，编辑完再导出 JPG。我吃过这个亏，一张图改了三遍存了三遍，最后文字边缘糊成一团。

5.3 命名与归档规则，为以后找图省事

批量输出最容易被忽略的就是命名。默认名字通常是"IMG_20240101_xxxx_translated"这种，一周之后你完全不知道哪张是哪张。我现在用的规则是：

原文件名_语言对_批次日期_序号

比如menu_ja-zh_0315_03.jpg。这个规则的好处是：按文件名排序就是按批次和序号排，一眼能看出语言对；想找某一批的图，搜日期就行。序号补零（01、02 而不是 1、2）很重要，否则 10 会排在 2 前面。

归档上我坚持一个原则：译图单独建相册，绝不混在原图相册里。每次批量开始前新建一个相册，命名带日期和主题（比如"0315 展会资料 日译中"），所有输出直接落到这个相册。这样原图相册保持干净，译图也成组存在，需要的时候整组分享或者整组删除，非常清爽。

5.4 原图要不要留

我的答案是：一定要留，而且至少在确认译图没问题之前不要删。

原因很实际。第一，翻译可能有错，尤其是专有名词、型号、数字，你需要回头核对原文。第二，有些图的译文排版崩了（溢出、错位），你需要重跑，重跑得有原图。第三，原图里有 EXIF 信息（拍摄时间、地点），译图经过重新编码这些信息通常会丢，如果这些信息对你有用，原图是唯一来源。

空间紧张的话，我的处理顺序是：先把译图确认完，然后把原图批量移到一个"已翻译归档"相册，压缩成 WebP 或者上传到网盘，本地只留译图。这样既省空间又不丢底稿。

6. 实测中最容易翻车的六种图，以及处理办法

6.1 混合语言的图

一张图上同时有英文和日文，或者中文标题配英文正文，这是批量翻译的头号杀手。识别阶段通常只会用一种语言模型，另一种语言会被识别成乱码或者直接跳过。表现就是译图上一半正常一半是奇怪的符号。

处理办法有两个：一是拆图，把不同语言的区域裁开分别处理；二是手动指定主语言，接受次要语言翻不出来，至少主语言是对的。如果这种图很多，我会把它们单独归一批，选"自动检测语言 + 高精度模式"，速度慢一点但准确率高。

6.2 低对比度与小字

灰色文字配浅灰背景、或者 8 像素高的小字，识别置信度会掉到 0.5 以下。这类图翻出来的结果通常是缺词、错字、或者整行丢失。更麻烦的是它不会报错，你只有在验收的时候才能发现。

我的应对是预处理增强：进批量之前先对这类图做一次对比度拉伸和锐化。手机上很多相册应用自带"增强"功能，点一下就行。另一个办法是把长边放大到 2400 再识别——虽然违背了我前面说的 2000 上限，但对于小字图，放大带来的识别提升值这点时间。

6.3 竖排与倾斜

倾斜超过 15 度的文字，检测框会歪，识别会串行。竖排前面已经说过，转 90 度是最稳的办法。倾斜的话，很多工具会做自动旋转校正，但校正失败的时候它不会告诉你，只是默默地给出错误结果。

一个简单的自检方法：译图出来后，看译文的方向跟原图文字的方向是否一致。如果原图是斜的而译文是水平贴上去的，说明校正没生效，这张需要手动转正重跑。

6.4 带水印和半透明叠加的图

水印最讨厌的地方是它会被识别成正文。你翻出来的译文里会莫名其妙多出"某某素材网"或者一串网址。半透明叠加的文字（比如视频截图上的字幕底衬）也会干扰检测。

这类图没有太好的自动办法。我的做法是先裁掉水印区域再进批量，或者接受译文里有多余内容，后期手动删掉那几个字。如果水印在图的角落且不压正文，裁剪是最快的。

6.5 艺术字与手写体

海报标题、封面大字、手写便签，这三类识别率都很低。艺术字的笔画被拉伸变形，手写体的字形千变万化，OCR 模型在这种输入上基本靠猜。翻出来的结果大概率是乱码。

我的原则很明确：这类图不进批量。批量的价值在于处理规整的、量大的、机械的活；艺术字这种需要人判断的，手工处理反而更快。硬塞进批量只会让你在验收阶段花更多时间去挑错。

6.6 超长图与超宽图

长截图（长宽比超过 1:4）和全景图（长宽比超过 4:1）在缩放环节会出问题。长边压到 2000 之后，短边可能只剩 200 多像素，文字彻底糊掉。

处理办法是先切分再批量。长截图按屏切，每段控制在常规比例；全景图按内容块切。切分这一步花的时间，远小于识别失败后重新处理的成本。

7. 我常用的两套参数组合，直接抄

跑了几百张图之后，我稳定下来两套配置，覆盖了九成场景。

A 套：规整截图快跑。适用于应用截图、网页截图、聊天记录里的图片。长边 1600，并发 3，批大小按单图，节流 300ms，输出 JPG 质量 90，纯译图形态。这一套的速度大概是每分钟 15 到 20 张，识别准确率很高，基本上跑完不用怎么校对。

B 套：翻拍资料精跑。适用于菜单、说明书、展板照片。长边 2400，并发 2，节流 500ms，输出 PNG，对照图形态，同时开透视校正和高精度识别。速度会慢到每分钟 5 到 8 张，但准确率和排版质量明显更好。

选哪套的判断依据很简单：看文字是屏幕渲染的还是光学拍摄的。屏幕渲染的走 A 套，光学拍摄的走 B 套。混着跑就是两头不讨好。

最后分享一个我用了很久的小技巧：批次跑完之后，别急着删原图，先在结果相册里按文件名倒序看最后三张。批量任务的失败往往集中在尾部——要么是内存吃紧，要么是接口被限流。尾部三张没问题，整批基本就稳了；尾部三张有问题，往前多看几张，通常能找到一个明确的转折点，那之后的都得重跑。这个习惯帮我省过好几次"以为跑完了其实后半截全废"的事故。