一种浏览器协同方法、系统、终端及存储介质

技术领域

本发明涉及软件技术领域，尤其涉及一种浏览器协同方法、系统、终端及存储介质。

背景技术

浏览器是用来检索、展示以及传递Web信息资源的应用程序。Web信息资源由统一资源标识符(Uniform Resource Identifier，URI)所标记，它是一张网页、一张图片、一段视频或者任何在Web上所呈现的内容。使用者可以借助超级链接(Hyperlinks)，通过浏览器浏览互相关联的信息。

随着目前网络界面的内容复杂度的增加，网站内容越来越丰富，向用户提供的信息也越来越多，但是由于浏览器对并发请求数量、内存占用等是有限制的。这也导致了在打开一些复杂页面时出现页面卡顿，白屏时间长、用户等待响应时间长等问题。为了解决该技术问题现提出一种浏览器协同方法、系统、终端及存储介质。

发明内容

为了解决上述现有技术中存在的技术问题，本发明提供了一种浏览器协同方法、系统、终端及存储介质，通过获取第一浏览器的运行状态，及时的调用其他第二浏览器缓解第一浏览器的压力，可明显缓解卡顿问题，有效提升浏览器工作效率。可减少用户等待时间，提升用户在浏览大数据量时的用户体验。

为实现上述目的，本发明实施例提供了如下的技术方案：

第一方面，在本发明提供的一个实施例中，提供了浏览器协同方法，该方法包括以下步骤：

获取客户端中第一浏览器的运行内存状态；

根据运行内存状态判断第一浏览器的运行内存是否超过设定阈值，若超过设定阈值，则开启第二浏览器，将第一浏览器中部分任务分配给第二浏览器执行；

将第二浏览器运行后的部分结果返回给第一浏览器，将部分结果与第一浏览器本地结果进行结合获得执行结果；

将完成任务后的第一浏览器实例和第二浏览器实例加入至内核池中，若内核池处于满负载状态，则将完成任务后的第一浏览器实例和第二浏览器实例进行销毁。

作为本发明的进一步方案，所述获取客户端中第一浏览器的运行内存状态，分为主动监控和浏览器实例主动上报。

作为本发明的进一步方案，所述主动监控为主动获取第一浏览器的运行内存状态。

作为本发明的进一步方案，所述浏览器实例主动上报为第一浏览器自行反馈其自身运行状态。

作为本发明的进一步方案，所述部分任务包括网页界面渲染。

作为本发明的进一步方案，第一浏览器中部分任务分配给第二浏览器执行，包括：

将多个要渲染组件的分发给多个新启动的第二浏览器内核实例，在各个第二浏览器内核实例内完成DOM树和CSS树的渲染和合成。

作为本发明的进一步方案，若第一浏览器自行反馈其自身运行状态，则基于第一浏览器发出的阻塞请求，启动第二浏览器。

第二方面，在本发明提供的又一个实施例中，提供了浏览器协同系统，该系统包括：

状态获取模块、状态判断模块、执行模块、后处理模块和浏览器内核池；

所述状态获取模块，用于获取客户端中第一浏览器的运行内存状；

所述状态判断模块，根据运行内存状态判断第一浏览器的运行内存是否超过设定阈值，若超过设定阈值，则开启第二浏览器，将第一浏览器中部分任务分配给第二浏览器执行；

所述执行模块，用于将第二浏览器运行后的部分结果返回给第一浏览器，将部分结果与第一浏览器本地结果进行结合获得执行结果；

所述后处理模块，用于将完成任务后的第一浏览器实例和第二浏览器实例加入至内核池中，若内核池处于满负载状态，则将完成任务后的第一浏览器实例和第二浏览器实例进行销毁；

所述浏览器内核池，用于储存浏览器内核。

第三方面，在本发明提供的又一个实施例中，提供了一种终端，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器加载并执行所述计算机程序时实现浏览器协同方法的步骤。

第四方面，在本发明提供的再一个实施例中，提供了一种存储介质，存储有计算机程序，所述计算机程序被处理器加载并执行时实现所述浏览器协同方法的步骤。

本发明提供的技术方案，具有如下有益效果：

本发明提供的浏览器协同方法、系统、终端及存储介质，通过获取第一浏览器的运行状态，及时的调用其他第二浏览器缓解第一浏览器的压力，可明显缓解卡顿问题，有效提升浏览器工作效率，可减少用户等待时间，提升用户在浏览大数据量时的用户体验。

