Packaging method and device of front-end code, storage medium and electronic equipment

Abstract

The application provides a front-end code packaging method and device, a storage medium and an electronic device, and relates to the field of computers. When performing a packaging operation, the front-end source code is first parsed into an abstract syntax tree, and a statement node for importing a static resource is identified therefrom, and then an original absolute path is directly replaced by a relative path of the static resource, so that a desktop application generated therefrom performs logical block address offset addressing based on a host file directory as a reference, without the intervention of a main process for interception or cross-process communication, so as to avoid the overhead and timing race of inter-process communication and improve the stability when a large number of pictures are loaded.

Description

Technical Field

[0001] This application relates to the field of computers, and more specifically, to a method, apparatus, storage medium, and electronic device for packaging front-end code. Background Technology

[0002] Hybrid application container architecture combines the development efficiency of web technologies with the native capabilities of desktop applications. It supports rapid cross-platform iteration and can deeply call the underlying interfaces of the operating system, making it widely used in the development of industrial-grade terminal applications.

[0003] Taking the development of a smart terminal for battery management as an example, this terminal needs to display multi-dimensional indicators such as the operating status of thousands of battery packs, the health of battery swapping stations, and charging and discharging trajectories in real time. To ensure an offline exploration experience during high-density data analysis, the front-end web pages (based on frameworks such as Next.js) are usually packaged into a local asset package containing .html, js, css, and images / icons through static export mode, and the Electron main process renders the interface by loading the local index.html file.

[0004] In traditional web development, page references to static visual entities (e.g., status icon images) typically use absolute root path addresses. For example, in business code, this might be written as...<imgsrc=" / assets / icons / warning.png" / > When this code is run in a web browser (using the http: / / or https: / / protocol), the browser will interpret the first letter " / " as the root directory of the current site (e.g., http: / / localhost:3000 / assets / ...), and it will load correctly.

[0005] However, when this same front-end code is packaged into the Electron desktop application, the application loads the page via the operating system's local file system protocol (file: / / ). The operating system's underlying behavior interprets the first letter " / " of the path as the root directory of the system's physical disk, leading to data loading failure.

[0006] In related technologies, developers abandon absolute paths in the source code and manually write code by calculating the relative hierarchy from the current component's directory to the resource directory.<imgsrc=".. / .. / .. / assets / icons / warning.png" / > This approach is extremely error-prone and unmaintainable. If the directory hierarchy of a UI component is moved, all .. / .. / .. / paths must be recalculated and modified. More seriously, this approach cannot maintain consistency between the web (HTTP retrieval method) and desktop (File retrieval method), disrupting the consistency of a single codebase running across multiple platforms.

[0007] In light of this, related technologies further propose registering a custom protocol by calling `protocol.registerFileProtocol('app',...)` when the Electron main process starts. When the rendering process sends a request for `app: / / assets / icons / warning.png`, the main process intercepts the request and uses Node.js's `path` module to dynamically construct the correct local disk physical path at runtime before returning the file stream to the front end.

[0008] In practice, it was found that custom protocol interception is a "runtime fallback" approach. Each image loading requires inter-process communication (IPC) between the main process and the rendering process. When loading a complex data table containing hundreds of status icons on the first screen, the main process interceptor may not have been fully initialized, which can easily lead to timing race conditions, resulting in a blank screen on the first launch or some images still failing to load. Summary of the Invention

[0009] To overcome at least one deficiency in the prior art, this application provides a method, apparatus, storage medium, and electronic device for packaging front-end code. The packaged desktop application can directly perform local file addressing based on the physical location of index.html at runtime, without the need for main process intervention or cross-process communication, thus avoiding the overhead of inter-process communication and timing race conditions, and improving stability when loading a large number of images.

[0010] Firstly, this application provides a method for packaging front-end code, the method comprising: In response to the packaging operation, the front-end source code to be packaged is parsed into an abstract syntax tree; Based on the abstract syntax tree, identify the statement nodes that import static resources; The original absolute path of the statement node is replaced with the relative path of the static resource to obtain the replaced abstract syntax tree. The relative path carries a preset addressing anchor point, which is used to force the operating system virtual file system to block the system root directory from going out of bounds when the desktop application runs in the local file system protocol, and to perform logical block address offset addressing based on the website root directory. Based on the replaced abstract syntax tree, the front-end source code is packaged into a desktop application.

