CN115202633A - 用于管理应用的组件的方法、装置、设备和介质 - Google Patents

Abstract

提供了用于管理应用的组件的方法、装置、设备和介质。接收分别定义组件在第一应用中的第一功能的第一描述和组件在第二应用中的第二功能的第二描述，第一功能和第二功能分别包括组件在第一应用和第二应用中的页面样式。基于第一描述和第二描述，确定实现组件的代码框架中的通用资源、第一专用资源和第二专用资源，通用资源实现第一功能和第二功能之间的通用功能，第一专用资源实现第一功能中的第一专用功能，以及第二专用资源实现第二功能中的第二专用功能。基于通用资源、第一专用资源和第二专用资源，针对第一应用和第二应用中的目标应用，生成用于实现组件在目标应用中的功能的目标资源。可以以统一管理组件的代码，并且提高代码重用程度。

Description

用于管理应用的组件的方法、装置、设备和介质

技术领域

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

背景技术

随着互联网技术的发展，目前已经开发出了在终端设备上运行的多种应用。例如，新闻应用可以向用户提供热点事件的新闻报道、视频应用可以向用户提供各种视频内容，等等。新闻应用和视频应用两者可以使用各自的组件来实现特定的功能。通常而言，不同应用所提供的功能可能会有所重叠。由于多个应用可能会使用不同方式开发，这导致不得不为各个应用分别开发各自的组件。此时，如何以统一并且有效的方式来管理多个应用的组件，成为软件开发领域的研究热点和难点。

发明内容

根据本公开的示例性实现方式，提供了一种用于管理应用的组件的方案。

在本公开的第一方面，提供了一种用于管理应用的组件的方法。在该方法中，接收用于分别定义组件在第一应用中的第一功能的第一描述以及组件在第二应用中的第二功能的第二描述，第一功能和第二功能分别包括组件在第一应用和第二应用中的页面样式。基于第一描述和第二描述，确定用于实现组件的代码框架中的通用资源、第一专用资源和第二专用资源，通用资源实现第一功能和第二功能之间的通用功能，第一专用资源实现第一功能中的第一专用功能，以及第二专用资源实现第二功能中的第二专用功能。基于通用资源、第一专用资源和第二专用资源，针对第一应用和第二应用中的目标应用，生成用于实现组件在目标应用中的功能的目标资源。

在本公开的第二方面，提供了一种用于管理应用的组件的装置。该装置包括：接收模块，被配置用于接收用于分别定义组件在第一应用中的第一功能的第一描述以及组件在第二应用中的第二功能的第二描述，第一功能和第二功能分别包括组件在第一应用和第二应用中的页面样式；确定模块，被配置用于基于第一描述和第二描述，确定用于实现组件的代码框架中的通用资源、第一专用资源和第二专用资源，通用资源实现第一功能和第二功能之间的通用功能，第一专用资源实现第一功能中的第一专用功能，以及第二专用资源实现第二功能中的第二专用功能；以及生成模块，被配置用于基于通用资源、第一专用资源和第二专用资源，针对第一应用和第二应用中的目标应用，生成用于实现组件在目标应用中的功能的目标资源。

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

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

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

附图说明

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

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

图2示出了根据本公开的一些实现方式的用于管理应用的组件的过程的框图；

图3示出了根据本公开的一些实现方式的基于分别用于多个应用的多个描述来确定代码框架中的通用资源和专用资源的过程的框图；

图4示出了根据本公开的一些实现方式的代码框架的框图；

图5示出了根据本公开的一些实现方式的用于不同应用的目标资源的框图；

图6示出了根据本公开的一些实现方式的用于管理组件的配置参数的框图；

图7示出了根据本公开的一些实现方式的用于基于继承模式来生成的目标资源的框图；

图8示出了根据本公开的一些实现方式的修改代码框架的过程的框图；

图9示出了根据本公开的一些实现方式的用于管理应用的组件的方法的流程图；

图10示出了根据本公开的一些实现方式的用于管理应用的组件的装置的框图；以及

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

具体实施方式

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

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

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

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

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

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

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

示例环境

首先参见图1描述管理应用的组件的应用环境，图1示出了本公开的实现方式能够在其中实现的示例环境100的框图。如图1所示，可以提供多个应用110和120。具体地，应用110可以用于提供新闻服务，该应用110可以包括“体育”组件116。具体地，该组件116可以提供篮球赛事的新闻。例如，内容区域112可以包括篮球决赛的文字直播，比分区域114可以包括两个参赛球队的比分，等等。进一步，应用120可以用于提供视频服务，该应用120可以包括“体育”组件126。具体地，该组件126可以提供篮球赛事的视频。例如，内容区域122可以包括篮球决赛的视频直播，比分区域124可以包括两个参赛球队的比分，等等。

在本公开的上下文中，组件可以表示在应用中提供特定功能的软件模块。具体地，组件可以以特定页面样式(例如，与应用的用户界面外观相关的呈现方式，包括背景色、页面中文字的颜色、字体、字号、页面中各种元素的尺寸和布局，等等)，呈现按照特定页面逻辑获得的内容。在此，页面逻辑表示针对待处理数据进行的处理过程。例如，在提供篮球赛事视频的组件126中，页面逻辑可以涉及根据用户操作来开始或者暂停视频播放。如图1所示，尽管两个组件116和126的功能类似，即，用于提供有关篮球决赛的信息，然而两个组件116和126的功能可以包括相同部分和不同部分。例如，组件116和126两者都以分页签方式提供，然而内容区域112和122中呈现的内容可以不同，并且比分区域114和124的显示样式可以不同，等等。

