CN108563472A - 基于多开应用的服务插件加载方法及装置 - Google Patents

Abstract

本发明公开了一种基于多开应用的服务插件加载方法及装置。其中，该方法包括：监测多开应用的运行状态是否符合预设检测条件；其中，多开应用支持服务插件的运行；若是，检测终端系统中是否已配置有支持服务插件运行的系统服务框架环境；若是，通过系统服务框架环境加载服务插件；若否，通过多开应用中配置的支持服务插件运行的应用服务框架环境加载服务插件。该方式能够自动检测系统中是否已配置有支持服务插件运行的系统服务框架环境，并在检测结果为是时利用系统中已配置的系统服务框架环境加载服务插件，从而避免了因环境冲突而造成的插件无法正常运行的问题。

Description

基于多开应用的服务插件加载方法及装置

技术领域

本发明涉及计算机技术领域，具体涉及一种基于多开应用的服务插件加载方法及装置。

背景技术

现在很多人在某些应用(如即时通信应用)中都有两个以上的账号，其中一个账号用于生活，另一个账号用于工作或者其他，使生活和工作不会互相干扰。然而手机的某些应用只能安装一个，无法同时登陆两个账号，为了使手机能够同时打开两个相同的应用，用户一般在手机上安装多开应用。目前的多开应用支持应用分身、游戏多开、多账户在线等功能，通过多开应用就可以利用一部手机轻松实现即时通信应用、购物应用、游戏应用等几乎所有应用的多账户同时在线，使生活和工作之间能够互不干扰，实现娱乐和游戏同时进行体验。

另外，为了丰富多开应用的功能，现有的多开应用可以支持更多类型的服务插件。当多开应用支持某些特定类型的服务插件(例如Xposed插件)时，为了确保服务插件的正常运行，需要在多开应用中配置支持该服务插件运行的服务框架环境(例如Xposed框架环境)。但是，发明人在实现本发明的过程中发现，现有技术中的上述方式至少存在下述缺陷：由于终端系统中也可能会配置支持该服务插件运行的服务框架环境，因此，终端系统中配置的服务框架环境可能会与多开应用中配置的服务框架环境冲突，从而导致服务插件无法正常运行。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的基于多开应用的服务插件加载方法及装置。

根据本发明的一个方面，提供了基于多开应用的服务插件加载方法，包括：监测多开应用的运行状态是否符合预设检测条件；其中，多开应用支持服务插件的运行；

若是，检测终端系统中是否已配置有支持服务插件运行的系统服务框架环境；

若是，通过系统服务框架环境加载服务插件；

若否，通过多开应用中配置的支持服务插件运行的应用服务框架环境加载服务插件。

根据本发明的另一个方面，提供了基于多开应用的服务插件加载装置，包括：

监测模块，适于监测多开应用的运行状态是否符合预设检测条件；其中，多开应用支持服务插件的运行；

检测模块，适于若是，检测终端系统中是否已配置有支持服务插件运行的系统服务框架环境；

第一加载模块，适于若是，通过系统服务框架环境加载服务插件；

第二加载模块，适于若否，通过多开应用中配置的支持服务插件运行的应用服务框架环境加载服务插件。

根据本发明的又一方面，提供了一种电子设备，包括：处理器、存储器、通信接口和通信总线，处理器、存储器和通信接口通过通信总线完成相互间的通信；

存储器用于存放至少一可执行指令，可执行指令使处理器执行上述基于多开应用的服务插件加载方法对应的操作。

根据本发明的再一方面，提供了一种计算机存储介质，存储介质中存储有至少一可执行指令，可执行指令使处理器执行如上述基于多开应用的服务插件加载方法对应的操作。

根据本发明公开的基于多开应用的服务插件加载方法及装置，能够在监测到多开应用的运行状态符合预设检测条件时，检测系统中是否已配置有支持服务插件运行的系统服务框架环境；若是，通过系统服务框架环境加载服务插件；若否，通过多开应用中配置的支持服务插件运行的应用服务框架环境加载服务插件。由此可见，该方式能够自动检测系统中是否已配置有支持服务插件运行的系统服务框架环境，并在检测结果为是时利用系统中已配置的系统服务框架环境加载服务插件，从而避免了因环境冲突而造成的插件无法正常运行的问题。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明一个实施例的基于多开应用的服务插件加载方法的流程示意图；

图2示出了本发明另一个实施例的基于多开应用的服务插件加载方法的流程示意图；

图3示出了本发明又一实施例提供的一种基于多开应用的服务插件加载装置的装置结构图；

图4示出了根据本发明实施例的一种电子设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了本发明一个实施例的基于多开应用的服务插件加载方法的流程示意图。如图1所示，该方法包括：

