Application loading method and device, electronic equipment and storage medium

Abstract

The invention provides an application loading method and device, electronic equipment and a storage medium, relates to the technical field of application software, and can solve the problem of high application development cost caused by meeting customization requirements. The specific technical scheme is as follows: a first device obtains an application package of a target client from a second device; the first device responds to a module loading operation for a target module in the target client, and first configuration information corresponding to the target module in the first application file and second configuration information corresponding to the target module in the second application file are obtained. And the first device obtains target configuration information corresponding to the target module according to the first configuration information and the second configuration information. And the first device loads the target module according to the target configuration information. By implementing the scheme, the application package construction efficiency can be improved, the development cost can be reduced, and the flexibility of module configuration in the client is also improved.

Description

Technical Field

[0001] This application relates to the field of application software technology, and in particular to application loading methods, apparatus, electronic devices, and storage media. Background Technology

[0002] With the rapid development of mobile internet, providing customized clients for customers or user groups in different regions has become a common need.

[0003] Currently, a common method for implementing such customized clients is for developers to manually customize the client. Specifically, developers first need to obtain the client's source code, and then manually modify relevant information in the client's source code according to the user's specific needs, thereby generating the final customized client application package.

[0004] However, this method of building application packages is not only inefficient and requires developers to repeatedly develop, but also requires developers to manually modify the application package of each customized client when the original client is updated and iterated, which further increases development costs and reduces efficiency. Summary of the Invention

[0005] This application provides an application loading method, apparatus, electronic device, and storage medium, which can improve the efficiency of application package construction, reduce development costs, and increase the flexibility of module configuration in the client.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: Firstly, an application loading method is provided, comprising: a first device obtaining an application package for a target client from a second device. The first device can be a terminal device such as a personal computer, smartphone, tablet, or laptop, and the second device can be a server or similar device. The second device stores application packages for clients corresponding to multiple regions. The target client is the client corresponding to the region where the target user is located among the multiple region-corresponding clients. For example, if the target user is located in region A, then the target client is the client corresponding to region A.

[0007] Each client application package includes a first application file, and the target client application package also includes a second application file. The first application file stores basic configuration information for the modules of clients across multiple regions; this basic configuration information refers to configuration information common to clients in multiple regions. The second application file stores personalized configuration information for the modules of the target client; this personalized configuration information refers to configuration information specific to the client in the target user's region.

[0008] In response to a module loading operation targeting a target module in a target client, the first device obtains first configuration information corresponding to the target module in a first application file and second configuration information corresponding to the target module in a second application file. This module loading operation can be triggered when the user launches the target client, or it can be a specific interactive operation performed by the user within the target client.

[0009] The first device obtains the target configuration information corresponding to the target module based on the first configuration information and the second configuration information. The first device then loads the target module according to the target configuration information.

[0010] This solution, by storing client configuration information in two parts—basic configuration information and personalized configuration information—separates the standard application (i.e., the first application file) from the unique applications for each user group (i.e., the second application file) in the code engineering structure, reducing code coupling. The first application file stores common basic configuration information, which can be reused by clients in multiple regions, reducing development workload. The second application file stores only personalized configuration information specific to a particular region, allowing for flexible implementation of differentiated requirements from clients in different regions, thus improving configuration flexibility.

[0011] Furthermore, when loading the target module, the first device obtains the target configuration information based on the first and second configuration information, achieving dynamic integration of basic and personalized configuration information. This ensures consistency in general functions while meeting regional customization needs. Compared to developing separate clients for each region, this solution reduces application package development and maintenance costs and improves application package construction efficiency through layering and reuse of configuration information. When it is necessary to modify the common basic configuration information across regions, only the first application file needs to be modified; when it is necessary to modify the personalized configuration information of a specific region, only the corresponding second application file for that region needs to be modified, improving the convenience and accuracy of application updates.

[0012] In one possible implementation of the first aspect, obtaining the second configuration information corresponding to the target module in the second application file includes: obtaining the first relative path of the target module in the second application file from the first application file; and obtaining the second configuration information corresponding to the target module in the second application file based on the first relative path.

[0013] Here, the first relative path refers to the storage location path of the target module's second configuration information in the second application file. For example, the first relative path can be in the format of "deposit / remoteDepositMaintenance / index". By parsing the first application file, the first device can determine the specific storage location of the target module in the second application file, thereby locating and reading the second configuration information.

[0014] This solution establishes a relationship between the first and second application files by recording a first relative path in the first application file. This enables the first device to locate the personalized configuration information of the target module, improving the speed and accuracy of configuration information acquisition. Furthermore, using a relative path to record the location of the second configuration information makes the application package structure more flexible, facilitating application package migration and deployment.

[0015] In another possible implementation of the first aspect, the first configuration information includes multiple first methods. Obtaining target configuration information corresponding to the target module based on the first configuration information and the second configuration information includes: if the second configuration information includes a second method, using the second method in the second configuration information to override the first method corresponding to the second method in the first configuration information to obtain the target configuration information corresponding to the target module; if the second configuration information does not include a second method, using the first configuration information as the target configuration information corresponding to the target module.

[0016] The first method refers to the basic functional implementation method of the target module, and the second method refers to the implementation method of customized functions for a specific region. The number of first methods included in the first configuration information is greater than or equal to the number of second methods included in the second configuration information. The personalized configuration information only covers some methods that require customization, while methods that do not require customization continue to use the basic configuration information.

[0017] This solution ensures the stability of general functions while allowing for flexible implementation of customized needs in specific regions. Furthermore, in the event of updates to basic functions, the updated first application file can be automatically applied to the application packages of clients in all regions without affecting the customized features already implemented in each region, thus improving application maintainability.

[0018] In another possible implementation of the first aspect, before using the second method in the second configuration information to override the first method corresponding to the second method in the first configuration information, the method further includes: for each second method in the second configuration information, determining the first method in the first configuration information that has the same method name as the second method as the first method corresponding to the second method.

