Binder驱动内存管理方法、装置、设备及存储介质

技术领域

本申请涉及技术领域，特别是涉及一种Binder驱动内存管理方法、装置、设备及存储介质。

背景技术

整个Android系统架构中，大量采用了Binder机制作为进程间通信(Inter-Process Communication，IPC)方案。Android系统中，每个应用程序都是由Android的四大组件(Activity、Service、Broadcast、ContentProvider)的一或多个组合而成，而这些组件所涉及的进程间的通信非常多，且都是依赖于Binder IPC机制。

在进程间通信过程中，当“数据发送进程”要将数据发送到“数据接收进程”，Binder驱动会申请一块物理内存缓存区用于存放通信的数据。Binder驱动会优先向BinderAlloc LRU链表申请用于存放通信数据的目标内存空间，当Binder Alloc LRU链表中空闲内存不足时，需要继续向伙伴系统(Buddy System)申请。若伙伴系统空闲内存不足时，则伙伴系统需要通过页面回收来保证分配，会导致内存分配速度较慢。

发明内容

本申请第一方面提供了一种Binder驱动内存管理方法，包括：获取第一进程向第二进程发起的Binder进程间通信指令；响应于Binder进程间通信指令，向内存回收链表请求为第一进程和第二进程分配用于存放通信数据的目标内存空间；响应于内存回收链表中对应第一进程和第二进程的空闲内存空间不足以存放通信数据，向预设内存池请求为第一进程和第二进程分配目标内存空间，其中，预设内存池独立于内存回收链表以及伙伴系统。

本申请第二方面提供了一种Binder驱动内存管理装置，包括：获取模块，用于获取第一进程向第二进程发起的Binder进程间通信指令；第一分配模块，用于响应于Binder进程间通信指令，从系统的内存回收链表中为第一进程和第二进程分配用于存放通信数据的目标内存空间；第二分配模块，用于响应于内存回收链表中对应第一进程和第二进程的空闲内存空间不足以存放通信数据，从预设内存池中为第一进程和第二进程分配用于存放通信数据的目标内存空间，其中，预设内存池为从伙伴系统中划分出的部分内存空间。

本申请第三方面提供了一种电子设备，该电子设备包括相互耦接的存储器和处理器，存储器用于存储程序数据，处理器用于执行程序数据以实现前述的方法。

本申请第四方面提供了一种计算机可读存储介质，该计算机可读存储介质中存储有程序数据，程序数据在被处理器执行时，用以实现前述的方法。

本申请的有益效果是：区别于现有技术的情况，本申请通过获取第一进程向第二进程发起的Binder进程间通信指令，然后响应于Binder进程间通信指令，向内存回收链表请求为第一进程和第二进程分配用于存放通信数据的目标内存空间；响应于内存回收链表中对应第一进程和第二进程的空闲内存空间不足以存放通信数据，向预设内存池请求为第一进程和第二进程分配目标内存空间，其中，预设内存池独立于内存回收链表以及伙伴系统。上述方案中，针对Binder驱动内存分配框架，提出了预设内存池，预设内存池独立于内存回收链表以及伙伴系统，在内存回收链表空闲内存空间不足时原本应向伙伴系统请求目标内存空间调整为向预设内存池请求目标内存空间，由此可以避免伙伴系统内存不足需要通过内存回收来保证内存分配的情况，从而可以提升Binder进程间通信中的内存分配速度。

附图说明

为了更清楚地说明本申请中的技术方案，下面将对实施例描述中所需要的附图作简单的介绍，显而易见地，下面描述的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来说，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。其中：

图1是Binder IPC原生方案的内存分配流程示意图；

图2是本申请Binder进程间通信过程中目标内存空间的申请和释放流程示意图；

图3是本申请Binder驱动内存管理方法一实施例的流程示意图；

图4是本申请Binder驱动内存管理方法另一实施例的流程示意图；

图5是图3中步骤S12一实施例的流程示意图；

图6是本申请Binder驱动内存管理方法又一实施例的流程示意图；

图7是本申请Binder驱动内存管理装置一实施例的结构示意框图；

