CN113849242A - 生成、注册ui服务包、以及加载ui服务的方法及装置 - Google Patents

Abstract

本申请公开了一种生成、注册UI服务包、以及加载UI服务的方法及装置，涉及软件工程领域。通过该方法中UI服务包中的UI服务构建场景类UI应用时，集成效率高，且该场景类UI应用的运行效率高。加载UI服务的方法应用于加载装置。该方法包括：接收包括待加载UI服务的复用路径的加载请求，该加载请求用于请求加载待加载UI服务；根据依赖图确定待加载UI服务的依赖；加载待加载UI服务和待加载UI服务的依赖；其中，该待加载UI服务的复用路径用于指示待加载UI服务的访问路径，该依赖图指示至少一个UI服务包中的至少一个UI服务的依赖，以及指示将该至少一个UI服务包中的任一个UI服务引用为依赖的UI服务。

Description

生成、注册UI服务包、以及加载UI服务的方法及装置

技术领域

本申请涉及软件工程领域，尤其涉及一种生成、注册用户界面(user interface，UI)服务包、以及加载UI服务的方法及装置。

背景技术

传统应用的构建，是开发人员基于用户的某一流程点(例如工作中的流程点或生活中的流程点)，实现的一组满足该流程点计算需要的工具类的UI集合。该工具类的UI集合，即为传统的工具类应用。用户根据自身场景产生的一组与工具类应用中UI交互操作的集合，可以使应用输出满足该用户的某一种场景的计算结果。

随着人工智能(artificial intelligence，AI)技术的发展，为了提高用户使用应用的体验，开发人员构建出基于AI技术的应用：基于上述用户根据场景产生的一组与UI交互操作的集合，构建场景类UI应用。其中，该场景类UI应用可以基于AI识别的用户场景，为用户提供场景UI。用户与场景UI产生一次交互，即可输出用户与工具类UI需要多次交互所产生的计算结果。

在现有技术中，开发人员可以基于微前端的架构开发上述场景类UI应用。然而，通过微前端架构开发的该多个场景类UI应用之间无法高效复用UI。因此，根据现有微前端架构开发的场景类UI应用的集成难度大，并且在通过多重嵌套集成UI应用时，运行效率较差。

发明内容

本申请提供了一种生成、注册UI服务包、以及加载UI服务的方法及装置，通过该方法中UI服务包中的UI服务构建开发场景类UI应用时，集成效率高，且该场景类UI应用的运行效率高。

为达上述目的，本申请提供如下技术方案：

第一方面，本申请提供了一种加载UI服务的方法，该方法应用于加载装置。该方法包括：接收加载请求。该加载请求用于请求加载待加载UI服务，该加载请求中包括待加载UI服务的复用路径，该待加载UI服务的复用路径用于指示待加载UI服务的访问路径。根据依赖图确定待加载UI服务的依赖。该依赖图指示至少一个UI服务包中的至少一个UI服务的依赖，以及指示将至少一个UI服务包中的任一个UI服务引用为依赖的UI服务。加载待加载UI服务和待加载UI服务的依赖。

其中，在软件工程中，依赖是指执行某个任务(如UI服务)时所需要的算法或函数。该算法或函数，可以是另一个任务，如UI服务或运行时依赖。依赖图是用于指示多个任务之间互相依赖的关系。其中，运行时依赖是运行UI时所需要的依赖。

通过本申请提供的方法，加载装置可以根据待加载UI服务的复用路径，在用于指示UI服务之间依赖关系的依赖图中，一次性将待加载UI服务的依赖都确定出来。这样，加载装置即可根据确定出的待加载UI服务的依赖，加载待加载UI服务，以及待加载UI服务的依赖，从而提高了加载待加载UI服务及其依赖的效率，即提高了通过UI服务集成的场景类UI应用的运行效率。

在一种可能的设计方式中，上述待加载UI服务的复用路径包括待加载UI服务所属UI服务包的模糊版本号。

根据该可能的设计，加载装置可以在加载待加载UI服务的过程中，根据复用路径中的模糊版本号，匹配到最新版本的包括待加载UI服务的UI服务包。这样，即使该UI服务包更新了版本，开发人员基于该UI服务包中的UI服务所集成的场景类UI应用也无需重新开发，从而节省了资源。

在另一种可能的设计方式中，上述依赖图是基于至少一个UI服务包中的部分或全部的UI服务包的依赖关系集得到的。

在另一种可能的设计方式中，上述依赖关系集包括部分或全部的UI服务包中的至少一个UI服务的依赖关系。其中，该部分或全部的UI服务包中的至少一个UI服务的依赖关系，用于指示该部分或全部的UI服务包中的至少一个UI服务的依赖。

在另一种可能的设计方式中，上述至少一个UI服务包中的任一个UI服务的代码包括复用路径。其中，该任一个UI服务的代码中的复用路径，用于指示该任一个UI服务的依赖的访问路径。

在另一种可能的设计方式中，上述至少一个UI服务包是在至少一个UI服务包注册装置中注册的UI服务包。

通过该可能的设计，同一个UI服务包可以在不同的注册装置中注册，从而不同的开发人员可以基于该UI服务包中的UI服务开发不同应用场景的UI服务，从而节省了开发不同场景类UI应用的工作量。

在另一种可能的设计方式中，上述至少一个UI服务包包括第一UI服务包。该第一UI服务包中的第一UI服务的代码中的复用路径，满足如下条件中的至少一种：该第一UI服务的代码中的复用路径，用于指示第二UI服务的访问路径，该第二UI服务是第一UI服务的依赖，该第二UI服务是第二UI服务包中的任一个UI服务，该第二UI服务包是不同于第一UI服务包的UI服务包；或者，该第一UI服务的代码中的复用路径，用于指示运行时依赖项的访问路径，该运行时依赖项是第一UI服务的依赖，该运行时依赖项是至少一个公共依赖UI服务包中的任一个运行时依赖项，该至少一个公共依赖UI服务包包括至少一个运行时依赖项，该至少一个公共依赖UI服务包用于为在至少一个UI服务包注册装置中注册的至少一个UI服务包中的UI服务提供依赖。其中，该第一UI服务包是上述至少一个UI服务包中的任一个UI服务包，该第一UI服务是该第一UI服务包中的任一个UI服务。

其中，运行时依赖是运行UI时所需要的依赖。当运行时依赖的代码被开发框架转化后，所得到公共依赖UI服务包中包括运行时依赖项。运行时依赖项和运行时依赖一一对应。

通过上述可能的设计，本申请中的UI服务可以用过复用路径高效的复用其他的UI服务或运行时依赖项。这样，复用了其他的UI服务或运行时依赖项的UI服务，在集成场景类UI应用时，集成效率高。

在另一种可能的设计方式中，上述“根据依赖图确定待加载UI服务的依赖”包括：根据上述依赖图确定待加载UI服务的依赖的复用路径。

这样，当加载装置确定出待加载UI服务的依赖的复用路径后，即可根据复用路径中的模糊版本号匹配到最新版本的包括该依赖的UI服务包。这样，这样，即使该UI服务包更新了版本，开发人员基于该UI服务包中的UI服务所集成的场景类UI应用也无需重新开发，从而节省了资源。

在另一种可能的设计方式中，在上述“加载待加载UI服务和待加载UI服务的依赖”之前，上述的方法还包括：基于待加载UI服务的复用路径和待加载UI服务的依赖的复用路径，并行的下载待加载UI服务和待加载UI服务的依赖。上述“加载待加载UI服务和待加载UI服务的依赖”包括：加载已下载的待加载UI服务和待加载UI服务的依赖。

这样，由于加载装置可以通过依赖图，一次性的确定出待加载UI服务的所有依赖。因此加载装置可以并行的下载待加载UI服务及其依赖，相比现有技术中需要串行的下载任务的依赖，本申请提供的方法提高了下载待加载UI服务及其依赖的效率。

在另一种可能的设计方式中，上述“加载已下载的待加载UI服务和待加载UI服务的依赖”包括：按照上述依赖图指示的依赖关系，按序加载已下载的待加载UI服务和待加载UI服务的依赖。

在另一种可能的设计方式中，上述方法还包括：如果上述待加载UI服务的依赖是运行时依赖项，则在加载上述至少一个UI服务和上述待加载UI服务的依赖的过程中，首次加载该运行时依赖项时，启动该运行时依赖项的驱动。

通过该可能的设计，相比现有技术中，需要手动的启动至少一个运行时依赖项的驱动，本申请提供的方法减少了开发UI应用时的工作量。

在另一种可能的设计方式中，上述方法还包括：更新上述依赖图。

通过该可能的设计，加载装置即可在最新的依赖图中，确定出待加载UI服务的依赖。这样，即使包括待加载UI服务的UI服务包更新过，该待加载UI服务可能通过复用了不同于更新之前所复用UI服务的UI服务，以实现性能或界面的优化。通过本申请的方法，加载装置能够通过更新的依赖图，确定出待加载UI服务当前最新的依赖。这样，包括待加载UI服务的场景类UI应用无需更新版本，也能向用户展现最新的性能。

在另一种可能的设计方式中，若上述加载装置包括第一加载装置与第二加载装置，则第一加载装置与第二加载装置彼此隔离。其中，该第一加载装置和该第二加载装置均用于为一个软件系统加载UI服务。

第二方面，本申请提供了一种生成UI服务包的方法，该方法应用于生成UI服务包的装置中。该方法包括：获取UI服务的代码。该UI服务的代码中包括复用路径，该复用路径用于指示服务的依赖的访问路径。转化该UI服务的代码，得到第一UI服务包。其中，该第一UI服务包包括至少一个UI服务。

通过本申请提供的方法，生成装置生成的不同UI服务包中的UI服务，可以通过复用路径高效的互相复用，从而能够根据不同的UI服务包中的UI服务包，高效的集成得到场景类UI应用。进一步的，在加载该场景类UI应用中的UI服务时，可以通过该UI服务的复用路径进行加载，能够提高该UI服务的加载效率，即提高了该场景类UI应用的运行效率。

在一种可能的设计方式中，上述第一UI服务包中第一UI服务的代码中的复用路径，满足如下条件中的至少一种：该第一UI服务的代码中的复用路径用于指示第二UI服务的访问路径，该第二UI服务是第一UI服务的依赖，该第二UI服务是第二UI服务包中的任一个UI服务，该第二UI服务包是不同于第一UI服务包的UI服务包；或者，该第一UI服务的代码中的复用路径用于指示运行时依赖项的访问路径，该运行时依赖项是第一UI服务的依赖，运行时依赖项是至少一个公共依赖UI服务包中的任一个运行时依赖项，该至少一个公共依赖UI服务包包括至少一个运行时依赖项，该至少一个公共依赖UI服务包用于为在至少一个UI服务包注册装置中注册的至少一个UI服务包中的UI服务提供依赖。其中，该第一UI服务是该第一UI服务包中的任一个UI服务。

在另一种可能的设计方式中，上述第一UI服务的代码中的复用路径包括模糊版本号。该模糊版本号用于指示满足预设版本条件的第二UI服务包或至少一个公共依赖UI服务包。

根据该可能的设计，本申请提供的方法中，生成装置生成的UI服务包中UI服务的代码里的复用路径，包括模糊版本号。这样当该UI服务被加载时，可以根据其复用路径中的模糊版本号，匹配到最新版本的包括该UI服务的UI服务包。这样，即使该UI服务包更新了版本，开发人员基于该UI服务包中的UI服务所集成的场景类UI应用也无需重新开发，从而节省了资源。

在另一种可能的设计方式中，上述获取的UI服务的代码是基于开发框架编写的。上述“转化该UI服务的代码，得到第一UI服务包”包括：通过上述的开发框架转化该UI服务的代码，得到第一UI服务包。

在另一种可能的设计方式中，上述的第二UI服务包或公共依赖UI服务包是基于上述开发框架得到的。

通过该两种可能的设计，开发人员可以基于统一的开发框架编写UI服务的代码，然后生成UI服务包的装置通过该开发框架转化该UI服务的代码，从而得到对应的UI服务包。这样的话，统一的开发UI服务的标准，降低了后续开发人员集成UI服务的门槛。

在另一种可能的设计方式中，上述“通过上述的开发框架转化该UI服务的代码，得到第一UI服务包”包括：基于预设的配置文件，通过上述的开发框架转化该UI服务的代码，得到第一UI服务包。其中，该配置文件用于指示第一UI服务包的类型，第一UI服务包的类型用于表示第一UI服务包的用途。

在另一种可能的设计方式中，上述第一UI服务包的类型包括以下至少一种：业务UI服务包、实现加载装置功能的UI服务包或公共依赖UI服务包。

通过该两种可能的设计，生成UI服务包的装置可以生成不同用途的UI服务包。这样，生成UI服务包的装置生成的UI服务包，可以构建出基于UI服务包开发场景类UI应用的完整生态。

在另一种可能的设计方式中，上述方法还包括：发布上述的第一UI服务包的注册信息。该注册信息包括第一UI服务包的名称和用于部署第一UI服务包的网络地址。该注册信息用于在至少一个UI服务包注册装置中注册第一UI服务包。

通过该可能的设计，通过本申请方法得到的UI服务包，可以被不同服务商的注册装置获取到。这样，该不同的服务商即可基于该UI服务包，开发属于自己的场景类UI应用。这样，即减少了该服务商开发场景类UI应用的工作量。这是因为，该服务商无需再开发该UI服务包，仅需复用该UI服务包中的UI服务即可开发出其专属的场景类UI应用。

在另一种可能的设计方式中，上述的第一UI服务包包括第一依赖关系集。其中，该第一依赖关系集包括第一UI服务包中至少一个UI服务的依赖关系。其中，该依赖关系用于指示该第一UI服务包中至少一个UI服务的依赖。

在另一种可能的设计方式中，上述方法还包括：向上述至少一个UI服务包注册装置发送第一依赖关系集，该至少一个UI服务包注册装置用于注册第一UI服务包。

通过上述两种可能的设计，UI服务包注册装置可以获取到生成UI服务包的装置生成的UI服务包的依赖关系集。这样，加载装置即可根据该依赖关系集得到加载UI服务时需要用到的依赖图，该依赖图中包括在UI服务包注册装置中注册的UI服务包中UI服务的依赖关系。

这样的话，加载装置在加载待加载UI服务时，可以在依赖图中同时确定出待加载UI服务的所有依赖的复用路径。这样，加载装置就可以根据待加载UI服务及其依赖的复用路径，并行的下载待加载UI服务及其依赖，然后按序加载待加载UI服务及其依赖，从而提高了下载以及加载UI服务及其依赖的效率，即提高了加载复用了UI服务或运行时依赖项的待加载UI服务的效率，从而提高了包括该待加载UI服务的场景类UI应用运行效率。

在另一种可能的设计方式中，上述方法还包括：更新上述的第一UI服务包。其中，更新后的第一UI服务包包括第二依赖关系集。该第二依赖关系集包括更新后的第一UI服务包中至少一个UI服务的依赖关系。

在另一种可能的设计方式中，上述方法还包括：向上述至少一个UI服务包注册装置发送第二依赖关系集。

通过上述两种可能的设计，UI服务包注册装置可以获取到的生成UI服务包的装置所生成的UI服务包的最新的依赖关系集。这样，加载装置即可根据最新的依赖关系集，得到加载UI服务时需要用到的最新的依赖图。

这样的话，加载装置在加载待加载UI服务时，可以在最新的依赖图中同时确定出待加载UI服务的所有依赖的复用路径。这样，加载装置就可以根据待加载UI服务及其依赖的复用路径，并行的下载待加载UI服务及其依赖，然后按序加载待加载UI服务及其依赖，从而提高了下载以及加载UI服务及其依赖的效率，即提高了复用了UI服务或运行时依赖项的待加载UI服务的运行效率。

在另一种可能的设计方式中，上述的第一UI服务中全部或部分的UI服务允许被引用为依赖。

第三方面，本申请提供一种注册UI服务包的方法，应用于UI服务包注册装置。该方法包括：获取第一UI服务包的注册信息。该注册信息包括第一UI服务包的名称和用于部署第一UI服务包的网络地址。将该注册信息添加至UI服务包注册装置的注册列表中。其中，该第一UI服务包中的第一UI服务的代码包括复用路径，该复用路径用于指示第一UI服务的依赖的访问路径。其中，该第一UI服务是第一UI服务包中的任一个UI服务。

通过该方法，在UI服务包注册装置中注册的UI服务包中，不同UI服务包中的UI服务可以通过复用路径，高效的互相复用，从而能够高效的集成场景类UI应用。这样，UI服务加载的装置即可获取到UI服务包注册装置中所注册的UI服务包的注册信息以及依赖关系集，并生成用于确定待加载UI服务的依赖的依赖图。这样，UI服务加载装置即可同时下载以及加载通过依赖图确定出的所有依赖，并加载待加载UI服务及其所有依赖，从而提高了待加载UI服务的加载效率，即提高了包括待加载UI服务的场景类UI应用的运行效率。

在一种可能的设计方式中，上述复用路径满足如下条件中的至少一种：该复用路径用于指示第二UI服务的访问路径，该第二UI服务是第一UI服务的依赖，该第二UI服务是第二UI服务包中的任一个UI服务，该第二UI服务包是不同于第一UI服务包的UI服务包；或者，该复用路径用于指示运行时依赖项的访问路径，该运行时依赖项是第一UI服务的依赖，该运行时依赖项是至少一个公共依赖UI服务包中的任一个运行时依赖项，该至少一个公共依赖UI服务包包括至少一个运行时依赖项，该至少一个公共依赖UI服务包用于为在至少一个UI服务包注册装置中注册的至少一个UI服务包中的UI服务提供依赖。

在另一种可能的设计方式中，上述方法还包括：获取第一UI服务包的依赖关系集。该依赖关系集包括第一UI服务包中至少一个UI服务的依赖关系。其中，该第一UI服务的依赖关系用于指示第一UI服务的依赖。

在另一种可能的设计方式中，上述“获取第一UI服务包的依赖关系集”包括：基于上述注册信息中的网络地址，周期性的从第一UI服务包中获取依赖关系集。

在另一种可能的设计方式中，上述“获取第一UI服务包的依赖关系集”包括：接收生成第一UI服务包的装置发送的依赖关系集。

通过上述几种可能的设计，注册UI服务包的注册装置能够获取到在其注册列表中注册的UI服务包的依赖关系集。这样，加载装置通过与注册UI服务包的装置的交互，即可从UI服务包注册装置中获取到在注册UI服务包的装置中注册的UI服务包中各UI服务的依赖关系，进而加载装置在加载待加载UI服务时，可以在基于获取到的依赖关系，同时确定出待加载UI服务的所有依赖的复用路径。这样，加载装置就可以根据待加载UI服务及其依赖的复用路径，并行的下载待加载UI服务及其依赖，然后按序加载待加载UI服务及其依赖，从而提高了下载以及加载UI服务及其依赖的效率，即提高了复用了UI服务或运行时依赖项的待加载UI服务的加载效率，从而提高了包括待加载UI服务的场景类UI应用的运行效率。

在另一种可能的设计方式中，上述复用路径包括第一UI服务包的模糊版本号。

根据该可能的设计，当加载装置可以在加载第一UI服务包中的UI服务时，可以根据该UI服务的代码中的复用路径里的模糊版本号，匹配到最新版本的第一UI服务包。这样，即使第一UI服务包更新了版本，开发人员基于第一UI服务包中的UI服务所集成的场景类UI应用也无需重新开发，从而节省了资源。

在另一种可能的设计方式中，上述方法还包括：基于上述的注册信息和第一UI服务包的版本号，生成第一UI服务包中至少一个UI服务的初始复用路径。该初始复用路径包括第一UI服务包的版本号。

在另一种可能的设计方式中，上述初始复用路径用于确定第一UI服务包中至少一个UI服务的复用路径。其中，该初始复用路径和该复用路径，均用于指示第一UI服务包中至少一个UI服务的访问路径。

通过上述两种可能的设计，开发人员可以根据该初始复用路径确定出至少一个UI服务的复用路径，从而在开发新的场景类UI应用时可以高效的复用该至少一个UI服务，并且基于复用路径加载UI服务时，加载效率高。

第四方面，本申请提供一种加载UI服务的装置。

在一种可能的设计方式中，该加载UI服务的装置可以用于执行上述第一方面提供的任一种方法。本申请可以根据上述第一方面提供的任一种方法，对该加载UI服务的装置进行功能模块的划分。例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。

