Methods, apparatus, media and computing devices for generating and loading file packages

Abstract

This disclosure provides a method, apparatus, medium, and computing device for generating and loading file packages. The method for generating file packages includes: determining dependencies between multiple module files, each module file including at least one intermediate file and an entry file that depends on the intermediate file, each module file recording application code; responding to the intermediate file including a dynamic intermediate file that dynamically imports the entry file, generating a first file package corresponding to the entry file and a second file package corresponding to the dynamic intermediate file based on the dependencies, wherein the second file package is loaded by the application's client after the first file package. This method can automate the splitting and packaging of file packages, has a high file package generation speed, and can improve the efficiency of client loading of file packages, shorten user waiting time, and improve user experience.

Description

Technical Field

[0001] The embodiments of this disclosure relate to the field of computer software technology, and more specifically, the embodiments of this disclosure relate to a method, apparatus, medium, and computing device for generating and loading file packages. Background Technology

[0002] This section is intended to provide background or context for embodiments of this disclosure. The description herein is not intended to imply that it is prior art simply because it is included in this section.

[0003] Before an application is released, it typically needs to be packaged into a bundle containing the application's code for client download and execution. As the application's codebase grows, packaging all module files into a single large bundle significantly increases loading and execution time, leading to performance degradation on the client side. Therefore, it's possible to split the application's module files into multiple bundles for separate download by the client.

[0004] To achieve splitting and packaging, the current approach typically involves application developers setting up multiple entry files when writing the program code, and specifying the corresponding module files for each entry file, thus splitting the module files. Then, each entry file and its corresponding module file are packaged to obtain a file package corresponding to each entry file. Summary of the Invention

[0005] However, the aforementioned splitting schemes in related technologies require developers to manually set multiple entry files. When the application code changes, the corresponding entry files also need to be manually updated, making rapid application updates difficult. Furthermore, during the file package generation process, each entry file and its corresponding module file must undergo a complete packaging process involving resolution, transformation, and serialization before a corresponding file package can be generated. For multiple entry files and their respective module files, each file needs to undergo the same complete packaging process to generate multiple application file packages, resulting in low overall efficiency for splitting and packaging.

[0006] In addition, the multiple file packages obtained in this way correspond to different entry files. The client needs to download and load all file packages before it can display the corresponding page content to the user. The low loading efficiency results in a long time for content display, which affects the user experience.

[0007] Therefore, there is a great need for an improved method for generating and loading file packages to improve the efficiency of file package generation and loading.

[0008] In this context, embodiments of the present disclosure are intended to provide a method, apparatus, medium, and computing device for generating and loading file packages.

[0009] In a first aspect of this disclosure, a method for generating a file package is provided, the method comprising:

[0010] Determine the dependencies between multiple module files, which include at least one intermediate file and an entry file that depends on the intermediate file. Each module file is used to record the application code.

[0011] In response to the intermediate file including a dynamic intermediate file that imports the entry file in a dynamic manner, a first file package corresponding to the entry file and a second file package corresponding to the dynamic intermediate file are generated according to the dependency relationship, wherein the second file package is used by the client of the application to load after the first file package.

[0012] In a second aspect of this disclosure, a method for loading a file package is provided, the method comprising:

[0013] In response to a file package retrieval instruction detected on the first page, a second file package is retrieved, wherein the first page is generated by the application's client loading the first file package;

[0014] The second file package is loaded. The first file package and the second file package are generated in response to preset conditions and according to the dependencies between multiple module files. The multiple module files include at least one intermediate file and an entry file that depends on the intermediate file. The preset conditions include: the intermediate file includes a dynamic intermediate file, the dynamic intermediate file imports the entry file in a dynamic manner, and each module file is used to record the code of the application.

[0015] In a third aspect of this disclosure, an apparatus for generating a file package is provided, the method comprising:

[0016] A dependency determination module is used to determine the dependency relationships between multiple module files, which include at least one intermediate file and an entry file that depends on the intermediate file. Each module file is used to record the application code.

[0017] The file package generation module is configured to, in response to the intermediate files including dynamic intermediate files that are dynamically imported from the entry file, generate a first file package corresponding to the entry file and a second file package corresponding to the dynamic intermediate files according to the dependency relationship, wherein the second file package is used by the client of the application to load after the first file package.

[0018] In a fourth aspect of this disclosure, an apparatus for loading a file package is provided, the method comprising:

[0019] The file package acquisition module is used to acquire a second file package in response to a file package acquisition instruction detected on the first page, wherein the first page is generated by the application's client loading the first file package;

[0020] A file package loading module is used to load the second file package. The first file package and the second file package are generated in response to preset conditions and according to the dependencies between multiple module files. The multiple module files include at least one intermediate file and an entry file that depends on the intermediate file. The preset conditions include: the intermediate file includes a dynamic intermediate file, the dynamic intermediate file imports the entry file in a dynamic manner, and each module file is used to record the code of the application.

[0021] In a fifth aspect of the present disclosure, a medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method for generating a file package as described in any embodiment of the first aspect or the method for loading a file package as described in any embodiment of the second aspect.

[0022] In a sixth aspect of this disclosure, a computing device is provided, comprising:

[0023] processor;

[0024] Memory used to store processor-executable instructions;

[0025] The processor executes the executable instructions to implement the method for generating a file package as described in any embodiment of the first aspect or the method for loading a file package as described in any embodiment of the second aspect.

[0026] According to the method for generating a file package according to embodiments of the present disclosure, for multiple module files including at least one intermediate file and an entry file that depends on the intermediate file, the file package generation device can determine the dependencies between the multiple module files, and then, in response to the intermediate file including a dynamic intermediate file that dynamically imports the entry file, generate a first file package corresponding to the entry file and a second file package corresponding to the dynamic intermediate file according to the aforementioned dependencies, wherein the second file package can be loaded by the application's client after the first file package. According to the method for loading a file package according to embodiments of the present disclosure, the application's client can load the first file package to generate a first page, and then, in response to a file package acquisition instruction detected in the first page, acquire and load the second file package.

[0027] In this approach, all module files in the application contain only one entry file, which is used to generate the corresponding first file package. The dynamic intermediate files imported into this entry file are then used to generate the second file package. As all other module files are imported from the same entry file, developers do not need to manually modify each entry file individually; they only need to update the code in the corresponding module files to achieve rapid application updates. Furthermore, because only one first file package corresponding to the entry file and one second file package corresponding to the dynamic intermediate files are generated, the aforementioned file packages only require a single complete process of parsing, conversion, and serialization, significantly improving the file package generation speed.

[0028] Furthermore, for multiple file packages obtained in this way, the client can first load the entry file to display the first page. Then, if a file package retrieval command is detected on this page, the client can retrieve and load the corresponding second file package, without having to load all file packages at once. This achieves on-demand loading of the second file package, which helps avoid unnecessary loading of the second file package and thus improves the efficiency of the client loading file packages. Moreover, since the number of second file packages that need to be retrieved and loaded is small, the user's waiting time can be significantly shortened, thereby improving the user experience. Attached Figure Description