图8是本申请电子设备一实施例的结构示意框图；

图9是本申请计算机可读存储介质一实施例的结构示意框图。

具体实施方式

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

本申请中的术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在电子设备上，性能毫无疑问是用户非常看重的一项重要指标。Binder IPC机制比起传统的管道、消息队列、Socket等进程通讯方式有更好的性能，如Binder IPC数据拷贝只需要一次(共享内存)，而管道、消息队列、Socket传统的进程通讯方式都需要2次。

整个Android系统架构中，大量采用了Binder机制作为IPC方案。Android系统中，每个应用程序都是由Android的四大组件(Activity、Service、Broadcast、ContentProvider)的一或多个组合而成，而这些组件所涉及的进程间的通信非常多，且都是依赖于Binder IPC机制。所以更好地优化Binder IPC机制，无疑对提升移动设备的性能有很大的帮助。

请参阅图1，图1是Binder IPC原生方案的内存分配流程示意图。

首先，在进程间通信之前，应用程序可以通过调用mmap()系统函数实现和驱动的内存映射。在Binder驱动中，通过用户空间传入的虚拟内存大小分配一块内核空间中的虚拟内存(最大为4M)缓存区。该虚拟内存缓存区会同用户空间一块地址产生映射，用户程序通过该地址可以进程间通讯。如图1所示，在进程间通信之前，Binder驱动已经为第二进程分配了一块虚拟内存缓存区。此时，Binder驱动并没有分配物理内存，Binder驱动采用的是需要用的时候再去申请内存，避免内存浪费。

接着，当第一进程要将数据发送到第二进程时，Binder驱动会向内核空间申请一块物理内存缓存区(即目标内存空间)用于存放通信数据，之后调用copy_from_user()将发送数据拷贝到内核中(Binder驱动)的目标内存空间中，此时第一进程会被挂起。由于在进程间通信之前已经构建了映射关系，此时相当于也将通信数据发送到了第二进程的用户空间中，之后Binder驱动通知Server端进程执行解包即可。

然后，第二进程收到Binder驱动通知后，对通信数据进行解包，并调用相关方法处理，处理完成后就会发出free buffer指令来释放目标内存空间。当然，第二进程还要将处理结果返回给第一进程，其流程相当于上面的逆过程，不再赘述。

最后，当上层进程(表示第一进程和第二进程中至少一个)退出进程间通信(即进程间通信被中断)，或者上层进程主动发起release buffer指令，或者上层进程在通信完后发起free buffer指令，binder驱动也会释放目标内存空间。

请参阅图2，图2是本申请Binder进程间通信过程中目标内存空间的申请和释放流程示意图。

目标内存空间的申请方式为：

第一进程第一次发起Binder进程间通信指令，请求Binder驱动分配用于存放通信数据的目标内存空间时，基于Binder驱动内存分配框架，须向伙伴系统申请目标内存空间。当通信完成后，目标内存空间将释放到Binder Alloc LRU链表中。其中，Binder Alloc LRU链表(以下简称LRU链表)是Binder原生缓存释放内存的链表，LRU链表中的内存空间是与进程间通信的进程对应的，只有通信间进程在通信完成后将目标内存空间释放到LRU链表中，LRU链表中才存在与该通信间进程对应的内存空间。

为了尽量减少内存回收引起的震荡，刚刚回收的内存马上又被访问需要重新分配。Linux设计了LRU(Last Recent Use)链表，来优先回收最长时间没有访问的内存。LRU链表的作用就是进行页排序，将应该回收的内存页放在链表尾部，最不该回收的内存页放在链表头部。内存回收主要是将LRU链表中最近很少访问的尾部内存页中的数据从内存转储到磁盘中，然后将转储后的内存页释放到伙伴系统，或者不进行转储，直接将内存页释放到伙伴系统，以作为空闲内存使用。