[0011] Secondly, this application provides a method for packaging front-end code, the method comprising: The syntax analysis module is used to parse the front-end source code to be packaged into an abstract syntax tree in response to the packaging operation; The node editing module is used to identify the statement nodes that import static resources from the abstract syntax tree. The node editing module is also used to replace the original absolute path of the statement node with the relative path of the static resource to obtain the replaced abstract syntax tree. The relative path carries a preset addressing anchor point, which is used to force the operating system virtual file system to block the system root directory from going out of bounds when the desktop application runs in the local file system protocol, and to perform logical block address offset addressing based on the website root directory. The source code packaging module is used to package the front-end source code into the desktop application based on the replaced abstract syntax tree.

[0012] Thirdly, this application provides a storage medium storing a computer program that, when executed by a processor, implements the aforementioned method for packaging front-end code.

[0013] Fourthly, this application provides an electronic device, the electronic device including a processor and a memory, the memory storing a computer program, the computer program implementing the front-end code packaging method when executed by the processor.

[0014] Compared with the prior art, this application has the following beneficial effects: In the packaging method, apparatus, storage medium, and electronic device for front-end code provided in this application, when performing the packaging operation, the front-end source code is first parsed into an abstract syntax tree, and the statement nodes that import static resources are identified from it. Then, the original absolute paths are directly replaced with the relative paths of the static resources, so that the desktop application generated accordingly performs logical block address offset addressing based on the website root directory, without the need for the main process to intervene or cross-process communication, avoiding the overhead of inter-process communication and timing race conditions, and improving the stability when loading a large number of images. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 One of the flowcharts illustrating the packaging method for front-end code provided in this application embodiment; Figure 2 A second flowchart illustrating the method for packaging front-end code provided in this application embodiment; Figure 3 A schematic diagram of the framework for the packaging method of front-end code provided in the embodiments of this application; Figure 4 A schematic diagram of the structure of the packaging device for front-end code provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application (hereinafter referred to as "the embodiments") clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0018] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0019] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0020] In the description of this application, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0021] Based on the above statement, as described in the background technology, this method involves using a custom protocol interception to allow the main process to intercept specific requests and dynamically modify the access address. While this method can solve the problem of manual modification, it may fail to load due to performance overhead when storing a large number of graphs.

[0022] It should be noted that the defects in the solutions in the prior art are the result of practice and careful research. Therefore, the discovery process of the above problems and the solutions proposed by the embodiments of this application in the following text should be regarded as contributions to this application in the process of invention and creation, and should not be understood as technical content known to those skilled in the art.

[0023] Based on the discovery of the above-mentioned technical problems, this embodiment provides a method for packaging front-end code. For example... Figure 1 As shown, the method includes: S1, in response to the packaging operation, parses the front-end source code to be packaged into an abstract syntax tree.

[0024] S2 identifies the statement nodes that import static resources based on the abstract syntax tree.

[0025] S3 replaces the original absolute path of the statement node with the relative path of the static resource to obtain the replaced abstract syntax tree.

[0026] The relative path carries a preset addressing anchor point, which is used to force the operating system's virtual file system to block outbounds from the system root directory when the desktop application is running in the local file system protocol, and to perform logical block address offset addressing based on the website root directory.

[0027] S4 packages the front-end source code into a desktop application based on the replaced abstract syntax tree.

[0028] This can be understood as follows: when performing the packaging operation, the front-end source code is first parsed into an abstract syntax tree, and the statement nodes that import static resources are identified from it. Then, the original absolute paths are directly replaced with the relative paths of the static resources. This allows the desktop application generated based on this to perform logical block address offset addressing based on the website root directory, without the need for the main process to intervene or cross-process communication. This avoids the overhead of inter-process communication and timing race conditions, and improves the stability when loading a large number of images.

[0029] It should be noted that the electronic device implementing the front-end code packaging method can be, but is not limited to, tablet computers, laptop computers, desktop computers, and servers. When it is a server, the server can be a single server or a group of servers. The server group can be centralized or distributed (e.g., the servers can be a distributed system). In some embodiments, the server can be local or remote relative to the user terminal. In some embodiments, the server can be implemented on a cloud platform; by way of example only, the cloud platform can include private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, inter-cloud, multi-cloud, etc., or any combination thereof. In some embodiments, the server can be implemented on an electronic device having one or more components.

