一种处理请求的方法、装置及设备、可读介质与流程

本申请涉及操作系统的性能优化，尤其涉及处理请求的方法、装置及设备、可读介质。

背景技术：

目前某些开放性的操作系统，例如Android(安卓)系统，对应用采取了完全信任的策略，但是众多应用中，可能存在劣质应用和恶意应用，而劣质应用和恶意应用可能会错误的生成大量的请求，占用大量缓存空间，影响其他应用的正常运行。

技术实现要素：

有鉴于此，本申请提供一种处理请求的方法、装置及设备、可读介质。

具体地，本申请是通过如下技术方案实现的：

根据本申请实施例的第一方面，提供一种处理请求的方法，包括步骤：

当接收到请求方的请求时，根据请求方的性能信用等级将所述请求存储到相应的缓冲区；所述性能信用等级基于请求的性能参数设定，不同的缓冲区用于存储不同性能信用等级的请求方的请求；

基于预定策略对缓冲区中的请求进行发送。

根据本申请的第二方面，提供一种电子设备，包括：

处理器；

存储处理器可执行指令的存储器；

其中，所述处理器耦合于所述存储器，用于读取所述存储器存储的程序指令，并作为响应，执行如下操作：

当接收到请求方的请求时，根据请求方的性能信用等级将所述请求存储到相应的缓冲区；所述性能信用等级基于请求方的性能参数设定，不同的缓冲区用于存储不同性能信用等级的请求方的请求；

基于预定策略对缓冲区中的请求进行发送。

根据本申请的第三方面，提供一种处理请求的装置，包括：

资源存储处理模块，用于当接收到请求方的请求时，根据请求方的性能信用等级将所述请求存储到相应的缓冲区；所述性能信用等级基于请求方的性能参数设定，不同的缓冲区用于存储不同性能信用等级的请求方的请求；

缓冲区资源处理模块，用于基于预定策略对缓冲区中的请求进行发送。

根据本申请的第四方面，提供一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得终端设备执行以上各实施例所述的方法。

本申请提供的实施例，对各种需要缓冲处理的请求进行分级管理，将不同级别的请求放入不同的缓存区，并针对请求方的性能信用区分对待，通过设置适合实际应用场景的预定策略，可以实现资源的合理分配，例如，某些场景可以将资源支持性能优良的应用，拒绝或延迟为性能较差的应用服务等等，因此可以避免某些应用占用缓存空间过多的问题。

附图说明

图1是本申请一示例性实施例示出的处理请求的方法的流程图；

图2是一实例中处理请求的方法的流程图；

图2a是一实例中处理请求的方法的又一流程图；

图3是本申请一示例性实施例示出的处理请求的装置的逻辑框图；

图4是本申请一示例性实施例示出的处理请求的装置的硬件架构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

很多具有独立功能的软件模块不能实时处理消息，需要借助缓存机制实现通信。以应用为例，传统技术中一些开放式的操作系统未对应用进行限制，无论是普通的应用还是劣质应用或恶意应用，均用同样的方式进行管理，导致劣质应用和恶意应用抢占缓存空间。以Android操作系统的四大组件之一的广播组件为例，各种应用均可能发送不限数量的广播消息，同时，接收广播消息的组件也可能很多，因此，可能需要一条或几条队列来保存广播消息，然后逐条处理。如果劣质应用或恶意应用不停的发送广播消息，并且超出接收组件的处理速度，则队列就会被大量占用，导致其他应用发送的广播消息无法及时被处理。进一步，如果应用具有超时重发机制，则导致队列拥塞的现象更加严重。

除了广播组件，操作系统中其他具有独立功能的软件模块也会存在类似问题，例如应用程序、线程、动态链接库、进程、服务等，这类软件模块均具有独立功能，可以与其他软件模块通信，且一般采用有序存储的方式(例如先进先出、先进后出等方式)将消息存储在缓存区，借助缓存机制来处理通信消息，本申请对此提出了对缓存资源的管理方法，能够有效管理缓存资源，提高操作系统对缓存资源的调度能力。本申请中，将存储在缓存区的数据称为缓存资源。缓存区可以是单向/双向队列、链表、栈、数据库等，本领域技术人员还可以将本方案扩展到其他类似属性的缓存方式。

图1是一实施例中处理请求的方法的部分流程图。

S101，当接收到请求方的请求时，根据请求方的性能信用等级将所述请求存储到相应的缓冲区；作为例子，请求方的性能信用等级可以基于请求方的性能参数设定，不同的缓冲区可以用来存储不同性能信用等级的请求方的请求；

