CN116860479A - 信息处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开提供一种信息处理方法、装置、电子设备及存储介质。该方法基于目标框架实现至少一个应用；所述至少一个应用中的每个应用包括：所述应用所提供的服务的接口和逻辑实现，所述逻辑实现用于实现所述服务对应的功能；所述目标框架包括：服务层，用于实现所述至少一个应用提供的服务的接口的注册、导出、查找、监听和注销中的至少一个；应用层，用于管理基于所述至少一个应用所生成的应用实例；资源容器抽象层，将系统资源提供给所述应用层和所述服务层。

Description

信息处理方法、装置、电子设备及存储介质

技术领域

本公开涉及技术领域程序设计，尤其涉及一种信息处理方法、装置、电子设备及存储介质。

背景技术

在程序设计中，程序产品通常包括多个业务模块，各个业务模块分别提供不同的功能，而各个模块之间需要相互通信。通常，一个业务模块的实现需要借助其他业务模块提供的某些能力，使得各个业务模块之间存在相互依赖关系。

随着程序设计的复杂化，业务模块之前的依赖关系可能存在循环依赖，进而导致程序运行出错。

发明内容

有鉴于此，本公开的目的在于提出一种信息处理方法、装置、电子设备及存储介质。

基于上述目的，本公开的第一个方面提供了一种信息处理方法，该方法基于目标框架实现至少一个应用；

所述至少一个应用中的每个应用包括：所述应用所提供的服务的接口和逻辑实现，所述逻辑实现用于实现所述服务对应的功能；

所述目标框架包括：

服务层，用于实现所述至少一个应用提供的服务的接口的注册、导出、查找、监听和注销中的至少一个；

应用层，用于管理基于所述至少一个应用所生成的应用实例；

资源容器抽象层，将系统资源提供给所述应用层和所述服务层。

本公开的第二个方面提供了一种信息处理装置，包括：

应用模块，被配置为：基于目标框架实现至少一个应用；所述至少一个应用中的每个应用包括：所述应用所提供的服务信息的接口和所述应用所提供的服务信息的逻辑实现信息，所述逻辑实现信息用于实现所述接口的功能；

目标框架，包括：服务层，用于实现用于实现所述至少一个应用提供的服务信息的接口的注册、导出、查找、监听和注销中的至少一个；应用层，用于管理基于所述至少一个应用所生成的应用实例；资源容器抽象层，将系统资源提供给所述应用层和所述服务层。

本公开的第三个方面提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如第一个方面所述的方法。

本公开的第四个方面提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，其中，所述计算机指令用于使计算机执行第一个方面所述的方法。

从上面所述可以看出，本公开提供的信息处理方法、装置、电子设备及存储介质，将各个应用的接口和逻辑实现分开，通过目标框架实现各个应用的功能，通过服务层实现各应用提供的服务的接口的注册、导出、查找、监听和注销，通过应用层管理应用实例，通过资源容器抽象层将系统资源提供给应用层和服务层，从而避免各个应用之间形成循环依赖，解决因各个应用之间循环依赖导致的程序错误问题。

附图说明

为了更清楚地说明本公开或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1A示出了相关技术中一种示例性依赖关系示意图。

图1B示出了相关技术中一种示例性依赖关系示意图。

图1C示出了相关技术中一种示例性依赖关系示意图。

图2示出了相关技术中一种示例性结构示意图。

图3示出了本公开实施例所提供的一种示例性框架结构示意图。

图4示出了本公开实施例所提供的一种示例性框架结构示意图。

图5示出了本公开实施例所提供的一种示例性方法的流程示意图。

图6示出了本公开实施例所提供的另一示例性装置的示意图。

图7示出了本公开实施例所提供的示例性计算机设备的硬件结构示意图。

具体实施方式

为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。

需要说明的是，除非另外定义，本公开实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

如背景技术所述，一个业务模块的实现需要借助其他业务模块提供的某些能力，例如某业务模块提供一个函数，另一个业务模块在实现其自身功能时需要调用该函数，这使得这两个业务模块之间存在一条显式的直接依赖。

采用Rust编程语言编写的程序产品可包括多个可编译单元(crate)。其中，一个可编译单元可以对应于程序产品中的一个业务模块，也可以对应于程序产品中的一个子业务模块，本公开实施例对此不作限制。

不同的可编译单元之间可以相互通信，一个可编译单元在实现其自身功能时需要其他可编译单元提供的功能，即一个可编译单元需要依赖其他的可编译单元来实现其业务功能。这就会存在循环依赖的可能。例如，crateA依赖crateB、crateB依赖crateC……crateM依赖crateN、crateN依赖crateA。当可编译单元之间的依赖关系为循环依赖时，可编译单元难以获得其他可编译单元的能力，这会影响可编译单元的编译。

