CN117093286A - 插件生成方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本申请实施例公开了一种插件生成方法、装置、设备及计算机可读存储介质，包括：获取业务应用中针对待打包业务类的抽离请求；业务应用包括待打包业务类，待打包业务类用于为业务应用提供业务服务；待打包业务类携带自定义注解，自定义注解用于标识待打包业务类处于待打包状态；在打包编译阶段中，截获业务应用对应的第一业务类集合，根据第一业务类集合获取携带自定义注解的目标业务类；第一业务类集合包括待打包业务类；目标业务类与自定义注解之间的关联关系是通过自定义注解对待打包业务类进行注解得到；将目标业务类提取至临时文件中，根据临时文件打包生成待打包业务类对应的第一业务插件，可以在编译阶段自动将业务类抽离成插件。

Description

插件生成方法、装置、设备及计算机可读存储介质

技术领域

本申请涉及软件开发技术领域，尤其是一种插件生成方法、装置、设备及计算机可读存储介质。

背景技术

在安卓系统应用的开发过程中，由于业务的不断增长，导致项目的软件代码量越来越大。为方便技术人员对业务应用的不同功能的改动，通常根据业务服务的内容对代码进行划分，将不同的业务代码放置到独立的功能模块中进行开发，得到不同业务服务的业务组件。

现有技术中，一般是将包含很多资源的大模块插件化，如将包含许多业务类或资源的模块插件化。因此，在对小模块插件化的过程中，通常需要将小模块中包括的单个业务类或者几个业务类手动抽离成插件，操作复杂，开发效率低下。

发明内容

本申请实施例提供了一种插件生成方法、装置、设备及计算机可读存储介质，可以将单个业务类或者多个业务类抽离插件，提升了插件的开发效率，适用性强。

本申请实施例提供了一种插件生成方法，该方法包括：

获取业务应用中针对待打包业务类的抽离请求；业务应用包括待打包业务类，待打包业务类用于为业务应用提供业务服务；待打包业务类携带自定义注解，自定义注解用于标识待打包业务类处于待打包状态；

在打包编译阶段中，根据所述抽离请求截获业务应用对应的第一业务类集合，根据第一业务类集合获取携带自定义注解的目标业务类；第一业务类集合包括待打包业务类；目标业务类与自定义注解之间的关联关系是通过自定义注解对待打包业务类进行注解得到；

将目标业务类提取至临时文件中，根据临时文件打包生成待打包业务类对应的第一业务插件；第一业务插件用于为业务应用提供业务服务。

本申请实施例一方面提供了一种插件生成装置，包括：

第一获取模块，用于在业务应用中获取针对待打包业务类的抽离请求；业务应用包括待打包业务类，待打包业务类用于为业务应用提供业务服务；待打包业务类携带自定义注解，自定义注解用于标识待打包业务类处于待打包状态；

第二获取模块，用于在打包编译阶段中，根据所述抽离请求截获业务应用对应的第一业务类集合，根据第一业务类集合获取携带自定义注解的目标业务类；第一业务类集合包括待打包业务类；目标业务类与自定义注解之间的关联关系是通过自定义注解对待打包业务类进行注解得到；

第一生成模块，用于将目标业务类提取至临时文件中，根据临时文件打包生成待打包业务类对应的第一业务插件；第一业务插件用于为业务应用提供业务服务。

其中，上述装置还包括：

第三获取模块，用于获取用于匹配业务需求的注入组件，配置注入组件；

在打包编译阶段中，截获业务应用对应的第一业务类集合，包括：

第一处理模块，用于在打包编译阶段中，通过所配置的注入组件截获业务应用对应的第一业务类集合。

其中，上述第二获取模块还包括：

第一处理单元，用于在打包编译阶段中，根据所述抽离请求通过面向切面工具对第一业务类集合中包括的每个第一业务类进行格式转换处理，得到面向切面工具适用的第二业务类集合；第二业务类集合包括第二业务类，第二业务类为格式转换后的第一业务类；

第二处理单元，用于通过面向切面工具从第二业务类集合中识别携带自定义注解的第二业务类，将携带自定义注解的第二业务类确定为目标业务类。

其中，上述自定义注解包括注解生命周期和注解对象；注解生命周期用于声明自定义注解存在于打包编译阶段；注解对象用于声明对处于待打包状态的业务类进行注解。

其中，上述第一业务类集合包括业务应用对应的主工程目录的类文件、本地类文件、打包类文件以及远程类文件。

其中，上述第二处理单元包括：

第一处理子单元，用于通过面向切面工具将自定义注解传入至第二业务类集合所关联的服务接口中，通过反射机制将服务接口返回的与自定义注解对应的注解对象的第二业务类确定为目标业务类。

其中，上述第一生成模块包括：

第三处理单元，用于在业务应用对应的主工程目录中新建待打包目录，将临时文件中包括的目标业务类拷贝至待打包目录中，通过编译打包工具对待打包目录进行打包处理，得到第一业务插件。

其中，上述第一生成模块包括：

第三处理单元，用于通过面向切面工具识别携带自定义注解的目标业务类关联的内部类；

第三处理单元，用于将内部类抽离至临时文件中。

本申请实施例一方面提供了一种计算机设备，包括：处理器和存储器；

上述处理器与存储器、网络接口相连，其中，网络接口用于提供数据通信功能，存储器用于存储程序代码，处理器用于调用上述程序代码，以执行如本申请实施例第一方面提供的方法。