本发明的这些方面或其他方面在以下实施例的描述中会更加简明易懂。应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

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

图1为本发明一个实施例的浏览器协同方法的流程图；

图2为本发明一个实施例的浏览器协同示例具体流程图；

图3为本发明一个实施例的一种终端的结构框图。

图中：状态获取模块-100、状态判断模块-200、执行模块-300、后处理模块-400、浏览器内核池-500、处理器-AA1、通信接口-AA2、存储器-AA3、通信总线-AA4。

具体实施方式

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

附图中所示的流程图仅是示例说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解、组合或部分合并，因此实际执行的顺序有可能根据实际情况改变。

应当理解，在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

具体地，下面结合附图，对本发明实施例作进一步阐述。

请参阅图1，图1是本发明实施例提供的一种浏览器协同方法的流程图，如图1所示，该浏览器协同方法包括步骤S10至步骤S40。

S10、获取客户端中第一浏览器的运行内存状态。

在本发明的实施例中，所述获取客户端中第一浏览器的运行内存状态，分为主动监控和浏览器实例主动上报。

在本发明的实施例中，所述主动监控为主动获取第一浏览器的运行内存状态。

在本发明的实施例中，所述浏览器实例主动上报为第一浏览器自行反馈其自身运行状态。

具体的，实时监控已第一浏览器的实例的内存状态，并可以为运行内存设置阈值，当某个浏览器实例的运行内存达到预设的阈值时，表明需要减轻当前实例的压力。

由于自主监控内存存在一定的弊端，对于请求浏览器请求阻塞无法准确监控，因此实施浏览器自主上报阻塞。当第一浏览器需要发送多个网络请求时，由于浏览器自身的限制，并发请求数量可能只有几个(不同浏览器限制数量不同)，其余请求会发生阻塞。此时浏览器主动上报调度中心，把阻塞的请求发出。

S20、根据运行内存状态判断第一浏览器的运行内存是否超过设定阈值，若超过设定阈值，则开启第二浏览器，将第一浏览器中部分任务分配给第二浏览器执行。

在本发明的实施例中，所述部分任务包括网页界面渲染。

在本发明的实施例中，第一浏览器中部分任务分配给第二浏览器执行，包括：

将多个要渲染组件的分发给多个新启动的第二浏览器内核实例，在各个第二浏览器内核实例内完成DOM树和CSS树的渲染和合成。

具体的，若自动获取第一浏览器的运行内存状态：则当检测到当前第一浏览器实例内存过高时，将启动第二浏览器实例，把第一浏览器的运行压力分配到新启动的第二浏览器内核上运行。第一浏览器、新启动的第二浏览器建立通信，将第一浏览器内核的运行的部分任务分配到新启动的第一浏览器。部分任务包括但不限于需要浏览器对界面的渲染工作，例如浏览器检测到界面内存在多个要渲染的大数据量组件时，可以将多个要渲染组件的分发给多个新启动的浏览器内核实例，在各个浏览器内核实例内完成DOM树和CSS树的渲染和合成。

在本发明的实施例中，若第一浏览器自行反馈其自身运行状态，则基于第一浏览器发出的阻塞请求，启动第二浏览器。

S30、将第二浏览器运行后的部分结果返回给第一浏览器，将部分结果与第一浏览器本地结果进行结合获得执行结果。

第一浏览器与第二浏览器之间具有通信通道。

第二浏览器根据阻塞请求返回部分结果，然后将部分结果压缩打包。

第一浏览器将执行结果展示给用户，从而完成了一个完整任务的运行。

S40、将完成任务后的第一浏览器实例和第二浏览器实例加入至内核池中，若内核池处于满负载状态，则将完成任务后的第一浏览器实例和第二浏览器实例进行销毁。

具体的，当启动的第二浏览器实例完整分配的任务后，如果仍然保持过多的浏览器内核实例会占用系统内存，而每次运行完任务都立即关闭浏览器内核实例则会加大运行负担，因此该系统采用浏览器内核池的方案，维护一个容量可控的内核池，将不活跃的内核实例加入到内核池内，需要启动内核时，直接从内核池里面取，免去了每次启动销毁内核的压力，使系统运行更加顺畅。只有当要启动或销毁的内核数量超过内核池数量时，对当前无任务执行的浏览器实例执行关闭指令以释放其占用的系统空间；继续监控存活的浏览器实例。