[0030] To make the solution provided in this embodiment clearer, a server is used as the electronic device for implementing the method below, and in conjunction with... Figure 1 Each step of the method is described in detail. However, it should be understood that the operations in the flowchart may not be implemented in sequence, and steps without logical contextual relationships may be reversed in order or implemented simultaneously. Furthermore, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowchart, or remove one or more operations from the flowchart.

[0031] See also Figure 1 The following is a detailed explanation of step S1 in the diagram: S1, in response to the packaging operation, parses the front-end source code to be packaged into an abstract syntax tree.

[0032] In practical applications, the server can respond to the packaging operation of the front-end project, automatically start the build toolchain, load the front-end source code to be packaged as a whole, and parse it into an abstract syntax tree. During this process, an abstract syntax tree with hierarchical structure and semantic relationships can be constructed in memory by a JavaScript parser (e.g., SWC or Babel).

[0033] For example, when a modular declaration like `import statusIcon from '@ / assets / warning.png'` appears in the source code, the parser generates a node of type `ImportDeclaration` and attaches it to the corresponding position in the syntax tree.

[0034] Based on the above examples regarding the front-end source code and abstract syntax tree, the following will continue to discuss... Figure 1 Step S2 will be explained in detail: S2 identifies the statement nodes that import static resources based on the abstract syntax tree.

[0035] In this embodiment, the server can traverse all nodes of the constructed abstract syntax tree and identify the statement node for importing static resources (e.g., the ImportDeclaration node), and point to the resources used for status identification in the front-end interface, such as icons and images.

[0036] For example, when a node of the form "import statusIcon from '@ / assets / warning.png'" exists in the syntax tree, the server determines that it belongs to a statement node for importing static resources that is yet to be processed.

[0037] Based on the statement nodes for importing static resources identified in the above embodiments, the following continues to write... Figure 1 Step S3 will be explained in detail: S3 replaces the original absolute path of the statement node with the relative path of the static resource to obtain the replaced abstract syntax tree.

[0038] The relative path carries a preset addressing anchor point, which is used to force the operating system's virtual file system to block out-of-bounds access to the system root directory when the desktop application is running using the local file system protocol, and to perform logical block address offset addressing based on the website root directory. This website root directory is also known as the host file directory where the current process control block is located.

[0039] As an optional implementation, the server can obtain the access address of the static resource relative to the website root directory; concatenate the preset addressing anchor with the access address to form a relative path; and replace the original absolute path of the statement node with the relative path.

[0040] In practical applications, the server can concatenate a preset addressing anchor with an access address relative to the website root directory to form a relative path. Using a protocol-aware tree traversal, it locates the ImportDeclaration AST node instance in main memory through a depth-first search. It then physically erases the original V8 memory pointer pointing to the absolute path and allocates new space in the young generation memory to assign the concatenated relative path literal, thereby forcibly redirecting the AST node pointer to this new physical address. Here, the website root directory refers to the directory containing index.html, and the addressing anchor is the string ". / " specified by the environment variable assetPrefix, which is used to start the search from the website root directory when looking for static resources.

[0041] For example, when the original import statement is "import warning from ' / assets / icons / warning.png'", the server will extract the resource path " / assets / icons / warning.png", concatenate it with ". / " to form ". / assets / icons / warning.png", and then write the new path to the value attribute of the corresponding ImportDeclaration node through the operation API of the Abstract Syntax Tree (AST).

[0042] In this way, by redirecting the pointers to the syntax tree nodes in memory, Chromium can naturally resolve the path starting from the directory where index.html is located when the generated packaged artifacts are loaded by Electron using the "file: / / " protocol, thus avoiding the operating system reading images from the root directory of the disk.

[0043] It should be noted that when performing lexical analysis on the front-end source code, directly using the access address of static resources will cause the static resources to be stored with their original filenames. This naming convention results in a lack of binding between file content and filename. When the icon content is updated but the filename remains unchanged, the desktop client may continue to read the old version cache, causing the interface display to be inconsistent with the actual business state.