本申请实施例一方面提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，该计算机程序适于由处理器加载并执行，以使得具有该处理器的计算机设备执行本申请实施例提供的方法。

本申请实施例一方面提供了一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机程序，处理器执行该计算机程序，使得该计算机设备执行本申请实施例提供的方法。

在本申请实施例中，可以获取业务应用中针对待打包业务类的抽离请求，根据抽离请求截获业务应用对应的第一业务类集合，根据第一业务类集合获取携带自定义注解的目标业务类，将目标业务类提取至临时文件中，根据临时文件打包生成待打包业务类对应的第一业务插件。其中，待打包业务类携带自定义注解，自定义注解用于标识待打包业务类处于待打包状态。应当理解，根据自定义注解从第一业务类集合中获取携带自定义注解的目标业务类，可以在编译打包阶段自动识别携带自定义注解的目标业务类，将目标业务类提取至临时文件中，进而自动根据临时文件生成待打包业务类对应的第一业务插件，不需要技术人员手动抽取目标业务类，也避免了技术人员手动配置第一业务插件与业务应用之间的依赖关系，可以降低开发成本。另外，采用本申请既可以对单个或者少数业务类进行插件化处理，也可以对大量的业务类进行插件化处理，适用性更强。

附图说明

图1是本申请实施例提供的一种网络架构的结构示意图；

图2是本申请实施例提供的插件生成方法的第一种流程示意图；

图3是本申请实施例提供的插件生成方法的一场景示意图；

图4是本申请实施例提供的插件生成方法的第二种流程示意图；

图5是本申请实施例提供的插件生成方法的一数据通信流程图；

图6是本申请实施例提供的插件生成装置的结构示意图；

图7是本申请实施例提供的计算机设备的结构示意图。

具体实施方式

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

下面结合附图来对本申请的技术方案的实施作进一步的详细描述。

1、面向切面编程（Aspect Oriented Programming，AOP编程）：是指在打包编译期间（Android Package，APK编译期间）通过预编译方式和运行期动态代理实现程序中某些功能的统一维护的一种技术。

2、编译打包工具（Android Gradle Plugin，AGP打包工具）：是基于安卓（Android）针对安卓系统的编译打包工具，能够实现自定义构建逻辑的插件。

3、Gradle插件：Gradle是项目构建工具，可以用于构建Android工程，Gradle插件则是基于Gradle实现的可以帮助开发人员提高开发效率、扩展功能的脚本。

4、注解：是一种应用于类、方法、参数、变量、构造器或包声明中的特殊修饰符，是用来描述元数据的一种工具。自定义注解为系统内置注解之外的、由开发人员利用元注解自行编写的注解。一般地，注释用于告知开发人员代码的逻辑、说明、特点等，可以无限制的随意编写；编译时，注释会被编译器完全忽略。注解是通过标注类、方法、参数、变量、构造器或包等元素，告知JAVA虚拟机这些元素的元数据，其一般以“@”起始，对于位置、语法、内容都有严格的限制，如果有任何错误，编译过程中就会显示异常。

5、安卓（Android）：Android是一个基于Linux内核与其他开源软件的开放源代码的移动操作系统。

6、安卓系统应用（Android App）：是在Android操作系统的终端设备上运行的应用程序，Android App可使用Java语言来编写开发。

7、Java：Java是一种广泛使用的计算机编程语言，拥有跨平台、面向对象、泛型编程的特性，广泛应用于企业级Web应用开发和移动应用开发。

8、插件（Plugin）：是一种遵循一定规范的应用程序接口编写出来的程序。

请参见图1，图1是本申请实施例提供的一种网络架构的结构示意图。如图1所示，该系统架构可以包括业务服务器100以及终端集群，终端集群可以包括：终端设备200a、终端设备200b、终端设备200c、……、终端设备200n等终端设备。其中，上述业务服务器100可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云数据库、云服务、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端设备（包括终端设备200a、终端设备200b、终端设备200c、……、终端设备200n）可以是智能手机、平板电脑、笔记本电脑、台式计算机、掌上电脑、可穿戴设备（例如智能手表、智能手环等）、智能电视、智能车载等智能终端。其中，业务服务器100与终端集群中的各终端设备可以建立通信连接，终端集群中的各终端设备之间也可建立通信连接。换句话说，业务服务器100可与终端设备200a、终端设备200b、终端设备200c、……、终端设备200n中的各终端设备建立通信连接，例如终端设备200a与业务服务器100之间可建立通信连接。终端设备200a与终端设备200b之间可建立通信连接，终端设备200a与终端设备200c之间也可建立通信连接。其中，上述通信连接不限定连接方式，可以通过有线通信方式进行直接或间接地连接，也可以通过无线通信方式进行直接或间接地连接等，具体可根据实际应用场景确定，本申请在此不做限制。

应该理解，如图1所示的终端集群中的每个终端设备均可以安装有业务应用，业务服务器100可以与各终端设备进行数据交互。例如，若终端设备通过业务应用调用登录组件时，操作对象可通过登录组件登录账户，业务服务器100可以通过终端设备存储操作对象登录的账户信息。当该业务应用运行于各终端设备中时，终端设备可以通过业务应用获取针对任一业务类的抽离请求。其中，业务应用可以包含多个业务类，各个业务类可以通过业务应用实现业务服务。为方便描述，该业务应用可以为社交客户端，即各终端设备可以获取业务应用中针对待打包业务类的抽离请求，各终端设备可以根据抽离请求截获业务应用对应的第一业务类集合。应当理解，待打包业务类用于实现待打包业务类对应的业务服务，待打包业务类携带自定义注解，自定义注解用于标识待打包业务类处于待打包状态，即操作对象可以根据自定义注解对需要打包成插件的业务类进行注解，得到待打包业务类。应当理解，本申请对处于待打包状态的待打包业务类的数量不做限制，具体可根据实际应用场景确定。进一步地，终端设备可以根据第一业务类集合获取携带自定义注解的目标业务类。其中，第一业务类集合包括待打包业务类，目标业务类与自定义注解之间的关联关系是通过自定义注解对待打包业务类进行注解得到。终端设备可以将目标业务类提取至临时文件中，根据临时文件打包生成待打包业务类对应的第一业务插件。其中，第一业务插件用于为业务应用提供业务服务。