通常而言，软件公司可以开发多个应用，并且各个应用可能会提供相同或类似的功能。例如，随着重要体育赛事的进行，新闻应用和视频应用都可以提供有关赛事的内容。新闻应用可以提供体育赛事的实时比分、文字和图片等内容，并且视频应用可以提供体育赛事的实时比分和视频等内容。此时，开发工程师不得不为各自的应用单独开发专用的组件代码。

在软件开发领域中，目前已经提出了“中台”的概念。中台可以集成软件公司的各种资源来服务于多个应用，从而满足前台的快速迭代需求和后台的稳定性需求。当新的需求来临时，中台可以快速响应从而提升研发效率。然而，各个应用所采用的设计语言可能会有所不同，并且各个应用可能会存在特定逻辑，等等，这产生了不同的中台管理方式。

在单独管理方式中，可以为各个应用单独开发代码并生成相应的组件。由于组件的核心逻辑通常是复用的，可以修改基础核心逻辑以便满足各个应用的特殊要求。如果针对每个应用单独生成专用组件，这导致出现大量重复代码并且不利于代码管理。此外，当需要修改核心逻辑时，需要单独修改每个组件，这大大降低了软件开发效率。又例如，在整合管理方式中，可以将适用于所有应用的代码整合到同一组件内进行维护。尽管整合管理方式便于全局管理，此时组件包括用于多个应用端的冗余代码，进而导致组件体积臃肿并且性能低下。

组件管理的架构

为了解决上述技术方案中的不足，根据本公开的一个示例性实现方式，提出了一种用于管理应用的组件的技术方案。概括而言，可以利用一个代码框架来管理在多个应用中使用的组件。例如，可以分析组件在不同应用中的功能的描述，以便确定代码框架中的可以在多个应用中使用的通用资源(例如，在应用110和应用120中都使用分页签方式来显示组件，等等)和专用于某个应用的专用资源(例如，在分页签内使用不同背景颜色和文字颜色，在内容区域112和122内分别显示文本和视频，比分区域114和124分别以不同格式显示比分，等等)。

将会理解，组件的页面样式是组件最直观的视觉表现形式并且直接影响用户体验，因而可以特别关注于页面样式相关的功能。以此方式，可以区分组件在不同应用中的页面样式相关的通用资源和专用资源，以便首先满足与组件的视觉表现相关的基础资源共享。进一步，可以以类似方式处理页面逻辑，进而实现更深层次的资源共享。以此方式，可以以统一方式管理用于多个应用的组件，从而以更为方便并且有效的方式管理组件。进一步，通用资源和专用资源可以隔离组件在多个应用中的功能，以此方式可以进一步降低针对某个目标应用的资源的体积。

在下文中，参见图2描述根据本公开的一个示例性实现方式的更多细节。图2示出了根据本公开的一些实现方式的用于管理应用的组件的过程的框图200。如图2所示，可以利用组件生成器260来实现管理应用的组件的过程。在此，应用110和120两者都可以使用组件240(例如上文描述的“体育”组件)。然而，组件240在应用110和120中的具体功能的细节可以有所不同。此时，可以接收分别定义组件240在应用110中的功能的描述210、以及定义组件240在应用120中的功能的描述220(为了便于区分，可以将应用110和120分别称为第一应用和第二应用，并且可以将描述210和220分别称为第一描述和第二描述)。

如图2所示，描述210可以定义组件240在应用110中的功能：以分页签方式显示组件，以白色背景黑色文字显示分页签内的文字，在内容区域112中显示文本，等等。描述220可以定义组件240在应用120中的功能：以分页签方式显示组件，以黑色背景白色文字显示分页签内的文字，在内容区域122中显示视频，等等。通过比较描述210和220可以发现，组件240在应用110和120中的功能包括通用功能：以分页签方式显示组件。进一步，组件240在应用110和120中的功能存在区别：显示文字的格式不同并且显示内容不同，可以将上述功能称为专用功能。

根据本公开的一个示例性实现方式，可以基于比较来确定用于实现组件240的代码框架230。具体地，可以确定代码框架230中的可以共享的通用资源250(用于实现以分页签显示组件的功能)、以及分别用于实现应用110和120中的专用功能的专用资源(例如，用于实现应用110的专用功能的专用资源252、254；以及用于实现应用120的专用功能的专用资源256、…、以及258)。将会理解，在本公开的上下文中，资源可以涉及页面样式、页面逻辑以及两者的组合，并且可以包括用于实现组件的各种功能所需要调用的多种类型的资源，包括但不限于代码(例如，原始代码和/或可执行代码，等)、文档、图像、音频、视频、配置文件，等等。

以此方式，可以在单一代码框架230中维护用于在多个应用中实现不同功能的组件240。进一步，可以基于通用资源250和各个专用资源，针对应用110和应用120中的任何一个目标应用，生成用于实现组件240在该目标应用中的功能的目标资源。具体地，对于应用110，目标资源212可以包括通用资源250、252、254，等等；对于应用120，目标资源222可以包括通用资源250、256、258，等等。继而，应用110可以直接调用由组件生成器260生成的目标资源212，并且应用120可以直接调用目标资源222。

