A method and system for collaborative loading of master and sub-packages for cross-platform JS applications

Abstract

This invention discloses a method and system for collaborative loading of master and sub-packages in cross-platform JavaScript applications, relating to the field of next-generation information technology. The method includes: during the compilation and unpacking stage, generating a structure list based on page ownership and package identifiers to record sub-package names, page routes, and their mapping relationships; and reusing the structure list during the publishing, host loading, and runtime execution stages, ensuring that page location, resource preparation, and script execution are based on the same set of identifier associations. This invention can reduce the scope of JavaScript code that needs to be loaded and executed in the first round and reduce the risk of loading failure due to inconsistencies in page ownership or package identifiers.

Description

Technical Field

[0001] This invention relates to the field of next-generation information technology industry technology, and more specifically, to a method and system for collaborative loading of master and sub-packages for cross-platform JS applications. Background Technology

[0002] In the field of next-generation information technology, existing cross-platform JavaScript application delivery solutions typically employ methods such as full package loading, code splitting based on front-end dynamic imports, or pre-preparing resources in modules by the host platform to adapt to different loading performance and resource management needs. However, in the mobile cross-platform JS runtime environment, metadata such as page ownership information, sub-package identifiers, and host resource configuration parameters generated during the compilation and unpacking phase lack a unified mapping with the runtime script loading entry point. This results in the correspondence between pages and sub-packages being scattered across different stages such as build and runtime, requiring additional logic at runtime to determine the sub-package to which the target resource belongs. Although the host side has the capability to prepare resources in modules, it cannot directly reuse compilation artifact information to determine the target to be loaded. At the same time, the lack of a unified identifier linking page jumps, dynamic imports, resource preloading, and script execution significantly increases the management complexity of the overall resource loading chain, making it difficult to guarantee loading efficiency and stability. Summary of the Invention

[0003] To address the aforementioned problems, the present invention aims to provide a master-sub-package collaborative loading method for cross-platform JS applications, applicable to the field of next-generation information technology industry technology, and to solve at least one of the problems in the background technology.

[0004] To achieve the above technical objectives, this application provides a main-sub-package collaborative loading method for cross-platform JS applications, applicable to the field of next-generation information technology industry technology, comprising the following steps: During the compilation and unpacking phase, a structure list is generated based on page ownership and package identifier to record sub-package names, page routes and their mapping relationships; During the publishing, host loading, and runtime execution phases, the structure manifest is reused so that page positioning, resource preparation, and script execution are based on the same set of identifier associations.

[0005] Preferably, when determining page ownership, the ownership relationship between the page and the main package and sub-package is established by reading the page information and sub-package information in the application configuration, thereby determining the page ownership.

[0006] Preferably, when generating package identifiers, after establishing the attribution relationship, a package identifier is generated for each sub-package that is consistently used in the build artifacts, runtime requests, and host load parameters.

[0007] Preferably, during the release phase, a download list is also generated to record the addresses, versions, or verification information required by the host to prepare the target sub-package resources.

[0008] Preferably, during the runtime phase, the structure list is queried to determine whether a corresponding sub-package exists, based on the target page routing or dynamically imported target. When the target sub-package is not yet ready, a sub-package loading request is sent to the host. The request carries the package identifier and corresponding loading parameters. The host completes local resource reading or remote resource acquisition based on the request, and returns the result to the runtime after the resource is available.

[0009] Preferably, during the runtime phase, in response to receiving the resource ready result, the target sub-package script is executed, and the loading status of the corresponding sub-package is updated.

[0010] Preferably, during the runtime phase, once the main package has been executed, the preparation and loading process is performed only on the target sub-package.

[0011] Preferably, in response to dynamic loading scenarios, the dynamic import request on the JS side is associated with the package identifier and converted into a sub-package loading request that can be recognized by the host, so that the dynamic import semantics are connected with the resource preparation capabilities of the mobile host.

[0012] Preferably, in response to scenarios involving built-in sub-packages within the client and runtime downloaded sub-packages, the setting of reusing the same package identifier and loading entry point is applied to both built-in sub-packages within the client and runtime downloaded sub-packages.