示例性的，本申请可以按照功能将该加载UI服务的装置划分为接收单元、确定单元以及加载单元等。上述划分的各个功能模块执行的可能的技术方案和有益效果的描述均可以参考上述第一方面或其相应的可能的设计提供的技术方案，此处不再赘述。

在另一种可能的设计中，该加载UI服务的装置包括：存储器和一个或多个处理器，所述存储器用于存储计算机指令，所述处理器用于调用所述计算机指令，以执行如第一方面及其任一种可能的设计方式提供的任一种方法。

第五方面，本申请提供一种生成UI服务包的装置。

在一种可能的设计方式中，该生成UI服务包的装置可以用于执行上述第二方面提供的任一种方法。本申请可以根据上述第二方面提供的任一种方法，对该生成UI服务包的装置进行功能模块的划分。例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。

示例性的，本申请可以按照功能将该生成UI服务包的装置划分为获取单元和转化单元等。上述划分的各个功能模块执行的可能的技术方案和有益效果的描述均可以参考上述第二方面或其相应的可能的设计提供的技术方案，此处不再赘述。

在另一种可能的设计中，该生成UI服务包的装置包括：存储器和一个或多个处理器，所述存储器用于存储计算机指令，所述处理器用于调用所述计算机指令，以执行如第二方面及其任一种可能的设计方式提供的任一种方法。

第六方面，本申请提供一种注册UI服务包的装置。

在一种可能的设计方式中，该注册UI服务包的装置可以用于执行上述第三方面提供的任一种方法。本申请可以根据上述第三方面提供的任一种方法，对该注册UI服务包的装置进行功能模块的划分。例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。示例性的，本申请可以按照功能将该注册UI服务包的装置划分为获取单元和添加单元等。上述划分的各个功能模块执行的可能的技术方案和有益效果的描述均可以参考上述第三方面或其相应的可能的设计提供的技术方案，此处不再赘述。

在另一种可能的设计中，该注册UI服务包的装置包括：存储器和一个或多个处理器，所述存储器用于存储计算机指令，所述处理器用于调用所述计算机指令，以执行如第三方面及其任一种可能的设计方式提供的任一种方法。

第七方面，本申请提供一种计算机可读存储介质，如计算机非瞬态的可读存储介质。其上储存有计算机程序(或指令)，当该计算机程序(或指令)在计算机上运行时，使得该计算机执行上述第一方面、第二方面或第三方面中任一种可能的实现方式提供的任一种方法。

第八方面，本申请提供一种计算机程序产品，当其在计算机上运行时，使得第一方面、第二方面或第三方面中的任一种可能的实现方式提供的任一种方法被执行。

第九方面，本申请提供一种芯片系统，该芯片系统包括一个或多个接口电路和一个或多个处理器；接口电路和处理器通过线路互联，接口电路用于从存储器接收信号，并向处理器发送信号，信号包括存储器中存储的计算机指令。处理器调用计算机指令，以执行如上述第一方面、第二方面或第三方面中任一种可能的实现方式提供的任一种方法。

第十方面，本申请提供一种软件系统，该软件系统包括如上述第四方面中任一种可能的实现方式提供的任一种加载UI服务的装置，以加载待加载UI服务。或者，该软件系统包括如上述第五方面中任一种可能的实现方式提供的任一种生成UI服务包的装置，以生成UI服务包。或者，该软件系统包括如上述第六方面中任一种可能的实现方式提供的任一种注册UI服务包的装置，以将UI服务包注册到软件系统的注册列表中。

第十一方面，本申请提供一种计算机设备，包括处理器和存储器；所述存储器上存储有计算机指令，所述处理器用于运行所述存储器上的计算机指令，以执行如上述第一方面、第二方面或第三方面中任一种可能的实现方式提供的任一种方法。

可以理解的是，上述提供的任一种装置、计算机存储介质、计算机程序产品或芯片系统等均可以应用于上文所提供的对应的方法，因此，其所能达到的有益效果可参考对应的方法中的有益效果，此处不再赘述。

在本申请中，上述生成UI服务包的装置、注册UI服务包的装置以及加载UI服务的装置等名字对设备或功能模块本身不构成限定，在实际实现中，这些设备或功能模块可以以其他名称出现。只要各个设备或功能模块的功能和本申请类似，属于本申请权利要求及其等同技术的范围之内。

本申请的这些方面或其他方面在以下的描述中会更加简明易懂。

附图说明

图1为本申请实施例提供的一种基于UI服务包开发场景类UI应用的示意图；

图2为本申请实施例提供的一种网络架构的示意图一；

图3为本申请实施例提供的一种网络架构的示意图二；

图4为本申请实施例提供的一种计算机设备的硬件结构示意图；

图5为本申请实施例提供的一种网络架构的示意图三；

图6为本申请实施例提供的一种手机的硬件结构示意图；

图7为本申请实施例提供的一种不同类型的UI服务包的示意图；

图8为本申请实施例提供的一种生成UI服务包的方法流程示意图；

图9为本申请实施例提供的一种注册UI服务包的方法流程示意图；

图10为本申请实施例提供的一种加载UI服务的方法流程示意图；

图11为本申请实施例提供的一种依赖图的示意图；

图12为本申请实施例提供的一种生成、注册UI服务包、加载UI服务的方法流程图；

图13a为本申请实施例提供的一种生成、注册UI服务包、加载UI服务的方法示意图一；

图13b为本申请实施例提供的一种生成、注册UI服务包、加载UI服务的方法示意图二；

图14为本申请实施例提供的一种生成UI服务包的装置的结构示意图；

图15为本申请实施例提供的一种注册UI服务包装置的结构示意图；

图16为本申请实施例提供的一种加载装置的结构示意图；

图17为本申请实施例提供的一种芯片系统的结构示意图；

图18为本申请实施例提供的计算机程序产品的结构示意图。

具体实施方式

为了更清楚的理解本申请实施例，下面对本申请实施例中涉及的部分术语或技术进行说明：

1)、开发框架

开发框架也可以称为脚手架。开发框架是一种软件开发工具，用于提供软件开发的基础环境，以及用于将开发的代码构建或编译为可以被框架运行的软件包。

开发框架实质上也是一个软件包(或称为开发框架软件包)。开发人员在开发软件时，可以通过包管理工具引入开发框架软件包。

2)、用户界面

UI也可以称为使用者界面，是软件系统和用户之间进行交互和信息交换的媒介。UI可以用于实现信息的内部形式与人类可以接受形式之间的转换。人类可接受的形式包括图像或音频等。因此，用于人机交互的可视化界面、或者音频，均可以称为UI。

因此，UI定义广泛，凡参与人类与机械的信息交流的领域都存在UI。

3)、依赖

在软件系统中，任务A引用任务B。当执行任务A时，需要先执行任务B，才能执行任务A。这种情况下，任务B可以称为任务A的依赖。

4)、运行时依赖

运行时依赖的具体体现形式可以是算法。运行时依赖是用于运行UI时所需要的依赖。例如，运行UI需要的控件，UI上的按钮等等。

5)、领域模型(domain model)

参考人类理解世界不同事物类型的方法，人将信息系统的数据按业务类型抽象为数据模型。若将一组相互之间有一对多的关联关系的数据模型归为一组，则该组可以称为领域。该领域内的数据模型，称为领域模型。

6)、组合逻辑函数

组合逻辑函数用于为UI提供文本数据。例如，组合逻辑函数可以将微服务(microservice)中领域模型的数据流，转化为UI模型的数据流，并将该UI模型的数据流提供给对应的UI显示。

7)场景UI和场景类UI应用

用户根据自身场景产生一组与工具类UI交互操作的集合，若开发人员将该集合构建为一个UI，即为场景UI。这样，包括该场景UI的应用，可以称为场景类UI应用。

其中，用户的自身场景可以称为用户场景。通常，用于识别用户场景的相关因子可以包括用户的身份、时间或用户所处的地理位置中的至少一种，当然，不限于此。

8)图

在计算机数据结构理论中，包括两大类数据结构，一种是集合，一种是图。例如，图可以是有向无环图(Directed Acyclic Graph，DAG)。其中，如果一个有向图无法从某个顶点出发经过若干条边回到该点，则这个图称为DAG图。

在本申请实施例中，通过依赖图表示UI服务之间的依赖关系。这里，依赖图即为图类的数据结构。其中，依赖图中的顶点用于表示UI服务和运行时依赖项，依赖图中的顶点之间的有向边用于表示UI服务之间(或者UI服务和运行时依赖项之间)的依赖关系。

9)渲染

终端设备将网页源代码处理后，得到可视化的网页，这一过程可以称为渲染。

10)前台、中台以及后台

前台，是由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，作为示例，企业的最终用户直接使用或交互的系统，即为企业与最终用户的交点。例如，用户直接使用的网站，手机应用程序(application，APP)等都属于前台范畴。

后台，是由后台系统组成的后端平台。作为示例，每个后台系统可以用于管理企业的一类核心资源(数据+计算)，例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。

中台，介于前台和后台之间，是被共用的中间件的集合。通常，中台从后台提取数据，并为不同前台系统提供公共数据。

11)、其他术语

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请的实施例中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，除非另有说明，“多个”的含义是两个或两个以上。

本申请中术语“至少一个”的含义是指一个或多个，本申请中术语“多个”的含义是指两个或两个以上，例如，多个第二报文是指两个或两个以上的第二报文。本文中术语“系统”和“网络”经常可互换使用。

应理解，在本文中对各种所述示例的描述中所使用的术语只是为了描述特定示例，而并非旨在进行限制。如在对各种所述示例的描述和所附权利要求书中所使用的那样，单数形式“一个(“a”，“an”)”和“该”旨在也包括复数形式，除非上下文另外明确地指示。

还应理解，本文中所使用的术语“和/或”是指并且涵盖相关联的所列出的项目中的一个或多个项目的任何和全部可能的组合。术语“和/或”，是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本申请中的字符“/”，一般表示前后关联对象是一种“或”的关系。

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

应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。

还应理解，术语“包括”(也称“includes”、“including”、“comprises”和/或“comprising”)当在本说明书中使用时指定存在所陈述的特征、整数、步骤、操作、元素、和/或部件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元素、部件、和/或其分组。

还应理解，术语“如果”可被解释为意指“当...时”(“when”或“upon”)或“响应于确定”或“响应于检测到”。类似地，根据上下文，短语“如果确定...”或“如果检测到[所陈述的条件或事件]”可被解释为意指“在确定...时”或“响应于确定...”或“在检测到[所陈述的条件或事件]时”或“响应于检测到[所陈述的条件或事件]”。

应理解，说明书通篇中提到的“一个实施例”、“一实施例”、“一种可能的实现方式”意味着与实施例或实现方式有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”、“一种可能的实现方式”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。

本申请实施例提供一种生成、注册UI服务包、以及加载UI服务的方法，该方法通过预先生成至少一个UI服务包，该至少一个UI服务包中的每个UI服务包，包括至少一个UI服务。其中，该至少一个UI服务包中的UI服务可以复用其他UI服务包中的UI服务。

进一步的，该至少一个UI服务包在至少一个UI服务包注册装置上注册。这样，加载装置可以从该至少一个UI服务包注册装置上获取上述至少一个UI服务包的依赖关系。然后，加载装置可以根据该依赖关系从上述至少一个UI服务包中加载待加载UI服务。当该待加载UI服务的代码被软件系统渲染后，可以得到至少一个UI。

这样，当通过上述UI服务包中的UI服务来构建UI应用时，可以减少开发人员构建UI应用时的冗余代码，从而减少资源浪费。并且，本申请实施例提供的加载UI服务的方法，能够提高UI服务的加载效率，从而提高了根据所加载UI服务构建的UI应用中UI的显示效率，进而提升了用户体验。其中，UI应用可以是场景类UI应用，该场景类UI应用可以包括至少一个场景UI，该至少一个场景UI是基于至少一个UI服务得到的。

上述的UI服务的具体体现可以是算法。该算法可以包括UI算法，当UI算法被运行后可以得到UI。可选的，该算法还可以包括组合逻辑函数，组合逻辑函数用于为UI算法所得到的UI提供文本数据。

示例性的，参考图1，图1示出了本申请实施例提供的一种基于UI服务包开发场景类UI应用的示意图。

如图1所示，在企业不同领域的中台，可以预先生成UI服务包A、UI服务包B以及UI服务包C。例如，UI服务包A可以是在领域中台1生成的，UI服务包B可以是在领域中台2生成的，UI服务包C可以是在领域中台3生成的，对此不作限定。其中，箭头11表示UI服务包A中的至少一个UI服务复用了UI服务包B中的至少一个UI服务，箭头12表示UI服务包B中的至少一个UI服务复用了UI服务包C中的至少一个UI服务。

如图1所示，当前台通过加载装置加载UI服务包A中至少一个UI服务和UI服务包B中的至少一个UI服务时，可以实现场景类UI应用1的功能。当前台通过加载装置加载UI服务包A中至少一个UI服务、UI服务包B中的至少一个UI服务、以及UI服务包C中的至少一个UI服务时，可以实现场景类UI应用2的功能。当前台通过加载装置加载UI服务包B中至少一个UI服务和UI服务包C中的至少一个UI服务时，可以实现场景类UI应用3的功能。这里，场景类UI应用1、场景类UI应用2以及场景类UI应用3可以分别是适用于不同用户场景的场景类UI应用。

其中，当用户所使用的终端设备具有人工智能(Artificial Intelligence，AI)功能，则该终端设备的AI可以识别到用户当前的用户场景。

作为示例，AI可以通过识别用户场景相关的因子(例如用户的身份、时间或用户所处的地理位置中的至少一种)，从而识别出用户当前的用户场景。例如，AI可以获取该终端设备中用户的身份信息以确定用户的身份，例如用户可以是学生。或者，AI可以根据当前的时间，确定当前的用户场景，例如，当前的时间是工作时间或休息时间等。或者，AI还可以根据终端设备的全球定位系统(global positioning system，GPS)信息，确定当前的用户场景，例如，用户当前所处的地理位置是工作场所(写字楼等)或生活场所(小区等)。

这样，终端设备通过AI技术分析与用户场景相关的因子识别出当前的用户场景，进而可以向用户推荐与用户场景相关的场景UI，从而提高了用户体验。

当然，上述描述仅示例性的列举了几种用户场景，以及示例性的描述了终端设备通过AI识别用户场景的几种方式，实际不限于此。

本申请实施例提供一种生成UI服务包的装置(为简单方便的描述，在下文中将“生成UI服务包的装置”简称为“生成装置”)，该生成装置可以用于执行本申请实施例中提供的生成UI服务包的方法。本申请实施例还提供一种UI服务包注册装置(为简单方便的描述，在下文中将“UI服务包注册装置”简称为“注册装置”)，该注册装置可以用于执行本申请实施例中提供的注册UI服务包的方法。

应理解，上述生成装置和上述注册装置可以集成在同一个服务节点上，也可以分别设置在不同的服务节点上。其中，该服务节点可以是通过物理机或虚拟机实现的服务节点。作为示例，该服务节点可以是服务器或通用PC等。本申请实施例对服务节点的具体形态此不作限定。

可选的，上述服务节点可以是同一个企业中台上的服务节点，也可以是不同企业中台上的服务节点，对此不作限定。

应理解，当上述生成装置和上述注册装置集成在同一个服务节点上，该生成装置和该注册装置可以通过硬件或软件相互隔离。

当上述生成装置和上述注册装置分别设置在不同的服务节点上，则该生成装置和该注册装置可以通过有线或无线的方式进行通信。可选的，该生成装置和该注册装置还可以通过第三方的平台进行通信。其中，该生成装置和该注册装置可以分别通过有线或无线的方式，和第三方平台通过进行通信。

参考图2，图2示出了本申请实施例提供的一种网络架构20的示意图，网络架构20包括生成装置21和注册装置22。其中，生成装置21和注册装置22之间可以通过有线或无线的方式进行通信。

参考图3，图3示出了本申请实施例提供的另一种网络架构30的示意图，网络架构30包括生成装置21、注册装置22以及第三方平台33。其中，生成装置21和第三方平台33之间通过可以通过有线或无线的方式进行通信。注册装置22和第三方平台33之间可以通过有线或无线的方式进行通信。

参考图4，图4示出了本申请实施例提供的一种计算机设备40的硬件结构。计算机设备40可以是上述的生成装置，也可以是上述的注册装置。如图4所示，计算机设备40可以包括处理器41、存储器42、通信接口43以及总线44。处理器41、存储器42以及通信接口43之间可以通过总线44连接。

处理器41是计算机设备40的控制中心，可以是一个通用中央处理单元(centralprocessing unit，CPU)，也可以是其他通用处理器等。其中，通用处理器可以是微处理器或者是任何常规的处理器等。

作为示例，处理器41可以包括一个或多个CPU，例如图4中所示的CPU 0和CPU 1。

存储器42可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

一种可能的实现方式中，存储器42可以独立于处理器41存在。存储器42可以通过总线44与处理器41相连接，用于存储数据、指令或者程序代码。处理器41调用并执行存储器42中存储的指令或程序代码时，能够实现本申请实施例提供的生成UI服务包方法，或者能够实现本申请实施例提供的注册UI服务包的方法。

另一种可能的实现方式中，存储器42也可以和处理器41集成在一起。

通信接口43，用于计算机设备40与其他设备(如加载UI的装置等)通过通信网络连接，所述通信网络可以是以太网，无线接入网(radio access network，RAN)，无线局域网(wireless local area networks，WLAN)等。通信接口43可以包括用于接收数据的接收单元，以及用于发送数据的发送单元。

总线44，可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component Interconnect，PCI)总线、扩展工业标准体系结构(Extended Industry Standard Architecture，EISA)总线或者高速串行计算机扩展(peripheral component interconnect express，PCIe)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

需要指出的是，图4中示出的结构并不构成对该计算机设备40的限定，除图4所示部件之外，该计算机设备40可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

本申请实施例还提供一种加载装置。该加载装置可以用于执行本申请实施例提供的加载UI服务的方法。作为示例，该加载装置可以是加载器(loader)。该加载装置可以应用于终端设备。具体的，该终端设备可以是手机、平板电脑、可穿戴电子设备等便携式设备，也可以是车载设备、智能机器人以及智能音响等设备，该终端设备还可以是个人计算机(personal computer，PC)、个人数字助理(personal digital assistant，PDA)、上网本、服务器等计算设备。对此不作限定。

上述加载装置可以和上述的注册装置通过有线或无线的方式进行通信。

参考图5，图5示出了本申请实施例提供的又一种网络架构50，网络架构50包括加载装置51和注册装置22。其中，加载装置51和注册装置22可以通过有线或无线的方式进行通信。

请参考图6，以上述终端设备是手机为例，图6示出了手机60的一种硬件结构。如图6所示，手机60可以包括处理器610，外部存储器接口620，内部存储器621，天线630以及显示屏640等。

可以理解的是，本申请实施例示意的结构并不构成对手机60的具体限定。在本申请实施例的另一些实施例中，手机60可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器610可以包括一个或多个处理单元，例如：处理器610可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，控制器可以是手机60的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器610中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器610中的存储器为高速缓冲存储器。该存储器可以保存处理器610刚用过或循环使用的指令或数据。如果处理器610需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器610的等待时间，因而提高了系统的效率。

在一些实施例中，处理器610可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

I2C接口是一种双向同步串行总线，包括一根串行数据线(serial data line，SDA)和一根串行时钟线(derail clock line，SCL)。

I2S接口可以用于音频通信。PCM接口也可以用于音频通信，将模拟信号抽样，量化和编码。

UART接口是一种通用串行数据总线，用于异步通信。该总线可以为双向通信总线。它将要传输的数据在串行通信与并行通信之间转换。

MIPI接口可以被用于连接处理器610与显示屏640，摄像头等外围器件。

MIPI接口包括摄像头串行接口(camera serial interface，CSI)，显示屏串行接口(display serial interface，DSI)等。

GPIO接口可以通过软件配置。GPIO接口可以被配置为控制信号，也可被配置为数据信号。

USB接口是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口可以用于连接充电器为手机60充电，也可以用于手机60与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如增强现实(augmented reality，AR)设备等。

可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对手机60的结构限定。在本申请另一些实施例中，手机60也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

外部存储器接口620可以用于连接外部存储卡，例如Micro SD卡，实现扩展手机60的存储能力。外部存储卡通过外部存储器接口620与处理器610通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器621可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器610通过运行存储在内部存储器621的指令，从而执行手机60的各种功能应用以及数据处理。