步骤S110：监测多开应用的运行状态是否符合预设检测条件；其中，多开应用支持服务插件的运行。

在本实施例中，服务插件可以是各类能够通过预先配置的与其适配的框架环境而运行的插件。多开应用通常是指：用于启动与原生应用相对应的分身应用的第三方应用，通过多开应用能够实现同时开启多个与原生应用相对应的分身应用的效果。

其中，预设检测条件包括各类需要检测框架环境的可能条件。例如，由于服务插件的加载需要依赖框架环境实现，因此，凡是在需要加载服务插件的场景中，均需要检测框架环境。相应地，可以将与加载服务插件的行为相关的条件均设定为预设检测条件。在本实施例中，由于多开应用启动时以及多开应用启动与原生应用对应的分身应用时均需要加载插件，因此，预设检测条件可以包括：多开应用处于启动状态；和/或，多开应用启动与原生应用对应的分身应用等。

步骤S120：若是，检测终端系统中是否已配置有支持服务插件运行的系统服务框架环境。

若多开应用的运行状态符合预设检测条件，则说明需要加载服务插件，为了确保服务插件的正常加载，在本步骤中，检测终端系统中是否已配置有支持服务插件运行的系统服务框架环境。具体地，可以预先确定与系统服务框架环境相对应的系统特征类和/或系统特征函数，检测系统中是否存在系统特征类和/或系统特征函数，若存在，则说明终端系统中已配置有支持服务插件运行的系统服务框架环境。

具体实施时，一旦终端系统中已配置有支持服务插件运行的系统服务框架环境，则执行步骤S130；否则，执行步骤S140。

步骤S130：若是，通过系统服务框架环境加载服务插件。

终端系统中已配置有支持服务插件运行的系统服务框架环境，则直接通过系统服务框架环境加载服务插件，以防止冲突。具体地，调用与系统服务框架环境相对应的系统预置框架代码和/或系统框架挂钩函数，以加载服务插件。

步骤S140：若否，通过多开应用中配置的支持服务插件运行的应用服务框架环境加载服务插件。

终端系统中未配置有支持服务插件运行的系统服务框架环境，则通过多开应用中配置的支持服务插件运行的应用服务框架环境加载服务插件。具体地，预先在多开应用中注入与应用服务框架环境相对应的应用预置框架代码和/或应用框架挂钩函数；通过应用预置框架代码和/或应用框架挂钩函数加载服务插件。另外，为了便于加载各个服务插件，在该步骤中，还可以预先在多开应用中注入服务插件的插件预置代码，结合插件预置代码加载服务插件。

根据本发明公开的基于多开应用的服务插件加载方法，能够在监测到多开应用的运行状态符合预设检测条件时，检测系统中是否已配置有支持服务插件运行的系统服务框架环境；若是，通过系统服务框架环境加载服务插件；若否，通过多开应用中配置的支持服务插件运行的应用服务框架环境加载服务插件。由此可见，该方式能够自动检测系统中是否已配置有支持服务插件运行的系统服务框架环境，并在检测结果为是时利用系统中已配置的系统服务框架环境加载服务插件，从而避免了因环境冲突而造成的插件无法正常运行的问题。

图2示出了本发明另一个实施例的基于多开应用的服务插件加载方法的流程示意图。在本实施例中，以服务插件为Xposed插件为例进行说明。其中，Xposed插件具体可以为多种不同功能的插件，例如，可以是用于微信应用的微X插件，也可以是用于安全防护的插件。相应地，本实施例中，服务插件包括多个不同功能的服务插件。如图2所示，该方法包括：

步骤S200：预先根据接收到的服务插件管理请求，确定多开应用中启用的服务插件，和/或多开应用中停用的服务插件；根据多开应用中启用的服务插件，和/或多开应用中停用的服务插件，更新多开应用中包含的插件配置文件。

具体地，由于服务插件的类型很多，有些服务插件通过多开应用本身即可支持，而有些服务插件则必须依赖于某一特定类型的分身应用才能实现，其中，分身应用是指由多开应用开启的与原生应用相对应的应用。例如，当原生应用为微信应用时，通过多开应用可以开启至少一个微信类型的分身应用，而微X插件则是依赖于微信类型的分身应用而实现的插件。

通过服务插件管理请求能够将多开应用本身以及多开应用所支持的各种类型的分身应用所对应的服务插件的种类和数量设置在插件配置文件中，以便实现统一管理。其中，服务插件管理请求包括：用于管理多开应用的插件管理请求，和/或用于管理分身应用的插件管理请求。