[0013] Based on the same inventive concept, this invention also discloses a master-sub-package collaborative loading system for cross-platform JS applications, applied in the field of next-generation information technology industry technology, comprising: The compilation module is used to generate a structure list during the compilation and unpacking stage, based on page ownership and package identifier, to record sub-package names, page routes and their mapping relationships; The collaborative loading module is used to reuse the structure manifest during the publishing, host loading, and runtime execution phases, so that page positioning, resource preparation, and script execution are based on the same set of identifier associations.

[0014] The present invention discloses the following technical effects: This invention can reduce the range of JS code that needs to be loaded and executed in the first round, and reduce the risk of loading failure due to inconsistent page ownership or package identification. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram illustrating the execution logic of the method described in this invention; Figure 2 This is a schematic diagram of the method described in this invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0018] like Figures 1-2 As shown, this invention provides a master-sub-package collaborative loading method for cross-platform JS applications, applicable to the field of next-generation information technology industry technology. The method includes four stages: compilation and unpacking, manifest generation, host resource preparation, and runtime execution.

[0019] For example, a cross-platform JS application refers to an application developed using JavaScript / TypeScript, where a single codebase can run simultaneously on Android, iOS, and HarmonyOS, with the UI driven by JS and rendered via Flutter self-drawing or native components.

[0020] In one implementation, during the compilation and unpacking stage, page information and sub-package information in the application configuration are read, the ownership relationship between pages and main packages and sub-packages is established, and a package identifier that is consistently used in the build artifacts, runtime requests, and host loading parameters is generated for each sub-package.

[0021] For example, the compilation phase generates a page configuration table / structure list and establishes the ownership relationship between pages or import targets and sub-packages based on the unified package identifier.

[0022] For example, the main package represents the basic package that must be downloaded, initialized, and executed when the application starts; the sub-package represents the code package that is lazily loaded, used to reduce the size and speed up the main package; the build artifact is the final file package that can be run directly after the code is compiled; the runtime request is the resource request initiated to the network / local during the application startup and operation; the host loading parameters are the parameters passed to the cross-platform framework when the container (host) starts the application; and the package identifier is a string ID used in the cross-platform sub-package system to uniquely identify, locate, request, and load the main package / sub-package.

[0023] In one implementation, based on the attribution relationship and package identifier, a structure manifest is generated during the compilation and unpacking stage to record sub-package names, page routes and their mapping relationships.

[0024] For example, in the sub-package architecture of cross-platform JS applications, the mapping relationship between the sub-package name, i.e. the package identifier, and the page route is the core technical association for realizing on-demand loading of sub-packages, host loading and location, and runtime request distribution. Its essence is to establish a one-to-one correspondence between "sub-package identifier and page resource path" through configuration conventions and framework parsing, which runs through the entire process of application building, running, and loading.

[0025] For example, the sub-package name (package identifier) ​​is a string identifier used to uniquely identify the sub-package. It has two core technical forms, both of which are defined by the developer in the configuration file and serve as the core basis for the framework to identify the sub-package.

[0026] For example, the root identifier in the subpackage name is a path identifier based on the project file system, corresponding to the absolute path of the subpackage in the project root directory. It is used to split and package the subpackage resources during the build process. The framework uses this path to package the pages, components, and static resources in the corresponding directory into independent subpackage artifacts.

[0027] For example, the name identifier in the sub-package name is a logical alias for the sub-package. It is used for sub-package requests, pre-downloading, and location during host loading at runtime. It has higher priority than the root identifier and can prevent sub-package location failure due to path changes.

[0028] For example, PageRoute is a unified resource path used to locate specific pages within an application. It adopts a hierarchical format of " / root path / subpackage path / page file name" and is the core location basis for the framework to implement page navigation and resource loading. It also contains subpackage identification information to associate with the corresponding subpackage.