利用本公开的示例性实现方式，在开发和测试过程中可以使用统一的代码框架230来管理组件240的代码，并且基于该代码框架230生成针对特定目标应用的目标资源。以此方式，避免了专门针对每个应用维护自己的代码版本需求，进而降低了代码管理的复杂性。另一方面，可以隔离用于不同应用的专用资源，例如，专用资源252和254可以专用于应用110，并且专用资源256和258可以专用于应用120。以此方式，可以降低代码之间的耦合度，并且可以在最终的目标资源212和222中仅仅包括用于各自应用的代码资源。以此方式，可以确保目标资源中不包括冗余资源，因而降低代码体积进而提高运行效率。

组件管理的具体实现

上文已经描述了组件管理的架构，在下文中，将详细描述组件管理过程中涉及的更多细节。根据本公开的一个示例性实现方式，组件生成器260可以经由多种方式来接收描述210和220，例如，可以从应用110和120的开发工程师处采集描述210和220。在本公开的上下文中，并不限制以何种方式来接收描述：例如，组件生成器260可以接收由开发工程师定义的描述文件；又例如，组件生成器260可以向开发工程师提供对话框，以便接收来自开发工程师定义的描述210和220。

在接收到描述210和220的情况下，组件生成器260可以分析描述210和描述220，以便确定代码框架230中包括的通用资源250和各个专用资源。在下文中，参见图3描述确定通用资源250和各个专用资源的更多细节。图3示出了根据本公开的一些实现方式的基于分别用于多个应用的多个描述来确定代码框架中的通用资源和专用资源的过程的框图300。如图3所示，描述可以包括页面样式和页面逻辑。在此，页面样式表示显示页面的方式，例如，页面背景色、页面中文字的颜色、字体、字号、页面中各种元素的尺寸和布局，等等。通常而言，页面样式不依赖于应用的上下文功能。页面逻辑可以包括用于实现组件中的页面的各种功能的资源，例如，以不同方式显示内容区域和比分区域的资源，等等。页面逻辑通常依赖于应用的上下文功能。

根据本公开的一个示例性实现方式，可以将描述划分为页面样式(即，上下文无关)和页面逻辑(即，上下文相关)两种情况。以此方式，可以处理组件开发过程中涉及的各种场景，进而以普遍适用的方式管理组件开发过程。

如图3所示，可以基于描述中的各个部分是否依赖于应用的上下文功能，将描述拆分为页面样式和页面逻辑，以便分别以不同方式进行后续处理。例如，描述210可以涉及页面逻辑310、页面样式312和页面逻辑314；进一步，描述220可以涉及页面逻辑320、页面样式322和页面逻辑324。通过比较发现，页面逻辑310和320涉及相同的功能，即分别在应用110和120中以分页签方式显示组件，此时页面逻辑310和320可以共享相同资源。也即，可以利用通用资源250来实现页面逻辑310和320。

根据本公开的一个示例性实现方式，可以以目前已知的和/或将在未来开发的多种方式实现通用资源250。例如，可以在单独的代码文件中实现通用资源250，也可以在多个代码文件中实现通用资源250。此时通过在组件中导入并调用相应代码文件，即可实现调用通用资源250。

进一步，由于页面样式312和322的具体显示方式不同，需要分别利用专用资源252和256来实现页面样式312和322。通常而言，页面样式不依赖于应用的上下文功能，因而可以基于独立于目标应用的独立资源来确定此类专用资源。如图3所示，可以利用专用资源252来实现页面样式312，并且利用专用资源256来实现页面样式322。

对于上下文无关的页面样式，本身没有交互或相互引用，页面样式可以直接在编译时确定，并不需要在后期运行时确定。因此，可以直接将每个应用的页面样式相关资源拆分成独立的文件进行维护。例如，可以利用单独的文件来存储与页面样式相关的资源。具体地，可以为每个应用单独维护样式文件：可以使用文件app1.css来实现页面样式312，并且使用文件app2.css来实现页面样式322。此时，代码框架230中的专用资源252可以包括调用文件app1.css的语句，以便实现页面样式312；并且专用资源256可以包括调用文件app1.css的语句，以便实现页面样式322。

将会理解，图3仅示意性示出了页面样式312和322不同的情况，假设两个页面样式以相同的方式来呈现页面，则此时可以使用相同的文件(例如，app.css)来实现两个相同的页面样式。此时，代码框架230将包括指向该页面样式文件的通用资源(未示出)，并且两个应用可以调用该通用资源，以便在两个应用中以相同的样式呈现背景色、字体，等等。

根据本公开的一个示例性实现方式，由于页面逻辑314和324的具体显示内容不同，需要分别利用专用资源254和258来实现页面逻辑314和324。通常而言，页面逻辑涉及应用的上下文相关功能，此时可以利用包括用于从目标应用接收上下文相关功能的上下文参数的接口的依赖资源，来确定专用资源。此时，页面逻辑与应用具有上下文联系，例如页面逻辑涉及内部有相互引用和交互。具体地，在组件中显示内容区域时，针对不同应用需要显示不同的内容。又例如，当应用的用户与应用交互时(例如，点击组件中的区域)需要判断将交互反馈到哪个应用，等等。此时，需要在运行时才能确定用户具体使用哪个应用。因此，需要确定应用的具体上下文参数。

