WO2022099459A1

WO2022099459A1 - Webassembly loading method and apparatus, and storage medium

Info

Publication number: WO2022099459A1
Application number: PCT/CN2020/127814
Authority: WO
Inventors: 熊智; 马健; 温书豪; 赖力鹏
Original assignee: 深圳晶泰科技有限公司
Priority date: 2020-11-10
Filing date: 2020-11-10
Publication date: 2022-05-19

Abstract

A WebAssembly loading method and apparatus, and a storage medium, comprising the following steps: A1: compiling a c++ source code into a wasm file and a middle-layer build.js file by using an emscripten compiler; A2: reading binary content of the wasm file, compressing the content, and converting the compressed content into a hexadecimal character string; A3: reading middle-layer build.js content, and merging same with a converted wasm character string; A4: performing encapsulation, and adding automatic decompression code in front of the merged character string; A5: storing encapsulated character string content to a local file, thereby completing the whole building process.

Description

A WebAssembly loading method, device and storage medium

technical field

The invention belongs to the technical field of WebAssembly loading, and in particular relates to a WebAssembly loading method, device and storage medium.

Background technique

Using WebAssembly can run code faster on web applications, which has the following characteristics: File loading - WebAssembly files are smaller in size, so downloads are faster.

Parsing - Decoding WebAssembly is faster than parsing JavaScript.

Compilation and optimization - Less time is required for compilation and optimization because more optimizations are already done before the file is pushed to the server, JavaScript needs to compile the code multiple times for dynamic types.

Re-optimization - WebAssembly code does not need to be re-optimized because the compiler has enough information to get the correct code on the first run.

Execution - Execution can be faster, with WebAssembly instructions closer to machine code.

Garbage collection - Currently WebAssembly does not directly support garbage collection, garbage collection is manually controlled, so it is more efficient than automatic garbage collection.

WebAssembly was officially incorporated into the W3C standard in December 2019, and its application in the front-end field has gradually become popular. The mainstream application method in the industry is: compile the C++ source code into the wasm file and the middle-layer build.js file through the emscripten compiler; Layer build.js file; the build.js file completes the loading of wasm through network requests; in this way, WebAssembly is loaded in web applications.

The loading process of the prior art is shown in Figure 1 and Figure 2. The shortcomings of the above methods: the compatibility of the front-end modularization is not good, and the wasm file cannot be completely decoupled from the web application. For a single-page web application (SPA), You need to separate the wasm file and deploy it to the same directory as the static file. The operation is cumbersome, and the speed of asynchronously requesting the wasm file through the network is greatly affected by the network environment, which is not conducive to the development experience and user experience.

SUMMARY OF THE INVENTION

In order to solve the above technical problems, the present invention provides a modularized WebAssembly construction process, including the following steps:

A1, the emscripten compiler compiles the C++ source code into the wasm file and the middle layer build.js file;

A2, read the binary content of the wasm file, compress the content, and then convert it into a hexadecimal string;

A3, read the content of build.js in the middle layer and merge it with the converted wasm string;

A4, encapsulate, inject automatic decompression code in front of the merged string;

A5, save the encapsulated string content to a local file to complete the entire construction process.

Among them, the existing technology is used for compiling, and the compiling tool used is the "emscripten compiler".

Preferably, in the step A4, the function of the encapsulation code is the reverse process of A2: extract the compressed content from the hexadecimal, and then decompress it. The content obtained after decompression is the original binary content of the wasm file, and the wasm binary The content is assigned to the Module global variable.

Preferably, in the step A4, the merging is to add the encapsulated code or string to the front of the build.js content or string, and then save it as a local file, that is, build the generated file, that is, step A5.

Correspondingly, the present invention also provides a loading process of WebAssembly, including the following steps:

B1, after the built generated file is loaded into the web browser, it will be parsed and executed;

B2, during the execution process, the automatic decompression code encapsulated at the time of construction will be automatically run, and the wasm content will be decompressed and instantiated to complete the loading process.

Preferably, in the step B1, the parsing is automatically completed by the browser. After the "constructed javascript file" is loaded into the browser, the browser will automatically parse and execute the content of the javascript file

Preferably, when the browser executes "build the generated file", it first executes the code encapsulated in step A4: first extracts the compressed content from the hexadecimal string, and then decompresses the compressed content to obtain the wasm binary content , and assign it to the Module global variable. This process completes the decompression and executes the "build generated file", the "intermediate layer build.js" code compiled and generated by emscripten will be executed, and the middle layer will determine whether the wasm binary content already exists in the Module global variable. If it does not exist, load the wasm binary content through the http network, and instantiate it after the loading is complete; if it exists, directly use the wasm binary content in the Module global variable for instantiation. The instantiation method is provided by the web browser.

