CN101510167B - 一种插件运行的方法、装置及系统 - Google Patents

Abstract

本申请公开了一种插件运行的方法，用以解决现有技术中插件运行方式带来的系统运行不稳定的问题。该方法包括：获取待运行插件的稳定级别，根据保存的稳定级别与插件运行模式的对应关系，确定获取的稳定级别对应的插件运行模式，根据确定的插件运行模式运行所述待运行插件。本申请还公开了一种插件运行的客户端和一种插件运行的系统。

Description

一种插件运行的方法、装置及系统

技术领域

本申请涉及计算机领域，尤其涉及一种插件运行的方法、装置及系统。

背景技术

随着网络技术的发展，一些网络工具已经被越来越广泛的使用了，例如：即时通讯工具已逐渐成为用户生活中不可或缺的网络工具。同时，随着这些网络工作的普遍使用，用户也对它们产生了更多的需求。在这种背景下，往往这些网络工具的开发商独自开发的软件已经不能满足用户的需求了，即这些网络工具的核心业务程序提供的服务已经不能满足客户的需求了。因此，通过制定规范，允许符合规范的程序模块，即插件，接入对应的网络工具的软件中，从而，插件和核心业务程序共同为用户提供更多的服务。这已经成为了一种不可阻挡的潮流。

目前，插件的运行模式有以下几种方法：

1、插件和核心业务程序运行于同一个进程中，这样，插件的支持体系简单，插件和核心业务程序交互效率高，但是因为在一个进程内，一旦插件出现问题，会直接导致核心业务程序出现异常或者崩溃，并且由于核心业务程序内的模块众多，较难具体定位是哪个模块或者插件出现了问题；

2、插件在核心业务程序运行进程之外运行，并且每个插件一个进程，这样，能够防止因插件导致核心业务程序被影响，但是当插件数量较多时候，将大量占用客户端的系统资源，降低用户体验；

3、插件在核心业务程序运行进程之外运行，并且全部插件运行于一个特定进程中，这样，能够节省客户端的系统资源，但是当某个插件出现异常，有可能导致所有的插件不可用或者异常，同时也不利于具体定位是哪个插件出现了问题。

由此可见，现有的插件运行方式对插件稳定性要求比较高，或者占用的客户端资源比较多。但是，随着插件开发者的增多，其技术水平良莠不齐，插件的稳定性也很难保证，通常都不如核心业务程序，插件会经常崩溃或者出现故障，这样，采用上述方法1或3，会因为个别插件运行不稳定，从而导致核心业务程序或者所有插件运行不正常。同时客户端的资源都是有限的，采用上述方法2会过多的占用客户端的资源，从而也会导致客户端的运行速度缓慢，甚至会导致客户端系统崩溃。

发明内容

有鉴于此，本申请实施例提供一种插件运行的方法，用以解决现有技术中插件运行方式带来的系统运行不稳定的问题。

本申请实施例提供的一种插件运行的方法，包括：

获取待运行插件的稳定级别；

根据保存的稳定级别与插件运行模式的对应关系，确定获取的稳定级别对应的插件运行模式；

根据确定的插件运行模式运行所述待运行插件。

本申请实施例提供的一种插件运行的客户端，包括：

第一获取单元，用于获取待运行插件的稳定级别；

存储单元，用于保存稳定级别与运行模式的对应关系；

第一确定单元，用于根据存储单元保存的稳定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式；

运行单元，用于根据确定的插件运行模式运行所述待运行插件。

本申请实施例提供的一种插件运行的系统，包括：

客户端，用于从服务器保存的插件的稳定级别中，获取待运行插件的稳定级别，根据保存的稳定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式，根据确定的插件运行模式运行所述待运行插件；

服务器，用于保存插件的稳定级别。

本申请实施例中，获取待运行插件的稳定级别，根据保存的稳定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式，根据确定的插件运行模式运行所述待运行插件，这样，根据插件的不同的稳定级别，选择不同的插件运行模式，从而可以提高系统运行的稳定性，也可以有效控制插件对资源的占用。

