组件化应用程序的开发方法、装置及存储介质与流程

1.本技术涉及计算机领域，尤其涉及一种组件化应用程序的开发方法、装置及存储介质。


背景技术：

2.组件化，是指在将整个应用程序(application，简称：app)进行拆分成各个不同的业务组件(module)以及公共组件(base module)之后，各个业务module之间互相没有依赖关系，但都同时依赖base module，且当各个业务module单独运行时，则将每个业务module以及base module打包成为一个独立app；当各个业务module组合成一个完整app时，会将各个业务module以及base module一起打包成为一个独立app。
3.现有技术中，在对app进行组件化时，由于需要将部分组件库以及业务逻辑在app启动时进行初始化，从而感知app的生命周期，而部分业务逻辑的逻辑代码已经在各个业务module中，但是base module是不依赖业务module的，因此，base module无法调用到相关的逻辑代码，因此，为了可以使base module调用到相关的逻辑代码，需要通过路由软件开发工具包(software development kit，简称：sdk)在base module中添加接口，并在业务module中添加实现类(“application”类)，然后通过路由sdk在“application”类中进行声明，从而使base module调用到业务module中的相关逻辑代码。
4.上述方法虽然实现了base module可以调用到相关的逻辑代码，但是依然需要使base module在业务module中的“application”类中进行强引用，因此，现有技术中依然存在base module依赖业务module的问题。


技术实现要素：