其中，当服务插件管理请求为用于管理多开应用的插件管理请求时，通过该请求能够设置多开应用本身所支持的各类Xposed插件。例如，可以修改多开应用本身启用的服务插件和/或修改多开应用本身停用的服务插件。当服务插件管理请求为用于管理分身应用的插件管理请求时，通过该请求能够确定分身应用中启用的服务插件，和/或分身应用中停用的服务插件。例如，以微信类型的分身应用而言，由于微信类型的分身应用中可以支持多种类型的Xposed插件，因此，可以修改微信类型的分身应用启用的服务插件和/或修改微信类型的分身应用停用的服务插件。相应地，插件配置文件包括：用于存储多开应用本身所启用和/或停用的服务插件的多开应用配置文件，以及用于存储各种类型的分身应用所启用和/或停用的服务插件的分身应用配置子文件。相应地，在更新多开应用中包含的插件配置文件时，既可以更新多开应用配置文件，也可以更新分身应用配置子文件，具体取决于服务插件管理请求的类型。

由此可见，通过步骤S200，可以预先设置多开应用及其能够开启的各种类型的分身应用所对应的插件的种类和数量。具体实施时，服务插件管理请求可以在各种时机发送，例如，可以在多开应用运行过程中，和/或分身应用运行过程中发送。

步骤S210：监测多开应用的运行状态是否符合预设检测条件；其中，多开应用支持服务插件的运行。

在本实施例中，预设检测条件包括各类需要检测框架环境的可能条件。例如，由于服务插件的加载需要依赖框架环境实现，因此，凡是在需要加载服务插件的场景中，均需要检测框架环境。相应地，可以将与加载服务插件的行为相关的条件均设定为预设检测条件。在本实施例中，由于多开应用启动时以及多开应用启动与原生应用对应的分身应用时均需要加载插件，因此，步骤S210具体包括：当监测到多开应用处于启动状态时，确定多开应用的运行状态符合预设检测条件；和/或，当监测到多开应用启动与原生应用对应的分身应用时，确定多开应用的运行状态符合预设检测条件。

其中，监测多开应用是否处于启动状态，是为了在多开应用启动时能够顺利加载多开应用所支持的各类Xposed插件。监测多开应用是否启动与原生应用对应的分身应用，是为了在该分身应用启动时能够顺利加载分身应用所支持的各类Xposed插件。另外，考虑到实际情况中，可能只有部分分身应用支持Xposed插件，因此，还可以预先维护一个分身应用列表，在该列表中标记支持Xposed插件的分身应用的类型，从而在监测过程中，只对支持Xposed插件的类型的分身应用的启动过程进行监测，从而节省开销。

步骤S220：若是，检测终端系统中是否已配置有支持服务插件运行的系统服务框架环境。

若多开应用的运行状态符合预设检测条件，则说明需要加载服务插件，为了确保服务插件的正常加载，在本步骤中，检测终端系统中是否已配置有支持服务插件运行的系统服务框架环境。具体地，若终端系统中已配置有支持服务插件运行的系统服务框架环境，则系统中会包含相应的类或函数，因此，可以预先确定与系统服务框架环境相对应的系统特征类和/或系统特征函数，检测系统中是否存在系统特征类和/或系统特征函数，若存在，则说明终端系统中已配置有支持服务插件运行的系统服务框架环境。

例如，在一个具体示例中，如果系统中安装了Xposed，系统中的每个应用(包括多开应用)都有Xposed环境。在多开应用中通过函数Class.forName

去查找Xposed的类de.robv.android.xposed.XposedHelpers是否存在来判断系统中是否已经存在Xposed环境。如果系统中存在Xposed环境，会使用系统中的Xposed环境支持多开应用内部的Xposed插件运行；否则，会在多开应用内部建立Xposed环境，以支持多开应用内部的Xposed插件运行。

具体实施时，一旦终端系统中已配置有支持服务插件运行的系统服务框架环境，则执行步骤S230；否则，执行步骤S240。

步骤S230：若是，通过系统服务框架环境加载服务插件。

若终端系统中已配置有支持服务插件运行的系统服务框架环境，则直接通过系统服务框架环境加载服务插件，以防止冲突。具体地，调用与系统服务框架环境相对应的系统预置框架代码和/或系统框架挂钩函数，以加载服务插件。例如，通过反射调用机制调用系统中的Xposed框架的预置代码及其中包含的HOOK函数，从而利用系统中的系统服务框架环境加载服务插件。由于此时无需使用多开应用中配置的应用服务框架环境，因此，不会导致程序运行的冲突，能够确保插件的正常加载。具体地，在加载插件时，需要读取Xposed插件入口类字符串，创建入口类实例并调用其入口函数，以使Xposed插件开始运行。上述操作均由系统中的Xposed框架的预置代码及其中包含的HOOK函数来执行。

步骤S240：若否，通过多开应用中配置的支持服务插件运行的应用服务框架环境加载服务插件。