[0019] Here, the method name refers to the identifier of a method, used to uniquely identify a method. The first device can establish a correspondence between the method names of the second method and the first method by comparing them. For example, if the method name of the second method is "print", the first device will search for the first method with the method name "print" among the multiple first methods in the first configuration information and determine it as the first method corresponding to the second method.

[0020] By adopting this scheme, a correspondence between the second method and the first method is established through a method name matching mechanism, which can accurately identify the first method that needs to be overridden, thereby improving the reliability and accuracy of application loading.

[0021] In another possible implementation of the first aspect, the first method with the same method name as the second method in the first configuration information is determined as the first method corresponding to the second method, including: obtaining the class name of the target class corresponding to the second method; and determining the first method with the same method name as the second method among multiple first methods of a public class with the same class name as the target class, as the first method corresponding to the second method.

[0022] Here, the target class refers to the class in the second configuration information that contains the second method. This target class typically corresponds to a public class in the first configuration information. The public class refers to the class in the first configuration information that contains the first method; this public class is used to implement the basic functionality of the target module. The target class and the public class typically use the same class name to correspond to the same functional module.

[0023] This scheme improves the accuracy of method matching by using a dual matching mechanism of class name and method name. The method of searching for the class first and then the method can also improve search efficiency.

[0024] In another possible implementation of the first aspect, the method further includes: a second device acquiring a first application file; the second device acquiring a second application file for each of the multiple regions according to a second relative path indicated by a script file in the first application file; and the second device constructing an application package for the client corresponding to the region based on the first application file and the second application file for the region.

[0025] The script file refers to a file contained within the first application file that indicates the location of the second application file. This script file records the location information of the second application files for each region within the second device's storage system. The second relative path refers to the path of the second application file relative to the directory containing the script file. By parsing the script file, the second device can determine the location of the second application file for each region, thereby obtaining the corresponding second application file. It then packages the second application file with the first application file to construct the application package for the client corresponding to that region.

[0026] Using this solution, the second device can automatically build application packages for multiple regions based on a unified first application file and second application files for different regions. A unified build rule is established through the second relative path in the script file, standardizing and automating the application package building process. This eliminates the need to maintain a complete build process for each region, thus improving build efficiency. Simultaneously, the first application file includes basic configuration information shared by multiple regions, which can be directly reused when building application packages for different regions, avoiding redundant processing and further saving build time and computing resources. Therefore, when adding an application package for a new region, only the second application file for that region needs to be provided, and the corresponding path configuration needs to be added to the script file, enhancing the scalability of the application package building method.

[0027] In another possible implementation of the first aspect, the first application file and the second application files corresponding to the multiple regions are different files.

[0028] The first application file and the second application files for each region are independent of each other at the file level. For example, the first application file can be named AA, the second application file for region A can be named BB, and the second application file for region B can be named CC, which are three independent files.

[0029] This solution decouples configuration information at the physical storage level by storing basic configuration information and personalized configuration information in different files. This file separation design allows basic configuration information and personalized configuration information to be maintained and updated independently, improving application maintainability.

[0030] Secondly, an application loading device is provided, comprising: The application acquisition module is used for the first device to acquire the application package of the target client from the second device; the second device includes application packages of clients corresponding to multiple regions, and the target client is the client corresponding to the region where the target user is located among the multiple clients corresponding to multiple regions; each client's application package includes a first application file, and the target client's application package also includes a second application file. The first application file is used to store the basic configuration information of the modules of the clients corresponding to multiple regions, and the second application file is used to store the personalized configuration information of the modules of the target client. The configuration acquisition module is used by the first device to acquire the first configuration information corresponding to the target module in the first application file and the second configuration information corresponding to the target module in the second application file in response to the module loading operation for the target module in the target client. The configuration processing module is used by the first device to obtain the target configuration information corresponding to the target module based on the first configuration information and the second configuration information. The module loading module is used by the first device to load the target module according to the target configuration information.

[0031] Thirdly, an electronic device is provided, the method comprising: a memory and at least one processor. The memory is communicatively connected to the processor. The memory is used to store computer program code, the computer program code including computer instructions. When the processor executes the computer instructions, it causes the electronic device to perform the method as described in the first aspect and any possible implementation thereof.

[0032] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions. When executed by a processor, these computer instructions are used to implement the method described in the first aspect and any possible implementation thereof.

[0033] Fifthly, embodiments of this application provide a computer program product that, when run on a computer or executed by a computer's processor, implements the method described in the first aspect and any possible design thereof. The computer may be the electronic device described in the second aspect and any possible implementation thereof.

[0034] It is understood that the beneficial effects achieved by the application loading device described in the second aspect, the electronic device described in the third aspect, the computer-readable storage medium described in the fourth aspect, and the computer program product described in the fifth aspect can be referred to as the beneficial effects in the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of an application scenario involved in the application loading method provided in the embodiments of this application; Figure 2 A flowchart illustrating an application loading method provided in an embodiment of this application; Figure 3 A flowchart illustrating an application package construction method involved in the application loading method provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of an application loading device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an application building device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0036] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0037] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0038] The collection, storage, use, processing, transmission, provision, and disclosure of information such as regions involved in the technical solutions provided in this application comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0039] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0040] In the current software technology field, an application can serve multiple different user groups. For example, a rental system can serve multiple tenants, a housing provident fund management system can serve housing provident fund centers in multiple provinces and cities, and an e-commerce platform can serve users in multiple regions. Such software systems that serve multiple user groups can be called multi-tenant systems.

[0041] In multi-tenant systems, different user groups often have different needs. Even for the same basic function, different user groups may have different customized requirements. For example, customers from different regions or organizations may have different requirements for backend application system functions and frontend application client applications. Specifically, these client requirements may include differences in the overall page layout, partial page layout, and code logic.

