应用程序的组件化、组件调用和组件初始化方法及其装置

技术领域

本发明涉及计算机技术领域，具体而言，本申请涉及一种应用程序的组件化方法和装置，应用程序的组件调用方法和装置，应用程序的组件初始化方法和装置，电子设备及计算机设备存储介质。

背景技术

随着App(外语全称：Application，应用程序)的不断迭代和开发，业务逻辑会变得越来越复杂，通常情况下一个App包括多个功能模块，不同功能模块之间会存在相互调用关系，相互之间功能模块耦合严重，维护成本越来越高；当使用组件化的方案来组织一个App的功能代码时，必须处理好不同功能模块之间的相互调用关系。因此，有必要开发更加合理的组件化框架来实现不同功能模块的相互解耦和独立维护。

目前，业界主流的解耦解决方案都是基于源码隔离和拆分独立SDK的方式实现，需要直接依赖相关头文件，并不能实现完全的依赖解耦；因此本方案可以更好的实现不同组件直接的结构和相互调用，达到完全组件之间解除依赖的目的。例如，一个App-A包含登录和看直播功能，用户在进入看直播之前必须先进行登录，则认为直播模块依赖于登录模块。在组件化重构之后，如果直播模块可以同时被另外一个App-B使用，App-B没有登录功能，用户不需要登录也能够直接看直播，此时需要直播模块和登录模块的完全解耦。

但在上述解耦方案中，功能模块的代码包括了所有的代码实现，并且一般是以头文件提供类声明的方式对外提供接口调用，这种调用方式属于强引用关系，一旦代码实现没有被引入到工程中，代码执行会出现崩溃异常，影响了应用程序的运行效果。

发明内容

本发明的目的旨在至少能解决上述的技术缺陷之一，特别是代码执行会出现崩溃异常，影响应用程序的运行效果的技术缺陷，而提供的解决方案。

在第一方面：

本申请提供一种应用程序的组件化方法，包括如下步骤：

配置功能模块的静态库文件；其中，所述静态库文件包括应用程序的所述功能模块的实现代码；

配置所述功能模块的至少一个协议文件；其中，所述协议文件为以抽象方式对外提供的接口文件，用于给其他组件进行接口调用；

对所述功能模块对应的静态库文件和协议文件进行组件封装。

在一个实施例中，所述配置所述功能模块的至少一个协议文件的步骤，包括：

获取所述功能模块的能力信息；

将所述能力信息描述为约束规则信息，并以所述约束规则信息为内容生成所述协议文件；

在一个实施例中，所述对所述功能模块对应的静态库文件和协议文件进行组件封装的步骤，包括：

以所述约束规则信息为实例进行组件封装，并将其与至少一个对外接口进行二次封装成目标组件；其中，所述对外接口为调用所述协议文件的接口。

在一个实施例中，在配置应用程序的功能模块的静态库文件之前，还包括：

根据所述应用程序的实现功能，将所述应用程序划分为多个功能模块；其中，所述功能模块由至少一个组件实现。

在第二方面：

本申请提供一种应用程序的组件化装置，包括：

第一配置模块，用于配置功能模块的静态库文件；其中，所述静态库文件包括应用程序的所述功能模块的实现代码；

第二配置模块，用于配置所述功能模块的协议文件；其中，所述协议文件为以抽象方式对外提供的接口文件，用于给其他组件进行接口调用；

组件封装模块，用于对所述功能模块对应的静态库文件和协议文件进行组件封装。

在第三方面：

本申请提供一种应用程序的组件调用方法，包括如下步骤：

在调用组件的协议文件中配置需要调用的目标对外接口；其中，所述协议文件为以抽象方式对外提供的接口文件，用于给其他组件进行接口调用；

根据所述配置的目标对外接口，查询实现该目标对外接口的目标组件；其中，所述目标组件封装有所述目标对外接口，以及应用程序的功能模块的实现代码的静态库文件；

根据所述调用组件的调用请求获取所述目标组件的实例，执行所述目标组件的实现代码。

在一个实施例中，在根据所述调用组件的调用请求调用所述目标组件，执行所述目标组件的实现代码之前，还包括：

利用组件管理器查询目标组件是否存在可执行的组件实例对象；

若存在，判定所述目标组件已完成初始化，执行所述目标组件的执行的组件实例对象的方法；

否则，判定所述目标组件未完成初始化，在指定时间段内等待，直至目标组件完成初始化后，执行所述目标组件的执行的组件实例对象的方法。

