CN114840183A - 一种基于用户行为的微前端调整方法及装置 - Google Patents

Abstract

本文涉及金融领域，尤其涉及一种基于用户行为的微前端调整方法及装置。该方法应用于微前端服务，包括：根据系统功能生成多个初始子工程，其中，各初始子工程包括至少一种与初始子工程的功能相关的业务模块；获取用户历史行为数据，根据用户历史行为数据确定用户对所述初始子工程中各业务模块的访问数据；根据所述访问数据调整所述初始子工程中的业务模块，确定新的子工程；根据所述新的子工程更新所述系统，将更新后的系统推送至用户。本方案将系统以功能划分为功能模块，基于用户行为分析进行工程拆分，减少模块之间的相互跳转，提升访问速度、提升用户交互体验、提高系统性能，减少开发维护成本。

Description

一种基于用户行为的微前端调整方法及装置

技术领域

本文涉及金融领域，尤其是一种基于用户行为的微前端调整方法及装置。

背景技术

随着银行等大型企业业务需求的不断增加，应用系统的功能也越来越复杂。工程目录文件数的日渐增多进一步造成代码行数越来越多，日常业务的维护难度也随之增大。

现有技术中利用微前端技术进行工程拆分，主要是根据业务划分的功能模块来拆分。通过此种方法拆分的子工程经过整合上线后，与用户实际的交互使用习惯有偏差。子工程会在子应用之间来回跳转，从而增加了子应用之间的耦合(例如，跳转、传值或相互调用)，影响了系统性能和用户体验，同时也增加了开发维护成本。

针对现有技术中子应用之间耦合程度高、系统性能低的问题，需要一种基于用户行为的微前端调整方法及装置。

发明内容

为解决上述现有技术的问题，本文实施例提供了一种基于用户行为的微前端调整方法、装置、计算机设备、存储介质及计算机程序产品。

本文实施例提供了一种基于用户行为的微前端调整方法，应用于微前端服务，包括：根据系统功能生成多个初始子工程，其中，各初始子工程包括至少一种与初始子工程的功能相关的业务模块；获取用户历史行为数据，根据用户历史行为数据确定用户对所述初始子工程中各业务模块的访问数据；根据所述访问数据调整所述初始子工程中的业务模块，确定新的子工程；根据所述新的子工程更新所述系统，将更新后的系统推送至用户。

根据本文实施例的一个方面，所述用户历史行为数据包括：用户在预设时间段内对各初始子工程中各业务模块的页面访问量、用户访问量、页面停留时间及页面转化率中的一种或几种的组合。

根据本文实施例的一个方面，所述根据用户历史行为数据确定用户对初始子工程中各业务模块的访问数据包括：根据用户历史行为数据中的页面访问量，或根据用户访问量及页面停留时间，确定用户对各业务模块的访问量及用户对所有业务模块的总访问量。

根据本文实施例的一个方面，所述根据用户历史行为数据确定用户对初始子工程中各业务模块的访问数据还包括：根据预设时间段内的页面转化率，确定用户访问各业务模块的顺序；根据用户访问各业务模块的顺序，确定用户对业务模块的访问路径。

根据本文实施例的一个方面，根据所述用户访问数据调整初始子工程中的业务模块包括：根据所述访问量与所述总访问量，确定用户对各业务模块的访问量比例；若所述访问量比例超过预设比例，将所述业务模块从初始子工程中拆分为新的子工程。

根据本文实施例的一个方面，根据所述用户访问数据调整初始子工程中的业务模块包括：根据所述访问路径中属于不同初始子工程的业务模块；将属于不同初始子工程的所述业务模块合并至所述不同初始子工程之一，形成所述新的子工程。

根据本文实施例的一个方面，将属于不同初始子工程的业务模块合并至所述不同初始子工程之一包括：比较所述访问路径中属于不同初始子工程中的业务模块的数量；将数量少的业务模块合并至数量多的业务模块所属的初始子工程中，形成新的子工程。