第一进程非第一次发起Binder进程间通信指令，请求Binder驱动分配用于存放通信数据的目标内存空间时，Binder驱动优先从Binder Alloc LRU链表申请目标内存空间，LRU链表找不到对应的目标内存空间，则再从伙伴系统申请目标内存空间。在第一进程向LRU链表申请目标内存空间时，LRU链表只能分配第一进程和第二进程对应的空闲内存空间，而无法将其他进程的内存空间分配给第一进程和第二进程。其中，LRU链表找不到对应的目标内存空间包括两种情况，第一种是LRU链表中不存在第一进程和第二进程对应的内存空间，第二种是LRU链表中对应第一进程和第二进程的内存空间不足，即第一进程和第二进程对应的内存空间小于目标内存空间。

当内存分配链表中对应第一进程和第二进程对应的内存空间不足时，再向伙伴系统请求目标内存空间。

对应地，目标内存空间的释放方式为：

第一种，当上层进程(表示第一进程和第二进程中至少一个)退出进程间通信(即进程间通信被中断)，或者上层进程主动发起release buffer指令，Binder驱动直接将目标内存空间释放回伙伴系统。

第二种，上层进程在通信完后发起free buffer指令，binder驱动会将目标内存空间释放回LRU链表。

基于目前的Binder驱动内存分配框架，两种情况会存在内存分配较慢的问题：

1、当进程第一次发起binder通信时，此时LRU链表中不存在该进程对应的内存空间，所以肯定要从伙伴系统里申请目标内存空间，由此可能存在伙伴系统因自身内存不足，需要通过页面回收来保证分配的情况，由此导致内存分配速度低。

2、当进程非第一次发起binder通信时，但是系统因内存不足时，LRU链表中的页面会被释放至伙伴系统，所以还是需要从伙伴系统里申请目标内存空间，由此导致内存分配速度低。

基于此，本申请提供了一种Binder驱动内存管理方法，调整了原有的Binder驱动内存分配框架，提出了预设内存池，具体请参见后续实施例。

请参阅图3至图4，图3是本申请Binder驱动内存管理方法一实施例的流程示意图，图4是本申请Binder驱动内存管理方法另一实施例的流程示意图。其中，本申请的执行主体为电子设备。

该方法可以包括以下步骤：

步骤S11：获取第一进程向第二进程发起的Binder进程间通信指令。

步骤S12：响应于Binder进程间通信指令，向内存回收链表请求为第一进程和第二进程分配用于存放通信数据的目标内存空间。

其中，内存回收链表为Binder Alloc LRU链表，Binder Alloc LRU链表在系统初始化时创建。内核使用双向链表来定义LRU链表，并且根据页面的类型分为LRU_ANON(匿名链表)和LRU_FILE(文件映射页面链表)。每种类型根据页面的活跃分为活跃LRU和不活跃LRU，所以内核中一共有如下5个LRU链表：LRU_INACTIVE_ANON(不活跃匿名页面链表)、LRU_ACTIVE_ANON(活跃匿名页面链表)、LRU_INACTIVE_FILE(不活跃文件映射页面链表)、LRU_ACTIVE_FILE(活跃文件映射页面链表)、LRU_UNEVICTABLE(不可回收页面链表)。

具体地，binder_update_page_range()函数用于向内存回收链表请求为进程间通信的进程分配用于存放通信数据的目标内存空间，并分别映射到内核态和用户态的虚拟内存地址空间。

步骤S13：响应于内存回收链表中对应第一进程和第二进程的空闲内存空间不足以存放通信数据，向预设内存池请求为第一进程和第二进程分配目标内存空间，其中，预设内存池独立于内存回收链表以及伙伴系统。

具体地，可以调用binder_page_poool_alloc_pages()函数向预设内存池(又称为Binder PagePool)请求为第一进程和第二进程分配目标内存空间。预测内存池的大小可以根据实际情况进行设置，此处不做限定。预测内存池管理的内存空间小于伙伴系统管理的内存空间。进一步地，可以是预测内存池管理的内存空间远小于伙伴系统管理的内存空间。例如，预测内存池管理的内存空间为8M，伙伴系统管理的内存空间为8G、12G，可见，使用8M的预设内存池，对于8G、12G运行内存的电子设备来说是很少的，但是却可以大量避免binder驱动分配物理内存进入伙伴系统拿，走慢速路径导致用户进程阻塞发生卡顿等问题。