若终端系统中未配置有支持服务插件运行的系统服务框架环境，则通过多开应用中配置的支持服务插件运行的应用服务框架环境加载服务插件。具体地，为了搭建应用服务框架环境，可以预先在多开应用中注入与应用服务框架环境相对应的应用预置框架代码和/或应用框架挂钩函数；通过应用预置框架代码和/或应用框架挂钩函数加载服务插件。

其中，本实施例中，应用服务框架环境和系统服务框架环境均指Xposed框架环境，均用于支持Xposed插件的运行。区别仅在于：应用服务框架环境是在多开应用的内部配置的Xposed框架环境，仅对多开应用有效；系统服务框架环境是在系统中配置的Xposed框架环境，对于系统中的各个应用均有效。

具体地，本步骤中，在加载插件时，也需要读取Xposed插件入口类字符串，创建入口类实例并调用其入口函数，以使Xposed插件开始运行。此处与上一步骤的区别在于：上述操作均由多开应用中的Xposed框架的预置代码及其中包含的HOOK函数来执行，以便能够在系统中不具有Xposed框架环境的前提下通过多开应用加载Xposed插件。

另外，为了便于加载各个服务插件，在该步骤中，还可以预先在多开应用中注入各个服务插件的插件预置代码，结合插件预置代码加载服务插件。

最后，还要说明的是，在步骤S230以及步骤S240中均需要加载服务插件。具体实施时，视实际场景来确定具体加载哪些服务插件。例如，假设当前场景为多开应用启动时，则需要根据上文提到的多开应用配置文件加载多开应用中启用的服务插件。又如，假设当前场景为多开应用启动与原生应用对应的分身应用时，则需要根据分身应用配置子文件加载分身应用中启用的服务插件。由此可见，步骤S230以及步骤S240的插件加载过程类似，区别仅在于：步骤S230是通过系统服务框架环境进行加载，步骤S240是通过应用服务框架环境进行加载。

另外，通过上面的描述可以看出，由于加载服务插件时需要查询预先配置的多开应用配置文件或分身应用配置子文件，因此，能够确定出当前启用或停用的插件的种类或数量，以便根据最新的配置结果完成相应插件的加载。

由此可见，本申请中的方案至少具有如下优势：多开应用除了是一个多开应用沙箱(可以运行其他第三方应用)，还可以借助系统中安装的Xposed环境，为Xposed插件创建运行环境，也可以看做是Xposed插件的沙箱。因此，在多开应用中启用和停用Xposed插件，仅需要重启多开应用即可生效，不需要重启终端系统，从而为用户提供了便利。而在系统中启用和停用Xposed插件，则必须重启终端系统。具体原因在于：本申请多开应用中的插件加载时机是多开应用进程(或分身应用进程)启动时。相应地，如果在多开应用或分身应用的运行过程中安装了新插件，将根据新插件的安装结果生成步骤S200中的服务插件管理请求并据此修改插件配置文件，当安装该新插件的多开应用或分身应用再次启动时，通过查询插件配置文件即可使该新插件生效。然而，系统Xposed的插件加载时机是在终端系统启动时，所以必须重启终端系统才能使新安装的插件功能生效。另外，由于Xposed框架的运行机制和多开应用的特殊运行环境，多开应用中无法完整支持Xposed插件运行(Xposed插件某些接口函数无法调用)。而多开应用内部提供的Xposed插件沙箱则可以完整支持Xposed插件运行。

另外，为了进一步提升多开应用的功能，在本实施例中，还可以通过如下操作，对多开应用中的分身应用的功能进行更新，以增强分身应用的使用功能：

首先，当多开应用启动与原生应用对应的分身应用时，需要预先将服务框架(即Xposed框架)的预置代码和服务框架插件(即Xposed插件)的预置代码注入到分身应用中。其中，服务框架和相应的服务框架插件用以实现对应用的增强功能，具体可以根据实际需求进行选择配置，在本实施例中不做限定。在上述技术方案中，由于多开应用本身属于第三方应用程序，其并不能直接访问原生应用，因此需要利用多开应用将原生应用的代码数据复制到多开应用中，这样多开应用中就有一个与原生应用相同的分身应用，此时就可以利用多开应用对分身应用进行访问。先将服务框架和服务框架插件的代码进行适配，使其成为可供多开应用使用的预置代码，然后根据服务框架的预置代码和服务框架插件的预置代码在多开应用中建立独立的数据库，并将其存储在该独立的数据库中。为了能够利用服务框架和服务框架插件对分身应用的功能进行修改、添加或删除，在分身应用启动之前，先将服务框架的预置代码和服务框架插件的预置代码注入到分身应用中。以供分身应用直接利用服务框架的预置代码和服务框架插件的预置代码，这样就可以无需root权限，直接通过多开应用使用服务框架插件对分身应用的功能进行更新。