[0029] For example, page routes are automatically generated by the framework during construction and are strongly associated with the sub-package root identifier. Their path structure must strictly match the project directory structure to ensure that the framework can quickly parse the corresponding sub-package identifier through the route at runtime.

[0030] For example, the mapping relationship refers to the mapping relationship between subpackage names and page routes. It is a technical association agreed upon through the subPackages node in the application configuration file. In essence, it is a one-to-many mapping of "subpackage identifier → all page routes under this subpackage". It is the core configuration basis for the framework to complete subpackage splitting, on-demand loading and host loading.

[0031] In one implementation, the technical features of the mapping relationship are uniqueness, relevance, and configurability. Uniqueness means that a page route can only map to one sub-package name, that is, a page belongs to only one sub-package, avoiding runtime sub-package location conflicts. Relevance means that the prefix of the page route is the root identifier of the corresponding sub-package. For example, the prefix "subpages / order" in " / subpages / order / list" is the sub-package root identifier, and the framework can quickly resolve the corresponding sub-package through the route prefix. Configurability means that the mapping relationship is declared through a configuration file and supports dynamic expansion. For example, when a new sub-package or page is added, updating the subPackages configuration will synchronously update the mapping relationship.

[0032] In one implementation, the construction of the mapping relationship includes three stages: a construction stage, a runtime request stage, and a host loading stage. The build phase involves build tools, such as application developer tools, parsing the mapping relationships in the subPackages configuration. Based on the subpackage root identifier, the pages, components, and static resources under the corresponding directory are split and packaged into independent subpackage artifacts. At the same time, the mapping relationship between page routes and subpackage identifiers is injected into the main package configuration, generating a "subpackage identifier-page route" mapping table for runtime calls. The runtime request phase occurs when the application triggers a page redirect or sub-package pre-download. The framework resolves the corresponding sub-package identifier (root / name) through the target page route, uses the sub-package identifier as the key, and initiates a network request for the sub-package resources to achieve on-demand loading of the sub-package.

[0033] The host loading phase occurs when the host loads a sub-package. By matching the sub-package identifier in the host loading parameters with the "sub-package identifier-page route" mapping table, the build artifact of the corresponding sub-package is located, the JS resources of the target sub-package are loaded, and the page is rendered by Flutter self-drawing or native components driven by the runtime.

[0034] In one embodiment, the present invention can also generate a download list during the release phase to record the addresses, versions, or verification information required by the host to prepare target sub-package resources.

[0035] In one implementation, during the runtime phase, the runtime queries the structure list to determine whether a corresponding sub-package exists, based on the target page routing or dynamically imported target.

[0036] For example, during the runtime phase, when the target sub-package is not yet ready, the runtime sends a sub-package loading request to the host, which carries the package identifier and corresponding loading parameters.

[0037] For example, during the runtime phase, the host completes local resource reading or remote resource acquisition based on the request, and returns the result to the runtime after the resource becomes available.

[0038] For example, during the runtime phase, after receiving the resource ready result, the runtime executes the target sub-package script and updates the loading status of the corresponding sub-package.

[0039] For example, during the runtime phase, in scenarios where the main package has already been executed, the runtime only performs the above preparation and loading process on the target sub-package.

[0040] In one embodiment, during the runtime phase, for dynamic loading scenarios, the present invention associates the dynamic import request on the JS side with the package identifier and converts it into a sub-package loading request that can be recognized by the host, so that the dynamic import semantics can be connected with the resource preparation capabilities of the mobile host.

[0041] For example, the JS side usually refers to the code execution layer based on the JavaScript language and running in the client-side host environment. Its core responsibility is to complete the interaction logic, view control, data preprocessing, and client state management on the user terminal.

[0042] For example, the JS side is responsible for page interaction, network requests, state management and view rendering. Its life cycle can be clearly divided into the release and build phase, the host loading phase and the runtime execution phase, with each phase having clear technical behaviors and constraints.

[0043] For example, the release build phase occurs on the server or build machine and is the process of transforming JS code from source code to executable artifacts; For example, the host loading phase refers to the process by which the container loads JS resources from the network and initializes the execution environment; it is the key phase from "network file" to "executable code".