[0029] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which:

[0030] Figure 1 A schematic diagram of an application deployment and operation system according to an embodiment of the present disclosure is shown.

[0031] Figure 2A flowchart illustrating a method for generating a file package according to an embodiment of the present disclosure is shown schematically;

[0032] Figure 3 A schematic diagram of a dependency tree according to an embodiment of the present disclosure is shown;

[0033] Figure 4 A schematic diagram illustrating a process for generating and loading a file package according to an embodiment of the present disclosure is shown.

[0034] Figure 5 A flowchart illustrating a method for loading a file package according to an embodiment of the present disclosure is shown schematically;

[0035] Figure 6 A schematic diagram illustrating a page relationship according to an embodiment of the present disclosure is shown.

[0036] Figure 7 A schematic diagram of a medium according to an embodiment of the present disclosure is shown;

[0037] Figure 8 A block diagram schematically illustrates an apparatus for generating a file package according to an embodiment of the present disclosure;

[0038] Figure 9 A block diagram schematically illustrates an apparatus for loading a file package according to an embodiment of the present disclosure;

[0039] Figure 10 A schematic diagram of a computing device according to an embodiment of the present disclosure is shown.

[0040] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0041] The principles and spirit of this disclosure will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are given merely to enable those skilled in the art to better understand and implement this disclosure, and are not intended to limit the scope of this disclosure in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0042] Those skilled in the art will recognize that embodiments of this disclosure can be implemented as a system, apparatus, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0043] According to embodiments of this disclosure, a method, apparatus, medium, and computing device for generating and loading file packages are proposed.

[0044] In this document, any number of elements in the accompanying figures is for illustrative purposes and not for limitation, and any naming is for distinction only and has no limiting meaning.

[0045] The principles and spirit of this disclosure will be explained in detail below with reference to several representative embodiments. Invention Overview

[0047] The inventors discovered that the unpacking schemes in related technologies require developers to manually set multiple entry files. When the application code changes, the corresponding entry files also need to be manually updated, making rapid application updates difficult. Furthermore, during the file package generation process, each entry file and its corresponding module file must undergo a complete parsing, conversion, and serialization process to generate the corresponding file package. For multiple entry files and their respective corresponding module files, each file needs to go through the same complete process to generate multiple application file packages, resulting in low overall efficiency for splitting and packaging. Additionally, since the multiple file packages obtained through this method correspond to different entry files, the client needs to download and load all file packages before displaying the corresponding page content to the user. This low loading efficiency leads to longer content display times, impacting user experience.

[0048] To address the aforementioned problems, this disclosure provides a method, apparatus, medium, and computing device for generating and loading file packages.

[0049] According to the method for generating a file package according to embodiments of the present disclosure, for multiple module files including at least one intermediate file and an entry file that depends on the intermediate file, the file package generation device can determine the dependencies between the multiple module files, and then, in response to the intermediate file including a dynamic intermediate file that dynamically imports the entry file, generate a first file package corresponding to the entry file and a second file package corresponding to the dynamic intermediate file according to the aforementioned dependencies, wherein the second file package can be loaded by the application's client after the first file package. According to the method for loading a file package according to embodiments of the present disclosure, the application's client can load the first file package to generate a first page, and then, in response to a file package acquisition instruction detected in the first page, acquire and load the second file package.

[0050] In this approach, all module files in the application contain only one entry file. This entry file is used to generate the corresponding first file package, while the dynamic intermediate files imported into this entry file are used to generate the second file package. As all other module files are imported into the same entry file, developers do not need to manually modify the entry file individually; they only need to update the code in the corresponding module files to achieve automated splitting and packaging of the file packages, thus facilitating rapid application updates. Furthermore, because only one first file package corresponding to the entry file and one second file package corresponding to the dynamic intermediate files are generated, the aforementioned file packages only require a single complete process of parsing, conversion, and serialization, significantly improving the file package generation speed.

[0051] Furthermore, for multiple file packages obtained in this way, the client can first load the entry file to display the first page. Then, if a file package retrieval command is detected on this page, the client can retrieve and load the corresponding second file package, without having to load all file packages at once. This achieves on-demand loading of the second file package, which helps avoid unnecessary loading of the second file package and thus improves the efficiency of the client loading file packages. Moreover, since the number of second file packages that need to be retrieved and loaded is small, the user's waiting time can be significantly shortened, thereby improving the user experience.

[0052] After introducing the basic principles of this disclosure, various non-limiting embodiments of this disclosure will be described in detail below.

[0053] Application Scenarios Overview

[0054] It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this disclosure, and the implementation of this disclosure is not limited in any way. On the contrary, the implementation of this disclosure can be applied to any applicable scenario.

[0055] Figure 1 This is a schematic diagram of an application development and operation system provided in an exemplary embodiment. For example... Figure 1 As shown, the system may include a network 10, a server 11, a database 12, and several electronic devices, such as mobile phones 13, 14, and 15.

[0056] Mobile phones 13-15 are just examples of one type of electronic device that users can use. In reality, users can obviously also use electronic devices such as tablets, laptops, PDAs (Personal Digital Assistants), wearable devices (such as smart glasses, smartwatches, etc.); a client running on any of the above electronic devices (such as the client for development or application described below) can be pre-installed on the electronic device, so that the client can be launched and run on the electronic device.

[0057] Server 11 can be a physical server containing an independent host, or server 11 can be a virtual server, cloud server, etc. hosted by a host cluster; database 12 can be a centralized or distributed database, etc., and one or more embodiments in this specification do not limit this. As for network 10, it can include various types of wired or wireless networks.

[0058] First, it should be noted that the aforementioned application development and operation system can consist of an application development platform and an application operation platform. The application development platform can include an application development client (e.g., mobile phone 13) and a storage device (e.g., database 12). Application developers can use the development client to write and compile the application's code, generate a file package from the module files containing the code, and publish it to the storage device. Alternatively, the development client, storage device, and server 11 can work together to achieve this process. The application operation platform can include the application's server (e.g., server 11), storage device (e.g., database 12), and client (e.g., mobile phones 14-15). After the file package corresponding to the new version of the application's client is published to the storage device, the old version of the application's client can retrieve and load the file package from the storage device to implement the new version locally. This client can then work with the server to implement corresponding business functions (e.g., displaying pages, displaying controls on the page, etc.). Of course, the terms "new" and "old" client versions are only used to distinguish between the client before and after loading the file package; in actual applications, both clients can use the same version number, which will not be elaborated further.