然后，根据与服务框架插件配置界面中输入的配置信息，通过调用注入的服务框架的预置代码和服务框架插件的预置代码，对分身应用中需要调用的与配置信息相关的接口函数代码进行拦截处理，实现按照配置信息更新分身应用的功能。在上述技术方案中，在服务框架插件中设有配置界面，用户可以在该配置界面中输入一些配置信息，例如，在配置界面中更改某些应用的图标、色彩和功能等。输入配置信息之后，分身应用无法直接根据该配置信息更新功能，需要利用上述注入分身应用中的服务框架的预置代码和服务框架插件的预置代码，对与配置信息相关的接口函数代码进行拦截。拦截之后分身应用就不会访问原来的接口函数，而是直接访问与用户输入的配置信息相对应的接口函数，进而执行该配置信息对应的功能，这样用户输入的配置信息才能正常生效。

上述技术方案可以应用到不同的操作系统中，通过上述技术方案，由于在多开应用中添加了服务框架的预置代码和服务框架插件的预置代码，操作系统就可以在无需root的情况下，根据用户自己实际的需要，利用多开应用程序中的服务框架插件，对分身应用的某些功能进行更改、添加或删除，以提高分身应用的功能，使分身应用的功能多样化，能够适应不同用户的不同需求。

图3示出了示出了本发明又一实施例提供的一种基于多开应用的服务插件加载装置的装置结构图，如图3所示，所述装置包括：

监测模块33，适于监测所述多开应用的运行状态是否符合预设检测条件；其中，所述多开应用支持所述服务插件的运行；

检测模块34，适于若是，检测终端系统中是否已配置有支持所述服务插件运行的系统服务框架环境；

第一加载模块35，适于若是，通过所述系统服务框架环境加载所述服务插件；

第二加载模块36，适于若否，通过所述多开应用中配置的支持所述服务插件运行的应用服务框架环境加载所述服务插件。

可选地，监测模块33具体适于：

当监测到所述多开应用处于启动状态时，确定所述多开应用的运行状态符合预设检测条件；和/或，

当监测到所述多开应用启动与原生应用对应的分身应用时，确定所述多开应用的运行状态符合预设检测条件。

可选地，其中，所述检测模块34具体适于：

预先确定与所述系统服务框架环境相对应的系统特征类和/或系统特征函数，检测系统中是否存在所述系统特征类和/或系统特征函数。

可选地，其中，所述第一加载模块35具体适于：

调用与所述系统服务框架环境相对应的系统预置框架代码和/或系统框架挂钩函数，以加载所述服务插件。

可选地，其中，所述第二加载模块36具体适于：

预先在所述多开应用中注入与所述应用服务框架环境相对应的应用预置框架代码和/或应用框架挂钩函数；

通过所述应用预置框架代码和/或应用框架挂钩函数加载所述服务插件。

可选地，其中，所述第二加载模块36具体适于：

预先在所述多开应用中注入所述服务插件的插件预置代码，结合所述插件预置代码加载所述服务插件。

可选地，其中，所述服务插件包括多个不同功能的服务插件，则所述装置进一步包括：

接收模块31，适于预先根据接收到的服务插件管理请求，确定所述多开应用中启用的服务插件，和/或所述多开应用中停用的服务插件；

更新模块32，适于根据所述多开应用中启用的服务插件，和/或所述多开应用中停用的服务插件，更新所述多开应用中包含的插件配置文件；

则所述第二加载模块36具体适于：根据所述插件配置文件加载所述多开应用中启用的服务插件。

可选地，其中，所述服务插件管理请求包括：用于管理多开应用的插件管理请求，和/或用于管理分身应用的插件管理请求；

其中，当所述服务插件管理请求为用于管理分身应用的插件管理请求时，所述接收模块31具体适于：确定所述分身应用中启用的服务插件，和/或所述分身应用中停用的服务插件；

并且，所述更新模块32具体适于：更新所述插件配置文件中包含的分身应用配置子文件。

可选地，其中，当所述多开应用启动与原生应用对应的分身应用时，所述第二加载模块36具体适于：根据所述分身应用配置子文件加载所述分身应用中启用的服务插件。

可选地，其中，所述服务插件包括：Xposed插件，所述服务框架环境包括：Xposed框架环境。

上述各个模块的具体结构和工作原理可参照方法实施例中相应步骤的描述，此处不再赘述。

本申请实施例提供了一种非易失性计算机存储介质，计算机存储介质存储有至少一可执行指令，该计算机可执行指令可执行上述任意方法实施例中的基于多开应用的服务插件加载方法。