应当理解，根据自定义注解从第一业务类集合中获取携带自定义注解的目标业务类，可以在编译打包阶段自动识别携带自定义注解的目标业务类，将目标业务类提取至临时文件中，进而自动根据临时文件生成待打包业务类对应的第一业务插件，不需要技术人员手动抽取目标业务类，也避免了技术人员手动配置第一业务插件与业务应用之间的依赖关系，可以降低开发成本，适用性强，提升了插件的生成效率。

可选的，终端设备通过业务应用获取任一业务类等的处理过程，也可以由业务服务器100执行。也就是说，业务服务器100可以通过终端设备获取针对任一业务类的抽离请求，根据调用请求向终端设备返回业务应用对应的第一业务类集合等。业务服务器100作为业务应用的服务器，可以为包括该业务应用对应的后台服务器、数据处理服务器等多个服务器的集合。上述业务应用可以为独立的客户端，也可以为集成在某客户端（例如上述社交客户端等）中的嵌入式子客户端，具体可根据实际应用场景确定，在此不做限定。

可以理解的是，在本申请的具体实施方式中，涉及到用户信息等相关的数据，当本申请实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

可以理解的是，本申请实施例提供的插件生成方法适用于基于包含多个业务类的业务应用。可以理解的是，上述插件生成方法所适用的终端设备包括但不限于智能手机、计算机、平板电脑、个人数码助理（personal digital assistant，PDA）、移动互联网设备（mobile Internet device，MID）以及可穿戴设备等。可选的，终端设备也可为上述智能手机、计算机、平板电脑、PDA、MID以及可穿戴设备对应的服务器等，具体可根据实际应用场景确定，在此不做限制。对应的，本申请实施例提供的插件生成装置包括但不限于智能手机、计算机、平板电脑、PDA、MID以及可穿戴设备等。为方便描述，本申请实施例提供的插件生成装置和/或终端设备将以智能手机（或简称手机）为例进行说明。

请参见图2，图2是本申请实施例提供的插件生成方法的第一种流程示意图。为了便于理解，本申请实施例以终端设备为例进行说明，即以图1中的终端设备200b为例进行叙述。本申请实施例可应用于各种场景，包括但不限于云技术、人工智能、软件开发等。在图2所示的插件生成方法中，插件生成方法的各个步骤可由上述图1中的终端设备200b来执行，如图2所示，该插件生成方法至少可以包括以下步骤S101-步骤S103。

步骤S101，获取业务应用中针对待打包业务类的抽离请求；业务应用包括待打包业务类，待打包业务类用于为业务应用提供业务服务；待打包业务类携带自定义注解，自定义注解用于标识待打包业务类处于待打包状态。

在一些可行的实施方式中，请参见图3，图3是本申请实施例提供的插件生成方法的一场景示意图。终端设备（即操作对象）可以通过装载在终端设备上的业务应用调用业务组件，从而实现业务服务。为方便描述，业务应用可以为带有支付功能的社交客户端。如图3所示的界面1、界面2以及界面3可以为业务应用在不同时刻的界面。如界面1所示，在操作对象完成支付任务之前，终端设备需通过业务应用调用登录组件为操作对象提供登录服务，此时终端设备将跳转至界面1，操作对象可在界面1上输入操作对象的账号（如图3所示的账户1）和密码，授权登录业务应用，以便于终端设备获取操作对象的用户信息。具体地，当操作对象输入账户以及密码时，终端设备可以提示操作对象阅读与用户相关的信息，如图3所示例的提示操作对象阅读并了解《用户协议》以及《隐私政策》，在操作对象触发已阅读控件201a时，终端设备才可以通过调用“登录”组件，完成账户验证。终端设备成功登录业务应用后，终端设备才可以调用其他业务组件实现业务服务。进一步地，终端设备也可以通过界面2所示的“更多”控件来调用其他业务组件。例如，当操作对象需要通过业务应用（如上述社交客户端）完成支付任务时，操作对象可以通过点击界面2所示的“更多”控件201b跳转至界面2，即当终端设备检测到操作对象在界面1上的点击位置为“更多”控件201b时，终端设备将跳转至界面3。进一步地，当终端设备检测到界面3所示的针对“收付款”控件201c的对象操作指令时，终端设备通过业务应用调用支付组件完成支付任务。应当理解，支付组件与登录组件均可以为业务应用中的业务组件，即终端设备可以通过业务应用分别调用支付组件、登录组件实现支付任务、登录任务。

应当理解，本申请提供的插件生成方法可以对任意携带自定义注解的待打包业务类进行插件化处理，得到待打包业务类对应的第一业务插件，并通过业务应用调用第一业务插件实现业务服务。也就是说，在终端设备通过业务应用调用支付组件之前，需要对对携带自定义注解的支付业务类进行插件化处理，得到支付业务类对应的支付组件，通过支付组件实现支付任务。