[0044] Taking Electron-based desktop applications as an example, when pages are loaded using the "file: / / " protocol instead of the "HTTP" protocol, a cache deadlock phenomenon for local static resources can easily occur. Specifically, suppose a new version replaces the warning icon with a clearer image, but the filename still uses "warning.png". After the desktop application is upgraded and reinstalled, because the filename has not changed, the underlying Chromium network stack in Electron is highly likely not to reread the file in the new installation directory, but will continue to read the old image from the previous version in the system's hidden cache directory (such as the application cache directory under %APPDATA%).

[0045] The aforementioned cache deadlock phenomenon can lead to version cross-contamination. For example, the content of a data alert icon may be updated (e.g., changing a yellow mild warning to a red severe warning), but the file name remains unchanged. Users will still see the old yellow icon on the client, which can easily cause business misjudgments and create a huge asset risk control vulnerability.

[0046] To address the aforementioned issues, static resources are renamed using their own hash fingerprints within relative paths. Therefore, as an optional implementation, before replacing the original absolute path of a statement node with the relative path of the static resource, the server, during lexical analysis of the front-end source code, if a modular declaration statement appears, triggers a preset hook to intercept and interrupt the URL string parsing pipeline for the modular declaration statement, and obtains the hash fingerprint of the static resource corresponding to the URL string. The hash fingerprint is then used to generate a hash filename for the static resource, which is then renamed using the hash filename and stored in a preset location.

[0047] In practical applications, servers can use build engines such as Webpack / Turbopack to bundle the front-end source code. A custom static dependency hijacking engine can be injected into the initialization configuration of these build engines and attached to the module parsing lifecycle hook. When a modular declaration statement appears in the front-end source code (e.g., `import statusIcon from '@ / assets / warning.png'`), the lexer of the build engine triggers this hook. This hook forcibly interrupts the default URL string parsing pipeline and calls Node.js's `fs.readFileSync()` interface to read the corresponding resource. Finally, the arithmetic logic unit performs multiple rounds of XOR operations on the read resource to generate a unique hash fingerprint.

[0048] Based on the generated hash fingerprint, the server calls `fs.writeFileSync()` to trigger a page cache refresh, renaming the original filename, the hash fingerprint, and the extension to form a hash filename, and then physically writing it to a preset location on disk. This preset location is determined by the build engine. Taking Next.js as an example, the engine automatically creates a folder called "_next" and subdirectories within it. All processed and hash-finded static image resources are automatically moved to the fixed physical subfolder "_next / static / media / ". In this embodiment, during the build phase, an addressing anchor point ". / " is forcibly added to the beginning of this address using the AST to change its addressing logic.

[0049] For example, suppose a static resource is named "warning.png" and its hash fingerprint is "a1b2c3d4". The final hash file name formed by concatenating the original file name, hash fingerprint and extension is "warning.a1b2c3d4.png".

[0050] It should also be noted that when obtaining the hash fingerprint of static resources, the image is usually loaded into the memory buffer block by block using the conventional file reading method, and then the CPU performs the hash calculation. When the number and size of static resources are large, I / O throughput becomes the performance bottleneck, causing the overall time to increase linearly with the number of static resources.

[0051] To address the aforementioned issues, as an optional implementation method, when obtaining the hash fingerprint of a static resource corresponding to a URL string, the server can schedule a direct memory access channel to move the static resource to an off-heap buffer pool allocated in memory; the arithmetic logic unit in the driver processor then performs a hash operation on the static resource in the buffer pool to obtain the hash fingerprint of the static resource.

[0052] In practical applications, the server can schedule direct memory access channels to move static resources to an off-heap buffer pool in memory, and drive the arithmetic logic unit in the processor to perform hash operations on the static resources in the buffer pool to obtain the hash fingerprint of the static resources.

[0053] Specifically, when the fs.readFileSync() interface is called to read an image, the CPU responds to a kernel soft interrupt, directly schedules the Direct Memory Access (DMA) channel, moves the binary stream on the SSD physical sector to a pre-allocated off-heap buffer pool in main memory, and calls crypto.createHash('sha256') to drive the CPU's arithmetic logic unit to perform multiple rounds of deterministic XOR operations on the continuous byte stream in the buffer pool, generating a unique hash fingerprint that strictly corresponds to the file content.