其中，依赖是指：一个应用(application)在业务逻辑中要借助其他应用提供的某些能力处理问题，例如提供一个函数，然后直接调用它。这会导致两个应用之间有了一条显式的直接依赖，在Rust中体现为两个可编译单元之间有了依赖关系。

为了便于描述该问题，本公开以crateA依赖crateB，且crateB依赖crateA为例阐述循环依赖所存在的问题。如图1A所示，该示例性实施例示出了crateA依赖crateB且crateB依赖crateA使得crateA、crateB之间存在循环依赖的情况。

当crateA依赖crateB时，若需要对crateA进行编译时，需要提前对crateB进行编译，获得crateB的编译结果后，才能够对crateA进行编译；当crateB依赖crateA时，若需要对crateB进行编译时，需要提前对crateA进行编译，获得crateA的编译结果后，才能够对crateB进行编译。而crateA、crateB之间循环依赖，没有一个开始点可以编译，就无法成功编译，导致程序运行出错。

当应用程序中包括多个应用时，各个应用之间的依赖关系复杂，新增、修改或删除应用时很容易导致各个应用之间出现循环依赖，进而无法找到一个开始点可以编译，就无法成功编译，导致程序运行出错。

相关技术中，如图2所示，每个业务模块可包括位于业务层的上层业务逻辑以及位于基础业务层的下层业务基础支持逻辑，例如聊天模块包括位于业务层的聊天业务(chat)以及位于基础业务层的聊天业务基础(chat-base)。

如图1B所示，当设置crateA依赖crateB时，可另上层业务逻辑A依赖下层业务基础支持逻辑B Base；当设置crateB依赖crateA时，可另上层业务逻辑B依赖下层业务基础支持逻辑A Base，这样可以改善循环依赖的问题，但是循环依赖仍然会存在。

如图1C所示，在业务层和基础业务层之间还存在逻辑层(logic)，在逻辑层存储依赖于下层业务基础支持逻辑但是又不能存放在业务层的各种逻辑，使得逻辑层包含各个业务模块的桥接逻辑的集合，导致所有的业务层的各个上层业务逻辑都依赖逻辑层，而逻辑层又依赖基础业务层的各个下层业务基础支持逻辑，使得逻辑层自身成为了一个依赖节点，这使得对逻辑层的逻辑拆分以及对逻辑层所依赖的下层业务基础支持逻辑的删减都很困难，导致维护成本很高。

相关技术中还可以采用全局变量来存储各个业务模块的依赖信息(例如所依赖函数的地址)，这样各个可编译单元可通过访问全局变量来实现其依赖关系。但是，由于各个应用模块都需访问全局变量，导致全局变量中存储的用户资源很容易被修改或误删，进而也容易导致程序出错，且一旦出现问题难以追查分析。

有鉴于此，本公开实施例提供一种信息处理方法，以解决上述问题。

如图3所示，所述信息处理方法方法基于目标框架实现至少一个应用；所述至少一个应用中的每个应用包括：所述应用所提供的服务的接口和逻辑实现，所述逻辑实现用于实现所述服务对应的功能。其中，所述应用所提供的服务可以包括函数调用和事件(event)派发。

所述目标框架包括：服务层，用于实现所述至少一个应用提供的服务的接口的注册、导出、查找、监听和注销中的至少一个；应用层，用于管理基于所述至少一个应用所生成的应用实例；资源容器抽象层，将系统资源提供给所述应用层和所述服务层。

如图3所示，每个应用可包括该应用提供的服务的接口和逻辑实现，其中该应用的接口用于定义该应用所属业务对外提供的接口，比如定义该应用所提供的服务的特征(trait)、与其他应用共享的数据结构、这个应用触发的事件定义等。该应用的接口只包含该应用的抽象接口而不包括该应用所提供的服务的具体实现逻辑。该应用的逻辑实现则包括该应用所提供的服务的具体逻辑实现。

其中，服务层(service layer)管理每个应用对外暴露的能力的抽象。一个服务(service)可以包括一组抽象接口与数据结构的集合，一个应用可以对外提供多个服务；目标框架负责服务的注册、导出、查找、监听和注销。同时，目标框架自身暴露的能力也可以通过服务层进行抽象，这样得到的就是一组预置或标准的服务。

应用层(application layer)用来描述每一个业务实体。其中，每一个业务实例都看成是独立的应用，每个应用都属于某个容器(Container)，自然可以访问关联该容器范围内的各种系统资源；目标框架用于管理应用的初始化，析构等生命周期流程。

资源容器抽象层(resource container layer)对下面系统层能力进行抽象，定义一系列数据结构和接口集合；该层次抽象结构(指Container)的生命周期可以映射为相关系统资源的生命周期(至少是有关联的)。其中，系统资源可包括文件系统，数据库，网络等，本申请通过资源容器抽象层对系统资源进行抽象和管理，从而可以使得该目标框架可以兼容运行多种运行时场景。同时，可通过资源容器抽象层对系统资源进行某个维度的管控，例如针对用户的管控。避免各个应用直接依赖不可控的第三方API，避免破坏某个平台的兼容性。

