的比例。
【附图说明】
[0047]为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
[0048]图1为本申请实施例公开的一种软件包处理方法的流程图；
[0049]图2为本申请实施例公开的又一软件包处理方法的流程图；
[0050]图3为本申请实施例公开的联合挂载的示意图；
[0051 ]图4为本申请实施例公开的又一软件包处理方法的流程图；
[0052]图5为本申请实施例公开的又一软件包处理方法的流程图；
[0053]图6为本申请实施例公开的一种软件包处理装置的流程图；
[0054]图7为本申请实施例公开的一种软件包处理系统的流程图。
【具体实施方式】
[0055]下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
[0056]在Linux系统的发行版中，几乎每一个发行版都有自己的软件包管理系统。常见有:管理RPM软件包的RPM。这些管理工具，虽然可以良好地管理和维护软件包，但需要依赖较多的依赖软件，占用了较多的磁盘空间。如果完全放弃将软件包作为管理对象的话，将会面对一大堆散列的文件，系统维护的难度将大幅增加。
[0057]因此，需要一种能够在不扩大系统容量，还能够实现软件包管理的方法。本申请公开的软件包处理方法则是一种不依赖于软件包管理系统但能够实现对软件包的处理的方法。
[0058]详细介绍如下:
[0059]本申请实施例公开的一种软件包处理方法的流程如图1所示，在本实施例中，是从执行对软件包进行处理的脚本的角度进行的描述，该脚本为开发人员为了实现本发明而预先编制的一段程序，只要运行该脚本，就能执行下述流程，以实现本发明。每个步骤的执行者都默认为该脚本。
[0060]步骤SlOl:获取系统中按照预设方式将应用程序软件包进行压缩后得到的应用程序压缩包，所述预设方式为带有文件系统的压缩方式；
[0061]在本实施例中，假设一个系统在此之前在利用其他的软件包管理软件，或者，还未安装过软件包管理软件，则可以将其所有的应用程序压缩包进行压缩，压缩方式为带有文件系统的压缩方式，具体可以为squashfs文件系统压缩或Cramfs文件系统压缩。
[0062]应用程序的内容如下:
[0063]一、AppManifest.xml 描述文件:
[0064]1、版本信息和编译日期。
[0065]2、当前的架构。
[0066]3、应用程序的描述descript1n。
[0067]4、依赖的模块。
[0068]5、作者和作者邮箱地址。
[0069]二、start.sh 脚本:
[0070]用于导出本程序使用的环境变量，如bin的路径，Iib的路径和资源路径等，然后再启动自己。
[0071]三、Install.sh脚本
[0072]在/usr/bin目录上创建链接文件(以唯一的应用名命名)，来指向软件包中的start.sh的脚本，便于其他模块调用。
[0073]步骤S102:分别为每一个应用程序压缩包分配一个可读写空间，所述可读写空间为读取所述应用程序压缩包时占用的空间；
[0074]由于每个压缩包在压缩状态或非压缩状态被运行时，都需要占用一定的内存空间，为了保证每个压缩包在运行时互相不影响，保证系统的正常工作，为每个压缩包都分配一个唯一对应的内存空间。
[0075]步骤S103:将所述应用程序压缩包及其对应的可读写空间的目录挂载到预先设定的应用目录。
[0076]将应用程序压缩包和可读写空间的目录一起挂在到预先设定的应用目录下，以方便系统查找该应用程序。
[0077]步骤S104:触发所述应用程序压缩包中的安装脚本，安装所述应用程序压缩包对应的应用程序。
[0078]本实施例公开的软件包处理方法，发生在系统每一次启动时，因为联合挂载这一手段为实时性的，所以每次系统启动时，将系统中的所有应用程序压缩包与对应的可读取空间目录进行联合挂载，然后再触发安装程序进行安装。
[0079]本申请实施例公开的软件包处理方法中，通过将应用程序的软件包按照带有文件系统的压缩方式进行压缩，缩小了系统的容量，并且，为每一个应用程序压缩包分配一个可读写空间，保证了应用程序能够正常运行，然后将压缩以后的应用程序压缩包及其对应的可读写空间的目录挂载到预设的应用目录下，以实现对软件包的管理。系统可以通过该应用目录快速查找应用程序的软件包，并对其进行处理。在该方法中，没有引进任何除系统应用程序以外的其他程序来实现对软件包的管理，因此，没有额外增加系统的容量，从而使得该方法可以适用于任何系统，具有较强的通用性。
[0080]进一步的，由于对所有的软件包都按照带有文件系统的压缩方式进行压缩，使得系统容量进一步缩小，大大减少了系统占用内存的比例。
[0081]在上述实施例中，按照预设方式进行应用程序压缩包可以存储在预先建立的软件包存储文件夹中。假设应用程序压缩包利用Squashfs进行压缩，则该文件夹可以命名为app-squ，其内部存储的多个应用程序压缩包为:appl.squa和app2.squa等。
[0082]进一步的，在上述实施例中，分别为每一个应用程序压缩包分配一个可读写空间后，还包括:
[0083]将所述可读写空间的目录存储在用于存储目录的文件夹。比如一个磁盘分区，分区名是/dev/sda4。需要把/dev/sda4分区挂载到/data目录下，在/data/目录下根据应用程序的压缩包来创建存储文件夹，比如应用程序压缩包为appl.squa,那么就创建/data/app-user/appl.user。
[0084]上述文件夹划分方式以及存储方式仅仅是本申请实施例举出的一个示例，并不起到限定作用。
[0085]并且，本申请实施例也并不限定一定按照上述方式将应用程序压缩包和可读写空间目录进行存储。两者可以存储在同一个文件夹中，也可以分散存储在多个文件夹中。只要系统中记录有应用程序压缩包与可读写空间目录的关联，能够找到应用程序对应的可读写空间即可。
[0086]进一步的，在上述实施例中，将所述应用程序压缩包及其对应的可读写空间的目录挂载到预先设定的应用目录的过程如图2所示，包括:
[0087]步骤S201:从所述软件包存储文件夹中获取所述应用程序压缩包，并从所述目录存储文件夹中获取所述应用程序压缩包对应的可读写空间目录；
[0088]步骤S202:利用Aufs联合文件系统，将所述应用程序压缩包及其对应的可读写空间的目录联合挂载到所述预先设定的应用目录。
[0089]上述过程的具体实现通过