[0059] in short, Figure 1The mobile phone 13 or server 11 shown can use the method for generating file packages described in this embodiment to split and package the module file containing the above-mentioned program code, thereby generating corresponding first and second file packages, and publishing the file packages to the database 12. Mobile phones 13 and 14 can use the method for loading file packages described in this embodiment to obtain and load the second file package from the database 12, and then realize the preset functions of the application by interacting with the server 11.

[0060] In this embodiment, the application development and running system can not only generate and load file packages, but also serve as an integrated functional platform for many other functions, such as performing dependency analysis on code and generating a dependency tree, detecting preset tags in intermediate files, determining the storage address of file packages, publishing or downloading generated file packages, and jumping to corresponding pages. One or more embodiments of this specification do not limit this.

[0061] According to the method for generating a file package according to embodiments of the present disclosure, for multiple module files including at least one intermediate file and an entry file that depends on the intermediate file, the file package generation device can determine the dependencies between the multiple module files, and then, in response to the intermediate file including a dynamic intermediate file that dynamically imports the entry file, generate a first file package corresponding to the entry file and a second file package corresponding to the dynamic intermediate file according to the aforementioned dependencies, wherein the second file package can be loaded by the application's client after the first file package. According to the method for loading a file package according to embodiments of the present disclosure, the application's client can load the first file package to generate a first page, and then, in response to a file package acquisition instruction detected in the first page, acquire and load the second file package.

[0062] The application described in this disclosure can be developed based on the React Native technology framework, i.e., the application can be an RN application. The RN application can run on the Android or iOS operating system of the terminal device, specifically as a standalone app (Application) running on the aforementioned operating system. During operation, the RN application can acquire and load relevant published data, i.e., acquire and load the file package generated by the solution described in this specification. Furthermore, the code for the application described in this disclosure can be written using the JavaScript programming language.

[0063] Exemplary methods

[0064] It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this disclosure, and the implementation of this disclosure is not limited in any way. On the contrary, the implementation of this disclosure can be applied to any applicable scenario.

[0065] refer to Figure 2 , Figure 2 A flowchart illustrating a method for generating a file package according to an embodiment of the present disclosure is shown schematically. The method may include the following steps: S201-S202.

[0066] Step S201: Determine the dependencies between multiple module files, wherein the multiple module files include at least one intermediate file and an entry file that depends on the intermediate file, and each module file is used to record the application code.

[0067] This method can be applied to a first device for developing applications, such as the aforementioned mobile phone 13 or server 11, and can be implemented by application development software running on the first device. Specifically, when the first device is a terminal device used by developers (such as the mobile phone 13), developers can write and compile application code using the development software running on the terminal device, and then trigger the terminal device to generate a corresponding file package according to the file package generation method described in this disclosure, and publish it, based on the file package generation function provided by the software. When the first device is a server (such as the server 11), developers can submit the aforementioned code or various module files containing the aforementioned code to the server, and trigger the server to generate a corresponding file package according to the file package generation method described in this disclosure and publish it.

[0068] After developers complete the development steps such as writing and compiling the code for the application to be released, they can obtain multiple module files. At this time, the first device can generate a file package based on the above-mentioned module files using the file package generation method described in this solution, for release. The module file mentioned in this disclosure is called a Module, and the file package is called a Bundle. The file package generation solution described in this disclosure is used to generate corresponding Bundles from multiple Modules.

[0069] The aforementioned module files include at least one intermediate file and an entry file that depends on the intermediate file. The file type of any module file (i.e., whether it is an entry file or an intermediate file) can be specified by the developer and recorded in the file's header information or in the file's code. For example, for the file code before splitting, the following statement can be written in its registration code to identify the entry file:

[0070] AppRegistry.registerComponent(appName,()=>App);

[0071] Taking template file Module A as an example, you can write the following statement at the end of the code in the file corresponding to Module A:

[0072] AppRegistry.registerComponent(appName+'A',()=>{return <app / >});

[0073] This allows the split module file Module A to be designated as the entry file.

[0074] Each module file is used to record the code of the application. Different module files may record the same or different code. The "code" recorded in any module file in this embodiment can include program code in a narrow sense, which can be basic code required for the application's runtime, such as code used to draw pages, set page backgrounds, or other parameters; or, the "code" contained in any module file can also include program code in a broad sense, which can be program resources required for the program's runtime, such as text and images. The aforementioned code can be associated with various forms of multimedia resources such as music and video. For example, the aforementioned text can be a hyperlink to a video access address, or the aforementioned image can be set to redirect to a certain music playback, etc., which will not be elaborated further. In other words, this embodiment does not limit the content recorded in any module file.

[0075] To ensure that each loaded file package can perform its preset functions, the generated file packages and their corresponding module files need to meet preset logical relationships, which can be reflected by the dependencies between the module files. Therefore, before generating the file packages, the first device can determine the dependencies between multiple module files.

[0076] In one embodiment, the first device can determine the dependencies between multiple module files using a dependency tree. For example, dependency analysis can be performed on the code recorded in the multiple module files, and a dependency tree corresponding to the multiple module files can be generated based on the analysis results. Then, the dependencies between the multiple module files can be determined based on the dependency tree.

[0077] by Figure 3 Let's take an example to illustrate. Figure 3The diagram shows the dependency tree generated after performing dependency analysis on the nine module files (Modules A through I). As can be seen, these nine module files include one entry file (Module A) and eight intermediate files (Modules B through I). The dependency tree determines the following relationships between the module files: Module A depends on Modules B, F, and G; Module B depends on Module C; Module C depends on Modules D and E; Module F does not depend on any other module files; Module G depends on Module H; and Module H further depends on Module I.

[0078] Step S202: In response to the intermediate file including a dynamic intermediate file that imports the entry file in a dynamic manner, a first file package corresponding to the entry file and a second file package corresponding to the dynamic intermediate file are generated according to the dependency relationship, wherein the second file package is used by the client of the application to load after the first file package.

[0079] For at least one intermediate file among the aforementioned multiple module files, the first device can determine the import method for each intermediate file so as to generate a file package of the corresponding type according to the import method. The import method of any intermediate file is the way in which that intermediate file is imported into the entry file. Furthermore, during runtime, the application client can load the file package corresponding to that intermediate file according to the loading method corresponding to the import method. The import method of any intermediate file can be dynamic import or static import. If the import method of any intermediate file is dynamic import, then that intermediate file is a dynamic intermediate file; if the import method of any intermediate file is static import, then that intermediate file is a static intermediate file.

[0080] The first device can determine that any intermediate file is a dynamic intermediate file in several ways. For example, developers can write preset dynamic or preset static tags in the code of any intermediate file to specify how the intermediate file is imported into the entry file. Accordingly, the first device can determine that any intermediate file is a dynamic intermediate file if it contains preset dynamic tags. These preset dynamic and preset static tags can be recorded in import type statements, such as "async" and "sync" respectively, and the corresponding import type statements can be as follows:

[0081] const AsyncModule=import('. / asyncModule'); and,

[0082] import syncModule from'. / syncModule';

[0083] Therefore, the import type of any intermediate file can be determined based on its import type statement. This allows developers to specify how each intermediate file is imported into the corresponding entry file when writing code. If the import method changes, only the code above needs to be modified, eliminating the need to process multiple entry files separately, thus simplifying application update operations.

[0084] For example, developers can write code in any intermediate file according to a specific import method to specify how the intermediate file is imported into the entry file. Correspondingly, the first device can identify an intermediate file as a dynamic intermediate file if the code recorded in any intermediate file is written according to the syntax rules corresponding to dynamic import. These syntax rules can be native rules corresponding to the programming language; or, to meet the personalized needs of developers, the syntax rules can also be custom rules specified by developers in the application's configuration file. This disclosure does not limit this approach.

[0085] like Figure 3 The dependency tree shown corresponds to multiple module files. Let's assume Module B is dynamically imported into Module A, Module H is dynamically imported into Module G, and all other intermediate files are statically imported into their respective parent intermediate files; further details are omitted. After determining the dynamic intermediate files among these, the first device can generate a first file package corresponding to the entry file and a second file package corresponding to the dynamic intermediate files based on the dependency relationships.

[0086] In one embodiment, the first device can generate corresponding file packages step by step according to the above-mentioned dependencies. For example, it can first generate second file packages corresponding to each dynamic intermediate file, and then generate the first file package corresponding to the entry file based on the generated second file packages. Continuing from the foregoing embodiments, for Figure 3Based on the aforementioned dependencies and the substitution methods of the intermediate files, the first device can generate Bundle1 from Modules B to E, and Bundle2 from Modules H and I. Then, based on Bundle1 and Bundle2, and combined with Modules A, F, and G, Bundle0 is generated. Clearly, Bundle0 is the first file package corresponding to the entry file Module A, Bundle1 is the second file package corresponding to the intermediate files Modules B to E, and Bundle2 is the second file package corresponding to the intermediate files Modules H and I. The process of generating a file package from multiple module files can be considered as packaging the multiple module files into a single file package.

[0087] In fact, hierarchical relationships can exist between multiple secondary files. For example, if Module I is also a dynamic intermediate file, that is, Module I imports Module H dynamically... Figure 3 (Not shown), with the dependencies and import methods between other module files remaining unchanged, the first device can first generate the second file package Bundle2” based on Module I, then generate the second Bundle2’ based on Module H, and finally generate the first file package Bundle0’ based on the Bundle1, Bundle2” and Bundle2’, combined with Module A, Module F and Module G.

[0088] To ensure that the client can successfully obtain and load the second file package after loading the first file package, the storage address of the second file package can be recorded in the first file package during its generation. For example, the first device can determine the second storage address of each second file package. This second storage address is used to store the corresponding second file package after publication (i.e., any second file package will be saved at the second storage address of the second file package after publication), and then the determined second storage addresses can be recorded in the first file package. In fact, for the first file package, a first storage address for storing that file package can also be determined. The storage address of any file package can be generated according to the rule {conventional domain name} + {application name} + {Bundle name}. The "conventional domain name" can be the access address or domain name of the application's server, etc. The "application name" can be the full name or preset number of the application, etc., and the "Bundle name" can be the file package name of the file package, such as the full name or preset number, etc., which will not be elaborated further.

[0089] Inherited from Figure 3 In the aforementioned embodiments, the first device can determine the second storage addresses of Bundle1 and Bundle2 respectively, and then record the determined second storage addresses in Bundle0. For example, the second storage addresses can be recorded in the header or information of Bundle0 when it is generated, which will not be elaborated further. In this way, when loading the first file package, the client can determine the second storage addresses of each corresponding second file package. Therefore, when any second file package needs to be loaded, it can download the second file package from the corresponding second storage address. This not only separates the first and second file packages but also separates the storage addresses of each file package, which helps improve the efficiency of file package distribution and download.

[0090] In another embodiment, the development software running on the first device can be Metro Tools, a packaging tool officially provided by React Native, which can be used to generate corresponding file packages based on each module file. When using Metro Tools for splitting and packaging, a complete packaging process includes three stages: parsing, conversion, and serialization. In the parsing stage, code analysis can be performed on the code recorded in each module file, and a dependency tree between the module files can be generated. In the conversion stage, the code written in the current language version can be converted into code in the target version language corresponding to the application to be released, thereby improving the compatibility of each file package during the loading process after release, ensuring the smooth operation of the application and the successful implementation of preset functions. In the serialization stage, corresponding file packages can be generated based on each module file containing the converted code.

[0091] In practice, with full authorization from all relevant parties, the method for generating file packages described in this disclosure can be implemented as a functional plugin for the Metro tool, either as an add-on or embedded component. This functional plugin can supplement and improve the native functionality provided by the Metro tool. After developers have developed the code for the application to be released using the Metro tool, they can use this functional plugin to split and package the various module files containing the aforementioned code, generating corresponding first and second file packages for release.

[0092] In related technologies, the module files of the application to be released usually contain multiple entry files. Therefore, each entry file and its corresponding intermediate file need to go through the above three stages separately and in sequence to generate the corresponding file package. In other words, for an application with n entry files, it is necessary to go through n complete packaging processes to generate n file packages. The process of generating file packages is cumbersome and inefficient.

[0093] In one embodiment of this disclosure, the Metro tool can generate a first file package corresponding to the entry file and a second file package corresponding to the dynamic intermediate file in the same serialization stage, based on the dependency relationship. In this embodiment, since the multiple module files contain only one entry file, the Metro tool ultimately only needs to generate one first file package corresponding to the entry file and at least one second file package corresponding to at least one dynamic intermediate file (included in the at least one intermediate file). Moreover, the first file package and at least one second file package can be generated in only one complete packaging process—the Metro tool only needs to execute one complete packaging process (including the above three stages), greatly simplifying the file package generation steps and significantly improving the file package generation efficiency.

[0094] In another embodiment, the intermediate files mentioned above may include not only dynamically imported entry files but also statically imported entry files. In this case, the first device can package the static intermediate files into the first file package to generate the first file package. Obviously, the entry file depends on the static intermediate files packaged into the first file package. Of course, if any dynamic intermediate file depends on at least one static intermediate file, the first device can also package the at least one static intermediate file into the second file package corresponding to the dynamic intermediate file to generate the second file package. Figure 3 Taking the dependency tree shown as an example, Module F and Module G, which the entry file Module A depends on, are statically imported into Module A. That is, Module F and Module G are both static intermediate files. Therefore, when generating the first file package Bundle0, Module F and Module G can be packaged into this file package. Similarly, Module I, which the dynamic intermediate file Module H depends on, is statically imported into Module H. That is, Module I is also a static intermediate file. Therefore, when generating the second file package Bundle2, Module I can be packaged into this file package. The same applies to Module C, which the dynamic intermediate file Module B depends on, and will not be elaborated further.