本实施例中，将各个应用的接口和逻辑实现分开，通过目标框架实现各个应用的功能，无需逻辑层这样的依赖节点；通过服务层实现各应用提供的服务的接口的注册、导出、查找、监听和注销，通过应用层管理应用实例，通过资源容器抽象层将系统资源提供给应用层和服务层，从而避免各个应用之间形成循环依赖，解决因各个应用之间循环依赖导致的程序错误问题。

在一些实施例中，所述目标框架中的服务层、应用层和资源容器抽象层具有上层依赖下层的依赖关系，即服务层依赖应用层，应用层依赖资源容器抽象层。同时，从生命周期的角度，上层的实例的生命周期小于等于下层对应实例的生命周期。例如，对于容器A的两个应用a和应用b，应用a或应用b的单独卸载都不会触发容器A的析构，只有二者都卸载才有可能触发用户A相关资源的释放。同理，如果用户A和用户B共享某个文件或其他资源，只有当两个用户都退出后该资源才能得到释放。

在一些实施例中，目标框架的服务层、应用层和资源容器抽象层是目标框架内部的抽象概念。也就是说，目标框架的使用者按照预设规则(例如包管理工具cargo)引入该目标框架并可以直接使用它，而不是说目标框架的使用方需要将自身的架构设计成如图3所述的层级形式，仅需将相应业务的业务逻辑抽象为目标框架中的实体。

在一些实施例中，所述接口的信息包括接口参数和返回值类型，且所述至少一个应用中的每个应用的接口参数和返回值类型不依赖于其他应用定义。

本实施例中，应用的接口的信息可包括接口参数和返回值类型。而接口会产生依赖主要是因为参数和返回值类型依赖其他的应用。如果确保参数和返回值类型是同一个可编译单元(crate)内部定义的，就可以认为这个可编译单元(crate)是自描述的，无任何外部依赖。

在本实施例中，各个应用的接口A逻辑实现分别通过接口可编译单元(crate)和逻辑实现可编译单元(crate)实现，且每个应用的逻辑实现可编译单元可以依赖其他应用的接口可编译单元(crate)，但不依赖于其他应用的逻辑实现可编译单元(crate)。

在一些实施例中，逻辑实现可编译单元不依赖于其他可编译单元，包括该逻辑实现可编译单元不依赖于Rust标准库之外其他的可编译单元，在有需要的情况下可以依赖protobuf等库。

在相关技术中，使用方应用需要根据场景判断当前需要调用哪个应用来实现其功能，此时需要使用方应用来获取正确的实现方应用，在这种情况下，当使用方应用的越多，需要判断的逻辑越多，出错的概率越大。

本实施例中，将应用提供的对外能力抽象为服务，使用方应用需要调用实现应用时，使用方应用只需要知道自己使用哪些服务，而无需了解是哪个应用提供的这些能力。这样既完成了接口的定义，又保留了服务实现方有一定的扩展和重构的能力。这样，当使用某一个应用或者某个策略逻辑时，不同场景下逻辑选择的责任由调用一方应用转移到实现一方应用，即使使用方数量不断增长也无问题，因为逻辑收敛方在实现方，从而可以减轻使用方应用的维护压力，也实现了选择逻辑的解耦。

应用程序中会存在动态加载/卸载的场景，如节能模式、模块管控等，对应于目标框架中处理某些服务不存在或需要替换的情况。因此在本实施例中，当需要下线某一应用时，目标框架可以及时响应该请求，对于正在处理的服务则不受影响。

本实施例中，通过目标框架将应用的接口和逻辑实现完全分开，每个应用的接口参数和返回值类型不依赖于其他应用定义，通过目标框架来实现依赖注入，避免各个应用之间形成循环依赖，解决因各个应用之间循环依赖导致的程序错误问题。

在一些实施例中，如图3所示，所述至少一个应用包括第一应用A和第二应用B。为了便于陈述本申请的技术方案，本申请以所述至少一个应用包括第一应用A和第二应用B为例陈述本申请的技术方案，当所述至少一个应用还包括其他应用时，其功能实现方法与第一应用A和第二应用B相同，本实施例在此不再赘述。

其中，第一应用A包括第一应用A提供的服务的A接口和A逻辑实现，其中第一应用A的A接口用于定义第一应用A所属业务对外提供的接口，比如定义第一应用A所提供的服务的特征(trait)、与其他应用共享的数据结构、这个应用触发的事件定义等。A接口只包含应用A的抽象接口而不包括应用A所提供的服务的具体实现逻辑。A逻辑实现则包括A所提供的服务的具体逻辑实现。第二应用B也包括第一应用B提供的服务的B接口和B逻辑实现，且B接口和B逻辑实现与A接口和A逻辑实现的作用相同，本实施例在此不再赘述。