本发明通过获取第一浏览器的运行状态，及时的调用其他第二浏览器缓解第一浏览器的压力，可明显缓解卡顿问题，有效提升浏览器工作效率。可减少用户等待时间，提升用户在浏览大数据量时的用户体验。

应该理解的是，上述虽然是按照某一顺序描述的，但是这些步骤并不是必然按照上述顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，本实施例的一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，参见图2所示，在本发明的实施例中还提供了浏览器协同系统，该系统包括状态获取模块100、状态判断模块200、执行模块300、后处理模块400和浏览器内核池500。

所述状态获取模块100，用于获取客户端中第一浏览器的运行内存状态。

在本发明的实施例中，所述主动监控为主动获取第一浏览器的运行内存状态。

在本发明的实施例中，所述浏览器实例主动上报为第一浏览器自行反馈其自身运行状态。

在本发明的实施例中，所述状态获取模块100可以通过主动监控和浏览器实例主动上报获取客户端中第一浏览器的运行内存状态。

所述状态判断模块200，根据运行内存状态判断第一浏览器的运行内存是否超过设定阈值，若超过设定阈值，则开启第二浏览器，将第一浏览器中部分任务分配给第二浏览器执行。

在本发明的实施例中，所述部分任务包括网页界面渲染。

在本发明的实施例中，第一浏览器中部分任务分配给第二浏览器执行，包括：

将多个要渲染组件的分发给多个新启动的第二浏览器内核实例，在各个第二浏览器内核实例内完成DOM树和CSS树的渲染和合成。

具体的，若自动获取第一浏览器的运行内存状态：则当检测到当前第一浏览器实例内存过高时，将启动第二浏览器实例，把第一浏览器的运行压力分配到新启动的第二浏览器内核上运行。第一浏览器、新启动的第二浏览器建立通信，将第一浏览器内核的运行的部分任务分配到新启动的第一浏览器。部分任务包括但不限于需要浏览器对界面的渲染工作，例如浏览器检测到界面内存在多个要渲染的大数据量组件时，可以将多个要渲染组件的分发给多个新启动的浏览器内核实例，在各个浏览器内核实例内完成DOM树和CSS树的渲染和合成。

在本发明的实施例中，若第一浏览器自行反馈其自身运行状态，则基于第一浏览器发出的阻塞请求，启动第二浏览器。

所述执行模块300，用于将第二浏览器运行后的部分结果返回给第一浏览器，将部分结果与第一浏览器本地结果进行结合获得执行结果。

第一浏览器与第二浏览器之间具有通信通道。

第二浏览器根据阻塞请求返回部分结果，然后将部分结果压缩打包。

第一浏览器将执行结果展示给用户，从而完成了一个完整任务的运行。

所述后处理模块400，用于将完成任务后的第一浏览器实例和第二浏览器实例加入至内核池中，若内核池处于满负载状态，则将完成任务后的第一浏览器实例和第二浏览器实例进行销毁。

具体的，当启动的第二浏览器实例完整分配的任务后，如果仍然保持过多的浏览器内核实例会占用系统内存，而每次运行完任务都立即关闭浏览器内核实例则会加大运行负担，因此该系统采用浏览器内核池的方案，维护一个容量可控的内核池，将不活跃的内核实例加入到内核池内，需要启动内核时，直接从内核池里面取，免去了每次启动销毁内核的压力，使系统运行更加顺畅。只有当要启动或销毁的内核数量超过内核池数量时，对当前无任务执行的浏览器实例执行关闭指令以释放其占用的系统空间；继续监控存活的浏览器实例。

所述浏览器内核池500，用于储存浏览器内核。

本发明通过获取第一浏览器的运行状态，及时的调用其他第二浏览器缓解第一浏览器的压力，可明显缓解卡顿问题，有效提升浏览器工作效率。可减少用户等待时间，提升用户在浏览大数据量时的用户体验。

在一个实施例中，参见图3所示，在本发明的实施例中还提供了一种终端，包括处理器AA1、通信接口AA2、存储器AA3和通信总线AA4，其中，处理器AA1，通信接口AA2，存储器AA3通过通信总线AA4完成相互间的通信。

存储器AA3，用于存放计算机程序；

处理器AA1，用于执行存储器AA3上所存放的计算机程序时，执行所述的浏览器协同方法，该处理器执行指令时实现上述方法实施例中的步骤：

S10、获取客户端中第一浏览器的运行内存状态。