根据本文实施例的一个方面，根据系统功能生成多个初始子工程包括：根据系统功能，将所述系统划分为多个功能模块；分别生成各功能模块的配置文件；根据所述配置文件生成各功能模块的初始子工程，其中，每一功能模块独立实现所属初始子工程的业务功能。

根据本文实施例的一个方面，调整所述初始子工程中的业务模块进一步包括：根据业务模块的合并、独立，变更所述初始子工程的配置文件中与调整的业务模块相关的字段，确定新的子工程。

本文实施例还提供了一种基于用户行为的微前端调整装置，所述装置包括：

初始子工程生成单元，用于根据系统功能生成多个初始子工程，其中，各初始子工程包括至少一种与初始子工程的功能相关的业务模块；

访问数据确定单元，用于根据用户历史行为数据确定用户对所述初始子工程中各业务模块的访问数据；

新的子工程确定单元，用于根据所述访问数据调整所述初始子工程中的业务模块，得到新的子工程；

推送单元，用于根据所述新的子工程及初始子工程更新所述系统，并推送至用户。

本文实施例还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述方法。

本文实施例还提供了一种计算机可读存储介质，其上存储有计算机指令，该计算机指令被处理器执行时实现上述的方法。

本文实施例还公开了一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现上述的方法。

本方案将系统以功能划分为功能模块，基于用户行为分析进行工程拆分，减少模块之间的相互跳转，提升访问速度、提升用户交互体验、提高系统性能，减少开发维护成本。

附图说明

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

图1所示为本文实施例一种基于用户行为的微前端调整方法的流程图；

图2所示为本文实施例一种确定用户对初始子工程中各业务模块的访问数据的方法流程图；

图3所示为本文实施例一种调整初始子工程的业务模块的方法流程图；

图4所示为本文实施例一种调整初始子工程的业务模块的又一方法流程图；

图5所示为本文实施例一种合并业务模块的方法流程图；

图6所示为本文实施例一种生成初始子工程的方法流程图；

图7所示为本文实施例基于用户行为的微前端调整装置的结构示意图；

图8所示为本文实施例基于用户行为的微前端调整装置的具体结构示意图；

图9A所示本文实施例初始子工程的示意图；

图9B所示为本文实施例另一初始子工程的示意图；

图9C所示为调整后的子工程的示意图；

图10所示为本文实施例一种计算机设备的结构示意图。

附图符号说明：

701、初始子工程生成单元；

7011、功能模块划分模块；

7012、配置文件生成模块；

702、访问数据确定单元；

7021、用户历史行为数据获取模块；

7022、访问量确定模块；

7023、访问路径确定模块；

703、新的子工程确定单元；

7031、子工程拆分模块；

7032、子工程合并模块；

704、推送单元；

1002、计算机设备；

1004、处理器；

1006、存储器；

1008、驱动机构；

1010、输入/输出模块；

1012、输入设备；

1014、输出设备；

1016、呈现设备；

1018、图形用户接口；

1020、网络接口；

1022、通信链路；

1024、通信总线。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本文实施例中的附图，对本文实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本文一部分实施例，而不是全部的实施例。基于本文中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本文保护的范围。

需要说明的是，本文的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本文的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、装置、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或装置产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。

需要说明的是，本文的基于用户行为的微前端调整方法可用于金融领域，也可用于除金融领域之外的其他领域，例如，软件开发领域、分布式架构。本文对基于用户行为的微前端调整方法及装置的应用领域不做限定。

如图1所示为本文实施例一种基于用户行为的微前端调整方法的流程图，其中具体包括如下步骤：

步骤101，根据系统功能生成多个初始子工程，其中，各初始子工程包括至少一种与初始子工程的功能相关的业务模块。