在一些实施例中，所述至少一个应用还可以包括除第一应用A和第二应用B以外的其他应用，且这些应用也包括相应应用的接口和逻辑实现，且这些应用的接口和逻辑实现与A接口和A逻辑实现的作用相同，本实施例在此不再赘述。

在本实施例中，第一应用A的A接口和A逻辑实现分别通过A接口可编译单元(crate)和A逻辑实现可编译单元(crate)实现，第二应用B的B接口和B逻辑实现分别通过B接口可编译单元(crate)和B逻辑实现可编译单元(crate)实现，且每个应用的逻辑实现可编译单元可以依赖其他应用的接口可编译单元(crate)，但不依赖于其他应用的逻辑实现可编译单元(crate)。

在一些实施例中，每个应用的逻辑实现需要封装到业务自定义的结构体里，从而可以可以为每个用户创建一个业务模块的实例，即应用，这样不同用户间的业务状态就不会互相影响了。

应用在创建的时候会接收一个其所属容器的句柄(handle)对象，这个句柄对象提供了与目标框架进行交互的功能，比如服务查询、事件处理等等。应用可以选择将这个句柄对象保存在应用的实例中，然后就可以在业务中使用这个句柄对象中提供的功能了。

在一些实施例中，如图5所示，所述信息处理方法，还包括：

步骤S101，将所述至少一个应用所提供的服务注册至所述目标框架的服务层。

本步骤中，需要将每个应用所提供的服务注册至目标框架的服务层，这样目标框架的服务层即可得知每个应用所能够提供的服务。

可选的，各个应用在注册时可以仅注册各个应用所提供的服务，而不执行各个应用上的逻辑实现。

即在本申请中，通过目标框架的服务层对各个应用的依赖进行收敛管理，

步骤S103，响应于所述第一应用接收第一请求，基于所述第一请求获取所述第一应用所需的第一依赖信息。

当第一应用接收到第一请求，第一应用基于该第一请求运行。在第一应用运行的过程中，需要依赖其他应用才能对第一请求进行响应。此时，第一应用获取其对第一请求进行响应所需的第一依赖信息。

在本实施例中，第一应用仅知道其为对第一请求进行响应需要第一依赖信息，而不知道第一依赖信息是属于哪个应用。

其中，第一依赖信息可以是例如可以是函数等，本实施例对此不作限制。

步骤S105，所述第一应用将所述第一依赖信息发送至所述目标框架的服务层。

第一应用获取其所需的第一依赖信息后，将第一依赖信息发送至目标框架的服务层。

步骤S107，所述目标框架的服务层确定与所述第一依赖信息对应的服务属于所述第二应用，在所述目标框架的应用层确定与所述第二应用对应的第二应用实例，基于所述第二应用实例获得与所述第一依赖信息对应的返回结果，并将所述返回结果发送至所述第一应用。

由于各个应用已将其所能提供的服务提前注册到目标框架的服务层，因此服务层在接收到第一应用所发送的第一依赖信息，即可确定哪个应用所提供的服务能够满足该第一依赖信息的需要。

本实施例中，假设第二应用所提供的服务与第一依赖信息对应，则基于第二应用所提供的服务从目标框架的应用层确定与所述第二应用对应的第二应用实例，并基于第二应用实例获取与第一依赖信息对应的返回结果发送至第一应用。其中，第二应用实例是基于第二应用以及与第二应用对应的业务数据所生成的。

步骤S109，所述第一应用基于所述返回结果对所述第一请求进行响应。

第一应用在获取了与第一依赖信息对应的返回结果后，即可基于该返回结果对第一请求进行响应。

本实施例中，通过将各个应用所提供的服务注册至目标框架的服务层，这样当第一应用需要依赖其他应用时，该第一应用无需得知其具体依赖哪一个应用，而是将其依赖信息直接发送至目标框架的服务层；由于目标框架的服务层已经存储了各个应用所能够提供的服务，因此目标框架的服务层即可基于第一应用所需的依赖信息确定其所需要的服务属于哪个应用，即第二应用，之后即可利用目标框架的应用层中与第二应用对应的第二应用实例进行响应获得针对依赖信息的相应信息，以使得第一应用能够对第一请求进行相应。

在一些实施例中，以demo应用为例，详细陈述本申请的技术方案。其中，demo应用包括两个应用：第一个compare应用会比较两个数字的大小；第二个echo应用有回显(echo)的功能。

demo应用首先启动echo应用，echo应用会调用compare应用比较两个数字的大小；compare应用接着会调用echo应用的回显功能打印一个字符串；

在compare应用比较数字的过程中还会派发一个事件，echo应用接收这个事件并打印；

将compare应用和echo应用分为对应于该应用的接口和逻辑实现，即接口crate和逻辑实现crate。

