在之前的文章中，我们探讨了Ubuntu Snap的应用方案，不少读者反馈其使用体验存在局限，并推荐了Flatpak作为替代选择。今天，我们将系统性地对比Flatpak和Ubuntu Snap的核心差异，分析它们在树莓派上的实际表现与适用场景。
Flatpak的发展历程与关键里程碑
Flatpak由Fedora社区主导开发，强调跨发行版兼容性与沙盒隔离机制，允许开发者构建独立于系统库的应用程序（如LibreOffice和GIMP）。其依赖管理采用分层共享模式（例如Freedesktop Runtime），有效减少存储冗余。该项目的发展历程丰富且获得广泛支持：
2007年8月：Alexander Larsson推出首个应用程序捆绑框架Glick。
2011年11月：发布现代化升级版Glick 2。
2012年7月：GUADEC大会讨论"GNOME OS"及新捆绑格式的初步规划。
2012年9月：推出实验性框架"bundler"。
2013年1月：布鲁塞尔举行的GNOME开发者体验黑客节讨论"Linux Apps"提案。
2014年12月：启动xdg-app项目，后续演变为Flatpak。
2015年3月：发布xdg-app 0.1版本（Flatpak的雏形）。
2015年12月：GNOME的"Software"支持安装xdg-app应用。
2016年5月：xdg-app更名为Flatpak并发布0.6.0版，获红帽、Endless Computers等支持。
2016年6月：启动桌面门户安全框架开发。
2016年6月：LibreOffice成为首个采用Flatpak的大型Linux应用。
2016年7月：GTK+ 3.21.4增加门户框架支持。
2016年8月：Endless OS 3.0成为首个默认集成Flatpak的操作系统。
2016年11月：ClearLinux宣布采用Flatpak。
2016年12月：Flatpak 0.8.0开启首个稳定支持系列。
2017年5月：Flathub服务低调上线，KDE Plasma 5.10支持门户。
2017年10月：发布Flatpak 0.10.0（第二个稳定系列），KDE Plasma 5.11支持Flatpak安装，GIMP采用Flatpak。
2017年11月：Linux Mint 18.3开箱集成Flatpak。
2018年8月：发布Flatpak 1.0，Flathub结束测试，Freedesktop运行时更新支持策略。
2018年9月：KDE推出测试应用Flatpak仓库。
2019年12月：elementary OS 5.1集成Flatpak。
2020年4月：Mozilla用Flatpak发布Linux版Firefox，System76的Pop!_OS 20.04集成Flatpak。
2021年10月：1Password采用Flatpak。
2022年2月：Valve的Steam Deck集成Flatpak，OBS Studio采用Flatpak。
2022年5月：红帽企业Linux工作站9集成Flatpak。
2022年10月：Flathub引入验证状态。
2023年4月：Purism推出Flatpak仓库，Valve为Steam应用采用门户。
2023年5月：Flathub应用超2000个，总下载量破10亿次。
2023年10月：Discord采用Flatpak发布Linux版。
值得关注的是，2024年Flatpak实现了20亿次下载的里程碑，彰显其日益增长的用户基础。
Ubuntu Snap：Canonical的打包方案解析
Snap是Canonical专为Ubuntu设计的强制沙盒化打包方案，默认绑定Ubuntu软件商店，依赖单一运行时环境，支持服务端应用（如Kubernetes和MySQL）。得益于Ubuntu的强力推广，Snap已积累相当规模的用户群体。我们在过往文章中已详细解析其机制，读者可参考以下内容进一步了解：
Snap Store开发者工具图谱：从全栈到云原生，一张图解锁Linux开发新姿势！ 树莓派生产力革命！Snap版PyCharm一键安装，告别安装过程中的依赖麻烦
Flatpak与Snap的实战性能对比
树莓派官方论坛的用户讨论揭示了两种技术的实际应用场景。一位用户因单一商店无法满足需求，采用混合安装策略：
Debian稳定版仓库软件版本老旧（如LibreOffice 6.1.5）。
通过Backports升级失败（依赖冲突）。
最终解决方案：
Flatpak安装LibreOffice 7.1.0.3（Flathub源）。
Snap安装Chromium 89、Telegram 2.5.8和Snap商店。
这表明两者目前势均力敌，尚未形成如移动端应用商店的垄断格局。
用户反馈也凸显了各自槽点：
Snap的隐形依赖问题：安装3个应用后，neofetch显示10个snap包，因强制捆绑基础运行时（core/core18/core20等），被吐槽为“自带半个操作系统”。
Flatpak的桌面集成缺陷：Snap应用自动生成菜单图标，而Flatpak版LibreOffice需手动添加启动项，引发用户困惑。
版本更新策略差异：Snap默认自动更新（用户未提及关闭方法），Flatpak需手动执行
flatpak update；用户倾向Flatpak的可控性，但担忧Snap频繁写入影响SD卡寿命。
论坛用户craigevil的结论颇具代表性：“两者均为Debian仓库的补充，但都无法完全替代传统包管理。我同时使用它们，只因各自生态不完整——如同用瑞士军刀和电钻修家具，虽别扭但有效。”
AppImage：无安装打包的挑战者崛起
正当Flatpak与Snap争论主导权时，AppImage以“流浪剑客”姿态登场，宣称：“真正的自由无需安装！”其哲学体现为三无主义：
无安装：双击即运行，U盘便携使用，无需系统目录介入。
无依赖：应用自带完整库（包括libc），彻底规避依赖冲突。
无后台：拒绝snapd或flatpak-system-helper等守护进程，运行后零残留。
此前介绍的Cherry Studio大模型工具即采用AppImage打包，凸显其易用优势。项目地址： https://github.com/CherryHQ/cherry-studio
结语：开源打包技术的未来走向思考
开源打包领域面临核心争议：Snap强制运行时是否违背轻量化初衷？Flatpak的菜单缺陷源于技术限制还是设计取舍？树莓派用户如何平衡软件更新与存储寿命？抑或您更青睐AppImage的极简主义？欢迎在评论区分享您的选择逻辑与实践心得。
参考文章： https://flatpak.org/ https://docs.flathub.org/blog/2-billion-downloads-2024/ https://forums.raspberrypi.com/viewtopic.php?t=304234