手机60的无线通信功能可以通过天线630、调制解调处理器以及基带处理器等实现。其中，调制解调处理器可以包括调制器和解调器。

天线630用于发射和接收电磁波信号。手机60中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线630复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

作为示例，天线630可以用于在加载装置下载待加载UI服务时，接收部署于预设的网络地址上的UI服务包中的待加载UI服务的数据。

手机60通过GPU，显示屏640，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏640和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器610可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。显示屏640用于显示图像，视频等。示例性的，本申请实施例提供的加载UI服务的方法所加载的UI服务被渲染后，可以显示在显示屏640上。显示屏640包括显示面板。

NPU为神经网络(neural-network，NN)计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现手机60的智能认知等应用，例如：图像识别，人脸识别，语音识别，文本理解等。

需要指出的是，图6中示出的结构并不构成对该终端设备60的限定，除图6所示部件之外，该终端设备60可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面对本申请实施例提供的UI服务包的类型予以说明。

在本申请实施例中，根据UI服务包的用途，可以将UI服务包分为以下几种类型的UI服务包：

类型一、业务UI服务包

业务UI服务包中的UI服务被加载渲染后，可以得到至少一个UI。业务UI服务包可以包括领域UI服务包和场景UI服务包。

一个领域UI服务包可以包括至少一个UI服务。在一个领域UI服务包中，该领域UI服务包中的UI服务，可以是相同领域的UI服务。不同的领域UI服务包可以包括不同领域的UI服务。作为示例，不同领域的UI服务可以是法务相关的UI服务、合同相关的UI服务、产品的UI服务等。

示例性的，服务商可以将企业资源计划(enterprise resource planning，ERP)系统中的数据按领域划分为不同领域的UI服务。这样，生成装置可以根据同一领域的UI服务生成该领域对应的领域UI服务包。例如，生成装置可以根据ERP系统中产品领域的UI服务生成产品类领域UI服务包，或者，生成装置可以根据报价领域的UI服务生成报价类领域UI服务包。

其中，不同的领域UI服务包中的UI服务可以互相复用。例如，产品类领域UI服务包中的UI服务，可以复用报价类领域UI服务包中的UI服务。报价类领域UI服务包中的UI服务，也可以复用产品类领域UI服务包中的UI服务，对此不作限定。

场景UI服务包可以包括至少一个场景UI服务，一个场景UI服务可以是基于领域UI服务包中的至少两个UI服务得到的。这里，该至少两个UI服务可以来自同一个领域UI服务包，也可以来自不同的领域UI服务包，对此不作限定。

当上述至少两个UI服务来自不同的领域服务包时，例如该至少两个UI服务可以分别来自领域服务包1和领域服务包2。其中，领域服务包1和领域服务包2可以是，同一个服务商中台上的生成装置所生成的领域服务包，也可以是不同服务商中台上的生成装置所生成的领域服务包。例如，领域服务包1可以是服务商1的中台上的生成装置所生成的领域服务包，领域服务包2可以是服务商2的中台上的生成装置所生成的领域服务包，对此不作限定。

可以理解的是，上述的场景UI服务包，以及被场景UI服务包中的UI服务复用的UI服务所属的领域UI服务包，可以是同一个服务商中台上的生成装置所生成的UI服务包，也可以是不同服务商中台上的生成装置所生成的UI服务包，对此不作限定。

可以理解，不同的场景UI服务包，可以提供不同应用场景的UI服务。

示例性的，基于产品类领域UI服务包中的UI服务和报价类领域UI服务包中的UI服务，可以得到针对通信运营商报价的场景UI服务，或者，可以得到针对企业报价的场景UI服务，或者，可以得到用于提供设备报价的场景UI服务，或者，还可以得到用于提供服务报价的场景UI服务等。相应的，在企业的中台，生成装置可以生成面向通信运营商的报价类场景UI服务包，面向企业的报价类场景UI服务包，针对设备报价的报价类场景UI服务包，或者，针对服务报价的报价类场景UI服务包，等等。这样，企业即可向用户提供不同应用场景的UI服务。

可以理解，场景UI服务包中的UI服务复用了领域UI服务包中的UI服务，而不同的场景UI服务包中的UI服务之间，也可以互相复用。例如，面向通信运营商的报价类场景UI服务包中的场景UI服务，可以复用针对设备报价的报价类场景UI服务包中的场景UI服务。

需说明的是，领域UI服务包中的UI服务和场景UI服务包中的UI服务，均可以复用公共依赖UI服务包中的运行时依赖项。公共依赖UI服务包的具体说明，可以参考下文S102中的描述，这里不予赘述。

参考图7，图7示例性的示出了业务UI服务包中的领域UI服务包和场景UI服务包的关系示意图。如图7所示，图7中的UI 311和UI 312分别是领域UI服务包中的UI服务对应的2个UI，UI 32可以是场景UI服务包中的UI服务对应的UI。

需要说明的是，上述的业务UI服务包，可以是基于不同的软件系统生成的业务UI服务包。其中，软件系统可以是基于某种相同用户授权、相同运行时或相同用户体验，所构建的软件APP、计算机操作系统或云平台。示例性的，软件系统可以是浏览器或微信等APP。或者，软件系统可以是移动设备使用的安卓(android)操作系统或IOS操作系统，或者是计算机使用的微软(windows)操作系统或IOS操作系统等。或者，软件系统可以是华为云等云平台。可以理解的是，上述软件系统还可以是上述APP或计算机操作系统所引入的插件，例如操作系统A所引入的补丁插件。

作为示例，本申请实施例提供的生成装置，可以基于华为的鸿蒙操作系统，生成适用于华为鸿蒙操作系统的业务UI服务包。

可以理解，本申请请实施例中的至少一个业务UI服务包，即可构成一个实现某种功能的工具类UI应用，或者构成一个适用于某种用户场景的场景类UI应用。该至少一个业务UI服务包中的任一个UI服务被渲染后，即得到该工具类UI应用或该场景类UI应用中的一个UI。这里，该工具类UI应用可以是工具类的app，例如是淘宝或微博等APP，对此不作限定。该场景类UI应用可以是场景类的APP。

应理解，在不同的软件系统中，UI显示的格式是不同的。因此，在不同的软件系统中，构成相同功能的UI应用的业务UI服务包，是基于不同软件系统生成的业务UI服务包。例如，基于操作系统A生成的业务UI服务包1，可以用于得到适用于操作系统A的UI应用1，基于操作系统B生成的业务UI服务包2，可以用于得到适用于操作系统B的UI应用2。其中，UI应用1和UI应用2实现的功能目的是相同的。

类型二、实现加载装置功能的UI服务包

这里，加载装置可以用于加载至少一个业务UI服务包中的至少一个UI服务，以及该至少一个UI服务的依赖。

在本申请实施例中，生成装置可以生成实现加载装置功能的UI服务包，并将其部署于网络中。这样，软件系统可以预先下载该UI服务包，并将该UI服务包预置在软件系统中。或者，软件系统在启动时，下载该UI服务包。然后，软件系统可以通过该UI服务包中的UI服务，实现加载装置的功能，并通过该加载装置加载待加载UI服务，以及待加载UI服务的依赖。

另外，在实现加载装置功能的UI服务包中，除包括实现加载装置功能的UI服务，还包括与加载装置相关的UI服务。

类型三、公共依赖UI服务包

公共依赖UI服务包可以包括至少一个运行时依赖项。该至少一个运行时依赖项可以用于被上述类型一、类型二以及类型三中的UI服务包中的UI服务引用为依赖。也就是说，该其他类型的UI服务包中的UI服务，可以复用公共依赖UI服务包中的至少一个运行时依赖项。这里，该其他类型的UI服务包可以是业务UI服务包或实现加载装置功能的UI服务包，对此不作限定。

需要说明的是，一个公共依赖UI服务包可以对应一个加载装置，而一个加载装置可以对应多个公共依赖UI服务包。公共依赖UI服务包可以为其对应的加载装置所能够加载的所有UI服务提供运行时依赖。

应理解，不同IT服务商可以根据擅长的领域，在自己的中台上通过本申请实施例提供的生成装置，根据本申请实施例提供的UI服务包的方法，生成上述业务UI服务包、实现加载装置功能的UI服务包以及公共依赖UI服务包。具体的，生成装置生成上述业务UI服务包、实现加载装置功能的UI服务包以及公共依赖UI服务包的过程，可以参考下文S101～S108的描述，这里不予赘述。

还需说明的是，软件系统通过上述实现加载装置功能的UI服务包所实现的加载装置，可以加载业务UI服务包中的至少一个UI服务。该至少一个UI服务被软件系统渲染后，可以得到至少一UI。

下面结合附图，对本申请实施例提供的生成、注册UI服务包、以及加载UI服务的方法进行说明。

参考图8，图8示出了本申请实施例提供的生成UI服务包的方法的流程示意图，该方法应用于生成装置，该方法包括以下步骤：

S101、生成装置获取开发框架。

S102、生成装置获取UI服务的代码，该UI服务的代码是基于上述开发框架编写的。

其中，该UI服务的代码中包括复用路径，该复用路径用于指示该UI服务的依赖的访问路径。

S103、生成装置通过所获取的开发框架转化上述获取的UI服务的代码，得到第一UI服务包。其中，第一UI服务包还包括第一依赖关系集。

其中，第一UI服务包包括至少一个UI服务。

其中，该第一依赖关系集包括第一UI服务包中至少一个UI服务的依赖关系，该依赖关系用于指示该至少一个UI服务的依赖。

S104、生成装置将第一UI服务包部署于预设的物理空间中。

S105(可选的)、生成装置发布第一UI服务包的注册信息，该注册信息用于在至少一个注册装置中注册第一UI服务包。

S106(可选的)、生成装置向上述至少一个注册装置发送第一依赖关系集，该至少一个注册装置用于注册第一UI服务包。

S107(可选的)、生成装置更新第一UI服务包，更新后的第一UI服务包包括第二依赖关系集。

S108(可选的)、生成装置向上述至少一个注册装置发送第二依赖关系集。

通过本申请实施例提供的生成UI服务包的方法，不同UI服务包之间可以通过复用代码中的复用路径，高效的复用UI服务。

并且，通过本申请实施例提供的生成UI服务包的方法，生成装置可以基于统一的开发框架得到上述UI服务包，当通过该UI服务包中的UI服务集成UI应用时，能够降低后续开发人员集成UI服务的门槛。

另外，本申请实施例提供的生成UI服务包的方法中，开发框架转化代码得到的UI服务包中，还包括该UI服务包中各个UI服务的依赖关系(例如第一依赖关系集和第二依赖关系集)。这样的话，加载装置可以从注册装置中获取到所有在注册装置注册的UI服务包的依赖关系集。这样，加载装置即可根据获取到的所有的依赖关系集，确定待加载UI服务的所有依赖的复用路径，进而可以根据待加载UI服务及其依赖的复用路径，并行的下载待加载UI服务及其依赖，并按序加载待加载UI服务及其依赖，从而提高了加载UI服务的效率，即提高了复用了UI服务或运行时依赖项的待加载UI服务的运行效率。

下面，对上述步骤S101～S108进行详细说明。

在S101，生成装置所获取的开发框架，用于将UI服务的代码转化为UI服务包。这里，UI服务的代码可以是适用于该开发框架的任一种计算机高级语言编写的代码。

生成装置可以基于软件包配置文件，从代码仓库中获取上述开发框架。

其中，软件包配置文件用于指示所获取的开发框架将UI服务的代码转化后所得到的UI服务包中，不包括该代码引用的运行时依赖。也就是说，本申请实施例中所获取的开发框架为开发态依赖的开发框架，开发态依赖的开发框架仅用于转化UI服务的代码，以得到UI服务包。开发态依赖的开发框架并不参与UI服务包的运行。

另外，本申请实施例所获取的开发框架可以是带版本的开发框架。这样，生成装置在获取开发框架时，可以基于开发框架的版本号，获取版本最新的开发框架。

具体的，生成装置可以基于软件包配置文件，通过代码仓库工具，从代码仓库中获取上述开发框架。

其中，代码仓库工具可以是包管理器(node package manager，npm)工具，或者，代码仓库工具可以是集成开发环境(integrated development environment，IDE)插件等，对此不作限定。

在一种可能的实现方式中，npm工具可以通过人工输入的命令行命令下发指令到生成装置的处理器，以使生成装置的处理器接收到该指令后，从代码仓库中获取开发框架。

示例性的，生成装置通过npm工具获取开发框架的步骤可以是：

步骤一、在npm的配置文件中添加一个配置项：

“devDependencies”:{

“@turboui/turbo-ui-c1i-service”:“^3.0.0”

}

步骤二、运行命令：npm install。

其中，“devDependencies”用于指示所要获取的开发框架是开发态依赖的开发框架。“@turboui/turbo-ui-c1i-service”表示获取开发框架的路径，“3.0.0”表示所要获取的开发框架的版本号。

在另一种可能的实现方式中，IDE插件可以通过UI交互下发指令到生成装置的处理器，以使生成装置的处理器接收到该指令后，从代码仓库中获取开发框架。

在又一种可能的实现方式中，IDE插件可以将通过UI交互下发的指令，用作向npm工具输入的命令行命令。进一步的，npm工具通过该命令行命令下发指令到生成装置的处理器，以使生成装置的处理器接收到该指令后，从代码仓库中获取开发框架。

在S102，具体的，生成装置所获取的UI服务的代码，可以是开发人员基于S101步骤中所获取的开发框架编写的。

本申请实施例中以该UI服务的代码包括m个UI服务的代码为例，其中，m是正整数。这里，该m个UI服务的代码可以对应m个UI服务，该m个UI服务中包括第一UI服务，第一UI服务是该m个UI服务中的任一个UI服务。第一UI服务的代码中包括复用代码，该复用代码中包括复用路径，该复用路径用于指示第一UI服务的依赖。第一UI服务的代码中的复用路径满足如下条件中的至少一种：

条件一、复用路径用于指示第一UI服务的依赖是第二UI服务，第二UI服务是第二UI服务包中的任一个UI服务。

这里，第二UI服务包可以是基于本申请实施例提供的生成UI服务包的方法生成的任一个UI服务包，并且，第二UI服务包是不同于第一UI服务包的UI服务包。可以看出，第一UI服务通过复用代码复用了第二UI服务包中的UI服务。

条件二、复用路径用于指示第一UI服务的依赖是运行时依赖项，该运行时依赖项是公共依赖UI服务包中的任一个运行时依赖项。这里，公共依赖UI服务包可以包括至少一个运行时依赖项，

具体的，公共依赖UI服务包可以是基于本申请实施例提供的生成UI服务包的方法，根据至少一个运行时依赖的代码生成的公共依赖UI服务包。当开发框架将至少一个运行时依赖的代码转化为公共依赖UI服务包后，该公共依赖UI服务包包括至少一个运行时依赖项，一个UI运行时依赖项对应一个运行时依赖的代码。

需要说明的是，公共依赖UI服务包可以用于为在注册装置中注册的至少一个UI服务包中的UI服务提供依赖，这里，注册装置的数量为至少一个。注册装置的相关说明可以参考下文S201～S204，这里不予赘述。

这样的话，本申请实施例提供的生成UI服务包的方法中，第一UI服务包中的UI服务通过复用代码中的复用路径，复用另一UI服务包中的UI服务和公共依赖UI服务包中的运行时依赖项中的至少一个，从而使得开发的第一UI服务包中的冗余代码减少。

上述第一UI服务的代码中的复用路径用于指示第二UI服务或运行时依赖项的访问路径，该复用路径可以基于第二UI服务的初始复用路径确定。这里，UI服务的初始复用路径可以包括UI服务包的名称和UI服务包的版本号。可选的，UI服务包的初始复用路径还可以包括加载装置名称，UI服务包中UI服务的索引目录名称，以及，UI服务名称。其中，初始复用路径的具体说明可以参考下文S204的描述，这里不予赘述。

应理解，若UI服务是运行时依赖项时，则上述初始复用路径包括：运行时依赖项的名称。这是由于，通常，包括运行时依赖项的公共依赖UI服务包通常部署于预设的网络地址上的、且全局唯一的UI服务包，并且，该预设的网络地址是加载装置默认的。其中，全局是指在该加载装置所对应的注册装置中注册的全部UI服务包。加载装置与注册装置的对应关系可以参考下文S103的描述，这里不予赘述。

在实际应用中，开发人员可以基于上述的UI服务的初始复用路径，确定复用代码中的该UI服务的复用路径。该UI服务的复用路径可以包括UI服务包的名称和UI服务包的版本号。可选的，复用路径还可以包括加载装置名称，UI服务包中UI服务的索引目录名称，以及，UI服务的的名称。其中，UI服务包的版本号可以是模糊版本号。若UI服务是运行时依赖项时，则复用路径与初始路径相同，即为运行时依赖项的名称。

其中，复用路径中的加载装置名称，UI服务包的名称，UI服务包中UI服务的索引目录名称，以及UI服务的名称，即上述初始复用路径中的加载装置名称，UI服务包的名称，UI服务包中UI服务的索引目录名称，以及，UI服务的的名称，在此不再赘述。

上述UI服务的复用路径中的UI服务包的模糊版本号，用于指示满足预设版本条件的UI服务包。若UI服务包的版本号通过m个数字表示的话，那么该预设条件可以是，UI服务包的版本号的前n个数字相同。这时，UI服务包的模糊版本号中的后m-n个数字可以用“x”表示，“x”表示UI服务包版本号中后m-n个数字为待定。其中，m和n均是正整数，m＞n。

示例性的，若UI服务的初始复用路径中的版本号为1.1.3，这时，m是3。若n是2，那么，满足预设版本条件的UI服务包的模糊版本号是1.1.x，1.1.x用于指示所有版本的前2位均为1的UI服务包。若n是1，那么满足预设条件的UI服务包的模糊版本号是1.x.x，1.x.x用于指示所有版本的前1位为1的UI服务包。

这样的话，当加载装置加载复用了UI服务包中的UI服务(例如第二UI服务)时，则可以根据第二UI服务的复用路径中的第二UI服务包的模糊版本号，从最新版本的第二UI服务包中下载被复用的UI服务。加载装置从最新版本的第二UI服务包中下载被复用的UI服务的过程可以参考下文S303的描述，这里不予赘述。

具体的，上述复用代码可以通过关键字引用复用路径的形式实现。

其中，复用路径的标准格式可以是：“$加载装置的名称/UI服务包名称@UI服务包版本号/UI服务包中UI服务的索引目录名称/UI服务名称”。

其中，“加载装置的名称”可以不填，不填则表示默认当前加载装置。“UI服务包中UI服务的索引目录名称”可以不填，不填则表示该UI服务包中只有一个索引目录。“UI服务名称”可以不填，不填则表示该UI服务的入口是默认入口(例如默认的应用程序接口(application programming interface，API))。

一种可能的实现方式，该复用代码可以通过import关键字引用复用路径的形式实现，或者，该复用代码可以通过import关键函数引用复用路径的形式实现。这里，import关键字和import关键函数均符合标准ECMA-262中定义的脚本语言规范(ecmascript，ES)。

在这种实现方式中，该复用路径所对应的UI服务在被软件系统的加载装置加载后，软件系统所采用的渲染模式为虚拟UI对象渲染模式。

示例性的，该复用代码可以是：

import cpqcpartlist from“$/test-component@1.0.x”；

import{test1}from“$/test-component@1.0.x/package1”；

其中，import“”为import关键字的格式。“$/test-component@1.0.x”表示复用路径，其中，该复用路径中包括UI服务包名称“test-component”和UI服务包的模糊版本号“1.0.x”。

又示例性的，该复用代码可以是：

()＝>import(“$/test-component@1.0.x/turbovuep”)；

其中，()＝>import(“”)为import关键函数的格式。“$/test-component@1.0.x/turbovuep”表示复用路径，其中，该复用路径中包括UI服务包名称“test-component”、UI服务包的模糊版本号“1.0.x”，以及UI服务的名称“turbovuep”。

另一种可能的实现方式，在执行非ES标准的软件系统中，该复用代码可以通过$turbo关键字引用复用路径的形式实现。

可选的，复用代码可以通过$turbo关键字引用复用路径的形式实现。

在这种实现方式中，该复用路径所对应的UI服务在被软件系统的加载装置加载后，所采用的渲染模式为真实UI渲染模式中的组合渲染模式。并且，软件系统将基于复用路径所对应的UI服务渲染得到的UI插入显示在软件系统当前所显示的UI中。

