CN117369773A - 用于管理代码资源的方法、装置、设备和介质 - Google Patents

Abstract

根据本公开的实现方式，提供了用于管理代码资源的方法、装置、设备和介质。代码资源包括父容器和被组装在父容器之中的至少一个模块类，在一种方法中，在代码资源的运行期间，构建用于管理至少一个模块类中的第一模块类的第一监督器，第一监督器用于管理父容器与第一模块类之间的关联关系。响应于确定父容器被调用，利用第一监督器来构建第一模块类的实例，第一模块类的实例用于在用户界面中呈现按照业务逻辑针对数据源进行处理的处理结果，用户界面、业务逻辑和数据源由第一模块类定义。利用第一监督器，基于父容器的生命周期来管理第一模块类的实例。可以基于模块类以统一方式管理用户界面、业务逻辑和数据源，并且实现生命周期管理。

Description

用于管理代码资源的方法、装置、设备和介质

技术领域

本公开的示例性实现方式总体涉及软件开发领域，特别地涉及用于管理代码资源的方法、装置、设备和计算机可读存储介质。

背景技术

随着软件开发技术的发展，目前已经开发出了用于实现复杂功能的应用程序。在应用程序的开发过程中，可以将复杂的业务逻辑拆分为多个较为简单的业务逻辑，并且可以利用多个功能单元来实现相应的业务逻辑。然而，软件工程师需要人工管理每个功能单元的事务，这极大地提高了工程师的工作负载。另一方面，如果人工拆分的多个功能单元存在耦合，则将会导致用于各个业务逻辑的代码资源之间紧密耦合，进而使得难以维护应用程序的整体代码资源。此时，如何以更为合理的方式辅助工程师的拆分过程、并且降低工程师在后期实现拆分后的各个功能单元的开发难度，成为软件开发领域中亟待解决的问题。

发明内容

在本公开的第一方面，提供了一种用于管理代码资源的方法，在此代码资源包括父容器和被组装在父容器之中的至少一个模块类。在该方法中，在代码资源的运行期间，构建用于管理至少一个模块类中的第一模块类的第一监督器，第一监督器用于管理父容器与第一模块类之间的关联关系。响应于确定父容器被调用，利用第一监督器来构建第一模块类的实例，第一模块类的实例用于在用户界面中呈现按照业务逻辑针对数据源进行处理的处理结果，用户界面、业务逻辑和数据源由第一模块类定义。利用第一监督器，基于父容器的生命周期来管理第一模块类的实例。

在本公开的第二方面，提供了一种用于管理代码资源的装置，在此代码资源包括父容器和被组装在父容器之中的至少一个模块类。该装置包括：监督器构建模块，被配置用于在代码资源的运行期间，构建用于管理至少一个模块类中的第一模块类的第一监督器，第一监督器用于管理父容器与第一模块类之间的关联关系；构建模块，被配置用于响应于确定父容器被调用，利用第一监督器来构建第一模块类的实例，第一模块类的实例用于在用户界面中呈现按照业务逻辑针对数据源进行处理的处理结果，用户界面、业务逻辑和数据源由第一模块类定义；以及管理模块，被配置用于利用第一监督器，基于父容器的生命周期来管理第一模块类的实例。

在本公开的第三方面，提供了一种电子设备。该电子设备包括：至少一个处理单元；以及至少一个存储器，至少一个存储器被耦合到至少一个处理单元并且存储用于由至少一个处理单元执行的指令，指令在由至少一个处理单元执行时使得设备执行根据本公开第一方面的方法。

在本公开的第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序在被处理器执行时使处理器实现根据本公开第一方面的方法。

应当理解，本发明内容部分中所描述的内容并非旨在限定本公开的实现方式的关键特征或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的描述而变得容易理解。

附图说明

在下文中，结合附图并参考以下详细说明，本公开各实现方式的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标记表示相同或相似的元素，其中：

图1示出了本公开的实现方式能够在其中实现的示例软件开发环境的框图；

图2示出了根据本公开的一些实现方式的用于管理代码资源的框架的框图；

图3示出了根据本公开的一些实现方式的模块类的框图；

图4A示出了根据本公开的一些实现方式的代码资源的层级结构的框图；

图4B示出了根据本公开的一些实现方式的用于管理如图4A所示的代码资源的过程的轨道图；

图5A示出了根据本公开的一些实现方式的代码资源的层级结构的框图；

图5B示出了根据本公开的一些实现方式的用于管理如图5A所示的代码资源的过程的轨道图；

图6示出了根据本公开的一些实现方式的代码资源的层级结构的框图；

图7示出了根据本公开的一些实现方式的用于管理代码资源的方法的流程图；

图8示出了根据本公开的一些实现方式的用于管理代码资源的装置的框图；以及

图9示出了能够实施本公开的多个实现方式的设备的框图。

具体实施方式

下面将参照附图更详细地描述本公开的实现方式。虽然附图中示出了本公开的某些实现方式，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实现方式，相反，提供这些实现方式是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实现方式仅用于示例性作用，并非用于限制本公开的保护范围。

在本公开的实现方式的描述中，术语“包括”及其类似用语应当理解为开放性包含，即“包括但不限于”。术语“基于”应当理解为“至少部分地基于”。术语“一个实现方式”或“该实现方式”应当理解为“至少一个实现方式”。术语“一些实现方式”应当理解为“至少一些实现方式”。下文还可能包括其他明确的和隐含的定义。如本文中所使用的，术语“模型”可以表示各个数据之间的关联关系。例如，可以基于目前已知的和/或将在未来开发的多种技术方案来获取上述关联关系。

可以理解的是，本技术方案所涉及的数据(包括但不限于数据本身、数据的获取或使用)应当遵循相应法律法规及相关规定的要求。

可以理解的是，在使用本公开各实施例公开的技术方案之前，均应当根据相关法律法规通过适当的方式对本公开所涉及个人信息的类型、使用范围、使用场景等告知用户并获得用户的授权。

例如，在响应于接收到用户的主动请求时，向用户发送提示信息，以明确地提示用户，其请求执行的操作将需要获取和使用到用户的个人信息。从而，使得用户可以根据提示信息来自主地选择是否向执行本公开技术方案的操作的电子设备、应用程序、服务器或存储介质等软件或硬件提供个人信息。

