摘要生成中...
AI 摘要
Hunyuan-lite

动态图片不是最近才有的东西，但我也是这两年才慢慢接受并使用它。对于我的这个态度转变过程的原因有很多，可能是各大 APP 开始支持动态图片展示掀起不小的热度，又或者是去年我换了一个拍照好看的手机，还可能为近期各种游游游拍拍拍想如实生动的记录下来……为了使我的博客以更丰富的形式展现生活状态，我开始有了让我的博客支持动态图片的方法。

Readme Card

本文介绍了我新开发的一款支持在 Hexo 博客中插入实况照片（动态图片，Live Photo）的插件 @uuanqin/hexo-filter-live-photo的一些心得和使用方法。该插件最简单的使用方式为：只要提供一个常规的视频链接，就能在博客中插入一张动图！

Live Photo
Live
鹅岭公园的小猫 Kitten in Eling Park

更多展示示例详见：站内文章动态图片测试。想直接看使用方式的直接看后面的部分 😥

期待你的 Star⭐~ 欢迎 Issues & PRs！诚挚邀请大家体验插件🎉~

会动的照片诞生在 10 年前

实况照片通过记录快门前后一两秒的动态影像和声音，将静态摄影的瞬间捕捉能力扩展到了动态的时间维度。

现在的比较完善的「会动的照片」功能最早出现在 2015 年苹果手机上，叫 Live Photos；安卓这边与之对标的相似功能叫「实况照片」或「Motion Photos」。如果还要往前追溯，那就是 2012 年诺基亚推出的「动态图片」功能，或者是各类厂商的「连拍」「照片集」功能，但是那时候的动态照片还没有声音，整体功能还处于探索阶段。

实况照片对于年轻人来说是一种很有新鲜感和展现生命力的照片形式。——OPPO

近两年来，随着微信、小红书和抖音等社交平台对实况照片的陆续支持，加上手机厂商对实况照片技术的不断跟进，这项 10 年前的技术又在最近小火了一把。

为了便于后文叙述，我把 实况照片、动态照片/图片、Live Photos 就混在一起讲咯。

实况照片的本质就是静态图像加上动态的影像的融合记录。不同厂商对于实况照片都有各自的实现：

厂商 实况照片的实现方式
苹果 早期版本中，一张实况照片由两个独立的文件组成，通过相同的文件名（不含扩展名）和特定的元数据 ID 进行关联。现代模式中，苹果通过一个 HEIC 容器封装实况照片。
谷歌 将视频嵌入在 JPEG 文件的 MP4 容器尾部（Micro Video）。现在新机型已经使用新标准（Motion Photo）。
三星 类似于早期 iOS，使用独立的视频文件或嵌入式结构。现在新机型已经使用新标准（Motion Photo）。
小米 现在 HyperOS 3 支持安卓动态照片新标准（Motion Photo）。

实况照片的实现技术划分为苹果和安卓两大阵营，下面的表格对比了两大手机阵营动图实现方式的差别：

阵营 苹果 安卓
封装格式 HEIF JPG
内容形式 照片 + 视频 照片编码数据 + 视频编码数据
编辑支持 编辑过后不会丢失数据 一经编辑就会丢失视频数据
还原支持 编辑过后仍可还原 一经编辑不可还原
压缩效率 压缩效率高，文件较小 压缩效率低，文件较大
导出支持 不支持 .heif 导出 支持 .jpg 直接导出
兼容性 编解码特殊，兼容性差 容易被魔成独占格式
内容提取 原文件导出即可分离出图片和视频 提取封面图片或视频困难

安卓阵营中各厂商实现方式也有所不同，且互相不一定兼容。不同厂商还可以需要动态照片中有自己的「私货」元数据才能识别动态照片。

博主使用的是小米手机，对于小米手机的动态图片的实现，我也有自己简单的探索。通过实操可以得到的现象和确定的事实如下：

  • 小米手机拍摄出来的动态图片命名格式为 MVIMG_YYYYMMDD_XXXXXX.jpg。这个前缀通常是用来标识安卓动图 MVIMG 的。
  • 小米手机拍摄出来的的动态图片以 JPG 结尾，视频数据存在于图片中，没有链接到其他文件夹中隐藏的视频。
  • Windows 自带的「照片」软件可以自动识别为动态图片。
  • 这个网站 可以直接解析小米的动态图片。
  • 小米相册中的部分编辑操作会导致「超动态预览关闭」，将动态图像变为普通静图，但即使未进行任何编辑，生成的静态图片体积反而会增加。