在一些可行的实施方式中，终端设备可以获取业务应用中针对待打包业务类的抽离请求。其中，业务应用包括待打包业务类，待打包业务类用于为业务应用提供业务服务。待打包业务类携带自定义注解，自定义注解用于标识待打包业务类处于待打包状态。请再参见图3，终端设备可以获取业务应用中针对支付业务类的抽离请求。其中，支付业务类携带自定义注解，自定义注解用于标识支付业务类处于待打包状态。其中，自定义注解为预先设置的注解，并设置了注解生命周期和注解对象。应当理解，注解生命周期用于声明自定义注解存在于打包编译阶段，即自定义注解仅在打包编译阶段使用，在其他阶段（如运行阶段）不再运行自定义注解。注解对象用于声明对待打包业务类进行注解。应当理解，注解通常是一种代码级别的说明，可以声明在包、类、字段、方法、局部变量、方法等前面，用以说明和注释，但不会直接影响到程序的语义。注解的形式一般为“@注解名”。

步骤S102，在打包编译阶段中，根据抽离请求截获业务应用对应的第一业务类集合，根据第一业务类集合获取携带自定义注解的目标业务类；第一业务类集合包括待打包业务类；目标业务类与自定义注解之间的关联关系是通过自定义注解对待打包业务类进行注解得到。

在一些可行的实施方式中，终端设备可以获取用于匹配业务需求的注入组件，配置注入组件。其中，注入组件用于在打包编译阶段中，截获业务应用对应的第一业务类集合。应当理解，注入组件为根据业务需求预先设置的组件，在打包编译阶段中配置注入组件，终端设备可以通过所配置的注入组件截获业务应用对应的第一业务类集合。应当理解，在本申请提供的插件生成方法中，上述业务需求为截获业务应用对应的所有类文件的需求，即终端设备可通过注入组建截获业务应用对应的第一业务类集合。进一步地，终端设备可以在打包编译阶段中，根据抽离请求通过所配置的注入组件截获业务应用对应的第一业务类集合，根据第一业务类集合获取携带自定义注解的目标业务类。具体地，终端设备可以对业务应用对应的第一业务类集合中包括的每个第一业务类进行格式转换处理，得到第二业务类集合。其中，第一业务类集合中包括多个第一业务类，多个第一业务类用于为业务应用提供业务服务。应当理解，第二业务类集合中包括的每个第二业务类都由第一业务类集合中包括的每个第一业务类进行格式转换处理得到的。第一业务类集合中包括的待打包业务类经过格式转换处理得到与待打包业务类对应的第二业务类。其中，与待打包业务类对应的第二业务类携带自定义注解。终端设备可以从第二业务类集合中获取与待打包业务类对应的第二业务类，并将与待打包业务类对应的第二业务类确定为目标业务类。例如，第一业务类集合包括支付业务类，支付业务类携带自定义注解，此时，支付业务类为待打包业务类。其中，自定义注解用于标识支付业务类处于待打包状态。也就是说，携带自定义注解的支付业务类也经过格式转换处理，即第二业务类集合中包括携带自定义注解的第二业务类。终端设备可以从业务应用对应的第一业务类集合中识别携带自定义注解的支付业务类，并将携带自定义注解的支付业务类确定为目标业务类。

步骤S103，将目标业务类提取至临时文件中，根据临时文件打包生成待打包业务类对应的第一业务插件；第一业务插件用于为业务应用提供业务服务。

在一些可行的实施方式中，终端设备可以将目标业务类提取至临时文件中，根据临时文件打包生成待打包业务类对应的第一业务插件。具体地，终端设备可以在业务应用对应的主工程目录中新建待打包目录，将临时文件中包括的目标业务类拷贝至待打包目录中，通过编译打包工具对待打包目录进行打包处理，得到第一业务插件。

在本申请实施例中，可以通过所配置的注入组件截获业务应用对应的第一业务类集合，在编译打包阶段，可以根据自定义注解自动识别携带自定义注解的目标业务类，将目标业务类提取至临时文件中，进而根据临时文件生成待打包业务类对应的第一业务插件，不需要技术人员手动抽取目标业务类，也避免了技术人员手动配置第一业务插件与业务应用之间的依赖关系，可以降低开发成本，提升了插件的生成效率。同时，本申请通过的插件生成方法即适用单个业务类或者少数业务类抽离成插件的场合，也适用针对大量业务类抽离成插件的场合，适用性更强。

请参见图4，图4是本申请实施例提供的插件生成方法的第二种流程示意图。在终端设备在打包编译阶段中，通过面向切面编程（即AOP编程）识别携带自定义注解的目标业务类的过程，具体如图4所示，该插件生成方法至少可以包括以下步骤S201-步骤S204。

步骤S201，获取业务应用中针对待打包业务类的抽离请求；业务应用包括待打包业务类，待打包业务类用于为业务应用提供业务服务；待打包业务类携带自定义注解，自定义注解用于标识待打包业务类处于待打包状态。

步骤S201的具体实现方式可以参见上述图2对应实施例中的S101，这里不再进行赘述。

步骤S202，在打包编译阶段中，根据抽离请求通过面向切面工具对第一业务类集合中包括的每个第一业务类进行格式转换处理，得到面向切面工具适用的第二业务类集合；第二业务类集合包括第二业务类，第二业务类为格式转换后的第一业务类。