附图说明

图1为本申请实施例插件运行的流程图；

图2为本申请实施例插件运行的具体方法流程图；

图3为本申请实施例获取插件运行的异常信息流程图；

图4为本申请实施例调整插件稳定级别的流程图；

图5为本申请实施例运行插件的客户端的结构图；

图6为本申请实施例运行插件的系统的架构图。

具体实施方式

本申请实施例中，当在客户端上运行的网络工具的核心业务程序提供的业务不能满足用户的需求时，需要运行该网络工具的插件来满足用户的需求，其插件运行的过程，参见图1，具体包括：

步骤101：获取待运行插件的稳定级别。

这里，可以从服务器保存的插件的稳定级别中，获取待运行插件的稳定级别。也可以从本地保存的插件的稳定级别中，获取待运行插件的稳定级别。插件的稳定级别可以根据设定时间内插件的运行状态进行划分，例如，稳定级别划分为三个级别，分别为稳定，普通，不稳定。这里，设定一个上限阈值，一个下限阈值，当设定时间内，该插件运行出现异常的次数大于等于上限阈值时，则该插件的稳定级别为不稳定；当设定时间内，该插件运行出现异常的次数小于等于下限阈值时，则该插件的稳定级别为稳定，当设定时间内，该插件运行出现异常的次数处于下限阈值与上限阈值之间时，则该插件的稳定级别为普通。当然，稳定级别也可以只划分为两个级别，稳定与普通，那么只需设定一个阈值，当设定时间内，该插件运行出现异常的次数大于该阈值时，则该插件的稳定级别为普通，否则为稳定。也可以将稳定级别划分为四个级别，稳定，比较稳定，普通和不稳定，那么就需要设定三个阈值，第一阈值，第二阈值，第三阈值，其大小异常递减，那么，当设定时间内，该插件运行出现异常的次数大于等于第一阈值时，则该插件的稳定级别为不稳定；当设定时间内，该插件运行出现异常的次数大于等于第二阈值，且小于第一阈值时，则该插件的稳定级别为普通；当设定时间内，该插件运行出现异常的次数大于等于第三阈值，且小于第二阈值时，则该插件的稳定级别为比较稳定；当设定时间内，该插件运行出现异常的次数小于第三阈值时，则该插件的稳定级别为稳定。

这里，服务器或本地客户端可以建立插件与稳定级别的对应的关系，当确定了待运行插件的插件信息后，例如标识信息，就可以获得该待运行插件的稳定级别。

步骤102：根据保存的稳定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式。

这里，可以预先设置稳定级别与运行模式的对应关系，并在客户端的存储单元中进行保存。其中，插件运行模式包括：针对插件的不同稳定级别，启动不同的加载器进程运行所述待运行插件，稳定级别与插件运行模式的对应关系包括：

稳定级别为稳定时，插件运行模式为放入共享的加载器进程中运行插件；稳定级别为普通时，插件运行模式为启动独立的加载器进程运行插件。其中，加载器进程为可执行的程序，可以由客户端上运行的网络工具的的核心服务程序创建，也可以由客户端中的其他程序创建，包括共享的加载器进程和独立的加载器进程。共享的加载器进程可以运行多个插件，独立的加载器进程只运行一个插件。这样，多个稳定级别为稳定的插件运行在一个共享的加载器进程中，可以减少对客户端资源的占用；稳定级别为普通的插件在独立的加载器进程中运行，可以减少该插件对核心业务程序，以及稳定级别为稳定的插件的影响，提高系统的稳定性。

这里，当稳定级别包括稳定，普通与不稳定时，稳定级别与插件运行模式的对应关系还包括：

稳定级别为不稳定时，插件运行模式为放弃运行插件，或者通知用户选择是否运行该插件。当用户选择运行时，启动独立的加载器运行该插件；当用户选择不运行时，放弃运行插件。

当稳定级别包括稳定，比较稳定、普通与不稳定时，稳定级别与插件运行模式的对应关系还包括：

