由 appimage-builder 创建的巨大 appimage

Question

我正在将我编写的应用程序打包到 AppImage 中，以便将其交付给 Linux 用户。

我使用的 GUI 工具包的一个关键特性是它小巧轻便，允许我编译一个静态链接到大约 6Mb 的 GUI 库的构建。

但是，在构建 AppImage 之后 - 我按照说明进行操作 - 使用所有功能（基本上只包括使用文件浏览器对话来加载文件） - 它会生成一个绝对巨大的 AppImage，大约 200Mb！

我知道 AppImages 应该是“一点点”大，但是当包含静态链接 GUI 工具包的本机编译二进制文件只有 6Mb 时，作为可移植性的提议解决方案，这完全是疯狂的。

但是，我完全不相信我需要全部 200Mb。一个非常与我相似的软件，但是另外使用Qt（相比之下相当臃肿）只有大约30Mb。我实际上怀疑 appimage-builder 做错了什么 - 我认为它列出了我在使用文件浏览器对话框作为依赖项时探索的目录中的文件（它们是大文件）。我没有其他真正的解释。但如果是这样，我该如何阻止它这样做呢？

为什么我的那么大？我该怎么办？

为了记录，我正在使用这种方法来构建我的 AppImage

1. 单独构建我的二进制文件
2. 运行 appimage-builder --generate 并填写表单
3. 正在运行appimage-builder --recipe AppImageBuilder.yml --skip-tests

编辑：删除明显不需要的正在打包的文件已将 appimage 的大小减小到仅 140Mb，但这仍然比我见过的同等 appimage 大近 5 倍。是否有一些我不知道的技巧/选项？

Answer 1

最近几天开始使用 AppImage 并遇到了同样的问题。

很快：通过任何可能的方式检查您的应用程序的依赖关系，并将配方配置为仅包含具体的依赖关系，并避免包含任何未真正使用的主题/图标/等包:)

我的案例是一个小应用程序，用 Dart (with Flutter) 编写。构建的项目本身重约 22MB（输出目录中的du -sh .）。我的主机操作系统是 Linux Mint (Cinnamon)。

我第一次运行appimage-builder --generate 时，它为我生成了一个“配方”，其中包含要安装的 17 个包和要从 /lib/x86_64-linux-gnu/ 复制的一堆库。当我从这个配方生成 AppImage 时，结果大约是 105MB，这在我看来对于小型应用程序来说非常大。

我的第一个实验是清理包含的文件部分，因为我猜应该从 apt 安装“所有必要的”库。我参考了网络上的一些配置，其中仅标记了几个包含的库，并且是 exclude 部分，其中包含一些与 DE 相关的文件（主题、字体、图标等）

使用我得到大约 50MB 的结果（仍然足够大）。

接下来的实验是从这个问题中提到的 - https://github.com/AppImageCrafters/appimage-builder/issues/130#issuecomment-843288012 不久 - 生成 AppImage 文件后，AppDir 文件夹内出现了文件 .bundle.yml 文件，其中包含已部署的库。建议是尝试从中排除一些东西。可能这是一个足够好的建议，但是如果至少通过appimage-builder（docker 容器）的官方测试破坏了导致 AppImage 文件的结果，则检查每个包/库需要很长时间。与任何合理的尺寸缩减相比，我面临的破坏结果更多。

我的下一个实验是减少应该从包管理器安装的依赖项并使用主机系统中的文件。我删除了AppDir 和appimage-builder-cache 文件夹并重新生成了配方。在下一步中，我评论了所有应该从包管理器安装的包，并且只留下了包含的文件。结果失败，因为需要一个包，但添加后我得到了 AppImage 结果为 36MB。这听起来比开始 105MB 甚至之前的 50MB 的结果要好得多。

在这里，我得到了小小的“提升”——Flutter 项目内置在 AOT 二进制文件中，没有运行时。所以我为我的应用检查了ldd 的输出，然后将所需库的列表映射到appimage-builder 检测到的库文件列表。最后，其中一些是正确的，一些在ldd 输出中找不到，一些在ldd 输出中，但没有被appimage-builder 检测到。我添加了所有未检测到的，删除了所有未使用的。我的最终结果是 26MB，它通过了所有 appimage-builder 测试（在 fedora、cent、debian、ubuntu 和 arch 的 docker 镜像中运行）

我知道连续构建已经够糟糕了，因为它需要始终检查使用过的库并在发生变化时调整配置，但对于很少见的构建，我想它在好与坏之间有某种平衡。