在一瞬间，我闪过了想用 站内文章010 编辑器 一探究竟的可怕想法，但被「上过 🐢⭐课」的回忆给打消了。

小米动图封装思路其实是把视频封装进了 JPG 图像的结尾，并通过 XMP 元数据标记出视频的位置，没有夹带「私货」元数据。在受支持的图片查看器中会显示为「动态照片」，在不受支持的查看其中仅显示封面图片。

image.png

现有技术调研

对于苹果的 Live Photos，官方提供了解析库 LivePhotosKit JS 以方便网页解析动图。基于这个解析库之上，不少开发者已经为其开发了在 Hexo 解析动图的插件。比如：Hexo 中实现 Live Photos 支持。而小米并没有提供相关的官方 JavaScript 库，只提供有 APP 应用集成 SDK——但这并不是我想要的。

Hexo 中已经有开发者开发过类似的插件，或者有过类似的实现。@程小客 开发了一款 JavaScript 库 Livephoto.js 以及对应的样式，使我们可以轻松的在网页上复现手机拍摄的动态图片的效果。它的基本使用方法为，在网页中引入写好的 JavaScript 和 CSS 文件，然后通过在插入 HTML 代码块进行实现：

1
2
3
4
5
6
<div class="live-photo-container">
    <img src="path/IMG.jpg" alt="描述文字" class="live-photo-static" />
    <video muted playsinline class="live-photo-video">
        <source src="path/VID.mp4" type="video/mp4" />
    </video>
</div>

HTML 代码块灵活性非常高，我们只需要填充好视频链接和封面链接就可以完成一张动图的插入了。对于 Hexo 用户，@程小客 基于这个库还特别开发了 Hexo 插件 @cykzht/hexo-live-photo，支持通过 Hexo 独有的「标签插件」语法完成对动图的插入：

1
{% livephoto image_path video_path %}

了解我的朋友都知道 [1]，虽然我用 Hexo 博客，但我宁愿自己开发工具，也不会用 Hexo 的标签语法的，因为它的语法侵入性太大了。但是对于「动态图片」这个新事物，现有的 Markdown 语言根本不支持，所以我还需要思考应当以何种形式，在最大限度保证语法纯洁和各平台兼容性上实现动图的插入。

自己开发插件前的构思

我首先想到的的是直接以 Markdown 图片格式完成动图插入，这可以说是很贴合 Markdown 原生的方式了，毕竟都是「图」嘛。我们只需要在 Obsidian、Hexo 平台开发相应的插件，自主解析图片是否为动图，然后按需渲染。这种方式的好处为：

  • 方便文档编写者插入图片；
  • 方便对图片的管理；
  • 不会破坏现有的所有文档工作流。

这种方式对文档编写者来说是最不打扰的方式，但是弊端也明显。还需要考虑：

  • 如果解析动图的职责将交给客户端，那么会有网页性能挑战。对于执行安卓标准的动图，没有像苹果那样的现成库，开发成本较高（懒）；
  • 解析动图的职责可以交给博客框架，在编译期间解析。但是这同样也有开发成本（懒），而且如果后续开发 Obsidian 插件，思路可能又不太一样。

基于上述考虑，我也放弃了直接以 Markdown 图片格式完成动图插入的想法，心中也放开一定的界限，允许有限语法侵入。这样一来，其实上面调研过的 Livephoto.js 直接嵌入 HTML 代码块是可以接受的了：

  • Hexo 允许第三方 JavaScript 和 CSS 接入；
  • Obsidian 可以引入 CSS，对动图有一个「降级」的封面展示；
  • 通过 Obsidian 的 scaffolds 设定模板，插入 HTML 模板也不麻烦。

但其实我还是想花费同样的语法侵入成本，保持一定灵活性的同时，用更优雅的方法实现动图的插入。毕竟在 Markdown 块插入一堆 HTML 显得过于「雷霆原生」了💩。

回想到，我之前写过 站内文章类似项目，就是利用 Markdown 超链接语法实现自定义 HTML 块的插入。理论上，@uuanqin/hexo-filter-custom-link 确实是可以实现当下的要求的。但是我一直对这个插件不太满意，因为它像是侵占了原生 Markdown 的含义，并定义了自己一套小众的「使用规范」，虽然没有涉及新语法，但还是有点打擦边球了。经过一波词元交流后，我的目光看向了「自定义代码块」。

自定义代码块的实现形式是在原先 Markdown 代码块语法中，将标记渲染语言位置中的词换成自己自定义的词，通过识别块进行自主的参数解析（通常是 YAML 的形式）和渲染。在 Obsidian 第三方插件生态中，很喜欢用这种形式实现各种各样的拓展功能（这也为打通 Obsidian 铺路）。

1
2
3
4
```custom_name
key1: arg1
key2: arg2
```

大致思路为，通过正则识别块，用 YAML 库解析参数，在 Markdown 渲染前完成自定义渲染内容的插入。代码块怎么看都比 HTML 顺眼，遇到降级显示时也不复杂，一眼看出是啥。视频和封面分别配置的方式虽多了步骤，但是更灵活，我们就不需要考虑各种手机厂商不同的动图规范了。

因为我之前有过开发 Hexo Filter 插件的经验 [2]，加上现在也有前人现成的 Livephoto.js 库，和 AI 充分讨论后判定为「可行」，于是新插件就着手开发了~

插件介绍

前面铺垫了这么多，终于进入正题了！

@uuanqin/hexo-filter-live-photo 是由我开发的一款方便用户在 Hexo 博客插入实况照片的插件，插件通过识别 livephoto 或 live-photo 自定义代码块中的视频地址及其他参数，完成可定制的动图插入。主要功能有：

  • 基本功能：动图的展示和播放设置、微信环境优化。也就是 Livephoto.js 库中的基本功能，具体而言：
    • 指定封面链接
    • 指定图片 ALT 文本
    • 动图标题
    • 动图宽度和高度的指定
    • 微信浏览器环境识别
  • 视频加载时有加载效果。
  • 支持配置动图图片循环播放。
  • 支持交互式声音按钮，并优化声音播放体验。
  • 其他在视觉、性能以及用户体验方面的优化。
插件不支持 Hexo 的「标签语法」

如有标签语法插入需求，请参考这个项目：cykzht/hexo-live-photo

Live Photo
Live
鹅岭公园的小猫 Kitten in Eling Park

其他各种动图预览详看这篇文章：站内文章动态图片测试。最小可运行的代码块插入示例为：

1
2
3
```livephoto
src: /live-photo.mp4
```

更多参数说明详看 项目文档。当我们在手机上拍摄好动图并打算上传到 Hexo 博客时，我们可以利用手机自带的导出为视频、导出封面等功能，或通过在线动图分解 网站，得到封面信息和视频文件。然后将这两个文件妥善安置（放博客资源目录或 CDN），并在动图块中填入地址即可。

欢迎大家试用并反馈意见~

后记

每个新插件例行都会写开发杂记，这篇文章把一些心路历程融合了进来。

插件开发周期大概为 5 天（全天），1 天调研、3 天开发、1 天审查和各种收尾。这次的项目实践也是有一次的 AI Coding 实践，虽然是基于前人开发的 JavaScript 库上做的，但是在各种功能改进的过程中，自己也慢慢把源代码给消化了，学习到更多样的 Hexo 插件开发方式。

通过近期几项 AI Coding 实践，我总结了一些经验要点：

  • 开发功能前，需要对需求进行讨论和打磨。确定功能实现内容和实现的方式；
  • 做好版本管理，必要时重做回退；
  • 必须人工审查 AI 给的代码，核对仔细修改位置和修改细节，理解代码含义；
  • 小功能，小修复逐步迭代；
  • 最后一步，检查代码性能，检查代码的可维护性。

这个插件的开发解决了动图在 Hexo 中的展示，但在实现 Hexo-Markdown-Obsidian-COS「打通」前还有一定的路要走。不过现在我已经看见了前人铺好的台阶🌟，敬请期待我的下一个项目~

本文参考

工具：

  1. 不了解的朋友也可以从这两篇文章中窥之一二：站内文章第一次开发 npm 插件、站内文章第一次写 Hexo 插件。 ↩︎

  2. 可以看看我写的 Hexo 插件：站内文章Hexo 博客适配 Obsidian 新语法、站内文章hexo-filter-custom-link。 ↩︎