在本步骤中，系统可以与项目对应。例如，某一普惠项目的系统功能包括：撮合活动列表、活动详情、企业列表、企业详情、用户供需列表、用户发布需求、用户需求详情等功能。这些系统根据功能划分主要可以划分为三类，分别为：活动相关的功能、企业相关的功能、用户供需相关的功能。本申请实施例可以通过将系统划分为多个功能模块、分别生成各功能模块的配置文件，再根据各配置文件生成各功能模块对应的初始子工程。因此与系统功能相对应，可以将项目系统划分为多个不同的初始子工程。以上文所述的普惠项目为例，根据系统功能可以生成三个不同的初始子工程，分别为：活动初始子工程、企业初始子工程及供需初始子工程。

在本步骤中，生成的多个初始子工程及其对应的业务模块可以以子工程清单的形式体现。每一个初始子工程都包含至少一种与初始子工程的功能相关的业务模块。例如，活动初始子工程中包含活动列表、活动大厅、活动详情等业务模块；企业初始子工程中包含企业列表、企业详情等业务模块。

在本说明书的一些实施例中，可以通过语义识别、关键词识别等方式从与项目系统相关的数据库中进行识别、匹配，以根据系统功能生成初始子工程。在本说明书的另外一些实施例中，也可以根据人工设置划分初始子工程。

步骤102，获取用户历史行为数据，根据用户历史行为数据确定用户对所述初始子工程中各业务模块的访问数据。在本说明书的一些实施例中，从用户行为数据库中获取用户历史行为数据。用户历史行为数据包括但不限于：用户在预设时间段内对各初始子工程中各业务模块的页面访问量、用户访问量、页面停留时间及页面转换率。

其中，从用户行为数据库中获取的用户历史行为数据可以是同一名用户在一段时间内对各初始子工程中各个业务模块的行为数据，也可以是多个用户在一段时间内对各初始子工程中各个业务模块的行为数据。即，获取用户历史行为数据包括根据单一用户的历史行为数据确定所述用户对初始子工程中各业务模块的访问数据。获取用户历史行为数据还包括根据多个用户的历史行为数据确定所述用户对初始子工程中各业务模块的访问数据。

例如，获取一名用户甲的用户行为数据。获取该用户甲在1小时内对活动初始子工程、企业初始子工程及供需初始子工程中的各个业务模块的访问量。又例如，获取100名用户的用户行为数据。获取该100名用户在1小时内对活动初始子工程、企业初始子工及供需初始子工程中的各个业务模块的访问量。本申请对获取用户行为数据过程中的用户数量不作限定。

步骤103，根据所述访问数据调整所述初始子工程中的业务模块，确定新的子工程。在本步骤中，根据用户的访问数据可以确定用户对各个初始子工程中的业务模块的访问习惯。根据对业务模块的访问习惯，可以进一步确定各个初始子工程中不同的业务模块被访问的次数/频率，也可以进一步确定用户完成一次业务目标所访问的业务模块路径。进一步调整各个初始子工程中不同的业务模块，以确定新的子工程。

步骤104，根据所述新的子工程更新所述系统，将更新后的系统推送至用户。在本步骤中，利用调整后的新的子工程与未调整的初始子工程更新原有系统。将更新后的系统推送给用户，或将更新后的系统直接保存至服务器端由用户获取。在本说明书的一些实施例中，可以根据单一用户的历史行为数据确定新的子工程，进一步更新系统，将更新后的系统推送至对应的单一用户。在本说明书的另外一些实施例中，可以根据多个用户的历史行为数据确定新的子工程，进一步更新系统，将更新后的系统推送至多个用户。

图2所示为本文实施例一种确定用户对初始子工程中各业务模块的访问数据的方法流程图。具体包括如下步骤：