之后，需要定义容器的实例。由于在目标框架中容器的概念是更基础的概念，它可以看成是应用的容器。因此在创建应用实例的时候首先要创建一个容器的实例。其中，目标框架的容器用于对硬件资源的抽象和管理，容器内部可对文件系统、DB、异步运行时以及容器级别的内存cache做出定义。如图4所示，容器的创建位于顶层的壳工程中，因为这个壳工程有负责初始化各个应用的职责。

容器实例定义完成后，需要定义、注册应用的实例。其中，在定义应用实例时，需要确定类型参数A即我们定义的应用类型；类型参数T则是Container<T>中指定的，这个定义本质是提供一个lambda并返回Arc<A>实例。

之后，分别创建compare应用和echo应用各自的应用实例和对应的lambda函数。

之后，在compare应用和echo应用的接口crate中分别定义各自的接口，并在各自的逻辑实现crate中定义两个应用各自的服务(service)。

之后，将两个应用的服务注册到目标框架的服务层上，以便于其他应用可以查询并调用它。在一些实施例中，步骤S107中所述目标框架的服务层确定与所述第一依赖信息对应的服务属于所述第二应用之后，还包括：

步骤S201，判断所述第二应用是否初始化。

步骤S203，若所述第二应用未初始化，则初始化所述第二应用，基于所述第二应用所提供的服务的逻辑实现在所述目标框架的应用层生成与所述第二应用对应的所述第二应用实例。

在本实施例中，步骤S101中将各个应用所提供的服务注册至目标框架的服务层，可以在各个应用初始化之前进行。也就是说，在各个应用初始化之前，可先将各个应用所提供的服务注册至目标框架的服务层。

这样，当步骤S107中确定了与第一依赖信息对应的服务属于第二应用之后，若第二应用已初始化，即目标框架的应用层已经存在与第二应用对应的第二应用实例，则可直接基于第二应用实例对第一依赖信息进行响应，从而获得返回信息。

若第二应用尚未初始化，则无法在目标框架的应用层确定与第二应用对应的第二应用实例。因此，在确定了与第一依赖信息对应的服务属于第二应用之后，需要先判断第二应用是否初始化，若第二应用尚未初始化，则初始化第二应用。

在一些实施例中，目标框架可向第二应用发送第二信息，第二应用接收该第二信息后即可初始化第二应用。在第二应用时，第二应用可向目标框架发送第一注册请求，基于该第一注册请求即可在目标框架的应用层生成与所述第二应用对应的第二应用实例。在一些实施例中，可基于第二应用所提供的服务的逻辑实现在目标框架的应用层创建与第二应用对应的第二应用实例。

在目标框架的应用层生成第二应用实例后，即可利用第二应用实例对第一依赖信息进行响应，从而获得与第一依赖信息对应的返回结果，以使得第一应用基于返回结果对所述第一请求进行响应。

相关技术中，若对于至少一个应用的每个应用来说，当确定了某一个应用需要依赖其他应用时，例如第一应用依赖第二应用，若第二应用尚未初始化，则第二应用无法对第一应用的依赖信息进行响应，这可能会导致程序出错，但是本申请中即使第二应用尚未初始化，也可以则通过目标框架来使得第二应用进行初始化，从而使得初始化后的第二应用能够对第一应用的依赖信息进行响应，从而避免程序运行时锁死。

在一些实施例中，步骤S203所述初始化所述第二应用之前，还包括：

步骤S301，所述第二应用将所述第二应用初始化所需的第二依赖信息发送至所述目标框架的服务层。

步骤S303，所述目标框架的服务层确定与所述第二依赖信息对应的服务属于第三应用，向所述第三应用发送第一信息，以使所述第三应用基于所述第一信息初始化。

本实施例中，当第二应用初始化时也需要依赖其他应用时，其可以将其所需的依赖信息即第二依赖信息发送至目标框架的服务层；由于目标框架的服务层事先已经存储了各个应用所提供的服务，因此目标框架的服务层可以确定与第二依赖信息对应的服务属于哪个应用，例如可以为第三应用，这样，当第三应用已初始化并在目标框架的应用层创建了与第三应用对应的第三应用实例，则可直接基于第三应用实例对第二依赖信息进行响应；若第三应用尚未初始化，则目标框架可向第三应用发送第一信息，第三应用在接收到该第一信息即可进行初始化，并基于第三应用的逻辑实现在目标框架的应用层创建与第三应用对应的第三应用实例，再基于第三应用实例对第二依赖信息进行响应。

可选的，若第三应用初始化需要依赖其他应用，再通过目标框架的服务层确定第三应用初始化需要依赖的应用，再通过目标框架使该应用初始化……这样，以第一应用为触发源，通过目标框架来确定各个应用初始化的顺序，并使得各个应用按照顺序初始化，从而使得任一应用在被使用时，与第一应用具有依赖关系的应用均可以初始化成功，避免程序运行时锁死；同时，各个应用在初始化或运行时，无需关注应用本身在哪个应用之前或在哪个应用之后初始化，通过目标框架来确定各个应用的初始化顺序，使得用户在设置各个应用之间依赖关系时，无需了解清楚每个应用的初始化顺序，便于用户的使用。