[0095] After generating the first file package and the second file package using the methods described in the foregoing embodiments, the first device can publish the file packages to the corresponding storage devices. For example, the first device can determine the first storage address of the first file package and the second storage address of the second file package, then publish the first file package to the first storage address and the second file package to the second storage address. Of course, if multiple second file packages are generated in the foregoing steps, the second storage address of each second file package can be determined separately, and each second file package can be published to its respective second storage address to achieve isolation between the file packages.

[0096] In addition, the first file package and the second file package can be associated and published to the storage device after they are generated; or, if the second file package is generated first and then the first file package is generated, the second file package and the first file package can be published in the order of generation described above. This disclosure does not limit this.

[0097] The storage address of any file package is the storage address of that file package on the storage device after it has been published. This storage device can take various forms. For example, to facilitate file package management, it can be a centralized database; or, if the application's clients are widely distributed, it can be a distributed database, such as a CDN (Content Delivery Network). In this case, clients can download the published file packages from the nearest location, helping to reduce download latency caused by geographically dispersed clients, thereby improving client response speed and ultimately enhancing the user experience.

[0098] In this approach, all module files in the application contain only one entry file. This entry file is used to generate the corresponding first file package, while the dynamic intermediate files imported into this entry file are used to generate the second file package. As all other module files are imported into the same entry file, developers do not need to manually modify the entry file individually; they only need to update the code in the corresponding module files to achieve automated file package splitting and packaging, thus facilitating rapid application updates. Furthermore, because only one first file package corresponding to the entry file and one second file package corresponding to the dynamic intermediate files are generated, each file package only needs to undergo one complete process of parsing, conversion, and serialization, significantly improving the file package generation speed.

[0099] Please see Figure 4 The diagram illustrates the process of generating and loading file packages. Figure 4As shown, the application development platform where the first device resides can use the schemes described in the foregoing embodiments to split and package multiple modules of the application and generate multiple bundles, that is, automatically split multiple module files to generate a first file package and at least one second file package. Subsequently, the platform can push the aforementioned multiple bundles to a CDN, whereby the CDN stores them in their respective storage addresses, thereby completing the distribution of each file package. Each distributed file package can correspond to a page of the application or at least one page content such as a component to be displayed on the page. After the aforementioned file packages are distributed, the application's client (such as...) can... Figure 4 The RN application client shown can download the corresponding file package from the CDN before displaying the above page or page content. By loading the file package and rendering the page, the above page or page content can be displayed.

[0100] The following is combined Figure 5 The flowchart illustrates a method for loading a file package, providing a detailed explanation of the file package loading process. This method can be applied to a first device running a client of the application described above, such as... Figure 1 The method can be implemented by a client of the application, as described in the following embodiments, with the client serving as the execution subject. The method may include the following steps S501-S502.

[0101] Step S501: In response to the file package retrieval instruction detected in the first page, retrieve the second file package. The first page is generated by the application's client loading the first file package.

[0102] First, it should be noted that the first file package and the second file package described in this disclosure embodiment can be generated by the file package generation method described in the foregoing embodiment, or they can be generated by other methods. This disclosure embodiment does not limit this.

[0103] The application client can first load the first file package to display the first page, which can be the application's homepage or any other page. Considering that the first file package is typically the client's entry point, and the first page corresponding to the first file package allows navigation to other functional pages, the first storage address of the first file package can be a fixed address maintained by the client. Thus, after startup, the client can retrieve the published first file package based on its maintained fixed address and then load it to display the first page. With the client maintaining a fixed storage address for the first file package, the client is unaware of the first file package's publishing process; it only needs to retrieve the corresponding first file package according to the fixed storage address to load the updated, latest first page. This simplifies the client's file package loading logic and the application's maintenance logic.

[0104] The client displaying the first page may generate or receive a file package retrieval instruction to trigger the retrieval of the second file package. For example, the client may receive a file package retrieval instruction sent by the server. Alternatively, the client may receive a file package retrieval instruction sent to the first device by other nearby devices via near-field communication, such as after a mobile phone scans a rentable item or is scanned by a cash register, the rentable item or cash register can send a corresponding file package retrieval instruction to the mobile phone 14 via near-field signal. Furthermore, while viewing the first page, the user of the second device may be interested in certain page content and thus perform a first trigger operation on the first page. The triggered page content may be an entry point to multimedia resources such as images, videos, or music, or a triggerable control such as a button; the first trigger operation may be an action such as clicking or swiping, or it may be a wake-up or voice control, etc., and this embodiment does not limit this. In response to the first trigger operation, the client or the first device can generate a corresponding file package retrieval instruction, and then the client can retrieve the corresponding second file package in response to the instruction.

[0105] In one embodiment, the client can first determine the storage address of the second file package corresponding to the file package retrieval instruction (i.e., the aforementioned second storage address). If the storage address is recorded in the file package retrieval instruction, it can be parsed from the instruction. Alternatively, the client or the server can maintain a mapping relationship between the file package identifiers and storage addresses of each second file package of the application. Thus, if the file package retrieval instruction contains the file package identifier of the second file package to be retrieved, the client can query the corresponding storage address from the locally maintained mapping relationship based on the file package identifier parsed from the instruction, or request (and the server queries) the corresponding storage address. If the mapping relationship is stored locally on the client, the client can associate the mapping relationship when downloading the first file package for the first time after the first and second file packages are released; or the mapping relationship can be recorded in the first file package. Furthermore, the mapping relationship can be updated accordingly when the first and second file packages are released next time.

[0106] Furthermore, the client can download the second file package from the obtained storage address. For example, it can obtain the second file package from the storage device by sending an HTTP (Hypertext Transfer Protocol) request. The client can generate an HTTP request header based on the obtained storage address and then send the HTTP request to obtain the second file package. Because HTTP requests have a caching mechanism, the client can check whether the required second file package is already stored locally before sending the request, thus avoiding repeatedly obtaining the same second file package within a short period, saving bandwidth and reducing network congestion. If, after the user triggers the first page (to obtain the second file package), causing the client to redirect to the second page and then return to the first page, if the same triggering operation is performed again within a short period (before the second file package is deleted from the local storage), the client can directly load the local second file package without repeatedly downloading it from the storage device.

[0107] Step S502: Load the second file package. The first file package and the second file package are generated in response to preset conditions and according to the dependencies between multiple module files. The multiple module files include at least one intermediate file and an entry file that depends on the intermediate file. The preset conditions include: the intermediate file includes a dynamic intermediate file, the dynamic intermediate file imports the entry file in a dynamic manner, and each module file is used to record the code of the application.