在一些可行的实施方式中，请参见图5，图5是本申请实施例提供的插件生成方法的另一数据通信流程图。如图5所示，在终端设备获取业务应用中针对待打包业务类的抽离请求之后，终端设备可以通过业务应用执行打包编译过程，即终端设备可以分别对业务应用（即宿主APP）打包编译以及对待打包业务类打包编译。在打包编译阶段之前，终端设备可以获取用于匹配业务需求的注入组件，配置注入组件，即将注入组件配置到打包编译流程中，使终端设备可以根据所配置的注入组件截获业务应用对应的第一业务类集合。终端设备可以通过打包编译工具（如Gradle插件）截获业务应用关联的源代码，终端设备可以调用Gradle插件中的Transform接口获取源代码中包括的第一业务类集合。如图5所示，第一业务类集合可以包括业务应用对应的主工程目录的类文件、本地类文件、打包类文件以及远程类文件。也就是说，上述第一业务类可以是主工程目录下的类文件、本地类文件、打包类文件（如AAR文件）以及远程类文件，具体可根据实际应用场景确定，本申请在此不做限制。应当理解，打包编译工具可以遍历读取业务应用中的class文件，在业务应用对应的源代码中，class文件存在多个地方，例如有java源码生成的class文件，jar包（各类SDK）中的class文件以及aar文件等，打包编译工具的入口会统一将这些class文件进行收集在一起，每一个class文件只读取一次，读取后的class文件会按照AOP编程中的AOP Handler处理链依次进行处理，直至遍历所有class类文件。

进一步地，如图5所示，终端设备可以根据抽离请求通过面向切面工具对第一业务类集合中包括的每个第一业务类进行格式转换处理，得到面向切面工具适用的第二业务类集合。其中，第二业务类集合可以包括多个第二业务类，每个第二业务类由对应的第一业务类经过格式转换后得到的。其中，第一业务类集合为业务应用中包括的所有业务类，上述第一业务类集合可以包括多个第一业务类，多个第一业务类中包括待打包业务类。应当理解，上述第一业务类集合中包括的各个第一业务类用于为业务应用提供业务服务。例如，上述第一业务类集合中可以包括支付业务类，支付业务类可以用于为业务应用提供业务服务。

具体地，终端设备可以调用Gradle插件中的Transform接口获取源代码中包括的第一业务类集合。例如，第一业务类集合可以包括支付组件关联的支付业务类，上述支付业务类用于为业务应用提供支付服务。当支付业务类携带自定义注解时，表示该支付业务类为待打包业务类，该支付业务类处于待打包状态。终端设备可以将该支付业务类抽离，生成该支付业务类对应的支付插件，以为业务应用提供支付服务。

进一步地，终端设备可以通过面向切面工具对第一格式类集合中包括的每个第一业务类进行格式转换处理，得到面向切面工具适用的第二业务类集合。其中，面向切面工具可以为Javassist编译工具，即终端设备可以通过Javassist编译工具对第一业务类集合进行格式转换，将第一业务类集合中的各个第一业务类转换为AOP编程适用的第二格式类。此时，第一业务类集合中的待打包业务类也经过格式转换处理，得到与待打包业务类对应的第二业务类，且该与待打包业务类对应的第二业务类携带自定义注解。例如，若待打包业务类为支付业务类，则第二业务类集合中包括与支付业务类对应的第二业务类，且该与支付业务类对应的第二业务类携带自定义注解。

具体地，终端设备可以通过面向切面工具将第一业务类集合中包括的每个第一业务类进行格式转换处理，得到面向切面工具适用的第二业类集合。如图5所示，终端设备可以通过Javassist编译工具对第一业务类集合中包括的各个class文件进行格式转换，得到ctclass文件。其中，class文件为第一业务类集合中包括的各个第一业务类，终端设备可以通过Javassist编译工具将格式文件为class文件的各个第一业务类转换成格式文件为ctclass文件的各个第二业务类，根据各个第二业务类得到第二业务类集合。

步骤S203，通过面向切面工具从第二业务类集合中识别携带自定义注解的第二业务类，将携带自定义注解的第二业务类确定为目标业务类。

在一些可行的实施方式中，终端设备通过面向切面工具从第二业务类集合中识别携带自定义注解的第二业务类，将携带自定义注解的第二业务类确定为目标业务类。其中，目标业务类与自定义注解之间的关联关系是通过自定义注解对N个实现类进行注解得到。如图5所示，终端设备可以通过Javassist编译工具识别携带自定义注解的ctclass文件，并将携带自定义注解的ctclass文件确定为目标业务类。终端设备可以通过Javassist编译工具将自定义注解传入至第二业务类集合中的每个第二业务类关联的服务接口中，根据反射机制将服务接口返回的与自定义注解对应的注解对象的第二业务类确定为目标业务类。具体地，终端设备将自定义注解传入至每个第二业务类关联的服务接口（getannotation接口）中，每个第二业务类将根据自定义注解遍历注解列表，若注解列表中包含自定义注解，将自定义注解实例化得到与自定义注解对应的注解对象，将注解对象返回至服务接口，终端设备将返回注解对象的第二业务类确定为目标业务类。例如，终端设备将自定义注解传入至与支付业务类对应的第二业务类（此时的与支付业务类对应的第二业务类为经过格式转换得到的）关联的服务接口中，根据反射机制接收到自定义注解对应的注解对象，并将与支付业务类对应的第二业务类确定为目标业务类。

