本申请公开了内存压缩的方法及装置、操作系统、电子设备，内存压缩的方法中，操作系统向虚拟机发送内存压缩的触发指令；所述虚拟机响应所述内存压缩的触发指令，对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括服务Service属性的进程和/或永久Persistent属性的进程。本申请所提供的方案能够改善设备的系统性能。
1.一种内存压缩的方法，其特征在于，该方法包括步骤：操作系统向虚拟机发送内存压缩的触发指令；
所述虚拟机响应所述内存压缩的触发指令，对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括服务Service属性的进程和/或永久Persistent属性的进程；
设备启动，所述操作系统向虚拟机发送内存压缩的触发指令；
所述方法还包括虚拟机对发送所述内存压缩的触发指令的进程进行权限验证；
所述虚拟机对发送所述内存压缩的触发指令的进程进行权限验证的步骤，包括：如果发送所述内存压缩的触发指令的进程为设定的系统进程，则权限验证通过。
2.根据权利要求1所述的方法，其特征在于，所述内存压缩的触发指令在满足主动触发事件时被发送；所述主动触发事件包括以下至少一种：设备启动、用户触发指定的控件、后台进程清理功能被触发。
3.根据权利要求1所述的方法，其特征在于，所述内存压缩的触发指令由所述操作系统内设定的系统进程发送；
所述虚拟机对发送所述内存压缩的触发指令的进程进行权限验证的步骤，还包括：否则，返回权限验证失败的结果；
对指定后台进程所占用的内存中的数据进行压缩的步骤在权限验证通过后执行。
4.根据权利要求1所述的方法，其特征在于，所述虚拟机对指定后台进程所占用的内存中的数据进行压缩之前还包括：记录本次收到的内存压缩的触发指令的时间，如果距离上次内存压缩的时间间隔符合预定条件，则执行对指定后台进程所占用的内存中的数据进行压缩的步骤，如果不符合预定条件，则忽略所述内存压缩的触发指令。
5.一种内存压缩的方法，其特征在于，该方法包括步骤：接收内存压缩的触发指令，对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括服务Service属性的进程和/或永久Persistent属性的进程；
所述方法还包括：对发送所述内存触发指令的进程进行权限验证；
所述对发送所述内存触发指令的进程进行权限验证的步骤，包括：如果发送所述内存触发指令的进程为设定的系统进程，则权限验证通过。
6.根据权利要求5所述的方法，其特征在于，所述内存压缩的触发指令在满足主动触发事件时被发送。
7.根据权利要求6所述的方法，其特征在于，所述主动触发事件包括以下至少一种：设备启动、用户触发指定的控件、后台进程清理功能被触发。
8.根据权利要求5所述的方法，其特征在于，所述对发送所述内存触发指令的进程进行权限验证的步骤，还包括：否则，返回权限验证失败的结果；
对指定后台进程所占用的内存中的数据进行压缩的步骤在权限验证通过后执行。
9.根据权利要求5所述的方法，其特征在于，对指定后台进程所占用的内存中的数据进行压缩之前还包括：记录本次收到的内存压缩的触发指令的时间，如果距离上次内存压缩的时间间隔符合预定条件，则执行对指定后台进程所占用的内存中的数据进行压缩的步骤，如果不符合预定条件，则忽略所述内存压缩的触发指令。
10.根据权利要求5所述的方法，其特征在于，所述方法由虚拟机执行；所述内存压缩的触发指令来自虚拟机外部。
11.根据权利要求10所述的方法，其特征在于，所述内存压缩的触发指令为操作系统调用所述虚拟机提供的接口的指令或操作系统向所述虚拟机发送的指定信号。
12.根据权利要求11所述的方法，其特征在于，所述虚拟机提供的接口为应用管理服务AMS模块的扩展接口。
13.根据权利要求10所述的方法，其特征在于，所述方法还包括：所述虚拟机对Activity属性的进程所占用的内存中的数据进行压缩。
内存压缩模块，对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括Service属性的进程和/或Persistent属性的进程；
所述装置还包括校验模块，用于对发送所述内存触发指令的进程进行权限验证；
所述校验模块，具体包括：如果发送所述内存触发指令的进程为设定的系统进程，则权限验证通过，并通知所述内存压缩模块。
15.根据权利要求14所述的装置，其特征在于，所述内存压缩的触发指令在满足主动触发事件时被发送；所述主动触发事件包括以下至少一种：设备启动、用户触发指定的控件、后台进程清理功能被触发。
16.根据权利要求14所述的装置，其特征在于，所述校验模块，还包括：否则，返回权限验证失败的结果。
17.根据权利要求14所述的装置，其特征在于，还包括判断模块，用于根据记录的本次收到的内存压缩的触发指令的时间，判断距离上次内存压缩的时间间隔是否符合预定条件，如果符合则通知所述内存压缩模块执行对指定后台进程所占用的内存中的数据进行压缩的步骤，如果不符合预定条件，则忽略所述内存压缩的触发指令。
18.根据权利要求14所述的装置，其特征在于，所述装置位于虚拟机，所述接口模块从所述虚拟机外部接收内存压缩的触发指令。
19.根据权利要求14所述的装置，其特征在于，所述接口模块为应用管理服务AMS模块的扩展接口。
20.根据权利要求14所述的装置，其特征在于，所述内存压缩模块还用于对Activity属性的进程所占用的内存中的数据进行压缩。
进程管理模块，用于管理多个进程，所述进程包括后台进程；
面向虚拟机的接口，用于向虚拟机发送内存压缩的触发指令，所述内存压缩的触发指令用于触发虚拟机对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括服务Service属性的进程和/或永久Persistent属性的进程；
通过进程，向虚拟机发送内存压缩的触发指令，以使所述虚拟机对发送所述内存触发指令的进程进行权限验证，如果进程为设定的系统进程，则权限验证通过。
22.根据权利要求21所述的操作系统，其特征在于，所述操作系统还包括设定的系统进程，用于调用所述面向虚拟机的接口向虚拟机发送内存压缩的触发指令。
23.根据权利要求21所述的操作系统，其特征在于，所述面向虚拟机的接口在响应主动触发事件时被调用。
24.根据权利要求23所述的操作系统，其特征在于，所述主动触发事件包括以下至少一种：设备启动、用户触发指定的控件、后台进程清理功能被触发。
25.根据权利要求21所述的操作系统，其特征在于，所述内存压缩的触发指令为调用所述虚拟机提供的接口的指令或向所述虚拟机发送的指定信号。
26.根据权利要求25所述的操作系统，其特征在于，所述虚拟机提供的接口为应用管理服务AMS模块的扩展接口。
接收内存压缩的触发指令，对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括Service属性的进程和/或Persistent属性的进程；
对发送所述内存触发指令的进程进行权限验证；如果发送所述内存压缩的触发指令的进程为设定的系统进程，则权限验证通过。
内存压缩的方法及装置、操作系统、电子设备
技术领域
[0001] 本申请涉及系统性能优化技术，尤其涉及内存压缩的方法及装置、操作系统电子设备。
背景技术
[0002] 进程是由操作系统所体现的程序运行的基本单元，通常一个程序至少有一个进程，进程在执行过程中拥有独立的内存空间。嵌入式计算机系统的硬件资源比较有限，特别是运行时内存一般不会太大，系统一般会对内存使用进行优化，即通过内存压缩尽量减少内存占用，加快内存释放。内存压缩通常是用算法将进程所占据的内存空间整体进行数据压缩，然后压到特定的内存区域。目前，为了对系统性能进行优化，通常针对有应用界面相关的进程(Activity属性的进程)进行内存压缩和碎片整理，但仍然无法有效清理内存。当启动新应用时，如果系统因为资源紧张无法为应用分配内存，则需要调用LMK(low Memory Killer，低内存释放)来释放资源，以便使应用正常启动，但这种做法会导致应用的启动时间变长，造成系统性能衰退。
发明内容
[0003] 本申请提供内存压缩的方法及装置、操作系统、电子设备，能够改善系统性能。
[0004] 根据本申请实施例的第一方面，提供一种内存压缩的方法，该方法包括步骤：
[0005] 操作系统向虚拟机发送内存压缩的触发指令；
[0006] 所述虚拟机响应所述内存压缩的触发指令，对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括服务Service属性的进程和/或永久Persistent属性的进程。
[0007] 根据本申请实施例的第二方面，提供一种内存压缩的方法，该方法包括步骤：
[0008] 接收内存压缩的触发指令，对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括服务Service属性的进程和/或永久Persistent属性的进程。
[0009] 根据本申请实施例的第三方面，提供一种内存压缩的装置，包括：
[0010] 接口模块，用于接收内存压缩的触发指令；
[0011] 内存压缩模块，对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括Service属性的进程和/或Persistent属性的进程。
[0012] 根据本申请实施例的第四方面，提供一种操作系统，包括：
[0013] 进程管理模块，用于管理多个进程，所述进程包括后台进程；
[0014] 面向虚拟机的接口，用于向虚拟机发送内存压缩的触发指令，所述内存压缩的触发指令用于触发虚拟机对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括服务Service属性的进程和/或永久Persistent属性的进程。
[0015] 根据本申请实施例的第五方面，提供一种电子设备，包括：
[0016] 处理器；
[0017] 用于存储处理器可执行指令的存储器；
[0018] 其中，所述处理器被配置为：
[0019] 接收内存压缩的触发指令，对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括Service属性的进程和/或Persistent属性的进程。
[0020] 本申请发现了导致内存不足的原因，对导致内存不足有重要影响的后台进程所产生的内存数据进行压缩，达到系统性能优化和减缓系统老化的优化目标，因此可以改善因内存不足导致的应用启动时间较长的问题。
附图说明
[0021] 图1为本申请实施例中一种设备内部逻辑架构图；
[0022] 图2a为本申请实施例中一种内存压缩的方法的部分流程图；
[0023] 图2b为本申请实施例中一种内存压缩的方法的部分流程图；
[0024] 图3a为一应用实例的内存压缩的方法的部分流程图；
[0025] 图3b为一应用实例中内存压缩的方法的另一流程图；
[0026] 图4为本申请实施例中内存压缩的装置的硬件架构图；
[0027] 图5为本申请实施例中内存压缩的装置的软件逻辑框图；
[0028] 图6为本申请实施例中一种操作系统的软件逻辑框图。
具体实施方式
[0029] 这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
[0030] 在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
[0031] 应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
[0032] 本申请提出了对设备的系统性能进行改善的方案。在一些实施例中，设备可以是台式计算机，在一些实施例中，设备可以是便携式的(例如笔记本计算机、平板计算机或手持设备)。在一些实施例中，设备可以是可穿戴的(例如智能手表、智能眼镜等)，在一些实施例中，设备可以是安装于其他设备上的(例如车载终端、导航仪等)。
[0033] 某些例子中，设备内部的逻辑架构可以参考图1，设备具有操作系统100，操作系统(Operating System，OS)的类型在本申请中不作限定，例如可以是Windows OS、iOS、MacOS、Android OS、Linux OS、YunOS(云OS)等。一些操作系统可能依赖于虚拟机，例如，Android OS、YunOS中，因此操作系统100的上层可以是虚拟机110，虚拟机(Virtual Machine)一般是指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。容易理解，某些例子中，设备内部的逻辑框架也可能不包括虚拟机110。系统框架(Framework)120是一个语言开发软件，提供了软件开发的框架，使开发更具工程性、简便性和稳定性。设备可以装载有多种应用，各种应用安装于应用层130。当应用或操作系统内部提供的服务被运行时，操作系统100启动相应的进程，并为该进程分配独立的内存空间。
[0034] 传统技术通常利用常规的GC(Garbage Collection，无用存储单元收集)策略对内存进行压缩，而常规的GC策略会导致heap(堆区)区域的碎片率越来越高，因此通常会在进程处于非敏感期时(比如应用从使用的前台切换到不使用时的后台时)对heap区的进程所产生的数据做一次压缩处理。由于与界面相关的进程(本申请称为Activity属性的进程)较容易判断从敏感期进入非敏感期的状态，因此常规的GC策略通常针对有Activity属性的进程所占用的内存中的数据进行压缩和碎片整理，在某些OS中，可以由虚拟机自动控制进行压缩的时间点。但申请人发现，针对Activity进程所占用的内存中的数据进行压缩并不能解决内存资源不足的问题，其原因是在设备运行时存在大量的后台进程，例如，Services属性的进程和Persistent属性的进程占用内存的比例很高，由于Services属性的进程或Persistent属性进程通常是后台的常驻进程，没有机会切换到非敏感期，所以无法通过GC策略对这些进程做heap区域的整理优化，造成系统运行时间加长而消耗更多的内存。因此，申请人提出对后台进程所占用的内存中的数据进行压缩的方案。某些例子中的部分流程可参见图2a。
[0035] S201a，操作系统向虚拟机发送内存压缩的触发指令；
[0036] S202a，虚拟机响应内存压缩的触发指令，对指定后台进程所占用的内存中的数据进行压缩。指定后台进程包括Service属性的进程和/或属性的Persistent进程，值得指出，并不排除在设计需要时对其他属性的后台进程进行压缩的可能。
[0037] 申请人发现当强制触发对某个后台进程内存压缩时可以整理出不少碎片，为了既对后台进程所占用的内存中的数据进行压缩，又不影响用户的正常使用，在图2a所示的例子中，通过选择合适的时机，通过内存压缩的触发指令主动触发后台进程的压缩过程，对后台进程进行压缩。
[0038] 图2a描述的例子，可以由虚拟机来执行内存压缩的操作，当然，在另一些例子中，根据操作系统的差异，可以通过操作系统或其他执行主体来执行内存压缩的操作。某些例子中，执行内存压缩的实体可以执行如图2b所示的部分步骤：
[0039] S201b，接收内存压缩的触发指令；
[0040] S202b，对指定后台进程所占用的内存中的数据进行压缩；指定后台进程可以包括Service属性的进程和/或属性的Persistent进程，但并不排除在设计需要时对其他属性的后台进程进行压缩的可能。
[0041] 以执行主体为虚拟机为例，触发指令可以来自虚拟机外部；也可以是预设一定的触发条件，在满足条件时虚拟机内部自动发出。在某些例子中，从虚拟机外部发送触发指令的时机可以是操作系统调用虚拟机所提供的接口时，或者通过操作系统向虚拟机发送指定的信号时主动触发内存压缩的触发指令。作为例子，虚拟机所提供的接口可以是虚拟机层所扩展的新增接口，例如，可以是AMS(Activity Manager Service，应用管理服务)模块的扩展接口，AMS模块可以对应用程序进行管理，如下载、移动、删除、升级和购买权限等。
[0042] 内存压缩的时机对于用户能否正常使用设备的功能有较大的影响，申请人经过大量的试验研究，研究出常驻后台进程的敏感期，确定了几种主动触发后台进程压缩的时刻，例如，主动触发事件可以是以下一种或几种方式：
[0043] 1、将设备启动时作为主动触发后台进程压缩的事件；
[0044] 2、可以新增一指定的控件，例如，一键加速的按钮等，当用户触发指定的控件时主动触发后台进程压缩的事件；
[0045] 3、可以通过某些已存在的控件触发已有功能时一并触发后台进程压缩的事件，例如，此时刻可以是在后台进程清理功能被触发时。
[0046] 容易理解，所列举的几种时刻仅仅作为示例进行说明，并不排除其他情况。
[0047] 作为例子，压缩的过程可以参照对Activity属性的进程进行GC压缩的方式，例如采用的压缩算法可以是mark-copy，也可以是mark-compact等等。在后台进程内存压缩流程被触发后，可以遍历所有的Services属性和Persistent属性的进程，向虚拟机发送内存压缩的触发指令。为了减少内存占用，该请求可以是异步请求。虚拟机接收到内存压缩的触发指令后，会尝试对需要压缩的后台进程所占用的内存中的数据进行压缩。
[0048] 在某些例子中，虚拟机在收到内存压缩的触发指令后，可以记录该次内存压缩的触发指令的时间戳，并在每次内存压缩后记录本次内存压缩的时间。如果本次收到内存压缩的触发指令的时间距离上次内存压缩的时间间隔符合预定条件，则执行对指定后台进程所占用的内存中的数据进行压缩的步骤，如果不符合预定条件，则忽略所述内存压缩的触发指令，预定条件可以根据设计者的设计需求确定，例如，可以设置5分钟作为时间间隔等。这是申请人充分考虑到如果两次内存压缩时间间隔过短时，新生成的heap碎片较少，再次做heap压缩会更加消耗系统资源，因此虚拟机的这个时间隔断保证了即使在虚拟机频繁收到内存压缩的触发指令时，也会保证内存压缩的高收益。
[0049] 为了保障安全性，在某些例子中，还可以具有对发送所述内存触发指令的进程进行权限验证的步骤，可以将一系统进程设定成默认的安全进程，如果发送内存触发指令的进程是此系统进程，则权限验证通过；否则，返回权限验证失败的结果。
[0050] 某些例子中，在后台进程压缩的时刻也可以对Activity属性的进程一并压缩，压缩方式可以参考传统方案中虚拟机通过接收所述AMS模块的接口发出内存压缩请求对Activity属性的进程所占用的内存中的数据进行压缩的过程。
[0051] 在某些例子中，除了在压缩后台进程时可以对Activity属性的进程所占用的内存中的数据进行压缩，还可以参照传统方案中虚拟机根据预设规则，在AMS模块的接口被调用时，虚拟机自动对Activity属性的进程进行压缩。
[0052] 图3a是一个应用场景下实例，移动终端上具有多个应用，虚拟机320的AMS模块提供第一接口，供虚拟机自动压缩Activity进程；提供扩展的第二接口，供虚拟机接收外部主动触发的压缩指令进行后台进程(例如Services属性的进程和Persistent属性的进程)的压缩。本例中以设备开机和用户触发“一键加速”按钮为主动触发后台进程压缩的触发事件。图3b示出了设备开机时对后台进程所占用的内存数据进行压缩的部分流程。
[0053] 阶段1，触发内存压缩流程：移动终端启动时，启动特定的系统进程来调用AMS模块的第二接口，通过第二接口向虚拟机发送内存压缩的触发指令；
[0054] 阶段2为身份校验过程：第二接口校验调用方是否是设定的系统进程，如果是，则在AMS模块中遍历所有的Services属性和Persistent属性的后台进程，通知每个目前处于活动状态的后台进程，由该进程自己先处理资源释放，再通过该后台进程向虚拟机接口发送内存压缩的异步请求，通知虚拟机进行内存压缩，如果校验结果不是设定的系统进程，则将收到内存压缩的触发指令丢弃；
[0055] 阶段3为内存压缩处理过程：虚拟机接收到请求后，会尝试对该进程进行内存压缩，并记录该次压缩请求的时间戳。
[0056] 阶段4对再次触发内存压缩过程的处理流程：当用户在使用移动设备的过程中，通过“一键加速”按钮再次触发内存压缩的触发指令，则再次启动特定的系统进程来调用第二接口执行上述步骤。如果虚拟机此次收到请求距离上次压缩发生的时间小于指定的时间，则忽略此次压缩(图中未示出)，如果不小于指定的时间，则再次进行压缩。
[0057] 需要指出，调用第二接口进行内存压缩时，也可以遍历所有的Activity属性的进程进行压缩。另外，当虚拟机内部自动调用第一接口时，也可以触发对Activity属性的进程进行压缩。
[0058] 针对本例，通过以下测试数据来与未经过后台进程压缩的测试数据进行对比，以显示后台进程压缩对系统性能带来的优势。以被测试的移动终端的内存为1G为例。
[0059] 步骤1，将移动设备300解锁后5秒开始记录内存数据。此数据作为“开机内存数据1”；
[0060] 步骤2，在步骤1基础上，静置3分钟后记录内存数据。此数据作为“开机内存数据2”；
[0061] 步骤3，解锁后10分钟开始记录内存数据。此数据作为“开机内存数据3”；同时，此数据将作为“一键加速前内存数据”；
[0062] 步骤4，在步骤2基础上，触发一键加速按钮，静置10秒后记录内存数据。此数据作为“一键加速后内存数据1”；
[0063] 步骤5，解锁后静置10分钟，然后触发一键加速按钮，静置10秒后记录内存数据。此数据作为“一键加速后内存数据2”；
[0064] 一键加速对内存的优化效果，主要可以参考“一键加速后内存数据2”和“一键加速前内存数据”。
[0065] 经过以上测试步骤，获得以下测试结果：
[0066] 1、“开机内存数据1”显示经过内存压缩的版本开机内存为：被使用的内存减小8.9M，空闲状态的内存增加8.4M；
[0067] 2、“开机内存数据2”显示经过内存压缩的版本开机内存为：被使用的内存减小9.5M，空闲状态的内存增加8.6M；
[0068] 3、“开机内存数据3”显示经过内存压缩的版本开机内存为：被使用的内存存减小3.9M，空闲状态的内存增加5.3M；
[0069] 4、“一键加速前内存数据”、“一键加速后内存数据1”显示经过内存压缩的版本相比未经过内存压缩的版本，一键加速使得：被使用的内存减小16.3M，空闲状态的内存增加15.3M；
[0070] 5、“一键加速前内存数据”、“一键加速后内存数据2”显示被使用的版本相比未经过内存压缩的版本，一键加速使得：Used内存减小19.6M，Free内存增加18.5M。
[0071] 由此可以推测在终端设备300正常使用过程中，一旦触发内存压缩的流程，可以多节省2％左右的内存。
[0072] 与前述内存压缩的方法的实施例相对应，本申请还提供了内存压缩的装置的实施例。
[0073] 本申请内存压缩的装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请内存压缩的装置所在电子设备的一种硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，存储器存储处理器可执行指令，实施例中装置所在的电子设备通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。处理器被配置为执行上文所述的相关动作，例如，某些例子中，处理器被配置为接收内存压缩的触发指令，通过虚拟机对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括Service属性的进程和/或Persistent属性的进程。
[0074] 请参考图5，内存压缩的装置500，可以包括：
[0075] 接口模块501，用于接收内存压缩的触发指令；
[0076] 内存压缩模块502，对指定后台进程所占用的内存中的数据进行压缩；指定后台进程可以包括Service属性的进程和/或Persistent属性的进程。
[0077] 作为例子，内存压缩的触发指令可以是在满足主动触发事件时被发送；主动触发事件可以包括以下至少一种：
[0078] 设备启动、用户触发指定的控件、后台进程清理功能被触发，并不排除有其他主动触发条件。
[0079] 某些例子中，装置500还可以包括校验模块502，用于对发送所述内存触发指令的进程进行权限验证，具体可以包括：
[0080] 如果发送所述内存触发指令的进程为设定的的系统进程，则权限验证通过，并通知所述内存压缩模块504；否则，返回权限验证失败的结果。
[0081] 某些例子中，还可以包括判断模块503，用于根据记录的本次收到的内存压缩的触发指令的时间，判断距离上次内存压缩的时间间隔是否符合预定条件，如果符合则通知所述内存压缩模块执行对指定后台进程所占用的内存中的数据进行压缩的步骤，如果不符合预定条件，则忽略所述内存压缩的触发指令。
[0082] 作为例子，所述装置500可以位于虚拟机，接口模块501可以从所述虚拟机外部接收内存压缩的触发指令。
[0083] 接口模块501可以是应用管理服务AMS模块的扩展接口。
[0084] 另外，内存压缩模块504还可以用于对Activity属性的进程所占用的内存中的数据进行压缩。
[0085] 图6是一种操作系统600的部分逻辑框图，包括：
[0086] 进程管理模块601，用于管理多个进程，所述进程包括后台进程；
[0087] 面向虚拟机的接口602，用于向虚拟机发送内存压缩的触发指令，所述内存压缩的触发指令用于触发虚拟机对指定后台进程所占用的内存中的数据进行压缩；所述指定后台进程包括服务Service属性的进程和/或永久Persistent属性的进程。
[0088] 操作系统600还可以包括设定的系统进程，用于调用所述面向虚拟机的接口向虚拟机发送内存压缩的触发指令，以便面向虚拟机的接口在响应主动触发事件时被调用。
[0089] 作为例子，主动触发事件可以包括以下至少一种：
[0090] 设备启动、用户触发指定的控件、后台进程清理功能被触发。
[0091] 内存压缩的触发指令可以是调用所述虚拟机提供的接口的指令，也可以是向所述虚拟机发送的指定信号等。
[0092] 作为例子，虚拟机提供的接口可以是AMS模块的扩展接口。
[0093] 上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
[0094] 对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
[0095] 以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。