在一个实施例中，所述在调用组件的协议文件中配置需要调用的目标对外接口的步骤，包括：

在调用组件的协议文件中声明需要调用的目标对外接口；或者，将所述目标组件的协议文件拷贝到调用组件的协议文件中。

在第四方面：

本申请提供一种应用程序的组件调用装置，包括：

第三配置模块，用于在调用组件的协议文件中配置需要调用的目标对外接口；其中，所述协议文件为以抽象方式对外提供的接口文件，用于给其他组件进行接口调用；

组件查询模块，用于根据所述配置的目标对外接口，查询实现该目标对外接口的目标组件；其中，所述目标组件封装有所述目标对外接口，以及应用程序的功能模块的实现代码的静态库文件；

代码执行模块，用于根据所述调用组件的调用请求获取所述目标组件的实例，执行所述目标组件的实现代码。

在第五方面：

本申请提供一种应用程序的组件初始化方法，包括如下步骤：

在接收到启动信号后获取应用程序的各个组件；其中，所述组件由应用程序的所述功能模块的静态库文件和协议文件封装得到，所述静态库文件包括所述功能模块的实现代码，所述协议文件为以抽象方式对外提供的接口文件，用于给其他组件进行接口调用；

配置各个所述组件之间的依赖关系，并根据所述依赖关系配置各个组件的初始化顺序；

响应所述启动信号并根据所述初始化顺序依次对各个组件进行初始化。

在一个实施例中，所述根据所述依赖关系配置各个组件的初始化顺序的步骤，包括：

根据所述依赖关系获取需要在主线程初始化的第一类组件，以及不需要在主线程初始化的第二类组件；

将所述第一类组件配置为在主线程串行初始化的组件，将所述第二类组件配置为与所述主线程并行初始化的组件；

所述根据所述初始化顺序依次对各个组件进行初始化的步骤，包括：

利用所述主线程执行所述第一类组件的初始化，以及利用其他并行线程执行所述第二类组件的初始化。

在一个实施例中，所述配置各个所述组件之间的依赖关系的步骤，包括：

根据各个所述组件的启动顺序、组件之间的调用关系和/或延时启动时间确定所述组件之间的依赖关系。

在第六方面：

本申请提供一种应用程序的组件初始化装置，包括：

组件获取模块，用于在接收到启动信号后获取应用程序的各个组件；其中，所述组件由应用程序的所述功能模块的静态库文件和协议文件封装得到，所述静态库文件包括所述功能模块的实现代码，所述协议文件为以抽象方式对外提供的接口文件，用于给其他组件进行接口调用；

依赖配置模块，用于配置各个所述组件之间的依赖关系，并根据所述依赖关系配置各个组件的初始化顺序；

初始化执行模块，用于响应所述启动信号并根据所述初始化顺序依次对各个组件进行初始化。

在第七方面：

本申请提供一种电子设备，其包括：

一个或多个处理器；

存储器；

一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于：执行如上所述的方法。

在第八方面：

本申请提供一种计算机设备存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上所述的方法。

本申请的技术方案，具有如下技术效果：

(1)通过组件化的开发框架，以抽象方式对外提供接口的协议文件，用于给其他组件进行接口调用，相对于提供类声明的方式对外提供接口调用的强引用关系，该协议文件可以解除组件之间的调用的强引用关系，协议文件和代码实现分离，从而实现了组件之间依赖关系的完全解耦，即使组件具体的代码实现没有被引入到工程中，代码执行也不会崩溃，而且代码实现还可以被替换，极大提升了应用程序的运行效果。

(2)基于上述组件化框架，在进行组件调用时，通过在调用组件的协议文件中配置需要调用的目标对外接口查询实现该目标对外接口的目标组件，将调用组件的调用请求交由目标组件来执行，组件之间相互独立，实现了组件的复用和组件之间的相互调用；在组件未完成初始化之前允许延迟等待直到组件完成初始化，解决了提前调用组件接口导致的异常和崩溃问题。

(3)基于上述组件化框架，组件之间依赖关系的完全解耦，在组件初始化过程中，可以自由配置各个组件之间的依赖关系，并根据该依赖关系配置各个组件的初始化顺序；由于使得应用程序非常容易配置不同组件的依赖关系和初始化顺序，代码更加容易维护和扩展，只需要修改配置参数就能完成启动顺序的调整，只需要增加一行配置代码即可新增业务组件。