步骤S204，在业务应用对应的主工程目录中新建待打包目录，将临时文件中包括的目标业务类拷贝至待打包目录中，通过编译打包工具对待打包目录进行打包处理，得到第一业务插件。

在一些可行的实施方式中，如图5所示，在确定目标业务类后，终端设备可以通过Javassist编译工具将目标业务类提取至临时文件中，即临时文件中包括携带自定义注解的目标业务类。请再参见图5，终端设备可以在业务应用对应的主工程目录中新建待打包目录。进一步地，终端设备可以将临时文件中包括的目标业务类拷贝至待打包目录中，通过编译打包工具对待打包目录进行打包处理，得到第一业务插件。其中，编译打包工具可以为AGP插件工具（如动态交付插件Dynamic Feature），终端设备可以通过AGP插件工具对待打包目录进行打包处理，得到第一业务插件。例如，终端设备在将与支付业务类对应的第二业务类确定为目标业务类后，可以将与支付业务类对应的目标业务类提取至临时文件中。终端设备可以通过在业务应用对应的主工程目录中新建待打包目录，将临时文件中包括的与支付业务类对应的目标业务类拷贝至待打包目录中。进一步地，通过AGP插件工具对包括与支付业务类对应的目标业务类的待打包目录中进行打包处理，得到支付业务类对应的支付插件。

在一些可行的实施方式中，终端设备可以通过面向切面工具识别携带自定义注解的目标业务类关联的内部类，将内部类抽离至临时文件中。例如，若上述与支付业务类对应的目标业务类中包括内部类，则终端设备可以通过面向切面工具识别与支付业务类对应的目标业务类中包括内部类，将与支付业务类对应的目标业务类中的内部类抽离至临时文件中。进一步地，终端设备可以将临时文件中包括的目标业务类以及目标业务类关联的内部类拷贝至待打包目录中。终端设备可以通过AGP插件工具对待打包目录进行打包处理，得到支付业务类对应的支付业务插件。

可选的，当需要增加、删除以及修改第一业务插件时，可以对待打包业务类进行增加、删除以及修改操作。例如，当待打包业务类为开关配置类时，终端设备可以根据本申请提供的插件生成方法得到与开关配置类对应的终端开关插件。当需要对终端开关插件进行增加、更新、删除时，只需要对开关配置类进行修改，进而对修改后的开关配置类进行插件化处理，从实现对终端开关插件的更新。与通过业务应的后台管理平台对终端开关插件的更新相比，本申请提供的插件生成方法不需要在后台管理平台中对每一个开关配置类都增加对应的配置项，因此降低了对终端开关插件维护成本。同时，通过对开关配置类修改实现对终端开关插件的更新，降低了终端开关插件配置的复杂性，提升了终端开关插件配置的可拓展性，还降低了终端开关插件与后台管理平台的耦合性。

在本申请实施例中，在编译打包阶段，根据自定义注解自动识别携带自定义注解的目标业务类，将目标业务类提取至临时文件中，进而自动根据临时文件生成待打包业务类对应的第一业务插件，不需要技术人员手动抽取目标业务类，也避免了技术人员手动配置第一业务插件与业务应用的依赖关系，可以降低成本，提升了插件的生成效率，适用性强。采用本申请可以通过对待打包业务类进行修改来更新第一业务插件，不需要通过业务应用的后台管理平台对第一业务插件进行更新，降低了第一业务插件与业务应用的耦合性，且提升了第一业务插件的拓展性。另外，采用本申请既可以对单个或者少数业务类进行插件化处理，也可以对大量的业务类进行插件化处理，适用性更强。

基于上述插件生成方法的实施例的描述，本申请实施例还公开了一种插件生成装置1。请参见图6，图6是本申请实施例提供的插件生成装置的结构示意图。在本申请实施例中，该装置可运行如下模块：

第一获取模块11，用于在业务应用中获取针对待打包业务类的抽离请求；业务应用包括待打包业务类，待打包业务类用于为业务应用提供业务服务；待打包业务类携带自定义注解，自定义注解用于标识待打包业务类处于待打包状态；

第二获取模块12，用于在打包编译阶段中，截获业务应用对应的第一业务类集合，根据第一业务类集合获取携带自定义注解的目标业务类；第一业务类集合包括待打包业务类；目标业务类与自定义注解之间的关联关系是通过自定义注解对待打包业务类进行注解得到；

第一生成模块13，用于将目标业务类提取至临时文件中，根据临时文件打包生成待打包业务类对应的第一业务插件；第一业务插件用于为业务应用提供业务服务。

其中，上述装置还包括：

第三获取模块14，用于获取用于匹配业务需求的注入组件，配置注入组件；

在打包编译阶段中，截获业务应用对应的第一业务类集合，包括：

第一处理模块15，用于在打包编译阶段中，通过所配置的注入组件截获业务应用对应的第一业务类集合。

其中，上述第二获取模块12还包括：

第一处理单元121，用于在打包编译阶段中，根据所述抽离请求通过面向切面工具对业务类集合中包括的每个第一业务类进行格式转换处理，得到面向切面工具适用的第二业务类集合；第二业务类集合包括第二业务类，第二业务类为格式转换后的第一业务类；

第二处理单元122，用于通过面向切面工具从第二业务类集合中识别携带自定义注解的第二业务类，将携带自定义注解的第二业务类确定为目标业务类。

其中，上述自定义注解包括注解生命周期和注解对象；注解生命周期用于声明自定义注解存在于打包编译阶段；注解对象用于声明对处于待打包状态的业务类进行注解。