步骤201，根据预设时间段内的页面转化率，确定用户访问各业务模块的顺序。在本步骤中，页面转化率表示从一个页面转化到下一个页面的比率。根据各个页面的转化率，可以确定用户在实现业务目标过程中的访问顺序。例如，从“活动列表”业务模块可以访问“活动大厅”、“活动详情”、“企业详情”等业务模块。在一段时间内，用户在“活动列表”业务模块到“活动详情”业务模块的转化率为80％，“活动列表”业务模块到“活动大厅”业务模块的转化率为20％。则可以理解为，一段时间内有80％的用户访问“活动列表”业务模块后，直接访问了“活动详情”业务模块；在该时间段内，有20％的用户在访问“活动列表”业务模块后，直接访问了“活动大厅”业务模块。因此，根据页面转化率，可以确定用户访问各个初始子工程中业务模块的顺序。相对应的，也可以理解为：一段时间内某单一用户在访问“活动列表”业务模块后，在“活动详情”业务模块的访问量/访问次数占据了从访问“活动列表”业务模块后访问其他页面总访问量的60％。该用户在访问“活动列表”业务模块后，在“活动大厅”业务模块的访问量/访问次数占据了从访问“活动列表”业务模块后访问其他页面总访问量的40％，

例如，根据页面转化率可以确定用户在实现“报名活动A”的业务目标时的访问顺序。其中，80％的用户在查看活动初始子工程中的“活动列表”的业务模块后，会接着查看“活动详情”的业务模块，接着会查看企业初始子工程中的“企业列表”的业务模块，最后进行活动报名。因此，可以确定用户在实现“报名活动A”的业务目标时的访问顺序为：活动初始子工程的活动列表-活动初始子工程的活动详情-企业初始子工程的企业列表。

又例如，根据页面转化率可以确定用户在实现“报名活动B”的业务目标时的访问顺序。其中，20％的用户在查询获得活动初始子工程中的“活动列表”的业务模块后，会接着查询活动初始子工程中的“活动详情”的业务模块。接着进行活动报名。因为，可以确定用户在实现“报名活动B”的业务目标时的访问顺序为：活动初始子工程的活动列表-活动初始子工程的活动详情。

步骤202，根据用户访问各业务模块的顺序，确定用户对业务模块的访问路径。根据步骤201中确定得到的用户访问各业务模块的顺序，可以确定用户对业务模块的访问路径。其中，访问路径可能是在同一个初始子工程内，也可能对应多个初始子工程。例如，访问路径可以是：活动初始子工程中的活动列表模块-活动初始子工程中的活动详情模块。该访问路径在同一个初始子工程内。又例如，访问路径为：活动初始子工程中的活动列表模块-活动初始子工程中的活动详情模块-企业初始子工程中的企业列表。该访问路径对应了不同的初始子工程，包括活动初始子工程及企业初始子工程。

在本说明书的一些实施例中，还可以根据用户历史行为数据中的页面访问量，或根据用户访问量及页面停留时间，确定用户对各业务模块的访问量及用户对所有业务模块的总访问量。一方面，可以根据用户的页面访问量确定用户对各个业务模块的访问量及用户对所有业务模块的总访问量。例如，可以确定单一用户在一段时间内对各个业务模块的访问量，也可以确定所有用户在一段时间内对所有业务模块的访问量。

另一方面，可以根据用户访问量及页面停留时间确定用户对各个业务模块的访问量及停留时间、用户对所有业务模块的访问量及停留时间，进一步确定受用户欢迎或符合用户查询习惯的业务模块，以确定用户对初始子工程中各个业务模块的访问数据。

图3所示为本文实施例一种调整初始子工程的业务模块的方法流程图。具体公开了如下步骤：

步骤301，根据所述访问量与所述总访问量，确定各业务模块的访问量比例。在本步骤中，访问量、总访问量均为一段时间内的业务访问数据。例如，1分钟、10分钟、20分钟、1小时、2小时、10小时、24小时内对各业务模块的访问量及对所有业务模块的访问量。访问量可以根据用户历史行文数据中的页面访问量确定，也可以根据用户访问量及页面停留时间两者共同确定。