根据本公开的一个示例性实现方式，可以提供专用上下文参数：例如，_APP1可以表示用于提供新闻服务的应用110，并且_APP2可以表示用于提供视频服务的应用120。在下文中，参见图4描述实现页面逻辑相关的专用资源的更多细节。图4示出了根据本公开的一些实现方式的代码框架的框图400。如图4所示，代码框架230可以包括多个部分：通用资源250可以实现在应用110和120之间共享的部分，也即，显示分页签的功能。进一步，代码框架230可以包括：专用资源254，用于实现在应用110中显示文本内容的功能；以及专用资源258，用于实现在应用120中显示视频内容的功能。

将会理解，在上文描述中仅以在应用110的内容区域112中显示文本以及在应用120的内容区域122中显示视频作为专用功能的具体示例，描述了如何确定专用资源的过程。根据本公开的一个示例性实现方式，专用功能还可以包括一个或多个其他功能。例如，在应用110的比分区域114和应用120的比分区域124中，可以以不同格式来显示比分。此时，可以基于定义比分区域114和124的具体描述，来分别确定用于实现各个比分区域114和124的功能的专用资源。

利用本公开的示例性实现方式，在代码框架230中可以以统一方式管理用于不同应用中的组件的资源。此时对于多个应用110和120，仅需要维护单一版本的代码框架230。以此方式，可以降低管理组件开发的复杂度，并且避免重复开发的额外开销。进一步，利用上下文参数“_APP1”和“_APP2”，在代码框架230中可以隔离分别用于不同应用的资源。以此方式，可以便于在后期针对某个目标应用生成相应的目标资源。

根据本公开的一个示例性实现方式，可以在组件开发的各个阶段调用组件生成器260。例如，在组件开发初期，可以利用组件生成器260来生成代码框架230。可以在代码框架230中预先指定通用资源和专用资源的位置。此时，可以在代码框架230的通用资源和专用资源可以是预留区域，并且可以向开发工程师提示在这些预留区域中编写通用资源和专用资源。具体地，可以在对话框中提示开发工程师来导入相应的代码，或者直接在对话框中编写代码。

备选地和/或附加地，可以在组件开发过程中调用组件生成器260。假设应用110的开发工程师已经开发了自己的代码框架230，此时组件生成器260可以接收来自应用120的开发工程师的描述220，并且将该描述220与描述210进行比较。进一步，可以确定能够共享的通用资源和不能共享的专用资源。此时，组件生成器260可以将代码框架230划分为通用资源和专用资源(此时，代码框架230仅包括通用资源250和用于应用110的专用资源252和254，并且用于应用120的专用资源可以指向预留区域)。此时，两个应用110和120可以共享通用资源250，并且可以为应用120的页面样式322和页面逻辑324指定相应的专用资源256和258(例如，指向预留区域)。进一步，可以提示应用120的开发工程师来补充并且完善专用资源256和258的内容。

利用本公开的示例性实现方式，可以在组件开发的多个阶段中调用组件生成器260，进而便于开发人员在需要时共享组件代码，并且提高代码的重用性。

在已经区分了通用资源和各个专用资源的情况下，可以组合通用资源和各个专用资源，进而针对多个应用中的目标应用来生成用于实现组件240在该目标应用中的功能的目标资源。将会理解，在此的目标应用可以是应用110和120中的任一项。在下文中，参见图5描述针对不同应用生成的目标资源。

图5示出了根据本公开的一些实现方式的用于不同应用的目标资源的框图500。如图5所示，可以利用文件APP1.js来定义为应用110生成的目标资源212。该目标资源212可以包括用于导入页面样式312的专用资源252，用于实现页面逻辑310的通用资源250，以及用于实现页面逻辑314的专用资源254。进一步，可以利用文件APP2.js来定义为应用120生成的目标资源222。该目标资源222可以包括用于导入页面样式322的专用资源256，用于实现页面逻辑320的通用资源250，以及用于实现页面逻辑324的专用资源258。

将会理解，上文仅示意性示出了在应用110和120之间共享一个通用资源250的情况。根据本公开的一个示例性实现方式，应用110和120可以共享用于实现其他功能的通用资源。例如，组件240可以提供相同的“统计”功能，用于统计各个球员的得分状况。此时，可以以类似方式确定通用资源，以便在各个应用中实现“统计”功能。

根据本公开的一个示例性实现方式，可以提供更多的配置参数来定义生成目标资源的方式。参见图6描述有关配置参数的更多细节，该图6示出了根据本公开的一些实现方式的用于管理组件的配置参数的框图600。根据本公开的一个示例性实现方式，可以利用如图6所示的配置参数610(例如，以JSON格式表示)来定义生成目标资源的多个参数。将会理解，图6仅仅示意性示出了实现配置参数610的示意性数据结构，根据本公开的一个示例性实现方式，可以在表格、文件、数组和/或以其他格式存储配置参数610。

具体地，配置参数610可以包括目标应用，例如以关键字“output_client”表示，以便指定针对哪个应用来生成目标资源。

根据本公开的一个示例性实现方式，可以针对应用110和120中的任一项生成目标资源，又例如，还可以针对应用110和120两者生成目标资源。在设置"output_client":["APP1"]的情况下，可以生成如图5所示的目标资源212；在设置"output_client":["APP2"]的情况下，可以生成如图5所示的目标资源222；在设置"output_client":["APP1","APP2"]的情况下，则可以生成如图5所示的两个目标资源212和222。利用本公开的示例性实现方式，只需要修改配置参数610，即可以简单并且灵活的方式定义为哪个应用生成目标资源。

根据本公开的一个示例性实现方式，配置参数610可以进一步包括生成模式。例如以关键字“output_mode”表示，以便指定在生成的目标资源中是否包括组件在目标应用以外的另一应用中的功能。此时，可以基于生成模式来确定生成目标资源的具体方式。

