2026-10-21
一台中端安卓机拍出来的照片，默认设置下常在 3 到 6MB，开启高像素模式能到 10MB 以上。发邮件、填报名表、传到公司系统，卡住的概率很高。压缩安卓照片有四种不装 App 的做法：相册自带的编辑导出、Google 相册的画质选项、分享时系统给的尺寸档位、以及用 Chrome 打开浏览器本地压缩工具定目标大小。前三种零门槛但控不住具体数字，第四种能压到指定 KB。
原因有两个，一个是像素数，一个是编码。一亿像素模式拍出来的原始信息量摆在那里，而安卓阵营默认多用 JPEG 存，少数机型用 HEIC 或 HEIF，同画质下比 JPEG 省四到五成。省归省，一次发二十张照样扛不住。
真正决定体积的是像素数和压缩质量这两项，跟用什么手机拍的关系没那么大，这点在 /blog/image-resolution-vs-file-size 里拆过。所以压缩的第一步不是找工具，是先想清楚这张照片最终要多大：发朋友圈和冲印 6 寸是完全不同的两个目标。
顺带一个常见误会：系统相册里显示的「已优化」「已备份」不代表本地文件变小了。云端存的是另一份，本地原图还在。
这条路的好处是系统自带、不产生新安装。短板也很明确：档位是固定的，压完多大要靠结果说话，而且各家相册的入口位置不一样，换台手机就得重新找一遍。
Google 相册的「存储节省器」会把已备份的照片在云端换成画质略低的版本，本地那份不受影响。它能释放的是云端空间，不是本地空间。
所以如果你的目标是「把这张照片变小然后发出去」，这条路帮不上忙。
这是最省事的一种，局限也最明确：只在那个 App 里生效，压完拿不到一份可以复用的小文件，而且档位是系统定死的。邮件附件该压到多大写在 /blog/compress-image-for-email-attachments 和 /blog/compress-photo-to-1mb-email。
如果卡着某个具体上限，比如报名表要求 200KB 以内，前三种都给不了保证。这时用浏览器本地工具：
这条路的好处是三件事同时成立：不装 App、不上传到别人的服务器、能压到具体数字。文件从头到尾都在手机里处理，对含人脸或工作材料的照片挺重要。压缩会不会掉画质单独写在 /blog/does-compressing-image-reduce-quality，一次处理几十张的做法写在 /blog/batch-compress-images-multiple。
部分安卓机型拍照默认存 HEIC 或 HEIF，同画质下比 JPEG 小。问题出在接收端：不少企业系统、老版本 Windows 和一些在线表单不认这个格式，传上去直接报错，而报错信息往往含糊，看起来像文件太大。
判断顺序是先看收件方是谁，再决定要不要转，而不是一律先转 JPEG，因为转成 JPEG 之后再压缩，体积优势就没了。iPhone 那边的同款判断和转换步骤见 /blog/heic-vs-jpg-iphone-photos 和 /blog/convert-heic-to-jpg-free。
看尺寸。压到 1920px 宽、200KB 左右，冲印 6 寸没问题，A4 以上会看出细节不足。要打印就别压太狠，先定尺寸再压质量。
多数情况不是体积，是格式。系统不认 HEIC 时会给出模糊的报错，看起来像文件太大。也有部分表单同时卡尺寸和像素数，先看清限制写的是哪一项。
不会，这选项本身就是为了留原图。但不同品牌措辞不一样，看到只有「保存」没有「另存为」时，先确认一次再点。
不会，批量只是把同样的一次处理跑二十遍。真正伤画质的是同一张图反复压缩，每压一次细节少一层，原因见 /blog/does-compressing-image-reduce-quality。
思路一样，入口不同。iPhone 靠快捷指令做批量，安卓多数靠相册自带的编辑导出，两边都能用浏览器本地工具定目标大小。iPhone 那三种方法写在 /blog/compress-photos-iphone-3-ways。