最近在做图片相关的 App 开发,遇到了一个让头发差点掉光的坑——Live Photo(实况照片/动态照片)。

本来以为把 Live Photo 保存到手机相册是个标准动作,结果真机实测下来,简直是“一个厂商一个坑”。搞定了华为,发现小米又是另外一套标准;好不容易兼容了小米,一上 OPPO,发现又不行了。国内这几家大厂,真的是各玩各的,完全没有统一标准。

今天就跟大家聊聊这个让人头秃的难题,以及目前能想到的一些解决思路。

Live Photo 概念示意图

Live Photo 由静态图片和视频组成

为什么这么难?

众所周知,iPhone 的 Live Photo 是一个成熟且封闭的生态,由一张静态图片(JPG/HEIC)和一个配套的视频文件(MOV)组成,系统相册原生支持,API 也给得比较足。

但在 Android 阵营,情况就复杂多了。

Google 也不是没努力过,早在 Android 7.0 就引入了 Motion Photo API,试图通过在 HEIF/HEIC 容器中嵌入视频流(或者作为元数据引用)来实现动态照片。但是,由于历史原因和商业利益,国内各大厂商并没有完全跟进这个标准(特别是早期机型),或者在其基础上进行了魔改。

Android 手机品牌徽标

国内安卓厂商生态碎片化

这就导致了极其碎片化的现状:

  • 华为:部分机型倾向于使用 HEIF 格式封装,视频流可能深埋在元数据里,或者通过特定的目录结构关联(比如在一个特定的命名规则下,图片和视频文件成对出现)。
  • 小米:早期机型可能直接保存为 MP4 视频和 JPG 图片的组合,依靠文件名匹配;新机型虽然支持 HEIC,但封装方式和读取逻辑依然有“私货”。
  • OPPO/vivo:也是五花八门,有的机型将视频作为元数据嵌入,有的则是纯粹的分离文件,甚至对不同相册应用的兼容性也不一样。

这种差异导致开发者调用系统的 MediaStore API 或者直接文件操作时,根本无法用一套代码跑通所有机型。你以为保存成功了一张“动态图”,结果在某些相册里只能看到静止的 JPG,视频流要么丢了,要么系统压根识别不出来。

相册文件分离示意图

双文件保存法示意图

有没有通用的解决方案?

面对这种现状,指望厂商一夜之间统一标准是不现实的。作为开发者,我们只能“见招拆招”。这里整理了一些目前比较可行的技术思路:

1. 降级兼容:双文件保存法

既然各家封装格式不统一,那我们就回到原点——“最笨”但也最稳妥的方法。

无论手机原生支持什么格式,App 在保存 Live Photo 时,强制保存为一张静态图片(JPG/PNG)和一个独立的视频文件(MP4)

代码检测品牌

检测手机厂商代码逻辑

  • 优点:逻辑简单,所有 Android 手机都能识别视频和图片文件,不会出现数据丢失。
  • 缺点:用户体验差。用户无法直接在系统相册中享受“长按播放动态图”的效果,只能看到两个独立的媒体文件。这更像是一个变通,而非真正的 Live Photo。

2. 使用 Google 的 Motion Photo 标准(选择性支持)

对于 Android 9.0 及以上,且相对“原生”的三星、Pixel 或部分较新的机型,可以尝试使用 Google 的标准 Motion Photo 格式。这通常需要使用 ExifInterface 或专门的图像处理库(如 Glide 或自定义解码器)将视频流写入 HEIF 容器的元数据中。

但要注意,这需要大量的机型测试,特别是要处理写入失败时的回退逻辑。

3. 自研封装或第三方库(硬核实操)

如果你必须让用户在相册里看到真正的 Live Photo 效果,可能需要针对不同品牌做适配层:

  • 判定厂商:运行时检测 Build.MANUFACTURER
  • 适配逻辑
    • 华为:尝试解析其特定的元数据结构,或者使用华为公开的特定 API(如果有)。
    • 小米/OPPO:尝试将视频嵌入图片特定轨道,或者按照厂商相册能识别的命名规则(如 IMG_20230815_123455.mp4IMG_20230815_123455.jpg 必须在同一目录且时间戳一致)进行文件落盘。

目前市面上没有特别完美的开源库能一键解决这些问题,很多时候需要自己读 AOSP 源码或者反编译厂商相册来看他们的识别逻辑。

4. 引入 FFmpeg 进行转封装

既然原生 API 乱得一塌糊涂,不如自己掌握控制权。

引入 FFmpeg,将 Live Photo 统一转封装为一种兼容性较好的格式(比如 Motion Photo 标准的 HEIF),或者干脆在 App 内部维护一个“动态图”的概念,用户只有在你的 App 里才能播放动态效果(类似微信朋友圈的逻辑),导出到系统相册时只提供静图或独立视频。

这虽然牺牲了系统级生态联动,但能保证功能的稳定性。

总结

安卓 Live Photo 的适配,归根结底是国内厂商“诸侯割据”的产物。作为开发者,除非你有巨大的体量去倒逼厂商提供标准 API,否则只能通过**“双文件兜底 + 针对性适配”**的混合策略来应对。

如果你也在做相关开发,欢迎在评论区分享你遇到的奇葩机型和踩坑经验,大家一起集思广益,或许能摸出一条最优解。

标签: none

评论已关闭