Since the wasm binary content has been stored in the Module global variable in the step A4, the intermediate layer code will directly use the binary content for instantiation. Complete the loading process. During the parsing and loading process, the middle-tier code "build.js" can directly use the wasm binary content extracted from the package, and does not require additional HTTP network requests to load the wasm binary content. Therefore, the web application only needs to deploy the "build-generated (javascript) file" together. For a single-page web application, the "build-generated (javascript) file" can also be built into the web single-page file together without deployment. wasm binary file, which realizes the decoupling of web application and wasm file.

The present invention also provides a WebAssembl loading device, comprising:

Compile module: use emscripten compiler to compile C++ source code into wasm file and middle layer build.js file;

The first reading module: read the binary content of the wasm file, compress the content, and then convert it into a hexadecimal string;

The second reading module: read the content of build.js in the middle layer and merge it with the converted wasm string;

Processing module: encapsulate, inject automatic decompression code in front of the merged string;

Save module: Save the encapsulated string content to a local file.

A storage medium on which a computer program is stored, and when the computer program is executed by a processor, implements the loading method of the present invention.

A loading device includes a memory, a processor, and a computer program stored on the memory and running on the processor, and the processor implements the loading method of the present invention when the processor executes the computer program.

The present invention brings following beneficial effects:

1. By merging the wasm file and the built target file, the merged target file can be independently published and deployed as a module; during the parsing and loading process, the middle layer code "build.js" can be directly extracted from the package using The wasm binary content does not require additional HTTP network requests to load the wasm binary content. Therefore, the web application only needs to deploy the "build-generated (javascript) file" together. For a single-page web application, the "build-generated (javascript) file" can also be built into the web single-page file together without deployment. wasm binary file, which realizes the decoupling of web application and wasm file.

2. The process of requesting wasm files from a separate network is removed, which improves the loading speed.

3. The present invention is compatible with the Web, Electron, and Node operating environments, and the combined modules are introduced in the same way. Here "same method" refers to the method of loading the wasm binary. For the existing technology: on the web/electron side, the wasm binary content is loaded separately through the http network, and on the node side, the wasm binary content is obtained by reading a local file. Therefore, it is necessary to deploy the wasm binary file in different ways for different operating environments, that is, deploy the wasm file to the web server in the web/electron environment, and deploy the wasm file to the corresponding file directory in the node environment.

4. For the method of the present invention: Since the wasm binary file has been encapsulated into the "build-generated file", and the build-generated file can be directly called by other js or merged into other js files, there is no need to do different deployments for different environments .

Description of drawings

Figure 1 shows the loading process of the prior art.

Figure 2 shows the loading process of the prior art.

Figure 3 illustrates the construction of the method.

Figure 4 is a loading process in the method of the present invention.

Detailed ways

Below in conjunction with the accompanying drawings, the preferred embodiments of the present invention are described in further detail:

Figure 3 illustrates the construction of the method. First, use the emscripten compiler to compile the C++ source code into the wasm file and the middle-tier build.js file. Read the binary content of the wasm file, compress the content, and convert it to a hexadecimal string. Read the middle layer build.js content and merge it with the converted wasm string. Then encapsulate and inject automatic decompression code in front of the merged string. Save the encapsulated string content to a local file to complete the entire build process.

Figure 4 illustrates the loading process. After the built generated file is loaded into the web browser, it will be parsed and executed. During the execution process, the automatic decompression code encapsulated during construction will be automatically run, and the wasm content will be decompressed and instantiated to complete the loading process.

Example 1

RDKit is a suite of open source chemical informatics software that supports the manipulation, modification and format conversion of molecules. In the XFEP and Universal Force Field projects, 2D images of a batch of chemical molecules need to be displayed on the human-computer interface. The RDKit tool was used in the project to convert the raw data of chemical molecules into 2D image data for display on the human-computer interface. In the implementation process, the technical scheme described in the method is adopted, and the concrete steps are as follows:

1. Use the emscripten compiler to compile the c++ source code of RDKit into the rdkit.wasm file and the middle layer build.js file;

2. Read the binary content of the rdkit.wasm file, compress the content, and then convert it to a hexadecimal string;

3. Read the content of build.js in the middle layer and merge it with the converted wasm string;

4. Encapsulate and inject automatic decompression code in front of the merged string;

5. Save the encapsulated string content as a local file rdkit.js to complete the entire construction process;

6. Deploy the production file (rdkit.js) together with the human-computer interface software code (front-end code) to the production environment (user PC);

7. When the user opens the human-computer interaction software, rdkit.js is loaded into the software and executed automatically;

8. After executing rdkit.js, the content of rdkit.wasm is decompressed and extracted, and instantiated;

9. The human-computer interaction software converts the chemical molecule data into 2D images through the instantiated rdkit, and displays them on the interface;

10. The above is the process from building wasm to loading and using it.

Example 2

Crystal Database is a set of report visualization software. The visual interface displays the reported molecular statistics charts and molecular 3D views to the user. The software runs in the WEB browser environment. The force algorithm library is used in the project to convert the raw data of chemical molecules into a 3D visual data structure. In the implementation process, the technical solution described in the method is adopted, and the specific steps are as follows:

1. Use the emscripten compiler to compile theforce's C++ source code into theforce.wasm file and the middle layer build.js file;

2. Read the binary content of theforce.wasm file, compress the content, and then convert it into a hexadecimal string;

5. Save the encapsulated string content as a local file theforce.js to complete the entire construction process;

6. Deploy the production file (thefroce.js) together with the visual interface software code (front-end code) to the production environment (WEB server);

7. When the user accesses the crystal database website through the browser, the visual interface software and thefroce.js are loaded into the browser and executed automatically;

8. After executing theforce.js, the content of theforce.wasm is decompressed and extracted, and instantiated;

9. The visualization software converts the chemical molecule data into 3D visualization data through the instantiated theforce, and displays it in 3D on the interface;

10. The above is the process from building wasm to loading and using it.

Example 3:

The XRD client is a set of software for the visualization of X-ray diffraction files (referred to as XRD files). The xrdio third-party open source library is used in the project to convert the original data of different types of xrd files into a common data structure for easy display. In the implementation process, the technical solution described in the method is adopted, and the specific steps are as follows:

1. Use the emscripten compiler to compile the C++ source code of xrdio into the xrdio.wasm file and the middle layer build.js file;

2. Read the binary content of the xrdio.wasm file, compress the content, and then convert it to a hexadecimal string;

5. Save the encapsulated string content as a local file xrdio.js to complete the entire construction process;

6. Deploy the production file (xrdio.js) together with the visual interface software code (front-end code) to the production environment (user's local computer);

7. When the user opens the XRD client software, the visual interface software and xrdio.js are loaded into the client and executed automatically;

8. After executing xrdio.js, the content of xrdio.wasm is decompressed and extracted, and instantiated;

9. The visualization software converts the original data of different types of xrd files into a common data structure through the instantiated xrdio, and displays them in the overlapping view and parallel view;

10. The above is the process from building wasm to loading and using it.

The above content is a further detailed description of the present invention in combination with specific preferred embodiments, and it cannot be considered that the specific implementation of the present invention is limited to these descriptions. For those of ordinary skill in the technical field of the present invention, without departing from the concept of the present invention, some simple deductions or substitutions can be made, which should be regarded as belonging to the protection scope of the present invention.

Claims

A construction process of WebAssembly, characterized in that it includes the following steps:

A1: Use the emscripten compiler to compile the C++ source code into the wasm file and the middle layer build.js file;

A2, read the binary content of the wasm file, compress the content, and then convert it into a hexadecimal string;

A3, read the content of build.js in the middle layer and merge it with the converted wasm string;

A4, encapsulate, inject automatic decompression code in front of the merged string;

A5, save the encapsulated string content to a local file to complete the entire construction process.
The construction process according to claim 1, wherein, in the step A4, the function of the encapsulation code is the reverse process of A2: extract the compressed content from the hexadecimal, and then decompress it, and the content obtained after decompression is For the original binary content of the wasm file, assign the wasm binary content to the Module global variable.
The construction process according to claim 1, wherein, in the step A4, merging is to add the packaged code or string to the front of the build.js content or string.
A loading process of WebAssembly as claimed in claim 1, is characterized in that, comprises the steps:

B1, after the built generated file is loaded into the web browser, it will be parsed and executed;

B2, the automatic decompression code encapsulated at build time will be automatically run during the execution process to decompress and instantiate the wasm content.
The loading process according to claim 4, wherein in the step B1, the parsing is automatically completed by the browser, and the browser will automatically parse after the "constructed javascript file" is loaded into the browser and execute the content of that javascript file.
The loading process according to claim 4, wherein, when the browser executes "build the generated file", the following steps are included:

Execute the code encapsulated in step A4: first extract the compressed content from the hexadecimal string;

Decompress the content to be compressed, get the wasm binary content, and assign it to the Module global variable.
The method according to claim 4, characterized in that, after the process is decompressed, and after executing "build the generated file", the middle layer code compiled and generated by emscripten will be executed, and the middle layer will judge whether the module global variable has been The wasm binary content exists; if it does not exist, the wasm binary content is loaded through the http network, and then instantiated after the loading is completed; if it exists, the wasm binary content in the Module global variable is directly used for instantiation.
A WebAssembl loading device, comprising:

Compile module: use emscripten compiler to compile C++ source code into wasm file and middle layer build.js file;

The first reading module: read the binary content of the wasm file, compress the content, and then convert it into a hexadecimal string;

The second reading module: reads the content of build.js in the middle layer and merges it with the converted wasm string; processing module: encapsulates and injects automatic decompression code in front of the merged string;

Save module: Save the encapsulated string content to a local file.
A storage medium on which a computer program is stored, characterized in that, when the computer program is executed by a processor, the loading method according to claim 4 is implemented.
A loading device, comprising a memory, a processor and a computer program stored on the memory and running on the processor, wherein the processor implements the computer program according to claim 4 when the processor executes the computer program Load method.