[0054] This avoids the overhead of frequent CPU intervention in data movement and cache management in the traditional approach, thereby improving the execution efficiency of generating large batches of static resource fingerprints.

[0055] Based on the modifications to the abstract syntax tree in the above embodiments, we will continue with the following... Figure 1 Step S4 will be explained in detail: S4 packages the front-end source code into a desktop application based on the replaced abstract syntax tree.

[0056] As an alternative implementation, the server can deserialize the replaced abstract syntax tree and package it as a desktop application.

[0057] For example, when the `value` attribute of the `ImportDeclaration` node has been rewritten to ". / _next / static / media / warning.a1b2c3d4.png", the generator outputs the final form of the corresponding import statement; all paths redirected by pointers are fixed as relative paths in the final packaged artifact. The server uses build tools to compress, obfuscate, and organize this code along with other resource files into a physical package structure that Electron can load, containing `index.html` and its dependent JS, CSS, and hashed image files.

[0058] In this way, the generated desktop application can directly locate all static resources under the "file: / / " protocol without any main process protocol interception or runtime path correction.

[0059] It should also be noted that during desktop application operation, if the target image fails to load due to disk bad sectors, permission lockout, or file corruption, the traditional approach is to simply rely on the browser's default error event to throw an error without any intervention. In this case, the `img` tag remains in a 404 state, and the corresponding DOM node has no valid visual content. This causes critical business indicators (such as battery pack offline, battery swapping station malfunction) to all display as cracked images on the battery management terminal.

[0060] To solve the above problems, such as Figure 2 As shown, the front-end code packaging method provided in this embodiment also includes: S5: If an abnormality is detected during the execution of the desktop application, a backup image is generated using a pre-compiled inline SVG vector code block that resides in memory.

[0061] In practical applications, it can be encapsulated at the React Virtual Document Object Model (DOM) layer. <assetstatusicon>The disaster recovery component, which is rendered by this component An `onError` event handler is mounted on the virtual node, serving as a local I / O fault tolerance probe residing within the rendering process. This probe directly listens for low-level error signals triggered by local file read operations driven down from the Chromium network stack. When the terminal device returns system-level error codes such as `ENOENT` or `EACCES` due to disk bad sectors, system privilege locks, or physical damage to the image file itself preventing the decoding engine from parsing it, these exceptions, originally belonging to the kernel or driver layer, are propagated upwards and ultimately transformed into DOM error events recognizable by the browser.

[0062] During this process, the disaster recovery probe captures and intercepts events before they bubble up into the global JavaScript execution environment, thus preventing the anomaly from spreading and causing the entire front-end application to become unusable. In this way, by using pre-compiled and memory-resident inline SVG vector code blocks to generate backup images, these backup images are used to replace the actual target image after an unrecoverable disk access failure is determined, masking the underlying access anomaly so that it is imperceptible to the user.

[0063] Based on the above explanation of anomaly interception and image backup, we will continue with... Figure 2 Step S6 will be explained below: S6 mounts the backup image to the DOM node where the target image is displayed, replacing the target image.

[0064] It should be noted that when a desktop application is running, if the target image fails to load due to disk failure or permission issues, the browser usually only triggers the default error event and stops rendering, resulting in the corresponding position being displayed as blank or a cracked image. To replace it, it is necessary to automatically locate which specific DOM node failed to load.

[0065] To address the above problems, this embodiment provides the following optional implementation methods for step S6: S6-1 calls the state update function to update the state of the target image display component, and compares the two virtual DOM trees before and after the state update to identify the DOM node position corresponding to the target image.

[0066] In practical applications, when a target image fails to load and is detected by the disaster recovery probe, the server can call the state update function provided by the front-end component React, such as "setState()", to change the current state of the target image display component in memory. This operation triggers the Fiber reconciliation engine inside the React framework, which automatically constructs a new virtual DOM tree and compares it node by node with the old virtual DOM tree generated in the previous rendering, thereby accurately identifying the virtual node positions directly associated with the image display component.

[0067] For example, if a component is named AssetStatusIcon, and its visual presentation is controlled by an isImgFailed boolean state, then after the state is updated, the harmonizer can lock the original object to which the component is attached. Logical coordinates of a node in the DOM tree.