进一步的，根据配置的依赖顺序，每一个组件都可以单独配置是否需要在主线程进行串行初始化，也可以配置组件无需在主线程初始化，组件化框架可以为组件分配不同的线程执行并行初始化，以提升应用程序的启动速度；特别是在实际应用中，可以充分利用设备的多核心特性来加快应用程序运行速度，提升应用程序的使用体验。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1是应用程序的组件化方法流程图；

图2是应用程序的组件化装置结构示意图；

图3是应用程序的组件调用方法流程图；

图4是一个示例的执行服务目标方法的流程图；

图5是应用程序的组件调用装置结构示意图；

图6是应用程序的组件初始化方法流程图；

图7是应用程序的组件初始化装置结构示意图；

图8是电子设备的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本申请的技术方案，可以构建移动端组件化开发框架，通过将组件对外的调用接口抽象为协议文件，组件之间通过协议文件进行调用，提供了一种应用程序的组件化开发和解耦调用方案。

参考图1所示，图1是应用程序的组件化方法流程图，包括如下步骤：

S101，配置功能模块的静态库文件；其中，所述静态库文件包括应用程序的所述功能模块的实现代码。

在本实施例方案中，将应用程序App的功能模块实现代码生成静态库文件，执行功能模块的实例。

通常情况下，一个应用程序App包括多个功能模块，不同功能模块之间通过相互调用关系，使用组件化的方案来组织一个应用程序App的功能代码。据此，在本实施例中，可以在配置静态库文件之前，根据所述应用程序的实现功能，将所述应用程序划分为多个功能模块；其中，所述功能模块由至少一个组件实现。

S102，配置所述功能模块的至少一个协议文件；其中，所述协议文件为以抽象方式对外提供的接口文件，用于给其他组件进行接口调用。

本申请采用了以抽象方式对外提供的协议文件，协议文件与静态库文件的实现代码并非一对一绑定关系，而是以抽象方式描述相关接口信息；相对于常规的对外头文件，由于包含与实现代码一一对应的类声明和方法，在其他组件进行调用时，必须要将对外头文件的类型声明引入到项目中，在业务使用时才能调用接口；而本申请通过协议文件方式则解除了这种对应关系，其他组件使用/拷贝协议文件内容，即可以根据协议文件内容调用到对应组件的实例。

对于本实施例中的“协议文件(Protocol)”，是指一系列方法声明的集合。组件(Component)，是指若干源代码组成的业务模块，实现了独立的逻辑功能，对外提供一个或多个的协议文件进行功能调用。

在本实施例中，对于协议文件的形成，可以通过获取所述功能模块的能力信息；将所述能力信息描述为约束规则信息，并以所述约束规则信息为内容生成。

S103，对所述功能模块对应的静态库文件和协议文件进行组件封装。

此步骤是将各个功能模块对应的静态库文件和协议文件进行组件封装过程，以实现组件化框架设计。

具体的，可以通过静态库文件对于功能模块的功能描述，通过协议文件内容将其所有能力描述为了约束规则内容，将该约束规则内容生成协议文件，提供给其他组件作为调用的接口，当其他组件要调用该组件时，可以在本组件的协议文件声明另一个组件的接口；也可以拷贝另一个组件的协议文件到本组件的项目，协议文件不参与编译，主要是解决符号匹配问题，由此，组件之间的调用方式是弱引用关系，只要组件的协议文件中符合了其他约束规则范围，即可调用该组件的接口；而且即使静态库文件的实现代码没有被引入到工程中，由于协议文件与实现代码没有绑定关系，因此调用方代码执行也不会崩溃。

作为实施例，对于上述组件封装过程，可以以所述约束规则信息为实例进行组件封装，并将其与至少一个对外接口进行二次封装成目标组件；其中，所述对外接口为调用所述协议文件的接口。

具体的，通过以约束规则信息为实例进行组件封装，在提供一个对外接口供其他组件进行调用，当其他组件要调用目标组件时，利用其对外接口获取到协议文件中的约束规则信息的实例，该实例是描述功能模块的能力相关规则，并非与静态库文件的实现代码一一绑定的关系，因此该实例执行过程中，即使静态库文件的实现代码不存在或者变更，都不影响该实例的执行，完全实现了关系解耦，代码执行也不会崩溃。

如上所述，本实施例方案，通过组件化的开发框架，以抽象方式对外提供接口的协议文件，用于给其他组件进行接口调用，相对于提供类声明的方式对外提供接口调用的强引用关系，该协议文件可以解除组件之间的调用的强引用关系，协议文件和代码实现分离，从而实现了组件之间依赖关系的完全解耦，即使组件具体的代码实现没有被引入到工程中，代码执行也不会崩溃，而且代码实现还可以被替换，极大提升了应用程序的运行效果。