根据本公开的一个示例性实现方式，拆分模式(例如，以关键字“separate”表示)可以表示在生成的目标资源中不包括组件在目标应用以外的另一应用中的功能。在设置"output_mode":"seperate"的情况下，可以基于通用资源和第一专用资源和第二专用资源中的与目标应用相对应的专用资源来生成目标资源。此时，为应用110生成目标资源可以包括通用资源250和用于应用110自身使用的专用资源252和254，而并不包括用于另一应用120使用的专用资源256和258。利用本公开的示例性实现方式，拆分模式可以隔离不同应用的专用资源，进而确保针对目标应用生成的目标资源不包括用于其他应用的冗余资源。以此方式，可以降低目标资源的体积进而提高目标资源的性能。

备选地和/或附加地，合并模式(例如，以关键字“mixed”表示)可以表示在生成的目标资源中包括组件在目标应用以外的另一应用中的功能。在设置"output_mode":"mixed"的情况下，可以基于通用资源、第一专用资源和第二专用资源来生成目标资源。此时，为应用110生成目标资源212可以包括：通用资源250、用于应用110自身使用的专用资源252和254、以及用于另一应用120使用的专用资源256和258。将会理解，目前还存在基于已有技术方案开发的大量组件，这些组件的代码资源包括用于多个应用的冗余资源。利用本公开的示例性实现方式，合并模式可以兼容已有技术方案，并且可以使得利用合并模式生成的组件可以直接被已有的应用调用。

根据本公开的一个示例性实现方式，配置参数610可以进一步包括继承模式(例如，以关键字“need_common”表示)，以便表示目标资源是否继承组件的通用页面样式(简称通用样式)。通常而言，组件框架可以包括用于描述组件的通用显示方式的通用样式(例如，背景、字体，等)。另外，组件的描述中的页面逻辑还可以指定某些特殊样式，以便覆盖组件的通用样式。

根据本公开的一个示例性实现方式，可以利用继承模式来指定是否导入组件的通用样式。图7示出了根据本公开的一些实现方式的用于基于继承模式来生成的目标资源的框图700。例如，在设置"need_common":True的情况下，在目标资源中将进一步导入通用样式。具体地，如图7所示，用于应用110的目标资源212可以包括导入通用样式的语句710。又例如，在设置"need_common":False的情况下，在目标资源212中可以不包括语句710，并且仅包括用于导入应用110的专用页面样式“app1.css”的语句。

利用本公开的示例性实现方式，继承模式可以允许设置在用于不同应用的目标资源中是否继承通用样式。在打开继承模式的情况下，开发工程师不必拷贝通用样式的代码，进而可以降低开发工程师的工作负荷。另一方面，在关闭继承模式的情况下，开发工程师自定义的显示样式将作为活跃的页面样式。以此方式，可以为组件管理过程提供更高的灵活性，并且允许开发工程师来按照具体应用环境选择打开或者关闭继承模式。

根据本公开的一个示例性实现方式，组件生成器260可以向开发工程师提供修改配置参数610的接口。例如，经由配置文件和/或专用对话框来修改配置参数610。利用本公开的示例性实现方式，可以为管理组件开发过程提供更多的灵活性，进而以更高的效率实现在多个应用之间共享组件。

根据本公开的一个示例性实现方式，开发人员可以针对目标资源进行进一步的调试和发布。在调试过程中，允许开发人员进行修改。将会理解，允许开发人员直接修改代码框架230中的通用资源和专用资源。此时，可以基于修改后的代码框架230中的各种资源生成新的目标资源，进而用于下一轮次的调试。将会理解，多个应用的大量开发人员频繁地修改代码框架230，可能会向代码框架230引入不稳定因素并且增加版本管理的难度。此时，可以允许开发人员修改用于自身应用的目标资源，并且在完成阶段调试并且获得较为稳定的版本之后(例如，每天一次，或者按照其他时间间隔)，再将该版本反馈至代码框架230。

图8示出了根据本公开的一些实现方式的修改代码框架的过程的框图800。图8示出了开发人员修改目标资源212的情况，在接收到针对目标资源212中的与通用资源250相对应的部分(例如，代码资源810)的修改，可以基于该修改来更新代码框架230中的通用资源250。将会理解，由于通用资源250涉及多个应用，有关通用资源250的修改需要多个应用的开发工程师之间的协调。例如，在协调一致的基础上，可以修改目标资源212中的代码资源810，进而将修改提交至代码框架230。备选地和/或附加地，可以由组件生成器260确定是否接受修改。备选地和/或附加地，组件生成器260可以允许在代码框架230处直接接收修改的通用资源250。

根据本公开的一个示例性实现方式，在接收到针对目标资源212中的与用于目标应用的专用资源254相对应的部分(例如，代码资源820)的修改，可以基于该修改来更新代码框架230中的用于目标应用的专用资源254。将会理解，专用资源254仅由应用110调用，因而无需协调多个应用的开发工程师，即可基于该修改来更新代码框架230。利用本公开的示例性实现方式，在提供统一的代码框架230的情况下，允许多个应用的开发人员执行各自的调试和发布工作。以此方式，可以将特定应用的开发工程师与无关代码资源相隔离，进而提高开发效率。