[0068] Thus, based on the inherent consistency between state changes and the virtual DOM, the exact DOM node position corresponding to the target image can be determined.

[0069] Based on the above description of the target image display nodes in the embodiments, step S6 further includes: S6-2 removes the bitmap tag from the DOM node position of the target image and mounts the backup image to the DOM node position of the target image.

[0070] The inline vector code block corresponding to the backup image is pre-compiled and resides in memory during the initialization of the desktop application.

[0071] In practical applications, desktop applications can execute low-level DOM manipulation commands, calling the `removeChild` interface to forcibly unload bitmap tags already mounted at the target location from the physical DOM tree, and simultaneously release the bitmap memory resources they occupy. Then, the `appendChild` interface can be called to directly mount pre-compiled inline SVG code blocks resident in the JS heap memory to the same DOM node location. It should be understood that the backup image here is not a specific image file, but rather an image drawn in memory using SVG vector code, which is parsed and persisted in memory during the desktop application initialization phase.

[0072] For example, when the battery pack status warning icon cannot be loaded due to bad sectors on the local disk, the original img tag can be replaced with a pre-stored red triangle warning SVG in memory, and the GPU can directly complete the rasterization redraw.

[0073] In the above embodiments, each step of the front-end code packaging method provided in this application has been described in detail. The overall framework of the method is as follows: Figure 3 As shown, to make the entire method flow clearer and more coherent, the following section combines... Figure 3 The method is described in its entirety.

[0074] like Figure 3 As shown, this method can be divided into compilation phase and runtime phase. The compilation phase involves a static resource physical reading engine, a content fingerprint encryptor, and an address pointer rewriting gateway; the runtime phase involves a local protocol address parser and a state-driven image adaptation layer.

[0075] In the server runtime domain, after the server parses the front-end source code into an abstract syntax tree, the static resource physical reading engine intervenes. Through the strong declaration of resource dependencies and binary interception capabilities, it intercepts the default URL string parsing pipeline when the modular declaration statement is triggered, and schedules the direct memory access channel to move the static resources to the off-heap buffer pool. Based on this, the server uses a content fingerprint encryptor to perform hash operations on the binary stream driven processor arithmetic logic unit in the buffer pool to generate a unique hash fingerprint, and then renames the static resource with a hash file name and stores it in a preset location.

[0076] Finally, the server erases the absolute path at the AST level by rewriting the address pointer of the gateway, uses the preset address anchor point and the hash file name to form a relative path, and performs pointer erasure and young generation redirection operations on the ImportDeclaration node in the V8 engine heap memory, and finally outputs a static asset package with a hash relative path.

[0077] After entering the user terminal runtime domain, the local protocol addressing resolver in the desktop application relies on the secure space anchoring capability in the offline state. It uses the physical file index.html as the unique space coordinate for the "file: / / " protocol resolution as the benchmark, and combines the virtual file system of the operating system to calculate the pointer offset of the path, accurately locate the disk logical block address, and complete the resource loading.

[0078] When the loading process fails due to disk bad sectors or permission abnormalities, the state-driven graphics adaptation layer in the desktop application intercepts I / O failures to trigger the React state update function. It compares the old and new virtual DOM trees in memory to identify the corresponding node position of the target image, then unloads the failed bitmap and mounts a pre-compiled inline SVG backup image that resides in the JS heap memory. The GPU then performs rasterization redrawing to ensure that the core visual semantics are always available.

[0079] Based on the same inventive concept as the front-end code packaging method provided in this embodiment, this embodiment also provides a front-end code packaging device. This device includes at least one software functional module that can be stored in a memory or embedded in an electronic device. The processor in the electronic device executes the executable module stored in the memory. For example, the software functional module and computer program included in this device. Please refer to... Figure 4 Functionally, the device may include: Syntax analysis module 11 is used to parse the front-end source code to be packaged into an abstract syntax tree in response to the packaging operation; The node editing module 12 is used to identify the statement nodes that import static resources from the abstract syntax tree; The node editing module 12 is also used to replace the original absolute path of the statement node with the relative path of the static resource to obtain the replaced abstract syntax tree; Source code packaging module 13 is used to package the front-end source code into a desktop application based on the replaced abstract syntax tree.

