1 什么是AppImage?

AppImage是近些年流行的一种安装包。

AppImage继承自Klik，它是这样一个软件：它让你在 linux平台上可以以普通用户的权限安装软件， 然后， 每个软件都安装在自己的一个目录下， 当你想卸载这个软件的时候，直接把这个目录删掉就可以了。

2 Linux中常见的安装包类型及缺点

我们来看看Linux中常见的安装包类型：

（1）tar包：这是一种用打包工具tar做成的压缩包，一般是源码安装包。

比如一个知名的录像开源软件OBS的源码“obs-studio-26.0.2.tar.gz”。如果这个工具是跨平台的，如果说还支持win平台，就会同时提供win平台的源码压缩包，比如“obs-studio-26.0.2.zip”。

（2）rpm：是Redhat Linux提供的一种包封装格式。包的管理工具是yum。

比如我下载的一个java开发包“jdk-8u65-linux-i586.rpm”，就是这种类型的。

（3）dpkg包：Debain Linux提供的一种包封装格式。包的管理工具，下载到本地的是用dbkg命令安装，在线用apt-get命令安装。

如我下载的虚拟机“virtualbox-6.0_6.0.6-amd64.deb”，在本地就可以执行"dpkg -i"来安装，也可以“apt get install”网上在线安装。

（4）bin包，如

jdk-1_5_0_05-linux-i586.bin，有些Linux软件不公开源代码，只发布二进制可执行程序，这类程序一般会以bin来标记。

多年以来，我们一直使用deb包来管理 Debian/Ubuntu的软件包，使用 RPM 管理 Fedora/SUSE 的软件包。有人说用户使用这些包管理工具，可以很方便的安装软件。要我说，其实一点也不方便。上面的这些方式，要么复杂难以处理（比如源码方式），要么有这个根深蒂固的问题：传统的软件安装方式都是将软件视为系统的一部分, 有些安装的时候会把软件的相关文件分别安装到 /usr/bin、/usr/share 等目录下，有些安装方式，内部多多少少都会有一些复杂的库依赖和文件拷贝动作，这让删除动作极不容易，系统很容易因为包的变动积累垃圾。

正因为如此，开发人员不得不开发更多的工具， 这时AppImage来到了我们面前。

3 AppImage简介

AppImage 使用通用的软件格式，通过将整个软件打包成AppImage,一个包包含了所有的功能. 并且几乎可以在所有的linux发行版本中使用。

通常我们安装linux软件将会在不同的目录生成多个文件，并且需要root权限来对系统进行修改。AppImage 不需要像传统的那样安装。事实上，AppImage 并不需要安装。AppImage 是一个压缩的镜像文件，它包含所有运行所需要的依赖和库文件。正如上面";对AppImage宣传的那样：AppImage 文件不需要安装，你就可以直接执行。当你把AppImage 文件删除了，整个软件也被删除了。你可以把它当成windows系统中的那些免安装的绿色版exe文件。

AppImage的一些特性或者优点：

可以运行在各种平台不需要安装，直接执行不需要root权限，不需要修改系统文件便携性：可以在位置执行App 只读卸载便利，只需要删除AppImage文件即可

4 在linux系统中如何使用AppImage

使用AppImage 文件非常简单，只需要三个步骤：

(1)下载AppImage 文件(2)赋予可执行权限：chmod a+x *.AppImage 当然图形界面也可以做到(3)双击或者在命令行中执行：./Subsurface*.AppImage

如何删除AppImage软件

因为软件并没有被安装，所以也不存在卸载一说。只需要删除AppImage 文件即可。

一个例子，网络上传的效果炸裂的终端工具：eDEX-UI，就有AppImage安装包供下载（

）。

下载后，执行下面两步：

chmod a+x eDEX-UI-Linux-x86_64.AppImage./eDEX-UI-Linux-x86_64.AppImage

5 AppImage真的这么好吗？

世间哪有两全法，不负如来不负卿！告诉你吧，压根就没有完美的事。

AppImage出现的根本原因，就是为了解决“Linux各发行版的二进制文件不能互相兼容运行”的问题。这是一个上古问题，如果能解决就真的是功德无量，因此从目前的“解决的程度”角度来评价，是比较有意义的。

AppImage只能说解决了一部分，但这不是AppImage的锅。

Linux各发行版之间二进制文件不能兼容问题，原因是：各个平台上的库，尤其是各发行版使用的glibc版本并不一致。而且同一个发行版升级版本后这些库（比如glibc等）也会变动，导致API并不能完全兼容，再加上其他底层依赖的版本千差万别，各种因素交织在一起，导致了根本没有办法使同一个二进制文件完美运行在所有发行版上。

直接带上二进制及其几乎所有的所需依赖，那么就能有效缓解这个问题。AppImage的这种解决办法来得比较简单粗暴。再看看docker，是不是有相似之处？

知乎上有高手讲：但是目前来看解决效果并不如docker好。问题很简单，因为不管appimage有多么强大，但是你总得现有一个预编译的二进制版本，这个版本不是天上掉下来的，是编译出来的，既然有编译，就肯定有编译环境，就得引用固定版本的API，例如是在ubuntu14.04下编译的C程序，那么一定依赖了ubuntu14.04依赖的一些API，可能来自glibc，可能还包含其他API。如果你在ubuntu14.04跑打包好的appimage，应该是没有问题的。但是如果在fedora26上，可能遇到一些问题，具体原因还不太清楚，可能跟内核还有关系，因为最常见的问题便是内核转储。你不可能在appimage里再打包一个内核。linux生态的碎片化，导致appimage注定只能解决一部分问题，如果让我说，也许appimage要解决的问题，最好的办法就是大家都用同一个发行版。

但不管怎么样，AppImage做了它能做的。对不对？！