举例说明：假如一个App-A包含登录和看直播功能，用户在进入看直播之前必须先进行登录，此时直播模块依赖于登录模块。在组件化重构之后，直播模块可以同时被另外一个App使用，称为App-B，App-B实际上没有登录功能，用户不需要登录也能够直接看直播，而通过本申请提供的技术方案就可以实现直播模块和登录模块的完全解耦，App-B不必强引用App-A也可以看直播。

为了更加清晰本申请提供技术方案，下面结合一个应用实例来对应用程序的组件化方法进行进一步描述。

常规方案中，应用程序App的一个功能模块的代码包括了所有的代码实现，并且一般是以头文件提供类声明的方式对外提供接口调用，例如，登录模块组成为：

libhyudb.a：静态库文件，包含已经编译好的实现代码；

HuyaLoginProxy.h：对外头文件，包含类声明和方法；

则对外头文件HuyaLoginProxy.h的内容如下：

类型声明HuyaLoginProxy，其他组件在调用时必须引入这个类型声明才能调用接口，调用方式为：

[[HuyaLoginProxy instance]loginPassport:_usernameTextField.textencPassword:encPasswordappCtx:[selfloginContextStringForType:0]]；//通过类的单例调用登录接口实现账号登录；

上述调用方式强引用关系的调用，当libhyudb.a没有被引入到工程中时，代码执行就会出现崩溃异常。

而采用本申请技术方案的组件化框架，组件的协议文件和实现代码完全分离，其组成为：

LibhyudbWrapper.a静态库文件，包括了所有的实现代码；

Headers/IhyudbService.h协议文件(Protocol)，以抽象方式对外提供的接口文件；

则通过组件封装，相应的的IhyudbService.h的文件内容为：

对应的，该组件的调用方式变为：

[HT_EXECUTOR(IhyudbService)loginPassport:_usernameTextField.textencPassword:encPasswo rd appCtx：[self loginContextStringForType:0]]；//HT_EXECUTOR实现了组件IhyudbService实例的获取，获取实例之后就可以调用其预先定义的登录接口。

基于上述组件化的框架，调用方式是弱引用关系的调用，也就是即使libhyudbWrapper.a没有被引入到工程中，由于执行的实例是登录类型HuyaLoginProxy，并非与实现代码一一对应绑定关系，因此调用组件的代码执行也不会崩溃，并且还可以根据需求随意替换libhyudbWrapper.a的实现。

下面阐述应用程序的组件化装置的实施例。

参考图2所示，图2是应用程序的组件化装置结构示意图，包括：

第一配置模块101，用于配置功能模块的静态库文件；其中，所述静态库文件包括应用程序的所述功能模块的实现代码；

第二配置模块102，用于配置所述功能模块的协议文件；其中，所述协议文件为以抽象方式对外提供的接口文件，用于给其他组件进行接口调用；

组件封装模块103，用于对所述功能模块对应的静态库文件和协议文件进行组件封装。

在本实施例中，第一配置模块101可以在配置静态库文件之前，根据所述应用程序的实现功能，将所述应用程序划分为多个功能模块；其中，所述功能模块由至少一个组件实现。

在本实施例中，第二配置模块102以抽象方式对外提供的协议文件，协议文件与静态库文件的实现代码并非一对一绑定关系，而是以抽象方式描述相关接口信息；相对于常规的对外头文件，由于包含与实现代码一一对应的类声明和方法，在其他组件进行调用时，必须要将对外头文件的类型声明引入到项目中，在业务使用时才能调用接口。对于协议文件的形成，可以通过获取所述功能模块的能力信息；将所述能力信息描述为约束规则信息，并以所述约束规则信息为内容生成。

在本实施例中，组件封装模块103可以通过静态库文件对于功能模块的功能描述，通过协议文件内容将其所有能力描述为了约束规则内容，将该约束规则内容生成协议文件，提供给其他组件作为调用的接口，当其他组件要调用该组件时，可以在本组件的协议文件声明另一个组件的接口；也可以拷贝另一个组件的协议文件到本组件的项目。

对于组件封装模块103的组件封装过程，可以以所述约束规则信息为实例进行组件封装，并将其与至少一个对外接口进行二次封装成目标组件；其中，所述对外接口为调用所述协议文件的接口。