根据对每个业务模块的访问量与对所有业务模块的总访问量的比值，可以确定各业务模块的访问量情况。例如，对活动初始子工程中的“活动大厅”业务模块的访问量为1000，对所有初始子工程中所有业务模块的访问量为1500，则可以计算得到“活动大厅”业务模块的访问量比例为2/3。又例如，对活动初始子工程中的“企业详情”业务模块的访问量为200，对所有初始子工程中所有业务模块的访问量为1500。则可以计算得到“业务详情”业务模块的访问量比例为2/15。

步骤302，若所述访问量比例超过预设比例，将所述业务模块从初始子工程中拆分为新的子工程。当访问量较大，超过预设比例，则认为该访问量较大的业务模块受用户欢迎，因此将该业务模块从其所属的初始子工程中拆分出来，单独成为一个新的子工程。例如，预设比例为1/2，则步骤301中活动初始子工程中的“活动大厅”业务模块的访问量比例超过预设比例，因此将“活动大厅”业务模块独立拆分为一个单独的子工程，如图9B所示。以便降低系统间业务模块的跳转、降低耦合和跳转开销，方便扩缩容、减少系统崩溃概率，保证系统安全可靠运行。当访问量较小未超过预设比例，则认为该访问量对应的业务模块较为普通，对该业务模块不作操作。在本步骤中，预设比例可以是预先设定的，也可以根据实际业务情况实时调整。

图4所示为本文实施例一种调整初始子工程的业务模块的又一方法流程图。具体包括如下步骤：

步骤401，根据所述访问路径，确定访问路径中属于不同初始子工程的业务模块。在本步骤中，当访问路径对应不同的初始子工程时，确定该访问路径中属于不同初始子工程的业务模块。例如，访问路径为：活动初始子工程中的活动列表模块-活动初始子工程中的活动详情模块-企业初始子工程中的企业列表。该访问路径中包括了活动初始子工程及企业初始子工程两个初始子工程。其中，该访问路径中包括“活动列表”、“活动详情”、“活动大厅”及“企业列表”4个业务模块。其中，“活动列表”、“活动详情”、“活动大厅”属于同一个活动初始子工程；“企业列表”属于企业初始子工程。

步骤402，将属于不同初始子工程的所述业务模块合并至所述不同初始子工程之一，形成所述新的子工程。在本步骤中，将属于不同初始子工程的业务模块进行合并。其中，可以将所有业务模块合并到不同初始子工程中的一个初始子工程中。本步骤关于具体如何合并业务模块的描述详见图5。

图5所示为本文实施例一种合并业务模块的方法流程图。具体包括如下步骤：

步骤501，比较访问路径中属于不同初始子工程中的业务模块的数量。在本步骤中，对于包含不同初始子工程的访问路径，需要进一步比较该访问路径中属于不同初始子工程的业务模块的数量。例如，如图9A实现箭头所示，某用户访问路径为：活动初始子工程中的活动列表模块-活动初始子工程中的活动详情模块-企业初始子工程中的企业列表。其中，属于活动初始子工程的业务模块的数量为2个，分别为：“活动列表”、“活动详情”；属于企业初始子工程的业务模块的数量为1个，为：“企业列表”。

步骤502，将数量少的业务模块合并至数量多的业务模块所属的初始子工程中，形成新的子工程。将数量少的业务模块合并至数量多的业务模块所属的初始子工程中，可以减少同一访问路径中属于不同的初始子工程的业务模块之间的调用，提升访问速度，进一步提升用户体验。

以步骤501中的例子为例，属于活动初始子工程的业务模块的数量有2个；属于企业初始子工程的业务模块的数量为1个。则将企业初始子工程中的1个业务模块合并至活动初始子工程中，该访问路径对应形成新的子工程。即，将企业初始模块中的“企业列表”业务模块合并到活动初始模块中，如图9C所示。

如图6所示为本文实施例一种生成初始子工程的方法流程图。具体包括如下步骤：