[0080] Optionally, the node editing module 12 replaces the original absolute path of the statement node with the relative path of the static resource in the following ways: Get the access address of static resources relative to the website root directory; The preset addressing anchor point and the access address are concatenated to form a relative path; Replace the original absolute path of the statement node with a relative path.

[0081] Optionally, in the relative path of a static resource, the static resource is renamed using its own hash fingerprint; Before replacing the original absolute path of the statement node with the relative path of the static resource, the syntax analysis module 11 is also used to trigger a preset hook to intercept and interrupt the URL string parsing pipeline of the modular declaration statement when a modular declaration statement appears during lexical analysis of the front-end source code, and to obtain the hash fingerprint of the static resource corresponding to the URL string. Use hash fingerprints to generate hash filenames for static resources, and then rename the static resources with the hash filenames and store them in a preset location.

[0082] Optionally, the syntax analysis module 11 obtains the hash fingerprint of the static resource corresponding to the URL string in the following ways: Schedule direct memory access channels to move static resources to an off-heap buffer pool in memory; The arithmetic logic unit in the driver processor performs hash operations on the static resources in the buffer pool to obtain the hash fingerprint of the static resources.

[0083] Optionally, the source code packaging module 13 packages the front-end source code into a desktop application based on the replaced abstract syntax tree, including: The replaced abstract syntax tree is deserialized and packaged as a desktop application.

[0084] Optionally, see [link to relevant documentation] Figure 4 The device also includes an exception handling module 14, which, if an exception is detected during the operation of the desktop application, generates a backup image using a pre-compiled and resident in-memory inline SVG vector code block. Mount the backup image to the DOM node where the target image is displayed, replacing the target image.

[0085] Optionally, the exception handling module 14 may mount the backup image to the DOM node where the target image is displayed, in order to replace the target image, including: The state update function is called to update the state of the target image display component, and the two virtual DOM trees before and after the state update are compared to identify the DOM node position corresponding to the target image. The bitmap tag of the target image is removed from the DOM node position, and the backup image is mounted to the DOM node position of the target image. The inline vector code block corresponding to the backup image is pre-compiled and resides in memory during the initialization of the desktop application.

[0086] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0087] It should also be understood that if the above embodiments are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0088] Therefore, this embodiment also provides a storage medium, which is a computer-readable storage medium. This storage medium stores a computer program, which, when executed by a processor, implements the front-end code packaging method provided in this embodiment. The storage medium can be any medium capable of storing program code, such as a USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0089] Please refer to Figure 5 The electronic device provided in this embodiment may include a processor 22 and a memory 21. The memory 21 stores a computer program, and the processor implements the front-end code packaging method provided in this embodiment by reading and executing the computer program in the memory 21 corresponding to the above embodiments.

[0090] See also Figure 5 The electronic device also includes a communication unit 23. The memory 21, processor 22 and communication unit 23 are electrically connected to each other directly or indirectly through system bus 24 to realize data transmission or interaction.

[0091] The memory 21 can be an information recording device based on any electronic, magnetic, optical, or other physical principles, used to record execution instructions, data, etc. In some embodiments, the memory 21 can be, but is not limited to, volatile memory, non-volatile memory, memory drive, etc.

[0092] In some embodiments, the volatile memory may be random access memory (RAM); in some embodiments, the non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, etc.; in some embodiments, the storage drive may be a disk drive, solid-state drive, any type of storage disk (such as optical disc, DVD, etc.), or similar storage media, or a combination thereof.

[0093] The communication unit 23 is used to send and receive data over a network. In some embodiments, the network may include a wired network, a wireless network, a fiber optic network, a telecommunications network, an intranet, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), a public switched telephone network (PSTN), a Bluetooth network, a ZigBee network, or a near field communication (NFC) network, or any combination thereof. In some embodiments, the network may include one or more network access points. For example, the network may include wired or wireless network access points, such as base stations and / or network switching nodes, through which one or more components of the service request processing system can connect to the network to exchange data and / or information.

[0094] The processor 22 may be an integrated circuit chip with signal processing capabilities, and may include one or more processing cores (e.g., a single-core processor or a multi-core processor). By way of example only, the processor described above may include a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), an Application Specific Instruction-set Processor (ASIP), a Graphics Processing Unit (GPU), a Physics Processing Unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a microcontroller unit, a Reduced Instruction Set Computing (RISC) computer, or a microprocessor, or any combination thereof.