可以理解，软件系统将该UI插入显示在软件系统当前所显示的UI中，改变了软件系统原本所显示UI的布局、页面、或篇幅等。

示例性的，复用代码可以是：

const component＝await$turbo(“#container”，“$/test-component@1.0.x”，options)；

其中，$turbo()表示$turbo关键字的格式，“$/test-component@1.0.x”表示复用路径。

可选的，复用代码可以通过$turbo.iframe关键字引用复用路径的形式实现。

在这种实现方式中，该复用路径所对应的UI服务在被软件系统的加载装置加载后，所采用的渲染模式为真实UI渲染模式中的浮动框架模式。并且，软件系统将基于复用路径所对应的UI服务渲染得到的UI叠加显示在软件系统当前所显示UI之上。

可以理解，软件系统将该UI叠加显示在软件系统当前所显示UI之前，不会改变软件系统原本所显示UI的布局、页面、或篇幅等。

示例性的，复用代码可以是：

const component＝await$turbo.iframe(“#container”，“$/test-component@1.0.x”，options)；

其中，$turbo.iframe()表示关键字的格式，“$/test-component@1.0.x”表示复用路径。

可选的，复用代码可以通过$turbo.vue关键字引用复用路径的形式实现。

在这种实现方式中，该复用路径所对应的UI服务在被软件系统的加载装置加载后，所采用的渲染模式为虚拟UI对象渲染模式。

示例性的，复用代码可以是：

TestComponent：()＝>$turbo.vue(“$/test-component@1.0.x”，vue)；

其中，“$turbo.vue()”表示关键字的格式，“$/test-component@1.0.x”表示的复用路径。“vue”是一种变量，表示对象。并且，“vue”是可选参数，其可填或者不填。若不填，表示当前加载装置内的vue对象，若填，则表示当前软件系统自身的vue对象。

可选的，复用代码可以通过$turbo.react关键字引用复用路径的形式实现。

在这种实现方式中，该复用路径所对应的UI服务在被软件系统的加载装置加载后，所采用的渲染模式为虚拟UI对象渲染模式。

示例性的，复用代码可以是：

TestComponent：()＝>$turbo.react(“$/test-component@1.0.x”，react)；

其中，“$turbo.react()”表示关键字的格式，“$/test-component@1.0.x”表示的复用路径。“react”是一种变量，表示对象。并且，“react”是可选参数，其可填或者不填。若不填，表示当前加载装置内的react对象，若填，则表示当前软件系统自身的react对象。

另外，由于本申请实施例提供的生成UI服务包的方法中，第一UI服务包中的UI服务可以复用第二UI服务包中的UI服务。当第一UI服务包的类型是业务UI服务包时，这种情况下，第一UI服务包生成后，第一UI服务包中的UI服务，也可以被其他至少一个UI服务包中的UI服务复用。

可选的，第一UI服务包中的UI服务可以全部的被其他至少一个UI服务包中的UI服务复用。

可选的，第一UI服务包中的UI服务可以部分的被其他至少一个UI服务包中的UI服务复用。

在具体实现时，生成装置可以通过在上述m个UI服务的代码所构成的代码文件中，基于入口文件，通过关键字导出可被复用的UI服务的列表，该列表可以作为第一UI服务包的配置文件。通过这种设计，可以使得后续开发人员在编写代码时，根据开发需求复用第一UI服务包中的可被复用的UI服务。

其中，上述入口文件可以是index.ts文件，上述关键字可以是export关键字。示例性的，基于入口文件index.ts，通过export关键字导出可被复用的UI服务的代码可以是：

packages>test-component>src>ts index.ts

1 export{default}from“components/cpart-list/index.vue”；

2 export{default as networktest}from“components/netw-test.vue”

3 export{default as testapp}from“app/index.vue”；

其中，标记编号“1～3”的代码，用于表示导出的3个UI服务。“default”表示所要导出的UI服务的入口为默认入口。“default as networktest”表示所要导出的UI服务的入口名称为“networktest”，“default as testapp”表示所要导出的UI服务的入口名称为“testapp”，“components/cpart-list/index.vue”、“components/netw-test.vue”、“app/index.vue”均表示所要导出的UI服务在该UI服务所属的UI服务包中的代码路径。

可以理解的是，生成装置可以先获取开发框架，然后通过输入输出接口接收开发人员输入的m个UI服务的代码。其中，该m个UI服务的代码是基于生成装置所获取的开发框架编写的。这种情况下，生成装置可以先执行S101，再执行S102。

当然，生成装置也可以从其他设备获取到上述m个UI服务的代码，该m个UI服务的代码是该其他设备获取开发框架后，通过输入输出接口接收开发人员所输入的m个UI服务的代码。其中，该m个UI服务的代码是基于该其他设备所获取的开发框架编写的。这种情况下，生成装置可以先执行S102，再执行S101。

可以理解的是，若生成装置所要生成的UI服务包是公共依赖UI服务包，则上述m个UI服务的代码，可以是m个运行时依赖的代码。该m个运行时依赖的代码经步骤S101所获取的开发框架转化后，即可得到公共依赖UI服务包。

其中，在m个运行时依赖的代码中，至少一个运行时依赖的代码可以关联驱动代码。这里，该驱动代码用于实现驱动的功能。当生成装置基于m个运行时依赖的代码，生成公共依赖UI服务包后，上述关联有驱动代码的至少一个运行时依赖的代码所对应的至少一个运行时依赖项，可以关联该驱动代码所实现的驱动，该驱动用于初始化该运行时依赖项。

在S103，通过所获取的开发框架转化上述m个UI服务的代码所得到的第一UI服务包，可以是业务UI服务包、实现加载装置功能的UI服务包或公共依赖UI服务包中的任意一种UI服务包。

具体的，生成装置可以基于第一配置文件(对应本申请实施例中的预设的配置文件)，通过步骤S101中所获取的开发框架，转化步骤S102中获取的m个UI服务的代码，从而得到第一UI服务包。该第一UI服务包包括m个UI服务和第一依赖关系集。

其中，第一配置文件可以是生成装置按照开发框架的标准预先配置的，也可以是生成装置预先从其他设备获取的，对此不作限定。

其中，第一配置文件用于指示第一UI服务包的类型，该类型用于表示第一UI服务包的用途。例如，第一UI服务包可以是上述的业务UI服务包、实现加载装置功能的UI服务包或者公共依赖UI服务包中的任一种UI服务包。

示例性的，在第一配置文件中，可以用“portal”表示实现加载装置功能的UI服务包，可以用“component”表示业务UI服务包，以及可以用“runtime”表示公共依赖UI服务包。这样的话，当第一配置文件包括“portal”，则生成装置基于第一配置文件生成的第一UI服务包，是实现加载装置功能的UI服务包。

当第一配置文件包括“component”，则生成装置基于第一配置文件生成的第一UI服务包，是业务UI服务包。当第一配置文件包括“runtime”，则生成装置基于第一配置文件生成的第一UI服务包，是公共依赖UI服务包。

当第一配置文件指示第一UI服务包的类型是实现加载装置功能的UI服务包，这种情况下，生成装置还预先配置有第二配置文件。

这种情况下，生成装置可以基于第一配置文件，通过步骤S101中所获取的开发框架，转化步骤S102中获取的m个UI服务的代码，从而得到第一UI服务包中，还包括有第二配置文件。该第一UI服务包是实现加载装置功能的UI服务包。

其中，第二配置文件包括至少一个注册装置的网络地址。这样，第一UI服务包所实现的加载装置，与该至少一个注册装置的网络地址所对应的注册装置对应。并且，该加载装置可以与该至少一个注册装置进行通信，并加载在该至少一个注册装置中注册的所有的UI服务包中的UI服务。

可以看出，一个加载装置可以对应至少一个注册装置。需要说明的是，一个注册装置，也可以对应至少一个加载装置。也就是说，一个注册装置的网络地址，可以配置在用于生成实现不同加载装置功能的UI服务包的第二配置文件中。

这里，注册装置的相关说明，可以参考下文S201～S204，这里不予赘述。

具体的，上述开发框架可以通过以下任一种方式得到第一UI服务包：

一种可能的实现方式，开发框架可以基于第一配置文件，将m个UI服务的代码转化为，区别于当前代码类型的另一种类型的代码，进而得到UI服务包。应理解，该另一种类型的代码可以被软件系统识别。

一种可能的实现方式，开发框架可以基于第一配置文件，将m个UI服务的代码编译为第一UI服务包。其中，编译是指把高级计算机语言转化成计算机可以识别的2进制语言的过程。

上述第一依赖关系集，可以是步骤S101所获取的开发框架在转化m个UI服务的代码时，对该m个UI服务的代码中的复用代码进行依赖检测分析，从而得到的第一依赖关系集。开发框架还将该第一依赖关系集打包在第一UI服务包中。

需要说明的是，该第一依赖关系集可以包括第一UI服务包中至少一个UI服务的依赖关系，该依赖关系用于指示该至少一个UI服务的依赖。在本申请实施例下文的描述中，以第一依赖关系集包括第一UI服务包中每个UI服务的依赖关系为例进行说明。

具体的，生成装置可以通过全文检测m个UI服务的代码中的关键字，以确定出m个UI服务的代码中的复用路径。其中，一个复用路径，用于指示代码中包括该复用路径的UI服务的依赖的访问路径。然后，生成装置基于确定出的复用路径，确定代码中包括该复用路径的UI服务的依赖。

其中，复用路径的有关描述，可以参考上文S102中有关复用路径的描述，这里不再赘述。

具体的，该第一依赖关系集包括m个依赖关系，该m个依赖关系中的每个依赖关系，用于指示第一UI服务包中的m个UI服务中每个UI服务的依赖。

例如，上述第一UI服务的依赖关系用于指示该第一UI服务的依赖。其中，第一UI服务的依赖，可以是区别于第一UI服务的UI服务和运行时依赖项中的至少一个。这里，区别于第一UI服务的UI服务，可以是第一UI服务包中的UI服务，也可以是区别于第一UI服务包的其他UI服务包(例如第二UI服务包)中的UI服务，对此不作限定。

示例性的，若第一UI服务包包括UI服务1和UI服务2，其中，UI服务1的依赖可以是UI服务3，UI服务2的依赖可以是UI服务4和运行时依赖项1。这里，UI服务3和UI服务4可以是第一UI服务包中的UI服务，也可以是区别于第一UI服务包的其他UI服务包(例如第二UI服务包)中的UI服务。

上述的第一依赖关系集可以通过表格的形式体现。当然，上述的第一依赖关系集也可以通过任一种能描述出UI服务的依赖关系的形式体现，对此不作限定。

参考表1，表1以表格的形式示出了第一依赖关系集。如表1所示，第一依赖关系集包括2个依赖关系，该2个依赖关系包括UI服务1的依赖关系和UI服务2的依赖关系。

其中，UI服务1的依赖关系指示了UI服务1的依赖包括UI服务3，UI服务2的依赖关系指示了UI服务2的依赖包括UI服务4和运行时依赖项1。

表1

在S104，生成装置可以根据预设的网络地址，将步骤S103得到的第一UI服务包部署于该预设的网络地址所对应的物理空间上。

具体的，生成装置可以通过图4所示的通信接口，将第一UI服务包发送或上传至该网络地址所对应的物理空间。

在S105，第一UI服务包的注册信息包括第一UI服务包的名称和用于部署第一UI服务包的网络地址。

具体的，生成装置可以通过图4所示的通信接口，发布第一UI服务包的注册信息。该注册信息用于在至少一个注册装置中注册第一UI服务包。

可选的，上述注册信息中还可以包括第一UI服务包的版本号。

可选的，生成装置可以将第一UI服务包的注册信息发送至该至少一个注册装置，以使该至少一个注册装置将第一UI服务包的注册信息添加至该至少一个注册装置的注册列表中。

可选的，生成装置也可以将第一UI服务包的注册信息发布在图3中所示的第三方平台，这样，该至少一个注册装置可以从该第三方平台获取到第一UI服务包的注册信息，并将第一UI服务包的注册信息添加至自身的注册列表。对此不作限定。

在S106，生成装置可以通过图4所示的通信接口，向上述至少一个注册装置发送步骤S103得到的第一UI服务包中的第一依赖关系集。

这样的话，当第一UI服务包在该至少一个注册装置注册后，该至少一个注册装置通过接收该第一依赖关系集，获取到该第一依赖关系集。

在S107，在实际应用中，第一UI服务包可以随时更新，更新第一UI服务包的过程可以参考S101～S104的过程，此处不再赘述。

可以理解，更新后的第一UI服务包可以包括第二依赖关系集，第二依赖关系集包括更新后的第一UI服务包中至少一个UI服务的依赖关系。

示例性的，若更新后的第一UI服务包中的任一个UI服务是第三UI服务，则第三UI服务的依赖关系用于指示第三UI服务的依赖。

可以理解的是，当生成装置更新第一UI服务包后，然而更新后的UI服务包并没有变更其名称、版本号以及所部属的网络地址。这时，生成装置执行步骤S108，向上述至少一个注册装置发送第二依赖关系集，以使该至少一个注册装置将第一依赖关系集更新为第二依赖关系集。

当生成装置更新第一UI服务包后，更新后的UI服务包的名称、版本号以及用于部属该更新后的UI服务包的网络地址中至少一个发生变化，例如版本号有更新。这种情况下，生成装置将发布更新后的第一UI服务包的注册信息，该注册信息包括更新后的第一UI服务包的名称和用于部署更新后的第一UI服务包的网络地址。该注册信息用于在至少一个注册装置中注册更新后的第一UI服务包。

可选的，更新后的第一UI服务包的注册信息，还可以包括更新后的第一UI服务包的版本号。

以上对本申请实施例提供的UI服务包的生成方法进行了描述，通过该方法，不同UI服务包之间可以通过复用代码中的复用路径，高效的复用UI服务。

并且，通过该方法，生成装置可以基于统一的开发框架得到上述UI服务包，当通过该UI服务包中的UI服务集成UI应用时，能够降低后续开发人员集成UI服务的门槛。

另外，本申请实施例提供的生成UI服务包的方法中，开发框架转化代码得到的UI服务包中，还包括该UI服务包中每各个UI服务的依赖关系(例如第一依赖关系集和第二依赖关系集)。这样的话，加载装置可以从注册装置中获取到所有在注册装置注册的UI服务包的依赖关系集。这样，加载装置即可根据获取到的所有的依赖关系集，确定待加载UI服务的所有依赖的复用路径，进而可以根据待加载UI服务及其依赖的复用路径，并行的下载待加载UI服务及其依赖，并加载待加载UI服务及其依赖，从而提高了加载UI服务的效率，即提高了复用UI服务或运行时依赖项的待加载UI服务的运行效率。

下面对本申请实施例提供的注册UI服务包的方法进行说明。

参考图9，图9示出了本申请实施例提供的注册UI服务包的方法的流程示意图，该方法应用于注册装置，该方法包括以下步骤：

S201、注册装置获取第一UI服务包的注册信息，其中，第一UI服务包包括至少一个UI服务。

其中，第一UI服务包的注册信息包括第一UI服务包的名称和用于部署第一UI服务包的网络地址。这里，第一UI服务包可以是通过上述步骤S101～S103得到的第一UI服务包。

可选的，该注册信息还可以包括第一UI服务包的版本号。

在一种可能的实现方式中，注册装置可以通过图4所示的通信接口，接收生成装置发送的第一UI服务包的注册信息。

在另一种可能的实现方式中，注册装置可以从第三方平台获取到第一UI服务包的注册信息。其中，生成装置预先将第一UI服务包的注册信息发布在该第三方平台，该第三方平台可以是公共服务平台等，对此不作限定。

在又一种可能的实现方式中，开发人员可以通过注册装置的输入输出接口，向注册装置输入(或导入)第一UI服务包的注册信息。相应的，注册装置可以获取到该注册信息，对此不作限定。

可选的，注册装置可以向第三方平台发送获取注册信息的请求。作为响应，第三方平台向注册装置发送第一UI服务包的注册信息。这样，注册装置即可获取到第一UI服务包的注册信息。

S202、注册装置将上述注册信息添加至注册装置的注册列表中。

具体的，注册装置将获取到的第一UI服务包的注册信息添加至该注册装置的注册列表中，这样，即实现了第一UI服务包在注册装置的注册。

其中，注册装置的注册列表中包括至少一个UI服务包的注册信息。该至少一个UI服务包可以是业务UI服务包、实现加载装置功能的UI服务包或公共依赖UI服务包，对此不作限定

示例性的，将第一UI服务包的注册信息添加至注册列表中的代码可以如下：

其中，“name”表示信息类型是UI服务包的名称，“acc-component”表示第一UI服务包的名称，“version”表示信息类型是UI服务包的版本号，“1.0.0”表示第一UI服务包的版本号，“rootUrl”表示信息类型是用于部署UI服务包的网络地址，“//r-beta.hw3static.com/s/acc-uiaas/lst”表示用于部署第一UI服务包的网络地址。

S203(可选的)、注册装置获取第一UI服务包的依赖关系集。

其中，第一UI服务包的依赖关系集的描述可以可参考上述S103中有关第一依赖关系集的相关描述，这里不再赘述。

可以理解的是，若注册装置首次获取到第一UI服务包的依赖关系集(例如步骤S103中描述的第一依赖关系集)，可以将该依赖关系集存储在注册装置中。应理解，该依赖关系集和注册列表中的第一UI服务包的注册信息对应。

可选的，注册装置可以将所获取到的依赖关系集作为第一UI服务包的一项注册信息，添加至注册列表中，以使该依赖关系集和注册列表中的第一UI服务包的注册信息对应。

若注册装置是非首次获取到第一UI服务包的依赖关系集，则注册装置更新原先保存的依赖关系集。

例如，注册装置用最新获取的依赖关系集(例如步骤S107中描述的第二依赖关系集)替换原先保存的依赖关系集(例如步骤S103中描述的第一依赖关系集)。

具体的，注册装置可以通过下述任一种可能的实现方式，获取第一UI服务包的依赖关系集。

一种可能的实现方式中，注册装置接收生成装置发送的第一UI服务包的依赖关系集。

应理解，注册装置首次接收到依赖关系集，可以是在接收生成装置发送的第一UI服务包的注册信息时接收到的。这里，该依赖关系集可以和该注册信息作为一条信息被注册装置接收到(例如，该注册信息包括该第一依赖关系集)。当然，该依赖关系集也可以和该注册信息作为两条信息被注册装置接收到，对此不作限定。

另一种可能的实现方式，注册装置可以根据第一UI服务包的注册信息中用于部署第一UI服务包的网络地址，从第一UI服务包中获取第一UI服务包的依赖关系集。

具体的，注册装置可以根据该网络地址，从该网络地址对应的物理空间中获取第一UI服务包的依赖关系集。

由于第一UI服务包可以随时更新。因此，部署在该网络地址的第一UI服务包的依赖关系集在不同时刻可能是不同的。这种情况下，注册装置可以根据该网络地址，周期性的从该网络地址对应的物理空间中，获取第一UI服务包的依赖关系集。

容易理解，注册装置根据第一UI服务包的注册信息中用于部署第一UI服务包的网络地址，从第一UI服务包中获取第一依赖关系集，可以看作是注册装置根据该网络地址，发现第一UI服务包中UI服务的依赖关系的过程。这样，通过本申请提供的注册UI服务包的方法，注册装置可以自动的发现第一UI服务包中UI服务的依赖关系。

也就是说，注册装置可以自动的发现在自身注册的每个UI服务包中每个UI服务的依赖关系。这样的话，当该注册装置对应的加载装置加载UI服务时，可以根据在该注册装置注册的每个UI服务包中每个UI服务的依赖关系，确定出待加载的全部UI服务及其依赖，并加载该全部UI服务及其依赖，从而提高了加载速度。

示例性的，注册装置根据用于部署第一UI服务包的网络地址，所获取的第一UI服务包中的第一依赖关系集的代码可以如下：

“dep”：[

“@aurora/ui”，

“$/test-component@1.0.x”，

]，

其中，“dep”表示信息类型是依赖，中括号“[]”内的内容表示依赖的复用路径。“$/test-component@1.0.x”表示UI服务的复用路径，“@aurora/ui”表示运行时依赖项的复用路径，对此不作限定。

又一种可能的实现方式，开发人员可以通过注册装置的输入输出接口，向注册装置输入(或导入)第一UI服务包的依赖关系集。相应的，注册装置可以获取到该依赖关系集，对此不作限定。

可选的，注册装置还可以根据获取到的、至少一个在注册装置注册的UI服务包(例如UI服务包1和UI服务包2)的依赖关系集(例如包括UI服务包1的依赖关系集1，以及UI服务包2的依赖关系集2)，生成初始依赖图。该初始依赖图中包括依赖关系集1和依赖关系集2所包括依赖关系，还包括依赖关系集1和依赖关系集2之间的关联关系。

初始依赖图的详细描述可以参考下文S302中依赖图的描述，这里不再赘述。

S204(可选的)、注册装置生成上述第一UI服务包中的至少一个UI服务的初始复用路径。

具体的，注册装置可以根据第一UI服务包的注册信息，生成上述第一UI服务包中的至少一个UI服务的初始复用路径。其中，第一UI服务包的注册信息包括第一UI服务包的名称、用于部署第一UI服务包的网络地址、以及第一UI服务包的版本号。

可以理解的是，如果第一UI服务包的注册信息中不包括第一UI服务包的版本号，则注册装置可以通过用于部署第一UI服务包的网络地址，获取到第一UI服务包的版本号。这种情况下，注册装置可以根据第一UI服务包的注册信息以及第一UI服务包的版本号，生成上述第一UI服务包中的至少一个UI服务的初始复用路径。

这样，开发人员在开发编写新的UI服务的代码时，即可根据上述第一UI服务包的中可被复用的UI服务的初始复用路径，确定复用该UI服务的复用路径。该初始复用路径和该复用路径，均用于指示上述至少一个UI服务的访问路径。其中，该复用路径包括第一UI服务包的模糊版本号。

第一UI服务包的模糊版本号的有关说明，可以参考上述S102中UI服务包的模糊版本号的有关描述，这里不再赘述。

这里，UI服务的初始复用路径可以包括UI服务包的名称和UI服务包的版本号，可选的，UI服务的初始复用路径还可以包括加载装置名称，UI服务包中UI服务的索引目录名称，以及UI服务的名称。

其中，生成装置所生成的实现加载装置功能的UI服务包中包括有第二配置文件，该第二配置文件中配置有至少一个注册装置的网络地址，因此，该加载装置名称可以是配置有上述注册装置网络地址的加载装置的名称。

UI服务包的名称和UI服务包的版本号，即上述UI服务所属UI服务包的名称以及UI服务包的版本号，即上述UI服务所属UI服务包的注册信息中的UI服务包的名称以及UI服务包的版本号。

UI服务包中UI服务的索引目录名称，可以用于表示UI服务包中不同的UI服务集合的集合名称(或者叫组合名称)。其中，一个UI服务集合包括至少一个UI服务。若UI服务包中包括m个UI服务，则该m个UI服务可以划分为至少一个UI服务集合。

示例性的，一个UI服务集合中的UI服务，可以是接口类型相同的UI服务。本申请对划分不同UI服务集合的依据不作限定。

UI服务的名称表示该UI服务的入口。示例性的，该入口可以是API。

类似的，注册装置也可以根据公共依赖UI服务包的注册信息，生成公共依赖UI服务包中至少一个运行时依赖项的初始复用路径，这里不再赘述。

这样，开发人员即可通过上述的UI服务或运行时依赖项的初始复用路径，确定复用该UI服务或运行时依赖项的复用路径。这样，生成装置在生成复用了UI服务或运行时依赖项的UI服务包时，可以基于复用路径分析得到第一UI服务包中UI服务的依赖关系。

进一步的，加载装置可以基于该依赖关系以及复用路径，下载以及加载被复用的UI服务或运行时依赖项。

可选的，注册装置可以将生成的上述第一UI服务包中的至少一个UI服务的初始复用路径，发布到公共服务平台，以便开发人员在开发新的UI服务包时，可以根据上述第一UI服务包中可被复用的UI服务的初始复用路径，确定复用该UI服务的复用路径，从而实现不同UI服务包中的UI服务可以互相复用。

当然，注册装置也可以将在该注册装置注册的公共依赖UI服务包中至少一个运行时依赖项的初始复用路径，发布到公共服务平台。以便开发人员在开发新的UI服务包时，可以根据至少一个运行时依赖项的初始复用路径，确定复用至少一个运行时依赖项的复用路径。

这样，通过本申请实施例提供的注册UI服务包的方法，第一UI服务包可以在注册装置中注册。注册装置还可以进一步的获取到第一UI服务包中至少一个UI服务的依赖关系(例如第一依赖关系集)。这样的话，加载装置可以从注册装置中获取到所有在注册装置注册的UI服务包的依赖关系集。

这样，加载装置即可根据获取到的所有的依赖关系集，确定待加载UI服务的所有依赖的复用路径，进而可以根据待加载UI服务及其依赖的复用路径，并行的下载待加载UI服务及其依赖，并加载待加载UI服务及其依赖，从而提高了加载UI服务的效率，即提高了复用了UI服务或运行时依赖项的待加载UI服务的运行效率。

需要说明的是，上述注册UI服务包的方法，也可以由本申请实施例提供的加载装置执行，这种情况下，加载装置和上述注册装置即为同一个装置。对此不作限定。

可以理解的是，上述生成UI服务包和注册UI服务包的方法流程，均是UI服务的开发态流程。这里，开发态流程表示开发UI服务的方法流程。下面，对UI服务的运行态流程进行说明。这里，运行态流程表示运行UI服务(或称作加载UI服务)的方法流程。

参考图10，图10示出了本申请实施例提供的加载UI服务的方法的流程示意图，该方法应用于加载装置。

这里，加载装置用于为软件系统加载UI服务。该加载装置包括依赖图，该依赖图指示至少一个UI服务包中至少一个UI服务的依赖，以及指示将该至少一个UI服务包中的任一个UI服务引用为依赖的UI服务。该至少一个UI服务包是在至少一个注册装置中注册的UI服务包。这里，该至少一个注册装置可以是生成装置在第二配置文件中配置的注册装置的网络地址所对应的注册装置。

如图10所示，该加载UI服务的方法包括以下步骤：

S301、加载装置接收加载请求，该加载请求用于请求加载待加载UI服务。

具体的，加载装置可以接收软件系统发出的加载请求，该加载请求用于请求加载待加载UI服务。该加载请求可以包括用于指示该待加载UI服务的复用路径。

其中，复用路径的描述可以参考上文S102中有关复用路径的描述，这里不再赘述。

该待加载UI服务可以包括至少一个UI服务。当待加载UI服务包括多个UI服务，则上述加载请求可以包括用于指示该多个UI服务中每个UI服务的复用路径。

这里，加载装置加载上述待加载UI服务后，软件系统可以将加载的待加载UI服务渲染为至少一个UI。该至少一个UI可以是基于本申请实施例中的UI服务包构建的工具类UI应用中的UI，也可以是基于本申请实施例中的UI服务包所构建的场景类UI应用中的UI，对此不作限定。

在实际应用中，软件系统可以接收用户通过输入输出接口(例如键盘、鼠标或者图6所示终端设备的触摸屏)输入的加载UI的请求，这里，该UI可以是任一个UI应用中的UI。然后，软件系统启动加载装置，并向加载装置发出加载请求，该加载请求用于请求加载待加载UI服务。当该待加载UI服务在被软件系统渲染后，可以得到用户请求加载的UI。

示例性的，以软件系统是浏览器为例，用户可以在浏览器的地址栏输入网络地址(或者，用户通过点击浏览器上的图标或按钮，由浏览器自动导入网络地址)。这样，浏览器即接收到用户加载UI的请求，例如该UI可以是浏览器的主页。然后，浏览器启动加载装置，并向加载装置发出加载请求，该加载请求用于请求加载待加载UI服务，该待加载UI服务在被浏览器渲染后，可以得到浏览器的主页UI。

可选的，软件系统在接收到用户加载UI的请求后，可以启动预置的至少一个加载装置。

可选的，软件系统在接收到用户加载UI的请求后，可以下载至少一个加载装置。然后，软件系统启动该至少一个加载装置。

示例性的，软件系统可以通过入口文件或桥接器下载至少一个加载装置(例如下载第一加载装置和第二加载装置)。以软件系统是浏览器为例，浏览器可以通过入口文件下载两个加载装置的代码可以如下：

<script type＝“text/javascript”src＝“http://kweweb-rhs1.huawei.com/isales/index/loader.js？ns＝isales”></script>

<script type＝“text/javascript”src＝“http://kweweb-rhs1.huawei.com/isales/cpq/index/loader.js？ns＝cpq”></script>

其中，“http://kweweb-rhs1.huawei.com/isales/index/loader.js？ns＝isales”表示第一加载装置的网络地址，“isales”表示第一加载装置的名称，“http://kweweb-rhs1.huawei.com/isales/cpq/index/loader.js？ns＝cpq”表示第二加载装置的网络地址，“cpq”表示第二加载装置的名称。

需要说明的是，该第一加载装置的网络地址可以是用于部署实现该第一加载装置功能的UI服务包的网络地址，该第二加载装置的网络地址可以是用于部署实现该第二加载装置功能的UI服务包的网络地址。该第一加载装置的网络地址和该第二加载装置的网络地址可以是开发人员配置在浏览器中的。

这种情况下，软件系统的代码中还包括，用于指示通过上述第一加载装置和第二加载装置加载UI服务的代码，该代码可以是：

$turbo.$isales(“$/test-component@1.0.x”)

$turbo.$cpq(“$/test-component@1.0.x”)

其中，代码“$turbo.$isales(“$/test-component@1.0.x”)”表示：第一加载装置“isales”可以用于加载复用路径“$/test-component@1.0.x”所指示的UI服务。代码“$turbo.$cpq(“$//test-component@1.0.x”)表示：第二加载装置“cpq”可以用于加载复用路径“$/test-component@1.0.x”所指示的UI服务。

可选的，软件系统还可以通过已经运行的加载装置(例如第一加载装置)引入第三加载装置。其中，第三加载装置也可以通过执行S301～S304的方法为软件系统加载UI服务。该第三加载装置的数量为至少一个。

具体的，第一加载装置可以通过实现第一加载装置功能的UI服务包中的第二配置文件，引入第三加载装置。该第二配置文件中包括用于引入第三加载装置的代码。

作为示例，该第二配置文件中用于引入第三加载装置的代码可以如下：

这里，上述代码表示引入了两个第三加载装置，包括加载装置'cpq'和加载装置'isales'。其中，第三加载装置'cpq'的网络地址是"http://cpq.huawei.com/"，第三加载装置'isales'的网络地址是http://isales.huawei.com/。

在这种情况下，实现第一加载装置功能的UI服务包的代码中还包括，用于指示通过上述两个第三加载装置加载UI服务的代码。

作为示例，在es标准下，采用import关键字时，该代码可以是：

import TestComponent1 from“$cpq/test-component@1.0.x”

import TestComponent2 from$isales/test-component@1.0.x

在es标准下，采用import关键函数时，该代码可以是：

()＝>import($cpq/test-component@1.0.x)；

()＝>import($isales/test-component@1.0.x)；

其中，对于import关键字和import关键函数的相关描述可以参考上文，这里不再赘述。

非es标准下，该代码可以是：

$turbo(“$cpq/test-component@1.0.x”)

$turbo(“$isales/test-component@1.0.x”)

其中，在上述两种标准下，复用路径“$cpq/test-component@1.0.x”中的加载装置名称为第三加载装置“cpq”，复用路径“$isales/test-component@1.0.x”中的加载装置名称为第三加载装置“isales”。

这样，当软件系统接收到加载复用路径“$cpq/test-component@1.0.x”所指示的UI服务时，则可以根据上述的第二配置文件中，用于引入第三加载装置的代码里的第三加载装置的网络地址，下载该第三加载装置，并通过该第三加载装置加载复用路径“$cpq/test-component@1.0.x”所指示的UI服务。

应理解，若软件系统通过至少两个加载装置(例如第一加载装置和第二加载装置)加载UI服务，则该至少两个加载装置是彼此隔离的，即第一加载装置和第二加载装置之间彼此隔离。这样的话，当同一个UI服务通过第一加载装置加载并运行时，和通过第二加载装置加载并运行时，是互不影响的，即彼此隔离的。

另外，由于在实现加载装置功能的UI服务包中，除了包括实现加载装置功能的UI服务，还包括至少一个与加载装置相关的UI服务。这种情况下，当加载装置所接收到的软件系统发出的加载请求中，包括请求加载实现加载装置功能的UI服务包中，与加载装置相关的UI服务时，加载装置可以直接加载这些与加载装置相关的UI服务，而无需执行后续的S302～S304。

S302、加载装置根据依赖图确定该待加载UI服务的依赖。

具体的，加载装置可以根据依赖图，确定该待加载UI服务的依赖的复用路径。

其中，该依赖图是基于至少一个UI服务包中部分或全部的UI服务包的依赖关系集得到的。该依赖关系集包括该部分或全部的UI服务包中至少一个UI服务的依赖关系。

其中，该部分或全部的UI服务包中至少一个UI服务的依赖关系，用于指示该部分或全部的UI服务包中至少一个UI服务的依赖。

其中，依赖关系集的描述，可以参考上文中S103中有关第一依赖关系集的描述，这里不再赘述。

可选的，加载装置中的依赖图，可以是加载装置基于在注册装置中注册的至少一个UI服务包的依赖关系集生成的，或者，可以是加载装置基于预先接收到的注册装置所生成的初始依赖图生成的。该依赖图可以用于指示在注册装置中的至少一个UI服务包中至少一个UI服务的依赖，以及将该UI服务引用为依赖的UI服务。这里，该注册装置是与该加载装置对应注册装置，该注册装置的数量为至少一个。其中，加载装置与注册装置的对应关系可以参考上文步骤S103的描述，这里不再赘述。

示例性的，参考图11，图11示出了一种依赖图110。

如图11所示，依赖图110包括3个依赖关系，其中，UI服务a的依赖关系包括：UI服务a是UI服务b的依赖、UI服务a依赖UI服务c以及UI服务a依赖运行时依赖项a(即UI服务a的依赖包括UI服务c和运行时依赖项a)。UI服务b的依赖关系包括：UI服务b依赖UI服务a，UI服务b依赖运行时依赖项b(即UI服务b的依赖包括UI服务a和运行时依赖项b)。UI服务c的依赖关系包括：UI服务c是UI服务a的依赖，以及UI服务c依赖运行时依赖项c(即UI服务c的依赖是运行时依赖项c)。

应理解，上述依赖图还可以通过两个集合表示。该两个集合可以分别是UI服务的集合，以及关系的集合。其中，关系可以包括UI服务和其依赖之间的关系、不同UI服务之间的关系、以及不同UI服务的依赖之间的关系。

可以理解的是，上述依赖图中，可以包括上述部分或全部的UI服务包中至少一个的UI服务和运行时依赖项的复用路径。

其中，复用路径的描述可以参考上文S102中有关复用路径的描述，这里不再赘述。

进一步的，加载装置可以根据上述加载请求中的复用路径，在上述依赖图中，确定该待加载UI服务的依赖的复用路径。其中，该待加载UI服务可以包括至少一个依赖。

应理解，若将该待加载UI服务的依赖称为第一级依赖，则对该第一级依赖而言，该第一级依赖的依赖可以称为该待加载UI服务的第二级依赖。以此类推，该第二级依赖的依赖可以称为该待加载UI服务的第三级依赖，该第三级依赖的依赖可以称为该待加载UI服务的第四级依赖，等等。

也就是说，第y级依赖的依赖可以称为该待加载UI服务的第(y+1)级依赖。其中，第y级依赖和第(y+1)级依赖均可以包括UI服务和运行时依赖项的至少一种。需要说明的是，当第y级依赖仅包括运行时依赖项，则第y级依赖不存在下一级依赖，即第y级依赖是该待加载UI服务的最后一级依赖。这时，该待加载UI服务的依赖包括y级依赖。其中，y是正整数。

示例性的，若待加载UI服务是图11中所示的UI服务b，则UI服务b的第一级依赖包括UI服务a和运行时依赖项b，由于UI服务a的依赖包括UI服务c和运行时依赖项a，则UI服务b的第二级依赖包括UI服务c和运行时依赖项a。由于UI服务c的依赖是运行时依赖项c，则UI服务b的第三级依赖包括运行时依赖项c。也就是说，UI服务b的依赖包括3级依赖。

应理解，由于上述依赖图可以直观的体现UI服务之间、或UI服务和运行时依赖项之间的依赖关系，这样，加载装置即可根据上述加载请求中的复用路径，在上述依赖图中，确定该待加载UI服务的y级依赖中，每一级依赖的的复用路径。

下面，以上述依赖图是基于在注册装置中注册的全部UI服务包的依赖关系集生成的为例进行说明。

这种情况下，加载装置可以根据预先获取的、在注册装置中注册的每个UI服务包的依赖关系集，生成上述依赖图。下面对加载装置预先获取在注册装置中注册的每个UI服务包的依赖关系集的过程予以说明。

具体的，加载装置可以根据第二配置文件(参考S103中所述的第二配置文件)中配置的至少一个注册装置的网络地址，向注册装置发送依赖获取请求。

该获取请求用于请求获取注册装置中的注册列表，或者，用于请求在该注册装置中注册的每个UI服务包的依赖关系集，或者用于获取该注册装置生成的初始依赖图。其中，注册列表中包括有在该注册装置中注册的每个UI服务包的依赖关系集，或该注册装置所生成的初始依赖图中的至少一个。

可选的，加载装置可以在运行时，向根据第二配置文件中配置的至少一个注册装置的网络地址，向注册装置发送上述依赖获取请求。

基于该依赖获取请求，注册装置向加载装置发送在自身注册的每个UI服务包的依赖关系集，或者向加载装置发送初始依赖图。

这样，加载装置即可根据接收到的在注册装置注册的每个UI服务包的依赖关系集，或者注册装置的初始依赖图，生成上述依赖图。

另外，由上文描述可知，在注册装置中注册的UI服务包(例如第一UI服务包)的依赖关系集可以是周期性的更新的。

因此，可选的，加载装置可以在运行时，向根据第二配置文件中配置的至少一个注册装置的网络地址，向注册装置发送上述依赖获取请求。基于该依赖获取请求，注册装置可以周期性的向加载装置发送在自身注册的每个UI服务包的依赖关系集，或者周期性的向加载装置发送初始依赖图。

可选的，由于在注册装置中注册的UI服务包(例如第一UI服务包)的依赖关系集可以是周期性的更新的。因此，加载装置可以在运行后，周期性的向根据第二配置文件中配置的至少一个注册装置的网络地址，向注册装置发送上述依赖获取请求。

相应的，注册装置周期性的向加载装置发送在自身注册的每个UI服务包的依赖关系集，或者周期性的向加载装置发送初始依赖图。

这样加载装置即可根据周期性接收到的在注册装置注册的每个UI服务包的依赖关系集，或者根据周期性接收到的注册装置的初始依赖图，更新上述依赖图。

S303(可选的)、加载装置基于待加载UI服务的复用路径和待加载UI服务的依赖的复用路径，下载待加载UI服务和上述确定出的该待加载UI服务的依赖。

其中，下载待加载UI服务，是指从存储待加载UI服务的设备或物理空间，将待加载UI服务下载到运行软件系统的本地设备的过程。下载该待加载UI服务的依赖，是指从存储该待加载UI服务的依赖的设备或物理空间，将该待加载UI服务的依赖，下载到运行软件系统的本地设备的过程。

可以理解的是，若待加载UI服务和/或待加载UI服务的依赖，本身就存储于运行软件系统的本地设备，则无需执行S303所述的下载步骤。

具体的，加载装置可以根据加载请求中待加载UI服务的复用路径，以及步骤S302确定出的待加载UI服务的依赖的复用路径，并行的下载该待加载UI服务和该待加载UI服务的依赖。这里，该待加载UI服务的依赖包括该待加载UI服务的y级依赖。

具体的，加载装置可以根据待加载UI服务的复用路径，以及该待加载UI服务的依赖的复用路径，同步或异步的并行下载该待加载UI服务和该待加载UI服务的依赖，对此不作限定。

这样，通过并行的下载该待加载UI服务和该待加载UI服务的依赖，可以提高加载装置下载该待加载UI服务和该待加载UI服务的依赖的效率，从而提高加载装置加载该待加载UI服务和该待加载UI服务的依赖的效率。

下面以加载装置根据待加载UI服务的复用路径，下载该待加载UI服务为例，对下载器下载待加载UI服务和该待加载UI服务的依赖的过程进行说明。

为方便描述，在步骤S303后面的描述中，将“待加载UI服务的复用路径”简称为“上述复用路径”。

一种可能的实现方式中，若加载装置获取到注册装置的注册列表。这样的话，加载装置即可根据上述复用路径中的UI服务包的名称和UI服务包的模糊版本号，在所获取到的注册列表中，确定最新版本的目标UI服务包，该目标UI服务包中包括待加载UI服务。然后，加载装置基于该目标UI服务包在注册列表中的注册信息，确定用于部署该目标UI服务包的网络地址。

这样，加载装置即可根据所确定的网络地址，以及上述复用路径中的UI服务包中UI服务的索引目录名称和UI服务的名称，从该网络地址对应的设备或物理空间中，下载目标UI服务包中的待加载UI服务。

另一种可能的实现方式中，加载装置向注册装置发送确定待加载UI服务的请求，该请求中包括上述复用路径中的UI服务包的名称和UI服务包的模糊版本号。这样，注册装置即可根据上述复用路径中的UI服务包的名称和UI服务包的模糊版本号，在注册列表中确定最新版本的目标UI服务包，该目标UI服务包中包括待加载UI服务。

然后，注册装置基于该目标UI服务包在注册列表中的注册信息，确定用于部署该目标UI服务包的网络地址。

接着，注册装置将所确定出的，用于部署目标UI服务包的网络地址，发送至加载装置。相应的，加载装置接收到用于部署该目标UI服务包的网路地址。

这样的话，加载装置即可根据该网络地址，以及上述复用路径中的UI服务包中UI服务的索引目录名称和UI服务的名称，从该网络地址对应的设备或物理空间中，下载目标UI服务包中的待加载UI服务。

下面通过示例，对加载装置或注册装置基于上述复用路径中的UI服务包的名称和UI服务包的模糊版本号，在注册列表中查找并确定最新版本的目标UI服务包的过程予以说明。

示例性的，若上述复用路径中的UI服务包的名称是aaa，上述复用路径中UI服务包的模糊版本号是1.1.x。若注册列表中所包括的UI服务包中，包括3个名称为aaa的UI服务包，其中，第一个名称为aaa的UI服务包的版本号是1.1.1，第二个名称为aaa的UI服务包的版本号是1.1.3，第三个名称为aaa的UI服务包的版本号是1.1.5。若注册装置和生成装置约定的版本号定义规则为：版本号的数值越大，版本越新。这样的话，加载装置或注册装置可以确定注册列表中，名称为aaa、版本号是1.1.5的UI服务包是最新版本的UI服务包。即，加载装置或注册装置将该UI服务包确定为目标UI服务包。

也就是说，通过上述复用路径中的UI服务包的名称和UI服务包的模糊版本号，加载装置或注册装置可以为待加载UI服务的依赖匹配到最新版本的UI服务包。这样，加载装置即可从最新版本的UI服务包中下载到待加载UI服务的依赖。

因此，即使待加载UI服务的依赖、该依赖所属的UI服务包更新过版本，通过本申请实施例中的UI服务包所构建的UI应用也无需进行升级，从而节省了资源。

S304、加载装置加载已下载的待加载UI服务和该待加载UI服务依赖。

具体的，加载装置可以根据步骤S302中描述的依赖图，按序加载已下载的待加载UI服务和该待加载UI服务的依赖。即，加载装置可以根据该依赖图，按序将下载到本地设备的待加载UI服务和该待加载UI服务依赖，加载到运行软件系统的内存中。其中，本地设备是运行软件系统的本地设备。

在实际应用中。加载装置通过步骤S303，并行下载待加载UI服务和该待加载UI服务依赖时，由于网速、带宽等网络因素，待加载UI服务中的至少一个UI服务，以及该至少一个UI服务所包括的至少一个依赖，并不会同时下载完成。这样，加载装置可以根据已下载到本地的UI服务以及依赖，并根据上述依赖图所指示的依赖关系的顺序，按序加载已下载的UI服务以及依赖。其中，该顺序可以是，先加载依赖，再加载引用该依赖的UI服务。

示例性的，以待加载UI服务是图11中所示的UI服务b为例。由于UI服务b的第一级依赖包括UI服务a和运行时依赖项b，UI服务b的第二级依赖包括UI服务c和运行时依赖项a，UI服务b的第三级依赖包括运行时依赖项c。这样的话，加载装置加载UI服务或运行时依赖项的顺序可以是，运行时依赖项c→UI服务c/运行时依赖项a→UI服务a/运行时依赖项b→UI服务b。

可选的，加载装置可以在待加载UI服务中的每个UI服务下载完成时，以及在待加载UI服务的依赖中的每个依赖下载完成时，依据上述依赖图所指示的依赖关系的顺序，确定该UI服务或该依赖是否是当前需要加载的项。若是，则加载该UI服务或该依赖，若不是，则等到该UI服务或该依赖是当前需要加载的项时，加载该UI服务或该依赖。

这样，加载装置实现了边下载UI服务或依赖，边加载UI服务或依赖，从而提高了加载效率。

可以理解的是，加载装置将待加载UI服务和该待加载UI服务依赖加载完成后，软件系统可以将待加载UI服务和该待加载UI服务的依赖渲染为至少一个UI，并显示该至少一个UI。例如软件系统可以通过图6中示出的显示屏640显示该至少一个UI。

可选的，若待加载UI服务的依赖是运行时依赖项，且该运行时依赖项关联有驱动时，则加载装置在首次加载该运行时依赖项时，启动该运行时依赖项的驱动，以实现该运行时依赖项初始化。

这是由于，该运行时依赖项可能被待加载UI服务中的UI服务多次复用。在这个过程中，该运行时依赖项只需通过其关联的驱动初始化一次即可，而无需重复初始化。其中，驱动的有关描述可以参考上文中S102中驱动的有关描述，这里不再赘述。

通过这样的设计，加载装置可以全局(即加载待加载UI服务的全部过程)启动一次该运行时依赖项所关联的驱动，以使该运行时依赖项全局初始化一次。这样，相比现有技术中开发者需要手动启动运行时依赖项的驱动以初始化运行时依赖项，本申请实施例提供的方法降低了启动运行时依赖项的开发门槛，提高了UI服务的开发效率。

可以理解的是，若本申请实施例提供的注册装置和加载装置为一个装置，则无需执行S301～S304中，注册装置和加载装置之间的交互动作。

这样，通过本申请实施例提供的加载UI服务的方法，由于加载装置可以预先获取到在注册装置注册的所有的UI服务包的依赖关系集，因此加载装置可以基于获取的所有的依赖关系集，确定待加载UI服务的所有依赖的复用路径。这样，加载装置即可根据待加载UI服务及其依赖的复用路径，并行的下载待加载UI服务及其依赖，并加载待加载UI服务及其依赖，从而提高了加载待加载UI服务的效率，即提高了复用了UI服务或运行时依赖项的待加载UI服务的运行效率。

其中，上述待加载UI服务被渲染后所得到的UI，可以是采用本申请实施例提供的UI服务包所构建的工具类UI应用中的任一个UI，也可以是采用本申请实施例提供的UI服务包所构建的场景类UI应用中的任一个UI，对此不作限定。

在面向大众用户的应用生态里，当上述待加载UI服务被渲染后所得到的UI，是采用本申请实施例提供的UI服务包所构建的场景类UI应用中的任一个UI，则使用方是通过利用多个中心化(centralized)APP(即工具类APP)中的不同UI服务，构建属于使用方的去中心化(decentralized)APP(即场景类UI应用)。这样，即可通过一个应用入口，向用户呈现使用方利用该不同UI服务所创造的所有内容，从而提高了用户体验。

其中，该多个中心化APP提供的不同UI服务，可以是上文中描述的不同领域中台中的生成装置所生成的不同UI服务包中的UI服务。这里，不同的领域中台可以是该多个中心化APP的服务商的中台。

这样，使用方A就可以通过该不同领域中台的生成装置所生成的不同UI服务包中的UI服务，构建属于使用方A的应用A。这样，用户即可通过应用A的入口，去观看使用方A根据不同领域中台所生成的不同UI服务包中的UI服务所创造的所有内容，从而提高了用户的体验。

在企业数字化的应用生态里，通过本申请实施例提供的方法，使用方可以向用户提供基于用户场景的场景类UI应用。这样，用户和场景类UI应用交互一次，即可达到用户和工具类UI应用的交互多次的效果，从而提高了用户体验。

这样，通过本申请实施例提供的方法，通过复用UI服务构建场景类UI应用，最大程度利用了第五代移动通信技术(5th generation mobile network，5G)带来的大流量，及AI技术带来的场景识别等能力，从而提高了用户使用面向大众的应用或企业数字化应用时的用户体验。

为了更清楚的描述对本申请实施例所提供的方法，下面以华为云上的企业IT系统为例，以及以注册装置执行注册UI服务包的方法，加载装置仅执行加载UI服务的方法为例，对本申请实施例所提供的方法做进一步说明。

参考图12，图12示出了本申请实施例提供的生成、注册UI服务包、加载UI服务的方法的流程图，该方法可以包括以下步骤：

S401、生成装置生成第一UI服务包，以及将第一UI服务包部署于预设的网络地址上。

其中，第一UI服务包可以是设置在不同中台上的生成装置生成的UI服务包。

这里的第一UI服务包，可以和图8所示流程图中的第一UI服务包是同一个UI服务包，也可以是不同于图8所示流程图中的第一UI服务包，对此不作限定。

示例性的，参考图13a，设置在华为IT的主干交易中台131的生成装置，可以通过执行上文中的步骤S101～S103，生成第一UI服务包。

然后，生成装置将第一UI服务包部署于预设的网络地址上。这里不再赘述。

参考图13a，图13a示出了设置在华为IT的主干交易中台131的生成装置，通过执行上文中的步骤S101～S103，生成的第一UI服务包。

其中，第一UI服务包可以是UI服务包a、UI服务包b、UI服务包c、UI服务包d以及UI服务包e中的任意一个。其中，UI服务包a可以用于提供向运营商进行报价的UI服务，UI服务包b可以用于提供向企业进行报价的UI服务，UI服务包c可以用于提供产品的UI服务，UI服务包d可以用于提供报价的UI服务，UI服务包e可以用于提供商品服务的UI服务。

其中，UI服务包a和UI服务包b可以是场景UI服务包，UI服务包c、UI服务包d以及UI服务包e可以是领域UI服务包，并且，UI服务包c中的UI服务复用了UI服务包d中的UI服务，UI服务包e复用了UI服务包d中的UI服务。

其中，场景UI服务包和领域UI服务包可以参考前文中的描述，这里不再赘述。

S402、生成装置向注册装置发送第一UI服务包的注册信息。

具体的，设置在华为IT的主干交易中台131的生成装置，可以根据上文中步骤S105中的描述，向设置在华为IT的主干交易中台131中的注册装置，发送第一UI服务包的注册信息，此处不再赘述。

其中，注册信息可以包括第一UI服务包的名称、版本号以及用于部署第一UI服务包的网络地址。

S403、注册装置基于接收到的第一UI服务包的注册信息，将第一UI服务包注册在该注册装置中。注册装置获取第一UI服务包的依赖关系集。

具体的，注册装置基于接收到的第一UI服务包的注册信息，将第一UI服务包注册在该注册装置中，可以参考上文中的步骤S201～S204的描述，这里不再赘述。

注册装置获取第一UI服务包的依赖关系集可以参考上述S203中的描述。这里不再赘述。

示例性的，注册装置可以是设置在图13a中所示的主干交易中台131的注册装置，例如图13a中所示的注册装置1。

S404、加载装置获取注册装置中的注册列表。

其中，该注册列表是注册装置中的注册列表。

具体的，加载装置获取注册装置中的注册列表的描述，可以参考上文中S302中，加载装置请求获取注册装置中的注册列表的描述，这里不再赘述。

S405、加载装置基于加载请求中待加载UI服务的复用路径，根据依赖图确定待加载UI服务的依赖的复用路径。其中，该依赖图是基于在注册装置中注册的至少一个UI服务包的依赖关系集或注册装置所生成的初始依赖图得到的。

具体的，加载装置基于加载请求中待加载UI服务的复用路径，根据该依赖图确定待加载UI服务的依赖的复用路径，可以参考上文中的步骤S302的描述，这里不再赘述。

S406、加载装置基于待加载UI服务的复用路径，以及待加载UI服务的依赖的复用路径，在注册列表中确定目标UI服务包，以及确定用于部署目标UI服务包的网络地址。

其中，目标UI服务包的数量为至少一个，目标UI服务包中包括待加载UI服务，以及待加载UI服务的依赖。

具体的，S406可以参考上文步骤S303中，加载装置在获取到的注册列表中，确定最新版本的目标UI服务包，以及确定用于部署该目标UI服务包的网络地址的描述，这里不再赘述。

S407、加载装置基于用于部署目标UI服务包的网络地址，下载并加载目标UI服务包中的待加载UI服务和待加载UI服务的依赖。

具体的，S407可以参考上文步骤S302～S303的描述，这里不再赘述。

类似的，通过本申请实施例提供的方法，还可以在图13a中所示的销售数字中台132生成UI服务包A，UI服务包B，UI服务包C，UI服务包D以及UI服务包E。

这样，通过执行上述S401～S407的方法，销售数字中台132中的注册装置2将UI服务包A，UI服务包B，UI服务包C，UI服务包D以及UI服务包E注册在注册装置2的注册列表中。

然后，软件系统可以渲染通过加载装置133下载以及加载的上述UI服务包A，UI服务包B，UI服务包C，UI服务包D以及UI服务包E中的UI服务。这里不再赘述。

参考图13a，图13a所示出的加载装置133可以同时对应注册装置1和注册装置2。也就是说，图13a中所示的注册装置1和注册装置2的网络地址均配置在生成用于实现加载装置133功能UI服务包的第二配置文件中。

当然，图13a中所示的注册装置1和注册装置2也可以对应不同的加载装置，例如，注册装置1可以对应加载装置133，注册装置2可以对应加载装置134。即，注册装置1的网络地址配置在生成用于实现加载装置133功能UI服务包的第二配置文件中，注册装置2的网络地址配置在生成用于实现加载装置134功能UI服务包的第二配置文件中。对此不作限定。

这样，当生成装置在如图13a中所示的主干交易中台131和销售数字中台132生成不同的领域UI服务包和场景UI服务包后，注册装置将其注册。这样，开发人员可以基于该不同的领域UI服务包和场景UI服务包中的UI服务，开发出适用于不同用户场景的场景类UI应用。当软件系统接收到加载该场景类UI应用中任一个UI的请求时，可以通过本申请实施例提供的加载装置，加载该任一个UI对应的UI服务，以使被加载的UI服务被渲染后，得到该任一个UI。

下面，对通过本申请实施例提供的生成UI服务包的方法、注册UI服务包的方法，以及加载UI服务的方法所构建的生态予以简单说明。

具体的，参考图13b，在UI服务提供商层面，UI服务提供商可以在各自的中台生成各自擅长领域的业务UI服务包。

其中，UI服务提供商可以是上文描述中所述的服务商。如图13b所示，提供商1可以在自己的中台生成提供商1擅长领域的业务UI服务包1，提供商2可以在自己的中台生成提供商2擅长领域的业务服务包2，提供商3可以在自己的中台生成提供商3擅长领域的业务服务包3。其中，业务UI服务包1、业务UI服务包2以及业务UI服务包3的数量均为至少一个。其中，业务UI服务包1、业务UI服务包2以及业务UI服务包3，可以是领域UI服务包，也可以是场景UI服务包。

其中，提供商在各自的中台生成各自的业务UI服务包的过程，可以参考上文生成UI服务包的描述，这里不再赘述。

可以理解，提供商可以将各自中台上生成的业务UI服务包的注册信息，发布在各自的网站，或者发布在其他公共平台(例如操作系统的应用商店等)，以使场景UI应用的集成商可以得到UI服务提供商所提供的业务UI服务包的相关信息，例如业务UI服务包的注册信息、业务UI服务包中UI服务的初始复用路径等。

在UI服务集成商层面，UI服务集成商可以根据从UI服务提供商的网站或其他公共平台获取到的、UI服务提供商所提供的业务UI服务包的相关信息，复用UI服务提供商所提供的UI服务，以开发生成自己的场景UI服务包，从而得到场景UI应用。如图13b所示，集成商1可以通过复用UI服务的提供商1、提供商2以及提供商3提供的UI服务，开发出属于自己的场景UI服务包1，从而得到集成商1的场景UI应用1，例如金融场景的UI应用。集成商2可以通过复用UI服务的提供商1、提供商2以及提供商3提供的UI服务，开发出属于自己的场景UI服务包2，从而得到集成商2的场景UI应用2，例如地产场景的UI应用。其中，场景UI服务包1和场景UI服务包2的数量均为至少一个。

其中，集成商通过复用UI服务提供商的UI服务包，生成自己的场景UI服务包的过程，可以参考上文生成UI服务包的过程，这里不再赘述。

其中，UI服务的集成商，可以是图13b所示出的UI服务提供商层面的UI服务提供商，也可以是上文中所述的构建去中心化APP的使用方，对此不作限定。

可选的，集成商可以将开发生成的场景UI服务包注册在集成商自己的注册装置中，或者注册在软件系统的注册中心(例如具有上文中注册装置功能的模块或单元)。若集成商将开发生成的场景UI服务包注册在自己的注册装置中，则集成商还将自己的注册装置的网络地址预置在自己的加载装置的配置文件中，或者预置在软件系统的加载装置的配置文件中。其中，加载装置的配置文件可以是上文中所述的第二配置文件。

集成商将开发生成的场景UI服务包注册在自己的注册装置中，或者注册在软件系统的注册中心的相关说明，可以参考上文注册UI服务包的描述，这里不再赘述。

这样，在用户层面，软件系统即可通过自己的加载装置，加载在软件系统的注册中心注册的场景UI服务包中的UI服务，从而在运行软件系统的终端设备的显示界面上，向用户显示渲染已加载UI服务所得到的UI。或者，软件系统通过引入集成商的加载装置，从而可以加载在集成商的注册装置上注册的场景UI服务包中的UI服务，进而运行软件系统的终端设备的显示界面上，向用户显示渲染已加载UI服务所得到的UI。

软件系统引入集成商的加载装置的相关描述，以及加载装置加载UI服务的相关描述，可以参考上文加载UI服务的方法中的描述，这里不再赘述。

如图13b所示，软件系统130可以是终端设备的操作系统，例如该软件系统可以是鸿蒙操作系统。该终端设备可以是移动设备或计算设备，或者，该终端设备也可以是大屏设备，对此不作限定。软件系统130中可以配置有加载装置1和加载装置2。

其中，加载装置1与注册装置1关联，加载装置2与注册装置2关联。其中，注册装置1可以是集成商1的注册装置，也可以是软件系统的注册中心。注册装置2可以是集成商2的注册装置，也可以是软件系统的注册中心，对此不作限定。若注册装置1是软件系统的注册中心，则软件系统的加载装置1的配置文件中预置该注册中心的接口。若注册装置1是集成商的注册装置，则软件系统的加载装置1的配置文件中预置注册装置1的网络地址。类似的，若注册装置2是软件系统的注册中心，则软件系统的加载装置2的配置文件中预置该注册中心的接口。若注册装置2是集成商的注册装置，则软件系统的加载装置2的配置文件中预置注册装置2的网络地址。

如图13b所示，UI服务提供商所生成的业务UI服务包也可以注册在注册装置1和/或注册装置2中。这样，对于任一个UI服务提供商而言，当该UI服务提供商通过其在中台上生成的业务UI服务包构建工具类UI应用或场景类UI应用后，该工具类UI应用或场景类UI应用中的UI服务，也可以通过注册装置1对应的加载装置1加载，或通过注册装置2对应的加载2加载。

可以理解，对于图13b中所示的UI服务提供商中的任一个提供商。例如提供商1而言，提供商1在自己的中台上生成UI服务包，注册UI服务包，以及通过加载装置加载UI服务的过程，可以是类似于图13a中所描述的生成UI服务包、注册UI服务包以及加载UI服务的过程。

可以理解，图13b中所示出的所有UI服务包，均是基于图13b所示出的软件系统130生成的UI服务包。该UI服务包中的任一个UI服务被加载渲染后，可以得到能够在运行该软件系统的终端设备的显示界面上显示的UI。

综上，本申请示例提供了一种生成、注册UI服务包、加载UI服务的方法，通过该方法，不同UI服务包之间可以通过复用代码中的复用路径，高效的复用UI服务。

并且，通过本申请实施例提供的生成UI服务包的方法，生成装置可以基于统一的开发框架得到上述UI服务包，当通过该UI服务包中的UI服务集成UI应用时，能够降低后续开发人员集成UI服务的门槛。

另外，通过该方法中，开发框架转化代码所得到的UI服务包中，还包括该UI服务包中各个UI服务的依赖关系。这样的话，当UI服务包在注册装置注册后，注册装置可以获取到UI服务包中UI的依赖关系。这样，加载装置即可从注册装置获取到该依赖关系，并可以基于该依赖关系确定待加载UI服务的所有依赖的复用路径，进而可以根据待加载UI服务及其依赖的复用路径，并行的下载待加载UI服务及其依赖，并加载待加载UI服务及其依赖，从而提高了加载UI服务的效率，即提高了复用了UI服务或运行时依赖项的待加载UI服务的运行效率。

实际应用中，在现有的面向大众用户的应用生态里，使用方可以利用多个中心化APP(即工具类的能力，创造内容给用户(即观看内容的最终消费者)。同时，用户需要通过该多个中心化APP的入口去观看使用方所创造的内容。

例如，使用方A可以通过APP 1和APP 2的能力，创造不同的内容给用户A。这样，用户A需要通过APP 1的入口观看使用方通过APP 1创造的内容，通过APP 2的入口观看使用方通过APP 2创造的内容。

通过本申请实施例提供的方法，使用方可以利用多个中心化APP中的不同UI服务，构建属于使用方自己的去中心化APP(即场景类UI应用)，并通过一个应用入口，向用户呈现使用方利用该不同UI服务所创造的所有内容，从而提高了用户的体验。

在企业数字化的应用生态里，通过本申请实施例提供的方法，使用方可以向用户提供基于用户场景的场景类UI应用。这样，用户和场景类UI应用交互一次，即可达到用户和工具类UI应用的交互多次的效果，从而提高了用户体验。

这样，通过本申请实施例提供的方法，通过复用UI服务构建UI，最大程度利用了第五代移动通信技术(5th generation mobile network，5G)带来的大流量，及AI技术带来的场景识别等能力，从而提高了用户使用面向大众的应用或企业数字化应用时的用户体验。

上述主要从方法的角度对本申请实施例提供的方案进行了介绍。为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对生成装置、注册装置和加载装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

如图14所示，图14示出了本申请实施例提供的生成装置140的结构示意图。

该生成装置140用于执行上述的生成UI服务包的方法，例如用于执行图8所示的方法。其中，生成装置140可以包括获取单元141和转化单元142。

获取单元141，用于获取UI服务的代码；该UI服务的代码中包括复用路径，该复用路径用于指示服务的依赖的访问路径。转化单元142，用于转化获取单元141获取的UI服务的代码，得到第一UI服务包，第一UI服务包包括至少一个UI服务。

作为示例，结合图8，获取单元141可以用于执行S102，转化单元142可以用于执行S103。

可选的，上述第一UI服务包中第一UI服务的代码中的复用路径，满足如下条件中的至少一种：

该第一UI服务的代码中的复用路径用于指示第二UI服务的访问路径，该第二UI服务是第一UI服务的依赖，该第二UI服务是第二UI服务包中的任一个UI服务，该第二UI服务包是不同于第一UI服务包的UI服务包。或者，

该第一UI服务的代码中的复用路径用于指示运行时依赖项的访问路径，该运行时依赖项是第一UI服务的依赖，该运行时依赖项是至少一个公共依赖UI服务包中的任一个运行时依赖项，该至少一个公共依赖UI服务包包括至少一个运行时依赖项，该至少一个公共依赖UI服务包用于为在至少一个UI服务包注册装置中注册的至少一个UI服务包中的UI服务提供依赖。其中，该第一UI服务是该第一UI服务包中的任一个UI服务。

可选的，上述第一UI服务的代码中的复用路径包括模糊版本号，该模糊版本号用于指示满足预设版本条件的第二UI服务包或至少一个公共依赖UI服务包。

可选的，获取单元141获取的UI服务的代码是基于开发框架编写的。转化单元142，具体用于通过开发框架转化获取单元141获取的UI服务的代码，得到第一UI服务包。

作为示例，结合图8，转化单元142可以用于执行S103。

可选的，上述的第二UI服务包或公共依赖UI服务包是基于上述的开发框架得到的。

可选的，转化单元142，具体用于基于预设的配置文件，通过开发框架转化获取单元141获取的UI服务的代码，得到第一UI服务包。其中，配置文件用于指示第一UI服务包的类型，该第一UI服务包的类型用于表示第一UI服务包的用途。

作为示例，结合图8，转化单元142可以用于执行S103。

可选的，上述第一UI服务包的类型包括以下至少一种：业务UI服务包、实现加载装置功能的UI服务包或公共依赖UI服务包。

可选的，生成装置140还包括：发送单元143，用于发布上述第一UI服务包的注册信息。该注册信息包括第一UI服务包的名称和用于部署第一UI服务包的网络地址，该注册信息用于在至少一个UI服务包注册装置中注册第一UI服务包。

作为示例，结合图8，发送单元143可以用于执行S105。

可选的，上述第一UI服务包包括第一依赖关系集。其中，第一依赖关系集包括第一UI服务包中至少一个UI服务的依赖关系。其中，该依赖关系用于指示第一UI服务包中至少一个UI服务的依赖。

可选的，发送单元143，还用于向至少一个UI服务包注册装置发送第一依赖关系集，该至少一个UI服务包注册装置用于注册第一UI服务包。

作为示例，结合图8，发送单元143可以用于执行S106。

可选的，生成装置140还包括：更新单元144，用于更新第一UI服务包。其中，更新后的第一UI服务包包括第二依赖关系集，该第二依赖关系集包括更新后的第一UI服务包中至少一个UI服务的依赖关系。

作为示例，结合图8，更新单元144可以用于执行S107。

可选的，发送单元143，还用于向上述至少一个UI服务包注册装置发送第二依赖关系集。

作为示例，结合图8，发送单元143可以用于执行S108。

可选的，上述第一UI服务中全部或部分的UI服务允许被引用为依赖。

关于上述可选方式的具体描述可以参见前述的方法实施例，此处不再赘述。此外，上述提供的任一种生成装置140的解释以及有益效果的描述均可参考上述对应的方法实施例，不再赘述。

作为示例，结合图4，生成装置140可以通过图4中的计算机设备40实现。

具体的，生成装置140中的获取单元141、转化单元142以及更新单元144实现的功能可以图4中的处理器41执行图4中的存储器42中的程序代码实现。发送单元143实现的功能可以通过图4中的通信接口43实现。

如图15所示，图15示出了本申请实施例提供的注册装置150的结构示意图。

该注册装置150用于执行上述的注册UI服务包的方法，例如用于执行图9所示的方法。其中，注册装置150可以包括获取单元151和添加单元152。

获取单元151，用于获取第一UI服务包的注册信息，该注册信息包括第一UI服务包的名称和用于部署第一UI服务包的网络地址。添加单元152，用于将获取单元151获取的注册信息添加至注册装置150的注册列表中。其中，该第一UI服务包中的第一UI服务的代码包括复用路径，该复用路径用于指示第一UI服务的依赖的访问路径。其中，该第一UI服务是第一UI服务包中的任一个UI服务。

作为示例，结合图9，获取单元151可以用于执行S201，添加单元152可以用于执行S202。

可选的，上述的复用路径满足如下条件中的至少一种：

该复用路径用于指示第二UI服务的访问路径，该第二UI服务是第一UI服务的依赖，该第二UI服务是第二UI服务包中的任一个UI服务，该第二UI服务包是不同于第一UI服务包的UI服务包。或者，

该复用路径用于指示运行时依赖项的访问路径，该运行时依赖项是第一UI服务的依赖，该运行时依赖项是至少一个公共依赖UI服务包中的任一个运行时依赖项，该至少一个公共依赖UI服务包包括至少一个运行时依赖项，该至少一个公共依赖UI服务包用于为在至少一个UI服务包注册装置中注册的至少一个UI服务包中的UI服务提供依赖。

可选的，上述复用路径包括第一UI服务包的模糊版本号。

可选的，获取单元151，还用于获取第一UI服务包的依赖关系集。该依赖关系集包括第一UI服务包中至少一个UI服务的依赖关系。其中，该第一UI服务的依赖关系用于指示第一UI服务的依赖。

作为示例，结合图9，获取单元151可以用于执行S203。

可选的，获取单元151，具体用于基于上述注册信息中的网络地址，周期性的从第一UI服务包中获取依赖关系集。

作为示例，结合图9，获取单元151可以用于执行S203。

可选的，获取单元151，具体用于接收生成上述第一UI服务包的装置发送的依赖关系集。

作为示例，结合图9，获取单元151可以用于执行S203。

可选的，注册装置150还包括：生成单元153，用于基于获取单元151获取的注册信息，以及第一UI服务包的版本号，生成第一UI服务包中至少一个UI服务的初始复用路径。该初始复用路径包括第一UI服务包的版本号。

作为示例，结合图9，生成单元153可以用于执行S204。

可选的，上述初始复用路径用于确定第一UI服务包中至少一个UI服务的复用路径。其中，该初始复用路径和该复用路径，均用于指示第一UI服务包中至少一个UI服务的访问路径。

关于上述可选方式的具体描述可以参见前述的方法实施例，此处不再赘述。此外，上述提供的任一种注册装置150的解释以及有益效果的描述均可参考上述对应的方法实施例，不再赘述。

作为示例，结合图4，注册装置150可以通过图4中的计算机设备40实现。

具体的，注册装置150中的获取单元151、添加单元152以及生成单元153实现的功能可以图4中的处理器41执行图4中的存储器42中的程序代码实现。

如图16所示，图16示出了本申请实施例提供的加载装置160的结构示意图。

该加载装置160用于执行上述的加载UI服务的方法，例如用于执行图10所示的方法。加载装置160可以包括接收单元161、确定单元162以及加载单元163。

接收单元161，用于接收加载请求。该加载请求用于请求加载待加载UI服务，该加载请求中包括待加载UI服务的复用路径。该待加载UI服务的复用路径用于指示待加载UI服务的访问路径。确定单元162，用于根据依赖图确定待加载UI服务的依赖。其中，该依赖图指示至少一个UI服务包中的至少一个UI服务的依赖，以及指示将至少一个UI服务包中的任一个UI服务引用为依赖的UI服务。加载单元163，用于加载待加载UI服务和待加载UI服务的依赖。

作为示例，结合图10，接收单元161可以用于执行S301，确定单元162可以用于执行S302，加载单元163可以用于执行S304。

可选的，上述待加载UI服务的复用路径包括待加载UI服务所属UI服务包的模糊版本号。

可选的，上述依赖图是基于至少一个UI服务包中的部分或全部的UI服务包的依赖关系集得到的。

可选的，上述依赖关系集包括上述部分或全部的UI服务包中的至少一个UI服务的依赖关系。其中，该部分或全部的UI服务包中的至少一个UI服务的依赖关系，用于指示该部分或全部的UI服务包中的至少一个UI服务的依赖。

可选的，上述至少一个UI服务包中的任一个UI服务的代码包括复用路径。该任一个UI服务的代码中的复用路径，用于指示任一个UI服务的依赖的访问路径。

可选的，上述至少一个UI服务包是在至少一个UI服务包注册装置中注册的UI服务包。

可选的，上述至少一个UI服务包包括第一UI服务包，该第一UI服务包中的第一UI服务的代码中的复用路径，满足如下条件中的至少一种：

该第一UI服务的代码中的复用路径，用于指示第二UI服务的访问路径，该第二UI服务是第一UI服务的依赖，该第二UI服务是第二UI服务包中的任一个UI服务，该第二UI服务包是不同于第一UI服务包的UI服务包。或者，

该第一UI服务的代码中的复用路径，用于指示运行时依赖项的访问路径，该运行时依赖项是第一UI服务的依赖，该运行时依赖项是至少一个公共依赖UI服务包中的任一个运行时依赖项，该至少一个公共依赖UI服务包包括至少一个运行时依赖项，该至少一个公共依赖UI服务包用于为在至少一个UI服务包注册装置中注册的至少一个UI服务包中的UI服务提供依赖。其中，该第一UI服务包是至少一个UI服务包中的任一个UI服务包，该第一UI服务是第一UI服务包中的任一个UI服务。

可选的，确定单元162，具体用于根据依赖图确定待加载UI服务的依赖的复用路径。

作为示例，结合图10，确定单元162可以用于执行S302。

可选的，加载装置160还包括：下载单元164，用于在加载单元163加载待加载UI服务和待加载UI服务的依赖之前，基于待加载UI服务的复用路径，以及确定单元162确定的待加载UI服务的依赖的复用路径，并行的下载待加载UI服务和待加载UI服务的依赖。加载单元163，具体用于加载下载单元164已下载的待加载UI服务和待加载UI服务的依赖。

作为示例，结合图10，下载单元164可以用于执行S303。

可选的，加载单元163，还具体用于按照依赖图指示的依赖关系，按序加载下载单元164已下载的待加载UI服务和待加载UI服务的依赖。

作为示例，结合图10，加载单元163，可以用于执行S304。

可选的，加载装置160还包括：启动单元165，用于如果依赖是运行时依赖项，则在加载单元163加载至少一个UI服务和依赖的过程中，首次加载运行时依赖项时，启动运行时依赖项的驱动。

可选的，加载装置160还包括：更新单元166，用于更新依赖图。

可选的，若加载装置160包括第一加载装置与第二加载装置，则第一加载装置与第二加载装置彼此隔离。其中，该第一加载装置和该第二加载装置均用于为一个软件系统加载UI服务。

关于上述可选方式的具体描述可以参见前述的方法实施例，此处不再赘述。此外，上述提供的任一种加载装置160的解释以及有益效果的描述均可参考上述对应的方法实施例，不再赘述。

作为示例，结合图6，加载装置160可以通过图6中的手机60实现。

具体的，加载装置160中的确定单元162、加载单元163、更新单元166以及启动单元165实现的功能可以图6中的处理器610执行图6中的内部存储器621中的程序代码实现。接收单元161和下载单元164实现的功能可以通过图6中的移动通信模块650或无线通信模块660实现。

本申请实施例还提供一种软件系统，该软件系统包括如上述图16所示加载装置，以加载待加载UI服务。

或者，该软件系统包括如上述图14所示的生成装置，以生成UI服务包。

或者，该软件系统包括如上述图15所示的注册装置，以将UI服务包注册到软件系统的注册列表中。

本申请实施例还提供一种芯片系统，如图17所示，该芯片系统170包括至少一个处理器和至少一个接口电路。

作为示例，当该芯片系统170包括一个处理器和一个接口电路时，则该一个处理器可以是图17中实线框所示的处理器171(或者是虚线框所示的处理器171)，该一个接口电路可以是图17中实线框所示的接口电路172(或者是虚线框所示的接口电路172)。当该芯片系统170包括两个处理器和两个接口电路时，则该两个处理器包括图17中实线框所示的处理器171和虚线框所示的处理器171，该两个接口电路包括图17中实线框所示的接口电路172和虚线框所示的接口电路172。对此不作限定。

处理器171和接口电路172可通过线路互联。例如，接口电路172可用于从其它装置(例如生成装置、注册装置的存储器)接收信号。又例如，接口电路172可用于向其它装置(例如处理器171)发送信号。

示例性的，接口电路172可读取存储器中存储的指令，并将该指令发送给处理器171。当处理器171调用所述指令时，以执行如图8、图9或图10中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本申请另一实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当指令在生成装置、注册装置或加载装置上运行时，该生成装置、注册装置或加载装置执行上述方法实施例所示的方法流程中该生成装置、注册装置或加载装置执行的各个步骤。

在一些实施例中，所公开的方法可以实施为以机器可读格式被编码在计算机可读存储介质上的或者被编码在其它非瞬时性介质或者制品上的计算机程序指令。

图18示意性地示出本申请实施例提供的计算机程序产品的概念性局部视图，所述计算机程序产品包括用于在计算设备上执行计算机进程的计算机程序。

在一个实施例中，计算机程序产品是使用信号承载介质180来提供的。所述信号承载介质180可以包括一个或多个程序指令，其当被一个或多个处理器运行时可以提供以上针对图8、图9或图10描述的功能或者部分功能。

因此，例如，参考图8中S101～S108，或者参考图9中S201～S204、或者参考图10中S301～S304中的一个或多个特征可以由与信号承载介质180相关联的一个或多个指令来承担。此外，图18中的程序指令也描述示例指令。

在一些示例中，信号承载介质180可以包含计算机可读介质181，诸如但不限于，硬盘驱动器、紧密盘(CD)、数字视频光盘(DVD)、数字磁带、存储器、只读存储记忆体(read-only memory，ROM)或随机存储记忆体(random access memory，RAM)等等。

在一些实施方式中，信号承载介质180可以包含计算机可记录介质182，诸如但不限于，存储器、读/写(R/W)CD、R/W DVD、等等。

在一些实施方式中，信号承载介质180可以包含通信介质183，诸如但不限于，数字和/或模拟通信介质(例如，光纤电缆、波导、有线通信链路、无线通信链路、等等)。

信号承载介质180可以由无线形式的通信介质183(例如，遵守IEEE 802.11标准或者其它传输协议的无线通信介质)来传达。一个或多个程序指令可以是，例如，计算机可执行指令或者逻辑实施指令。

在一些示例中，诸如针对图8、图9或图10描述的生成装置、注册装置或加载装置可以被配置为，响应于通过计算机可读介质181、计算机可记录介质182、和/或通信介质183中的一个或多个程序指令，提供各种操作、功能、或者动作。

应该理解，这里描述的布置仅仅是用于示例的目的。因而，本领域技术人员将理解，其它布置和其它元素(例如，机器、接口、功能、顺序、和功能组等等)能够被取而代之地使用，并且一些元素可以根据所期望的结果而一并省略。另外，所描述的元素中的许多是可以被实现为离散的或者分布式的组件的、或者以任何适当的组合和位置来结合其它组件实施的功能实体。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机执行指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(digitalsubscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

以上所述，仅为本申请的具体实施方式。熟悉本技术领域的技术人员根据本申请提供的具体实施方式，可想到变化或替换，都应涵盖在本申请的保护范围之内。

Claims (72)

1.一种加载用户界面UI服务的方法，其特征在于，应用于加载装置；所述方法包括：

接收加载请求，所述加载请求用于请求加载待加载UI服务，所述加载请求中包括所述待加载UI服务的复用路径，所述待加载UI服务的复用路径用于指示所述待加载UI服务的访问路径；

根据依赖图确定所述待加载UI服务的依赖，所述依赖图指示至少一个UI服务包中的至少一个UI服务的依赖，以及指示将所述至少一个UI服务包中的任一个UI服务引用为依赖的UI服务；

加载所述待加载UI服务和所述待加载UI服务的依赖。

2.根据权利要求1所述的方法，其特征在于，所述待加载UI服务的复用路径包括所述待加载UI服务所属UI服务包的模糊版本号。

3.根据权利要求1或2所述的方法，其特征在于，所述依赖图是基于所述至少一个UI服务包中的部分或全部的UI服务包的依赖关系集得到的。

4.根据权利要求3所述的方法，其特征在于，所述依赖关系集包括所述部分或全部的UI服务包中的至少一个UI服务的依赖关系；其中，所述部分或全部的UI服务包中的至少一个UI服务的依赖关系，用于指示所述部分或全部的UI服务包中的至少一个UI服务的依赖。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述至少一个UI服务包中的任一个UI服务的代码包括复用路径；所述任一个UI服务的代码中的复用路径，用于指示所述任一个UI服务的依赖的访问路径。

6.根据权利要求1至5中任一项所述的方法，其特征在于，所述至少一个UI服务包是在至少一个UI服务包注册装置中注册的UI服务包。

7.根据权利要求6所述的方法，其特征在于，所述至少一个UI服务包包括第一UI服务包，所述第一UI服务包中的第一UI服务的代码中的复用路径，满足如下条件中的至少一种：所述第一UI服务的代码中的复用路径，用于指示第二UI服务的访问路径，所述第二UI服务是所述第一UI服务的依赖，所述第二UI服务是第二UI服务包中的任一个UI服务，所述第二UI服务包是不同于所述第一UI服务包的UI服务包；或者，

所述第一UI服务的代码中的复用路径，用于指示运行时依赖项的访问路径，所述运行时依赖项是所述第一UI服务的依赖，所述运行时依赖项是至少一个公共依赖UI服务包中的任一个运行时依赖项，所述至少一个公共依赖UI服务包包括至少一个运行时依赖项，所述至少一个公共依赖UI服务包用于为在所述至少一个UI服务包注册装置中注册的至少一个UI服务包中的UI服务提供依赖；

其中，所述第一UI服务包是所述至少一个UI服务包中的任一个UI服务包，所述第一UI服务是所述第一UI服务包中的任一个UI服务。

8.根据权利要求1至7中任一项所述的方法，其特征在于，所述根据所述依赖图确定所述待加载UI服务的依赖，包括：

根据所述依赖图确定所述待加载UI服务的依赖的复用路径。

9.根据权利要求8所述的方法，其特征在于，在所述加载所述待加载UI服务和所述待加载UI服务的依赖之前，所述方法还包括：

基于所述待加载UI服务的复用路径和所述待加载UI服务的依赖的复用路径，并行的下载所述待加载UI服务和所述待加载UI服务的依赖；

所述加载所述待加载UI服务和所述待加载UI服务的依赖包括：

加载已下载的所述待加载UI服务和所述待加载UI服务的依赖。

10.根据权利要求9所述的方法，其特征在于，所述加载已下载的所述待加载UI服务和所述待加载UI服务的依赖，包括：

按照所述依赖图指示的依赖关系，按序加载已下载的所述待加载UI服务和所述待加载UI服务的依赖。

11.根据权利要求7至10中任一项所述的方法，其特征在于，所述方法还包括：

如果所述待加载UI服务的依赖是运行时依赖项，则在加载所述至少一个UI服务和所述待加载UI服务的依赖的过程中，首次加载所述运行时依赖项时，启动所述运行时依赖项的驱动。

12.根据权利要求1至11中任一项所述的方法，其特征在于，所述方法还包括：

更新所述依赖图。

13.根据权利要求1至12中任一项所述的方法，其特征在于，若所述加载装置包括第一加载装置与第二加载装置，则所述第一加载装置与所述第二加载装置彼此隔离，所述第一加载装置和所述第二加载装置均用于为一个软件系统加载UI服务。

14.一种生成用户界面UI服务包的方法，其特征在于，应用于生成UI服务包的装置；所述方法包括：

获取UI服务的代码；所述UI服务的代码中包括复用路径，所述复用路径用于指示所述服务的依赖的访问路径；

转化所述UI服务的代码，得到第一UI服务包，所述第一UI服务包包括至少一个UI服务。

15.根据权利要求14所述的方法，其特征在于，所述第一UI服务包中第一UI服务的代码中的复用路径，满足如下条件中的至少一种：所述第一UI服务的代码中的复用路径用于指示第二UI服务的访问路径，所述第二UI服务是所述第一UI服务的依赖，所述第二UI服务是第二UI服务包中的任一个UI服务，所述第二UI服务包是不同于所述第一UI服务包的UI服务包；或者，

所述第一UI服务的代码中的复用路径用于指示运行时依赖项的访问路径，所述运行时依赖项是所述第一UI服务的依赖，所述运行时依赖项是至少一个公共依赖UI服务包中的任一个运行时依赖项，所述至少一个公共依赖UI服务包包括至少一个运行时依赖项，所述至少一个公共依赖UI服务包用于为在至少一个UI服务包注册装置中注册的至少一个UI服务包中的UI服务提供依赖；

其中，所述第一UI服务是所述第一UI服务包中的任一个UI服务。

16.根据权利要求15所述的方法，其特征在于，所述第一UI服务的代码中的复用路径包括模糊版本号，所述模糊版本号用于指示满足预设版本条件的所述第二UI服务包或所述至少一个公共依赖UI服务包。

17.根据权利要求14至16中任一项所述的方法，其特征在于，所述UI服务的代码是基于开发框架编写的；

所述转化所述UI服务的代码，得到第一UI服务包，包括：

通过所述开发框架转化所述UI服务的代码，得到所述第一UI服务包。

18.根据权利要求17所述的方法，其特征在于，所述第二UI服务包或所述公共依赖UI服务包是基于所述开发框架得到的。

19.根据权利要求17或18所述的方法，其特征在于，所述通过所述开发框架转化所述UI服务的代码，得到所述第一UI服务包，包括：

基于预设的配置文件，通过所述开发框架转化所述UI服务的代码，得到所述第一UI服务包；其中，所述配置文件用于指示所述第一UI服务包的类型，所述类型用于表示所述第一UI服务包的用途。

20.根据权利要求19所述的方法，其特征在于，所述第一UI服务包的类型包括以下至少一种：业务UI服务包、实现加载装置功能的UI服务包或公共依赖UI服务包。

21.根据权利要求14至20中任一项所述的方法，其特征在于，所述方法还包括：

发布所述第一UI服务包的注册信息，所述注册信息包括所述第一UI服务包的名称和用于部署所述第一UI服务包的网络地址，所述注册信息用于在至少一个UI服务包注册装置中注册所述第一UI服务包。

22.根据权利要求14至21中任一项所述的方法，其特征在于，所述第一UI服务包包括第一依赖关系集；其中，所述第一依赖关系集包括所述第一UI服务包中至少一个UI服务的依赖关系；其中，所述依赖关系用于指示所述第一UI服务包中至少一个UI服务的依赖。

23.根据权利要求22所述的方法，其特征在于，所述方法还包括：

向所述至少一个UI服务包注册装置发送所述第一依赖关系集，所述至少一个UI服务包注册装置用于注册所述第一UI服务包。

24.根据权利要求14至23中任一项所述的方法，其特征在于，所述方法还包括：

更新所述第一UI服务包；其中，更新后的所述第一UI服务包包括第二依赖关系集，所述第二依赖关系集包括更新后的所述第一UI服务包中至少一个UI服务的依赖关系。

25.根据权利要求24所述的方法，其特征在于，所述方法还包括：

向所述至少一个UI服务包注册装置发送所述第二依赖关系集。

26.根据权利要求14至25中任一项所述的方法，其特征在于，所述第一UI服务中全部或部分的UI服务允许被引用为依赖。

27.一种注册用户界面UI服务包的方法，其特征在于，应用于UI服务包注册装置，所述方法包括：

获取第一UI服务包的注册信息，所述注册信息包括所述第一UI服务包的名称和用于部署所述第一UI服务包的网络地址；

将所述注册信息添加至所述UI服务包注册装置的注册列表中；

其中，所述第一UI服务包中的第一UI服务的代码包括复用路径，所述复用路径用于指示所述第一UI服务的依赖的访问路径；所述第一UI服务是所述第一UI服务包中的任一个UI服务。

28.根据权利要求27所述的方法，其特征在于，所述复用路径满足如下条件中的至少一种：所述复用路径用于指示第二UI服务的访问路径，所述第二UI服务是所述第一UI服务的依赖，所述第二UI服务是第二UI服务包中的任一个UI服务，所述第二UI服务包是不同于所述第一UI服务包的UI服务包；或者，

所述复用路径用于指示运行时依赖项的访问路径，所述运行时依赖项是所述第一UI服务的依赖，所述运行时依赖项是至少一个公共依赖UI服务包中的任一个运行时依赖项，所述至少一个公共依赖UI服务包包括至少一个运行时依赖项，所述至少一个公共依赖UI服务包用于为在至少一个UI服务包注册装置中注册的至少一个UI服务包中的UI服务提供依赖。

29.根据权利要求27或28所述的方法，其特征在于，所述复用路径包括所述第一UI服务包的模糊版本号。

30.根据权利要求27至29中任一项所述的方法，其特征在于，所述方法还包括：

获取所述第一UI服务包的依赖关系集，所述依赖关系集包括所述第一UI服务包中至少一个UI服务的依赖关系；其中，所述第一UI服务的依赖关系用于指示所述第一UI服务的依赖。

31.根据权利要求30所述的方法，其特征在于，所述获取所述第一UI服务包的依赖关系集，包括：

基于所述网络地址，周期性的从所述第一UI服务包中获取所述依赖关系集。

32.根据权利要求30所述的方法，其特征在于，所述获取所述第一UI服务包的依赖关系集，包括：

接收生成所述第一UI服务包的装置发送的依赖关系集。

33.根据权利要求27至32任一项的所述的方法，其特征在于，所述方法还包括：

基于所述注册信息和所述第一UI服务包的版本号，生成所述第一UI服务包中至少一个UI服务的初始复用路径，所述初始复用路径包括所述第一UI服务包的版本号。

34.根据权利要求33所述的方法，其特征在于，所述初始复用路径用于确定所述第一UI服务包中至少一个UI服务的复用路径，所述初始复用路径和所述复用路径，均用于指示所述第一UI服务包中至少一个UI服务的访问路径。

35.一种加载用户界面UI服务的装置，其特征在于，所述装置包括：

接收单元，用于接收加载请求，所述加载请求用于请求加载待加载UI服务，所述加载请求中包括所述待加载UI服务的复用路径，所述待加载UI服务的复用路径用于指示所述待加载UI服务的访问路径；

确定单元，用于根据依赖图确定所述待加载UI服务的依赖，所述依赖图指示至少一个UI服务包中的至少一个UI服务的依赖，以及指示将所述至少一个UI服务包中的任一个UI服务引用为依赖的UI服务；

加载单元，用于加载所述待加载UI服务和所述待加载UI服务的依赖。

36.根据权利要求35所述的装置，其特征在于，所述待加载UI服务的复用路径包括所述待加载UI服务所属UI服务包的模糊版本号。

37.根据权利要求35或36所述的装置，其特征在于，所述依赖图是基于所述至少一个UI服务包中的部分或全部的UI服务包的依赖关系集得到的。

38.根据权利要求37所述的装置，其特征在于，所述依赖关系集包括所述部分或全部的UI服务包中的至少一个UI服务的依赖关系；其中，所述部分或全部的UI服务包中的至少一个UI服务的依赖关系，用于指示所述部分或全部的UI服务包中的至少一个UI服务的依赖。

39.根据权利要求35至38中任一项所述的装置，其特征在于，所述至少一个UI服务包中的任一个UI服务的代码包括复用路径；所述任一个UI服务的代码中的复用路径，用于指示所述任一个UI服务的依赖的访问路径。

40.根据权利要求35至39中任一项所述的装置，其特征在于，所述至少一个UI服务包是在至少一个UI服务包注册装置中注册的UI服务包。

41.根据权利要求40所述的装置，其特征在于，所述至少一个UI服务包包括第一UI服务包，所述第一UI服务包中的第一UI服务的代码中的复用路径，满足如下条件中的至少一种：所述第一UI服务的代码中的复用路径，用于指示第二UI服务的访问路径，所述第二UI服务是所述第一UI服务的依赖，所述第二UI服务是第二UI服务包中的任一个UI服务，所述第二UI服务包是不同于所述第一UI服务包的UI服务包；或者，

所述第一UI服务的代码中的复用路径，用于指示运行时依赖项的访问路径，所述运行时依赖项是所述第一UI服务的依赖，所述运行时依赖项是至少一个公共依赖UI服务包中的任一个运行时依赖项，所述至少一个公共依赖UI服务包包括至少一个运行时依赖项，所述至少一个公共依赖UI服务包用于为在所述至少一个UI服务包注册装置中注册的至少一个UI服务包中的UI服务提供依赖；

其中，所述第一UI服务包是所述至少一个UI服务包中的任一个UI服务包，所述第一UI服务是所述第一UI服务包中的任一个UI服务。

42.根据权利要求35至41中任一项所述的装置，其特征在于，

所述确定单元，具体用于根据所述依赖图确定所述待加载UI服务的依赖的复用路径。

43.根据权利要求42所述的装置，其特征在于，所述装置还包括：

下载单元，用于在所述加载单元加载所述待加载UI服务和所述待加载UI服务的依赖之前，基于所述待加载UI服务的复用路径，以及所述确定单元确定的所述待加载UI服务的依赖的复用路径，并行的下载所述待加载UI服务和所述待加载UI服务的依赖；

所述加载单元，具体用于加载所述下载单元已下载的所述待加载UI服务和所述待加载UI服务的依赖。

44.根据权利要求43所述的装置，其特征在于，

所述加载单元，还具体用于按照所述依赖图指示的依赖关系，按序加载所述下载单元已下载的所述待加载UI服务和所述待加载UI服务的依赖。

45.根据权利要求41至44中任一项所述的装置，其特征在于，所述装置还包括：

启动单元，用于如果所述依赖是运行时依赖项，则在所述加载单元加载所述至少一个UI服务和所述依赖的过程中，首次加载所述运行时依赖项时，启动所述运行时依赖项的驱动。

46.根据权利要求35至45中任一项所述的装置，其特征在于，所述装置还包括：

更新单元，用于更新所述依赖图。

47.根据权利要求35至46中任一项所述的装置，其特征在于，若所述装置包括第一加载装置与第二加载装置，则所述第一加载装置与所述第二加载装置彼此隔离，所述第一加载装置和所述第二加载装置均用于为一个软件系统加载UI服务。

48.一种生成用户界面UI服务包的装置，其特征在于，所述装置包括：

获取单元，用于获取UI服务的代码；所述UI服务的代码中包括复用路径，所述复用路径用于指示所述服务的依赖的访问路径；

转化单元，用于转化所述获取单元获取的UI服务的代码，得到第一UI服务包，所述第一UI服务包包括至少一个UI服务。

49.根据权利要求48所述的装置，其特征在于，所述第一UI服务包中第一UI服务的代码中的复用路径，满足如下条件中的至少一种：所述第一UI服务的代码中的复用路径用于指示第二UI服务的访问路径，所述第二UI服务是所述第一UI服务的依赖，所述第二UI服务是第二UI服务包中的任一个UI服务，所述第二UI服务包是不同于所述第一UI服务包的UI服务包；或者，

所述第一UI服务的代码中的复用路径用于指示运行时依赖项的访问路径，所述运行时依赖项是所述第一UI服务的依赖，所述运行时依赖项是至少一个公共依赖UI服务包中的任一个运行时依赖项，所述至少一个公共依赖UI服务包包括至少一个运行时依赖项，所述至少一个公共依赖UI服务包用于为在至少一个UI服务包注册装置中注册的至少一个UI服务包中的UI服务提供依赖；

其中，所述第一UI服务是所述第一UI服务包中的任一个UI服务。

50.根据权利要求49所述的装置，其特征在于，所述第一UI服务的代码中的复用路径包括模糊版本号，所述模糊版本号用于指示满足预设版本条件的所述第二UI服务包或所述至少一个公共依赖UI服务包。

51.根据权利要求48至50中任一项所述的装置，其特征在于，所述获取单元获取的UI服务的代码是基于开发框架编写的；

所述转化单元，具体用于通过所述开发框架转化所述获取单元获取的UI服务的代码，得到所述第一UI服务包。

52.根据权利要求51所述的装置，其特征在于，所述第二UI服务包或所述公共依赖UI服务包是基于所述开发框架得到的。

53.根据权利要求51或52所述的装置，其特征在于，

所述转化单元，具体用于基于预设的配置文件，通过所述开发框架转化所述获取单元获取的UI服务的代码，得到所述第一UI服务包；其中，所述配置文件用于指示所述第一UI服务包的类型，所述类型用于表示所述第一UI服务包的用途。

54.根据权利要求53所述的装置，其特征在于，所述第一UI服务包的类型包括以下至少一种：业务UI服务包、实现加载装置功能的UI服务包或公共依赖UI服务包。

55.根据权利要求48至54中任一项所述的装置，其特征在于，所述装置还包括：

发送单元，用于发布所述第一UI服务包的注册信息，所述注册信息包括所述第一UI服务包的名称和用于部署所述第一UI服务包的网络地址，所述注册信息用于在至少一个UI服务包注册装置中注册所述第一UI服务包。

56.根据权利要求48至55中任一项所述的装置，其特征在于，所述第一UI服务包包括第一依赖关系集；其中，所述第一依赖关系集包括所述第一UI服务包中至少一个UI服务的依赖关系；其中，所述依赖关系用于指示所述第一UI服务包中至少一个UI服务的依赖。

57.根据权利要求56所述的装置，其特征在于，

所述发送单元，还用于向所述至少一个UI服务包注册装置发送所述第一依赖关系集，所述至少一个UI服务包注册装置用于注册所述第一UI服务包。

58.根据权利要求48至57中任一项所述的装置，其特征在于，所述装置还包括：

更新单元，用于更新所述第一UI服务包；其中，更新后的所述第一UI服务包包括第二依赖关系集，所述第二依赖关系集包括更新后的所述第一UI服务包中至少一个UI服务的依赖关系。

59.根据权利要求58所述的装置，其特征在于，

所述发送单元，还用于向所述至少一个UI服务包注册装置发送所述第二依赖关系集。

60.根据权利要求48至59中任一项所述的装置，其特征在于，所述第一UI服务中全部或部分的UI服务允许被引用为依赖。

61.一种注册用户界面UI服务包的装置，其特征在于，所述装置包括：

获取单元，用于获取第一UI服务包的注册信息，所述注册信息包括所述第一UI服务包的名称和用于部署所述第一UI服务包的网络地址；

添加单元，用于将所述获取单元获取的注册信息添加至所述装置的注册列表中；

其中，所述第一UI服务包中的第一UI服务的代码包括复用路径，所述复用路径用于指示所述第一UI服务的依赖的访问路径；所述第一UI服务是所述第一UI服务包中的任一个UI服务。

62.根据权利要求61所述的装置，其特征在于，所述复用路径满足如下条件中的至少一种：所述复用路径用于指示第二UI服务的访问路径，所述第二UI服务是所述第一UI服务的依赖，所述第二UI服务是第二UI服务包中的任一个UI服务，所述第二UI服务包是不同于所述第一UI服务包的UI服务包；或者，

所述复用路径用于指示运行时依赖项的访问路径，所述运行时依赖项是所述第一UI服务的依赖，所述运行时依赖项是至少一个公共依赖UI服务包中的任一个运行时依赖项，所述至少一个公共依赖UI服务包包括至少一个运行时依赖项，所述至少一个公共依赖UI服务包用于为在至少一个UI服务包注册装置中注册的至少一个UI服务包中的UI服务提供依赖。

63.根据权利要求61或62所述的装置，其特征在于，所述复用路径包括所述第一UI服务包的模糊版本号。

64.根据权利要求61至63中任一项所述的装置，其特征在于，

所述获取单元，还用于获取所述第一UI服务包的依赖关系集，所述依赖关系集包括所述第一UI服务包中至少一个UI服务的依赖关系；其中，所述第一UI服务的依赖关系用于指示所述第一UI服务的依赖。

65.根据权利要求64所述的装置，其特征在于，

所述获取单元，具体用于基于所述网络地址，周期性的从所述第一UI服务包中获取所述依赖关系集。

66.根据权利要求64所述的装置，其特征在于，

所述获取单元，具体用于接收生成所述第一UI服务包的装置发送的依赖关系集。

67.根据权利要求61至66中任一项所述的装置，其特征在于，所述装置还包括：

生成单元，用于基于所述获取单元获取的注册信息和所述第一UI服务包的版本号，生成所述第一UI服务包中至少一个UI服务的初始复用路径，所述初始复用路径包括所述第一UI服务包的版本号。

68.根据权利要求67所述的装置，其特征在于，所述初始复用路径用于确定所述第一UI服务包中至少一个UI服务的复用路径，所述初始复用路径和所述复用路径，均用于指示所述第一UI服务包中至少一个UI服务的访问路径。

69.一种软件系统，其特征在于，

所述软件系统包括如权利要求1至13中任一项所述的加载装置，以加载待加载UI服务；或者，

所述软件系统包括如权利要求14至26中任一项所述的生成UI服务包的装置，以生成UI服务包；或者，

所述软件系统包括如权利要求27至34中任一项所述的注册UI服务包的装置，以将UI服务包注册到软件系统的注册列表中。

70.一种芯片系统，其特征在于，所述芯片系统包括一个或多个接口电路和一个或多个处理器；

所述接口电路和所述处理器通过线路互联；所述接口电路用于从存储器接收信号，并向所述处理器发送所述信号，所述信号包括所述存储器中存储的计算机指令；所述处理器调用所述计算机指令，以执行如权利要求1至34中任一项所述的方法。

71.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序；当所述计算机程序在计算机上运行时，使得所述计算机执行权利要求1至34中任一项所述的方法。

72.一种计算机设备，其特征在于，包括处理器和存储器；

所述存储器上存储有计算机指令，所述处理器用于运行所述存储器上的计算机指令，以执行如权利要求1至34中任一项所述的方法。

Images