在一些实施例中，所述第一请求包括初始化请求；所述第一应用基于所述请求结果对所述第一请求进行响应，包括：基于所述请求结果，在所述目标框架的应用层生成基于所述第一应用的第一应用实例。

本实施例中，当第一请求是初始化请求时，通过目标框架确定第一应用的初始化时需要依赖第二应用，从而基于目标框架中第二应用的第二应用实例获得相应的返回结果，并基于返回结果以及第一应用的相关信息，例如第一应用的数据、逻辑实现等在目标框架的应用层创建与第一应用对应的第一应用实例，完成对第一应用的初始化。

在一些实施例中，所述第一请求包括服务调用请求；所述第一应用基于所述请求结果对所述第一请求进行响应，包括：基于所述返回结果以及所述第一应用所提供的服务对所述第一请求进行响应。

本实施例中，当第一请求是服务调用请求时，即需要调用第一应用时，通过目标框架确定第一应用的被调用时需要依赖第二应用，从而基于目标框架中第二应用的第二应用实例获得相应的返回结果，并基于返回结果以及第一应用所提供的服务，例如基于第一应用的第一应用实例对第一请求进行响应，从而实现对第一应用的调用。

在一些实施例中，所述方法，还包括：

步骤S401，通过所述至少一个应用的接口将所述至少一个应用所关注的事件注册至所述目标框架的服务层。

步骤S403，所述至少一个应用中的目标应用向所述目标框架的服务层发送事件触发请求。

步骤S405，所述目标框架的服务层获取与所述事件触发请求对应的第一事件，并确定所述第一事件所属的指定应用。

步骤S407，通过所述指定应用对所述第一事件进行响应。

本实施例中，可通过目标框架实现事件(event)的管理。其中，事件(event)作为事件派发的目标对象与媒介，其通常作为多方沟通的桥梁角色，因此事件(event)的定义设置在应用的接口crate中，便于其他业务实现者看到它。

当所述至少一个应用中的一个或多个应用需要关注一些事件时，可通过一个或多个应用的接口将该应用所关注的事件注册至目标框架的服务层，这样，目标框架的服务层可知道各个应用所关注的事件。

当某一目标应用会触发某些事件(例如第一事件)时，该目标应用会将其需要触发的事件通过事件触发请求发送至目标框架的服务层。由于目标框架的服务层存储了各个应用所关注的事件，则目标框架的服务层可以确定目标应用所触发的第一事件是哪些应用所关注的，例如指定应用关注该第一事件，则目标框架会告知指定应用其关注的第一事件已被触发，这样指定应用即可对第一事件进行响应。

与服务类似，事件(Event)作为事件派发的目标对象与媒介，是多方沟通的桥梁角色，因此它的定义应当放在业务的接口crate中，便于其他业务实现者看到它。定义了EchoEvent类型，其本质上是一个String类型的包装，目标框架要求派生宏reckoner::container::Event的使用，使用基于TypeId事件派发模型时，具体的事件类型需要实现trait Event。

之后，需要注册接收事件的类型。与注册服务(Service)类似，如果希望接收定义的事件类型，则需要注册以告知目标框架需要关注的事件，假设compare应用希望获得该事件派发时的通知，则需要compare应用将其关注的事件注册至目标框架。其中，该方法是属于容器Container<T>类型的。

其中，需要定义订阅的目标事件类型以及当该事件派发时接收通知的回调，其中订阅的目标事件类型的限定条件是需要实现派生宏::reckoner::container::Event。派发事件的接口是定义在ContainerHandle<T>。

对于基于哈希的事件派发，与基于TypeId的事件派发类似，都是实现一个trait；注册一个回调；派发一个对象。本实施例在此不再赘述。

在一些实施例中，所述目标框架设置于容器中；所述方法，还包括：基于所述至少一个应用生成的属于同一用户的数据存储于同一容器中；基于所述至少一个应用生成的属于不同用户的数据存储于不同容器中。

本实施例中，可将目标框架设置于容器中，并且同一用户在一个或多个应用所生成的数据存储在同一个容器中，从而保证同一用户的数据在同一个容器内可以相互通信；同时，不同用户在一个或多个应用所生成的数据存储在不同容器中，从而保证不同用户的数据在不同的容器中不能通信，从而避免串数据。

其中，用户也可以为租户，即本实施例中同一租户在一个或多个应用所生成的数据存储在同一个容器中，从而保证同一租户的数据在同一个容器内可以相互通信；同时，不同租户在一个或多个应用所生成的数据存储在不同容器中，从而保证不同租户的数据在不同的容器中不能通信，从而使得在用户在进行租户切换时不会串数据，保证租户的数据安全。