稳定级别为比较稳定时，插件运行模式为放入共享的加载器进程中运行插件，这里，共享的加载器可以是与稳定级别为稳定对应的共享的加载器，也可以是另外一个共享的加载器。

这样，步骤101中获取的待运行插件的稳定级别不同，其运行模式就不同。

步骤103：根据步骤102确定的插件运行模式运行待运行插件。

本实施例中，插件的运行过程中，可能会出现异常，因此，本实施例插件运行的方法还包括：当插件运行异常时，客户端获取插件运行的异常信息，保存该异常信息，或者将该异常信息发送给服务器进行保存，其中，所述异常信息包括：异常原因，以及运行的插件的插件信息。异常原因又具体包括：加载器进程崩溃，插件执行线程僵死，或插件长时间占用过高的内存或者处理器。插件信息又具体包括：插件的标识信息，名称，版本等等。

这样，客户端或者服务器就可以根据插件运行的异常信息确定插件的稳定级别，并可以定期进行调整，也就是根据保存的异常信息，确定插件在设定时间内出现的异常次数，并根据所述异常次数调整所述插件的稳定级别。其具体的调整过程包括：当设定时间触发后，也就是设定时间到达后，获取所述设定时间内使用次数超过阈值的插件的插件信息，根据保存的异常信息，确定获取的插件信息在设定时间内出现的异常次数，根据所述异常次数自动调整所述插件的稳定级别。当然，为了下一次定期调整，需将异常次数以及使用次数进行复位。这里，还可以人工进行调整，客服人员统计一定时间内插件的运行状态，当设定时间内，插件运行异常的次数超过设定值时，修改该插件的稳定级别。

在客户端运行网络工具的插件运行过程可以由该网络工具的核心业务程序来管理，也可以由客户端中其他的程序来管理。其中，本实施例中，核心业务程序不仅提供该网络工具的核心业务，也包括管理插件的程序。加载器进程是客户端中的独立的可执行程序，核心业务程序也可以是一个加载进程。

下面结合说明书附图对本申请实施例作进一步详细描述，参见图2，插件运行的具体过程如下：

步骤201：核心业务程序获取待运行插件的稳定级别。

这里，当核心业务程序向服务器请求获取待运行插件的稳定级别时，服务器根据该请求，获取该待运行插件的插件信息，例如标识信息，在保存的插件与插件的稳定级别的对应关系中，查询该标识信息的对应的待运行插件的稳定级别，将查询到的稳定级别返回给核心业务程序，并将记录的待运行插件的使用次数递加。其中，稳定级别包括稳定，普通和不稳定。

当核心业务程序从本地客户端获取待运行插件的稳定级别时，客户端在保存的插件的稳定级别中，查询该待运行插件的稳定级别，将查询到的稳定级别返回给核心业务程序，并将记录的待运行插件的使用次数递加。同样，稳定级别包括稳定，普通和不稳定。

步骤202：核心业务程序判断待运行插件的稳定级别是为稳定，普通，或不稳定，当稳定级别为稳定时，执行步骤203；当稳定级别为普通时，执行步骤206；当稳定级别为不稳定时，执行步骤207。

步骤203：核心业务程序判断共享的加载器进程是否存在，当存在时，执行步骤205，当不存在时，执行步骤204。

步骤204：核心业务程序创建一个共享的加载器进程。

步骤205：共享的加载器进程运行待运行的插件。

步骤206：核心业务程序为稳定级别为普通的待运行插件建立一个独立的加载进程，该加载进程运行待运行的插件。

步骤207：插件运行过程结束。

上述实施例中，当不存在共享的加载器进程时，步骤204创建了一个共享的加载器进程，这里，也可以直接把核心业务程序作为共享的加载器，在核心业务程序进程中运行稳定级别为稳定的插件。

本申请实施例中，当插件运行出现异常时，客户端还可以获取该插件的异常信息，并保存这些异常信息，或者发送给服务器。插件都是在加载器进程中运行的，因此，插件运行出现异常，也就是加载器进程出现异常时，客户端获取到加载器进程的异常信息，并保存这些异常信息，或者发送给服务器，参见图3，其体过程如下：