其中，binder_page_poool_alloc_pages()函数用于向预设内存池请求为进程间通信的进程分配目标内存空间。

在一些实施方式中，响应于内存回收链表中对应第一进程和第二进程的空闲内存空间不足以存放通信数据可以是响应于内存回收链表中不存在对应第一进程和第二进程的空闲内存空间，或者内存回收链表中对应第一进程和第二进程的空闲内存空间小于目标内存空间，请求预设内存池为第一进程和第二进程分配目标内存空间。

其中，LRU链表中的内存空间是与进程间通信进程对应的，只有通信间进程在通信完成后将目标内存空间释放到LRU链表中，LRU链表中才存在与该通信间进程对应的空闲内存空间。所以当第一进程第一次向第二进程发起的Binder进程间通信指令时，LRU链表中不存在对应第一进程和第二进程的空闲内存空间。

其中，当LRU链表中存在对应第一进程和第二进程的空闲内存空间，但是该空闲内存空间小于目标内存空间，说明LRU链表不足以为第一进程和第二进程分配目标内存空间，由此需要向预设内存池请求。一般地，当LRU链表中对应第一进程和第二进程的空闲内存空间不足以存放通信数据时，是向伙伴系统请求分配目标内存空间，而本申请改变了原有的内存分配机制，在伙伴系统和LRU链表之间设置了一个中间的预设内存池，从而无需从伙伴系统中请求目标内存空间。

上述方案，通过获取第一进程向第二进程发起的Binder进程间通信指令，然后响应于Binder进程间通信指令，向内存回收链表请求为第一进程和第二进程分配用于存放通信数据的目标内存空间；响应于内存回收链表中对应第一进程和第二进程的空闲内存空间不足以存放通信数据，向预设内存池请求为第一进程和第二进程分配目标内存空间，其中，预设内存池独立于内存回收链表以及伙伴系统。上述方案中，针对Binder驱动内存分配框架，提出了预设内存池，预设内存池独立于内存回收链表以及伙伴系统，在内存回收链表空闲内存空间不足时原本应向伙伴系统请求目标内存空间调整为向预设内存池请求目标内存空间，由此可以避免伙伴系统内存不足需要通过内存回收来保证内存分配的情况，从而可以提升Binder进程间通信中的内存分配速度。

请参阅图5，图5是图3中步骤S12一实施例的流程示意图。

在本实施例中，步骤S12可以包括子步骤S121～S123：

步骤S121：响应于Binder进程间通信指令，向内存回收链表申请目标内存空间。

步骤S122：确定内存回收链表中对应第一进程和第二进程的空闲内存空间，其中，内存回收链表用于回收至少一组通信进程通信完成后释放的内存空间。

步骤S123：响应于内存回收链表中对应第一进程和第二进程的空闲内存空间大于或等于目标内存空间，则从内存回收链表中为第一进程和第二进程分配目标内存空间。

在一具体示例中，内存回收链表中对应第一进程和第二进程的空闲内存空间为0.2M，而目标内存空间为0.1M，则从内存回收链表中为第一进程和第二进程分配目标内存空间。

请参阅图4和图6，图6是本申请Binder驱动内存管理方法又一实施例的流程示意图。

该方法可以包括以下步骤：

步骤S21：获取第一进程向第二进程发起的Binder进程间通信指令。

步骤S22：响应于Binder进程间通信指令，向内存回收链表请求为第一进程和第二进程分配用于存放通信数据的目标内存空间。

步骤S23：响应于内存回收链表中对应第一进程和第二进程的空闲内存空间不足以存放通信数据，向预设内存池请求为第一进程和第二进程分配目标内存空间，其中，预设内存池独立于内存回收链表以及伙伴系统。

关于步骤S21～S23的说明请参见前述实施例，此处不再赘述。

步骤S24：响应于预设内存池中的空闲内存空间不足以存放通信数据，向伙伴系统请求为第一进程和第二进程分配目标内存空间。

在一些实施方式中，预设内存池管理的内存空间，即包括已经分配给其他进程通信的占用内存空间，也包括未被分配出去的空闲内存空间。所以，当第一进程请求的目标内存空间，目标内存空间大于当前的空闲内存空间时，预设内存池无法为第一进程和第二进程分配目标内存空间，由此需要向伙伴系统请求目标内存空间。

在一些实施方式中，当预设内存池中的空闲内存量小于预设阈值时，可以向伙伴系统请求为预设内存池分配内存空间至预设内存池中的空闲内存量到达预设阈值。另外，当预设内存池中的空闲内存量大于预设阈值时，可以将超过预设阈值的空闲内存空间回收至伙伴系统。由此，在一示例中，预设内存池可以一直保持8M空闲的内存空间，从而使得预设内存池的空闲内存空间可以满足目标内存空间的分配。

需要说明的是，本实施例中的步骤S24～S28之间并不一定的先后关系，步骤之间可以先后执行，也可以同时执行，此处不作限定。

步骤S25：响应于对内存回收链表中的内存空间的回收指令，将内存回收链表中的待回收内存空间回收至预设内存池。

其中，当伙伴系统内存不足时，会生成对内存回收链表中的内存空间的回收指令，在一些技术方案中，该回收指令用于将内存回收链表中的待回收内存空间回收至伙伴系统，但是在本实施例中，响应于该回收指令，优先将内存回收链表中的待回收内存空间回收至预设内存池。

具体地，当伙伴系统内存不足时，会通过回调驱动函数shrink()回收物理内存。

其中，待回收内存空间可以为内存回收链表中的空闲内存空间，或者为占用内存空间中不活跃的内存空间，即预设时间范围内未被访问的内存空间，待回收内存空间具体可以根据实际情况进行设置或调整此处不做限定。可选地，预设时间范围可以为2小时、1天等，可以根据实际情况进行设置或调整此处不做限定。

步骤S26：响应于预设内存池中的空闲内存量大于预设阈值时，将内存回收链表中剩余的待回收内存空间回收至伙伴系统。

可选地，预设阈值可以根据实际情况进行设置或调整此处不做限定。在一示例中，预设阈值可以为预设内存池总内存量(如8M)，或者总内存量的80％～90％(如6.4M～7.2M)等。

具体地，可以调用free_page()函数将内存回收链表中剩余的待回收内存空间回收至伙伴系统，以增加系统内存空间。

步骤S27：响应于第一进程和第二进程的进程间通信被中断，释放目标内存空间并将目标内存空间回收至预设内存池。

其中，第一进程和第二进程的进程间通信被中断可以是第一进程和第二进程中的至少一者退出运行，具体可以是被系统查杀或者用户主动关闭运行等。

在一些实施方式中，响应于第一进程和第二进程的进程间通信被中断，可以调用release buffer()函数释放目标内存空间，然后调用binder_page_pool_free_pages()函数将将目标内存空间回收至预设内存池。其中，binder_page_pool_free_pages()函数用于将进程间通信被中断时释放的内存空间回收至预设内存池。

在一些实施方式中，响应于预设内存池中的空闲内存量大于预设阈值时，将进程间通信被中断时释放的至少部分目标内存空间回收至伙伴系统。关于预设阈值的说明请参见步骤S26，此处不再赘述。

步骤S28：响应于第一进程和第二进程的进程间通信完成，释放目标内存空间并将目标内存空间回收至内存回收链表。

在一些实施方式中，响应于第一进程和第二进程的进程间通信完成，可以调用free buffer()释放目标内存空间，然后调用list_lru_add()函数将目标内存空间回收至内存回收链表。

其中，free buffer()：用于在进程间通信完成时，释放内核空间中的目标内存空间；release buffer()：用于在进程间通信被中断时，释放内核空间中的目标内存空间；list_lru_add()：用于将free buffer()释放的目标内存空间添加到LRU链表中。