在本发明的实施例中，所述获取客户端中第一浏览器的运行内存状态，分为主动监控和浏览器实例主动上报。

在本发明的实施例中，所述主动监控为主动获取第一浏览器的运行内存状态。

在本发明的实施例中，所述浏览器实例主动上报为第一浏览器自行反馈其自身运行状态。

具体的，实时监控已第一浏览器的实例的内存状态，并可以为运行内存设置阈值，当某个浏览器实例的运行内存达到预设的阈值时，表明需要减轻当前实例的压力。

由于自主监控内存存在一定的弊端，对于请求浏览器请求阻塞无法准确监控，因此实施浏览器自主上报阻塞。当第一浏览器需要发送多个网络请求时，由于浏览器自身的限制，并发请求数量可能只有几个(不同浏览器限制数量不同)，其余请求会发生阻塞。此时浏览器主动上报调度中心，把阻塞的请求发出。

S20、根据运行内存状态判断第一浏览器的运行内存是否超过设定阈值，若超过设定阈值，则开启第二浏览器，将第一浏览器中部分任务分配给第二浏览器执行。

在本发明的实施例中，所述部分任务包括网页界面渲染。

在本发明的实施例中，第一浏览器中部分任务分配给第二浏览器执行，包括：

将多个要渲染组件的分发给多个新启动的第二浏览器内核实例，在各个第二浏览器内核实例内完成DOM树和CSS树的渲染和合成。

具体的，若自动获取第一浏览器的运行内存状态：则当检测到当前第一浏览器实例内存过高时，将启动第二浏览器实例，把第一浏览器的运行压力分配到新启动的第二浏览器内核上运行。第一浏览器、新启动的第二浏览器建立通信，将第一浏览器内核的运行的部分任务分配到新启动的第一浏览器。部分任务包括但不限于需要浏览器对界面的渲染工作，例如浏览器检测到界面内存在多个要渲染的大数据量组件时，可以将多个要渲染组件的分发给多个新启动的浏览器内核实例，在各个浏览器内核实例内完成DOM树和CSS树的渲染和合成。

在本发明的实施例中，若第一浏览器自行反馈其自身运行状态，则基于第一浏览器发出的阻塞请求，启动第二浏览器。

S30、将第二浏览器运行后的部分结果返回给第一浏览器，将部分结果与第一浏览器本地结果进行结合获得执行结果。

第一浏览器与第二浏览器之间具有通信通道。

第二浏览器根据阻塞请求返回部分结果，然后将部分结果压缩打包。

第一浏览器将执行结果展示给用户，从而完成了一个完整任务的运行。

S40、将完成任务后的第一浏览器实例和第二浏览器实例加入至内核池中，若内核池处于满负载状态，则将完成任务后的第一浏览器实例和第二浏览器实例进行销毁。

具体的，当启动的第二浏览器实例完整分配的任务后，如果仍然保持过多的浏览器内核实例会占用系统内存，而每次运行完任务都立即关闭浏览器内核实例则会加大运行负担，因此该系统采用浏览器内核池的方案，维护一个容量可控的内核池，将不活跃的内核实例加入到内核池内，需要启动内核时，直接从内核池里面取，免去了每次启动销毁内核的压力，使系统运行更加顺畅。只有当要启动或销毁的内核数量超过内核池数量时，对当前无任务执行的浏览器实例执行关闭指令以释放其占用的系统空间；继续监控存活的浏览器实例。

本发明通过获取第一浏览器的运行状态，及时的调用其他第二浏览器缓解第一浏览器的压力，可明显缓解卡顿问题，有效提升浏览器工作效率。可减少用户等待时间，提升用户在浏览大数据量时的用户体验。