在一些实施例中，可将应用程序中的业务对应于应用，即目标框架使用应用(Application)概念来表达业务的概念，应用是一个遵循了某些特征(trait)限定的结构体(struct)实例；应用实例有生命周期，创建/回收由目标管理。即对应聊天等业务crate，需要提供一个符合条件的结构体(struct)类型，目标框架会在适当的时机初始化这些结构体的实例。

业务的对外能力对应服务(Service)，很多业务需要向外(它的兄弟业务)提供一些能力辅助完成一些业务需求，这些能力需要抽象成一个或一组特征(trait)定义，业务实现这些特征(trait)，能力依赖方调用这些特征(trait)。

业务单元隔离能力对应容器(Container)，一些应用程序中包括租户，不同的租户使用不同的沙盒资源，在目标框架中，使用容器(Container)对应这个沙盒的概念。每一个容器(Container)都有独立的系统资源，包括文件系统、DB数据、网络请求能力等。一个容器(Container)可以包含多个应用，一个容器(Container)可以提供和实现多组服务。

在目标框架中，应用实例满足下面的条件：应用具有类型T的概念；目标框架中包括Arc<T>引用，即从而可以通过目标框架决定对象何时析构。对于同一个容器(Container)，同一个应用的类型T只可能最多存在一份实例；但不同的容器(Container)之间互不影响，即同一个业务对象可以存在多份，但一定从属于不同的容器(Container)空间；容器(Container)的生命周期一定长于属于它的任何一个应用实例的生命周期，如果某个容器(Container)至少还存在有一个应用实例，那么该容器(Container)就不会被目标框架析构；位于同一个容器(Container)下的应用之间共享同一份容器(Container)抽象的硬件资源，不同容器(Container)之间互不影响；应用只能查询到同一个容器(Container)下其他应用提供的服务，不同的容器(Container)之间互不影响。

需要说明的是，本公开实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本公开实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。

需要说明的是，上述对本公开的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种信息处理装置。

参考图6，所述装置，包括：

应用模块11，被配置为：基于目标框架实现至少一个应用；所述至少一个应用中的每个应用包括：所述应用所提供的服务信息的接口和所述应用所提供的服务信息的逻辑实现信息，所述逻辑实现信息用于实现所述接口的功能；

目标框架13，包括：服务层，用于实现用于实现所述至少一个应用提供的服务信息的接口的注册、导出、查找、监听和注销中的至少一个；应用层，用于管理基于所述至少一个应用所生成的应用实例；资源容器抽象层，将系统资源提供给所述应用层和所述服务层。

在一些实施例中，所述接口的信息包括接口参数和返回值类型，且所述至少一个应用中的每个应用的接口参数和返回值类型不依赖于其他应用定义。

在一些实施例中，所述至少一个应用包括第一应用和第二应用；所述装置，还被配置为：

将所述至少一个应用所提供的服务注册至所述目标框架的服务层；

响应于所述第一应用接收第一请求，基于所述第一请求获取所述第一应用所需的第一依赖信息；

所述第一应用将所述第一依赖信息发送至所述目标框架的服务层；

所述目标框架的服务层确定与所述第一依赖信息对应的服务属于所述第二应用，在所述目标框架的应用层确定与所述第二应用对应的第二应用实例，基于所述第二应用实例获得与所述第一依赖信息对应的返回结果，并将所述返回结果发送至所述第一应用；

所述第一应用基于所述返回结果对所述第一请求进行响应。

在一些实施例中，所述目标框架的服务层确定与所述第一依赖信息对应的服务属于所述第二应用之后，所述装置，还被配置为：

判断所述第二应用是否初始化；

若所述第二应用未初始化，则初始化所述第二应用，基于所述第二应用所提供的服务的逻辑实现在所述目标框架的应用层生成与所述第二应用对应的所述第二应用实例。

在一些实施例中，所述初始化所述第二应用之前，所述装置，还被配置为：

所述第二应用将所述第二应用初始化所需的第二依赖信息发送至所述目标框架的服务层；

所述目标框架的服务层确定与所述第二依赖信息对应的第二服务属于第三应用，向所述第三应用发送第一信息，以使所述第三应用基于所述第一信息初始化。

在一些实施例中，所述第一请求包括初始化请求；所述装置，还被配置为：基于所述返回结果，在所述目标框架的应用层生成基于所述第一应用的第一应用实例。

在一些实施例中，所述第一请求包括服务调用请求；所述第一应用基于所述返回结果对所述第一请求进行响应，包括：

基于所述返回结果以及所述第一应用所提供的服务对所述第一请求进行响应。

在一些实施例中，所述装置，还被配置为：

通过所述至少一个应用的接口将所述至少一个应用所关注的事件注册至所述目标框架的服务层；

所述至少一个应用中的目标应用向所述目标框架的服务层发送事件触发请求；