[0108] After obtaining the second file package, the client can load it. Since the currently displayed first page corresponds to the first file package, and the obtained second file package corresponds to the entry file and dynamic intermediate file respectively, and the entry file and dynamic intermediate file satisfy the corresponding dependency relationship, the client can load the obtained second file package within the runtime environment of the first file package. This ensures that the runtime environment of each file package corresponding to the same application is consistent, avoiding compatibility issues during the loading of the second file package.

[0109] Taking loading a first file package to generate a first page and loading a second file package to generate a second page as an example: Through the above method, bidirectional communication can be achieved between the first page and the second page running in the same runtime environment. In other words, although the client is the executing entity of this solution, the actual data interaction is between the first page and the second page; for example, data can be transferred between the threads of the first page and the second page. Clearly, this method eliminates the need for the client to act as a data intermediary between the two pages, which helps improve page interaction efficiency and the client's response speed to the file package retrieval command.

[0110] In one embodiment, the second device often runs more than one application at a time. Therefore, during the running of the application's client, the second device typically allocates a client container for that client to manage the hardware and software resources that the client can access. This client container can be exclusively used by the application's client or shared with other applications. In this case, the client can load the second file package within the client container that loads the first file package. Loading the second file package within this client container ensures that the second file package and the first file package are running in the same environment. Furthermore, loading the first and second file packages into the same client container eliminates the need to allocate a new client container and the client to adapt its own container, thus achieving better file package loading speed and client operating efficiency.

[0111] In another embodiment, the application code can be written in JavaScript. In this case, the first code recorded in the first file package and the second code recorded in the second file package are written in JavaScript. The client can load the second file package by creating an independent function. For example, the client can generate a `Function()` function containing the second code and execute it within the context of the first code. This allows the first and second file packages to be executed separately within the same context, significantly reducing the import cost of importing the second file package into the first file package, and eliminating the need for the client to adapt the first and second file packages.

[0112] From the perspective of the display page, the client responds to the file package acquisition instruction to obtain and load the second file package, enabling it to further display new page content or jump to a new page based on the first page. For example, the client can refresh the first page based on the loading result of the second file package, thereby updating the page content of the first page. Alternatively, the client can also jump to the second page based on the loading result of the second file package, where the second page can completely replace (cover) the first page, or it can be displayed above the first page in a partially covered or pop-up manner. Furthermore, the client can respond to a second trigger operation on the second page, refreshing the first page or jumping to a third page based on the corresponding operation result. If the first page is a membership purchase page, the second page can be a payment page. Users on the second device can make payments on this payment page. The client can then display subsequent information based on the payment result: if the payment is successful, the client can refresh the membership purchase page to display the purchased member homepage, or redirect to the current balance page, etc.; otherwise, if the payment fails due to insufficient balance, the client can refresh the membership purchase page to display a purchase failure page, or redirect to the payment page corresponding to a lower membership level, thus increasing the success rate of membership purchases. Further details are omitted. Specifically, the above page updates can take various forms, such as adding page content, deleting or hiding existing page content, and adjusting the size, position, color, speed, trajectory, and other display parameters of existing page content on the first page, etc., which will not be elaborated further.

[0113] like Figure 4As shown, the client displays page 1 by loading the first file package. Responding to the user's real-time trigger operation on page 1, which generates a file package retrieval command, the client can download the corresponding second file package from the CDN and then load that file package to display page 2. Of course, based on any page, file packages corresponding to page content (such as page components) can also be further downloaded, thereby displaying the corresponding page content on that page. It is evident that through the above method, the client can respond to file package retrieval commands and download each second file package as needed, without having to download the entire application's file package at once. Furthermore, due to... Figure 4 As can be seen from the foregoing embodiments, after generating the various file packages corresponding to the application, the objects to be published, downloaded, and loaded are all file packages, rather than single module files or code, which helps to improve processing efficiency.

[0114] According to the method for generating a file package according to embodiments of the present disclosure, for multiple module files including at least one intermediate file and an entry file that depends on the intermediate file, the file package generation device can determine the dependencies between the multiple module files, and then, in response to the intermediate file including a dynamic intermediate file that dynamically imports the entry file, generate a first file package corresponding to the entry file and a second file package corresponding to the dynamic intermediate file according to the aforementioned dependencies, wherein the second file package can be loaded by the application's client after the first file package. According to the method for loading a file package according to embodiments of the present disclosure, the application's client can load the first file package to generate a first page, and then, in response to a file package acquisition instruction detected in the first page, acquire and load the second file package.

[0115] In this approach, all module files in the application contain only one entry file. This entry file is used to generate the corresponding first file package, while the dynamic intermediate files imported into this entry file are used to generate the second file package. As all other module files are imported into the same entry file, developers do not need to manually modify the entry file individually; they only need to update the code in the corresponding module files to achieve automated splitting and packaging of the file packages, thus facilitating rapid application updates. Furthermore, because only one first file package corresponding to the entry file and one second file package corresponding to the dynamic intermediate files are generated, the aforementioned file packages only require a single complete process of parsing, conversion, and serialization, significantly improving the file package generation speed.

[0116] Furthermore, for multiple file packages obtained in this way, the client can first load the entry file to display the first page. Then, if a file package retrieval command is detected on this page, the client can retrieve and load the corresponding second file package, without having to load all file packages at once. This achieves on-demand loading of the second file package, which helps avoid unnecessary loading of the second file package and thus improves the efficiency of the client loading file packages. Moreover, since the number of second file packages that need to be retrieved and loaded is small, the user's waiting time can be significantly shortened, thereby improving the user experience.

[0117] Exemplary media

[0118] After introducing the methods of exemplary embodiments of this disclosure, the following references are made. Figure 7 The medium for exemplary embodiments of this disclosure will be described.

[0119] In this exemplary embodiment, the above method can be implemented by a program product, such as a portable compact disc read-only memory (CD-ROM) including program code, which can run on a device, such as a personal computer. However, the program product disclosed herein is not limited thereto. In this document, the readable medium 70 can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0120] The program product can take the form of any combination of one or more readable media. The readable medium 70 can be a readable signal medium or a readable medium in general. The readable medium 70 can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable media (a non-exhaustive list) include: electrical connections with one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0121] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable medium that can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0122] The program code contained on the readable medium 70 can be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RE, etc., or any suitable combination thereof.

[0123] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0124] Exemplary device

[0125] Having introduced the medium of exemplary embodiments of this disclosure, the following references are made to... Figure 8 and Figure 9 The apparatus according to exemplary embodiments of this disclosure will be described. The specific manner in which each functional module performs its operations and the specific functions achieved after the operations are performed have been described in detail in the foregoing embodiments of the methods for generating and loading file packages, and will not be elaborated further here.

[0126] Figure 8 A block diagram schematically illustrates an apparatus for generating a file package according to an embodiment of the present disclosure. The apparatus for generating a file package may include:

[0127] Dependency determination module 801 is used to determine the dependency relationships between multiple module files, the multiple module files including at least one intermediate file and an entry file that depends on the intermediate file, and each module file is used to record the application code;

[0128] The file package generation module 802 is configured to, in response to the intermediate file including a dynamic intermediate file that imports the entry file in a dynamic manner, generate a first file package corresponding to the entry file and a second file package corresponding to the dynamic intermediate file according to the dependency relationship, wherein the second file package is used by the client of the application to load after the first file package.

[0129] Optionally, the dependency determination module 801 is further configured to:

[0130] Dependency analysis is performed on the code recorded in the multiple module files to generate a dependency tree corresponding to the multiple module files;

[0131] The dependency relationships between the multiple module files are determined based on the dependency tree.

[0132] Optionally, any intermediate file is a dynamic intermediate file, including:

[0133] Each of the intermediate files contains a preset dynamic marker; or...

[0134] The code recorded in any of the intermediate files is written according to the syntax rules corresponding to dynamic import.

[0135] Optionally, the file package generation module 802 is further configured to:

[0136] Generate the second file package corresponding to each of the aforementioned dynamic intermediate files;

[0137] The first file package corresponding to the entry file is generated based on each of the second file packages.

[0138] Optionally, the file package generation module 802 is further configured to:

[0139] Determine the second storage address for each second file package, the second storage address being used to store the corresponding second file package after publication;

[0140] The determined second storage addresses are recorded in the first file package.

[0141] Optionally, the file package generation module 802 is further configured to:

[0142] During the same serialization stage, the Metro tool generates a first file package corresponding to the entry file and a second file package corresponding to the dynamic intermediate file based on the dependencies.

[0143] Optionally, the intermediate files also include static intermediate files that are statically imported from the entry file, and the file package generation module 802 is further configured to:

[0144] The static intermediate files are packaged into the first file package.

[0145] Optionally, it also includes:

[0146] Address determination module 803 is used to determine the first storage address of the first file package and the second storage address of the second file package respectively;

[0147] The file package publishing module 804 is used to publish the first file package to the first storage address and the second file package to the second storage address.

[0148] Optionally, the storage address is the storage address of the second file package in the content delivery network.

[0149] Figure 9 A block diagram schematically illustrates an apparatus for loading a file package according to an embodiment of the present disclosure. The apparatus for loading a file package may include:

[0150] The file package acquisition module 901 is used to acquire a second file package in response to a file package acquisition instruction detected on the first page, wherein the first page is generated by the application's client loading the first file package;

[0151] File package loading module 902 is used to load the second file package. The first file package and the second file package are generated in response to preset conditions and according to the dependencies between multiple module files. The multiple module files include at least one intermediate file and an entry file that depends on the intermediate file. The preset conditions include: the intermediate file includes a dynamic intermediate file, the dynamic intermediate file imports the entry file in a dynamic manner, and each module file is used to record the code of the application.

[0152] Optionally, the file package retrieval instruction is generated by a first trigger operation on the first page facing the client.

[0153] Optionally, the file package acquisition module 901 is further configured to:

[0154] Determine the storage address of the second file package corresponding to the file package acquisition instruction, and download the second file package from the storage address.

[0155] Optionally, the file package acquisition module 901 is further configured to:

[0156] Generate the HTTP request header based on the storage address;

[0157] The second file package is obtained by sending the HTTP request.

[0158] Optionally, the file package loading module 902 is further configured to:

[0159] Load the second file package in the runtime environment of the first file package.

[0160] Optionally, the file package loading module 902 is further configured to:

[0161] The second file package is loaded in the client container that loads the first file package.

[0162] Optionally, the first code recorded in the first file package and the second code recorded in the second file package are written in JavaScript, and the file package loading module 902 is further configured to:

[0163] Generate a Function() function containing the second code, and execute the Function() function in the context of the first code.

[0164] Optionally, it also includes:

[0165] The page refresh module 903 is used to refresh the first page based on the loading result of the second file package; or,

[0166] The page redirection module 904 is used to redirect to the second page based on the loading result of the second file package, and in response to the second trigger operation on the second page, refresh the first page or redirect to the third page according to the corresponding operation result.

[0167] Exemplary computing device

[0168] Having described the methods, media, and apparatus of exemplary embodiments of this disclosure, the following references... Figure 10 A computing device according to an exemplary embodiment of the present disclosure will be described.

[0169] Figure 10 The computing device 100 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0170] like Figure 10 As shown, the computing device 100 is presented in the form of a general-purpose computing device. The components of the computing device 100 may include, but are not limited to: at least one processing unit 1001, at least one storage unit 1002, and a bus 1003 connecting different system components (including the processing unit 1001 and the storage unit 1002).

[0171] Bus 1003 includes a data bus, a control bus, and an address bus.

[0172] Storage unit 1002 may include readable media in the form of volatile memory, such as random access memory (RAM) 10021 and / or cache memory 10022, and may further include readable media in the form of non-volatile memory, such as read-only memory (ROM) 10023.

[0173] Storage unit 1002 may also include a program / utility 10025 having a set (at least one) program module 10024, such program module 10024 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0174] The computing device 100 can also communicate with one or more external devices 1004 (such as a keyboard, pointing device, etc.).

[0175] This communication can be performed via input / output (I / O) interface 1005. Furthermore, the computing device 100 can also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapter 1006. Figure 10 As shown, network adapter 1006 communicates with other modules of computing device 100 via bus 1003. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with computing device 100, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0176] It should be noted that although several units / modules or sub-units / modules of the means for generating or loading file packages have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0177] Furthermore, although the operations of the methods disclosed herein are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0178] While the spirit and principles of this disclosure have been described with reference to several specific embodiments, it should be understood that this disclosure is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for convenience of expression. This disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A method for generating a file package, applied to a first device for developing React Native applications, the first device running Metro tools, comprising: Determine the dependencies between multiple module files, which include at least one intermediate file and an entry file that depends on the intermediate file. Each module file is used to record the code of the React Native application. The import method of the at least one intermediate file into the entry file is determined. If the import method of any intermediate file is dynamic import, then the intermediate file is determined to be a dynamic intermediate file; if the import method of any intermediate file is static import, then the intermediate file is determined to be a static intermediate file. In response to the intermediate file being a dynamic intermediate file, the Metro tool generates a second file package corresponding to each of the dynamic intermediate files in the same serialization stage, and generates a first file package corresponding to the entry file based on each second file package. The second file package is used by the React Native application client to load after the first file package. In response to the intermediate file being a static intermediate file, the static intermediate file is packaged into the first file package.

2. The method according to claim 1, wherein determining the dependencies between multiple module files includes: Dependency analysis is performed on the code recorded in the multiple module files to generate a dependency tree corresponding to the multiple module files; The dependency relationships between the multiple module files are determined based on the dependency tree.