[0044] For example, the runtime execution phase is the long-term running phase after the JS environment starts up, where it continuously responds to users and events. It is the core phase where the JS side truly undertakes the business logic.

[0045] For example, during the runtime phase, for in-client built-in sub-packages and runtime downloaded sub-packages, the present invention can reuse the same package identifier and loading entry point. The main difference lies in the different sources of resources on the host side.

[0046] In summary, compared to methods that only temporarily determine resource ownership during runtime, this invention brings page ownership and package identifiers forward to the compilation and unpacking stage, and reuses this information during the publishing, host loading, and runtime execution stages. This ensures that page location, resource preparation, and script execution are based on the same set of identifier associations. When the target page is located in a sub-package that has not been loaded, this invention can reduce the scope of JS code that needs to be loaded and executed in the first round, and reduce the risk of loading failure due to inconsistencies in page ownership or package identifiers.

[0047] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0048] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for collaborative loading of master and sub-packages in cross-platform JS applications, characterized in that, Includes the following steps: During the compilation and unpacking phase, a structure list is generated based on page ownership and package identifier to record sub-package names, page routes and their mapping relationships; During the publishing, host loading, and runtime execution phases, the structure manifest is reused so that page positioning, resource preparation, and script execution are based on the same set of identifier associations.

2. The main-sub-package collaborative loading method for cross-platform JS applications according to claim 1, characterized in that: When determining page ownership, the page ownership relationship with the main package and sub-package is established by reading the page information and sub-package information in the application configuration, thereby determining the page ownership.

3. The main-sub-package collaborative loading method for cross-platform JS applications according to claim 2, characterized in that: When generating package identifiers, after establishing ownership relationships, a package identifier is generated for each sub-package that is used consistently in the build artifacts, runtime requests, and host load parameters.

4. The main-sub-package collaborative loading method for cross-platform JS applications according to claim 1, characterized in that: During the release phase, a download list is also generated, which records the addresses, versions, or verification information required by the host to prepare the target sub-package resources.

5. The main-sub-package collaborative loading method for cross-platform JS applications according to claim 1, characterized in that: During the runtime phase, based on the target page route or dynamically imported target, the structure list is queried to determine whether a corresponding sub-package exists; When the target sub-package is not yet ready, a sub-package loading request is sent to the host. The request carries the package identifier and corresponding loading parameters. The host completes local resource reading or remote resource acquisition based on the request, and returns the result to the runtime after the resource is available.

6. The main-sub-package collaborative loading method for cross-platform JS applications according to claim 5, characterized in that: During the runtime phase, in response to receiving the resource ready result, the target sub-package script is executed, and the loading status of the corresponding sub-package is updated.

7. The main-sub-package collaborative loading method for cross-platform JS applications according to claim 6, characterized in that: During the runtime phase, once the main package has finished executing, the preparation and loading process is only performed on the target sub-package.

8. The main-sub-package collaborative loading method for cross-platform JS applications according to claim 1, characterized in that: In response to dynamic loading scenarios, dynamic import requests from the JS side are associated with package identifiers and converted into sub-package loading requests that can be recognized by the host, so as to connect the dynamic import semantics with the resource preparation capabilities of the mobile host.

9. The main-sub-package collaborative loading method for cross-platform JS applications according to claim 1, characterized in that: In response to scenarios involving in-app built-in sub-packages and runtime downloaded sub-packages, the same package identifier and loading entry point settings will be reused for both in-app built-in sub-packages and runtime downloaded sub-packages.

10. A master-sub-package collaborative loading system for cross-platform JS applications, used to implement the master-sub-package collaborative loading method for cross-platform JS applications as described in claim 1, characterized in that, include: The compilation module is used to generate a structure list during the compilation and unpacking stage, based on page ownership and package identifier, to record sub-package names, page routes and their mapping relationships; The collaborative loading module is used to reuse the structure manifest during the publishing, host loading, and runtime execution phases, so that page positioning, resource preparation, and script execution are based on the same set of identifier associations.

Images