特許 CNA - 一种插件运行的方法、装置及系统 -
Google 特許検索CN A出願CN 日日日, , , .4, CN
A, CN A, CN , CN-A-, CN A, CNA, CN, CN.4, , , ,
(3) , 一种插件运行的方法、装置及系统CN
A 本申请公开了一种插件运行的方法，用以解决现有技术中插件运行方式带来的系统运行不稳定的问题。该方法包括：获取待运行插件的稳定级别，根据保存的稳定级别与插件运行模式的对应关系，确定获取的稳定级别对应的插件运行模式，根据确定的插件运行模式运行所述待运行插件。本申请还公开了一种插件运行的客户端和一种插件运行的系统。
1、一种插件运行的方法，其特征在于，包括：获取待运行插件的稳定级别；根据保存的稳定级别与插件运行模式的对应关系，确定获取的稳定级别对应的插件运行模式；根据确定的插件运行模式运行所述待运行插件。
2、 如权利要求1所述的方法，其特征在于，所述获取待运行插件的稳定级别包括：从服务器保存的插件的稳定级别中，获取待运行插件的稳定级别；或，从本地保存的插件的稳定级别中，获取待运行插件的稳定级别。
3、 如权利要求1所述的方法，其特征在于，所述插件运行模式包括：针对插件的不同稳定级别，启动不同的加载器进程运行所述待运行插件。
4、 如权利要求1或3所述的方法，其特征在于，所述插件运行模式包括：当获取的稳定级别为稳定时，插件运行模式为放入共享的加载器进程中运行插件；当获取的稳定级别为普通时，插件运行才莫式为启动独立的加载器进程运行插件。
5、 如权利要求1所述的方法，其特征在于，该方法还包括：当插件运行异常时，该方法还包括：获取并保存所述插件运行的异常信息。
6、 如权利要求5所述的方法，其特征在于，所述异常信息包括：异常原因，以及所述插件的插件信息。
7、 如权利要求5所述的方法，其特征在于，当从服务器保存的插件的稳定级别中，获取待运行插件的稳定级别时，该方法还包括：将所述异常信息发送给服务器进行保存。
8、 如权利要求2所述的方法，其特征在于，该方法还包括：将所述保存的插件的稳定级别进4于定期调整。
9、 如权利要求5或7所述的方法，其特征在于，所述定期调整包括：根据保存的异常信息，确定插件在设定时间内出现的异常次数；根据所述异常次数调整所述插件的稳定级别。
10、 一种运行插件的客户端，其特征在于，包括：第一获取单元，用于获取待运行插件的稳定级别；存储单元，用于保存稳定级别与运行模式的对应关系；第一确定单元，用于根据存储单元保存的稳定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式；运行单元，用于根据确定的插件运行模式运行所述待运行插件。
11、 如权利要求IO所述的客户端，其特征在于，所述客户端还包括：第二获取单元，用于获取插件运行的异常信息；贝'J,存储单元，还用于存储所述异常信息。
12、 如权利要求11所述的客户端，其特征在于，所述客户端还包括：第二确定单元，用于根据存储单元保存的异常信息，确定插件在设定时间内出现的异常次数；调整单元，用于根据所述异常次数调整所述插件的稳定级别。
13、 如权利要求IO所述的客户端，其特征在于，所述客户端还包括：发送单元，用于发送所述异常信息。
14、 一种插件运行的系统，其特征在于，包括：客户端，用于从服务器保存的插件的稳定级别中，获取待运行插件的稳定级别，根据保存的稳定级别与运行模式的对应关系，确定获取的稳定级別对应的插件运行冲莫式，根据确定的插件运行模式运行所述待运行插件；服务器，用于保存插件的稳定级别。
15、 如权利要求14所述的系统，其特征在于，所述客户端，还用于获取插件运行的异常信息，将所述异常信息发送给服务器。
16、如权利要求15所的系统，其特征在于，所述服务器，还用于接收并保存异常信息，根据保存的异常信息，确定插件出现的异常次数，根据所述异常次数调整所述插件的稳定级别。
一种插件运行的方法、装置及系统
本申请涉及计算机领域，尤其涉及一种插件运行的方法、装置及系统。 背景技术
随着网络技术的发展， 一些网络工具已经被越来越广泛的使用了，例如： 即时通讯工具已逐渐成为用户生活中不可或缺的网络工具。同时，随着这些网 络工作的普遍^f吏用，用户也对它们产生了更多的需求。在这种背景下，往往这 些网络工具的开发商独自开发的软件已经不能满足用户的需求了 ，即这些网络 工具的核心业务程序提供的服务已经不能满足客户的需求了。因此，通过制定 规范，允许符合规范的程序模块，即插件，接入对应的网络工具的软件中，从 而，插件和核心业务程序共同为用户提供更多的服务。这已经成为了一种不可 阻挡的潮流。
目前，插件的运行^^式有以下几种方法：
1、 插件和核心业务程序运行于同一个进程中，这样，插件的支持体系筒 单，插件和核心业务程序交互效率高，但是因为在一个进程内， 一旦插件出现 问题，会直接导致核心业务程序出现异常或者崩溃，并且由于核心业务程序内 的模块众多，较难具体定位是哪个模块或者插件出现了问题；
2、 插件在核心业务程序运行进程之外运行，并且每个插件一个进程，这 样，能够防止因插件导致核心业务程序被影响，但是当插件数量较多时候，将 大量占用客户端的系统资源，降低用户体验；
3、 插件在核心业务程序运行进程之外运行，并且全部插件运行于一个特 定进程中，这样，能够节省客户端的系统资源，但是当某个插件出现异常，有 可能导致所有的插件不可用或者异常，同时也不利于具体定位是哪个插件出现了问题。
由此可见，现有的插件运行方式对插件稳定性要求比较高，或者占用的客 户端资源比较多。但是，随着插件开发者的增多，其技术水平良莠不齐，插件 的稳定性也很难保证，通常都不如核心业务程序，插件会经常崩溃或者出现故
障，这样，采用上述方法1或3，会因为个别插件运行不稳定，从而导致核心 业务程序或者所有插件运行不正常。同时客户端的资源都是有限的，采用上述 方法2会过多的占用客户端的资源，从而也会导致客户端的运行速度緩慢，甚 至会导致客户端系统崩溃。
有鉴于此，本申请实施例提供一种插件运行的方法，用以解决现有技术中 插件运行方式带来的系统运行不稳定的问题。
本申请实施例提供的一种插件运行的方法，包括： 获取待运行插件的稳定级别；
根据保存的稳定级别与插件运行模式的对应关系，确定获取的稳定级别对 应的插件运行模式；
根据确定的插件运行模式运行所述待运行插件。
本申请实施例提供的一种插件运行的客户端，包括：
第一获取单元，用于获取待运行插件的稳定级别；
存储单元，用于保存稳定级别与运行模式的对应关系；
第一确定单元，用于根据存储单元保存的稳定级别与运行模式的对应关 系，确定获取的稳定级别对应的插件运行模式；
运行单元，用于根据确定的插件运行模式运行所述待运行插件。
本申请实施例提供的一种插件运行的系统，包括：
客户端，用于从服务器保存的插件的稳定级别中，获取待运行插件的稳定 级别，根据保存的稳定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式，根据确定的插件运行模式运行所述待运行插件； 服务器，用于保存插件的稳定级别。
本申请实施例中，获取待运行插件的稳定级别，才艮据保存的稳定级别与运 行模式的对应关系，确定获取的稳定级别对应的插件运行模式，根据确定的插 件运行模式运行所述待运行插件，这样，根据插件的不同的稳定级别，选择不 同的插件运行模式，从而可以提高系统运行的稳定性，也可以有效控制插件对 资源的占用。
图1为本申请实施例插件运行的流程图；
图2为本申请实施例插件运行的具体方法流程图；
图3为本申请实施例获取插件运行的异常信息流程图；
图4为本申请实施例调整插件稳定级别的流程图；
图5为本申请实施例运行插件的客户端的结构图；
图6为本申请实施例运行插件的系统的架构图。
具体实施方式
本申请实施例中，当在客户端上运行的网络工具的核心业务程序提供的业 务不能满足用户的需求时，需要运行该网络工具的插件来满足用户的需求，其 插件运行的过程，参见图1,具体包括：
步骤101:获取待运行插件的稳定级别。
这里，可以从服务器保存的插件的稳定级别中，获取待运行插件的稳定级 别。也可以从本地保存的插件的稳定级别中，获取待运行插件的稳定级别。插 件的稳定级别可以根据设定时间内插件的运行状态进行划分，例如，稳定级别 划分为三个级别，分别为稳定，普通，不稳定。这里，设定一个上限阈值，一 个下限阈值，当设定时间内，该插件运行出现异常的次数大于等于上限阈值时，则该插件的稳定级别为不稳定；当设定时间内，该插件运行出现异常的次数小 于等于下限阈值时，则该插件的稳定级别为稳定，当设定时间内，该插件运行 出现异常的次数处于下限阈值与上限阈值之间时，则该插件的稳定级别为普 通。当然，稳定级别也可以只划分为两个级别，稳定与普通，那么只需设定一 个阈值，当设定时间内，该插件运行出现异常的次数大于该阈值时，则该插件 的稳定级别为普通，否则为稳定。也可以将稳定级别划分为四个级别，稳定， 比较稳定，普通和不稳定，那么就需要设定三个阈值，第一阈值，第二阈值， 第三阈值，其大小异常递减，那么，当设定时间内，该插件运行出现异常的次 数大于等于第一阈值时，则该插件的稳定级别为不稳定；当设定时间内，该插 件运行出现异常的次数大于等于第二阈值，且小于第一阈值时，则该插件的稳 定级别为普通；当设定时间内，该插件运行出现异常的次数大于等于第三阈值， 且小于第二阈值时，则该插件的稳定级别为比较稳定；当设定时间内，该插件
运行出现异常的次数小于第三阈值时，则该插件的稳定级别为稳定。
这里，服务器或本地客户端可以建立插件与稳定级别的对应的关系，当确 定了待运行插件的插件信息后，例如标识信息，就可以获得该待运行插件的稳 定级别。
步骤102:根据保存的稳定级别与运行模式的对应关系，确定获取的稳定 级别对应的插件运朽-才莫式。
这里，可以预先设置稳定级别与运行模式的对应关系，并在客户端的存储 单元中进行保存。其中，插件运行模式包括：针对插件的不同稳定级别，启动 不同的加载器进程运行所述待运行插件，稳定级别与插件运行模式的对应关系 包括：
稳定级别为稳定时，插件运行模式为放入共享的加载器进程中运行插件； 稳定级别为普通时，插件运行模式为启动独立的加载器进程运行插件。其中， 加载器进程为可执行的程序，可以由客户端上运行的网络工具的的核心服务程 序创建，也可以由客户端中的其他程序创建，包括共享的加载器进程和独立的
8加载器进程。共享的加载器进程可以运行多个插件，独立的加载器进程只运行 一个插件。这样，多个稳定级别为稳定的插件运行在一个共享的加载器进程中，
可以减少对客户端资源的占用；稳定级别为普通的插件在独立的加载器进程中 运行，可以减少该插件对核心业务程序，以及稳定级别为稳定的插件的影响， 提高系统的稳定性。
这里，当稳定级别包括稳定，普通与不稳定时，稳定级别与插件运行模式 的对应关系还包括：
稳定级别为不稳定时，插件运行模式为放弃运行插件，或者通知用户选择 是否运行该插件。当用户选择运行时，启动独立的加载器运行该插件；当用户 选择不运行时，放弃运行插件。
当稳定级别包括稳定，比较稳定、普通与不稳定时，稳定级别与插件运行 模式的对应关系还包括：
稳定级别为比较稳定时，插件运行模式为放入共享的加载器进程中运行插 件，这里，共享的加载器可以是与稳定级别为稳定对应的共享的加载器，也可 以是另外一个共享的加载器。
这样，步骤101中获取的待运行插件的稳定级别不同，其运行模式就不同。
步骤103:根据步骤102确定的插件运行模式运行待运行插件。
本实施例中，插件的运行过程中，可能会出现异常，因此，本实施例插件 运行的方法还包括：当插件运行异常时，客户端获取插件运行的异常信息，保 存该异常信息，或者将该异常信息发送给服务器进行保存，其中，所述异常信 息包括：异常原因，以及运行的插件的插件信息。异常原因又具体包括：加载 器进程崩溃，插件执行线程僵死，或插件长时间占用过高的内存或者处理器。 插件信息又具体包括：插件的标识信息，名称，版本等等。
这样，客户端或者服务器就可以根据插件运行的异常信息确定插件的稳定 级别，并可以定期进行调整，也就是根据保存的异常信息，确定插件在设定时 间内出现的异常次数，并根据所述异常次数调整所述插件的稳定级别。其具体的调整过程包括：当设定时间触发后，也就是设定时间到达后，获取所述设定 时间内使用次数超过阈值的插件的插件信息，根据保存的异常信息，确定获取 的插件信息在设定时间内出现的异常次数，根据所述异常次数自动调整所述插 件的稳定级别。当然，为了下一次定期调整，需将异常次数以及使用次数进行 复位。这里，还可以人工进行调整，客月认员统计一定时间内插件的运行状态， 当设定时间内，插件运行异常的次数超过设定值时，修改该插件的稳定级别。
在客户端运行网络工具的插件运行过程可以由该网络工具的核心业务程 序来管理，也可以由客户端中其他的程序来管理。其中，本实施例中，核心业 务程序不仅提供该网络工具的核心业务，也包括管理插件的程序。加载器进程 是客户端中的独立的可执行程序，核心业务程序也可以是一个加载进程。
下面结合说明书附图对本申请实施例作进一步详细描述，参见图2，插件 运行的具体过程如下：
步骤201:核心业务程序获取待运行插件的稳定级别。
这里，当核心业务程序向服务器请求获取待运行插件的稳定级别时，服务 器根据该请求，获取该待运行插件的插件信息，例如标识信息，在保存的插件 与插件的稳定级别的对应关系中，查询该标识信息的对应的待运行插件的稳定 级别，将查询到的稳定级别返回给核心业务程序，并将记录的待运行插件的使 用次数递加。其中，稳定级别包括稳定，普通和不稳定。
当核心业务程序从本地客户端获取待运行插件的稳定级别时，客户端在保 存的插件的稳定级别中，查询该待运行插件的稳定级别，将查询到的稳定级别 返回给核心业务程序，并将记录的待运行插件的使用次数递加。同样，稳定级 别包括稳定，普通和不稳定。
步骤202:核心业务程序判断待运行插件的稳定级别是为稳定，普通，或 不稳定，当稳定级别为稳定时，执行步骤203;当稳定级别为普通时，执行步 骤206;当稳定级别为不稳定时，执行步骤207。
步骤203:核心业务程序判断共享的加载器进程是否存在，当存在时，执行步骤205,当不存在时，执行步骤204。
步骤204:核心业务程序创建一个共享的加载器进程。 步骤205:共享的加载器进程运行待运行的插件。
步骤206:核心业务程序为稳定级别为普通的待运行插件建立一个独立的 加载进程，该加载进程运行待运行的插件。 步骤207:插件运行过程结束。
上述实施例中，当不存在共享的加载器进程时，步骤204创建了一个共享 的加载器进程，这里，也可以直接把核心业务程序作为共享的加载器，在核心 业务程序进程中运行稳定级别为稳定的插件。
本申请实施例中，当插件运行出现异常时，客户端还可以获取该插件的异 常信息，并保存这些异常信息，或者发送给服务器。插件都是在加载器进程中 运行的，因此，插件运行出现异常，也就是加载器进程出现异常时，客户端获 取到加载器进程的异常信息，并保存这些异常信息，或者发送给服务器，参见 图3,其体过程如下：
步骤301:获取加载器进程的异常信息，异常信息包括：加载器进程的异 常原因，以及在该加载器进程中运行的插件的插件信息。
这里，当加载器进程为独立的加载器进程时，则异常信息包括：异常原因， 以及在该独立的加载器进程中运行的插件的插件信息，当加载器进程为共享的 加载器进程时，则异常信息包括：异常原因，以及在该共享的加载器进程中运 行的所有插件的插件信息。异常信息还可以包括：加载器进程的异常上下文。 这里，异常上下文包括：加载器进程的内存影像，函数堆栈上下文，加载器进 程加载的插件等技术信息。通过对这些信息的分析可以知道上下文对应的时 刻，加载器进程内所运行的插件，当前正在执行的指令等等。
客户端可以通过4企测获得加载器进程的异常原因。异常原因有可能是加载 器进程崩溃了，插件执行线程僵死了，或者插件长时间占用过高的内存或者处 理器。这里，加载器进程可以自检发现异常原因，也可以由客户端的其他检查程序对加载器进程进行检测，发现异常原因。
客户端还可以通过周期性的心跳报告的形式，得到加载器进程的异常信 息，即加载器进程周期性向核心业务程序发送一个消息，就是所谓的心跳，当 客户端核心业务程序在设定时间内没有收到加栽器进程的心跳报告，则表明加 载器进程出现异常。
步骤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,用于根据确定的插件运行^t式运行所述待运行插件。 上述各个单元既可以是客户端中独立的程序，也可以由核心业务程序来执
行第一获取单元510、存储单元520和第一确定单元530的功能，加载器进程 来执行运行单元540的功能。
进一步，客户端还包括第二获取单元，用于获取插件运行的异常信息，其 中，所述异常信息包括：异常原因，以及所述插件的插件信息。贝'J，
存储单元520，还用于存储所述异常信息。
这样，当设定时间触发后，客户端根据存储单元保存的异常信息，确定插 件在设定时间内出现的异常次数，并根据所述异常次数调整所述插件的稳定级别。具体可以为获取所述设定时间内使用次数超过阈值的插件的插件信息，根 据保存的异常信息，f角定获取的插件信息在设定时间内出现的异常次数，根据 所述异常次数调整所述插件的稳定级别，并将所述异常次数以及使用次数进行 复位。
当然，客户端还可以包括发送单元，用于发送第二获取单元获取的异常信
本申请实施例中，可以从服务器保存的插件的稳定级别中，获取待运行插
件的稳定级别，因此，可以构建一种插件运行的系统，包括参见图6,包括客 户端100和服务器200。
客户端100，用于从服务器200保存的插件的稳定级别中，获取待运行插 件的稳定级别，才艮据保存的稳定级别与运行^^莫式的对应关系，确定获取的稳定 级别对应的插件运行才莫式，根据确定的插件运行冲莫式运行所述待运行插件。
服务器200，用于保存插件的稳定级别。
因此，客户端100包括：第一获取单元110、存储单元120、第一确定单
元130以及运行单元140。其中，
第一获取单元110，用于获取待运行插件的稳定级别。 存储单元120,用于保存稳定级别与运行模式的对应关系。 第一确定单元130,用于根据存储单元120保存的稳定级别与运行模式的
对应关系，确定获取的稳定级别对应的插件运行^^莫式。
运行单元140,用于根据确定的插件运行模式运行所述待运行插件。 还包括第二获取单元150，用于获取插件运行的异常信息；则，存储单元
120,还用于存储所述异常信息。
当客户端IOO运行插件出现异常时，客户端IOO还包括发送单元160，用
于获取该插件的异常信息，将异常信息发送给服务器200,其中，异常信息包
括：异常原因，以及所述插件的插件信息。
进一步，服务器200包括存储单元210，不仅用于保存插件的稳定级别，还用于接收并保存异常信息。
服务200还包括调整单元220,用于当设定时间触发后，根据存储单元210 保存的异常信息，确定插件在设定时间内出现异常的数量，根据所述数量调整 所述插件的稳定级别。
为了描述的方便，以上所述客户端和服务器的各部分以功能分为各种单元 分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件或 硬件中实现。
综上所述，本申请实施例中，获取待运行插件的稳定级别，根据保存的稳 定级别与运行模式的对应关系，确定获取的稳定级别对应的插件运行模式，根 据确定的插件运行模式运行所述待运行插件，这样，将不同稳定级别的插件放 入不同的加载器进程中运行，可以避免由于插件的不稳定造成核心业务程序出 现故障的状况，提高了网络工具的稳定性。将稳定性较高的、且属于同一稳定 级别的插件放入一个共享的加载器中运行，可以节省客户端的系统资源，提高 了客户端系统的稳定性。并且通过收集插件的异常信息，动态调整插件的稳定 级别，可以将不稳定的插件淘汰，提高了用户的体验。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申 请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及 其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
北京书生国际信息技术有限公司一种实现插件的方法和装置 国際特許分類, ,
欧州特許分類G06F11/07P4C, G06F11/07P1AREGReference to a national codeRef country code: HKRef legal event code: DERef document number: 1133713Country of ref document: HKC10Request of examination as to substanceC06Publication回転&2012 Google