根据本公开的一个示例性实现方式，可以基于上文描述的过程来不断更新代码框架230的内容。利用本公开的示例性实现方式，可以以统一方式管理代码框架230，并且可以确保代码框架230可以以迭代方式被及时更新。进一步，可以基于代码框架230中的更新的通用资源和更新的用于目标应用的专用资源，来更新目标资源。以此方式，组件生成器260可以向开发工程师提供更为便捷的共享开发环境，进而便于在多个应用之间共享组件。

根据本公开的一个示例性实现方式，在已经完成组件的调试之后，可以发布相应的组件。例如，可以发布来自目标资源212和222的最终组件。此时，应用110和120可以经由指定的地址来访问最终组件，进而实现在应用110和120中分别提供完成期望功能的组件。

根据本公开的一个示例性实现方式，多个应用可以是实现不同功能的软件应用，例如，上文描述的用于提供新闻服务的应用110和用于提供视频服务的应用120。在本公开的上下文中，并不限制各个应用所基于的操作系统，例如，应用110和应用120可以是基于相同或者不同操作系统开发的应用。根据本公开的一个示例性实现方式，多个应用可以是基于不同操作系统开发的用于实现相同功能的软件应用。例如，两个应用可以是基于不同操作系统开发的用于实现视频服务的应用。

将会理解，尽管上文以应用110和120为示例描述了在两个应用之间共享组件的过程。根据本公开的一个示例性实现方式，可以在更多应用之间共享组件。例如，除了上文描述的提供新闻的应用110和提供视频的应用120，还可以在用于提供即时消息服务的应用中调用上文描述的“体育”组件。此时，可以在即时消息服务的应用中，以分页签方式显示“体育”组件。基于该应用的具体描述，“体育”组件在该应用中可以具有自定义的功能。例如，可以以红色背景和黑色字体显示文字，可以以文本和图片方式显示内容区域，等等。

利用本公开的示例性实现方式，允许在多个应用之间共享组件开发过程。以此方式，多个应用中的组件可以共享相同的代码框架。此时，在编写组件代码时只需要编写一套代码，从而避免因为针对每个应用维护各自的组件版本的场景下导致的需要逐一修改每个版本的情况。进一步，为各个应用生成的目标资源可以隔离各个应用的特殊功能，进而保证最终部署的组件资源体积较小，从而实现更快的响应速度。

利用本公开的示例性实现方式，可以以更为精细的粒度来管理组件240的代码框架230。换言之，组件240的代码框架230的功能被进一步拆分为通用资源和专用资源，由此允许在组件内部以更为精细的方式，实现代码共享。

示例过程

图9示出了根据本公开的一些实现方式的管理应用的组件的方法900的流程图。具体地，在框910处，接收用于分别定义组件在第一应用中的第一功能的第一描述以及组件在第二应用中的第二功能的第二描述，第一功能和第二功能分别包括组件在第一应用和第二应用中的页面样式；在框920处，基于第一描述和第二描述，确定用于实现组件的代码框架中的通用资源、第一专用资源和第二专用资源，通用资源实现第一功能和第二功能之间的通用功能，第一专用资源实现第一功能中的第一专用功能，以及第二专用资源实现第二功能中的第二专用功能；以及在框930处，基于通用资源、第一专用资源和第二专用资源，针对第一应用和第二应用中的目标应用，生成用于实现组件在目标应用中的功能的目标资源。

根据本公开的一个示例性实现方式，确定第一专用资源包括：响应于确定第一描述涉及上下文无关功能，基于独立于目标应用的独立资源来确定第一专用资源。

根据本公开的一个示例性实现方式，第一功能进一步包括组件在第一应用中的页面逻辑，以及确定第一专用资源包括：响应于确定第一描述涉及上下文相关功能，基于依赖于目标应用的依赖资源来确定第一专用资源，依赖资源包括用于从目标应用接收上下文相关功能的上下文参数的接口。

根据本公开的一个示例性实现方式，生成用于实现组件在目标应用中的功能的目标资源进一步包括：接收指定目标资源的生成模式，生成模式表示目标资源是否包括组件在目标应用以外的另一应用中的功能；以及基于生成模式来生成目标资源。

根据本公开的一个示例性实现方式，基于生成模式来生成目标资源包括：响应于确定生成模式表示目标资源不包括另一应用中的功能，基于通用资源和第一专用资源和第二专用资源中的与目标应用相对应的专用资源来生成目标资源。

根据本公开的一个示例性实现方式，基于生成模式来生成目标资源包括：响应于确定生成模式表示目标资源包括另一应用中的功能，基于通用资源、第一专用资源和第二专用资源来生成目标资源。

根据本公开的一个示例性实现方式，生成用于实现组件在目标应用中的功能的目标资源进一步包括：接收指定目标资源的继承模式，继承模式表示目标资源是否继承组件的通用页面样式；以及基于继承模式来生成目标资源。

根据本公开的一个示例性实现方式，方法900进一步包括以下至少任一项：响应于接收到针对目标资源中的与通用资源相对应的部分的修改，基于修改来更新代码框架中的通用资源；以及响应于接收到针对目标资源中的与用于目标应用的专用资源相对应的部分的修改，基于修改来更新代码框架中的用于目标应用的专用资源。

根据本公开的一个示例性实现方式，方法900进一步包括：基于代码框架中的更新的通用资源和更新的用于目标应用的专用资源，更新目标资源。

根据本公开的一个示例性实现方式，第一应用和第二应用是用于实现不同功能的软件应用。

根据本公开的一个示例性实现方式，第一应用和第二应用是基于不同操作系统开发的用于实现相同功能的软件应用。