[0042] In this context, overall page differences refer to completely different layouts and functionalities across the entire client application. For example, users in region A need to display five functional modules on their client application, while users in region B need to display seven functional modules, and the order and display method of these modules are also different.

[0043] Local page differences refer to variations in a specific display area or component within the client application. For example, users in area A might need a toolbar with three buttons displayed at the top of the client, while users in area B might need a toolbar with five buttons displayed at the top of the client, or they might need the toolbar's background color changed from blue to green.

[0044] Differences in code logic refer to differences in the specific business logic processing of the same function in the client. For example, for a data validation function, users in region A need to validate five fields, while users in region B need to validate seven fields, and the validation rules also differ.

[0045] Understandably, these customized needs from different user groups can emerge gradually during use. Therefore, developers cannot anticipate all user group customization needs during the initial client design phase and cannot develop a client fully compatible with all user groups' customization requirements. As more user groups join the multi-tenant system and more customized needs arise, how to dynamically and flexibly respond to and meet the customized needs of different user groups during client updates and iterations has become a pressing technical problem to be solved.

[0046] Currently, there are several technical solutions for handling different customization requirements of the same function in a client.

[0047] The first approach is to add logical conditional branches, such as if-else statements, to the client's source code to differentiate between the customized needs of different user groups. Specifically, developers add conditional statements to the client's source code to execute corresponding code logic based on the user group the current user belongs to. For example, the following logical condition could be added to the client's source code: if the current user belongs to region A, execute logic A; if the current user belongs to region B, execute logic B; if the current user belongs to region C, execute logic C.

[0048] However, as the number of users increases, the number of conditional branches in the client's source code also increases, leading to high code coupling and reduced readability and maintainability. For example, if the client needs to meet the customization requirements of 10 different user groups, ten conditional branches need to be added to the client's source code. Furthermore, when modifying the customization requirements of a particular user group, developers need to locate the corresponding code branch within complex logical decision branches, increasing development complexity. Moreover, the customization requirements of different user groups may overlap, meaning that modifying the code corresponding to the customization requirements of one user group may prevent the customization requirements of other user groups from being properly met.

[0049] The second approach is to develop a new client for each user group with customization needs, based on the existing client's source code. Specifically, when a user group requests customization, the developers create a separate copy of the client's source code for that group, modify the copy, and obtain a new client to meet that user group's customization requirements.

[0050] However, even if there are only minor differences between different user groups, a new client still needs to be developed, resulting in a significant amount of redundant development work. Furthermore, common functionalities across user groups cannot be reused. When a standard function shared by all user groups needs updating, each user group's client must be modified separately, making a unified update impossible. For example, if 8 out of 10 user groups use the same data query function, and this function needs updating, developers would need to modify 8 different clients, resulting in a large workload and a higher error rate.

[0051] The third approach is for developers to redesign the client-side modules based on the new customization requirements. The redesigned modules would then be compatible with both existing and new customization needs. However, compared to designing a single module to meet only one requirement, designing a module compatible with multiple requirements is more complex, involves more development work, and may even cause previously working functions to malfunction.

[0052] In summary, none of the three existing technical solutions can solve the problem of excessive workload in meeting customization needs, resulting in high development costs and low development efficiency.

[0053] Based on this, embodiments of this application provide an application loading method. This method divides the client's file structure into two parts: a first application file and a second application file. The first application file stores basic configuration information shared by all user groups, while the second application file stores personalized configuration information for a specific user group. When it is necessary to load a target module from the client, the basic configuration information of the target module in the first application file and the personalized configuration information in the second application file are read simultaneously. Then, the final target configuration information is obtained based on the basic configuration information and the personalized configuration information, and the module is loaded according to this target configuration information.

[0054] This method, by storing client configuration information in two parts—basic configuration information and personalized configuration information—separates the standard application (i.e., the first application file) from the unique applications for each user group (i.e., the second application file) in the code engineering structure, reducing code coupling. The first application file stores common basic configuration information, which can be reused by clients in multiple regions, reducing development workload. The second application file stores only personalized configuration information specific to a particular region, allowing for flexible implementation of differentiated requirements from clients in different regions, thus improving configuration flexibility.

[0055] Furthermore, when loading the target module, the first device obtains the target configuration information based on the first and second configuration information, achieving dynamic integration of basic and personalized configuration information. This ensures consistency in general functions while meeting regional customization needs. Compared to developing separate clients for each region, this solution reduces application package development and maintenance costs and improves application package construction efficiency through layering and reuse of configuration information. When it is necessary to modify the common basic configuration information across regions, only the first application file needs to be modified; when it is necessary to modify the personalized configuration information of a specific region, only the corresponding second application file for that region needs to be modified, improving the convenience and accuracy of application updates.

[0056] This application loading method involves a first device and a second device. The first device refers to the device running the target client, such as a user's terminal device, including personal computers, smartphones, tablets, laptops, etc. The second device refers to the device providing the application package for the target client, such as a server.

[0057] For ease of explanation, in this embodiment, the customized needs of user groups within a region can be referred to as "regional customized needs," and the clients developed in a region to meet these customized needs can be referred to as "region-specific clients." It should be understood that the region in this embodiment can be considered as a region comprised of user groups. This region can be a geographical area, such as city A, city B, and city C; an organizational area, such as company A, company B, and company C; or a business area, such as business area A, business area B, and business area C. Each region corresponds to one client, and each client corresponds to one application package.

[0058] In this embodiment, the second device stores application packages for clients corresponding to multiple regions. An application package refers to a collection of files used to install and run the client. When the client refers to a front-end application, the application package may include Hypertext Markup Language (HTML) files, Cascading Style Sheets (CSS) files, JavaScript files, image files, configuration files, etc. Each client's application package includes a first application file, and some client application packages also include a second application file.