图4示出了根据本发明实施例的一种电子设备的结构示意图，本发明具体实施例并不对电子设备的具体实现做限定。

如图4所示，该电子设备可以包括：处理器(processor)402、通信接口(Communications Interface)404、存储器(memory)406、以及通信总线408。

其中：

处理器402、通信接口404、以及存储器406通过通信总线408完成相互间的通信。

通信接口404，用于与其它设备比如客户端或其它服务器等的网元通信。

处理器402，用于执行程序410，具体可以执行上述基于多开应用的服务插件加载方法实施例中的相关步骤。

具体地，程序410可以包括程序代码，该程序代码包括计算机操作指令。

处理器402可能是中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。电子设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器406，用于存放程序410。存储器406可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序410具体可以用于使得处理器402执行以下操作：

监测所述多开应用的运行状态是否符合预设检测条件；其中，所述多开应用支持所述服务插件的运行；

若是，检测终端系统中是否已配置有支持所述服务插件运行的系统服务框架环境；

若是，通过所述系统服务框架环境加载所述服务插件；

若否，通过所述多开应用中配置的支持所述服务插件运行的应用服务框架环境加载所述服务插件。

在一种可选的方式中，程序410具体可以进一步用于使得处理器402执行以下操作：

当监测到所述多开应用处于启动状态时，确定所述多开应用的运行状态符合预设检测条件；和/或，

当监测到所述多开应用启动与原生应用对应的分身应用时，确定所述多开应用的运行状态符合预设检测条件。

在一种可选的方式中，程序410具体可以进一步用于使得处理器402执行以下操作：

预先确定与所述系统服务框架环境相对应的系统特征类和/或系统特征函数，检测系统中是否存在所述系统特征类和/或系统特征函数。

在一种可选的方式中，程序410具体可以进一步用于使得处理器402执行以下操作：

调用与所述系统服务框架环境相对应的系统预置框架代码和/或系统框架挂钩函数，以加载所述服务插件。

在一种可选的方式中，程序410具体可以进一步用于使得处理器402执行以下操作：

预先在所述多开应用中注入与所述应用服务框架环境相对应的应用预置框架代码和/或应用框架挂钩函数；

通过所述应用预置框架代码和/或应用框架挂钩函数加载所述服务插件。

在一种可选的方式中，程序410具体可以进一步用于使得处理器402执行以下操作：

预先在所述多开应用中注入所述服务插件的插件预置代码，结合所述插件预置代码加载所述服务插件。

在一种可选的方式中，所述服务插件包括多个不同功能的服务插件，则程序410具体可以进一步用于使得处理器402执行以下操作：

预先根据接收到的服务插件管理请求，确定所述多开应用中启用的服务插件，和/或所述多开应用中停用的服务插件；

根据所述多开应用中启用的服务插件，和/或所述多开应用中停用的服务插件，更新所述多开应用中包含的插件配置文件；

则程序410具体可以进一步用于使得处理器402执行以下操作：

根据所述插件配置文件加载所述多开应用中启用的服务插件。

在一种可选的方式中，其中，所述服务插件管理请求包括：用于管理多开应用的插件管理请求，和/或用于管理分身应用的插件管理请求；

其中，当所述服务插件管理请求为用于管理分身应用的插件管理请求时，则程序410具体可以进一步用于使得处理器402执行以下操作：

确定所述分身应用中启用的服务插件，和/或所述分身应用中停用的服务插件；

并且，所述更新所述多开应用中包含的插件配置文件的步骤具体包括：更新所述插件配置文件中包含的分身应用配置子文件。

在一种可选的方式中，当所述多开应用启动与原生应用对应的分身应用时，程序410具体可以进一步用于使得处理器402执行以下操作：

根据所述分身应用配置子文件加载所述分身应用中启用的服务插件。

在一种可选的方式中，程序410具体可以进一步用于使得处理器402执行以下操作：所述服务插件包括：Xposed插件，所述服务框架环境包括：Xposed框架环境。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的基于多开应用的服务插件加载装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明还公开了：A1.一种基于多开应用的服务插件加载方法，包括：

监测所述多开应用的运行状态是否符合预设检测条件；其中，所述多开应用支持所述服务插件的运行；

若是，检测终端系统中是否已配置有支持所述服务插件运行的系统服务框架环境；

若是，通过所述系统服务框架环境加载所述服务插件；

若否，通过所述多开应用中配置的支持所述服务插件运行的应用服务框架环境加载所述服务插件。

A2.根据A1所述的方法，其中，所述监测所述多开应用的运行状态是否符合预设检测条件的步骤具体包括：

当监测到所述多开应用处于启动状态时，确定所述多开应用的运行状态符合预设检测条件；和/或，