本实施例方案通过组件化的开发框架，以抽象方式对外提供接口的协议文件，用于给其他组件进行接口调用，相对于提供类声明的方式对外提供接口调用的强引用关系，该协议文件可以解除组件之间的调用的强引用关系，协议文件和代码实现分离，从而实现了组件之间依赖关系的完全解耦，即使组件具体的代码实现没有被引入到工程中，代码执行也不会崩溃，而且代码实现还可以被替换，极大提升了应用程序的运行效果。

本申请的应用程序的组件化装置与应用程序的组件化方法一一对应，在应用程序的组件化方法实施例当中相关技术特征及其技术效果，均适用于应用程序的组件化装置实施例中，特此声明。

下面阐述本申请提供的应用程序的组件调用方法的实施例，在阐述应用程序的组件调用方法的相关技术特征，对于组件的定义及其解析，可以依据应用程序的组件化方法实施例中对于组件的定义及其解析。

本申请通过组件化，实现了组件之间实现相互解耦和独立，便于组件的复用，通过本申请的技术方案，组件和组件之间建立的是弱引用关系，在不同组件之间相互调用时，本申请可以实现一种新的应用程序的组件调用方法。

参考图3，图3是应用程序的组件调用方法流程图，包括如下步骤：

S201，在调用组件的协议文件中配置需要调用的目标对外接口；其中，所述协议文件为以抽象方式对外提供的接口文件，用于给其他组件进行接口调用。

本申请采用了以抽象方式对外提供的协议文件，协议文件与静态库文件的实现代码并非一对一绑定关系，而是以抽象方式描述相关接口信息；相对于常规的对外头文件，由于包含与实现代码一一对应的类声明和方法，在其他组件进行调用时，必须要将对外头文件的类型声明引入到项目中，在业务使用时才能调用接口；而本申请通过协议文件方式则解除了这种对应关系，其他组件使用/拷贝协议文件内容，即可以根据协议文件内容调用到对应组件的实例。

在本实施例中，对于配置需要调用的目标对外接口的方法，方案一可以在调用组件的协议文件中声明需要调用的目标对外接口；方案二可以将所述目标组件的协议文件拷贝到调用组件的协议文件中。

对于上述方案一，当其他组件要调用该组件时，可以在本组件的协议文件声明另一个组件的接口，该接口为协议文件的对外接口；对于方案二，通过拷贝另一个组件的协议文件到本组件的项目，协议文件不参与编译，组件之间的调用方式是弱引用关系，只要组件的协议文件中符合了其他约束规则范围，即可调用该组件的对外接口。

S202，根据所述配置的目标对外接口，查询实现该目标对外接口的目标组件；其中，所述目标组件封装有所述目标对外接口，以及应用程序的功能模块的实现代码的静态库文件。

此步骤中，利用应用程序的目标组件所提供的对外接口，在调用之前可以查询目标组件，如果某个目标组件封装有该目标对外接口，再查询目标对外接口是否有可执行的实例，即是否有应用程序的功能模块的实现代码的静态库文件。

S203，根据所述调用组件的调用请求获取所述目标组件的实例，执行所述目标组件的实现代码。

此步骤中，响应调用组件的调用请求获取所述目标组件的实例，通过该获取实例，执行目标组件的实现代码，实现了对目标组件的调用过程。

在本实施例中，在执行所述目标组件的实现代码之前，还可以利用组件管理器查询目标组件是否存在可执行的组件实例对象；若存在，判定所述目标组件已完成初始化，执行所述目标组件的执行的组件实例对象的方法；否则，判定所述目标组件未完成初始化，在指定时间段内等待，直至目标组件完成初始化后，执行所述目标组件的执行的组件实例对象的方法。

上述技术方案，基于上述组件化框架，在进行组件调用时，通过在调用组件的协议文件中配置需要调用的目标对外接口查询实现该目标对外接口的目标组件，将调用组件的调用请求交由目标组件来执行，组件之间相互独立，实现了组件的复用和组件之间的相互调用；在组件未完成初始化之前允许延迟等待直到组件完成初始化，解决了提前调用组件接口导致的异常和崩溃问题。

为了更加清晰本申请提供技术方案，下面结合一个应用实例来对应用程序的组件调用方法进行进一步描述。

参考图4，图4是一个示例的执行服务目标方法的流程图；在该应用实例中，定义了宏T_EXECUTOR，通过宏HT_EXECUTOR来执行服务目标方法的方式：

s401，执行宏HT_EXECUTOR；

