CN116414378A - Page packaging method, page loading method and device based on WeexSDK frame - Google Patents
Page packaging method, page loading method and device based on WeexSDK frame Download PDFInfo
- Publication number
- CN116414378A CN116414378A CN202111642287.4A CN202111642287A CN116414378A CN 116414378 A CN116414378 A CN 116414378A CN 202111642287 A CN202111642287 A CN 202111642287A CN 116414378 A CN116414378 A CN 116414378A
- Authority
- CN
- China
- Prior art keywords
- page
- pages
- code
- file
- packaging
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000004806 packaging method and process Methods 0.000 title claims abstract description 118
- 238000000034 method Methods 0.000 title claims abstract description 55
- 238000011068 loading method Methods 0.000 title claims abstract description 44
- 238000013507 mapping Methods 0.000 claims description 26
- 238000012856 packing Methods 0.000 claims description 25
- 238000012545 processing Methods 0.000 claims description 10
- 238000010586 diagram Methods 0.000 description 11
- 230000008569 process Effects 0.000 description 9
- 238000010276 construction Methods 0.000 description 6
- 230000003190 augmentative effect Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000014759 maintenance of location Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 238000012858 packaging process Methods 0.000 description 2
- 239000013585 weight reducing agent Substances 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000009191 jumping Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/36—Software reuse
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
- G06F9/44526—Plug-ins; Add-ons
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application discloses a page packaging method, a page loading method and a page loading device based on a WeexSDK frame, wherein the method comprises the following steps: determining a storage path of codes of a plurality of pages to be packaged; determining a business code and a public code of each page based on a storage path of each page in the plurality of pages; and packaging the business codes of each page in the plurality of pages into a packaging file, and packaging one part of each kind of public codes in the public codes called by the plurality of pages into the packaging file. The file package volume after the WeexSDK framework is constructed can be greatly reduced.
Description
Technical Field
The application belongs to the technical field of file processing, and particularly relates to a page packaging method, a page loading method and a page loading device based on a WeexSDK frame.
Background
With the continuous development of Hybird technology on a mobile terminal, the Hybird scheme is widely bloomed on the mobile terminal, and a WeexSDK framework aims to enable a developer to build Android, iOS and Web applications based on the modern advanced Web development technology by using JavaScript language and a modern popular front-end framework. Too large a code volume can cause the user to consume excessive traffic and time when downloading, resulting in a very poor user experience. The WeexSDK provides both routing capabilities to support routing to interface classes using native page frames and routing to interface classes using custom page frames. However, both routing capabilities cannot solve the problem of excessive volume of the packet after the construction of the WeexSDK.
Disclosure of Invention
The application provides a page packaging method, a page loading method and a page loading device based on a WeexSDK frame, so that the volume of a file package constructed by the WeexSDK frame is greatly reduced.
In order to solve the above problems, the present application proposes a web page packaging method based on a WeexSDK framework, which includes:
determining a storage path of codes of a plurality of pages to be packaged;
determining a business code and a public code of each page based on a storage path of each page in the plurality of pages;
and packaging the business codes of each page in the plurality of pages into a packaging file, and packaging one part of each kind of public codes in the public codes called by the plurality of pages into the packaging file.
Wherein the step of determining the storage path of the codes of the plurality of pages to be packed comprises:
processing an entry in a Webpack configuration based on a storage path of the code of the plurality of pages;
and based on the processed entry, executing the steps of determining the business code and the public code of each page based on the storage path of each page in the plurality of pages, packaging the business code of each page in the plurality of pages into a packaging file, and packaging one part of each kind of public code in the public codes called by the plurality of pages into the packaging file.
The step of processing the entry in the weback configuration based on the storage paths of the codes of the plurality of pages to be packaged comprises the following steps:
registering each page in the plurality of pages into a page template in the form of a sub-component based on the storage paths of codes of the plurality of pages to generate a page entry;
and taking the page inlet as an inlet in the Webpack configuration.
Wherein the step of determining the service code and the common code of each page based on the storage path of each page of the plurality of pages includes:
determining a path of a current page to be packaged from an entry in the Webpack configuration;
and regularly intercepting the path of the current page to be packaged to obtain the storage path of the code of the current page to be packaged.
Wherein the method further comprises:
and writing the corresponding relation between the information of each page and the information of the packaging file into a path mapping file.
Wherein the method further comprises:
and writing the corresponding relation between the information of each page and the identification of the service code of each page into the path mapping file.
Wherein the step of determining the storage path of the codes of the plurality of pages to be packed comprises:
determining a storage path of codes of the pages, and dividing all the pages to be packaged into at least one group of page groups;
the step of packaging the business codes of each page in the plurality of pages into a packaging file, and packaging one copy of each kind of common codes in the common codes called by the plurality of pages into the packaging file comprises the following steps:
and packaging the business codes of all pages in each page group into a packaging file, and packaging one part of all kinds of common codes called by all pages in each page group into the packaging file.
Wherein the step of dividing all pages to be packaged into at least one group of pages comprises:
dividing all pages to be packaged into at least one group of page groups according to the quantity; or alternatively, the first and second heat exchangers may be,
multiple pages in the same memory path are divided into the same page group.
In order to solve the above problems, the present application proposes a page loading method, which includes:
determining a storage path of a packaging file of codes packaged with the pages to be loaded, wherein a plurality of pages are packaged in the packaging file, and the number of files shared by at least two pages in the packaging file is 1;
searching the packaging file based on the storage path;
and loading codes of the pages to be loaded from the packaging file to finish loading of the pages to be loaded.
The step of loading the code of the page to be loaded from the packaging file comprises the following steps:
obtaining a path mapping file of the packaging file;
searching the identification of the code corresponding to the identification of the page to be loaded from the path mapping file;
and loading and running the code of the page to be loaded from the packaging file based on the identification of the code.
In order to solve the above problems, the present application proposes an electronic device, including a processor and a memory, where the memory stores program instructions, and the processor is configured to execute the program instructions to implement the above identification method.
To solve the above-described problems, the present application proposes a computer storage medium in which program instructions are stored, the program instructions being executed to implement the above-described identification method.
The page packaging method based on the WeexSDK framework comprises the following steps: the service codes and the public codes of a plurality of pages are packaged into a packaged file, the number of the public codes in the packaged file is 1, and therefore, each preset public code in the packaged file is only one, wherein the preset public code is a public code called by at least two pages in the plurality of pages, so that the same public code of at least two pages is not rewritten into the packaged file, the volume of a file package constructed by a WeexSDK framework can be greatly reduced, the flow and time of downloading loss can be greatly reduced when a user downloads or updates the file package, the user experience is improved, the occupation of disk space of the user terminal is smaller, the user unloading application probability is reduced, and the user retention success rate is increased.
Drawings
FIG. 1 is a schematic diagram of an implementation of a web page packaging method based on a WeexSDK framework in an application scenario;
FIG. 2 is a flow diagram of one embodiment of a web page packaging method based on the WeexSDK framework of the present application;
FIG. 3 is a schematic diagram of an implementation of the web page packaging method based on the WeexSDK framework in another application scenario;
FIG. 4 is a schematic diagram of implementation effects of the web page packaging method based on the WeexSDK framework;
FIG. 5 is a flow diagram of another embodiment of a web page packaging method based on the WeexSDK framework of the present application;
FIG. 6 is a flow diagram of one embodiment of a web page loading method based on the WeexSDK framework of the present application;
FIG. 7 is a flow diagram of one embodiment of a web page loading method based on the WeexSDK framework of the present application;
FIG. 8 is a schematic diagram of path conversion in the web-based page loading method of the present application;
FIG. 9 is a schematic diagram of an embodiment of an electronic device of the present application;
FIG. 10 is a schematic diagram of a framework of one embodiment of the computer storage media of the present application.
Detailed Description
The technical solutions of the present application are described in further detail below with reference to the accompanying drawings and examples, which are not to be construed as limiting the present application.
For the purpose of making the objects, technical solutions and advantages of the present application more apparent, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.
As shown in fig. 1, in the prior art construction scheme of page files based on the WeexSDK framework, each page file is constructed separately, that is, all files of each page are packaged separately into one page file, and each page file thus constructed contains a large amount of common codes. When there are more pages of a plug-in or application, the entire plug-in package or application package becomes very bulky. When the application is used for offline downloading of the compressed package, the downloading resource and time are occupied, and the hard disk space of the mobile phone is occupied.
In Android or iOS, a dynamic library is generally built by common codes to perform weight reduction on a file package of an application, so that the dynamic library can be shared across processes to achieve a weight reduction effect. The application packages are typically thinned in the Web in such a way that the common code is pulled out as a single file and introduced in the business code. However, because the WeexSDK framework is limited, the common code cannot be introduced into the business code in a dynamic library or a single file mode when the page is loaded, namely, the method for slimming the file package of Android, iOS and Web cannot be applied to a page file packaging scheme (namely, a project construction scheme) based on the WeexSDK framework.
Based on this, the application proposes a page packaging method based on a WeexSDK framework, as shown in fig. 1, the method packages service codes and public codes of a plurality of pages into a packaging file, and the number of parts of each public code in the packaging file is 1, so that each preset public code in the packaging file is only one part, wherein the preset public code is a public code called by at least two pages in the plurality of pages, so that the same public code of at least two pages is not rewritten into the packaging file, the package volume of the file after the construction of the WeexSDK framework can be greatly reduced, the flow and time of downloading loss can be greatly reduced when a user downloads or updates, the user experience is improved, the disk space occupation of the user terminal is smaller, the application unloading probability of the user is reduced, and the user retention success rate is increased.
As shown in fig. 2, the page packaging method based on the WeexSDK framework in this embodiment specifically includes the following steps. It should be noted that the following step numbers are only for simplifying the description, and are not intended to limit the execution order of the steps, and the execution order of the steps of the present embodiment may be arbitrarily changed without departing from the technical idea of the present application.
S101: a storage path for code of a plurality of pages to be packaged is determined.
The storage paths of the codes of the plurality of pages to be packaged can be determined first, so that the service codes and the common codes of each page can be queried based on the storage paths of the codes of each page, and then the service codes and the common codes of all the pages can be packaged into one packaging file.
Optionally, each page may include a service code for each page and at least one common code invoked by the service code. The service code of the page can bear information such as layout of the page. And the common code may refer to common function code that may be invoked.
In this case, in step S101, a storage path of the service code of each page to be packaged may be determined. Of course, in other alternative embodiments, in step S101, it may be determined a storage path of the service code and the common code of each page to be packaged.
S102: the traffic code and the common code for each page are determined based on the storage path of each page.
Wherein, after determining the storage path of the code of each page based on step S101, the service code and the common code of each page may be determined based on the storage path of each page, so that the service codes and the common codes of a plurality of pages to be packaged are subsequently packaged into one package file.
In an implementation manner, the step S101 determines a storage path of the service code of each page, so that the service code of each page can be queried based on the storage path of the service code of each page, and then the service code of each page can be parsed to determine all the common codes called by the service code of each page.
In another possible manner, the step S101 determines the storage paths of the service code and the common code of each page to be packaged, so that the service code of each page can be queried based on the storage path of the service code of each page, and the common code of each page can be queried based on the storage path of the common code of each page.
S103: the business codes and the common codes of a plurality of pages are packaged into a package file.
After determining the service code and the common code of each of the plurality of pages based on the steps, the common code and the service code of the plurality of pages may be packaged into a package file.
In step S103, the service code of each page in the plurality of pages may be written into the packaging file, and each kind of common code in the common codes called by the plurality of pages is packaged into one part to the packaging file, so that the number of parts of each common code in the packaging file is 1, that is, each preset common code in the packaging file also has only one part, where the preset common code is the common code called by at least two pages in the plurality of pages, so that the preset common code is not rewritten into the packaging file, the package volume of the file after the WeexSDK framework is constructed can be greatly reduced, and because the service code and the common code of each page are in the same packaging file, the service code can normally call the common code in the same packaging file when the page is loaded, so that the packaging file constructed based on the page packaging method of the application normally loads the page, and the problem that the file cannot be normally loaded due to the application of the Android, iOS and Web application method to the wesdk framework can not occur.
If the codes in the two public codes are identical, the two public codes are the same type of public codes; if the codes in the two common codes are different, the two common codes are different kinds of common codes. To facilitate distinguishing between different kinds of common codes, each common code may be provided with a unique identification, so that based on the identification of the common code, it is possible to know what the common code called by the service code is, and to facilitate querying the common code called by the service code from the package file. It will be appreciated that each service code may also be provided with a unique identification.
The term "common code called by a plurality of pages" refers to a union of common codes called by a plurality of pages. For example, as shown in fig. 3, page 1 includes a service code 1, a common code 1, and a common code 3; page 2 includes business code 2, public code 2 and public code 6; page 3 includes business code 3, public code 1 and public code 4; the page 4 includes the service code 4, the common code 3 and the common code 5, so that the common codes called by the page 1-page 4 are six kinds of common codes, namely, the common code 1, the common code 2, the common code 3, the common code 4, the common code 5 and the common code 6, and thus in step S103, the 6 kinds of common codes are packaged into one package, so that the problem that the package volume of the plug-in package or the application package is too large due to repeated calling of the common code 1 and the common code 3 can be reduced, and the plug-in package or the application package can be thinned.
Specifically, the packing process of step S103 may specifically include: the business codes of each page are written into the packaging file, and the public codes of each page, which are different from the existing public codes in the packaging file, are written into the packaging file, so that the purpose of packaging one part of each kind of public codes in the public codes called by a plurality of pages into the packaging file can be realized, each preset public code cannot be repeatedly written into the packaging file, and the package volume of the file after the construction of the WeexSDK framework can be greatly reduced as shown in FIG. 4.
Further, in order to facilitate loading a page, the path mapping file of the page and the packaging file can be determined in the process of the page packaging method based on the WeexSDK framework, so that when the page is loaded, the device can inquire the packaging file containing the code of the page, and then inquire the service code and the public code of the page in the packaging file, so as to complete the page loading. Specifically, as shown in fig. 5, the web page packaging method based on the WeexSDK framework of this embodiment may include the following steps. It should be noted that the following step numbers are only for simplifying the description, and are not intended to limit the execution order of the steps, and the execution order of the steps of the present embodiment may be arbitrarily changed without departing from the technical idea of the present application.
S201: and determining all pages to be packaged, and dividing all the pages to be packaged into at least one page group according to a preset rule.
Optionally, in step S201, all the pages to be packaged may be determined, and the pages to be packaged may be divided into at least one page group according to a preset rule, and storage paths of codes of a plurality of pages in each page group are determined, so that service codes and common codes of the plurality of pages in each page group are packaged into one package file, and a package file of each page group is obtained.
Wherein, all the pages to be packaged can refer to at least part of pages of the same plug-in or the same application.
The preset rule may be set according to actual situations, and is not limited herein.
For example, all pages to be packaged may be divided into at least one page group according to a quantity average rule.
For another example, the division may be performed according to a hierarchical structure of file targets where the engineering is located. Specifically, the storage paths of codes of all pages to be packed may be determined first, and then a plurality of pages under the same storage path may be divided into the same page group.
After grouping is completed based on the scheme, the entries in the Webpack configuration can be processed according to the grouping condition; in this way, the weback will construct a package file with the entry in the processed weback configuration as the starting point of the construction (i.e. execute step S202 and step S203), that is, construct a package file based on the entry in the weback configuration, so that multiple pages of each page group can be packaged into one package file according to the page packaging method of the present application.
Specifically, the processing manner of the entry in the weback configuration may be: registering all pages under each page group in a page template of each page group in the form of sub-components, and generating a page entry of each page group; and taking the page entry of each processed page group as an entry in the Webpack configuration.
Specifically, before processing the entry in the weback configuration, a storage path of the code of each page in each page group may be obtained; in the process of processing the entry in the Webpack configuration, all pages under each page group are registered in the page template of each page group in the form of sub-components based on the storage paths of codes of the pages in each page group, so that the page entry of each page group is obtained.
Specifically, the storage path of the codes of the respective pages in each page group may be determined by means of manual confirmation. Alternatively, the memory path of the code of each page may be determined based on the initial entry of the Webpack configuration. Specifically, a file path corresponding to the initial entry may be obtained, and then a storage path of a code of a page to be loaded may be regularly intercepted.
S202: the service codes and common codes for the individual pages in each page group are determined based on the stored paths.
After the page groups are determined based on the steps, the service codes and the common codes of the pages in each page group can be determined based on the storage paths of the codes of the pages in each page group, so that the service codes and the common codes of all the pages in each page group can be packaged into a packaging file to obtain the packaging file of each page group.
When executing step S202 and step S203, the service code and the common code of each page may be queried sequentially based on the storage path of the code of each page, and then the queried service code and the common code different from the existing common code in the package file may be written into the package file.
Specifically, the storage path of the code of the current page to be packaged may be determined from entry in the weback configuration (i.e., the page entry of the page group to which the current page to be packaged belongs). Specifically, a file path of a current page to be packaged may be determined from entries in the weback configuration; and then intercepting file paths of the page to be packaged in a regular interception mode and the like to obtain a storage path of codes of the current page to be packaged.
S203: and packaging the service codes and the common codes of all the pages in each page group, and constructing a path mapping file of the pages and the packaged file.
In the process of packaging the service codes and the common codes of all the pages in each page group into one packaging file, the path mapping files of the pages and the packaging files can be constructed, so that when the pages are subsequently loaded, the equipment can inquire the packaging file containing the codes of the pages based on the path mapping files of the pages and the packaging files, and then inquire the service codes and the common codes of the pages in the packaging file, so that the page loading is completed.
In the process of packing the service codes and the common codes of all the pages in each page group into one packing file, the corresponding relation between the information (such as the identification of the page and/or the storage path of the page) of all the pages in each page group and the information (such as the identification of the packing file and/or the storage path of the packing file) of the packing file can be written into the path mapping file of the page and the packing file, so that the packing file storing the codes of the page can be searched from the path mapping file when the relevant page is loaded, and then the codes of the page can be found from the packing file so as to complete the page loading.
In addition, the corresponding relation between the information (such as the identification of the page and/or the storage path of the page) of all the pages in each page group and the information (such as the identification information of the service code) of the page can be written into the path mapping file of the page and the packaging file, so that the service code of the page can be searched from the packaging file containing the page code based on the information of the page in the path mapping file and the information of the service code of the page when the relevant page is loaded, and the service code of the page can be executed so as to complete the page loading.
The various correspondences in the path map file may be automatically written by weback during the packaging process. And the path mapping file can be stored into the root path of the packaging file after the path mapping file is written, so that the path mapping file can be conveniently acquired during page loading to complete page loading.
In addition, in other alternative embodiments, the path map file described above may not be required to be constructed. Specifically, in the packing process, if the identifier and the storage path of the page to be skipped (hereinafter, simply referred to as the lower page) exist in the service code of the current page to be packed, the storage path of the lower page in the service code of the current page to be packed may be updated to the storage path of the packing file where the code of the lower page is located, so that under the condition of skipping from the current page to the lower page, the packing file where the lower page code is located may be directly queried based on the storage path of the packing file where the code of the lower page in the service code of the current page to be packed, and then the service code of the lower page may be queried from the packing file where the lower page code is located based on the identifier of the lower page, so as to complete the loading of the lower page.
Optionally, in the packaging process, the page and the service code of the page may have the same identifier, so that when the code of the page is found in the packaging file, the code with the same identifier can be found from the packaging file directly based on the identifier of the page, and thus, the corresponding relationship between the page and the identifier of the service code of the page is not required to be stored.
As shown in fig. 6, the present application further provides a page loading method, which is used for loading pages from an application package or a plug-in package obtained by using the above page packaging method based on the WeexSDK framework. Specifically, the page loading method of this embodiment may include the following steps. It should be noted that the following step numbers are only for simplifying the description, and are not intended to limit the execution order of the steps, and the execution order of the steps of the present embodiment may be arbitrarily changed without departing from the technical idea of the present application.
S301: a storage path of the packaged file that is packaged with the page to be loaded is determined.
The storage path of the packing file of the code packing the page to be loaded can be determined firstly, then the packing file of the code packing the page to be loaded is inquired based on the storage path, then the code of the page to be loaded is inquired from the packing file, and then the code of the page to be loaded can be operated to finish the loading of the page to be loaded.
Alternatively, the storage path of the package file containing the code of the page to be loaded may be queried through the identification of the page to be loaded or the storage path based on the correspondence between the information of the page to be loaded in the path mapping file and the storage path of the package file. In addition, in this embodiment, as shown in fig. 7, when the plug-in or the application is opened, it may be first confirmed whether the plug-in package or the application package includes the path mapping file (i.e., the pageMapping shown in fig. 7); if the path mapping file is included, executing step S301 and the subsequent steps to finish loading the page to be loaded; if the physical page cannot be obtained in the loading process, indicating that the real page cannot be found, and reporting an exception; if the plug-in package or the application package does not contain the path mapping file, the plug-in package or the application package constructed in a mode that each page is individually packaged into a file is described, and the existing loading logic can be used for directly jumping the weex plug-in to complete the loading of the page to be loaded.
In other alternative embodiments, the identifier of the page to be loaded and the storage path of the packaging file packaging the page to be loaded are stored in the service code of the upper page of the page to be loaded, so that the storage path of the packaging file packaging the page to be loaded can be directly obtained from the service code of the upper page of the page to be loaded.
S302: and searching the packaged file based on the storage path.
S303: and loading codes of the pages to be loaded from the packaging file to finish loading of the pages to be loaded.
After the packing file is found based on the steps, the code of the page to be loaded can be found from the packing file so as to run the code to finish loading the page to be loaded.
Optionally, the identification of the service code of the page to be loaded can be queried through the identification of the page to be loaded or the information such as the path and the like based on the information of the page to be loaded and the identification of the service code of the page to be loaded in the path mapping file, and then the service code of the page to be loaded is found from the packaging file based on the identification of the service code of the page to be loaded. Specifically, in the implementation process of the device, as shown in fig. 8, a path mapping file under the root path of the package file can be obtained through the storage path of the package file; traversing the path mapping file, and finding a sub-component identifier of the page to be loaded (which can be the identifier of the page to be loaded or the identifier of the service code of the page to be loaded); splicing the sub-component identification of the page to be loaded into a storage path of the packaging file to transfer the sub-component identification of the page to be loaded, so that service codes of the page to be loaded can be loaded from the packaging file based on the sub-component identification of the page to be loaded, and loading of the page to be loaded is completed.
In other alternative embodiments, the page to be loaded and the service code of the page to be loaded have the same identifier, so that the code having the same identifier as the page to be loaded can be directly searched from the packaging file, and the service code of the page to be loaded can be found.
After the code of the page to be loaded is found based on the method, the code of the page to be loaded can be run to finish loading of the page to be loaded.
Optionally, the service code of the page to be loaded can be run, and when the common code needs to be called, the common code needing to be called is searched and called from the packaging file based on the identification of the common code in the service code, so that the loading of the page to be loaded is completed.
When the page is loaded, the sub-assembly identification of the page to be loaded can be obtained according to the information in the storage path before the page view is created, so that the corresponding sub-assembly is loaded, and dynamic display is carried out by loading the sub-assembly in the form of a dynamic assembly.
Referring to fig. 9, the electronic device 70 of the present embodiment includes a memory 71 and a processor 72 coupled to each other, and the processor 72 is configured to execute program instructions stored in the memory 71 to implement the steps of the above-described method embodiment.
In one particular implementation scenario, electronic device 70 may include, but is not limited to: the microcomputer and the server, and the electronic device 70 may also include a mobile device such as a notebook computer and a tablet computer, which is not limited herein.
Specifically, the processor 72 is configured to control itself and the memory 71 to implement any of the above-described management methods of information or the steps of the display method embodiment of augmented reality. The processor 72 may also be referred to as a CPU (Central Processing Unit ). The processor 72 may be an integrated circuit chip having signal processing capabilities. The processor 72 may also be a general purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a Field programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. In addition, the processor 72 may be commonly implemented by an integrated circuit chip.
Referring to fig. 10, fig. 10 is a schematic diagram illustrating a framework of an embodiment of a computer readable storage medium according to the present application. The computer-readable storage medium 80 stores program instructions 81 that can be executed by a processor, the program instructions 81 being for implementing the steps of the management method or the augmented reality display method embodiment of any one of the above information.
The above embodiments are provided for illustrating the technical solution of the present application and not for limiting it, and those skilled in the art may make various corresponding changes and modifications according to the present application without departing from the spirit and essence of the present application, but they should fall within the scope of the claims appended hereto.
Claims (12)
1. A web page packaging method based on a WeexSDK framework, the method comprising:
determining a storage path of codes of a plurality of pages to be packaged;
determining a business code and a public code of each page based on a storage path of each page in the plurality of pages; common for various kinds of multiple calls
And packaging the business codes of each page in the plurality of pages into a packaging file, and packaging one part of each kind of public codes in the public codes called by the plurality of pages into the packaging file.
2. The method of claim 1, wherein the step of determining the storage path of the code for the plurality of pages to be packaged comprises:
processing an entry in a Webpack configuration based on a storage path of the code of the plurality of pages;
and based on the processed entry, executing the steps of determining the business code and the public code of each page based on the storage path of each page in the plurality of pages, packaging the business code of each page in the plurality of pages into a packaging file, and packaging one part of each kind of public code in the public codes called by the plurality of pages into the packaging file.
3. The method of claim 2, wherein the processing the entry in the weback configuration based on the memory path of the code of the plurality of pages to be packaged comprises:
registering each page in the plurality of pages into a page template in the form of a sub-component based on the storage paths of codes of the plurality of pages to generate a page entry;
and taking the page inlet as an inlet in the Webpack configuration.
4. The method of claim 2, wherein the step of determining the service code and the common code for each of the plurality of pages based on the memory path of each page comprises:
determining a path of a current page to be packaged from an entry in the Webpack configuration;
and regularly intercepting the path of the current page to be packaged to obtain the storage path of the code of the current page to be packaged.
5. The method according to claim 1, wherein the method further comprises:
and writing the corresponding relation between the information of each page and the information of the packaging file into a path mapping file.
6. The method of claim 5, wherein the method further comprises:
and writing the corresponding relation between the information of each page and the identification of the service code of each page into the path mapping file.
7. The method of claim 1, wherein the step of determining the storage path of the code for the plurality of pages to be packaged comprises:
determining a storage path of codes of the pages, and dividing all the pages to be packaged into at least one group of page groups;
the step of packaging the business codes of each page in the plurality of pages into a packaging file, and packaging one copy of each kind of common codes in the common codes called by the plurality of pages into the packaging file comprises the following steps:
and packaging the business codes of all pages in each page group into a packaging file, and packaging one part of all kinds of common codes called by all pages in each page group into the packaging file.
8. The method of claim 7, wherein the step of grouping all pages to be packaged into at least one group of pages comprises:
dividing all pages to be packaged into at least one group of page groups according to the quantity; or alternatively, the first and second heat exchangers may be,
multiple pages in the same memory path are divided into the same page group.
9. A web page loading method based on a WeexSDK framework, the method comprising:
determining a storage path of a packing file of codes packing pages to be loaded, wherein a plurality of pages are packed in the packing file, and the number of files shared by at least two pages in the packing file is 1;
searching the packaging file based on the storage path;
and loading codes of the pages to be loaded from the packaging file to finish loading of the pages to be loaded.
10. The method of claim 9, wherein the step of loading the code of the page to be loaded from the packaging file comprises:
obtaining a path mapping file of the packaging file;
searching the identification of the code corresponding to the identification of the page to be loaded from the path mapping file;
and loading and running the code of the page to be loaded from the packaging file based on the identification of the code.
11. An electronic device comprising a processor and a memory, the memory having stored therein program instructions for executing the program instructions to implement the method of any of claims 1-10.
12. A computer storage medium, characterized in that the computer storage medium has stored therein program instructions that are executed to implement the method of any of claims 1-10.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111642287.4A CN116414378A (en) | 2021-12-29 | 2021-12-29 | Page packaging method, page loading method and device based on WeexSDK frame |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111642287.4A CN116414378A (en) | 2021-12-29 | 2021-12-29 | Page packaging method, page loading method and device based on WeexSDK frame |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116414378A true CN116414378A (en) | 2023-07-11 |
Family
ID=87051446
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111642287.4A Pending CN116414378A (en) | 2021-12-29 | 2021-12-29 | Page packaging method, page loading method and device based on WeexSDK frame |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116414378A (en) |
-
2021
- 2021-12-29 CN CN202111642287.4A patent/CN116414378A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110704037B (en) | Rule engine implementation method and device | |
| CN112800095B (en) | Data processing method, device, equipment and storage medium | |
| CN107885540A (en) | A kind of method, apparatus and terminal of loading application programs static resource | |
| CN108647032B (en) | Application loading method and device, computer device and computer readable storage medium | |
| CN110908707B (en) | Resource packaging method, device, server and storage medium | |
| CN111400246B (en) | Asynchronous file import method, device, computer equipment and storage medium | |
| CN111506579B (en) | Method, program and equipment for generating intelligent contract code | |
| CN108062235B (en) | Data processing method and device | |
| CN111159278B (en) | Data display method and device, electronic equipment and computer readable storage medium | |
| CN111988429A (en) | Algorithm scheduling method and system | |
| CN112860412B (en) | Service data processing method and device, electronic equipment and storage medium | |
| CN117473949A (en) | Form dynamic layout method and system | |
| CN112306507A (en) | Picture resource processing method, device, terminal and storage medium | |
| CN111324645B (en) | Block chain data processing method and device | |
| CN109324838B (en) | Execution method and execution device of single chip microcomputer program and terminal | |
| CN111176715A (en) | Information calling method and server | |
| CN116414378A (en) | Page packaging method, page loading method and device based on WeexSDK frame | |
| CN115328457A (en) | Method and device for realizing form page based on parameter configuration | |
| CN113282541B (en) | File calling method and device and electronic equipment | |
| CN114358936A (en) | Intelligent contract operation method based on micro-service block chain | |
| CN113312075A (en) | Configuration information issuing method and device, storage medium and processor | |
| CN109213821B (en) | Data processing method and system | |
| CN110334098A (en) | A kind of database combining method and system based on script | |
| CN113282624B (en) | Rule matching method, device, electronic equipment and storage medium | |
| CN110968599B (en) | Inquiry method and device based on Impala |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |