近期，我的新作品「HEIF & HEVC 转换器」已在 App Store 发布。这款 App 能够将 iPhone、iPad、Mac 相册中的照片和视频，转换为更高效的 HEIF/HEVC 格式，在尽可能减少画质损失的情况下，节省存储空间。
为庆祝 App 上架，在文章末尾，我将提供 20 个 App 兑换码。欢迎兑换并下载体验。
开发背景
2017 年发布的 iOS 11，增加了对 HEIF 和 HEVC 格式的支持，这两种新格式具有更高的压缩率，占用存储空间较少。新拍摄的照片和视频，默认都会保存为 HEIF 和 HEVC 格式。
我的 iOS 相册中，几乎保存了自己的所有照片，包括 2017 年之前拍摄的照片、其他人分享给我的照片，还有使用 Google 照片扫描仪扫描的老照片。这些照片大多是 JPEG 格式。
iOS 11 发布后，我一直想将这些照片转换为 HEIF 格式，减少空间占用，但一直没有找到合适的工具。所以我打算开发一款工具，实现这样的功能，但是一直没有开始动手。
由于 AI 编程工具的逐步普及，我觉得在 AI 的帮助下，自己能够更快地实现想要的功能。于是，我开始使用 Alex 等编程工具，进行了此项目的开发。
功能与特色
- 支持批量转换整个照片图库，也可手动选择指定照片和视频进行处理
- 兼容实况照片（Live Photo）：图片部分转换为 HEIF 格式，视频部分转换为 HEVC 格式
- 尽可能多地保留照片元数据，包括位置信息、收藏状态等
- 转换后的照片，仍会放在原始相册，无需重新整理
- 全程在本地转换，不联网，不泄漏隐私
转换效果
在默认设置下（JPEG 图片质量为 90%，PNG 图片质量为无损，视频质量为「高质量」），我尝试转换了照片库中的一部分照片和视频，共 20GB。转换后节省了 6.25GB 的空间：
查看具体的统计信息，可以看到 PNG 图片（一般是截图）的压缩率最好：953.1MB 的图片，压缩后只剩下 97.3MB。JPEG 照片也有着不错的压缩率，节省了接近一半的空间。对于视频，节省的空间较小，原来 7.12GB 的视频，压缩后还有 6.76GB：
经过分析，在默认配置下，部分视频转换后会变小，部分视频转换后会变得更大，整体看还是能节省空间的。在当前版本中，我已经对 Live Photo 的视频部分进行了优化，如果转换后的大小大于原视频，则只转换照片部分，视频部分仍使用原始视频。后续版本，我将提供一个选项，用户可以选择是否保留转换后变得更大的视频。
提示与技巧
- 如果照片视频较多，想要分批转换，可以在转换一部分媒体后，直接点「取消转换」；已经转换的媒体仍可以保存到照片图库；
- 如果转换过程锁屏、关机，或任务切换，导致此 App 被杀后台，已转换的媒体不会丢失；只需重新打开 App，按照提示保存已转换媒体即可；
- 除了 iPhone 和 iPad，此 App 还支持 Apple Silicon Mac。在 Mac 上转换性能更好，而且 App 能长时间在保持在后台运行，持续转换；
- 推荐搭配 CleanMy®Phone、ByePhotos 等 App，以及 iOS 相册中的「合并重复项目」功能使用。这些工具可以清理重复照片、模糊照片、屏幕截图等，而且能调整视频的分辨率和质量，进一步释放存储空间；
- 为了使 App 能够发挥其全部功能，建议打开 App 的网络权限，并允许完全访问照片图库（下文会解释这两个权限的具体作用）；
- ⚠️ 转换完成后，原始媒体将被删除。为了确保数据安全，使用前请先完整备份照片图库。
由于照片和视频的转换，涉及较多细节处理。开发者不能保证所有媒体都能成功转换。如果发现有无法转换的媒体，或者转换后出现色彩错误等问题，请与我邮件反馈（feedback at blanboom.org），并在邮件中附上有问题的照片或视频。
常见问题
为什么 App 需要网络权限？
如果打开了 iCloud 照片的「优化存储空间」，App 在获取照片和视频的原始文件时，需要从 iCloud 下载，从而触发了 iOS 请求网络权限。
具体来讲，在扫描阶段，由于不同格式的视频，可能会有相同的扩展名，例如 .mov，所以无法根据扩展名判断视频格式。App 需要获取视频的更多元数据，这个过程触发了 iCloud 下载。
在转换阶段，对于所有的待转换媒体，App 都会从 iCloud 获取原始文件。
除此之外，App 不会与其他第三方服务器通信。
为什么建议允许 App 完全访问照片图库？
此 App 会在保存照片和视频的过程中，获取其所在的相册。转换后的照片，也会放在原有的相册中。
由于 iOS 的限制，如果只允许访问部分照片，则 App 无法获取到媒体所属的相册信息，导致转换后的媒体，无法放回到相册中。
HEIF/HEVC 格式的兼容性如何？是否存在与其他 App 或设备不兼容的情况？
简单来说，如果你在 2017 年之后使用 iOS 拍照，且没有遇到不方便的地方（例如照片发送给别人后无法打开、第三方 App 和设备无法识别照片等），那就不需要担心兼容性问题。
2017 年发布的 iOS 17，会将照片和视频默认保存为 HEIF/HEVC 格式。而且 iOS 做了不少兼容性处理，例如分享照片时，会根据情况自动转换回 JPEG 格式。这保证了用户基本感受不到兼容性问题。
不过，当时仍有一部分 App 和设备，例如 Google Photos，以及群晖 NAS，对 HEIF 格式的不是很完善。不过在后续的几年里，这些 App 大多都陆续完善了对 HEIF 格式的支持。
当前版本已知缺陷
- 当转换大量照片时，转换速度会越来越慢；
- 暂不支持 HDR Gain Map：在转换 iOS 14.1 及以上版本拍摄的，带有 HDR Gain Map 的 JPEG 照片后，HDR 效果会丢失。由于 iOS 11 之后的版本，照片已经默认保存为 HEIF 格式，此问题不会影响大部分用户。
关于 AI 编程
先说结论：App 超过 90% 的代码都来自 AI，但开发过程并没有想象中简单
先说结论，「HEIF & HEVC 转换器」的共有 21 个 swift 文件，5808 行代码，其中 90% 以上的代码都是 AI 生成的。包括 App 的图标，也是 AI 创作的。
blanboom@blanboom-studio ~/W/ConvertToHEIFHEVC (develop)> cloc .
43 text files.
34 unique files.
53 files ignored.
github.com/AlDanial/cloc v 2.04 T=0.03 s (1274.5 files/s, 285252.9 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Swift 21 954 416 5808
JSON 5 0 0 156
Markdown 3 18 0 144
XML 5 0 0 114
-------------------------------------------------------------------------------
SUM: 34 972 416 6222
-------------------------------------------------------------------------------但是，开发 App 的过程，并没有像《我用 Cursor 半小时制作了一个网站》、《我用 Cursor 两小时开发了一个 App》之类的文章所说的那样简单。目前的 AI 辅助编程工具，还无法做到提一个需求，就生成一个复杂的 App。
我需要将需求细分成小的功能点，让 AI 针对单一功能点生成代码，解决编译错误，运行和调试，然后继续下一个功能点的开发。
回顾了一下 git log，从 2024 年 12 月首次提交代码，到 App 发布，一共花了四个月的时间。我主要利用每周末的空闲时间进行开发，每周大约投入四小时左右。
Cursor 与 Windsurf 初体验
最初体会到 AI 辅助编程的便利，是在为 AirTerminal 增加 Telnet 服务器功能 时、的时候。当时我还没有使用专门的 AI 编程工具，只是通过与 ChatGPT 的几轮对话，就成功实现了功能，包括界面和具体逻辑。
在开发「HEIF & HEVC 转换器」初期，我尝试了 Cursor 和 Windsurf。两款工具的体验基本类似，由于 Windsurf 更便宜，我选择了为 Windsurf 付费，并顺利完成了 App 最初的照片转换功能。
但随着项目复杂度增加，这两款工具为了节省上下文长度，经常只给 AI 提供代码的一小部分，而非完整文件，导致生成的代码频繁出现问题和编译错误。
改用 Alex
后来，我了解到 Alex，这款工具可以直接集成到 Xcode 中，避免了频繁在 Xcode 和其他编辑器之间来回切换的麻烦，更重要的是，Alex 会尽可能向 AI 提供完整的源文件，使得生成代码的编译通过率和实际可用性都明显提高。
期间，我也试用了 Cline 和 Roo Code，它们虽然也能提供完整的文件上下文，但必须使用自己的 API Key，按使用量付费，长期使用成本较高。我在配合 OpenRouter 上的 Claude 3.5 Sonnet API 使用一晚上后，就发现已经用掉了 10 美元。即使切换到更便宜的 DeepSeek V3，仍会花费较多费用。
此外 Cline 和 Roo Code 具有更高级的自动化功能，例如执行终端命令，获取 Git 的 commit 日志，或者自动编译并修复编译错误等。但实际体验发现，如果完全放任 AI 自动操作，不进行人工干预，修改后的代码往往会偏离最初的需求。
因此，我最终还是选择了与 Xcode 集成更紧密的 Alex。
使用 AI 编程的经验
在使用 Cursor 等 AI 编程工具，从零开始开发一个新项目时，我相信大部分人都会和我一样，都会惊叹于 AI 编程带来的神奇体验：只需简单几轮对话，就能生成一个可用的 demo，并成功运行。这很容易让人产生一种错误：AI 编程原来如此轻松。
然而，当项目复杂度逐渐提升，这种轻松感就会慢慢消退。此时，我开始尝试一些额外的技巧，让 AI 持续稳定地辅助自己编程：
- 首先，我需要对功能点继续细分，让 AI 更准确地理解需求，一次只完成一个小功能。有时候我想偷一下懒，一次让 AI 完成两三个功能，生成的代码往往就不能很好地工作了；
- 当一个文件变大后，我开始尝试对文件进行拆分，避免单个文件过大；
- 项目文件变多后，我开始为项目增加
.cursorrules、.windsurfrules、.clinerules等文件，在其中描述项目的代码结构，和每个文件的功能。这有助于让 AI 更容易找到需要的文件。
当项目变得更加复杂，即使用了上述技巧，并从 Windsurf 换成 Cursor，AI 也不能很好地工作了。这时候，我需要进一步熟悉和理解项目代码结构，在提问时，找出关键代码并进行解释。通过这样的方式，AI 仍然可以逐步实现自己需要的功能。
在项目调试和解决复杂问题时，我经常使用的一种方法，是让 AI 生成详细的日志，再将运行结果和日志反馈给 AI。反复几轮对话后，一般都能成功解决问题。
对于模型的选择，我优先使用的是 Claude 3.5 Sonnet，在编程方面有着不错的效果。后来推出的的 Claude 3.7 Sonnet 整体用下来，没有 3.5 效果好，但更适合进行图形化界面方面的任务。所以在项目后期，我主要用 Claude 3.7 Sonnet 优化界面。
总结与个人感受
目前我从事网络协议方面的开发，主要使用 C 语言开发 Linux Kernel 中的网络协议栈，以及在 Linux 用户态实现路由协议。所以完成这个 App 的过程，完全无法用到自己的工作经验。
我的 iOS 开发知识，主要来自 Stanford CS193p iOS 开发公开课，以及开发 HackerRemote 和 AirTerminal 这两个简单 App 时的一些积累。整体上讲，我对 iOS 开发谈不上熟练。
这些 AI 编程工具，并没有让我实现「提出需求、自动制作完整的 App」。但是，它们却能让我这个非专业 iOS 开发者降低开发一款新 App 的心理压力，并立刻行动起来，利用自己的有限时间，将想法一步步变为现实。
兑换码
- M6YMFPF67L36
- TFJ3AJANFAXJ
- 46P4FFANP3ME
- RP9RWRAAMKE3
- LJETHTNYTWLH
- NF7YWMEY9YT3
- F3P9KXNATWPJ
- A3NLY4EYFALX
- WH4RJJ993XKR
- AXW7F7T67XLA
- X33JNRLALH3J
- F96X7J79N6XM
- LKHJNM4YYFWY
- H6JW7WT64YJE
- RN3HY9YJX4Y7
- 6RLJPMRXM4XR
- 6K4X4AL4JL37
- KRYLH9FXKTFF
- 4K7AY4KRY7KM
- JMX3WMM439FP
可在浏览器中打开此链接，输入兑换码进行兑换：
留言