具体的，HT_EXECUTOR封装了execute()方法的执行，可以通过execute接口间接实现目标方法的执行；

s402，执行方法调用Execute；

s403，找到其他组件中相同的响应的类型(class For Protocol)；

具体的，Execute()方法根据组件的声明找到其他组件中相同的响应的类型；

s404，获取执行方法签名(instance Method Signature For Selector)；

具体的，根据需要执行的目标方法获取相应的签名，通过方法签名才能确定该实例是否可以执行该目标方法；

s405，根据协议文件获取执行示例(instance For Protocol)；

具体的，可以通过内部的组件管理器查询是否存在可执行组件的实例对象；若是，执行s406，否则执行s407；

s406，通过唤起方法执行目标方法(invoke With Target)，结束；

s407，判断可执行组件的实例对象是否没完成异步初始化过程(allowAsync)；若是，执行s408，

s408，进入等待状态(sleep)；

s409，判断是否满足等待时间(可以设置延迟调用最长等待时间为3秒)；若是，结束调用，否则执行异步调用，返回s405，直到初始化完成后执行目标方法。

通过上述应用实例，由于协议文件与实现代码是完全解耦的，在应用程序App启动的初始化过程中，如果某些组件需要依赖于其他组件，那么在进行方法调用之前，可以先判断目标组件是否已经完成了初始化，通过查找目标组件中是否有可执行实例的方式，如果未初始化，这些组件的执行也不受影响终止，而是可以允许延迟调用则循环等待直到组件完成初始化，从而避免了提前调用组件接口导致的异常和崩溃问题。

下面阐述应用程序的组件调用装置的实施例。

参考图5所示，图5是应用程序的组件调用装置结构示意图，包括：

第三配置模块201，用于在调用组件的协议文件中配置需要调用的目标对外接口；其中，所述协议文件为以抽象方式对外提供的接口文件，用于给其他组件进行接口调用；

组件查询模块202，用于根据所述配置的目标对外接口，查询实现该目标对外接口的目标组件；其中，所述目标组件封装有所述目标对外接口，以及应用程序的功能模块的实现代码的静态库文件；

代码执行模块203，用于根据所述调用组件的调用请求获取所述目标组件的实例，执行所述目标组件的实现代码。

本实施例中，第三配置模块201可以以抽象方式对外提供的协议文件，协议文件与静态库文件的实现代码并非一对一绑定关系，而是以抽象方式描述相关接口信息；通过协议文件方式则解除了这种对应关系，其他组件使用/拷贝协议文件内容，即可以根据协议文件内容调用到对应组件的实例。

本实施例中，组件查询模块202可以利用应用程序的目标组件所提供的对外接口，在调用之前可以查询目标组件，如果某个目标组件封装有该目标对外接口，再查询目标对外接口是否有可执行的实例，即是否有应用程序的功能模块的实现代码的静态库文件。

在本实施例中，代码执行模块203可以在执行所述目标组件的实现代码之前，还可以利用组件管理器查询目标组件是否存在可执行的组件实例对象；若存在，判定所述目标组件已完成初始化，执行所述目标组件的执行的组件实例对象的方法；否则，判定所述目标组件未完成初始化，在指定时间段内等待，直至目标组件完成初始化后，执行所述目标组件的执行的组件实例对象的方法。

对于代码执行模块203，具体是用于响应调用组件的调用请求获取所述目标组件的实例，通过该获取实例，执行目标组件的实现代码，实现了对目标组件的调用过程。

本申请的应用程序的组件调用装置与应用程序的组件调用方法一一对应，在应用程序的组件调用方法实施例当中相关技术特征及其技术效果，均适用于应用程序的组件调用装置实施例中，特此声明。

下面阐述应用程序的组件初始化方法的实施例，在阐述应用程序的组件初始化方法的相关技术特征，对于组件的定义及其解析，可以依据应用程序的组件化方法和应用程序的组件调用方法实施例中对于组件的定义及其解析。

参考图6，图6是应用程序的组件初始化方法流程图，包括如下步骤：

S301，在接收到启动信号后获取应用程序的各个组件；其中，所述组件由应用程序的所述功能模块的静态库文件和协议文件封装得到，所述静态库文件包括所述功能模块的实现代码，所述协议文件为以抽象方式对外提供的接口文件，用于给其他组件进行接口调用。

具体的，可以通过静态库文件对于功能模块的功能描述，通过协议文件内容将其所有能力描述为了约束规则内容，将该约束规则内容生成协议文件，提供给其他组件作为调用的接口，由此，组件之间的调用方式是弱引用关系，只要组件的协议文件中符合了其他约束规则范围，即可调用该组件的接口。