[0095] Understandable. Figure 5 The structure shown is for illustrative purposes only. Electronic devices may also have more advanced features. Figure 5 Showing more or fewer components, or having with Figure 5 The different configurations shown. Figure 5 The components shown can be implemented using hardware, software, or a combination thereof.

[0096] It should be understood that the apparatus and methods disclosed in the above embodiments can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0097] The above descriptions are merely various embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / assetstatusicon>

Claims

1. A method for packaging front-end code, characterized in that, The method includes: In response to the packaging operation, the front-end source code to be packaged is parsed into an abstract syntax tree; Based on the abstract syntax tree, identify the statement nodes that import static resources; The original absolute path of the statement node is replaced with the relative path of the static resource to obtain the replaced abstract syntax tree. The relative path carries a preset addressing anchor point, which is used to force the operating system virtual file system to block the system root directory from going out of bounds when the desktop application runs in the local file system protocol, and to perform logical block address offset addressing based on the website root directory. Based on the replaced abstract syntax tree, the front-end source code is packaged into the desktop application.

2. The method for packaging front-end code according to claim 1, characterized in that, Replacing the original absolute path of the statement node with the relative path of the static resource includes: Obtain the access address of the static resource relative to the website root directory; The preset addressing anchor point is concatenated with the access address to form the relative path; Replace the original absolute path of the statement node with the relative path.

3. The method for packaging front-end code according to claim 1, characterized in that, In the relative path, the static resource is renamed using its own hash fingerprint; Before replacing the original absolute path of the statement node with the relative path of the static resource, the method further includes: When performing lexical analysis on the front-end source code, if a modular declaration statement appears, a preset hook is triggered to intercept and interrupt the URL string parsing pipeline of the modular declaration statement, and the hash fingerprint of the static resource corresponding to the URL string is obtained. The hash fingerprint is used to generate a hash filename for the static resource, and the static resource is renamed with the hash filename and stored in a preset location.

4. The method for packaging front-end code according to claim 3, characterized in that, Obtaining the hash fingerprint of the static resource corresponding to the URL string includes: Schedule a direct memory access channel to move the static resources to an off-heap buffer pool in memory; The arithmetic logic unit in the driver processor performs a hash operation on the static resources in the buffer pool to obtain the hash fingerprint of the static resources.

5. The method for packaging front-end code according to claim 1, characterized in that, Based on the replaced abstract syntax tree, the front-end source code is packaged into a desktop application, including: The replaced abstract syntax tree is deserialized and packaged into the desktop application.

6. The method for packaging front-end code according to claim 1, characterized in that, The method further includes: If the desktop application detects an anomaly while loading the target image during operation, it generates a backup image using a pre-compiled inline SVG vector code block that resides in memory. The backup image is mounted to the DOM node that displays the target image, thus replacing the target image.

7. The method for packaging front-end code according to claim 6, characterized in that, Mounting the backup image to the DOM node displaying the target image to replace the target image includes: The state update function is called to update the state of the target image display component, and the two virtual DOM trees before and after the state update are compared to identify the DOM node position corresponding to the target image. The bitmap tag of the target image is stripped from the DOM node position, and the backup image is mounted to the DOM node position of the target image. The inline vector code block corresponding to the backup image is pre-compiled and resides in memory during the initialization of the desktop application.

8. A method for packaging front-end code, characterized in that, The method includes: The syntax analysis module is used to parse the front-end source code to be packaged into an abstract syntax tree in response to the packaging operation; The node editing module is used to identify the statement nodes that import static resources from the abstract syntax tree. The node editing module is also used to replace the original absolute path of the statement node with the relative path of the static resource to obtain the replaced abstract syntax tree. The relative path carries a preset addressing anchor point, which is used to force the operating system virtual file system to block the system root directory from going out of bounds when the desktop application runs in the local file system protocol, and to perform logical block address offset addressing based on the website root directory. The source code packaging module is used to package the front-end source code into the desktop application based on the replaced abstract syntax tree.

9. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the packaging method for the front-end code as described in any one of claims 1-7.

10. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing a computer program that, when executed by the processor, implements the front-end code packaging method according to any one of claims 1-7.

Images