[0059] The first application file is the file that stores the basic configuration information of the modules for clients across all regions. Basic configuration information refers to common configuration information shared by clients across multiple regions, such as common function codes, common components, and common data processing logic. The first application file may include multiple sub-files, each corresponding to a different module within the client. For example, the first application file may include a basic configuration file for a user management module, a basic configuration file for a data query module, and a basic configuration file for a report generation module.

[0060] The second application file refers to a file that stores personalized configuration information for the client modules corresponding to a specific region. Personalized configuration information refers to configuration information unique to the client in the target user's region, such as region-specific function code, customized components, and customized data processing logic. The second application file can also include multiple sub-files, each corresponding to a different module in the client. It's important to note that not all client application packages for all regions include a second application file; only application packages for clients in regions with customization requirements include a second application file.

[0061] Please see Figure 1 , Figure 1 This is a schematic diagram of an application scenario involving the application loading method provided in this application embodiment. Multiple user terminals 101 are terminal devices of users in different regions. These terminal devices may refer to the first device in the above embodiment. Each terminal device 101 is communicatively connected to a server 102, which may refer to the second device in the above embodiment. The terminal device 101 can obtain the application package of the client corresponding to the user's region from the server 102. It should be understood that when different users are located in different regions, the application packages obtained by the corresponding terminal devices 101 will also be application packages of different clients.

[0062] Next, the application loading method provided in this application will be described in detail.

[0063] Please see Figure 2 , Figure 2 This is a flowchart illustrating an application loading method provided in an embodiment of this application. Figure 2 As shown, the method includes the following steps: S201, the first device obtains the application package of the target client from the second device.

[0064] Among them, the target client is the client corresponding to the region where the target user is located among multiple regions of clients.

[0065] In this embodiment, the target user refers to the user currently using the first device. The target user's location refers to the geographical area, organizational area, or business area to which the user belongs. For example, in the case of a multi-tenant system that is a housing provident fund management system, the target user can be an employee of a municipal housing provident fund center, and the target user's location can refer to the geographical area of ​​that city or the business area corresponding to the municipal housing provident fund center. In the case of a multi-tenant system that is a rental system, the target user can be an employee of a company, and the employee's location can refer to the organizational area to which the tenant belongs, i.e., the company.

[0066] Before acquiring the application package from the target client, the first device needs to determine the target user's region. In one implementation, the first device determines the target user's region through user login information. Specifically, when the user logs in, they enter their username and password. The first device sends the login information to a second device for authentication. The second device determines the user's region based on their account information and returns the region information to the first device. In another implementation, the first device determines the target user's region through a user selection action. Specifically, the first device displays multiple region options on the login screen. The first device detects the user's selection of one of the region options and can record the selected region.

[0067] After determining the target user's location, the first device sends an application package retrieval request to the second device. This request may include identification information about the target user's location. Upon receiving the application package retrieval request, the second device, based on the location identification information, selects the application package for the target client corresponding to the target user's location from a stored list of application packages for clients corresponding to multiple regions, and then sends the target client's application package to the first device.

[0068] It should be noted that the client application packages corresponding to the multiple regions stored in the second device are pre-built. Each client application package for each region includes a first application file, and the client application packages for regions with customization requirements also include a second application file.

[0069] After obtaining the target client's application package, the first device installs the application package onto itself. The installation process includes steps such as decompressing the application package, extracting application files, and configuring the runtime environment. Once installation is complete, the first device can run the target client.

[0070] S202, the first device responds to the module loading operation for the target module in the target client by obtaining the first configuration information corresponding to the target module in the first application file and the second configuration information corresponding to the target module in the second application file.

[0071] In this embodiment, the target module refers to the functional module that needs to be loaded in the target client. The client typically includes multiple functional modules, each used to implement a specific business function. For example, in the client of a housing provident fund management system, it may include a user management module, a data query module, a report generation module, a business processing module, etc.

[0072] A module loading operation refers to the operation that triggers the first device to load a target module. In one implementation, the module loading operation is an interactive operation on the client's user interface. For example, the module loading operation is a click on a function button on the client's user interface to trigger the loading of the corresponding function module. In another implementation, the module loading operation is a client startup operation. For example, the first device receives a startup operation, can start the client, and automatically load necessary modules such as the homepage module and navigation bar module upon startup.

[0073] Upon detecting a module loading operation targeting the target module, the first device begins acquiring the configuration information corresponding to the target module. This configuration information may include, but is not limited to, the target module's code logic, interface layout, data processing rules, and interaction methods.

[0074] The first device first obtains the first configuration information corresponding to the target module from the first application file. The first configuration information is the basic configuration information of the target module, including the functional code, component definitions, and data structures common to all regions of the target module. The first application file may include multiple sub-files, each corresponding to the basic configuration information of a functional module. Based on the identification information of the target module, the first device locates the corresponding sub-file in the first application file and reads its contents to obtain the first configuration information.

[0075] The first application file may include configuration files corresponding to each functional module. Specifically, the first application file may include configuration files describing the module structure, configuration files defining the module interfaces, configuration files setting module parameters, etc.

[0076] If the target client's application package includes a second application file, the first device also needs to obtain the second configuration information corresponding to the target module from the second application file. The second configuration information is the personalized configuration information of the target module for the target user's region, including customized function code, customized components, and customized data processing logic for that region. The organizational structure of the second application file can correspond to that of the first application file, and may also include multiple sub-files, each sub-file corresponding to the personalized configuration information of a functional module.

[0077] It should be noted that not all modules in the target client have corresponding second configuration information in the second application file. If a module does not have customization requirements in the target user's region, the second application file may not contain the second configuration information for that module. In this case, the first device can only obtain the first configuration information for that module from the first application file.

[0078] In one implementation, if the application package of the target client does not include the second application file, it indicates that there is no customization requirement in the region where the target user is located, and the first device can obtain the first configuration information corresponding to the target module only from the first application file.

