我正在将我编写的应用程序打包到AppImage中，以便它可以交付给Linux用户。
我正在使用的GUI工具包的一个关键特性是它小而轻，允许我编译一个静态链接到大约6Mb的GUI库的构建。
然而，在构建AppImage之后——我按照说明做——使用所有的功能(基本上只包括使用文件浏览器对话框来加载文件)——它生成了一个大约200Mb的绝对巨大的AppImage !
我知道AppImages应该是"一点点"很大，但是当本机编译的二进制文件(包括静态链接的GUI工具包)只有6Mb时，作为可移植性的建议解决方案，这完全是疯狂的。
但是，我完全不相信我需要所有的200Mb。一个非常类似于我的软件，但是另外使用Qt(相比之下相当臃肿)只有大约30Mb。实际上，我怀疑appimage-builder做了一些非常错误的事情——我认为它在使用文件浏览器对话框作为依赖项时列出了我所浏览的目录中的文件(它们是大文件)。我没有其他真正的解释。但如果是这样，我该如何阻止它呢?
为什么我的这么大?我该怎么办呢?
为了记录，我使用这个方法来构建我的AppImage
- 单独构建我的二进制文件
- 运行
appimage-builder --generate并填写表格 - 运行
appimage-builder --recipe AppImageBuilder.yml --skip-tests
编辑:删除打包的明显不需要的文件将appimage的大小减少到140Mb，但这仍然是我见过的等效appimage的近5倍。是否存在一些我不知道的技巧/选择?
最近几天我开始使用AppImage，遇到了同样的问题。
简要:通过任何可能的方式检查你的应用程序的依赖关系，并配置recipe只包含具体的依赖关系，避免包含任何不真正使用的主题/图标等包:)
我的案例是一个小应用程序，用Dart编写(与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文件，至少需要appimage-builder(docker容器)的官方测试，那么检查每个包/库需要很长时间。我面对的破碎结果比任何相同大小的缩减都要多。
我的下一个实验是减少应该从包管理器安装的依赖，并使用来自主机系统的文件。我删除了AppDir和appimage-builder-cache文件夹，并重新生成了配方。在下一步中，我注释了所有应该从包管理器安装的包，只留下包含的文件。结果是失败的，因为需要一个包，但在添加它之后，我得到了36MB的AppImage结果。这听起来比启动105MB甚至之前的50MB要好得多。
这里我得到了小的"boost"- Flutter项目内置到AOT二进制文件中，没有运行时。所以我检查了我的应用程序的ldd的输出，然后将所需的库列表映射到appimage-builder检测到的库文件列表。最后，有些是正确的，有些在ldd输出中没有发现，有些在ldd输出中没有发现，但appimage-builder没有检测到。我添加了所有未检测到的，删除了所有未使用的。我的最终结果是26MB，它通过了所有appimage-builder测试(在fedora, cent, debian, ubuntu和arch的docker镜像中运行)
我明白这对于持续构建来说已经足够糟糕了，因为它需要总是检查使用的库并在某些事情发生变化时调整配置，但对于足够罕见的构建，我想它在好与坏之间有某种平衡。