例如，可以以所述约束规则信息为实例进行组件封装，并将其与至少一个对外接口进行二次封装成目标组件；其中，所述对外接口为调用所述协议文件的接口。

S302，配置各个所述组件之间的依赖关系，并根据所述依赖关系配置各个组件的初始化顺序。

具体的，通过组件化的开发框架，协议文件可以解除组件之间的调用的强引用关系，协议文件和代码实现分离，从而实现了组件之间依赖关系的完全解耦，即使组件具体的代码实现没有被引入到工程中，代码执行也不会崩溃，据此，可以在初始化过程当中，根据需要来配置各个组件之间的依赖关系，从而确定各个组件的初始化顺序。

作为实施例，对于配置各个组件之间的依赖关系，可以根据各个所述组件的启动顺序、组件之间的调用关系和/或延时启动时间确定所述组件之间的依赖关系。

此过程中，依赖关系即调用关系，可以根据应用程序App的启动顺序需要，或者组件之间的调用关系需要，或者根据某些组件延时启动的需要来设定各个组件之间依赖关系。

进一步的，对于根据依赖关系配置各个组件的初始化顺序的方法，可以根据所述依赖关系获取需要在主线程初始化的第一类组件，以及不需要在主线程初始化的第二类组件；将所述第一类组件配置为在主线程串行初始化的组件，将所述第二类组件配置为与所述主线程并行初始化的组件。

上述实施例，为了提升应用程序App的启动速度，框架可以给每一个组件都可以单独配置是否需要在主线程初始化，或者为组件分配不同的线程执行并行初始化。

S303，响应所述启动信号并根据所述初始化顺序依次对各个组件进行初始化。

具体的，在初始化启动信号到来时，根据初始化顺序对各个组件进行初始化，作为实施例，可以利用所述主线程执行所述第一类组件的初始化，以及利用其他并行线程执行所述第二类组件的初始化。

例如，可以根据在主线程初始化的组件，按照依赖顺序进行串行初始化，配置无需在主线程初始化的组件，则为组件分配不同的线程执行并行初始化。

上述实施例的方案，基于上述组件化框架，组件之间依赖关系的完全解耦，在组件初始化过程中，可以自由配置各个组件之间的依赖关系，并根据该依赖关系配置各个组件的初始化顺序；由于使得应用程序非常容易配置不同组件的依赖关系和初始化顺序，代码更加容易维护和扩展，只需要修改配置参数就能完成启动顺序的调整，只需要增加一行配置代码即可新增业务组件。并且，根据配置的依赖顺序，每一个组件都可以单独配置是否需要在主线程进行串行初始化，也可以配置组件无需在主线程初始化，组件化框架可以为组件分配不同的线程执行并行初始化，以提升应用程序的启动速度。

采用本实施例的方案，可以充分利用设备的多核心特性来加快应用程序运行速度，提升应用程序的使用体验。

为了更加清晰本申请提供技术方案，下面结合若干应用实例来对应用程序的组件初始化方法进行进一步描述。

在本应用示例中，通过一个应用程序App的启动流程管理来进行描述。在应用程序App通过接入本申请提供框架完成组件化之后，应用程序App的启动流程即为各个业务组件的启动过程，不同的业务对应的组件与组件之间存在相互依赖关系，基于本申请对组件解耦的基础上，可以设置不同组件的初始化顺序并尽可能提升应用程序App的启动性能。

由于本申请的组件化框架支持配置不同组件初始化依赖关系，因此，可以根据需求设置不同的组件之间初始化顺序，下面介绍一个典型的应用程序App启动流程配置部分代码示意如下：

上述部分示意代码完成了业务组件、网络组件(IMTPNetServiceService)、日志组件(IMTPLogService)、推送组件(IhypushsdkService)、登录组件(IhyudbService)、反馈组件(IMTPFeedbackService)等的初始化配置。

具体的，本申请的组件化框架可以提供根据对外接口配置组件之间的依赖关系；在上述示例中，配置网络组件和日志组件启动即执行初始化，配置推送组件和登录组件在网络组件完成初始化制作再执行初始化，配置反馈组件在启动1秒之后再执行初始化。

相对于常规的组件化框架，组件之间的依赖关系是固定的，必须要按照固有顺序去执行初始化，而且是被依赖的组件一旦无法顺利完成初始化过程，那么就会导致调用方也无法继续执行初始化，而且初始化必须依赖于固有顺序串行执行。