S102，基于预定策略对缓冲区中的请求进行发送。

本实施例中，性能信用等级可以基于性能参数确定，可以根据性能参数确定出一个性能信用等级作为基准等级，代表该性能信用等级的软件模块对操作系统产生可接受的影响，评价标准可以根据需求自行设定。比基准等级性能优良的软件模块定为基准以上等级、比基准等级性能较差的软件模块定为基准以下等级。性能参数可以由设计者根据设计需要决定，例如，某些场合可以选择超时未响应时长参数(例如ANR)、对缓存区的占用时间等参数作为性能参数。

本申请提供了几种获得性能参数的途径，在此仅作为示例说明，并非排除其他获取途径。

在一些操作系统中可能会有软件模块对缓存空间操作的API记录，记录了操作被处理的时间、是否有不良记录等信息，以Android系统为例，Android系统在处理完广播消息后，会通过BroadcastQueue函数记录一段广播消息的历史信息，其中包括记录的ANR的次数、请求被处理的时间等信息，因此，一个例子中，可以根据操作系统所记录的历史信息来获取所需要的性能参数(例如ANR参数等)。在另一些例子中，还可以利用软件模块中设置的埋点数据来获得所需要的性能参数。

对不同软件模块分级是为了区分软件模块的质量，例如，可以按照软件模块的请求对操作系统性能的影响，划分为三个级别，为方便描述，定义为第一级别、第二级别、第三级别。第一级别代表基准以上等级(例如，可以是优质应用)，第二级别代表基准等级(例如，可以是普通应用)，第三级别代表基准以下等级(例如可以是劣质应用)。当然，在其他示例中，也可以划分为更多或更少的等级(例如，还可以包括第四等级，代表比第三等级更低的等级，比如恶意应用等)。

在基于性能参数设定性能信用等级时，可以先采集请求方的性能参数；根据各性能参数的权值计算对应的统计值；基于统计值的排序划分请求方的性能信用等级。

以下对一个分级的具体做法举例说明：可以统计一定数量的软件模块的预设性能参数，并按照一定的权值对各参数加权，计算出每个软件模块的统计值后，根据排名次序，按照一定的比例划分性能信用等级。例如，设置一个ANR次数最大值，然后设置一个权值a，对应ANR次数不大于最大值时的权值、一个权值b，对应ANR次数大于最大值时的权值、一个权值c，对应ANR次数不大于最大值时请求消息占用缓存区的时间的权值。

当请求的ANR次数未达到此最大值时，统计每个请求占用缓存区的时间，对根据权值a和权值c计算统计结果，并对统计结果排序，占用时间越短表明性能越优，则排序越靠前。当达到ANR次数最大值后，则可以不再统计该请求占用缓存的时间，而是按照权值b计算统计值，权值b的的权重可以高于权值a，使得ANR次数超出最大值的请求的排序位于其他未超出ANR次数最大值的请求的排序之后。

针对排序结果，将前30％的软件模块划为第一级别，排在30％-90％之间的软件模块划为第二级别，排在后10％的软件模块划为第三级别。

容易理解，将哪些参数作为性能参数、以及如何划分各个性能信用等级，并非仅限于一种方式，对此不再加以赘述。

本申请中，发送请求的软件模块称为请求方。传统做法通常是将所有请求方的请求统一放在同一个缓冲区，不同于此种做法，本实施例对应每个级别的软件模块各开设一个缓冲区，当某个软件模块作为请求方发起请求时，将该请求存储到与该级别所对应的缓冲区内，以便后续处理。

针对各个缓冲区内存储的请求，可以设置不同的预定策略来处理，在不同场景下，处理的方式可以不同，例如，可以是将一些请求丢弃、或者将一些请求优先发送至接收方、或者将一些请求在设定条件下从一个缓存区放入另一个缓存区等。以下是对预定策略的几种实例说明：

策略一：根据请求方的性能信用等级确定请求被发送至接收方的先后次序。例如，可以设定优先被发送的请求的级别：由于基准以上等级的软件模块性能高于正常性能，不容易产生由于代码质量导致的各种问题，因此可以将基准以上等级的请求优先发送至接收方。再例如，可以设定被延迟发送的请求的级别：由于基准以下等级的软件模块质量较差，或者会产生恶意行为，可以将基准以下等级的软件模块的请求在处理完基准以上等级和基准等级的软件模块的请求后再处理，作为一种具体实现，可以是当基准等级的请求被处理完后，如果基准以下等级的请求存储时长未超时，则将该基准以下等级的请求存入基准等级的请求对应的缓存区后进行发送。另外，还可以同时设置优先被发送的请求的级别和延迟被发送的请求的级别等。设置的方式在不同的应用场景下可能会有所差异，并非局限于此处所列举的方式。

