应用程序生成器创建的巨大应用程序映像

Question

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

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

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

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

然而，我根本不相信我需要所有的200‘m。一个与我非常相似的软件，但它使用的Qt (相比起来相当臃肿)只有大约30 in。实际上，我怀疑appimage做了一些非常错误的事情--我认为当使用文件浏览器对话框作为依赖项(它们是大文件)时，它列出了我探索的目录中的文件。我没有其他真正的解释。但如果是这样的话，我该如何阻止这种行为呢？

为什么我的这么大？我能做些什么？

为了记录在案，我正在使用此方法构建我的AppImage

构建二进制separately

• Running appimage-builder --generate并完成运行appimage-builder --recipe AppImageBuilder.yml --skip-tests

的表单

编辑:删除正在打包的明显不需要的文件，将appimage的大小缩小到只有140 to，但这仍然比我看到的等效appimage大5倍。有没有一些我不知道的窍门/选项？

Answer 1

最近几天开始使用AppImage，并面临着同样的问题。

简短:通过任何可能的方式检查应用程序的依赖关系，并将菜谱配置为只包含具体的依赖项，避免包含没有实际使用的任何主题/图标/etc包:)

我的案例是一个小应用程序，用Dart编写(带有颤音)。构建的项目本身的重量约为22 in (输出目录中的du -sh .)。我的主机os是Linux (肉桂)。

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

我的第一个实验是清理包含文件的部分，因为我想“所有必要的”库都应该从apt安装。我提到了一些来自网络的信息，其中标记的包含和exclude部分的库很少，其中包含一些与DE相关的文件(主题、字体、图标等)。

使用它，我得到了大约50 are的结果(仍然足够大)。

接下来的实验提到了这个问题-- https://github.com/AppImageCrafters/appimage-builder/issues/130#issuecomment-843288012 --在生成AppImage文件后不久，AppDir文件夹中出现了包含已部署库的文件.bundle.yml文件。建议是尝试将某物排除在外。这可能是一个很好的建议，但是如果每个包/库破坏了最终的AppImage文件，那么检查每个包/库所需的时间就太长了，至少对appimage-builder (码头容器)的官方测试是这样的。我面临着比任何理智的尺寸缩减更多的坏结果。

我的下一个实验是减少依赖关系，这些依赖应该从包管理器中安装，并使用来自主机系统的文件。我删除了AppDir和appimage-builder-cache文件夹并重新生成了菜谱。在接下来的步骤中，我注释了应该从包管理器安装的所有包，并且只留下包含的文件。结果失败，因为需要一个包，但是在添加它之后，我得到了36 it的AppImage结果。这听起来比启动105 of甚至之前50 of的结果要好得多。

在这里，我得到了一个小的"boost“项目--内置在AOT二进制文件中的、没有运行时的颤振项目。因此，我检查了我的应用程序的ldd输出，然后将所需库的列表映射到应用程序构建器检测到的库文件列表。最后，其中一些是正确的，一些在ldd输出中没有发现，还有一些在ldd输出中，但是没有被appimage检测到。我添加了所有未被发现的，删除了所有未使用的。我的最终结果是26 My，它通过了所有应用程序构建器测试(运行在fedora、分、debian、ubuntu和arch的docker映像中)。

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