3. The method according to claim 1, wherein any intermediate file is a dynamic intermediate file, comprising: Each of the intermediate files contains a preset dynamic marker; or, The code recorded in any of the intermediate files is written according to the syntax rules corresponding to dynamic import.

4. The method according to claim 1, wherein generating the first file package corresponding to the entry file based on each second file package includes: Determine the second storage address for each second file package, the second storage address being used to store the corresponding second file package after publication; The determined second storage addresses are recorded in the first file package.

5. The method according to claim 1, further comprising: Determine the first storage address of the first file package and the second storage address of the second file package respectively; The first file package is published to the first storage address, and the second file package is published to the second storage address.

6. The method according to claim 5, wherein the storage address is the storage address of the second file package in the content delivery network.

7. A method for loading a file package, applied to a client running a React Native application, comprising: In response to a file package retrieval instruction detected on the first page, a second file package is retrieved, the first page being generated by the React Native application client loading the first file package; The second file package is loaded. The first and second file packages are generated in response to preset conditions and based on the dependencies between multiple module files. The multiple module files include at least one intermediate file and an entry file that depends on the intermediate file. The preset conditions include: the intermediate files include dynamic intermediate files and static intermediate files; the dynamic intermediate files are dynamically imported into the entry file; each module file is used to record the code of the React Native application; the first and second file packages are generated by the Metro tool in the same serialization stage, each corresponding to a second file package of the dynamic intermediate file; a first file package corresponding to the entry file is generated based on each second file package; the static intermediate file is statically imported into the entry file, and the static intermediate file is packaged into the first file package.

8. The method according to claim 7, wherein the file package acquisition instruction is generated by a first triggering operation of the first page facing the client.

9. The method according to claim 7, wherein obtaining the second file package comprises: Determine the storage address of the second file package corresponding to the file package acquisition instruction, and download the second file package from the storage address.

10. The method according to claim 9, wherein downloading the second file package from the storage address comprises: Generate the HTTP request header based on the storage address; The second file package is obtained by sending the HTTP request.

11. The method according to claim 7, wherein loading the second file package comprises: Load the second file package in the runtime environment of the first file package.

12. The method according to claim 11, wherein loading the second file package in the runtime environment of the first file package comprises: The second file package is loaded in the client container that loads the first file package.

13. The method according to claim 11, wherein the first code recorded in the first file package and the second code recorded in the second file package are written in JavaScript, and loading the second file package in the runtime environment of the first file package includes: Generate a Function() function containing the second code, and execute the Function() function in the context of the first code.

14. The method of claim 7, further comprising: Refresh the first page based on the loading result of the second file package; or, Based on the loading result of the second file package, the user is redirected to the second page, and in response to the second trigger operation on the second page, the user refreshes the first page or redirects to the third page based on the corresponding operation result.

15. An apparatus for generating a file package, used on a first device for developing React Native applications, the first device running Metro tools, comprising: A dependency determination module is used to determine the dependency relationships between multiple module files, which include at least one intermediate file and an entry file that depends on the intermediate file. Each module file is used to record the code of the ReactNative application. The import method determination module is used to determine the import method in which the at least one intermediate file is imported into the entry file. If the import method of any intermediate file is dynamic import, then the intermediate file is determined to be a dynamic intermediate file; if the import method of any intermediate file is static import, then the intermediate file is determined to be a static intermediate file. The file package generation module is used to generate second file packages corresponding to each of the dynamic intermediate files in the same serialization stage in response to the intermediate file being a dynamic intermediate file; generate a first file package corresponding to the entry file based on each of the second file packages, wherein the second file packages are used by the React Native application client to load after the first file package; and package the static intermediate file into the first file package in response to the intermediate file being a static intermediate file.

16. The apparatus of claim 15, wherein the dependency determination module is further configured to: Dependency analysis is performed on the code recorded in the multiple module files to generate a dependency tree corresponding to the multiple module files; The dependency relationships between the multiple module files are determined based on the dependency tree.

17. The apparatus according to claim 15, wherein any intermediate file is a dynamic intermediate file, comprising: Each of the intermediate files contains a preset dynamic marker; or, The code recorded in any of the intermediate files is written according to the syntax rules corresponding to dynamic import.

18. The apparatus according to claim 15, wherein the file package generation module is further configured to: Determine the second storage address for each second file package, the second storage address being used to store the corresponding second file package after publication; The determined second storage addresses are recorded in the first file package.

19. The apparatus of claim 15, further comprising: The address determination module is used to determine the first storage address of the first file package and the second storage address of the second file package, respectively. The file package publishing module is used to publish the first file package to the first storage address and the second file package to the second storage address.

20. The apparatus of claim 19, wherein the storage address is the storage address of the second file package in the content delivery network.

21. An apparatus for loading a file package, applied to a client running a React Native application, comprising: The file package acquisition module is used to acquire a second file package in response to a file package acquisition instruction detected on the first page, wherein the first page is generated by the React Native application client loading the first file package; A file package loading module is used to load the second file package. The first file package and the second file package are generated in response to preset conditions and according to the dependencies between multiple module files. The multiple module files include at least one intermediate file and an entry file that depends on the intermediate file. The preset conditions include: the intermediate files include dynamic intermediate files and static intermediate files; the dynamic intermediate files are dynamically imported into the entry file; each module file is used to record the code of the React Native application; the first file package and the second file package are generated by the Metro tool in the same serialization stage, each corresponding to a second file package of the dynamic intermediate file; a first file package corresponding to the entry file is generated based on each second file package; the static intermediate file is statically imported into the entry file and packaged into the first file package.

22. The apparatus of claim 21, wherein the file package acquisition instruction is generated by a first triggering operation of the first page facing the client.

23. The apparatus according to claim 21, wherein the file package acquisition module is further configured to: Determine the storage address of the second file package corresponding to the file package acquisition instruction, and download the second file package from the storage address.

24. The apparatus according to claim 23, wherein the file package acquisition module is further configured to: Generate the HTTP request header based on the storage address; The second file package is obtained by sending the HTTP request.

25. The apparatus according to claim 21, wherein the file package loading module is further configured to: Load the second file package in the runtime environment of the first file package.

26. The apparatus according to claim 25, wherein the file package loading module is further configured to: The second file package is loaded in the client container that loads the first file package.

27. The apparatus of claim 25, wherein the first code recorded in the first file package and the second code recorded in the second file package are written in JavaScript, and the file package loading module is further configured to: Generate a Function() function containing the second code, and execute the Function() function in the context of the first code.

28. The apparatus of claim 21, further comprising: The page refresh module is used to refresh the first page based on the loading result of the second file package; or, The page redirection module is used to redirect to the second page based on the loading result of the second file package, and in response to the second trigger operation on the second page, refresh the first page or redirect to the third page according to the corresponding operation result.

29. A medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of claims 1-14.

30. A computing device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-14 by executing the executable instructions.

Images