[0079] In some embodiments, the process by which the first device obtains the second configuration information corresponding to the target module in the second application file may include the following steps: First, the first device obtains the first relative path of the target module in the second application file from the first application file. Then, the first device locates the configuration file corresponding to the target module in the second application file according to the first relative path, and reads the contents of the configuration file to obtain the second configuration information.

[0080] Here, the first relative path refers to the storage location path of the second configuration information of the target module in the second application file. This first relative path is a relative path based on the root directory of the second application file. For example, if the root directory of the second application file is "hfms_zjyw_webapp / src / page", the first relative path for the second configuration information of a certain user management module could be "deposit / remoteDepositMaintenance / index". Then, the storage location path of the second configuration information of the target module in the second application file is the combination of the root directory of the second application file and the first relative path, i.e., "hfms_zjyw_webapp / src / page / deposit / remoteDepositMaintenance / index".

[0081] The first configuration information of each target module in the first application file contains the first relative path of each target module in the second application file, thereby realizing the dynamic loading of configuration information.

[0082] By pre-storing the first relative paths of each module in the second application file in the first application file, the first device can dynamically load the second configuration information. The first device does not need to obtain the path information of the second application file in advance, thereby improving the flexibility of configuration loading. If the directory structure of the second application file changes, only the first relative paths in the first application file need to be modified.

[0083] S203, the first device obtains the target configuration information corresponding to the target module based on the first configuration information and the second configuration information.

[0084] In this embodiment, the target configuration information refers to the configuration information that the first device ultimately uses to load the target module. This target configuration information can be obtained by fusing the first configuration information and the second configuration information.

[0085] In some embodiments, the first configuration information includes multiple first methods; if there are customization requirements corresponding to the region where the target user is located, the second configuration information includes second methods. Here, a method refers to a code unit used to implement a specific function. Each method typically includes components such as a method name, method parameters, and a method body. The method name identifies the method, the method parameters are the data required for the method to execute, and the method body is the specific execution logic of the method.

[0086] The first methods in the first configuration information are implementation methods for the basic functions of the target module, used to achieve functions that are common to all regions of the target module. For example, when the target module is a data query module, the first configuration information may include the following first methods: a first method for initializing the query interface, a first method for receiving query parameters, a first method for performing query operations, a first method for displaying query results, etc.

[0087] The second method in the second configuration information is a method for implementing customized functions for the target module in the target user's region. This second method is used to override or replace the corresponding first method in the first configuration information to meet the region's customization requirements. For example, if a region has customized requirements for the display of query results in the data query module, the second configuration information may include a second method for displaying query results, which implements the customized display method for that region.

[0088] When the second configuration information includes a second method, the first device uses the second method in the second configuration information to override the first method corresponding to that second method in the first configuration information, thereby obtaining the target configuration information corresponding to the target module. The number of first methods included in the first configuration information is greater than or equal to the number of second methods included in the second configuration information.

[0089] The first device using a second method to override the first method means replacing the first method with the second method, so that the functionality originally implemented by the first method in the target configuration information is now implemented by the second method. For example, the first configuration information includes a first method named "print," which implements query result printing logic common to all regions. The second configuration information also includes a second method named "print," which implements query result printing logic customized for the target user's region. When the first device obtains the target configuration information based on the first and second configuration information, it uses the "print" method in the second configuration information to override the "print" method in the first configuration information, so that the "print" method in the target configuration information implements the query result printing logic defined in the second configuration information.

[0090] It should be noted that the number of second methods in the second configuration information is usually less than the number of first methods in the first configuration information. This is because the second configuration information only includes methods that need to be customized, not all methods. For methods that do not require customization, the second configuration information may not include the corresponding second method, and the first method in the first configuration information can be used directly.

[0091] If the second configuration information does not include the second method, it indicates that the target module does not have customization requirements in the target user's region, and the first device can use the first configuration information as the target configuration information corresponding to the target module. In this case, the target configuration information is the same as the first configuration information, and the target module is loaded according to the basic configuration information common to all regions.

[0092] In one possible implementation, before using the second method in the second configuration information to override the first method corresponding to the second method in the first configuration information, the first device needs to determine the first method corresponding to the second method. Specifically, for each second method in the second configuration information, the first device determines the first method in the first configuration information that has the same method name as the second method as the first method corresponding to that second method.

[0093] A method name is an identifier used to distinguish different methods. In both the first and second configuration information, methods performing the same function use the same method name. For example, the method name for the first method in the first configuration information, which prints query results, is "print," and the method name for the second method in the second configuration information, which displays the query results, is also "print." By comparing the method names, the first device can determine the first method that needs to be overridden by the second method.

[0094] Specifically, the first device iterates through each second method in the second configuration information and obtains the method name of each second method. Then, the first device searches for a first method in the first configuration information whose method name is the same as that of the second method. If a first method with the same method name is found, the first device determines that the first method is the first method corresponding to the second method, that is, the second method will override the first method.

[0095] In one possible implementation, when determining the first method corresponding to the second method, the first device may compare the method's parameter list in addition to comparing the method name. The method's parameter list includes the types and number of parameters contained in the method. It should be understood that two methods with the same method name but different parameter lists are different methods.

[0096] Specifically, when searching for the first method corresponding to the second method, the first device compares not only the method name but also the method's parameter list. The first device searches the first configuration information for a first method whose method name and parameter list are identical to the second method. If a first method meeting these conditions is found, the first device determines that this first method is the first method corresponding to the second method.

[0097] By comparing the method name and parameter list simultaneously, the first method corresponding to the second method can be determined more accurately, avoiding incorrect matching caused by the same method name but different parameter lists.

[0098] In some embodiments, the methods in the first and second configuration information are defined within classes. In object-oriented programming, classes are used to encapsulate data and methods. A class can include multiple methods that collectively implement the functionality represented by the class. It should be understood that the class in this embodiment can be not limited to the "class" in code, but can also be other objects that can contain methods, such as "mixin" or "mixins".