步骤301：获取加载器进程的异常信息，异常信息包括：加载器进程的异常原因，以及在该加载器进程中运行的插件的插件信息。

这里，当加载器进程为独立的加载器进程时，则异常信息包括：异常原因，以及在该独立的加载器进程中运行的插件的插件信息，当加载器进程为共享的加载器进程时，则异常信息包括：异常原因，以及在该共享的加载器进程中运行的所有插件的插件信息。异常信息还可以包括：加载器进程的异常上下文。这里，异常上下文包括：加载器进程的内存影像，函数堆栈上下文，加载器进程加载的插件等技术信息。通过对这些信息的分析可以知道上下文对应的时刻，加载器进程内所运行的插件，当前正在执行的指令等等。

客户端可以通过检测获得加载器进程的异常原因。异常原因有可能是加载器进程崩溃了，插件执行线程僵死了，或者插件长时间占用过高的内存或者处理器。这里，加载器进程可以自检发现异常原因，也可以由客户端的其他检查程序对加载器进程进行检测，发现异常原因。

客户端还可以通过周期性的心跳报告的形式，得到加载器进程的异常信息，即加载器进程周期性向核心业务程序发送一个消息，就是所谓的心跳，当客户端核心业务程序在设定时间内没有收到加载器进程的心跳报告，则表明加载器进程出现异常。

步骤302：将获取到的异常信息，发送给服务器。

这里，客户端可以直接将获得的异常信息发送给服务器，也可以对设定时间内的异常信息进行处理，例如：统计设定时间内每个插件出现的异常次数，然后再发送给服务器。

本步骤当然也可是只是保存获取到的异常信息，并不发送给服务器，直接对对设定时间内的异常信息进行处理。

客户端或者服务器收集到异常信息后，可以根据收集到的异常信息，定期对插件的稳定级别进行调整，参见图4，定期调整任一插件的稳定级别的过程如下：

步骤401：到达设定的时间后，获取在该设定时间内插件的使用次数。

在设定的时间内，当客户端每访问一次服务器，获取待运行插件的稳定等级时，服务器就会递加一次该待运行插件的使用次数，这样，服务器会保存了每一个插件在设定时间内的使用次数。或者，

当客户端每次从本地获取待运行插件的稳定等级时，就会递加一次该待运行插件的使用次数，这样，客户端会保存了每一个插件在设定时间内的使用次数。

这里，本实施例中需调整的插件在设定的一个月内运行了120次。

步骤402：将获取的使用次数与设定的阈值相比较，当获取的使用次数大于等于设定的阈值时，执行步骤403，否则，流程结束，该插件使用率不高，不需要调整稳定级别。

步骤403：根据保存的异常信息，获取该插件出现的异常次数。

客户端或服务器每次获取的异常信息中包括了插件信息，因此，可以查询该插件的插件信息在设定的时间内的异常信息中出现的异常次数，例如：一个月内出现了30次。

步骤404：根据获取的该插件的使用次数以及异常次数，调整该插件的稳定级别。

这里，稳定级别划分为三个级别，分别为稳定，普通，不稳定。设定一个上限阈值，一个下限阈值，例如上限阈值为20％，下限阈值为5％，当异常次数除以使用次数得到的值大于等于上限阈值时，则该插件的稳定级别为不稳定；当异常次数除以使用次数得到的值小于等于下限阈值时，则该插件的稳定级别为稳定，当异常次数除以使用次数得到的值处于下限阈值与上限阈值之间时，则该插件的稳定级别为普通。例如该插件初始的稳定级别为普通，而在本次调整周期内，即设定的一个月内，使用次数是120次，异常次数为30次，那么，30/120＝25％，25％＞20％，则将该插件的稳定级别调整为不稳定。