当监测到所述多开应用启动与原生应用对应的分身应用时，确定所述多开应用的运行状态符合预设检测条件。

A3.根据A1或A2所述的方法，其中，所述检测终端系统中是否已配置有支持所述服务插件运行的系统服务框架环境的步骤具体包括：

预先确定与所述系统服务框架环境相对应的系统特征类和/或系统特征函数，检测系统中是否存在所述系统特征类和/或系统特征函数。

A4.根据A1-A3任一所述的方法，其中，所述通过所述系统服务框架环境加载所述服务插件的步骤具体包括：

调用与所述系统服务框架环境相对应的系统预置框架代码和/或系统框架挂钩函数，以加载所述服务插件。

A5.根据A1-A3任一所述的方法，其中，所述通过所述多开应用中配置的支持所述服务插件运行的应用服务框架环境加载所述服务插件的步骤具体包括：

预先在所述多开应用中注入与所述应用服务框架环境相对应的应用预置框架代码和/或应用框架挂钩函数；

通过所述应用预置框架代码和/或应用框架挂钩函数加载所述服务插件。

A6.根据A5所述的方法，其中，所述通过所述应用预置框架代码和/或应用框架挂钩函数加载所述服务插件的步骤具体包括：

预先在所述多开应用中注入所述服务插件的插件预置代码，结合所述插件预置代码加载所述服务插件。

A7.根据A1-A6任一所述的方法，其中，所述服务插件包括多个不同功能的服务插件，则所述方法进一步包括步骤：

预先根据接收到的服务插件管理请求，确定所述多开应用中启用的服务插件，和/或所述多开应用中停用的服务插件；

根据所述多开应用中启用的服务插件，和/或所述多开应用中停用的服务插件，更新所述多开应用中包含的插件配置文件；

则所述加载所述服务插件的步骤具体包括：根据所述插件配置文件加载所述多开应用中启用的服务插件。

A8.根据A7所述的方法，其中，所述服务插件管理请求包括：用于管理多开应用的插件管理请求，和/或用于管理分身应用的插件管理请求；

其中，当所述服务插件管理请求为用于管理分身应用的插件管理请求时，所述确定所述多开应用中启用的服务插件，和/或所述多开应用中停用的服务插件的步骤具体包括：确定所述分身应用中启用的服务插件，和/或所述分身应用中停用的服务插件；

并且，所述更新所述多开应用中包含的插件配置文件的步骤具体包括：更新所述插件配置文件中包含的分身应用配置子文件。

A9.根据A8所述的方法，其中，当所述多开应用启动与原生应用对应的分身应用时，所述加载所述服务插件的步骤具体包括：根据所述分身应用配置子文件加载所述分身应用中启用的服务插件。

B10.根据B1-B9任一所述的装置，其中，所述服务插件包括：Xposed插件，所述服务框架环境包括：Xposed框架环境。

B11.一种基于多开应用的服务插件加载装置，包括：

监测模块，适于监测所述多开应用的运行状态是否符合预设检测条件；其中，所述多开应用支持所述服务插件的运行；

检测模块，适于若是，检测终端系统中是否已配置有支持所述服务插件运行的系统服务框架环境；

第一加载模块，适于若是，通过所述系统服务框架环境加载所述服务插件；

第二加载模块，适于若否，通过所述多开应用中配置的支持所述服务插件运行的应用服务框架环境加载所述服务插件。

B12.根据B11所述的装置，其中，所述监测模块具体适于：

当监测到所述多开应用处于启动状态时，确定所述多开应用的运行状态符合预设检测条件；和/或，

当监测到所述多开应用启动与原生应用对应的分身应用时，确定所述多开应用的运行状态符合预设检测条件。

B13.根据B11或B12所述的装置，其中，所述检测模块具体适于：

预先确定与所述系统服务框架环境相对应的系统特征类和/或系统特征函数，检测系统中是否存在所述系统特征类和/或系统特征函数。

B14.根据B11-B13任一所述的装置，其中，所述第一加载模块具体适于：

调用与所述系统服务框架环境相对应的系统预置框架代码和/或系统框架挂钩函数，以加载所述服务插件。

B15.根据B11-B13任一所述的装置，其中，所述第二加载模块具体适于：

预先在所述多开应用中注入与所述应用服务框架环境相对应的应用预置框架代码和/或应用框架挂钩函数；

通过所述应用预置框架代码和/或应用框架挂钩函数加载所述服务插件。

B16.根据B15所述的装置，其中，所述第二加载模块具体适于：

预先在所述多开应用中注入所述服务插件的插件预置代码，结合所述插件预置代码加载所述服务插件。

B17.根据B11-B16任一所述的装置，其中，所述服务插件包括多个不同功能的服务插件，则所述装置进一步包括：