示例装置和设备

图10示出了根据本公开的一些实现方式的用于管理应用的组件的装置1000的框图。该装置1000包括：接收模块1010，被配置用于接收用于分别定义组件在第一应用中的第一功能的第一描述以及组件在第二应用中的第二功能的第二描述，第一功能和第二功能分别包括组件在第一应用和第二应用中的页面样式；确定模块1020，被配置用于基于第一描述和第二描述，确定用于实现组件的代码框架中的通用资源、第一专用资源和第二专用资源，通用资源实现第一功能和第二功能之间的通用功能，第一专用资源实现第一功能中的第一专用功能，以及第二专用资源实现第二功能中的第二专用功能；以及生成模块1030，被配置用于基于通用资源、第一专用资源和第二专用资源，针对第一应用和第二应用中的目标应用，生成用于实现组件在目标应用中的功能的目标资源。

根据本公开的一个示例性实现方式，确定模块1020包括：样式资源确定模块，被配置用于响应于确定第一描述涉及上下文无关功能，基于独立于目标应用的独立资源来确定第一专用资源。

根据本公开的一个示例性实现方式，第一功能进一步包括组件在第一应用中的页面逻辑，以及确定模块1020包括：逻辑资源确定模块，被配置用于响应于确定第一描述涉及上下文相关功能，基于依赖于目标应用的依赖资源来确定第一专用资源，依赖资源包括用于从目标应用接收上下文相关功能的上下文参数的接口。

根据本公开的一个示例性实现方式，生成模块1030进一步包括：生成模式接收模块，被配置用于接收指定目标资源的生成模式，生成模式表示目标资源是否包括组件在目标应用以外的另一应用中的功能；以及功能生成模块，被配置用于基于生成模式来生成目标资源。

根据本公开的一个示例性实现方式，功能生成模块包括：拆分模式生成模块，被配置用于响应于确定生成模式表示目标资源不包括另一应用中的功能，基于通用资源和第一专用资源和第二专用资源中的与目标应用相对应的专用资源来生成目标资源。

根据本公开的一个示例性实现方式，功能生成模块包括：合并模式生成模块，被配置用于响应于确定生成模式表示目标资源包括另一应用中的功能，基于通用资源、第一专用资源和第二专用资源来生成目标资源。

根据本公开的一个示例性实现方式，生成模块1030进一步包括：继承模式接收模块，被配置用于接收指定目标资源的继承模式，继承模式表示目标资源是否继承组件的通用页面样式；以及样式生成模块，被配置用于基于继承模式来生成目标资源。

根据本公开的一个示例性实现方式，该装置1000进一步包括以下至少任一项：通用修改模块，被配置用于响应于接收到针对目标资源中的与通用资源相对应的部分的修改，基于修改来更新代码框架中的通用资源；以及专用修改模块，被配置用于响应于接收到针对目标资源中的与用于目标应用的专用资源相对应的部分的修改，基于修改来更新代码框架中的用于目标应用的专用资源。

根据本公开的一个示例性实现方式，该装置1000进一步包括：更新模块，被配置用于基于代码框架中的更新的通用资源和更新的用于目标应用的专用资源，更新目标资源。

根据本公开的一个示例性实现方式，第一应用和第二应用是用于实现不同功能的软件应用。

根据本公开的一个示例性实现方式，第一应用和第二应用是基于不同操作系统开发的用于实现相同功能的软件应用。

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

如图11所示，计算设备1100是通用计算设备的形式。计算设备1100的组件可以包括但不限于一个或多个处理器或处理单元1110、存储器1120、存储设备1130、一个或多个通信单元1140、一个或多个输入设备1150以及一个或多个输出设备1160。处理单元1110可以是实际或虚拟处理器并且能够根据存储器1120中存储的程序来执行各种处理。在多处理器系统中，多个处理单元并行执行计算机可执行指令，以提高计算设备1100的并行处理能力。

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

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

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

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

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

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

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

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

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

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

Claims (20)

1.一种用于管理应用的组件的方法，包括：

接收用于分别定义组件在第一应用中的第一功能的第一描述以及所述组件在第二应用中的第二功能的第二描述，所述第一功能和所述第二功能分别包括所述组件在所述第一应用和所述第二应用中的页面样式；

基于所述第一描述和所述第二描述，确定用于实现所述组件的代码框架中的通用资源、第一专用资源和第二专用资源，所述通用资源实现所述第一功能和所述第二功能之间的通用功能，所述第一专用资源实现所述第一功能中的第一专用功能，以及所述第二专用资源实现所述第二功能中的第二专用功能；以及

基于所述通用资源、所述第一专用资源和所述第二专用资源，针对所述第一应用和所述第二应用中的目标应用，生成用于实现所述组件在所述目标应用中的功能的目标资源。

2.根据权利要求1的所述方法，其中确定所述第一专用资源包括：响应于确定所述第一描述涉及上下文无关功能，基于独立于所述目标应用的独立资源来确定所述第一专用资源。

3.根据权利要求1的所述方法，其中所述第一功能进一步包括所述组件在所述第一应用中的页面逻辑，以及确定所述第一专用资源包括：响应于确定所述第一描述涉及上下文相关功能，基于依赖于所述目标应用的依赖资源来确定所述第一专用资源，所述依赖资源包括用于从所述目标应用接收所述上下文相关功能的上下文参数的接口。

4.根据权利要求1的所述方法，其中生成用于实现所述组件在所述目标应用中的所述功能的所述目标资源进一步包括：