步骤601，根据系统功能，将所述系统划分为多个功能模块。可以将系统中关联紧密的功能划分到相同的功能模块中。如步骤101中所述，根据功能将系统划分为不同的功能模块。本步骤中。例如，某普惠项目的系统具有如下功能：从该系统的活动列表可以查询到活动详情，在活动详情下可以查询到企业列表，从企业列表可以查询到企业详情，在企业详情下又可以发布供求信息。因此可以将该系统划分为三类功能，分别为：活动相关的功能、企业相关的功能、用户供需相关的功能。相对应的将系统划分为三个功能模块：活动模块、企业模块及供需模块。

步骤602，分别生成各功能模块的配置文件。本步骤根据步骤601中的功能模块划分结果，根据一定规则生成各个功能模块的配置文件。其中，配置文件包括功能模块的名称、功能列表、技术类型等。

在本说明书的一些实施例中提供了活动模块及企业模块对应的配置文件对应的代码，如下所示：

其中，配置文件中包括模块名、功能列表及技术类型。例如配置文件中的“Activity”、“Enterprise”为模块名，分别表示活动模块、企业模块，表示配置文件对应的划分后的功能模块的名称。配置文件中的Moules表示该配置文件所包含的业务功能列表或业务功能页面。例如，活动模块“Activity”中包含的功能列表为：“Moules”:[‘ActivityList’,‘ActivityDetail’,‘ActivityHall’](活动清单、活动列表和活动大厅)。配置文件中的Template表示技术类型；Terminal表示该配置文件连接的终端。

步骤603，根据所述配置文件生成各功能模块对应的初始子工程，其中，每一初始子工程功能独立实现其对应的功能模块的功能。在本步骤中，初始子工程根据步骤602中生成的配置文件脚本直接生成。其中，初始子工程与功能模块一一对应，每个初始子工程可以实现一个功能模块的功能。例如，活动模块对应的初始子工程“Activity”为活动初始子工程，其包括‘ActivityList’,‘ActivityDetail’活动列表和活动详情两个功能页面。该活动初始子工程可以实现活动模块的功能。

在本说明书的一些实施例中，调整所述初始子工程中的业务模块进一步包括：根据业务模块的合并、独立，变更所述初始子工程的配置文件中与调整的业务模块相关的字段，确定新的子工程。本申请中通过更改初始子工程中的配置文件的字段来调整初始子工程中业务模块与其他初始子工程中的业务模块合并，或将某业务模块独立出来形成新的子工程。如下所示为某新的子工程对应的配置文件。其中，该配置文件中包括活动业务模块、企业模块、活动大厅模块。活动模块中的功能列表包括：“活动清单”、“活动详情”、“企业列表”三个业务模块。相比于图6中示出的配置文件，本实施例将图6中活动模块中的功能列表中的‘ActivityHall’(活动大厅)功能模块独立为一个单独的子工程。并在活动模块的功能列表中增加了“企业列表”这个业务功能模块。

因此，通过在初始子工程对应的配置文件中增加或删除与待调整的业务模块相关的字段，可以更新配置文件，进一步确定新的子工程、更新系统。

如图7所示为本文实施例一种基于用户行为的微前端调整装置的结构示意图，在本图中描述了基本结构，其中的功能单元、模块可以采用软件方式实现，也可以采用通用芯片或者特定芯片实现，所述的功能单元、模块一部分或者全部可以在硬件上，该装置具体包括：

初始子工程生成单元701，用于根据系统功能生成多个初始子工程，其中，各初始子工程包括至少一种与初始子工程的功能相关的业务模块；

访问数据确定单元702，用于根据用户历史行为数据确定用户对所述初始子工程中各业务模块的访问数据；

新的子工程确定单元703，用于根据所述访问数据调整所述初始子工程中的业务模块，得到新的子工程；

推送单元704，用于根据所述新的子工程及初始子工程更新所述系统，并推送至用户。

本方案将系统以功能划分为功能模块，基于用户行为分析进行工程拆分，减少模块之间的相互跳转，提升访问速度、提升用户交互体验、提高系统性能，减少开发维护成本。