[0099] The process by which the first device identifies the first method with the same method name as the second method in the first configuration information as the first method corresponding to the second method may include the following steps: First, the first device obtains the class name of the target class corresponding to the second method. Then, the first device identifies the first method with the same method name as the second method among multiple first methods of a public class with the same class name as the target class, and uses it as the first method corresponding to the second method.

[0100] Here, the target class refers to the class in the second configuration information that contains the second method. This target class typically corresponds to a public class in the first configuration information. The public class refers to the class in the first configuration information that contains the first method; this public class is used to implement the basic functionality of the target module. The target class and the public class typically use the same class name to correspond to the same functional module.

[0101] The first device first obtains the class name of the target class to which the second method belongs in the second configuration information. Then, the first device searches for a public class with the same class name as the target class in the first configuration information. If a public class with the same class name is found, the first device searches for a first method with the same method name as the second method among the multiple first methods of that public class, and identifies that first method as the first method corresponding to the second method.

[0102] By first determining the class name and then the method name, the corresponding first method to be overridden by the second method can be accurately located. This is because methods with the same name may exist in different classes, and matching only by method name may lead to matching errors. By matching the class name first and then the method name, the accuracy of the second method overriding the first method can be ensured.

[0103] In some embodiments, when the first device uses the second method to override the first method, it can employ a mixin mechanism to achieve method overriding. Mixin refers to the mechanism of copying the attributes and methods of one object to another. In the embodiments of this application, the first device can mix the second method defined in the second configuration information into the public class defined in the first configuration information, thereby achieving overriding of the first method in the public class.

[0104] Specifically, the first device iterates through all the second methods defined in the second configuration information. For each second method, the first device searches for the corresponding first method in the first configuration information. If a corresponding first method is found, the first device replaces the first method with the second method. If no corresponding first method is found, the first device adds the second method to the public class corresponding to the first configuration information as a new method of that public class.

[0105] The mixin mechanism enables more flexible method customization. It can not only override methods already present in the first configuration information, but also add new methods to the public class in the first configuration information, thereby extending the functionality of the public class.

[0106] S204, The first device loads the target module according to the target configuration information.

[0107] In this embodiment of the application, loading the target module means that the first device performs initialization, instantiation, and configuration operations on the target module according to the target configuration information, so that the target module can run on the first device and provide corresponding functions.

[0108] Specifically, the first device executes the initialization method defined in the target configuration information to initialize the target module. Then, the first device generates the user interface of the target module according to the interface layout information defined in the target configuration information and displays the user interface on the first device's screen. When an interaction operation between the user and the user interface of the target module is detected, the first device calls the corresponding method defined in the target configuration information to execute the corresponding business logic.

[0109] The above embodiments describe the steps involved in the first device obtaining the target client's application package from the second device and subsequent steps. Before the first device obtains the target client's application package from the second device, the second device needs to pre-build the application packages for the clients corresponding to each region. The process of the second device building the application packages is described below.

[0110] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating an application package construction method involved in the application loading method provided in this application embodiment.

[0111] S301, the second device obtains the first application file.

[0112] In this embodiment of the application, the first application file may be a pre-developed collection of files, which may contain sub-files corresponding to each functional module of the client, with each functional module corresponding to one or more sub-files.

[0113] The second device can obtain the first application file in several ways. For example, the developer may pre-store the first application file in the second device's storage system. Another example is that the second device pulls the first application file from a code management system. The second device obtains the latest version of the first application file by accessing the code management system.

[0114] S302, the second device obtains the second application file for each of the multiple regions according to the second relative path indicated by the script file in the first application file.

[0115] In this embodiment, the script file refers to a file contained within the first application file that indicates the location of the second application file. This script file records the location information of the second application files in each region within the storage system of the second device. The second relative path refers to the path of the second application file relative to the directory where the script file is located.

[0116] The second device reads the script file in the first application file and extracts the second relative path corresponding to each region from the script file. The script file may record the identification information of multiple regions and their corresponding second relative paths. For example, the script file may record the second relative path corresponding to region A as "hfms_zjyw_webapp / src / page" and the second relative path corresponding to region B as "hfms_zjls_webapp / src / page".

[0117] For each of the multiple regions, the second device locates the second application file for that region in its storage system based on the second relative path corresponding to that region. The second device then reads the file content at that location to obtain the second application file for that region.

[0118] It should be noted that not all regions have a second application file. If a region does not have customization requirements, the script file may not record the corresponding second relative path for that region, or the recorded second relative path may point to an empty directory. In this case, the second device will not be able to obtain the second application file for that region, or the obtained second application file will be empty.

[0119] In some embodiments, when the second device obtains a second application file for a certain region, it can first determine whether there is a customization requirement for that region. Specifically, the second device checks whether the script file records a second relative path corresponding to that region. If the script file records a second relative path corresponding to that region, the second device determines that there is a customization requirement for that region and obtains the second application file for that region according to the second relative path. If the script file does not record a second relative path corresponding to that region, the second device determines that there is no customization requirement for that region and may not obtain the second application file for that region.

[0120] In some embodiments, after obtaining the second application file, the second device can verify the second application file to ensure its integrity and correctness. For example, the second device can check whether the file format of the second application file conforms to a predefined specification, check whether there are syntax errors in the configuration information in the second application file, and check whether the resource files referenced in the second application file exist. If the second application file fails verification, the second device can record the error information and terminate the application package building process for that area.

[0121] S303, the second device constructs the application package for the client corresponding to the region based on the first application file and the second application file for the region.

[0122] In this embodiment, building an application package refers to the second device combining and packaging the first application file and the second application file to generate an application package file that can be installed and run by the first device. The application package file can be a compressed file, such as a ZIP file, a RAR file, or other format installation package file.

[0123] The second device builds a client application package for each region. Specifically, the second device merges the first application file with the second application file for that region. The merging operation may include copying the first and second application files to the same directory and saving them according to a predefined directory structure, thus isolating the first and second application files.