而基于本申请的技术方案，接入本申请提供的组件化框架之后，可以非常容易配置不同组件的依赖关系和初始化顺序，同时也让组件的代码更容易维护和扩展，实际应用中，只需要修改配置参数就能完成启动顺序的调整，而且要新增业务组件也只需要增加一行配置代码即可。

如上述示例所示，本申请的技术方案支持配置多个组件并行/串行初始化，每一个组件都可以单独配置是否需要在主线程初始化，同样在主线程初始化的组件会按照依赖顺序进行串行初始化；如果配置组件无需在主线程初始化，则组件化框架可以给组件分配不同的线程执行并行初始化，以提升应用程序App的启动速度。

对于主线程和非主线程的配置接口过程，可以如下：

通过并行初始化处理，可以充分利用设备(如多CPU的智能手机)多核心特性来加快移动终端的应用程序App运行速度，对应用程序App的使用体验来说可以得到极大的提升。

下面阐述应用程序的组件初始化装置的实施例。

参考图7所示，图7是应用程序的组件初始化装置结构示意图，包括：

组件获取模块301，用于在接收到启动信号后获取应用程序的各个组件；其中，所述组件由应用程序的所述功能模块的静态库文件和协议文件封装得到，所述静态库文件包括所述功能模块的实现代码，所述协议文件为以抽象方式对外提供的接口文件，用于给其他组件进行接口调用；

依赖配置模块302，用于配置各个所述组件之间的依赖关系，并根据所述依赖关系配置各个组件的初始化顺序；

初始化执行模块303，用于响应所述启动信号并根据所述初始化顺序依次对各个组件进行初始化。

本实施例中，组件获取模块301可以通过静态库文件对于功能模块的功能描述，通过协议文件内容将其所有能力描述为了约束规则内容，将该约束规则内容生成协议文件，提供给其他组件作为调用的接口，由此，组件之间的调用方式是弱引用关系，只要组件的协议文件中符合了其他约束规则范围，即可调用该组件的接口。

本实施例中，依赖配置模块302可以通过组件化的开发框架，协议文件可以解除组件之间的调用的强引用关系，协议文件和代码实现分离，从而实现了组件之间依赖关系的完全解耦，即使组件具体的代码实现没有被引入到工程中，代码执行也不会崩溃，据此，可以在初始化过程当中，根据需要来配置各个组件之间的依赖关系，从而确定各个组件的初始化顺序。

进一步的，依赖配置模块302在根据依赖关系配置各个组件的初始化顺序时，可以根据所述依赖关系获取需要在主线程初始化的第一类组件，以及不需要在主线程初始化的第二类组件；将所述第一类组件配置为在主线程串行初始化的组件，将所述第二类组件配置为与所述主线程并行初始化的组件。

本实施例中，初始化执行模块303可以在初始化启动信号到来时，根据初始化顺序对各个组件进行初始化，作为实施例，可以利用所述主线程执行所述第一类组件的初始化，以及利用其他并行线程执行所述第二类组件的初始化。

例如，可以根据在主线程初始化的组件，按照依赖顺序进行串行初始化，配置无需在主线程初始化的组件，则为组件分配不同的线程执行并行初始化。

本申请的应用程序的组件初始化装置与应用程序的组件初始化方法一一对应，在应用程序的组件初始化方法实施例当中相关技术特征及其技术效果，均适用于应用程序的组件初始化装置实施例中，特此声明。

下面阐述电子设备的实施例。

本申请提供的电子设备，其包括：一个或多个处理器；存储器；一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于：执行上述任意实施例所指的方法。

如图8所示，图8是电子设备的结构示意图，该电子设备包括：处理器801和存储器803。其中，处理器801和存储器803相连，如通过总线802相连。可选地，计算机设备800还可以包括收发器804。需要说明的是，实际应用中收发器804不限于一个，该电子设备800的结构并不构成对本申请实施例的限定。

处理器801可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器801也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。总线802可包括一通路，在上述组件之间传送信息。总线802可以是PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。总线802可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器803可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器803用于存储执行本申请方案的应用程序的各个组件的代码，并由处理器801来控制执行。处理器801用于执行存储器803中存储的应用程序代码，以实现前述方法实施例所示的内容。

其中，该电子设备包括但不限于：移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图8示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

下面阐述计算机可读存储介质的实施例。

本申请提供的一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，当其在计算机上运行时，使得计算机可以执行前述方法实施例中相应内容。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。