其中，上述第一业务类集合包括业务应用对应的主工程目录的类文件、本地类文件、打包类文件以及远程类文件。

其中，上述第二处理单元122包括：

第一处理子单元1221，用于通过面向切面工具将自定义注解传入至第二业务类集合所关联的服务接口中，通过反射机制将服务接口返回的与自定义注解对应的注解对象的第二业务类确定为目标业务类。

其中，上述第一生成模块13包括：

第三处理单元131，用于在业务应用对应的主工程目录中新建待打包目录，将临时文件中包括的目标业务类拷贝至待打包目录中，通过编译打包工具对待打包目录进行打包处理，得到第一业务插件。

其中，上述第一生成模块包括：

第三处理单元131，用于通过面向切面工具识别携带自定义注解的目标业务类关联的内部类；

第三处理单元131，用于将内部类抽离至临时文件中。

根据上述图2所对应的实施例，图2所示的插件生成方法中步骤S101至S103所描述的实现方式可由图6所示的装置的各个模块执行。例如，上述图2所示的插件生成方法中步骤S101所描述的实现方式可由图6所示的装置中第一获取模块11来执行，步骤S102所描述的实现方式可由第二获取模块12来执行，步骤S103所描述的实现方式可由第一生成模块13来执行。其中，上述第一获取模块11、第二获取模块12以及第一生成模块13所执行的实现方式可参见上述图2所对应的实施例中各个步骤所提供的实现方式，在此不再赘述。

在本申请实施例中，终端设备可以对业务应用中携带自定义注解的待打包业务类进行处理，即在业务应用对应的第一业务类集合中，根据自定义注解获取携带自定义注解的目标业务类，并在编译打包阶段自动对携带自定义注解的目标业务类进行打包处理，得到目标业务类对应的第一业务插件，不需要技术人员手动抽取目标业务类，也避免了技术人员手动配置第一业务插件与业务应用的依赖关系，提升插件生成的开发效率，可以降低成本，适用性强。

在本申请实施例中，上述图所示的装置中的各个模块可以分别或全部合并为一个或若干个另外的模块来构成，或者其中的某个（些）模块还可以再拆分为功能上更小的多个模块来构成，这可以实现同样的操作，而不影响本申请实施例的技术效果的实现。上述模块是基于逻辑功能划分的，在实际应用中，一个模块的功能也可以由多个模块来实现，或者多个模块的功能由一个模块实现。在本申请的其它可行的实现方式中，上述装置也可以包括其它模块，在实际应用中，这些功能也可以由其它模块协助实现，并且可以由多个模块协作实现，在此不做限制。

请参见图7，图7是本申请实施例提供的计算机设备的结构示意图，该计算机设备可以是终端设备或服务器。该计算机设备1000可以包括：处理器1001，网络接口1004和存储器1005，此外，上述计算机设备1000还可以包括：用户接口1003，和至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。其中，在一些实施例中，用户接口1003可以包括显示屏（Display）、键盘（Keyboard），可选用户接口1003还可以包括标准的有线接口、无线接口。可选的，网络接口1004可以包括标准的有线接口、无线接口（如WI-FI接口）。存储器1005可以是高速RAM存储器，也可以是非不稳定的存储器（non-volatilememory），例如至少一个磁盘存储器。可选的，存储器1005还可以是至少一个位于远离前述处理器1001的存储装置。如图7所示，作为一种计算机可读存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。

在如图7所示的计算机设备1000中，网络接口1004可提供网络通讯功能；而用户接口1003主要用于为用户提供输入的接口；而处理器1001可以用于调用存储器1005中存储的设备控制应用程序，以实现：

获取业务应用中针对待打包业务类的抽离请求；业务应用包括待打包业务类，待打包业务类用于为业务应用提供业务服务；待打包业务类携带自定义注解，自定义注解用于标识待打包业务类处于待打包状态；

在打包编译阶段中，根据所述抽离请求截获业务应用对应的第一业务类集合，根据第一业务类集合获取携带自定义注解的目标业务类；第一业务类集合包括待打包业务类；目标业务类与自定义注解之间的关联关系是通过自定义注解对待打包业务类进行注解得到；

将目标业务类提取至临时文件中，根据临时文件打包生成待打包业务类对应的第一业务插件；第一业务插件用于为业务应用提供业务服务。

应当理解，本申请实施例中所描述的计算机设备1000可执行前文图2、图4所对应实施例中对插件生成方法的描述，也可执行前文图6所对应实施例中对插件生成装置的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

此外，这里需要指出的是：本申请实施例还提供了一种计算机可读存储介质，且计算机可读存储介质中存储有前文提及的插件生成装置所执行的计算机程序，当处理器执行计算机程序时，能够执行前文图2、图4所对应实施例中对插件生成方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机可读存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。作为示例，计算机程序可被部署在一个计算机设备上执行，或者在位于一个地点的多个计算机设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算机设备上执行，分布在多个地点且通过通信网络互连的多个计算机设备可以组成通信系统。

此外，需要说明的是：本申请实施例还提供了一种计算机程序产品，该计算机程序产品可以包括计算机程序，该计算机程序可以存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机程序，处理器可以执行该计算机程序，使得该计算机设备可执行前文图2、图4所对应实施例中对插件生成方法的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机程序产品实施例中未披露的技术细节，请参照本申请方法实施例的描述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储记忆体（Read-Only Memory，ROM）或随机存储记忆体（Random Access Memory，RAM）等。