[0124] In one implementation, when building the application package, the second device can use the first application file as the base part of the application package and the second application file as an extension part. The second device creates a directory corresponding to the first application file in the root directory of the application package and copies all files from the first application file into that directory. Similarly, the second device creates a directory corresponding to the second application file in the root directory of the application package and copies all files from the second application file in that area into that directory.

[0125] In some embodiments, the second device may also perform compilation operations and resource optimization operations when building the application package. The compilation operation refers to the process of converting source code into executable code, and the resource optimization operation refers to the process of optimizing resource files in the application package. For example, the second device may compress image files to reduce their size.

[0126] After the build process is complete, the second device stores the generated application package file in the storage system. The second device can assign a corresponding region identifier to the application package file for each region, so that when the first device requests to obtain the application package later, the second device can determine the corresponding application package file based on the region identifier.

[0127] In some embodiments, the first application file and the second application files corresponding to each of the multiple regions are different files. That is, the first application file and the second application files for each region are independent of each other in the file system; they are stored in different directories or different files. Modifications to the first application file will not directly affect the second application files, and vice versa.

[0128] By setting the first and second application files to different files, physical isolation of configuration information can be achieved. This isolation method facilitates code management and maintenance. When it is necessary to modify the basic configuration information common to all regions, developers only need to modify the first application file, without needing to modify the second application files for each region. When it is necessary to modify the personalized configuration information for a specific region, developers only need to modify the second application file corresponding to that region, without needing to modify the first application file or the second application files for other regions.

[0129] In some embodiments, when building an application package, the second device can build it according to the configuration information in the build configuration file. The build configuration file is a configuration file used to guide the application package building process. This build configuration file can record application package version information, build parameters, dependent third-party library information, etc. The second device reads the build configuration file and performs the build operation according to the configuration information in the build configuration file.

[0130] In some embodiments, the second device can also build application packages for multiple regions in parallel. Specifically, the second device can build application packages for multiple regions simultaneously, rather than building them serially. The second device can allocate an independent build task for the application package building process for each region, and multiple build tasks can be executed in parallel. By using parallel building, the computing resources of the second device can be fully utilized, and the overall build time for application packages in multiple regions can be shortened.

[0131] In one possible implementation, the second device can verify the build result after the build is complete. Specifically, the second device can verify the generated application package, checking whether the application package is corrupted and whether it can be installed and run normally. If errors occur in the application package, the second device can record the error information and re-execute the build operation.

[0132] In this embodiment, the second device can automatically build application packages for multiple regions based on a unified first application file and second application files for different regions. A unified build rule is established through the second relative path in the script file, standardizing and automating the application package building process. This eliminates the need to maintain a complete build process for each region, thereby improving build efficiency. Simultaneously, the first application file includes basic configuration information shared by multiple regions, which can be directly reused when building application packages for different regions, avoiding redundant processing and further saving build time and computing resources. Therefore, when adding an application package for a new region, only the second application file for that region needs to be provided, and the corresponding path configuration needs to be added to the script file, enhancing the scalability of the application package building method.

[0133] Figure 4 This is a schematic diagram of an application loading device provided in an embodiment of this application. Figure 4 As shown, the application loading device includes: an application acquisition module 401, a configuration acquisition module 402, a configuration processing module 403, and a module loading module 404.

[0134] Application acquisition module 401 is used to acquire the application package of the target client from the second device; the second device includes application packages of clients corresponding to multiple regions, and the target client is the client corresponding to the region where the target user is located among the multiple clients corresponding to multiple regions; each client's application package includes a first application file, and the target client's application package also includes a second application file. The first application file is used to store the basic configuration information of the modules of the multiple clients corresponding to multiple regions, and the second application file is used to store the personalized configuration information of the modules of the target client. The configuration acquisition module 402 is used to respond to the module loading operation for the target module in the target client and acquire the first configuration information corresponding to the target module in the first application file and the second configuration information corresponding to the target module in the second application file. The configuration processing module 403 is used to obtain the target configuration information corresponding to the target module based on the first configuration information and the second configuration information; Module loading error 404, used to load the target module according to the target configuration information.

[0135] In some other embodiments, the configuration acquisition module 402 is further configured to acquire a first relative path of the target module in the second application file from the first application file; and acquire second configuration information corresponding to the target module in the second application file based on the first relative path.

[0136] In other embodiments, the first configuration information includes multiple first methods. The configuration processing module 403 is further configured to, when the second configuration information includes second methods, use the second methods in the second configuration information to overwrite the first methods corresponding to the second methods in the first configuration information to obtain target configuration information corresponding to the target module; wherein the number of first methods included in the first configuration information is greater than or equal to the number of second methods included in the second configuration information; and when the second configuration information does not include second methods, the first configuration information is used as the target configuration information corresponding to the target module.

[0137] In other embodiments, the application loading device may further include a method correspondence module, which is used to determine, for each second method in the second configuration information, a first method in the first configuration information that has the same method name as the second method as the first method corresponding to the second method.

[0138] In other embodiments, the module corresponding to the above method is further configured to obtain the class name of the target class corresponding to the second method; and among the multiple first methods of a public class with the same class name as the target class, determine the first method with the same method name as the second method as the first method corresponding to the second method.

[0139] The application loading device provided in this application embodiment can be the device in the first device described above, to execute the method executed by the first device as shown in the method embodiment above. Its implementation principle and beneficial effects can be referred to the relevant description in the method embodiment, and will not be repeated here.

[0140] Figure 5 This is a schematic diagram of an application building device provided in an embodiment of this application. Figure 5 As shown, the application building device includes: a file acquisition module 501, a path parsing module 502, and an application building module 503.

[0141] File acquisition module 501 is used to acquire the first application file; The path resolution module 502 is used to obtain the second application file of each of the multiple regions according to the second relative path indicated by the script file in the first application file.