5.本技术实施例提供一种组件化应用程序的开发方法、装置及存储介质，用于解决现有技术中依然存在公共组件需要依赖业务组件的问题。
6.第一方面，本技术实施例提供一种组件化应用程序的开发方法，该方法包括：获取目标接口，目标接口为通过预先创建的类实现的，并在预先创建的类中添加自定义注解的接口，预先创建的类与组件化应用程序中的业务组件一一对应，预先创建的类用于定义对应的业务组件的功能；基于目标接口创建代理类，代理类用于实现目标接口；调用软件开发工具包中的应用程序生命周期回调管理器中的回调方法；基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中。
7.本技术实施例提供的技术方案可以包括以下有益效果：由于将创建的代理类注册至应用程序生命周期回调管理器中，这样公共组件就可以根据代理类实现将应用程序生命周期回调管理器中的回调方法回调给业务组件中的类中，因此，业务组件就可以根据回调的方法及时处理相关逻辑代码，从而避免公共组件在调用业务组件中的相关逻辑代码时，需要依赖业务组件的问题，实现了公共组件不依赖业务组件的目的。
8.在一种可能的实施方式中，获取目标接口之前，该方法还包括：基于预设插件扫描
应用程序中所有的业务组件对应的类；在所有的业务组件对应的类中确定添加了自定义注解的类；相应地，获取目标接口，包括：通过添加了自定义注解的类获取目标接口。
9.本技术实施例提供的技术方案可以包括以下有益效果：由于应用程序中存在很多业务组件对应的类，使用预设插件可以实现对应用程序中所有的类进行全局扫描，确定出添加了自定义注解的类，从而通过该添加了自定义注解的类实现的目标接口创建代理类之后，只要添加了自定义注解的类的某一个方法调用了应用程序生命周期回调管理器中的对应方法，就可以完成将代理类注册至应用程序生命周期回调管理器，因此，实现了代理类的动态注册。
10.在一种可能的实施方式中，自定义注解添加在类的声明处。
11.本技术实施例提供的技术方案可以包括以下有益效果：添加了自定义注解的类可以实现目标接口，从而生成代理类，将自定义注解添加在类的声明处，可以实现利用自定义注解声明各个业务组件的代理类，对于开发人员来说，由于没有任何侵入性的代码，因此，可以减小开发人员的工作量。
12.在一种可能的实施方式中，回调方法包括以下至少之一：用于监控应用程序启动的回调方法；用于在应用程序所运行的系统的内存不足时进行回调的回调方法；用于根据业务组件的优先级从高到低的顺序进行回调的回调方法。
13.本技术实施例提供的技术方案可以包括以下有益效果：应用程序的生命周期状态不同，选择的回调方法也不同，因此，回调方法可以有多种，从而满足应用程序在不同的生命周期状态时，都可以完成将代理类注册至应用程序生命周期回调管理器。
14.在一种可能的实施方式中，基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中之前，该方法还包括：获取应用程序的生命周期状态；将应用程序的生命周期状态发送至应用程序生命周期回调管理器；相应地，基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中，包括：根据应用程序的生命周期状态在应用程序生命周期回调管理器中的回调方法中确定目标回调方法；基于目标回调方法将代理类注册至应用程序生命周期回调管理器中。
15.本技术实施例提供的技术方案可以包括以下有益效果：应用程序的生命周期状态不同，选择的回调方法也不同，应用程序生命周期回调管理器可以根据应用程序的生命周期状态选择对应的回调方法，从而可以提高将代理类注册至应用程序生命周期回调管理器的注册成功率。
16.在一种可能的实施方式中，调用软件开发工具包中的应用程序生命周期回调管理器中的回调方法之前，该方法还包括：在公共组件中初始化应用程序生命周期回调管理器；相应地，基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中，包括：在公共组件中基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中。
17.本技术实施例提供的技术方案可以包括以下有益效果：由于需要实现公共组件不依赖业务组件，因此，在公共组件中初始化应用程序生命周期回调管理器之后，可以在公共组件中基于对应的回调方法将代理类注册至应用程序生命周期回调管理器中，从而实现将公共组件中的应用程序生命周期回调管理器中对应的回调方法回调给各个业务组件的类中，因此，业务组件就可以根据回调的方法及时处理相关逻辑代码，进而实现公共组件不依
赖业务组件。
18.在一种可能的实施方式中，基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中之后，方法还包括：向代理类反馈注册信息，注册信息用于表示将代理类注册至应用程序生命周期回调管理器中。
19.本技术实施例提供的技术方案可以包括以下有益效果：在将代理类注册至应用程序生命周期回调管理器中之后，可以向代理类反馈注册信息，从而就可以确定代理类已经注册至应用程序生命周期回调管理器中，因此开发人员在创建新的业务组件时，只需要根据新的业务组件中的类实现接口，并在新的业务组件中的类中添加自定义注解即可，无需其他操作，从而可以提高组件化应用程序的开发效率，提高组件化应用程序的可扩展性。
20.在一种可能的实施方式中，该方法由开发平台中的软件开发工具包sdk实现。
21.第二方面，本技术实施例提供一种组件化应用程序的开发装置，包括：获取模块，用于获取目标接口，目标接口为通过预先创建的类实现的，并在预先创建的类中添加自定义注解的接口，预先创建的类用于定义实现对应的业务组件的功能的方法；创建模块，用于基于目标接口创建代理类，代理类用于实现目标接口；调用模块，用于调用软件开发工具包中的应用程序生命周期回调管理器中的回调方法；注册模块，用于基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中。
22.本技术实施例提供的技术方案可以包括以下有益效果：由于将创建的代理类注册至应用程序生命周期回调管理器中，这样公共组件就可以根据代理类实现将应用程序生命周期回调管理器中的回调方法回调给业务组件中的类中，因此，业务组件就可以根据回调的方法及时处理相关逻辑代码，从而避免公共组件在调用业务组件中的相关逻辑代码时，需要依赖业务组件的问题，实现了公共组件不依赖业务组件的目的。
23.第三方面，本技术实施例提供一种组件化应用程序的开发装置，包括：处理器，存储器，显示器；存储器用于存储程序和数据，处理器调用存储器存储的程序，以执行第一方面的组件化应用程序的开发方法。
24.本技术实施例提供的技术方案可以包括以下有益效果：由于将创建的代理类注册至应用程序生命周期回调管理器中，这样公共组件就可以根据代理类实现将应用程序生命周期回调管理器中的回调方法回调给业务组件中的类中，因此，业务组件就可以根据回调的方法及时处理相关逻辑代码，从而避免公共组件在调用业务组件中的相关逻辑代码时，需要依赖业务组件的问题，实现了公共组件不依赖业务组件的目的。
25.第四方面，本技术实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现第一方面的组件化应用程序的开发方法。
26.本技术实施例提供的技术方案可以包括以下有益效果：由于将创建的代理类注册至应用程序生命周期回调管理器中，这样公共组件就可以根据代理类实现将应用程序生命周期回调管理器中的回调方法回调给业务组件中的类中，因此，业务组件就可以根据回调的方法及时处理相关逻辑代码，从而避免公共组件在调用业务组件中的相关逻辑代码时，需要依赖业务组件的问题，实现了公共组件不依赖业务组件的目的。
27.第五方面，本技术实施例提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面的组件化应用程序的开发方法。
28.本技术实施例提供的技术方案可以包括以下有益效果：由于将创建的代理类注册
至应用程序生命周期回调管理器中，这样公共组件就可以根据代理类实现将应用程序生命周期回调管理器中的回调方法回调给业务组件中的类中，因此，业务组件就可以根据回调的方法及时处理相关逻辑代码，从而避免公共组件在调用业务组件中的相关逻辑代码时，需要依赖业务组件的问题，实现了公共组件不依赖业务组件的目的。
附图说明
29.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
30.图1为组件化应用程序中业务组件和公共组件之间的依赖关系示意图；
31.图2为本技术实施例提供的组件化应用程序的开发方法的一种应用场景示意图；
32.图3为本技术实施例提供的组件化应用程序的开发方法的流程图；
33.图4为本技术实施例提供的组件化应用程序的开发装置实施例一的结构示意图；
34.图5为本技术实施例提供的组件化应用程序的开发装置实施例二的结构示意图。
具体实施方式
35.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在根据本实施例的启示下做出的所有其他实施例，都属于本技术保护的范围。
36.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
37.背景技术中提供的现有技术中，至少存在以下技术问题：
38.随着信息技术不断的发展，app所承载的信息越来越多，而随着业务需求不断的累积增加，编程所需要的代码量也在逐步增加，同时在应用程序工程中，一款app可以拆分为多个功能组件，例如im通信，日历，音视频等，各个组件之间基本相互独立，而大量的代码带来了编译速度慢，业务耦合等问题，因此，将应用程序工程进行组件化就势在必行。
39.组件化，是指在将整个app进行拆分成各个不同的业务module以及base module之后，各个业务module之间互相没有依赖关系，但都同时依赖base module，如图1所示，图1为组件化应用程序中业务组件和公共组件之间的依赖关系示意图，在图1中，多个业务组件(在图1中用业务组件1、业务组件2、业务组件3、
…
、业务组件n表示)同时依赖公共组件，base module用于存放应用程序工程需要用到的各种基础的组件库，例如日志库，网络库等等。当各个业务module单独运行时，则将每个业务module以及base module打包成为一个独
类，重写“application”类中的相关方法，就可以感知到app的相关生命周期。本技术中的开发人员创建的sdk中定义的类主要指开发人员自行创建的继承自“application”类的类。
48.gradle插件：gradle是项目构建工具，可以用于构建android工程，gradle插件则是基于gradle实现的可以帮助开发人员提高开发效率、扩展功能的脚本。
49.注解：代码中的特殊标记，这些标记可以在编译、类加载、运行时被读取，并执行相应的处理。
50.接口：是对一类行为的定义，通常具有一个或者多个方法(即行为)。
51.本技术提供的组件化应用程序的开发方法，其核心思想是在base module中集成sdk，并在app的开发工具中集成gradle插件，开发人员在业务module中创建sdk中定义的类，并在该类的声明处中添加sdk定义的注解，该类可以实现base module的应用程序生命周期观察接口。在gradle插件编译注解期间，sdk会在应用程序中进行全局查找实现了注解的应用程序生命周期观察接口，并为实现了注解的应用程序生命周期观察接口生成代理类，然后base module的应用程序生命周期观察接口的相关生命周期方法会调用应用程序生命周期回调管理器中的方法，实现将代理类注册至应用程序生命周期回调管理器中，从而实现将应用程序生命周期观察接口的相关生命周期方法回调给业务module中的类，因此，业务module就可以根据回调的方法及时处理相关逻辑代码，从而实现使base module不依赖业务module的目的。
52.在一种实施例中，可以在一种应用场景中应用该组件化应用程序的开发方法。图2为本技术实施例提供的组件化应用程序的开发方法的一种应用场景示意图，如图2所示，在该场景中，多个开发人员(在图2中用开发人员a、开发人员b、
…
、开发人员n表示)中的开发人员a在一个业务module中创建sdk定义的类“messageapplication”，然后在该“messageapplication”类的声明处添加注解，该“messageapplication”类可以用于实现一个应用程序生命周期观察接口；开发人员b在另一个业务module中创建sdk定义的“rtcapplication”类，然后在该“rtcapplication”类的声明处添加注解，该“rtcapplication”类可以用于实现另一个应用程序生命周期观察接口，其他的开发人员也可以进行类似处理，此时开发人员的工作完成。
53.在上述场景中，在gradle插件编译注解期间，sdk会在应用程序中进行全局查找实现了注解的应用程序生命周期观察接口，并为每个实现了注解的应用程序生命周期观察接口生成代理类；在app启动之后，app可以向sdk中的应用程序生命周期回调管理器通知app的相关生命周期状态，应用程序生命周期回调管理器在确定了app的相关生命周期状态之后，根据app的相关生命周期状态确定对应的回调方法，sdk会根据应用程序生命周期回调管理器中确定出的对应的回调方法将代理类注册至应用程序生命周期回调管理器，这样base module就可以根据代理类实现将应用程序生命周期回调管理器中的回调方法回调给业务组件中的类中，业务组件根据回调的方法及时处理相关逻辑。
54.在上述场景中，将代理类注册至应用程序生命周期回调管理器的同时，sdk还将代理类已完成注册的注册信息通知给所有的观察者，该观察者也即代理类，这样当开发人员在业务module中创建类时，sdk会为该类生成代理类，代理类就持有了该类，从而在app启动之后，由于代理类已经注册到应用程序生命周期回调管理器中了，因此，app可以通过应用程序生命周期回调管理器将app的生命周期状态通知到代理类，而代理类在生成时已经持
有了开发人员在业务module中创建的类，因此，代理类可以将app的生命周期状态通知到开发人员在业务module中创建的类中，从而实现各个业务module对app生命周期状态的感知，比如，当开发人员a再次在业务module中创建“messageapplication”类时，sdk会为该“messageapplication”类生成代理类，代理类就持有了该“messageapplication”类，在app启动之后，app可以通过应用程序生命周期回调管理器将app的生命周期状态通知到代理类，而代理类又持有“messageapplication”类，因此，代理类可以将app的生命周期状态通知到“messageapplication”类，这样业务module就可以感知到app的生命周期状态。
55.结合上述场景，下面通过几个具体实施例对本技术提供的组件化应用程序的开发方法的技术方案进行详细说明。
56.图3为本技术实施例提供的组件化应用程序的开发方法的流程图，如图3所示，该方法可以包括以下步骤：
57.s301：获取目标接口，目标接口为通过预先创建的类实现的，并在预先创建的类中添加自定义注解的接口，预先创建的类用于定义对应的业务组件的功能。
58.在本步骤中，目标接口也即前述的应用程序生命周期观察接口。目标接口为通过开发人员预先创建的类实现的，预先创建的类与组件化应用程序中的业务组件一一对应，该类可以为集成在base module中的sdk定义的类，比如，“messageapplication”类、“rtcapplication”类等，开发人员可以在该类的声明处添加sdk定义的注解。
59.在上述方案中，在base module中集成的sdk中包括应用程序生命周期回调管理器，该应用程序生命周期回调管理器内部包括一个静态集合，该静态集合中包括多个代理类。
60.在上述方案中，开发人员在类的声明处添加sdk定义的注解，是为了可以利用注解声明各个业务module对应的代理类，对于开发人员而言，没有任何侵入性的代码，因此，可以减小开发人员的工作量。
61.s302：基于目标接口创建代理类，代理类用于实现目标接口。
62.在本步骤中，在base module中集成的sdk中还可以包括开发人员在类的声明处添加sdk定义的注解，以及针对该注解的解释器。在gradle插件编译注解期间对于实现该注解的类实现的目标接口，解释器可以为该目标接口创建代理类，创建的代理类也同样可以用于实现该目标接口，也即前述的应用程序生命周期观察接口。该代理类中同时也包含了被代理类的对象，在复写的方法中均调用了被代理类的对象的相同方法名字的方法。
63.在上述方案中，某个类在实现接口时，会重写接口的方法；某个类实现了这个接口，就表示需要重写这个接口的方法，代表这个类具有这个接口相同的能力。因此，上述目标接口中包括了多个生命周期的方法，每个生命周期的方法代表着app的生命周期的一个运行状态。sdk基于目标接口生成代理类时，也需要实现目标接口，重写目标接口的所有方法，在重写的这些方法中，具体的实现就是调用被代理类的对象的相同方法名字的方法，该被代理类就是各个业务module自行实现的类，比如，“application”类。
64.在上述方案中，被代理类的对象的方法名字与回调方法中的方法名字相同，比如，被代理类的对象的方法名字为“oncreate”方法，回调方法中的方法名字也为“oncreate”方法，这样开发人员在业务module中定义“application”类时，若看到“oncreate”方法，则可以确定为应用程序启动的回调方法，从而可以实现开发人员在业务module中创建类时减少
理解的歧义。
65.s303：调用软件开发工具包中的应用程序生命周期回调管理器中的回调方法。
66.在本步骤中，应用程序生命周期回调管理器中的回调方法与app的生命周期状态有关，不同的生命周期状态对应不同的回调方法，比如，当app的生命周期状态为启动时，回调方法可以为用于监控app启动的回调方法。
67.s304：基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中。
68.在本步骤中，在确定了对应的回调方法之后，sdk可以根据该回调方法将代理类注册至sdk中的应用程序生命周期回调管理器中，由于sdk集成在base module中，这样base module就可以根据代理类实现将应用程序生命周期回调管理器中的回调方法回调给业务module中的类，因此，业务module就可以根据回调的方法及时处理相关逻辑，比如，当sdk根据oncreate方法将代理类注册至应用程序生命周期回调管理器中，base module就可以根据代理类将oncreate方法回调至业务module中的类，由于oncreate方法是用于监控app启动的回调方法，此时，业务module根据oncreate方法基于自身业务进行相关逻辑的初始化声明，从而实现base module不依赖业务module的目的。
69.本实施例提供的组件化应用程序的开发方法，由于将创建的代理类注册至应用程序生命周期回调管理器中，这样公共组件就可以根据代理类实现将应用程序生命周期回调管理器中的回调方法回调给业务组件中的类中，因此，业务组件就可以根据回调的方法及时处理相关逻辑代码，从而避免公共组件在调用业务组件中的相关逻辑代码时，需要依赖业务组件的问题，实现了公共组件不依赖业务组件的目的。
70.在一种实施例中，获取目标接口之前，该方法还包括：基于预设插件扫描应用程序中所有的业务组件对应的类；在所有的业务组件对应的类中确定添加了自定义注解的类；相应地，获取目标接口，包括：通过添加了自定义注解的类获取目标接口。
71.在该方案中，预设插件可以为前述的gradle插件，该gradle插件可以用于实现代理类的动态注册。开发人员在app的开发工具中集成该gradle插件之后，在gradle插件编译注解期间，sdk通过gradle插件扫描app中所有的业务组件对应的类，由于代理类需要目标接口来创建，而目标接口需要添加了自定义注解的类来实现，因此，需要查找到所有添加了自定义注解的类，从而根据添加了自定义注解的类获取目标接口，从而得到基于目标接口创建的代理类。
72.在上述方案中，在查找到代理类之后，可以将代理类对象注册到应用程序生命周期回调管理器的对应方法中，比如，“init”方法，这样sdk根据应用程序生命周期回调管理器中的回调方法将每个代理类注册至应用程序生命周期回调管理器中时，只要添加了自定义注解的类的某一个方法调用了应用程序生命周期回调管理器中的对应方法，比如，在“application”类的“oncreate”方法中调用应用程序生命周期回调管理器的“init”方法，就可以完成注册。由于这些操作不需要开发人员完成，且开发app的实际编写的项目中也不存在注册的代码，因此，通过gradle插件可以实现动态注册，从而减少开发人员的工作量。
73.在上述方案中，“init”方法即为用于注册代理类的方法。使用gradle插件帮助开发人员在编译注解期间，自动将代理类的注册代码写入到“init”方法中，这样“init”方法会在“application”类的“oncreate”方法中调用，因此，执行“init”方法之后所有的代理类
都可以注册到应用程序生命周期回调管理器，而这对于开发人员是完全没有感知的，因此，可以大大减小开发人员的工作量。
74.在上述方案中，在app启动之后，由于“application”类的“oncreate”方法被调用，而“application”类的“oncreate”方法中调用了应用程序生命周期回调管理器的“oncreate”方法，因此，应用程序生命周期回调管理器的“oncreate”方法在app启动之后也会被调用，在“init”方法中注册的代理类的对象的“oncreate”方法也同时会被调用。
75.在一种实施例中，自定义注解添加在类的声明处。
76.在该方案中，添加了自定义注解的类可以实现目标接口，从而生成代理类，将自定义注解添加在类的声明处，可以实现利用自定义注解声明各个业务组件的代理类，对于开发人员来说，由于没有任何侵入性的代码，因此，可以减小开发人员的工作量。
77.在一种实施例中，回调方法包括以下至少之一：用于监控应用程序启动的回调方法；用于在应用程序所运行的系统的内存不足时进行回调的回调方法；用于根据业务组件的优先级从高到低的顺序进行回调的回调方法。
78.在该方案中，app的生命周期状态不同，应用程序生命周期回调管理器中对应的回调方法也不同。当app的生命周期状态为app启动时，回调方法即为用于监控应用程序启动的回调方法，比如，“oncreate”方法；当app的生命周期状态为app所运行的系统的内存不足时，回调方法即为用于在应用程序所运行的系统的内存不足时进行回调的回调方法，比如，“onlowmemory”方法，或者“ontrimmemory”方法；当app中的多个业务module同时应用时，需要考虑各个业务module不同的优先级，因此选择用于根据业务module的优先级从高到低的顺序进行回调的回调方法，比如，“getpriority”方法，该方法表示返回业务module的优先级，各个业务module之间可能存在不同的优先级，优先级高的业务module在生命周期方法回调时会被优先回调。
79.在上述方案中，“getpriority”方法是用来给各个业务module的“application”类做优先级的。比如，在app中，会话module被认为优先级最高，那么在实现“messageapplication”类(会话module的自行实现的“application”类)时，重写“getpriority”方法就会将会话module的优先级设置为最高，并在将会话module的优先级设置为最高后，在“oncreate”方法、“onlowmemory”方法和“ontrimmemory”方法这三个生命周期方法回调时，由于会回调给所有的代理类，因此，哪个代理类进行优先回调就可以根据业务module的优先级进行确定。
80.在上述方案中，app的生命周期状态不同，选择的回调方法也不同，因此，回调方法可以有多种，从而满足app在不同的生命周期状态时，都可以完成将代理类注册至应用程序生命周期回调管理器。
81.在一种实施例中，基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中之前，该方法还包括：获取应用程序的生命周期状态；将应用程序的生命周期状态发送至应用程序生命周期回调管理器；相应地，基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中，包括：根据应用程序的生命周期状态在应用程序生命周期回调管理器中的回调方法中确定目标回调方法；基于目标回调方法将代理类注册至应用程序生命周期回调管理器中。
82.在该方案中，app的生命周期状态不同，选择的回调方法也不同，因此，在将代理类
注册至应用程序生命周期回调管理器中之前，可以先获取app的生命周期状态，然后将app的生命周期状态发送至应用程序生命周期回调管理器，这样应用程器生命周期回调管理器就可以实时确定app的生命周期状态，从而确定出对应的回调方法，因此，可以按照确定出的与app生命周期状态对应的回调方法将代理类注册至应用程序生命周期回调管理器中，避免由于回调方法不准确导致的代理类注册失败的问题，从而可以提高将代理类注册至应用程序生命周期回调管理器的注册成功率。
83.在一种实施例中，调用软件开发工具包中的应用程序生命周期回调管理器中的回调方法之前，该方法还包括：在公共组件中初始化应用程序生命周期回调管理器；相应地，基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中，包括：在公共组件中基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中。
84.在该方案中，在开发人员创建了sdk定义的类，并在该类的声明处添加了sdk定义的注解之后，可以在base module中初始化应用程序生命周期回调管理器，从而完成对代理类的注册。由于sdk集成在base module中，因此，需要实现base module不依赖业务module，就可以在base module中初始化应用程序生命周期回调管理器之后，在base module中基于对应的回调方法将代理类注册至应用程序生命周期回调管理器中，从而实现将base module中的应用程序生命周期回调管理器中对应的回调方法回调给各个业务module的类中，这样就可以使各个业务module基于自身的业务进行相关逻辑的处理，从而实现base module不依赖业务module。
85.在一种实施例中，基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中之后，该方法还包括：向代理类反馈注册信息，注册信息用于表示将代理类注册至应用程序生命周期回调管理器中。
86.在该方案中，在将代理类注册至应用程序生命周期回调管理器中之后，可以向代理类反馈注册信息，从而就可以确定代理类已经注册至应用程序生命周期回调管理器中，因此开发人员在创建新的业务module时，只需要根据新的业务module中的sdk定义的类实现接口，并在新的业务module中的类的声明处中添加sdk定义的注解即可，无需其他操作，从而可以提高组件化应用程序的开发效率，提高组件化应用程序的可扩展性。
87.在一种实施例中，该方法由开发平台中的软件开发工具包sdk实现。
88.在该方案中，软件开发工具包sdk可以集成在base module中。
89.本实施例提供的组件化应用程序的开发方法，通过在base module中集成sdk，在app的开发工具中集成gradle插件，从而实现各个业务module动态向应用程序生命周期回调管理器中注册代理类，且在“application”类的相关方法在被调用时，能够及时通知各个业务module，然后各个业务module在相关方法回调时可以根据回调的方法及时处理相关的逻辑，比如，“application”类的“oncreate”方法被调用时，会通知各个业务module，各个业务module基于自身业务进行相关逻辑的初始化声明等，从而实现base module不依赖业务module的目的。
90.从总体上来说，本技术提供的技术方案，是一种既可以使开发的组件化应用程序中的公共组件不依赖业务组件，又可以提升组件化应用程序的开发速度的技术实现方法。
91.图4为本技术实施例提供的组件化应用程序的开发装置实施例一的结构示意图，
该组件化应用程序的开发装置400包括：
92.获取模块401，用于获取目标接口，目标接口为通过预先创建的类实现的，并在预先创建的类中添加自定义注解的接口，预先创建的类用于定义对应的业务组件的功能；
93.创建模块402，用于基于目标接口创建代理类，代理类用于实现目标接口；
94.调用模块403，用于调用软件开发工具包中的应用程序生命周期回调管理器中的回调方法；
95.注册模块404，用于基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中。
96.可选的，该装置还用于在获取目标接口之前，基于预设插件扫描应用程序中所有的业务组件对应的类；在所有的业务组件对应的类中确定添加了自定义注解的类；相应地，获取模块401还用于通过添加了自定义注解的类获取目标接口。
97.可选的，自定义注解添加在类的声明处。
98.可选的，回调方法包括以下至少之一：用于监控应用程序启动的回调方法；用于在应用程序所运行的系统的内存不足时进行回调的回调方法；用于根据业务组件的优先级从高到低的顺序进行回调的回调方法。
99.可选的，该装置还用于在基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中之前，获取应用程序的生命周期状态；将应用程序的生命周期状态发送至应用程序生命周期回调管理器；相应地，注册模块404还用于根据应用程序的生命周期状态在应用程序生命周期回调管理器中的回调方法中确定目标回调方法；基于目标回调方法将代理类注册至应用程序生命周期回调管理器中。
100.可选的，该装置还用于在调用软件开发工具包中的应用程序生命周期回调管理器中的回调方法之前，在公共组件中初始化应用程序生命周期回调管理器；相应地，注册模块404还用于在公共组件中基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中。
101.可选的，该装置还用于在基于应用程序生命周期回调管理器中的回调方法将代理类注册至应用程序生命周期回调管理器中之后，向代理类反馈注册信息，注册信息用于表示将代理类注册至应用程序生命周期回调管理器中。
102.可选的，该装置可以应用在开发平台中的软件开发工具包sdk中。
103.本实施例提供的组件化应用程序的开发装置，用于执行前述方法实施例中的组件化应用程序的开发方法的技术方案，其实现原理和技术效果类似，在此不再赘述。
104.图5为本技术实施例提供的组件化应用程序的开发装置实施例二的结构示意图，该组件化应用程序的开发装置500包括：
105.处理器511、存储器512、显示器513；
106.存储器512用于存储程序和数据，处理器511调用存储器512存储的程序，以执行前述方法实施例提供的组件化应用程序的开发方法的技术方案。
107.在上述组件化应用程序的开发装置中，存储器512和处理器511之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可以通过一条或者多条通信总线或信号线实现电性连接，如可以通过总线连接。存储器512中存储有实现组件化应用程序的开发方法的计算机执行指令，包括至少一个可以软件或固件的形式存储于存储器中的
软件功能模块，处理器511通过运行存储在存储器512内的软件程序以及模块，从而执行各种功能应用以及数据处理。
108.存储器可以是，但不限于，随机存取存储器(random access memory，简称：ram)，只读存储器(read only memory，简称：rom)，可编程只读存储器(programmable read-only memory，简称：prom)，可擦除只读存储器(erasable programmable read-only memory，简称：eprom)，电可擦除只读存储器(electric erasable programmable read-only memory，简称：eeprom)等。其中，存储器用于存储程序，处理器在接收到执行指令后，执行程序。进一步地，上述存储器内的软件程序以及模块还可包括操作系统，其可包括各种用于管理系统任务(例如内存管理、存储设备控制、电源管理等)的软件组件和/或驱动，并可与各种硬件或软件组件相互通信，从而提供其他软件组件的运行环境。
109.处理器可以是一种集成电路芯片，具有信号的处理能力。上述的处理器可以是通用处理器，包括中央处理器(central processing unit，简称：cpu)、网络处理器(network processor，简称：np)等。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
110.本技术实施例还提供一种计算机可读存储介质，计算机可读存储介质包括程序，程序在被处理器执行时用于实现方法实施例中提供的组件化应用程序的开发方法的技术方案。
111.本技术还提供一种计算机程序产品，包括：计算机程序，该计算机程序被处理器执行时用于实现前述方法实施例提供的组件化应用程序的开发方法的技术方案。
112.本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
113.最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。