接收指定所述目标资源的生成模式，所述生成模式表示所述目标资源是否包括所述组件在所述目标应用以外的另一应用中的功能；以及

基于所述生成模式来生成所述目标资源。

5.根据权利要求4的所述方法，其中基于所述生成模式来生成所述目标资源包括：

响应于确定所述生成模式表示所述目标资源不包括所述另一应用中的所述功能，基于所述通用资源和所述第一专用资源和所述第二专用资源中的与所述目标应用相对应的专用资源来生成所述目标资源。

6.根据权利要求4的所述方法，其中基于所述生成模式来生成所述目标资源包括：

响应于确定所述生成模式表示所述目标资源包括所述另一应用中的所述功能，基于所述通用资源、所述第一专用资源和所述第二专用资源来生成所述目标资源。

7.根据权利要求1的所述方法，其中生成用于实现所述组件在所述目标应用中的所述功能的所述目标资源进一步包括：

接收指定所述目标资源的继承模式，所述继承模式表示所述目标资源是否继承所述组件的通用页面样式；以及

基于所述继承模式来生成所述目标资源。

8.根据权利要求1的所述方法，进一步包括以下至少任一项：

响应于接收到针对所述目标资源中的与所述通用资源相对应的部分的修改，基于所述修改来更新所述代码框架中的所述通用资源；以及

响应于接收到针对所述目标资源中的与用于所述目标应用的专用资源相对应的部分的修改，基于所述修改来更新所述代码框架中的用于所述目标应用的专用资源。

9.根据权利要求8的所述方法，进一步包括：基于所述代码框架中的更新的通用资源和更新的用于所述目标应用的专用资源，更新所述目标资源。

10.根据权利要求1的所述方法，其中所述第一应用和所述第二应用满足以下至少任一项：

所述第一应用和所述第二应用是用于实现不同功能的软件应用；以及

所述第一应用和所述第二应用是基于不同操作系统开发的用于实现相同功能的软件应用。

11.一种用于管理应用的组件的装置，包括：

接收模块，被配置用于接收用于分别定义组件在第一应用中的第一功能的第一描述以及所述组件在第二应用中的第二功能的第二描述，所述第一功能和所述第二功能分别包括所述组件在所述第一应用和所述第二应用中的页面样式；

确定模块，被配置用于基于所述第一描述和所述第二描述，确定用于实现所述组件的代码框架中的通用资源、第一专用资源和第二专用资源，所述通用资源实现所述第一功能和所述第二功能之间的通用功能，所述第一专用资源实现所述第一功能中的第一专用功能，以及所述第二专用资源实现所述第二功能中的第二专用功能；以及

生成模块，被配置用于基于所述通用资源、所述第一专用资源和所述第二专用资源，针对所述第一应用和所述第二应用中的目标应用，生成用于实现所述组件在所述目标应用中的功能的目标资源。

12.根据权利要求11的所述装置，其中所述确定模块包括：样式资源确定模块，被配置用于响应于确定所述第一描述涉及上下文无关功能，基于独立于所述目标应用的独立资源来确定所述第一专用资源。

13.根据权利要求11的所述装置，其中所述第一功能进一步包括所述组件在所述第一应用中的页面逻辑，以及所述确定模块包括：逻辑资源确定模块，被配置用于响应于确定所述第一描述涉及上下文相关功能，基于依赖于所述目标应用的依赖资源来确定所述第一专用资源，所述依赖资源包括用于从所述目标应用接收所述上下文相关功能的上下文参数的接口。

14.根据权利要求11的所述装置，其中所述生成模块进一步包括：

生成模式接收模块，被配置用于接收指定所述目标资源的生成模式，所述生成模式表示所述目标资源是否包括所述组件在所述目标应用以外的另一应用中的功能；以及

功能生成模块，被配置用于基于所述生成模式来生成所述目标资源。

15.根据权利要求14的所述装置，其中所述功能生成模块包括：

拆分模式生成模块，被配置用于响应于确定所述生成模式表示所述目标资源不包括所述另一应用中的所述功能，基于所述通用资源和所述第一专用资源和所述第二专用资源中的与所述目标应用相对应的专用资源来生成所述目标资源。

16.根据权利要求14的所述装置，其中所述功能生成模块包括：

合并模式生成模块，被配置用于响应于确定所述生成模式表示所述目标资源包括所述另一应用中的所述功能，基于所述通用资源、所述第一专用资源和所述第二专用资源来生成所述目标资源。

17.根据权利要求11的所述装置，其中所述生成模块进一步包括：

继承模式接收模块，被配置用于接收指定所述目标资源的继承模式，所述继承模式表示所述目标资源是否继承所述组件的通用页面样式；以及

样式生成模块，被配置用于基于所述继承模式来生成所述目标资源。

18.根据权利要求11的所述装置，进一步包括：

通用修改模块，被配置用于响应于接收到针对所述目标资源中的与所述通用资源相对应的部分的修改，基于所述修改来更新所述代码框架中的所述通用资源；以及

专用修改模块，被配置用于响应于接收到针对所述目标资源中的与用于所述目标应用的专用资源相对应的部分的修改，基于所述修改来更新所述代码框架中的用于所述目标应用的专用资源；以及

更新模块，被配置用于基于所述代码框架中的更新的通用资源和更新的用于所述目标应用的专用资源，更新所述目标资源。

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

至少一个处理单元；以及

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

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

Images