当然，稳定级别也可以只划分为两个级别，稳定与普通，那么只需设定一个阈值，当异常次数除以使用次数得到的值大于该阈值时，则该插件的稳定级别为普通，否则为稳定。也可以将稳定级别划分为四个级别，稳定，比较稳定，普通和不稳定，那么就需要设定三个阈值，第一阈值，第二阈值，第三阈值，其大小异常递减，那么，当异常次数除以使用次数得到的值大于等于第一阈值时，则该插件的稳定级别为不稳定；当异常次数除以使用次数得到的值大于等于第二阈值，且小于第一阈值时，则该插件的稳定级别为普通；当异常次数除以使用次数得到的值大于等于第三阈值，且小于第二阈值时，则该插件的稳定级别为比较稳定；当异常次数除以使用次数得到的值小于第三阈值时，则该插件的稳定级别为稳定。

步骤405：将使用次数与异常次数复位，即将记录的使用次数与异常次数清零，重新开始下一个调整周期内的计数。

在本申请实施例中，插件的稳定级别可以划分为多种，那么客户端在运行插件的过程中，可以使用多个共享的加载器进程，例如，稳定级别分为：稳定、比较稳定、普通、不稳定，那么，可以将所有稳定级别为稳定的插件放入一个共享的加载器进程中运行，将所有稳定级别为比较稳定的插件放入另一个共享的加载器进程中运行。则，客户端上保存的稳定级别与插件运行模式的对应关系包括：

当获取的稳定级别为稳定时，插件运行模式为放入第一共享的加载器进程中运行插件；当获取的稳定级别为比较稳定时，插件运行模式为放入第二共享的加载器进程中运行插件；当获取的稳定级别为普通时，插件运行模式为启动独立的加载器进程运行插件；当获取的稳定级别为不稳定时，插件运行模式为放弃运行插件。

根据本申请实施例上述方法可以构建一种插件运行的客户端，参见图5，包括：第一获取单元510、存储单元520、第一确定单元530以及运行单元540。其中，

第一获取单元510，用于获取待运行插件的稳定级别。

存储单元520，用于保存稳定级别与运行模式的对应关系。

第一确定单元530，用于根据存储单元520保存的稳定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式。

运行单元540，用于根据确定的插件运行模式运行所述待运行插件。

上述各个单元既可以是客户端中独立的程序，也可以由核心业务程序来执行第一获取单元510、存储单元520和第一确定单元530的功能，加载器进程来执行运行单元540的功能。

进一步，客户端还包括第二获取单元，用于获取插件运行的异常信息，其中，所述异常信息包括：异常原因，以及所述插件的插件信息。则，

存储单元520，还用于存储所述异常信息。

这样，当设定时间触发后，客户端根据存储单元保存的异常信息，确定插件在设定时间内出现的异常次数，并根据所述异常次数调整所述插件的稳定级别。具体可以为获取所述设定时间内使用次数超过阈值的插件的插件信息，根据保存的异常信息，确定获取的插件信息在设定时间内出现的异常次数，根据所述异常次数调整所述插件的稳定级别，并将所述异常次数以及使用次数进行复位。

当然，客户端还可以包括发送单元，用于发送第二获取单元获取的异常信息。

本申请实施例中，可以从服务器保存的插件的稳定级别中，获取待运行插件的稳定级别，因此，可以构建一种插件运行的系统，包括参见图6，包括客户端100和服务器200。

客户端100，用于从服务器200保存的插件的稳定级别中，获取待运行插件的稳定级别，根据保存的稳定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式，根据确定的插件运行模式运行所述待运行插件。

服务器200，用于保存插件的稳定级别。

因此，客户端100包括：第一获取单元110、存储单元120、第一确定单元130以及运行单元140。其中，

第一获取单元110，用于获取待运行插件的稳定级别。

存储单元120，用于保存稳定级别与运行模式的对应关系。

第一确定单元130，用于根据存储单元120保存的稳定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式。

运行单元140，用于根据确定的插件运行模式运行所述待运行插件。

还包括第二获取单元150，用于获取插件运行的异常信息；则，存储单元120，还用于存储所述异常信息。