策略二：根据请求方的性能信用等级确定不被发送的请求。例如，基准以下等级可能存在恶意软件模块，因此可以将基准以下等级的软件模块的请求丢弃；再例如，也可以针对所存储的一些性能信用等级(比如基准以下等级)的软件模块(例如劣质软件模块)的请求设置定时器，在存储超时后，则这些请求将不再被发送至接收方。

容易理解，一些情况下，预定策略的设定可以跟性能信用等级划分的方式有关，当然，使用者可以根据实际应用环境设定不同的预定策略，并非仅限于本申请所列举的方式。

一些例子中，可以进一步改进管理缓存资源的方法，提供可以动态的调整软件模块的性能信用等级的方案，具体实现可以是在请求被处理后，采集该请求的性能参数，根据所采集的性能参数更新请求方的性能信用等级。这是考虑到软件模块的版本升级后可能会使得软件模块的性能发生变化。例如，软件模块的开发者可能会通过新版本来克服旧版本的代码缺陷，或者新版本出现了旧版本没有的代码质量问题，因此可以在每次新版本发布后，对软件模块的性能重新进行评价并划分性能信用等级，当收到新版本的软件模块的请求时，按照更新后的性能信用等级存储到相应的缓冲区。

作为例子，还可以设计其他的调整软件模块的性能信用等级的方式，例如，可以为用户提供相应的接口，供用户手动更改软件模块的性能信用等级。

通过动态调整软件模块的性能信用等级，可以使管理缓冲资源的模式形成一个闭环，软件模块的不同版本会影响资源分配的结果，操作系统将可用资源优先分配给性能优良的软件模块，使得软件模块的性能良性发展，实现了自动控制管理缓冲资源的过程。

在一些例子中，还可以提供数据共享的解决方案。终端设备上软件模块的性能信用等级信息还可以被同步到云端服务器，并且所上传的性能信用等级信息可以共享给其他用户，从而实现数据共享。例如，a用户通过终端设备将软件模块A1相关的性能信用等级信息上传到云端服务器，云端服务器下发给装有该软件模块的其他用户，可以供其他用户在手动调整该软件模块的性能信用等级时参考。再例如，以一个应用为例，该应用可能是通过应用商店的软件平台被用户安装到终端设备，则该应用在各个终端设备上的性能信用等级信息可以被上传到应用商店的软件平台，而应用商店的软件平台的发布者具有调整应用性能信用等级的权限，可以根据所采集的性能信用等级信息综合评定，调整该应用的性能信用等级。

从以上各实施例的描述可以看出，设置或调整软件模块的性能信用等级的动作可以由终端设备的操作系统执行、也可以由服务器来统一执行后下发给各终端设备。

以下以应用发送广播消息的场景为例，阐述一实例。

此实例中，在各应用发布时，操作系统采集各应用的一些预定性能参数进行评测，根据评测结果划分各应用的性能信用等级，应用A被标识为优质应用、应用B被标识为普通应用、应用C被标识为较差绩效应用、应用D被标识为可疑恶意应用，各应用所对应的性能信用等级信息被存储在应用绩效数据库中。另外，针对四个性能信用等级，构建三个队列，队列A用来存储优质应用的请求、队列B用来存储普通应用的请求、队列C用来存储较差绩效应用的请求。本例中，对各队列中存储的请求的处理策略为：优先将队列A中的请求发送给接收方、当队列A中的请求处理完后发送队列B中的请求、当队列B空闲时，将队列C中的请求加入队列B中、针对队列C启动定时器，当定时器超时时，将队列C中存储的请求删除、当收到应用D的请求时，将应用D的请求过滤掉。各队列存储请求的存储方式可参照本领域技术人员的常用做法实现。

参见图2，S201，应用A、B、C、D向操作系统发送广播请求，操作系统连续接收到应用A、B、C、D发送的广播请求，判断各应用的性能信用等级(S202)，由于判断结果应用A为优质应用、应用B为普通应用、应用C为较差绩效应用、应用D为恶意应用，因此将A、B、C应用分别放入队列A、队列B、队列C，并将应用D的请求过滤(S203)；