接收模块，适于预先根据接收到的服务插件管理请求，确定所述多开应用中启用的服务插件，和/或所述多开应用中停用的服务插件；

更新模块，适于根据所述多开应用中启用的服务插件，和/或所述多开应用中停用的服务插件，更新所述多开应用中包含的插件配置文件；

则所述第二加载模块具体适于：根据所述插件配置文件加载所述多开应用中启用的服务插件。

B18.根据B17所述的装置，其中，所述服务插件管理请求包括：用于管理多开应用的插件管理请求，和/或用于管理分身应用的插件管理请求；

其中，当所述服务插件管理请求为用于管理分身应用的插件管理请求时，所述接收模块具体适于：确定所述分身应用中启用的服务插件，和/或所述分身应用中停用的服务插件；

并且，所述更新模块具体适于：更新所述插件配置文件中包含的分身应用配置子文件。

B19.根据B18所述的装置，其中，当所述多开应用启动与原生应用对应的分身应用时，所述第二加载模块具体适于：根据所述分身应用配置子文件加载所述分身应用中启用的服务插件。

B20.根据B11-B19任一所述的装置，其中，所述服务插件包括：Xposed插件，所述服务框架环境包括：Xposed框架环境。

C21.一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如A1-A10中任一项所述的基于多开应用的服务插件加载方法对应的操作。

D22.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如A1-A10中任一项所述的基于多开应用的服务插件加载方法对应的操作。

Claims (10)

1.一种基于多开应用的服务插件加载方法，包括：

监测所述多开应用的运行状态是否符合预设检测条件；其中，所述多开应用支持所述服务插件的运行；

若是，检测终端系统中是否已配置有支持所述服务插件运行的系统服务框架环境；

若是，通过所述系统服务框架环境加载所述服务插件；

若否，通过所述多开应用中配置的支持所述服务插件运行的应用服务框架环境加载所述服务插件。

2.根据权利要求1所述的方法，其中，所述监测所述多开应用的运行状态是否符合预设检测条件的步骤具体包括：

当监测到所述多开应用处于启动状态时，确定所述多开应用的运行状态符合预设检测条件；和/或，

当监测到所述多开应用启动与原生应用对应的分身应用时，确定所述多开应用的运行状态符合预设检测条件。

3.根据权利要求1或2所述的方法，其中，所述检测终端系统中是否已配置有支持所述服务插件运行的系统服务框架环境的步骤具体包括：

预先确定与所述系统服务框架环境相对应的系统特征类和/或系统特征函数，检测系统中是否存在所述系统特征类和/或系统特征函数。

4.根据权利要求1-3任一所述的方法，其中，所述通过所述系统服务框架环境加载所述服务插件的步骤具体包括：

调用与所述系统服务框架环境相对应的系统预置框架代码和/或系统框架挂钩函数，以加载所述服务插件。

5.根据权利要求1-3任一所述的方法，其中，所述通过所述多开应用中配置的支持所述服务插件运行的应用服务框架环境加载所述服务插件的步骤具体包括：

预先在所述多开应用中注入与所述应用服务框架环境相对应的应用预置框架代码和/或应用框架挂钩函数；

通过所述应用预置框架代码和/或应用框架挂钩函数加载所述服务插件。

6.根据权利要求5所述的方法，其中，所述通过所述应用预置框架代码和/或应用框架挂钩函数加载所述服务插件的步骤具体包括：

预先在所述多开应用中注入所述服务插件的插件预置代码，结合所述插件预置代码加载所述服务插件。

7.根据权利要求1-6任一所述的方法，其中，所述服务插件包括多个不同功能的服务插件，则所述方法进一步包括步骤：

预先根据接收到的服务插件管理请求，确定所述多开应用中启用的服务插件，和/或所述多开应用中停用的服务插件；

根据所述多开应用中启用的服务插件，和/或所述多开应用中停用的服务插件，更新所述多开应用中包含的插件配置文件；

则所述加载所述服务插件的步骤具体包括：根据所述插件配置文件加载所述多开应用中启用的服务插件。

8.一种基于多开应用的服务插件加载装置，包括：

监测模块，适于监测所述多开应用的运行状态是否符合预设检测条件；其中，所述多开应用支持所述服务插件的运行；

检测模块，适于若是，检测终端系统中是否已配置有支持所述服务插件运行的系统服务框架环境；

第一加载模块，适于若是，通过所述系统服务框架环境加载所述服务插件；

第二加载模块，适于若否，通过所述多开应用中配置的支持所述服务插件运行的应用服务框架环境加载所述服务插件。

9.一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-7中任一项所述的基于多开应用的服务插件加载方法对应的操作。

10.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-7中任一项所述的基于多开应用的服务插件加载方法对应的操作。