以上，本申请针对Binder进程通信驱动模块物理内存申请进行了优化，有效地解决了由于Binder通信过程物理内存分配慢，导致用户线程阻塞造成的性能卡顿问题。经测试发现，在android移动终端，该优化方案能减少90％的Binder分配物理内存进入慢速路径，降低5％的应用丢帧率。

请参阅图7，图7是本申请Binder驱动内存管理装置一实施例的结构示意框图。

Binder驱动内存管理装置100包括获取模块110、第一分配模块120和第二分配模块130。获取模块110用于获取第一进程向第二进程发起的Binder进程间通信指令；第一分配模块120用于响应于Binder进程间通信指令，向内存回收链表请求为第一进程和第二进程分配用于存放通信数据的目标内存空间；第二分配模块130用于响应于内存回收链表中对应第一进程和第二进程的空闲内存空间不足以存放通信数据，向预设内存池请求为第一进程和第二进程分配目标内存空间，其中，预设内存池独立于内存回收链表以及伙伴系统。

在一些实施方式中，响应于Binder进程间通信指令，向内存回收链表请求为第一进程和第二进程分配用于存放通信数据的目标内存空间，包括：响应于Binder进程间通信指令，向内存回收链表申请目标内存空间；确定内存回收链表中对应第一进程和第二进程的空闲内存空间，其中，内存回收链表用于回收至少一组通信进程通信完成后释放的内存空间；响应于内存回收链表中对应第一进程和第二进程的空闲内存空间大于或等于目标内存空间，则从内存回收链表中为第一进程和第二进程分配目标内存空间。

在一些实施方式中，第二分配模块130具体用于：响应于内存回收链表中不存在对应第一进程和第二进程的空闲内存空间，或者内存回收链表中对应第一进程和第二进程的空闲内存空间小于目标内存空间，请求预设内存池为第一进程和第二进程分配目标内存空间。

在一些实施方式中，第二分配模块130还用于：响应于预设内存池中的空闲内存空间不足以存放通信数据，向伙伴系统请求为第一进程和第二进程分配目标内存空间。

在一些实施方式中，Binder驱动内存管理装置100还包括回收模块(图未示)，用于响应于对内存回收链表中的内存空间的回收指令，将内存回收链表中的待回收内存空间回收至预设内存池。

在一些实施方式中，回收模块还用于响应于预设内存池中的空闲内存量大于预设阈值时，将内存回收链表中剩余的待回收内存空间回收至伙伴系统。

在一些实施方式中，回收模块还用于响应于第一进程和第二进程的进程间通信被中断，释放目标内存空间并将目标内存空间回收至预设内存池。

关于上述步骤的说明，请参见前述方法实施例此处不再赘述。

请参阅图8，图8是本申请电子设备一实施例的结构示意框图。

电子设备200包括相互耦接的存储器210和处理器220，存储器210用于存储程序数据，处理器220用于执行程序数据以实现上述任一方法实施例中的步骤。

电子设备200可以包括但不限于：个人电脑(例如，台式机、笔记本电脑、平板电脑、掌上电脑等)、手机、服务器、可穿戴设备，以及增强现实(Augmented Reality,AR)、虚拟现实(Virtual Reality,VR)设备、电视机等，在此不做限定。

具体而言，处理器220用于控制其自身以及存储器210以实现上述任一方法实施例中的步骤。处理器220还可以称为中央处理单元(Central Processing Unit,CPU)。处理器220可能是一种集成电路芯片，具有信号的处理能力。处理器220还可以是通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application SpecificIntegrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。另外，处理器220可以由多个集成电路芯片共同实现。

请参阅图9，图9是本申请计算机可读存储介质一实施例的结构示意框图。

计算机可读存储介质300存储有程序数据310，程序数据310被处理器执行时，用以实现上述任一方法实施例中的步骤。

计算机可读存储介质300可以为U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等可以存储计算机程序的介质，也可以为存储有该计算机程序的服务器，该服务器可将存储的计算机程序发送给其他设备运行，或者也可以自运行该存储的计算机程序。

以上，本申请中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本申请中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法和装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施方式方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。