作为一种可选的但非限制性的实现方式，响应于接收到用户的主动请求，向用户发送提示信息的方式，例如可以是弹出窗口的方式，弹窗中可以以文字的方式呈现提示信息。此外，弹出窗口中还可以承载供用户选择“同意”或“不同意”向电子设备提供个人信息的选择控件。

可以理解的是，上述通知和获取用户授权过程仅是示意性的，不对本公开的实现方式构成限定，其他满足相关法律法规的方式也可应用于本公开的实现方式中。

示例环境

首先参见图1描述软件开发环境的概要，图1示出了本公开的实现方式能够在其中实现的示例软件开发环境的框图100。如图1所示，工程师可以利用开发环境所提供的基础开发库130来开发应用程序110。例如，在安卓开发环境中，可以基于多种基础类(例如，Activity(活动)类132、Fragment(碎片)类134、…、DialogFragment(对话框碎片)类136，来开发满足特定业务逻辑的应用程序110。在此，应用程序110可以包括私信功能单元120和直播功能单元122，等等。具体地，私信功能单元120可以支持用户与其他用户进行私有通信，并且直播功能单元122可以支持用户发布自己的直播内容或者观看其他用户的直播，等等。

在软件开发过程期间，工程师可以自己定义应用程序110的架构，例如，工程师可以人工定义私信功能120和直播功能单元122的用户界面以及相应的业务逻辑，可以针对各个功能难以进行拆分或者组合。然而，按照已有的软件开发模式，并不能从应用程序110的代码中清晰地了解各个功能之间的关系以及各个模块的具体内容。例如，并不能了解每个功能涉及哪些用户界面及其具体业务逻辑。另一方面，由于各个功能之间的边界不够清晰，这导致在两个或者更多功能之间可能会出现耦合，进而导致工程师在修改一个功能单元时可能会影响其他功能单元的正常运行。

目前已经提出了功能拆分的概念，工程师可以基于基础开发库130提供的碎片类134来执行功能拆分。例如，可以利用一个或多个碎片来完成应用程序110(可以包括一个或多个页面)中的功能，然而碎片和页面之间的关系并不明确。此外，碎片方式并不支持数据隔离，目前也不存在碎片间的安全通信手段。这导致碎片内的数据并不安全并且可能会被非法访问。又例如，工程师可以通过自定义类来实现功能拆分，此时工程师不得不自己管理自定义类的整个生命周期内的全部事务，这极大地提高用工程师的工作量。此外，自定义类同样不支持数据隔离和安全通信，这使得应用程序110的运行过程面临安全风险。

代码资源管理的架构

为了解决上述技术方案中的不足，根据本公开的一个示例性实现方式，提出了一种用于管理代码资源的技术方案。首先参见图2描述管理代码资源的概要，该图2示出了根据本公开的一些实现方式的用于管理代码资源的框架的框图200。如图2所示，可以在应用程序110和基础开发库130之间增加模块类层240，模块类层240可以基于基础开发库130的基本功能来提供模块类210。模块类210可以封装与应用程序开发中的各种基本功能相关的用户界面212、数据源214和业务逻辑216。将会理解，在此的用户界面212、数据源214和业务逻辑216可以提供闭环的MVVM(模型-视图-视图模型)的开发模式，进而可以作为拆分和封装特定功能的基本单位。

可以利用模块类210来封装期望的功能，此时，工程师不必自己编写用于管理用户界面212、数据源214和业务逻辑216之间的关联关系的具体代码，而是模块类210的接口可以自动实现管理过程。可以将基于模块类210编写的代码资源组装在由基础开发库130支持的父容器230(例如，活动)中，以便由父容器230调用封装的功能。以此方式，可以提高代码重用性、降低工程师的工作负载，并且为应用程序的功能拆分提供更多便利。

利用本公开的示例性实现方式，模块类层240可以提供具有更高级模块管理功能的编程框架。该编程框架可以以统一方式解决在功能拆分过程中可能涉及的多种需求，并且允许工程师直接调用编程框架内定义的功能。

进一步，在运行利用模块类开发的代码资源时，可以构建监督器220来管理代码资源的运行。该监督器220可以监视父容器230的生命周期222，并且构建模块类210的实例。进一步，监督器220可以基于父容器230的生命周期222来管理模块类210的实例的运行。以此方式，工程师不必自己维护特定模块类的生命周期内的各种事务，而是可以直接调用模块类层240提供的监督器220，来完成模块类210的实例的生命周期管理。

利用本公开的示例性实现方式，模块类层240可以作为应用程序110和基础开发库130之间的桥梁，为工程师执行功能拆分提供更多便利。换言之，模块类层240可以作为在基础开发库130之上提供的上层软件开发工具包(SDK)以便工程师调用。工程师不必自己编写实现各种基本功能代码，而是可以直接调用SDK中所提供的用于管理用户界面212、数据源214和业务逻辑216以及生命周期222的上层功能。以此方式，工程师可以更加关注于如何实现拆分后的具体功能，并且开发相应的代码。

代码资源管理的具体实现

上文已经描述了组件管理的框架，在下文中，将详细描述组件管理过程中涉及的更多细节。根据本公开的一个示例性实现方式，可以调用图2所示的模块层类240中的模块类210，可以进一步扩展模块类210的内容以便实现自定义的功能。具体地，可以基于一个或多个模块类来编写代码资源，并且将一个或多个模块类组装在父容器230中。根据本公开的一个示例性实现方式，可以存在多种类型的模块类，以便实现不同的功能。例如，可以基于如下表1所示的功能描述来构建模块类。

表1所示了构建特定类型(如UIContentAssem类型)的模块类。在本公开的上下文中，还可以存在多种其他类型的模块类，包括但不限于：Assem类型、UIAssem类型、UIContentAssem类型以及UISlotAssem类型，等等。将会理解，尽管上文表1以描述方式记载了构建过程，例如可以使用Kotlin域专用语言(Domain Specific Language，缩写DSL)的格式实现上述过程，还可以基于目前已知的和/或将在未来开发的其他格式来构建模块类。将会理解，表1仅示意性示出了模块类的基本内容，可以根据具体应用环境来向表1中添加用于实现期望目标的代码。

在下文中，首先参见图3介绍模块类210的更多细节。图3示出了根据本公开的一些实现方式的模块类的框图300。如图3所示，可以提供多种类型的模块类，例如模块类310例如可以具有类型“Assem”。将会理解，在本公开的上下文中，仅以“Assem”作为模块类的标识符的具体示例。根据本公开的一个示例性实现方式，还可以采用其他方式(例如，“Asse”，等等)来命名模块类310。将会理解，图3中的模块类310表示基类，可以继承该基类以便形成一个或多个其他的模块类320、330、以及332，等等。

如图3所示，模块类310可以包括如下属性：内容(context)、用于管理该模块类310的监督器(supervisor)、孩子(children，表示代码资源的层级结构中的子节点)、父亲(parent，表示层级结构中的父节点)。进一步，模块类310可以实现加载功能(Trigglelazyload)，并且可以执行与模块类310相关联的生命周期管理的多种回调函数：创建(onCreate)、开始(onStart)、恢复(onResume)、暂停(onPause)、停止(onStop)、销毁(onDestroy)。例如，可以基于如下表2所示的功能描述来设置各个回调函数相关的具体功能。

将会理解，表2仅以描述方式提供了管理回调任务相关的过程描述，根据本公开的一个示例性实现方式，可以利用具体的代码来实现上述重写过程。例如，可以使用onCreate()函数来重写创建函数，使用onStart()函数来重写开始函数，等等。进一步，模块类310可以具有多个接口340、342、344和346，并且这些接口可以实现多种功能。例如，接口340(IVMSubscriber)可以实现与数据源的变更和订阅相关联的功能。接口342(LifecycleOwner)可以表示模块类310具有自己的生命周期，同时也是LifecycleObserver，也即可以与父容器的生命周期相互作用。接口344(ViewModelStoreOwner)可以表示模块类310具有自己独有的ViewModelStore(也即，用于存储MVVM中的ViewModel的存储空间)，这可以保证模块类310具有独立空间以用于存储自身的ViewModel，进而避免其他模块类对其ViewModel内数据的直接访问。接口346(ViewModelFactoryOwner)表示模块类310可以自行构建ViewModel实例。

将会理解，上文示出了模块类310的基类的基本功能，可以继承上述基类的功能并且实现更多的功能。例如，模块类320(UIAssem)可以进一步实现有关用户界面的更多功能。具体地，模块类320具有属性containerView，也即，具有自己的用户界面。contentView可以来源于两种情况：(1)在父容器的布局文件中直接组装的子视图；以及(2)在父容器的布局文件中的插槽视图，此时，子模块将独立构建视图，并且将该视图添加至父容器的插槽视图中。可以在模块的onViewCreated回调中体现上述两种情况的完成。又例如，模块类330(UIContentAssem)中的contentLayoutID以及模块类332(UISlotAssem)中的slotLayoutID可以表示与父容器的用户界面元素相关联，等等。以此方式，每个模块类提供独立地管理相关用户界面、数据源、业务逻辑以及生命周期的能力。工程师可以根据自身需求来调用模块类，进而便于开发拆分后的功能单元。

根据本公开的一个示例性实现方式，模块类310可以具有自身独立的MVVM闭环，也即，在用户界面中呈现按照业务逻辑针对数据源进行处理的处理结果。MVVM可以将用户界面(也即，视图View)的状态和行为抽象化，并且将视图和业务逻辑分开。在MVVM中，Model(模型)表示数据源，在应用程序中用于提供数据。在此数据源可以是是网络请求获得的数据，也可以是本地获得的数据。Model相对独立并且仅用于提供数据，而并不关系数据的用途。MVVM中的View表示视图元素和视图元素初始化。在安卓开发环境中，View表示页面布局文件或者Activity中的元素初始化部分。也即，在安卓开发环境中全部可见的用户界面都是View。在View中对用户界面进行初始化。MVVM中的ViewModel(视图模型)表示对数据进行操作，并将操作结果呈现在View上。

在本公开的上下文中，模块类320分别包括用户界面212(对应于View)、数据源214(Model)和业务逻辑216(ViewModel)，因而可以实现MVVM闭环。换言之，可以利用业务逻辑216处理数据源214，并且将处理结果呈现在用户界面212之上。具体地，模块类可以继承自ViewModelStore，自己独立维护ViewModel域。此时，在模块类中构建的ViewModel只在该模块类下可见，并且其他模块类无法访问同一个ViewModel。进一步，ViewModel随着模块类的销毁而销毁。Model作为数据模型，被绑定至ViewModel并且不会脱离ViewModel存在和使用。

根据本公开的一个示例性实现方式，可以利用模块类来描述拆分后的功能单元。例如，可以利用一个模块类描述私信功能单元120，并且利用另一个模块类来描述直播功能单元122。可以在模块类提供的基本定义的基础上，完成用于定义用户界面、数据源和业务逻辑的具体代码。进一步，还可以对私信功能单元120进一步拆分，例如，可以将其拆分为：未读消息显示单元、通讯录单元，等等。可以基于上文描述的模块类来编写这些单元的代码。利用本公开的示例性实现方式，在每个模块类内可以形成MVVM的闭环，这可以确保各个模块类之间的低耦合，并且可以相互独立地利用模块类开发各个功能单元的代码。

根据本公开的实现方式，可以通过byassemViewModel构建和存储ViewModel的实例，在Assem中可以操作ViewModel，订阅ViewModel的Model数据变更，进而使用最新的Model来呈现用户界面。具体地，可以基于以下表3所示来定义用户界面呈现相关的功能。

将会理解，表3仅示意性示出了用户界面相关的功能，根据本公开的一个示例性实现方式，可以使用具体代码来实现各个功能，例如，可以利用onViewCreated()函数来重写创建视图函数，可以在“onSuccess＝{}”内输入呈现用户界面的具体代码，并且可以在“onError＝{}”内输入故障处理代码。利用本公开的示例性实现方式，图3所示的模块类提供了有关管理用户界面、数据源和业务逻辑以及生命周期的基础功能。此时，可以直接基于各个模块类的定义，实现应用程序中的功能拆分。将会理解，图3仅仅示意性示出了根据本公开的一个示例性实现方式的模块类的示例。根据本公开的一个示例性实现方式，还可以使用其他方式定义用于本公开上下文所描述的封装功能的模块类。例如，可以改变模块类、属性以及接口的命名，并且每个模块类可以具有用于实现不同功能的属性和/或接口。

根据本公开的一个示例性实现方式，模块类层240允许将基础开发库130支持的类(例如，活动类、碎片类以及对话框碎片类)拆分为多个自定义的模块类，并且允许在该类下组装自定义的模块类。例如，可以在Activity类中拆分和组装。具体地，通过指定contentViewId和slotLayoutId，可以将模块类与Activity下的用户界面元素进行绑定，可以利用Kotlin的DSL组装模块类。在此，每个DSL表示注解了@DslMarker的函数方法，该方法的参数是构造器类型的lambda，即AssemDSLBuilder.()->Unit。输入AssemDSLBuilder则可以输出Unit，并且AssemDSLBuilder中包含构造模块类的所有配置参数。

以下表4示出了在一个Activity父容器中组装三个模块类(分别是uiContentAssem类、uiSlotAssem类、uiContentAssem类)。具体地，对于uiContentAssem类而言，可以确定实例的类型为type，并且用户界面的相关设置为contentViewId。

在上文所示的表4中，示出了在父容器Activity下包括3个模块类：uiContentAssem、uiSlotAssem、uiContentAssem。此时，可以清晰了解在父容器下部署了用于实现哪些功能的模块类。根据本公开的一个示例性实现方式，在Fragment类中进行拆分和组装，可以指定contentViewId和slotLayoutId以便将模块类与Fragment下的用户界面元素进行绑定。以下表5示出了在Fragment下组装模块类uiSlotAssem。

根据本公开的一个示例性实现方式，可以在Assem中进行拆分和组装，其操作与和在Activity和Fragment以下的操作类似。以下表6示出了在Assem下组装模块类uiSlotAssem。

从表4至6的组装方式可见，组装过程仅需要模块类的信息而并不需要实例的信息，此时所有模块类的实例都不可访问。以此方式，可以避免实例数据被访问/篡改的可能性。

上文已经描述了模块类层240的详细信息，在下文中，将描述如何处理基于模块类层240编写的代码资源。根据本公开的一个示例性实现方式，可以接收按照上文描述的方式组装模块类，并且编写应用程序的代码资源。例如，可以将私信功能单元拆分为未读消息单元和通讯录单元。此时，在实现私信功能单元的父容器之下，可以组装用于实现未读消息单元的模块类以及用于实现通讯录单元的模块类。此时，代码资源可以包括父容器和被组装在父容器之中的各个模块类。

为了简单起见，首先描述父容器仅包括一个模块类的简单情况，图4A示出了根据本公开的一些实现方式的代码资源的层级结构的框图400。将会理解，代码资源的具体示例如表4至6所示，并且在图4A中仅示意性示出了代码资源的层级结构。如图4A所示，代码资源表示：在父容器230中组装有模块类210。可以运行接收到的代码资源并且在代码资源的运行期间，可以构建用于管理模块类210的监督器。在此，监督器可以管理父容器210与模块类210之间的关联关系。换言之，可以在监督器与模块类210之间建立关联关系，并且利用监督器来管理模块类210的实例化过程，也即，管理模块类210的实例的生命周期(从创建至销毁)的全部事务。将会理解，尽管图4A以基础开发库130中定义的Activity作为父容器230的示例，根据本公开的一个示例性实现方式，父容器230可以是基础开发库130中定义其他对象。

根据本公开的一个示例性实现方式，由于模块类210被组装在父容器210内，因而在父容器230被调用时可以构建模块类210的实例。具体地，可以利用监督器来构建模块类210的实例。模块类210是按照上文描述的方式定义的，因而模块类210的实例可以实现上文描述的MVVM闭环。也即，此时模块类210的实例包括上文定义的属性：用户界面、数据源以及数据逻辑，并且该实例可以在模块类210所定义的用户界面中呈现按照业务逻辑针对数据源进行处理的处理结果。

根据本公开的一个示例性实现方式，为了构建模块类210的实例，监督器可以从代码资源中确定描述模块类的组装配置。将会理解，组装配置可以表示模块类210的类型和父容器230。具体地，可以从用于组装模块类的代码资源中读取模块类210的类型和父容器230。例如，在上文示出的表4中，示出了设置类型和父容器相关的信息。例如，基于type＝TaskAddFloatingAssem来设置类型，并且基于contentViewId＝R.id.fab_add_task来设置父容器。当代码资源组装了更多模块类时，可以基于类似方式确定其他模块类的类型和父容器。进一步，监督器可以基于组装配置中的类型和父容器，来构建模块类210的实例。可以指定模块类的contentViewId，以便将模块类210与父容器230下的用户界面元素进行绑定，由此将构建的模块类210的实例添加至父容器230。

根据本公开的一个示例性实现方式，在构建模块类210的实例的过程中，可以按照模块类210的定义，构建模块类210中的用户界面、数据源以及业务逻辑。将会理解，由于模块类210的定义了用户界面(例如，利用参数view表示)，此时可以调用模块类210的底层接口，以便获得与用户界面相关联的数据源和业务逻辑。具体地，可以调用IVMSubscriber接口，以便订阅数据源；进一步，可以调用ViewModelFactoryOwner，以便获得相应的业务逻辑，进而可以使用该业务逻辑来处理数据源。以此方式，通过直接调用模块类210中所提供的接口，即可在模块类210的实例中方便地实现MVVM闭环。此时，模块类210向工程师提供了支持MVVM闭环过程的强有力的工具，以此方式，工程师不必单独为拆分后的每个功能单元的MVVM相关事务编写专用代码，以此方式可以提高软件代码的重用性。

根据本公开的一个示例性实现方式，可以为父容器230构建组装器(Assembler)。具体地，组装器类可以继承自ViewModel类，并且可以基于组装器类来构建组装器的实例(简称组装器)。在父容器230下存在唯一的组装器，并且该组装器可以负责维护父容器230和监督器的关系。在代码资源运行过程中，可能会构建多个监督器，此时组装器可以包括键-值形式的数据结构以便存储父容器和多个监督器之间的映射关系。在此“键”可以表示父容器230，并且“值”可以表示监督器。进一步，可以利用组装器构建监督器。在代码资源的运行过程中，可以基于组装器和父容器230来找到期望的监督器，进而可以找到由监督器所管理的全部模块类。

利用本公开的示例性实现方式，组装器可以记录父容器230与监督器之间的映射，从而可以经由该映射来找到用于管理父容器内的各个模块类的监督器。将会理解，在应用程序的真实开发过程中，可能会将应用程序的复杂功能拆分为大量简单功能单元，并且利用为数众多的模块类实现这些简单功能单元。通过使用组装器，可以以统一的方式管理被组装在父容器230内的这些模块类。

参见图4B描述基于组装器和监督器管理代码资源的过程，该图4B示出了根据本公开的一些实现方式的用于管理如图4A所示的代码资源的过程的轨道图400B。如图4B所示，可以基于接收到的代码资源来构建组装器410和监督器420，并且利用监督器420来构建模块类210的实例422。具体地，父容器230可以基于initialize操作来构建(430)组装器410，此时组装器410被初始化。组装器410可以基于initialize操作来构建(432)监督器420，此时将生成用于管理父容器230下的模块类210的监督器420。父容器230可以基于findSupervisor操作来寻找(434)构建的监督器420，并且在键-值形式的数据结构中记录父容器230与监督器420之间的映射。父容器230的生命周期进入(436)创建(onCreate)阶段，并且可以触发被组装在该父容器230内的模块类的进一步动作。

父容器230可以基于dispatchOnCreate操作，指示(438)监督器420构建模块类210的实例422。监督器420在接收到指令之后可以基于handelOnCreate操作构建(440)模块类210的实例422。具体地，可以基于initialize操作构建(442)模块类210的实例422，此时，实例422的生命周期进入(444)创建(onCreate)阶段。继而，监督器420可以监视父容器230的生命周期，并且利用父容器230的生命周期来管理模块类210的实例422的生命周期。

根据本公开的一个示例性实现方式，如果确定父容器230的生命周期发生变化，可以基于组装器410处的映射关系查找用于管理被组装在父容器230内的模块类210的监督器420。进一步，监督器420可以基于父容器的生命周期来调度模块类210的实例422，也即管理实例422的生命周期内的各个事务。

将会理解，尽管上文仅示意性示出了生命周期的创建阶段的相关操作，根据本公开的一个示例性实现方式，生命周期可以进一步包括以下阶段中的至少任一项：开始、恢复、暂停、停止、销毁。此时，可以基于确定父容器230进入生命周期的某个阶段，来相应地管理模块类210的实例422。具体地，可以经由组装器410找到用于管理父容器230内模块类210的监督器420，并且由监督器420基于父容器230的生命周期管理实例422的运行。

将会理解，在模块类210的实例422的生命周期内，监督器420可以将实例422中的用户界面、数据源和业务逻辑均设置为仅在实例内部可访问，并且对外界不可访问。以此方式，可以实现模块类210的实例422之间的数据隔离，防止实例的各种相关属性被其他实例和/或无关函数访问，进而提高代码资源运行过程中的数据安全性。

继续参见图4B，当期望结束代码资源运行时，父容器230可以基于findSupervisor操作查找(446)相关的监督器420，并且可以经由dispatchDestory操作指示(448)监督器420销毁实例422。继而，监督器420可以基于HandelOnDestroy操作来销毁(450)实例422。此时，实例422的生命周期进入(452)销毁阶段。在已经成功销毁实例422之后，父容器230的生命周期进入(454)销毁阶段。

将会理解，父容器230内组装的模块类210的实例422依赖于父容器230并且完成父容器230的细化功能。因而，实例422的生命周期依赖于父容器230的生命周期。利用本公开的示例性实现方式，监督器420可以直接基于父容器230的生命周期来管理实例422，这使得工程师不必自行编写用于管理实例422的生命周期管理的繁琐代码。以此方式，可以降低工程师的工作负载，并且提高生命周期管理相关的代码重用性。

上文已经参见图4A和图4B示出了在父容器中仅组装一个模块类的简单情况，此时父容器下层仅包括一个模块类的层级。根据本公开的一个示例性实现方式，父容器230下层可以包括更多的层级。此时，可以在每个层级处构建一个监督器，以便管理该层级处的一个或多个模块类。

根据本公开的一个示例性实现方式，代码资源的层级结构可以指示：父容器230内包括模块类210。进一步，如果层级结构中的指向模块类210的节点包括指向另一模块类(称为子模块类)的子节点，此时可以基于模块类210的实例422构建用于管理子模块类的另一监督器。进一步，可以使用该监督器管理模块类210的实例与子模块类之间的关联关系。可以使用每个层级处的监督器来为该层级处的模块类构建实例，并且可以使用父节点的生命周期来管理当前层级的实例的生命周期。利用本公开的示例性实现方式，可以按照每个层级处的模块类被组装的顺序，利用每个层级处的监督器统一地管理该层级处的各个实例。

在下文中，参见图5A和图5B描述有关处理具有更多层级的代码资源的更多细节。图5A示出了根据本公开的一些实现方式的代码资源的层级结构的框图500A。如图5A所示，在父容器230内组装了两个模块类210和510，并且模块类510是模块类210的子节点。此时，父容器230下层包括两个层级，并且可以在两个层级处分别构建两个监督器。图5B示出了根据本公开的一些实现方式的用于管理如图5A所示的代码资源的过程的轨道图500B。在图5B中，箭头430至454所示的操作与图4B所示相同，并且箭头530至544示出了处理第二层级的模块类510的过程。

如图5B所示，实例422可以基于dispatchOnCreate操作指示(530)构建下层的监督器520。监督器520可以基于handelOnCreate操作构建(532)模块类510的实例512，并且实例512可以基于initialize操作来实现初始化(534)，并且进入(536)生命周期的创建阶段。进一步，监督器520可以基于实例422的生命周期，管理实例512的生命周期。

根据本公开的一个示例性实现方式，当希望销毁父容器230时，可以逐级销毁各个层级的实例。如图5B所示，实例422可以经由dispatchOnDestroy操作指示(538)监督器520销毁实例510。此时，监督器520可以经由handelOnDestory操作来执行销毁(540)，实例510的生命周期进入(542)销毁阶段，接着实例422的生命周期进入(544)销毁阶段。最后，父容器230的生命周期进入(454)销毁阶段。

根据本公开的一个示例性实现方式，代码资源的层级结构可以包括树状结构，此时模块类可以进一步具有兄弟节点。具体地，假设层级结构中的指向模块类210的节点包括指向另一模块类(例如，称为兄弟模块类)的兄弟节点，则可以利用模块类210的监督器420来管理该兄弟模块类。具体地，可以利用监督器420管理父容器230与该兄弟模块类之间的关联关系，构建该兄弟模块类的实例，并且基于父节点230的生命周期来管理该兄弟模块类的实例的生命周期。将会理解，可以利用与上文类似的方式来管理兄弟模块类的实例，因而不再赘述。

利用本公开的示例性实现方式，每个监督器可以管理本层级的一个或多个模块类的实例。当某个层级包括多个模块类时，监督器可以按照各个模块类被组装的顺序，逐个将各个模块类实例化。以此方式，监督器可以统一地管理该层级的各个模块类的实例，进而在组装器410的统一管理下实现相应的生命周期管理。

在下文中，参见图6描述具有更为复杂层级结构的代码资源。图6示出了根据本公开的一些实现方式的代码资源的层级结构的框图600。在图6所示的层级结构中，父容器610下层可以包括多个模块类620、622和624。此时，各个模块类可以具有不同的类型，例如模块类620可以基于Fragment实现，实例622和624可以基于Assem实现。进一步，模块类620可以具有子节点(即，UISlottAssem模块类630)，并且模块类630可以具有子节点(即，UIContentAssem模块类640)。模块类624可以具有两个子节点：Assem模块类634和UIContentAssem模块类636。进一步，模块类636可以具有子节点：UIContentAssem模块类642。

此时，可以在第1至3层分别构建监督器：第1层处的监督器可以按照各个模块类被组装的顺序，将各个模块类实例化。假设Fragment首先被组装、并且两个Assem随后被组装，则监督器可以首先构建模块类620的实例并且随后构建模块类622和624的实例。进一步，第2层处的监督器可以构建第2层的各个模块类630、634和636的实例，并且管理各个实例的生命周期。第3层处的监督器可以构建第3层的各个实例，例如按照模块类640、642的顺序，并且管理各个实例的生命周期。

利用本公开的示例性实现方式，分别位于多个层级处的多个监督器可以并行操作，以便管理代码资源中所组装的各个模块类。相对于开发程序员必须针对每个功能单元逐一开发生命周期管理以及MVVM管理代码的常规技术方案而言，利用本公开的模块层类240，可以提供有关生命周期管理和MVVM管理相关的统一接口。以此方式，可以大大降低工程师的工作负载，进而有助于提高工程师拆分功能单元的粒度。将会理解，当应用程序110中的功能单元具有更为精细的控制粒度时，功能单元之间的耦合性将会降低。以此方式，可以实现松耦合的功能单元进而便于应用程序的整体管理，并且便于多个工程师并行地开发各自功能单元的代码。

将会理解，上文示意性示出了根据本公开的一个示例性实现方式的模块类层240的工作过程。利用本公开的示例性实现方式，可以支持在Activity、Fragment、以及DialogFragment的基础上进一步拆分业务逻辑。模块类层240允许在Activity、Fragment、以及DialogFragment上随意组装，并且无需修改用户界面的布局。此时，每个模块类包括各自的用户界面、数据源以及业务逻辑，并且可以形成MVVM的闭环。模块类层240允许采用Kotlin DSL格式设计的各个模块类的组装方式，因而可以清晰地示出功能单元具体包括哪些模块类。进一步，模块类可以提供数据隔离，进而避免在多个模块类的实例之间进行不必要数据访问。以此方式，可以加强数据封装并且降低代码耦合性。

示例过程

图7示出了根据本公开的一些实现方式的用于管理代码资源的方法700的流程图，代码资源包括父容器和被组装在父容器之中的至少一个模块类。在框710处，在代码资源的运行期间，构建用于管理至少一个模块类中的第一模块类的第一监督器，第一监督器用于管理父容器与第一模块类之间的关联关系。在框720处，确定父容器是否被调用。如果父容器被调用，则方法700前进至框730。在框730处，利用第一监督器来构建第一模块类的实例，第一模块类的实例用于在用户界面中呈现按照业务逻辑针对数据源进行处理的处理结果，用户界面、业务逻辑和数据源由第一模块类定义。在框740处，利用第一监督器，基于父容器的生命周期来管理第一模块类的实例。

根据本公开的一个示例性实现方式，利用第一监督器来构建第一模块类的实例包括：基于代码资源确定描述第一模块类的组装配置，组装配置指定第一模块类的类型和父容器；基于组装配置来构建第一模块类的实例；以及将第一模块类的实例添加至父容器。

根据本公开的一个示例性实现方式，基于组装配置来构建第一模块类的实例包括：基于模块类的类型，在模块类的实例中构建：用于显示处理结果的用户界面、用于定义将被处理的数据的数据源、以及用于针对数据源进行处理的业务逻辑。

根据本公开的一个示例性实现方式，构建用于管理至少一个模块类中的第一模块类的第一监督器包括：构建用于管理父容器的组装器；以及利用组装器构建第一监督器，组装器包括父容器与第一监督器之间的映射关系。

根据本公开的一个示例性实现方式，利用第一监督器，基于父容器的生命周期来管理第一模块类的实例包括：响应于确定父容器的生命周期发生变化，基于映射关系查找用于管理被组装在父容器内的第一模块类的第一监督器；以及利用第一监督器，基于父容器的生命周期来调度第一模块类的实例的生命周期。

根据本公开的一个示例性实现方式，父容器的生命周期包括以下至少任一阶段：创建、开始、恢复、暂停、停止、销毁。

根据本公开的一个示例性实现方式，利用第一监督器，基于父容器的生命周期来管理第一模块类的实例包括：在第一模块类的实例的生命周期期间，利用监督器将第一模块类的实例中的用户界面、数据源和业务逻辑设置为仅在实例内部可访问。

根据本公开的一个示例性实现方式，代码资源按照层级结构来组织父容器和至少一个模块类。在该方法700中，响应于确定层级结构中的指向第一模块类的节点包括指向至少一个模块类中的第二模块类的子节点，基于第一模块类的实例构建用于管理第二模块类的第二监督器，第二监督器用于管理第一模块类的实例与第二模块类之间的关联关系；利用第二监督器构建第二模块类的实例；以及利用第二监督器，基于第一模块类的生命周期来管理第二模块类的实例的生命周期。

根据本公开的一个示例性实现方式，响应于确定层级结构中的指向第一模块类的节点包括指向至少一个模块类中的第三模块类的兄弟节点，利用第一监督器管理父容器与第三模块类之间的关联关系；利用第一监督器构建第三模块类的实例；以及利用第一监督器，基于父节点的生命周期来管理第三模块类的实例的生命周期。

根据本公开的一个示例性实现方式，父容器包括以下至少任一项：安卓开发环境中的用于实现代码资源的活动类、碎片类、对话框碎片类。

示例装置和设备

图8示出了根据本公开的一些实现方式的用于管理代码资源的装置800的框图，在此代码资源包括父容器和被组装在父容器之中的至少一个模块类。具体地，该装置800包括：监督器构建模块810，被配置用于在代码资源的运行期间，构建用于管理至少一个模块类中的第一模块类的第一监督器，第一监督器用于管理父容器与第一模块类之间的关联关系；构建模块820，被配置用于响应于确定父容器被调用，利用第一监督器来构建第一模块类的实例，第一模块类的实例用于在用户界面中呈现按照业务逻辑针对数据源进行处理的处理结果，用户界面、业务逻辑和数据源由第一模块类定义；以及管理模块830，被配置用于利用第一监督器，基于父容器的生命周期来管理第一模块类的实例。

根据本公开的一个示例性实现方式，构建模块820包括：配置确定模块，被配置用于基于代码资源确定描述第一模块类的组装配置，组装配置指定第一模块类的类型和父容器；实例构建模块，被配置用于基于组装配置来构建第一模块类的实例；以及添加模块，被配置用于将第一模块类的实例添加至父容器。

根据本公开的一个示例性实现方式，实例构建模块包括：属性构建模块，被配置用于基于模块类的类型，在模块类的实例中构建：用于显示处理结果的用户界面、用于定义将被处理的数据的数据源、以及用于针对数据源进行处理的业务逻辑。

根据本公开的一个示例性实现方式，监督器构建模块810包括：组装器构建模块，被配置用于构建用于管理父容器的组装器；以及映射模块，被配置用于利用组装器构建第一监督器，组装器包括父容器与第一监督器之间的映射关系。

根据本公开的一个示例性实现方式，管理模块830包括：查找模块，被配置用于响应于确定父容器的生命周期发生变化，基于映射关系查找用于管理被组装在父容器内的第一模块类的第一监督器；以及调度模块，被配置用于利用第一监督器，基于父容器的生命周期来调度第一模块类的实例的生命周期。

根据本公开的一个示例性实现方式，父容器的生命周期包括以下至少任一阶段：创建、开始、恢复、暂停、停止、销毁。

根据本公开的一个示例性实现方式，管理模块830包括：设置模块，被配置用于在第一模块类的实例的生命周期期间，利用监督器将第一模块类的实例中的用户界面、数据源和业务逻辑设置为仅在实例内部可访问。

根据本公开的一个示例性实现方式，代码资源按照层级结构来组织父容器和至少一个模块类，其中：监督器构建模块810进一步被配置用于：响应于确定层级结构中的指向第一模块类的节点包括指向至少一个模块类中的第二模块类的子节点，基于第一模块类的实例构建用于管理第二模块类的第二监督器，第二监督器用于管理第一模块类的实例与第二模块类之间的关联关系；构建模块820进一步被配置用于：利用第二监督器构建第二模块类的实例；以及管理模块830进一步被配置用于：利用第二监督器，基于第一模块类的生命周期来管理第二模块类的实例的生命周期。

根据本公开的一个示例性实现方式，监督器构建模块810进一步被配置用于：响应于确定层级结构中的指向第一模块类的节点包括指向至少一个模块类中的第三模块类的兄弟节点，利用第一监督器管理父容器与第三模块类之间的关联关系；构建模块820进一步被配置用于：利用第一监督器构建第三模块类的实例；以及管理模块830进一步被配置用于：利用第一监督器，基于父节点的生命周期来管理第三模块类的实例的生命周期。

根据本公开的一个示例性实现方式，父容器包括以下至少任一项：安卓开发环境中用于实现代码资源的活动类、碎片类、对话框碎片类。

图9示出了能够实施本公开的多个实现方式的设备900的框图。应当理解，图9所示出的电子设备900仅仅是示例性的，而不应当构成对本文所描述的实现方式的功能和范围的任何限制。图9所示出的电子设备900可以用于实现上文描述的方法。

如图9所示，电子设备900是通用电子设备的形式。电子设备900的组件可以包括但不限于一个或多个处理器或处理单元910、存储器920、存储设备930、一个或多个通信单元940、一个或多个输入设备950以及一个或多个输出设备960。处理单元910可以是实际或虚拟处理器并且能够根据存储器920中存储的程序来执行各种处理。在多处理器系统中，多个处理单元并行执行计算机可执行指令，以提高电子设备900的并行处理能力。

电子设备900通常包括多个计算机存储介质。这样的介质可以是电子设备900可访问的任何可以获得的介质，包括但不限于易失性和非易失性介质、可拆卸和不可拆卸介质。存储器920可以是易失性存储器(例如寄存器、高速缓存、随机访问存储器(RAM))、非易失性存储器(例如，只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、闪存)或它们的某种组合。存储设备930可以是可拆卸或不可拆卸的介质，并且可以包括机器可读介质，诸如闪存驱动、磁盘或者任何其他介质，其可以能够用于存储信息和/或数据(例如用于训练的训练数据)并且可以在电子设备900内被访问。

电子设备900可以进一步包括另外的可拆卸/不可拆卸、易失性/非易失性存储介质。尽管未在图9中示出，可以提供用于从可拆卸、非易失性磁盘(例如“软盘”)进行读取或写入的磁盘驱动和用于从可拆卸、非易失性光盘进行读取或写入的光盘驱动。在这些情况中，每个驱动可以由一个或多个数据介质接口被连接至总线(未示出)。存储器920可以包括计算机程序产品925，其具有一个或多个程序模块，这些程序模块被配置为执行本公开的各种实现方式的各种方法或动作。

通信单元940实现通过通信介质与其他电子设备进行通信。附加地，电子设备900的组件的功能可以以单个计算集群或多个计算机器来实现，这些计算机器能够通过通信连接进行通信。因此，电子设备900可以使用与一个或多个其他服务器、网络个人计算机(PC)或者另一个网络节点的逻辑连接来在联网环境中进行操作。

输入设备950可以是一个或多个输入设备，例如鼠标、键盘、追踪球等。输出设备960可以是一个或多个输出设备，例如显示器、扬声器、打印机等。电子设备900还可以根据需要通过通信单元940与一个或多个外部设备(未示出)进行通信，外部设备诸如存储设备、显示设备等，与一个或多个使得用户与电子设备900交互的设备进行通信，或者与使得电子设备900与一个或多个其他电子设备通信的任何设备(例如，网卡、调制解调器等)进行通信。这样的通信可以经由输入/输出(I/O)接口(未示出)来执行。

根据本公开的示例性实现方式，提供了一种计算机可读存储介质，其上存储有计算机可执行指令，其中计算机可执行指令被处理器执行以实现上文描述的方法。根据本公开的示例性实现方式，还提供了一种计算机程序产品，计算机程序产品被有形地存储在非瞬态计算机可读介质上并且包括计算机可执行指令，而计算机可执行指令被处理器执行以实现上文描述的方法。根据本公开的示例性实现方式，提供了一种计算机程序产品，其上存储有计算机程序，程序被处理器执行时实现上文描述的方法。

这里参照根据本公开实现的方法、装置、设备和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理单元，从而生产出一种机器，使得这些指令在通过计算机或其他可编程数据处理装置的处理单元执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

可以把计算机可读程序指令加载到计算机、其他可编程数据处理装置、或其他设备上，使得在计算机、其他可编程数据处理装置或其他设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其他可编程数据处理装置、或其他设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实现的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本公开的各实现，上述说明是示例性的，并非穷尽性的，并且也不限于所公开的各实现。在不偏离所说明的各实现的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实现的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其他普通技术人员能理解本文公开的各个实现方式。

Claims (13)

1.一种用于管理代码资源的方法，所述代码资源包括父容器和被组装在所述父容器之中的至少一个模块类，所述方法包括：

在所述代码资源的运行期间，构建用于管理所述至少一个模块类中的第一模块类的第一监督器，所述第一监督器用于管理所述父容器与所述第一模块类之间的关联关系；

响应于确定所述父容器被调用，利用所述第一监督器来构建所述第一模块类的实例，所述第一模块类的所述实例用于在用户界面中呈现按照业务逻辑针对数据源进行处理的处理结果，所述用户界面、所述业务逻辑和所述数据源由所述第一模块类定义；以及

利用所述第一监督器，基于所述父容器的生命周期来管理所述第一模块类的所述实例。

2.根据权利要求1的所述方法，其中利用所述第一监督器来构建所述第一模块类的所述实例包括：

基于所述代码资源确定描述所述第一模块类的组装配置，所述组装配置指定所述第一模块类的类型和所述父容器；

基于所述组装配置来构建所述第一模块类的所述实例；以及

将所述第一模块类的所述实例添加至所述父容器。

3.根据权利要求2的所述方法，其中基于所述组装配置来构建所述第一模块类的所述实例包括：

基于所述模块类的所述类型，在所述模块类的所述实例中构建：用于显示所述处理结果的所述用户界面、用于定义将被处理的数据的所述数据源、以及用于针对所述数据源进行处理的所述业务逻辑。

4.根据权利要求1的所述方法，其中构建用于管理所述至少一个模块类中的所述第一模块类的所述第一监督器包括：

构建用于管理所述父容器的组装器；以及

利用所述组装器构建所述第一监督器，所述组装器包括所述父容器与所述第一监督器之间的映射关系。

5.根据权利要求4的所述方法，其中利用所述第一监督器，基于所述父容器的所述生命周期来管理所述第一模块类的所述实例包括：响应于确定所述父容器的所述生命周期发生变化，

基于所述映射关系查找用于管理被组装在所述父容器内的所述第一模块类的所述第一监督器；以及

利用所述第一监督器，基于所述父容器的所述生命周期来调度所述第一模块类的所述实例的生命周期。

6.根据权利要求1的所述方法，其中所述父容器的所述生命周期包括以下至少任一阶段：创建、开始、恢复、暂停、停止、销毁。

7.根据权利要求1的所述方法，其中利用所述第一监督器，基于所述父容器的生命周期来管理所述第一模块类的所述实例包括：在所述第一模块类的所述实例的生命周期期间，利用所述监督器将所述第一模块类的所述实例中的所述用户界面、所述数据源和所述业务逻辑设置为仅在所述实例内部可访问。

8.根据权利要求1的所述方法，其中所述代码资源按照层级结构来组织所述父容器和所述至少一个模块类，所述方法进一步包括：响应于确定所述层级结构中的指向所述第一模块类的节点包括指向所述至少一个模块类中的第二模块类的子节点，

基于所述第一模块类的所述实例构建用于管理所述第二模块类的第二监督器，所述第二监督器用于管理所述第一模块类的所述实例与所述第二模块类之间的关联关系；

利用所述第二监督器构建所述第二模块类的实例；以及

利用所述第二监督器，基于所述第一模块类的所述生命周期来管理所述第二模块类的所述实例的生命周期。

9.根据权利要求8的所述方法，进一步包括：响应于确定所述层级结构中的指向所述第一模块类的所述节点包括指向所述至少一个模块类中的第三模块类的兄弟节点，

利用所述第一监督器管理所述父容器与所述第三模块类之间的关联关系；

利用所述第一监督器构建所述第三模块类的实例；以及

利用所述第一监督器，基于所述父节点的所述生命周期来管理所述第三模块类的所述实例的生命周期。

10.根据权利要求1的所述方法，其中所述父容器包括以下至少任一项：安卓开发环境中的用于实现所述代码资源的活动类、碎片类、对话框碎片类。

11.一种用于管理代码资源的装置，所述代码资源包括父容器和被组装在所述父容器之中的至少一个模块类，所述装置包括：

监督器构建模块，被配置用于在所述代码资源的运行期间，构建用于管理所述至少一个模块类中的第一模块类的第一监督器，所述第一监督器用于管理所述父容器与所述第一模块类之间的关联关系；

构建模块，被配置用于响应于确定所述父容器被调用，利用所述第一监督器来构建所述第一模块类的实例，所述第一模块类的所述实例用于在用户界面中呈现按照业务逻辑针对数据源进行处理的处理结果，所述用户界面、所述业务逻辑和所述数据源由所述第一模块类定义；以及

管理模块，被配置用于利用所述第一监督器，基于所述父容器的生命周期来管理所述第一模块类的所述实例。

12.一种电子设备，包括：

至少一个处理单元；以及

至少一个存储器，所述至少一个存储器被耦合到所述至少一个处理单元并且存储用于由所述至少一个处理单元执行的指令，所述指令在由所述至少一个处理单元执行时使所述电子设备执行根据权利要求1至10中任一项所述的方法。

13.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序在被处理器执行时使所述处理器实现根据权利要求1至10中任一项所述的方法。