[0142] Application building module 503 is used to build the application package of the client corresponding to the region based on the first application file and the second application file of the region.

[0143] In other embodiments, the first application file and the second application files corresponding to the multiple regions are different files.

[0144] The application building apparatus provided in this application embodiment can be the apparatus in the second device described above, to execute the method executed by the second device as shown in the method embodiment above. Its implementation principle and beneficial effects can be referred to the relevant description in the method embodiment, and will not be repeated here.

[0145] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device includes: a memory 601, a transceiver 602, and at least one processor 603.

[0146] The transceiver 602 is used to interact with other devices to send and receive data. For example, in this embodiment, the transceiver 602 can specifically be used to send and receive application packets.

[0147] The memory 601 stores computer program code, which includes computer instructions. These computer instructions run in the described electronic device to implement the method shown in the above-described method embodiments. For example, the memory may include high-speed random access memory (RAM), and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be a USB flash drive, portable hard drive, read-only memory, disk, or optical disc, etc.

[0148] Processor 603 can be a general-purpose processor, including a Central Processing Unit (CPU), a network processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 603 can also be other general-purpose processors. The general-purpose processor can be a microprocessor or any conventional processor.

[0149] The memory 601, transceiver 602, and processor 603 are communicatively connected. For example, the memory 601 and transceiver 602 can be connected to the processor 603 via a system bus and communicate with each other. The system bus can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, an industry standard architecture (ISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the figure, but this does not mean that there is only one bus or one type of bus.

[0150] Optionally, the memory 601 can be either standalone or integrated with the processor 603. When the memory 601 is set up independently, it is connected to the processor 603 via a system bus.

[0151] This application also provides a chip for executing instructions, which is used to execute the technical solution of the application loading method in the above embodiments.

[0152] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed by a processor, they are used to implement the technical solution of the loading method described in the above embodiments. Specifically, when the computer instructions are executed by a processor, the electronic device can perform the technical solution of the loading method described in the above embodiments.

[0153] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solution of the loading method applied in the above embodiments.

[0154] The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0155] An exemplary computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the computer-readable storage medium can exist as discrete components in an electronic control unit or main control device; this application does not limit this.

[0156] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0157] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0158] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0159] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0160] It should be understood that the steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0161] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0162] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. An application loading method, characterized in that, include: The first device obtains the application package of the target client from the second device; The second device includes application packages for clients corresponding to multiple regions. The target client is the client corresponding to the region where the target user is located among the multiple clients corresponding to multiple regions. Each client application package includes a first application file, and the target client application package also includes a second application file. The first application file is used to store basic configuration information of the modules of the multiple clients corresponding to multiple regions, and the second application file is used to store personalized configuration information of the modules of the target client. In response to a module loading operation for a target module in the target client, the first device obtains first configuration information corresponding to the target module in the first application file and second configuration information corresponding to the target module in the second application file; The first device obtains the target configuration information corresponding to the target module based on the first configuration information and the second configuration information; The first device loads the target module according to the target configuration information.

2. The application loading method according to claim 1, characterized in that, Obtaining the second configuration information corresponding to the target module in the second application file includes: Obtain the first relative path of the target module in the second application file from the first application file; Based on the first relative path, obtain the second configuration information corresponding to the target module in the second application file.

3. The application loading method according to claim 1, characterized in that, The first configuration information includes multiple first methods; The step of obtaining the target configuration information corresponding to the target module based on the first configuration information and the second configuration information includes: When the second configuration information includes a second method, the second method in the second configuration information is used to overwrite the first method corresponding to the second method in the first configuration information to obtain the target configuration information corresponding to the target module; wherein, the number of first methods included in the first configuration information is greater than or equal to the number of second methods included in the second configuration information; If the second configuration information does not include the second method, the first configuration information shall be used as the target configuration information corresponding to the target module.

4. The application loading method according to claim 3, characterized in that, Before using the second method in the second configuration information to override the first method corresponding to the second method in the first configuration information, the method further includes: For each second method in the second configuration information, the first method in the first configuration information that has the same method name as the second method is determined as the first method corresponding to the second method.

5. The application loading method according to claim 4, characterized in that, The step of identifying the first method in the first configuration information that has the same method name as the second method as the first method corresponding to the second method includes: Obtain the class name of the target class corresponding to the second method; Among the multiple first methods of a public class with the same class name as the target class, the first method with the same method name as the second method is determined as the first method corresponding to the second method.

6. The application loading method according to any one of claims 1-5, characterized in that, The method further includes: The second device acquires the first application file; The second device, for each of the multiple regions, obtains the second application file for that region according to the second relative path indicated by the script file in the first application file; The second device constructs an application package for the client corresponding to the region based on the first application file and the second application file of the region.

7. The application loading method according to claim 6, characterized in that, The first application file and the second application files corresponding to the multiple regions are different files.

8. An application loading device, characterized in that, include: The application acquisition module is used to acquire the application package of the target client from the second device. The second device includes application packages for clients corresponding to multiple regions. The target client is the client corresponding to the region where the target user is located among the multiple clients corresponding to multiple regions. Each client application package includes a first application file, and the target client application package also includes a second application file. The first application file is used to store basic configuration information of the modules of the multiple clients corresponding to multiple regions, and the second application file is used to store personalized configuration information of the modules of the target client. The configuration acquisition module is used to acquire, in response to a module loading operation for a target module in the target client, first configuration information corresponding to the target module in the first application file and second configuration information corresponding to the target module in the second application file; A configuration processing module is used to obtain target configuration information corresponding to the target module based on the first configuration information and the second configuration information; The module loading module is used to load the target module according to the target configuration information.

9. An electronic device, characterized in that, include: A memory and at least one processor; the memory is communicatively connected to the processor; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, When the computer program product is run on a computer / executed by the computer's processor, it implements the method as described in any one of claims 1 to 7.

Images