本申请实施例的说明书和权利要求书及附图中的术语“第一”、“第二”等是用于区别不同对象，而非用于描述特定顺序。此外，术语“包括”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、装置、产品或设备没有限定于已列出的步骤或模块，而是可选地还包括没有列出的步骤或模块，或可选地还包括对于这些过程、方法、装置、产品或设备固有的其他步骤单元。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例提供的方法及相关装置是参照本申请实施例提供的方法流程图和/或结构示意图来描述的，具体可由计算机程序实现方法流程图和/或结构示意图的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。这些计算机程序指令可提供到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或结构示意图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或结构示意图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或结构示意一个方框或多个方框中指定的功能的步骤。

以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (12)

1.一种插件生成方法，其特征在于，所述方法包括：

获取业务应用中针对待打包业务类的抽离请求；所述业务应用包括所述待打包业务类，所述待打包业务类用于为所述业务应用提供业务服务；所述待打包业务类携带自定义注解，所述自定义注解用于标识所述待打包业务类处于待打包状态；

在打包编译阶段中，根据所述抽离请求截获所述业务应用对应的第一业务类集合，根据所述第一业务类集合获取携带所述自定义注解的目标业务类；所述第一业务类集合包括所述待打包业务类；所述目标业务类与所述自定义注解之间的关联关系是通过所述自定义注解对所述待打包业务类进行注解得到；

将所述目标业务类提取至临时文件中，根据所述临时文件打包生成所述待打包业务类对应的第一业务插件；所述第一业务插件用于为所述业务应用提供业务服务。

2.如权利要求1所述的插件生成方法，其特征在于，在所述获取业务应用中针对待打包业务类的抽离请求之前，所述方法还包括：

获取用于匹配业务需求的注入组件，配置所述注入组件；

所述在打包编译阶段中，截获所述业务应用对应的第一业务类集合，包括：

在打包编译阶段中，通过所配置的所述注入组件截获所述业务应用对应的第一业务类集合。

3.如权利要求1所述的插件生成方法，其特征在于，所述在打包编译阶段中，根据所述抽离请求截获所述业务应用对应的第一业务类集合，根据所述第一业务类集合获取携带所述自定义注解的目标业务类，包括：

在所述打包编译阶段中，根据所述抽离请求通过面向切面工具对所述第一业务类集合中包括的每个第一业务类进行格式转换处理，得到所述面向切面工具适用的第二业务类集合；所述第二业务类集合包括第二业务类，所述第二业务类为格式转换后的第一业务类；

通过所述面向切面工具从所述第二业务类集合中识别携带所述自定义注解的第二业务类，将携带所述自定义注解的第二业务类确定为目标业务类。

4.如权利要求1所述的插件生成方法，其特征在于，所述自定义注解包括注解生命周期和注解对象；所述注解生命周期用于声明所述自定义注解存在于所述打包编译阶段；所述注解对象用于声明对处于待打包状态的业务类进行注解。

5.如权利要求1所述的插件生成方法，其特征在于，所述第一业务类集合包括所述业务应用对应的主工程目录的类文件、本地类文件、打包类文件以及远程类文件。

6.如权利要求3所述的插件生成方法，其特征在于，所述通过所述面向切面工具从所述第二业务类集合中识别携带所述自定义注解的第二业务类，将所述携带所述自定义注解的第二业务类确定为目标业务类，包括：

通过所述面向切面工具将所述自定义注解传入至所述第二业务类集合所关联的服务接口中，通过反射机制将所述服务接口返回的与所述自定义注解对应的注解对象的所述第二业务类确定为所述目标业务类。

7.如权利要求1所述的插件生成方法，其特征在于，所述将所述目标业务类提取至临时文件中，根据所述临时文件打包生成所述待打包业务类对应的第一业务插件，包括：

在所述业务应用对应的主工程目录中新建待打包目录，将所述临时文件中包括的目标业务类拷贝至所述待打包目录中，通过编译打包工具对所述待打包目录进行打包处理，得到所述第一业务插件。

8.如权利要求3所述的插件生成方法，其特征在于，所述将所述目标业务类提取至临时文件中，包括：

通过所述面向切面工具识别携带所述自定义注解的所述目标业务类关联的内部类；

将所述内部类抽离至所述临时文件中。

9.一种插件生成装置，其特征在于，包括：

第一获取模块，用于在业务应用中获取针对待打包业务类的抽离请求；所述业务应用包括所述待打包业务类，所述待打包业务类用于为所述业务应用提供业务服务；所述待打包业务类携带自定义注解，所述自定义注解用于标识所述待打包业务类处于待打包状态；

第二获取模块，用于在打包编译阶段中，截获所述业务应用对应的第一业务类集合，根据所述第一业务类集合获取携带所述自定义注解的目标业务类；所述第一业务类集合包括所述待打包业务类；所述目标业务类与所述自定义注解之间的关联关系是通过所述自定义注解对所述待打包业务类进行注解得到；

第一生成模块，用于将所述目标业务类提取至临时文件中，根据所述临时文件打包生成所述待打包业务类对应的第一业务插件；所述第一业务插件用于为所述业务应用提供业务服务。

10.一种计算机设备，其特征在于，包括：处理器、存储器以及网络接口；

所述处理器与所述存储器、所述网络接口相连，其中，所述网络接口用于提供数据通信功能，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，以执行权利要求1-8任一项所述的方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，所述计算机程序适于由处理器加载并执行权利要求1-8任一项所述的方法。

12.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中，且适于由处理器读取并执行，以使得具有所述处理器的计算机设备执行权利要求1-8任一项所述的方法。