上述终端提到的通信总线可以是外设部件互连标准(PeripheralComponentInterconnect，简称PCI)总线或扩展工业标准结构(Extended IndustryStandardArchitecture，简称EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述终端与其他设备之间的通信。

存储器可以包括随机存取存储器(Random Access Memory，简称RAM)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(ApplicationSpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field－ProgrammableGate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

所述终端包括用户设备与网络设备。其中，所述用户设备包括但不限于电脑、智能手机、PDA等；所述网络设备包括但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(Cloud Computing)的由大量计算机或网络服务器构成的云，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。其中，所述终端可单独运行来实现本发明，也可接入网络并通过与网络中的其他终端的交互操作来实现本发明。其中，所述终端所处的网络包括但不限于互联网、广域网、城域网、局域网、VPN网络等。

还应当进理解，在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

在本发明的一个实施例中还提供了一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法实施例中的步骤：

S10、获取客户端中第一浏览器的运行内存状态。

在本发明的实施例中，所述获取客户端中第一浏览器的运行内存状态，分为主动监控和浏览器实例主动上报。

在本发明的实施例中，所述主动监控为主动获取第一浏览器的运行内存状态。

在本发明的实施例中，所述浏览器实例主动上报为第一浏览器自行反馈其自身运行状态。

具体的，实时监控已第一浏览器的实例的内存状态，并可以为运行内存设置阈值，当某个浏览器实例的运行内存达到预设的阈值时，表明需要减轻当前实例的压力。

由于自主监控内存存在一定的弊端，对于请求浏览器请求阻塞无法准确监控，因此实施浏览器自主上报阻塞。当第一浏览器需要发送多个网络请求时，由于浏览器自身的限制，并发请求数量可能只有几个(不同浏览器限制数量不同)，其余请求会发生阻塞。此时浏览器主动上报调度中心，把阻塞的请求发出。

S20、根据运行内存状态判断第一浏览器的运行内存是否超过设定阈值，若超过设定阈值，则开启第二浏览器，将第一浏览器中部分任务分配给第二浏览器执行。

在本发明的实施例中，所述部分任务包括网页界面渲染。

在本发明的实施例中，第一浏览器中部分任务分配给第二浏览器执行，包括：

将多个要渲染组件的分发给多个新启动的第二浏览器内核实例，在各个第二浏览器内核实例内完成DOM树和CSS树的渲染和合成。

具体的，若自动获取第一浏览器的运行内存状态：则当检测到当前第一浏览器实例内存过高时，将启动第二浏览器实例，把第一浏览器的运行压力分配到新启动的第二浏览器内核上运行。第一浏览器、新启动的第二浏览器建立通信，将第一浏览器内核的运行的部分任务分配到新启动的第一浏览器。部分任务包括但不限于需要浏览器对界面的渲染工作，例如浏览器检测到界面内存在多个要渲染的大数据量组件时，可以将多个要渲染组件的分发给多个新启动的浏览器内核实例，在各个浏览器内核实例内完成DOM树和CSS树的渲染和合成。

在本发明的实施例中，若第一浏览器自行反馈其自身运行状态，则基于第一浏览器发出的阻塞请求，启动第二浏览器。

S30、将第二浏览器运行后的部分结果返回给第一浏览器，将部分结果与第一浏览器本地结果进行结合获得执行结果。

第一浏览器与第二浏览器之间具有通信通道。

第二浏览器根据阻塞请求返回部分结果，然后将部分结果压缩打包。

第一浏览器将执行结果展示给用户，从而完成了一个完整任务的运行。

S40、将完成任务后的第一浏览器实例和第二浏览器实例加入至内核池中，若内核池处于满负载状态，则将完成任务后的第一浏览器实例和第二浏览器实例进行销毁。

具体的，当启动的第二浏览器实例完整分配的任务后，如果仍然保持过多的浏览器内核实例会占用系统内存，而每次运行完任务都立即关闭浏览器内核实例则会加大运行负担，因此该系统采用浏览器内核池的方案，维护一个容量可控的内核池，将不活跃的内核实例加入到内核池内，需要启动内核时，直接从内核池里面取，免去了每次启动销毁内核的压力，使系统运行更加顺畅。只有当要启动或销毁的内核数量超过内核池数量时，对当前无任务执行的浏览器实例执行关闭指令以释放其占用的系统空间；继续监控存活的浏览器实例。

本发明通过获取第一浏览器的运行状态，及时的调用其他第二浏览器缓解第一浏览器的压力，可明显缓解卡顿问题，有效提升浏览器工作效率。可减少用户等待时间，提升用户在浏览大数据量时的用户体验。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述方法的实施例的流程。其中，本发明所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。

应当理解的是，在本文中使用的，除非上下文清楚地支持例外情况，单数形式“一个”旨在也包括复数形式。还应当理解的是，在本文中使用的“和/或”是指包括一个或者一个以上相关联地列出的项目的任意和所有可能组合。上述本发明实施例公开实施例序号仅仅为了描述，不代表实施例的优劣。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本发明实施例公开的范围(包括权利要求)被限于这些例子；在本发明实施例的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，并存在如上的本发明实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。因此，凡在本发明实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本发明实施例的保护范围之内。