所述目标框架的服务层获取与所述事件触发请求对应的第一事件，并确定所述第一事件所属的指定应用；

通过所述指定应用对所述第一事件进行响应。

在一些实施例中，所述目标框架设置于容器中所述装置，还被配置为：

基于所述至少一个应用生成的属于同一用户的数据存储于同一容器中；

基于所述至少一个应用生成的属于不同用户的数据存储于不同容器中。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本公开时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

上述实施例的装置用于实现前述任一实施例中相应的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的方法。

图7示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

上述实施例的电子设备用于实现前述任一实施例中相应的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的方法。

本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本公开实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本公开实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本公开实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本公开实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本公开的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本公开实施例。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本公开的具体实施例对本公开进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本公开实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本公开实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (12)

1.一种信息处理方法，其中，该方法基于目标框架实现至少一个应用；

所述至少一个应用中的每个应用包括：所述应用所提供的服务的接口和逻辑实现，所述逻辑实现用于实现所述服务对应的功能；

所述目标框架包括：

服务层，用于实现所述至少一个应用提供的服务的接口的注册、导出、查找、监听和注销中的至少一个；

应用层，用于管理基于所述至少一个应用所生成的应用实例；

资源容器抽象层，将系统资源提供给所述应用层和所述服务层。

2.根据权利要求1所述的方法，其中，所述接口的信息包括接口参数和返回值类型，且所述至少一个应用中的每个应用的接口参数和返回值类型不依赖于其他应用定义。

3.根据权利要求1所述的方法，其中，所述至少一个应用包括第一应用和第二应用；所述方法，还包括：

将所述至少一个应用所提供的服务注册至所述目标框架的服务层；

响应于所述第一应用接收第一请求，基于所述第一请求获取所述第一应用所需的第一依赖信息；

所述第一应用将所述第一依赖信息发送至所述目标框架的服务层；

所述目标框架的服务层确定与所述第一依赖信息对应的服务属于所述第二应用，在所述目标框架的应用层确定与所述第二应用对应的第二应用实例，基于所述第二应用实例获得与所述第一依赖信息对应的返回结果，并将所述返回结果发送至所述第一应用；

所述第一应用基于所述返回结果对所述第一请求进行响应。

4.根据权利要求3所述的方法，其中，所述目标框架的服务层确定与所述第一依赖信息对应的服务属于所述第二应用之后，还包括：

判断所述第二应用是否初始化；

若所述第二应用未初始化，则初始化所述第二应用，基于所述第二应用所提供的服务的逻辑实现在所述目标框架的应用层生成与所述第二应用对应的所述第二应用实例。

5.根据权利要求4所述的方法，其中，所述初始化所述第二应用之前，还包括：

所述第二应用将所述第二应用初始化所需的第二依赖信息发送至所述目标框架的服务层；

所述目标框架的服务层确定与所述第二依赖信息对应的第二服务属于第三应用，向所述第三应用发送第一信息，以使所述第三应用基于所述第一信息初始化。

6.根据权利要求3所述的方法，其中，所述第一请求包括初始化请求；所述第一应用基于所述返回结果对所述第一请求进行响应，包括：

基于所述返回结果，在所述目标框架的应用层生成基于所述第一应用的第一应用实例。

7.根据权利要求3所述的方法，其中，所述第一请求包括服务调用请求；所述第一应用基于所述返回结果对所述第一请求进行响应，包括：

基于所述返回结果以及所述第一应用所提供的服务对所述第一请求进行响应。

8.根据权利要求3所述的方法，还包括：

通过所述至少一个应用的接口将所述至少一个应用所关注的事件注册至所述目标框架的服务层；

所述至少一个应用中的目标应用向所述目标框架的服务层发送事件触发请求；

所述目标框架的服务层获取与所述事件触发请求对应的第一事件，并确定所述第一事件所属的指定应用；

通过所述指定应用对所述第一事件进行响应。

9.根据权利要求1所述的方法，其中，所述目标框架设置于容器中；所述方法，还包括：

基于所述至少一个应用生成的属于同一用户的数据存储于同一容器中；

基于所述至少一个应用生成的属于不同用户的数据存储于不同容器中。

10.一种信息处理装置，包括：

应用模块，被配置为：基于目标框架实现至少一个应用；所述至少一个应用中的每个应用包括：所述应用所提供的服务信息的接口和所述应用所提供的服务信息的逻辑实现信息，所述逻辑实现信息用于实现所述接口的功能；

目标框架，包括：服务层，用于实现用于实现所述至少一个应用提供的服务信息的接口的注册、导出、查找、监听和注销中的至少一个；应用层，用于管理基于所述至少一个应用所生成的应用实例；资源容器抽象层，将系统资源提供给所述应用层和所述服务层。

11.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求1至9任意一项所述的方法。

12.一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，其中，所述计算机指令用于使计算机执行权利要求1至9任意一项所述的方法。