S204步骤中，操作系统在处理各队列中的广播请求，优先取出队列A中的请求，发送广播请求，在处理完队列A中广播的请求后，对队列B中的广播请求进行处理；当处理完队列B的广播请求后，将队列C中的广播请求放入队列B中，进行处理(S207)；如果在处理时如果有其他普通应用的请求被存储进队列B，则继续处理队列B中的请求，直至队列B空闲后，再次将队列C中的请求加入队列B。在队列C中的请求被加入队列B之前，如果定时器超时，则将队列C中超时的请求删除(S208)。

结合图2a可以直观的理解此处理过程。

在操作系统每处理完一条请求后，记录请求被处理的时间以及是否有ANR记录等信息，并存储到应用绩效数据库中(S205)。

在各应用发布新版本时，操作系统根据预先设定的性能参数对新发布的应用重新进行测评，如果测评结果划分的应用的性能信用等级与旧版本的性能信用等级不同，则将该应用的当前性能信用等级替换应用绩效数据库中保存的性能信用等级。当收到新版本的应用的请求时，按照更新后的性能信用等级将请求存储到对应的队列，并进行处理。

针对图2所列举的方案，以下分别列举一实例来显示应用此方案前后的操作系统的性能差异。

结合图2，实例中，短信应用为应用b，如果绩效较差的应用c在短信应用b发送短信之前收短信，并且Android系统默认超时时间是60秒，由于应用c性能较差，不能及时处理收短信的请求，并且需要等待60秒超时后才可以重新收短信，那么每次用户收短信都会延迟60秒。一些实际场景中，很多应用会使用验证码的功能，而验证码的有效期通常为1分钟，导致用户在使用这些应用时无法通过验证。而在应用本发明所列举的各实施例之后，第二次收短信时，应用c的请求将会被放入队列c，处理次序后排，性能正常的短信应用所发送的短信就可以正常收到了。甚至，通过设置队列c的超时时长，可以使应用c完全收不到短信，保障了操作系统的正常运行。

与前述处理请求的方法的实施例相对应，本申请还提供了处理请求的装置的实施例。

请参考图3，处理请求的装置300，包括：

资源存储处理模块301，用于当接收到请求方的请求时，根据请求方的性能信用等级将所述请求存储到相应的缓冲区；所述性能信用等级基于请求方的性能参数设定，不同的缓冲区用于存储不同性能信用等级的请求方的请求；

缓冲区资源处理模块302，用于基于预定策略对缓冲区中的请求进行发送。

作为例子，预定策略可以包括：请求被发送至接收方的先后次序的策略；和/或

请求不被发送的策略。

在一个例子中，请求方的性能信用等级可以包括基准等级、以及基准以上等级或基准以下等级；请求不被发送的策略可以包括：

基准以下等级的请求存储时长超时后不被发送。

作为例子，可以按照以下方式发送基准以下等级的请求：

当基准等级的请求被处理完后，如果基准以下等级的请求存储时长未超时，则将该基准以下等级的请求存入基准等级的请求对应的缓存区后进行发送。

一些例子中，基于预定策略对缓冲区中的请求进行处理后，缓冲区资源处理模块还可以采集该请求的性能参数；根据所采集的性能参数更新请求方的性能信用等级。

一些例子中，缓冲区资源处理模块可以采集请求方的性能参数；根据各性能参数的权值计算对应的统计值；基于统计值的排序划分请求方的性能信用等级。

作为例子，性能参数可以包括以下至少任一：

请求的超时未响应次数、请求被存储时长。

缓存区包括可以以下任一：

队列、链表、栈、数据库。

请求方可以包括以下任一：

应用程序、组件、进程、线程、服务。

请求可以是广播请求。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本申请处理请求的装置的实施例可以应用在电子设备上。具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现中，电子设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备、互联网电视、智能机车、智能家居设备或者这些设备中的任意几种设备的组合。

装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器等可读介质中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请处理请求的装置所在电子设备的一种硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。电子设备的存储处理器可以是可执行指令的存储器；处理器可以耦合存储器，用于读取所述存储器存储的程序指令，并作为响应，执行如下操作：当接收到请求方的请求时，根据请求方的性能信用等级将所述请求存储到相应的缓冲区；所述性能信用等级基于请求方的性能参数设定，不同的缓冲区用于存储不同性能信用等级的请求方的请求；以及基于预定策略对缓冲区中的请求进行处理。

在其他实施例中，处理器所执行的操作可以参考上文方法实施例中相关的描述，在此不予赘述。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。