作为本文的一个实施例，还可以参考如图8所示的本实施例基于用户行为的微前端调整装置的具体结构示意图。

作为本文的一个实施例，所述初始子工程生成单元701进一步包括：

功能模块划分模块7011，用于根据系统功能，将系统划分为多个功能模块；

配置文件生成模块7012，用于分别生成各功能模块的配置文件；

作为本文的一个实施例，所述访问数据确定单元702进一步包括：

用户历史行为数据获取模块7021，用于获取用户历史行为数据；

访问量确定模块7022，用于根据用户历史行为数据，确定用户对各业务模块的访问量及用户对所有业务模块的总访问量；

访问路径确定模块7023，用于根据用户历史行为数据确定用户对业务模块的访问路径；

作为本文的一个实施例，新的子工程确定单元703进一步包括：

子工程拆分模块7031，用于将业务模块从初始子工程中拆分为新的子工程；

子工程合并模块7032，用于将属于不同初始子工程的业务模块合并至不同初始子工程之一。

图9A所示为本文实施例初始子工程的示意图。图中包括活动初始子工程及企业初始子工程。其中，活动初始子工程中包括活动列表、活动详情及活动大厅3个业务功能。企业初始子工程包括企业详情、企业列表2个业务功能。根据用户行为数据分析得到：80％的用户在查看活动信息业务模块后，会再查询报名活动的企业列表业务模块，接着进行报名操作(如图9A中实线箭头所示的操作路线)；20％的用户在查看活动信息业务模块后直接报名参加活动(如图9A中虚线箭头所示的操作路线)。

图9B所示为本文实施例另一初始子工程的示意图。图中包括活动初始子工程及企业初始子工程。其中，活动初始子工程中包括活动列表、活动详情及活动大厅3个业务功能。根据用户历史行为数据分析得到：活动大厅业务模块上有超过70％的访问量。其中，企业初始子工程中包括企业列表及企业详情2个业务模块。

图9C所示为调整后的子工程的示意图。根据用户历史行为数据对图9A和图9B中的2个初始子工程中的业务模块进行了调整，形成了新的子工程。如图所示，活动子工程中包含活动列表、活动详情及企业列表3个业务模块。企业子工程中包含企业详情业务模块，原属于活动初始子工程中的活动大厅业务模块独立为新的子工程：活动大厅子工程。

如图10所示，为本文实施例提供的一种计算机设备，所述计算机设备1002可以包括一个或多个处理器1004，诸如一个或多个中央处理单元(CPU)，每个处理单元可以实现一个或多个硬件线程。计算机设备1002还可以包括任何存储器1006，其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的，比如，存储器1006可以包括以下任一项或多种组合：任何类型的RAM，任何类型的ROM，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备1002的固定或可移除部件。在一种情况下，当处理器1004执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备1002可以执行相关联指令的任一操作。计算机设备1002还包括用于与任何存储器交互的一个或多个驱动机构1008，诸如硬盘驱动机构、光盘驱动机构等。

计算机设备1002还可以包括输入/输出模块1010(I/O)，其用于接收各种输入(经由输入设备1012)和用于提供各种输出(经由输出设备1014)。一个具体输出机构可以包括呈现设备1016和相关联的图形用户接口(GUI)1018。在其他实施例中，还可以不包括输入/输出模块1010(I/O)、输入设备1012以及输出设备1014，仅作为网络中的一台计算机设备。计算机设备1002还可以包括一个或多个网络接口1020，其用于经由一个或多个通信链路1022与其他设备交换数据。一个或多个通信总线1024将上文所描述的部件耦合在一起。

通信链路1022可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路1022可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。

对应于图1至图6中的方法，本文实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法的步骤。

本文实施例还提供一种计算机可读指令，其中当处理器执行所述指令时，其中的程序使得处理器执行如图1至图6所示的方法。

本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现如图1至图6所示的方法。

应理解，在本文的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本文实施例的实施过程构成任何限定。

还应理解，在本文实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本文的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本文所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本文实施例方案的目的。