当客户端100运行插件出现异常时，客户端100还包括发送单元160，用于获取该插件的异常信息，将异常信息发送给服务器200，其中，异常信息包括：异常原因，以及所述插件的插件信息。

进一步，服务器200包括存储单元210，不仅用于保存插件的稳定级别，还用于接收并保存异常信息。

服务200还包括调整单元220，用于当设定时间触发后，根据存储单元210保存的异常信息，确定插件在设定时间内出现异常的数量，根据所述数量调整所述插件的稳定级别。

为了描述的方便，以上所述客户端和服务器的各部分以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件或硬件中实现。

综上所述，本申请实施例中，获取待运行插件的稳定级别，根据保存的稳定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式，根据确定的插件运行模式运行所述待运行插件，这样，将不同稳定级别的插件放入不同的加载器进程中运行，可以避免由于插件的不稳定造成核心业务程序出现故障的状况，提高了网络工具的稳定性。将稳定性较高的、且属于同一稳定级别的插件放入一个共享的加载器中运行，可以节省客户端的系统资源，提高了客户端系统的稳定性。并且通过收集插件的异常信息，动态调整插件的稳定级别，可以将不稳定的插件淘汰，提高了用户的体验。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (9)

1.一种插件运行的方法，其特征在于，包括：

从服务器保存的插件的稳定级别中，获取待运行插件的稳定级别；或，从本地保存的插件的稳定级别中，获取待运行插件的稳定级别；

根据保存的稳定级别与插件运行模式的对应关系，确定获取的稳定级别对应的插件运行模式；

根据确定的插件运行模式运行所述待运行插件；

当插件运行异常时，获取并保存所述插件运行的异常信息；

根据保存的异常信息，确定插件在设定时间内出现的异常次数；

根据所述异常次数调整所述插件的稳定级别。

2.如权利要求1所述的方法，其特征在于，所述插件运行模式包括：针对插件的不同稳定级别，启动不同的加载器进程运行所述待运行插件。

3.如权利要求1或2所述的方法，其特征在于，所述插件运行模式包括：

当获取的稳定级别为稳定时，插件运行模式为放入共享的加载器进程中运行插件；

当获取的稳定级别为普通时，插件运行模式为启动独立的加载器进程运行插件。

4.如权利要求1所述的方法，其特征在于，所述异常信息包括：异常原因，以及所述插件的插件信息。

5.如权利要求1所述的方法，其特征在于，当从服务器保存的插件的稳定级别中，获取待运行插件的稳定级别时，该方法还包括：

将所述异常信息发送给服务器进行保存。

6.一种运行插件的客户端，其特征在于，包括：

第一获取单元，用于从服务器保存的插件的稳定级别中，获取待运行插件的稳定级别；或，从本地保存的插件的稳定级别中，获取待运行插件的稳定级别；

存储单元，用于保存稳定级别与运行模式的对应关系；以及存储异常信息；

第一确定单元，用于根据存储单元保存的稳定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式；

运行单元，用于根据确定的插件运行模式运行所述待运行插件；

第二获取单元，用于获取插件运行的异常信息；

第二确定单元，用于根据存储单元保存的异常信息，确定插件在设定时间内出现的异常次数；

调整单元，用于根据所述异常次数调整所述插件的稳定级别。

7.如权利要求6所述的客户端，其特征在于，所述客户端还包括：

发送单元，用于向服务器发送所述异常信息。

8.一种插件运行的系统，其特征在于，包括：

客户端，用于从服务器保存的插件的稳定级别中，获取待运行插件的稳定级别，根据保存的稳定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式，根据确定的插件运行模式运行所述待运行插件；以及当插件运行异常时，获取并保存所述插件运行的异常信息；

服务器，用于接收并保存异常信息，根据保存的异常信息，确定插件出现的异常次数，根据所述异常次数调整并保存所述插件的稳定级别。

9.如权利要求8所述的系统，其特征在于，所述客户端，还用于将所述异常信息发送给服务器。