另外，在本文各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本文的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本文中应用了具体实施例对本文的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本文的方法及其核心思想；同时，对于本领域的一般技术人员，依据本文的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本文的限制。

Claims (13)

1.一种基于用户行为的微前端调整方法，其特征在于，所述方法应用于微前端服务，包括：

根据系统功能生成多个初始子工程，其中，各初始子工程包括至少一种与初始子工程的功能相关的业务模块；

获取用户历史行为数据，根据用户历史行为数据确定用户对所述初始子工程中各业务模块的访问数据；

根据所述访问数据调整所述初始子工程中的业务模块，确定新的子工程；

根据所述新的子工程更新所述系统，将更新后的系统送至用户。

2.根据权利要求1所述的基于用户行为的微前端调整方法，其特征在于，所述用户历史行为数据包括：用户在预设时间段内对各初始子工程中各业务模块的页面访问量、用户访问量、页面停留时间及页面转化率中的一种或几种的组合。

3.根据权利要求2所述的基于用户行为的微前端调整方法，其特征在于，所述根据用户历史行为数据确定用户对所述初始子工程中各业务模块的访问数据包括：

根据用户历史行为数据中的页面访问量，或根据用户访问量及页面停留时间，确定用户对各业务模块的访问量及用户对所有业务模块的总访问量。

4.根据权利要求2所述的基于用户行为的微前端调整方法，其特征在于，所述根据用户历史行为数据确定用户对所述初始子工程中各业务模块的访问数据还包括：

根据预设时间段内的页面转化率，确定用户访问各业务模块的顺序；

根据所述用户访问各业务模块的顺序，确定用户对业务模块的访问路径。

5.根据权利要求3所述的基于用户行为的微前端调整方法，其特征在于，根据所述访问数据调整初始子工程中的业务模块包括：

根据所述访问量与所述总访问量，确定用户对各业务模块的访问量比例；

若所述访问量比例超过预设比例，将所述业务模块从初始子工程中拆分为新的子工程。

6.根据权利要求4所述的基于用户行为的微前端调整方法，其特征在于，根据所述访问数据调整初始子工程中的业务模块包括：

确定所述访问路径中属于不同初始子工程的业务模块；

将属于不同初始子工程的所述业务模块合并至所述不同初始子工程之一，形成所述新的子工程。

7.根据权利要求6所述的基于用户行为的微前端调整方法，其特征在于，将属于不同初始子工程的业务模块合并至所述不同初始子工程之一包括：

比较所述访问路径中属于不同初始子工程中的业务模块的数量；

将数量少的业务模块合并至数量多的业务模块所属的初始子工程中，形成新的子工程。

8.根据权利要求7所述的基于用户行为的微前端调整方法，其特征在于，根据系统功能生成多个初始子工程包括：

根据系统功能，将所述系统划分为多个功能模块；

分别生成各功能模块的配置文件；

根据所述配置文件生成各功能模块对应的初始子工程，其中，每一初始子工程功能独立实现其对应的功能模块的功能。

9.根据权利要求8所述的基于用户行为的微前端调整方法，其特征在于，调整所述初始子工程中的业务模块进一步包括：

根据业务模块的合并、独立，变更所述初始子工程的配置文件中与调整的业务模块相关的字段，确定新的子工程。

10.一种基于用户行为的微前端调整装置，其特征在于，所述装置包括：

初始子工程生成单元，用于根据系统功能生成多个初始子工程，其中，各初始子工程包括至少一种与初始子工程的功能相关的业务模块；

访问数据确定单元，用于根据用户历史行为数据确定用户对所述初始子工程中各业务模块的访问数据；

新的子工程确定单元，用于根据所述访问数据调整所述初始子工程中的业务模块，确定新的子工程；

推送单元，用于根据所述新的子工程更新所述系统，并推送至用户。

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

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-9任意一项所述的方法。

13.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现权利要求1至9任意一项所述的方法。

Images