Web resource processing method, system, device, and medium

Abstract

This application relates to the field of embedded technology and discloses a method, system, device, and medium for processing web page resources, mainly addressing the technical problem of limited storage resources in web page deployment on embedded devices. The method includes: receiving a web page resource request sent by a client; retrieving a corresponding web page resource template from a resource server as needed based on the request; dynamically loading the retrieved web page resource template into the volatile memory of the embedded device; retrieving real-time data from the volatile memory of the embedded device and using the real-time data to dynamically synthesize the web page resource template to generate target web page content; and returning the target web page content to the client for dynamic rendering. The web page resource template is dynamically released using a preset memory management strategy.

Description

Technical Field

[0001] This application relates to the fields of embedded systems and communication technology, and in particular to a method, system, device and medium for processing web page resources. Background Technology

[0002] With the rapid development of IoT technology, directly accessing and monitoring embedded devices through a browser (i.e., B / S mode) has become the mainstream interaction solution in fields such as industrial control and smart homes. In this architecture, embedded devices typically need to integrate a miniature web server to respond to client access requests and display the interactive interface.

[0003] In traditional embedded web system implementations, static resources such as HTML, CSS, JavaScript, and icons for web pages typically need to be pre-hardened and persistently stored in the embedded device's local non-volatile memory (such as Flash). When a user initiates a visit, the embedded device's web server reads the corresponding resource file from Flash through the file system and sends it to the browser for rendering via the network protocol stack.

[0004] However, this reliance on local persistent storage exhibits significant limitations in resource-constrained embedded environments. Firstly, due to hardware cost constraints, mainstream low-power IoT chips (such as the ESP8266 and STM32 series) typically have extremely limited physical Flash memory, usually only a few hundred KB to around 1 MB. Simultaneously, modern web applications, in pursuit of a superior user experience, often incorporate massive script frameworks and complex UI resources, typically reaching several MB in size, far exceeding the local storage capacity of low-end chips. This creates a severe contradiction between limited local hardware storage resources and the ever-growing size of web assets, making it difficult to successfully deploy high-performance rich media applications on low-cost embedded terminals.

[0005] Therefore, how to dynamically deploy and run web applications on embedded devices with limited storage resources without relying on local persistent storage is a key problem that urgently needs to be solved. Summary of the Invention

[0006] This application provides a method, system, device, and medium for processing web page resources in embedded devices, mainly to solve the technical problem of limited storage resources in current web page deployment schemes for embedded devices.

[0007] A method for processing web page resources in an embedded device, the method comprising: Receive web resource requests sent by the client; Based on the web page resource request, obtain the corresponding web page resource template from the resource server as needed; The obtained web page resource template is dynamically loaded into the volatile memory of the embedded device; The embedded device's real-time data is retrieved from the volatile memory, and the web page resource template is dynamically synthesized using the real-time data to generate the target web page content. The target webpage content is returned to the client so that the client can perform dynamic rendering; wherein, the webpage resource template is dynamically released using a preset memory management strategy.

[0008] An embedded device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the aforementioned web page resource processing method.

[0009] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned web page resource processing method.

[0010] One of the solutions provided in this application greatly improves the scalability and operation and maintenance efficiency of the Internet of Things system, and solves the technical problem of insufficient deployment capability caused by storage resource limitations in traditional embedded device web deployment solutions. Attached Figure Description

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

[0012] Figure 1 This is a flowchart illustrating a web page resource processing method for an embedded device according to an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a web page resource processing device for an embedded device according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an embedded device according to an embodiment of this application. Detailed Implementation

[0013] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0014] This application provides a web resource processing solution for embedded devices, mainly to address the problem of limited storage resources in current web deployment schemes for embedded devices. For ease of understanding, before introducing the solution, the following will first describe the technical terms involved in this application / the relevant field, as well as the background of this application.

[0015] Basic Network and Architecture Terminology Embedded system terminology Webpage Deployment Core Technical Terminology Supplementary Terminology for Tools and Protocols The table above describes the technical terms involved in this application / the field. The background of the solution provided in this application is introduced below.

[0016] With the development of web page deployment technology for embedded devices, the collaborative architecture of local storage media and HTTP servers has become the mainstream implementation solution. This architecture integrates non-volatile storage media (such as Flash or SD cards) to store web page resources (HTML / CSS / JS) and carries a lightweight HTTP server to provide network access capabilities, enabling remote monitoring and management functions. The following analysis examines the technical characteristics of the storage media and HTTP server, and illustrates its implementation details with typical embedded platform examples.

[0017] Mainstream technical solution: A collaborative architecture combining local flash storage and built-in HTTP service Embedded devices commonly employ a technical architecture of local Flash storage + lightweight HTTP server. Local Flash, as the core storage medium, handles the persistent storage of web resources and system programs. Its capacity is typically in the hundreds of KB to several MB range (e.g., the ESP8266 Flash capacity ranges from 512KB to 4MB, with custom designs supporting up to 16MB). It communicates with the main control unit via the SPI bus. Although its access speed is about 12 times slower than internal RAM, the RAM caching mechanism can improve the response efficiency for frequently accessed data. To adapt to resource-constrained environments, embedded HTTP servers need to meet characteristics such as low memory usage (typically <100KB) and no dynamic memory allocation. Mainstream solutions include Elysian Web Server written in C, asmttpd optimized from assembly (with extremely low resource usage), and BOA server commonly used in industrial applications. These servers are all implemented based on a simplified TCP / IP protocol stack (such as lwIP) and can run stably in 8-bit / 16-bit MCU environments.

[0018] However, embedded web deployments require a balance between storage capacity and service performance. For example, traditional Apache servers require several MB of storage space, while flash memory in embedded environments is often less than 4MB (e.g., the standard configuration of ESP32 is 4MB Flash). Therefore, a lightweight implementation is necessary. Below are two typical platform implementation examples: (1) ESP8266: Flash storage solution based on SPIFFS file system The ESP8266, a widely used Wi-Fi module in the IoT field, relies on the SPIFFS (SPIFlash File System) file system for local resource management in its web page deployment. The module's Flash memory uses a W25Q32 chip (4MB capacity), divided into 64KB blocks, 4KB sectors, and 256-byte pages, supporting sector / block-level erasure and page-level writing. The SPIFFS file system is optimized for embedded Flash, allowing direct mounting of web page file directories and responding to user requests via a built-in HTTP server (such as nonodemcu-espress). In typical applications, a 512KB Flash module allocates approximately 64KB of available space to web page resources, while a 4MB module provides 3MB of available storage. Its Flash storage layout must differentiate between OTA and non-OTA modes: the non-OTA layout allocates the first 64 sectors (256KB) to the main program, user data, and parameter storage; the OTA layout uses symmetrical partitioning (e.g., 256KB / 512KB / 1MB) to reserve storage space for upgrade programs, ensuring isolation between web page resources and system programs.

[0019] (2) STM32: External storage expansion solution based on SD card For high-end embedded scenarios with limited Flash capacity (such as industrial control), STM32 series microcontrollers often use external SD cards to expand storage, enabling the storage of large-capacity web resources (such as complex charts and historical data reports) through the SDIO interface. SD cards, as hot-swappable storage media, can reach capacities in the GB range, overcoming the physical space limitations of local Flash (typically, STM32 on-chip Flash is 256KB~2MB). For HTTP service implementation, STM32 often integrates the lwIP protocol stack and a matching lwip-httpd server, managing web files on the SD card through a file system (such as FatFs), supporting HTTP / 1.1 Range request headers for resumeable downloads, and optimizing the transmission efficiency of large files (such as firmware upgrade packages). This solution needs to address the stability issues of external storage, typically ensuring data integrity through hardware CRC checks and software fault tolerance mechanisms (such as file system logs).

[0020] As can be seen, existing technologies for dynamically deploying embedded devices on web pages present several technical challenges in scenarios without local storage. These include insufficient storage capacity preventing the deployment of large applications, complex update mechanisms leading to device downtime risks, and deficiencies in resource loading and security mechanisms limiting the feasibility of dynamic deployment. These issues collectively constitute the core technical bottleneck of dynamically deploying embedded devices on web pages.

[0021] Based on this, the embodiments of this application provide a web page resource processing solution for embedded devices. Through various embodiments, the main problems to be solved include the existing technical problems of limited storage resources.

[0022] The web resource processing solution for embedded devices provided in this application adopts a three-tier distributed architecture, which includes the embedded device, the resource server, and the client. Through the separation of responsibilities design of centralized resource management on the resource server side, request forwarding proxy on the embedded device, and dynamic rendering on the client side, dynamic deployment of web pages without local storage on the embedded device is achieved.

[0023] The resource server serves as the central hub for resource storage and distribution, acting as the core resource repository and responsible for comprehensive web resource management and intelligent distribution. Its storage layer includes static HTML / CSS / JS resources, dynamic scripts, and device configuration files, achieving global resource indexing and version control through a central resource management system. To adapt to the low-bandwidth characteristics of embedded devices, an HTTP Range breakpoint resume module is integrated, supporting resource consistency verification and chunked transmission based on If-Range request headers to ensure reliable downloading of large files (such as firmware and high-definition charts).

[0024] In terms of technical implementation, the resource server can optimize resource consumption through an application-specific Web resource server architecture. This involves using the compiler to select the minimum class libraries required by the Web application, forming a lightweight service instance, and reducing the dependence on resource server hardware resources.

[0025] Embedded devices are storage-free forwarding proxies. Acting as a connection bridge, their core characteristic is the absence of local persistent storage; they rely solely on lightweight web resource servers for request forwarding and temporary data processing. Their core capabilities include: Lightweight HTTP resource server kernel: It adopts ultra-small resource servers such as NanoHTTPD (single Java file, loosely coupled modular design), cwhttpd (core simplified, supports ESP8266 / ESP32) or MinnowServer (for resource-constrained devices such as Cortex-M0), retaining only the TCP / IP protocol stack and HTTP request parsing capabilities, and removing the local file storage module.

[0026] Temporary handling mechanism for volatile memory: By using distributed loading technology, web page resources forwarded by the resource server are loaded from network fragments to local volatile memory. The code runs directly in the volatile memory, and the data can be automatically cleared without the need for Flash storage.

[0027] Based on the above-mentioned terminology, background information, and the technical framework provided in this application, various embodiments of a web page resource processing scheme for an embedded device provided in this application will be described below.

[0028] In one embodiment, a method for processing web page resources in an embedded device is provided. This embodiment fundamentally overturns the traditional collaborative architecture of local Flash storage + built-in HTTP service, and adopts a novel three-tier distributed architecture (server-embedded device-client). This method aims to address the core pain point of how to efficiently achieve dynamic deployment of web pages in embedded devices with no local storage or extremely limited storage. Specifically, as follows... Figure 1 As shown, the method includes the following steps: S110: Receive web page resource requests sent by the client.

[0029] The method in this embodiment is primarily applied to embedded devices with limited storage resources built upon microcontroller units (MCUs, such as ESP8266, STM32, or Cortex-M series). A typical physical characteristic of such devices is their extremely small capacity of non-volatile storage media (such as Flash), typically ranging from a few hundred KB to a few MB, making it difficult to support modern, complex, and aesthetically pleasing static web page resources. The solution in this embodiment enables such embedded devices to dynamically deploy rich media pages without requiring local persistent storage of large web page files. For example, embedded devices specifically include, but are not limited to, ultra-low-power terminals built upon STM32 or Cortex-M series MCUs, whose limited hardware specifications are manifested in physical Flash capacity typically being less than 1 MB.

[0030] In step S110, when a client (such as a standard browser) initiates a webpage access request, the embedded device takes on the task of receiving the request. Unlike traditional architectures, the embedded device now runs a highly streamlined, lightweight web server kernel (e.g., local file storage and retrieval modules have been removed, retaining only the basic TCP / IP protocol stack and HTTP request parsing capabilities). At this point, the embedded device has essentially transformed from a traditional storage medium into a forwarding proxy. During the webpage resource request phase, the embedded device typically operates as a lightweight HTTP server (HTTPD, such as ElysianWebServer, NanoHTTPD, or tinyweb), with its peak static memory usage preferably controlled below 20KB. When a user accesses the device IP through a standard browser on a mobile device or PC, the client can initiate a Hypertext Transfer Protocol (HTTP) request via a B / S architecture.

[0031] S120. Based on the web page resource request, obtain the corresponding web page resource template from the resource server as needed.

[0032] After parsing the client's specific request target, the embedded device redirects or forwards the request, initiating calls to the resource server that centrally manages complete webpage resources as needed to obtain the basic webpage resource template. In other words, "on-demand acquisition" in the process of obtaining webpage resource templates means that the device no longer embeds static resources such as HTML, CSS, or JavaScript into its local Flash memory. Instead, it pulls the corresponding template fragments, i.e., webpage resource templates, from the remote resource server in real time according to the needs of the current business logic. A webpage resource template refers to a block of character data with logical placeholders that constitutes the skeleton of a webpage. For example, it is typically broken down into small fragments of 10KB-50KB to adapt to narrow bandwidth environments.

[0033] This mechanism completely shifts the storage pressure of static resources to the resource server or host computer, fundamentally breaking through the physical capacity ceiling of Flash memory, which is generally limited to a few hundred KB to a few MB, in embedded devices.

[0034] S130. Dynamically load the obtained web page resource template into the volatile memory of the embedded device.

[0035] After acquiring the template data stream, the system guides this network data directly into and resides in the device's volatile memory (RAM). The entire process completely bypasses non-volatile media such as Flash, and its entire lifecycle does not involve any write operations to media such as Flash or SD cards. This means that code and resources exist in RAM as temporary data, and the data is immediately cleared once the system is reset or powered off, achieving true non-local persistent operation.

[0036] S140. Obtain real-time data from the embedded device in volatile memory, and use the real-time data to dynamically synthesize the web page resource template to generate the target web page content.

[0037] In the dynamic synthesis phase of embedded devices, real-time data refers to variables characterizing the current physical state or logical parameters of the embedded device. Examples include ambient temperature values, voltage readings, or the high / low level states of GPIO pins obtained via the I2C interface. Dynamic synthesis involves using a webpage parsing engine to identify pre-defined logical tags (such as "TAG:Temperature") in webpage resource templates and replacing these tags in-situ with the aforementioned acquired real-time state parameter strings. This tag-replacement-based approach avoids running complex CGI or PHP script engines on resource-constrained devices, significantly reducing CPU load.

[0038] S150. Return the target webpage content to the client so that the client can perform dynamic rendering; wherein, the webpage resource template uses a preset memory management strategy for dynamic release.

[0039] After the synthesis is complete, the embedded device returns the final target webpage content via the network, offloading the most computationally intensive page rendering and UI repainting tasks to the client browser. Simultaneously, to prevent this mechanism from impacting the embedded device's extremely limited RAM space, the system strictly adheres to a preset memory management strategy. Once the target webpage content has been sent, or if memory usage reaches a dangerous level (such as ≥80% threshold conditions), the system immediately and completely releases the webpage resource template and intermediate processing data from volatile storage.

[0040] As can be seen, this embodiment eliminates the embedded device's reliance on Flash or external SD cards for storage through a three-layer architecture with separation of responsibilities, significantly reducing hardware costs. More importantly, offloading complex page rendering tasks to the client significantly reduces the system overhead of the embedded device, enabling it to transform from a storage carrier to a communication proxy. This breakthrough not only allows devices with limited storage space (such as those with only 512KB Flash) to smoothly handle large dynamic web pages, but also improves the overall system's response efficiency and concurrent processing capabilities. Furthermore, since web page resources are not embedded in the firmware, iterative updates to web page content only need to be completed on the server side, eliminating the business downtime risk caused by frequent firmware burning for web page updates in traditional solutions, shortening maintenance and update time, and greatly improving the scalability and operational efficiency of the IoT system.

[0041] In one embodiment, to achieve dynamic deployment without local storage, resource preprocessing needs to be completed during the development phase. In this embodiment, the Single Page Application (SPA) assets can be converted into C arrays using a dedicated tool on the development side. Combined with library selection compilation technology, necessary modules are extracted from the Web server library to form a lightweight embedded Web service firmware. Resource integration employs two methods: one is to compress the Web resources and application into a single file; the other is to convert the resource characters into standard binary code (American Standard Code for Information Interchange, ASCII) arrays and compile them directly into the embedded device's firmware, avoiding runtime reliance on local storage.

[0042] The above describes the preprocessing stage of embedded development. Specifically, single-page application assets are scanned by specialized tools on the development side and converted into a series of static C language arrays. This means that the originally independent HTML, CSS, or JavaScript files lose their file format before compilation and become constant data that can be directly addressed in the firmware source code. To further reduce the firmware size, compilation techniques can be selected based on the library during development. By configuring parameters similar to a service option structure, unnecessary redundant modules can be precisely extracted from the web server library, retaining only the core logic for handling HTTP requests. This ultimately results in a very small embedded web service firmware, whose memory usage can typically be compressed to less than 20KB.

[0043] During resource integration, two strategies can be flexibly chosen. One is to merge and compress web page resources with the main application into a single file, sacrificing a small amount of CPU decompression performance to achieve the highest storage utilization. The other is to directly convert resource characters into ASCII code arrays, allowing the web server to directly reference data in ROM at runtime with zero addressing latency. This flow path, from asset conversion at the development stage to device firmware encapsulation, and then to loading from ROM to memory after power-on, ensures that web page resources can be accessed instantly during runtime. The fundamental reason for adopting this extreme preprocessing method is to resolve the contradiction between the extremely limited Flash space of embedded chips and the huge size of rich media web pages. Many low-cost IoT chips often have less than 1MB of storage space, while a fully functional single-page application usually far exceeds this limit.

[0044] As can be seen, in this embodiment, through this processing, the embedded device no longer needs to carry a bulky file system driver, thus reducing storage footprint and successfully deploying complex web applications on a chip with extremely small capacity. Furthermore, this processing method also greatly improves the system's response performance. Traditional disk or Flash file system read operations suffer from significant I / O latency (input / output latency), while by coding the resources, the web server can directly locate the data through memory pointers when receiving a request. Combined with the dynamic synthesis technology of this embodiment, the embedded device can skip the time-consuming file retrieval process and directly assemble the pre-defined template array with real-time hardware sampling data in memory. This not only reduces a significant amount of computational overhead but also enables the embedded device to maintain stable communication with a very low memory sliding window when facing high concurrency access, thereby achieving a smoother human-computer interaction experience.

[0045] In one embodiment, the intelligent cache negotiation mechanism is further refined to address how the system efficiently executes the process of retrieving web page resource templates from the resource server on demand. Traditional embedded devices often need to re-download all resources each time they are accessed, which not only wastes network bandwidth and slows down loading speed, but also easily leads to frequent page loading failures in unstable network environments such as industrial settings. To solve this problem, step S120 above, namely, retrieving the corresponding web page resource template from the resource server on demand according to the web page resource request, includes the following steps: S210. Obtain the cache policy memory mapping table.

[0046] During system startup or service initialization, embedded devices pre-parse relevant caching policy configuration files and generate and obtain a caching policy memory mapping table with minimal footprint (e.g., RAM ≤ 2KB) in volatile memory. This mapping table clearly records the mandatory caching rules corresponding to different web page resource types (such as HTML, JSON, etc.), as well as the negotiated caching priority followed when verification is required (e.g., specifying that verification using ETag file fingerprint takes precedence over Last-Modified modification time verification).

[0047] S220. Obtain the cache status identifier carried in the request for web page resources, which is used to indicate the existence status of the local cache on the client.

[0048] When a client browser attempts to access a webpage on a device, it first checks its local cache status using JavaScript, much like a reader checking their library records. Subsequently, the client includes a cache status indicator (e.g., via a specific AJAX header field X-Cache-Status:HIT / MISS) in the webpage resource request header, explicitly informing the embedded device whether the client already has a cached version of the webpage locally. The embedded device then parses the request header and retrieves this indicator.

[0049] S230. When the cache status indicator indicates that the client has a corresponding local cache, a resource metadata verification request is sent to the resource server based on the negotiated cache priority recorded in the cache policy memory mapping table.

[0050] If the identifier indicates that the client has no local cache, the embedded device will directly request the complete file from the resource server. However, if the identifier indicates that the client has a local cache (i.e., the page has been downloaded before), the embedded device will pause fetching the complete large file. In this case, the HTTPD module inside the embedded device will query the aforementioned cache policy memory mapping table and, based on the negotiated cache priority of this type of resource recorded in the table, send only a very lightweight resource metadata verification request to the resource server (e.g., initiate an HTTP HEAD request to obtain the ETag or Last-Modified metadata of the file on the server side, without downloading the file entity).

[0051] S240. Perform a consistency comparison between the target resource identifier returned by the resource server and the historical resource identifier carried in the web page resource request.

[0052] After obtaining the latest metadata returned by the server, the embedded device uses it as the target resource identifier and compares it with the historical resource identifier (such as the If-None-Match or If-Modified-Since field value in the request header) carried by the client in the initial web page resource request. This step is similar to verifying whether the "old book in the reader's hands" and the "new book in the library" are the same version.

[0053] S250, Dynamically decide on the content to return based on the comparison results.

[0054] If the comparison results match, it means that the webpage resource template on the resource server has not been updated. In this case, the embedded device directly returns a resource-unmodified status code (e.g., HTTP 304 NotModified) to the client. This response does not contain any substantial response body data. This explicitly instructs the client to directly call its local cache for rendering. This mechanism effectively distributes the heavy responsibility of rendering and data holding to the client side.

[0055] If the comparison results are inconsistent, it indicates that the resources on the resource server have been iterated. At this point, the embedded device officially obtains the corresponding web page resource template completely from the resource server and passes it through to the client (e.g., returning an HTTP 200 OK status code, along with a brand new file entity and a new ETag).

[0056] In one embodiment, obtaining the corresponding web page resource template completely from the resource server includes: extracting the byte range header identifier from the web page resource request; and, based on the byte range header identifier, initiating a range request to the resource server through an asynchronous communication mechanism to obtain the web page resource data block within the corresponding byte range, and using it as the web page resource template.

[0057] In this embodiment, specifically, the byte range header identifier refers to the Range request header field conforming to the Hypertext Transfer Protocol (HTTP) specification. It should be understood that in embedded web interaction scenarios, when a client browser attempts to load a large web page resource (such as a complex JavaScript library or high-resolution background image reaching 500KB in size), the embedded device's random access memory (RAM) is extremely limited (e.g., only 20KB to 50KB of free space), making it impossible to load the entire file at once. In this case, the embedded device extracts the byte range header identifier from the request to determine the data range to be retrieved within the current processing cycle. For example, bytes=0-4096 indicates that only the first 4KB of data from the resource is retrieved.

[0058] Asynchronous communication mechanism refers to a non-blocking data interaction mode. In this embodiment, the embedded device can utilize the ALE (Asynchronous Loading Engine) component to obtain the data. After the client initiates a network request, it does not enter a dead-end state, but waits for the data to arrive through callback functions or task polling. As an example, after an embedded web server (such as Elysian Web Server) sends a range request, its main control process can continue to process the underlying industrial control tasks or sensor sampling tasks. When the resource server returns the corresponding web page resource data block, it triggers an interrupt or event notification for processing. A web page resource data block refers to a resource fragment with continuous byte characteristics after being physically segmented. Through this segmented retrieval method, the originally large web page resource template is transformed into a series of small data stream blocks. For example, in a web page deployment scenario containing a large historical chart, the embedded device first extracts the identifier and obtains the HTML structure data block, and then obtains the subsequent style and logic data blocks through multiple range requests, realizing dynamic deployment by breaking down the whole into parts. In this example, by extracting the byte range header identifier and initiating a range request in conjunction with the asynchronous communication mechanism, the sliced ​​flow of web page resources in a memory-constrained environment is realized. The principle behind this approach is to break down the continuous large file download task, which originally exceeded the physical capacity of the embedded device's hardware, into multiple discrete acquisition tasks within the RAM buffer capacity. Based on this, it not only completely solves the inherent problem that embedded chips cannot store large web pages due to insufficient Flash space (usually less than 1MB), but also avoids the interference of network latency on the device's real-time control tasks through an asynchronous mechanism. This ensures the robustness of the embedded device under high-load web page requests and significantly reduces storage resource consumption compared to the traditional full-load solution.

[0059] As can be seen, this embodiment further defines the intelligent cache negotiation decision flow when the system acquires resources. This mechanism perfectly intercepts meaningless repeated downloads, avoiding the end-to-end transmission of invalid data. Compared to traditional embedded devices passively and fully outputting web page files, the negotiation interception with extremely low overhead (only a few KB of memory consumption and lightweight HEAD requests) significantly reduces the consumption of communication bandwidth and significantly shortens the page loading time. At the same time, this also avoids the access failure problem caused by repeated downloads of large files in industrial weak network environments, making the loading experience of embedded dynamic web pages comparable to native local applications.

[0060] It is worth noting that, in one embodiment, the embedded device integrates an exponential backoff retry mechanism when performing asynchronous acquisition. When encountering network congestion or momentary packet loss, the embedded device does not immediately abandon the connection, but initiates up to 10 retransmission attempts at exponentially increasing intervals, and works in conjunction with the ACK (acknowledgment) mechanism to ensure the integrity of segmented resource blocks, thereby ensuring the reliability of dynamic webpage deployment in weak network environments.

[0061] In one embodiment, to address how the system can efficiently and accurately establish the underlying judgment criteria for intelligent cache negotiation in embedded memory with extremely limited resources, the specific initialization steps for obtaining the cache policy memory mapping table are further refined. Specifically, step S210, i.e., obtaining the cache policy memory mapping table, includes the following steps: S310: Read the preset caching strategy configuration file.

[0062] During the startup phase of an embedded device, or when its internal lightweight web service (such as the HTTPD module) is initialized, the system first reads a very small, pre-defined caching strategy configuration file (e.g., named cache_config.json) from internal read-only memory. This caching strategy configuration file is like a guide for the system to handle web page requests, pre-defining the principles for handling different types of files.

[0063] S320. Parse the cache policy configuration file to extract the mandatory caching rules and negotiated cache priorities for different resource types.

[0064] The embedded device's HTTPD module then parses the configuration file and extracts two core control parameters: The first item is the mandatory caching rule, which is used to directly determine how long a certain type of resource will absolutely not need to be downloaded again. For example, for static images (.png), set max-age=86400 (meaning it will not be downloaded again within 24 hours), for dynamic data (.json), set must-revalidate, and for the main frame of a webpage (.html), set no-cache.

[0065] The second item is negotiated cache priority, which specifies which fingerprint verification method should be used first when comparison with the server is required. For example, for HTML or JSON files, the priority order can be specified as file fingerprint verification (ETag) taking precedence over modification time checking (Last-Modified).

[0066] S330: Using the extracted forced caching rules and negotiated caching priorities, initialize the memory configuration of the embedded device to build a cache policy memory mapping table.

[0067] After extracting the above rules, the system uses this structured data to directly initialize and configure the volatile memory (RAM) of the embedded device. Specifically, the system allocates a very small dedicated area in the RAM and binds different resource types to their corresponding processing rules, thereby constructing a cache strategy memory mapping table for fast runtime retrieval.

[0068] As can be seen, this embodiment details the process of transforming the caching strategy from static files to a dynamic in-memory data structure. This design perfectly balances the flexibility of the strategy with extremely low execution overhead. Through a pre-defined configuration file, developers can flexibly adjust the caching strategies for different web page resources without modifying the device's underlying C code or recompiling the firmware. Simultaneously, by parsing and converting complex text configurations into a structured memory mapping table during the initialization phase, the table occupies minimal RAM space at runtime. This ensures that the embedded device can make caching decisions with extremely fast memory addressing speeds when handling high-frequency concurrent web page requests.

[0069] In one embodiment, considering the extremely limited memory space of embedded devices (e.g., some MCUs have only 64KB or 96KB of RAM), the specific execution logic of the preset memory management strategy is further refined. Since this solution completely abandons local Flash storage, all web page templates are temporarily resided and dynamically synthesized in RAM. Therefore, a strict dynamic release mechanism is necessary to prevent system crashes. The preset memory management strategy includes the following steps: S410: Real-time monitoring of the running memory usage of embedded devices.

[0070] As the embedded device runs and continuously responds to client web page requests, the underlying lightweight web server (or the operating system's memory management module) continuously monitors the usage of volatile memory (RAM) in real time. This step is a fundamental prerequisite for the system to maintain self-awareness and prevent memory overflow.

[0071] S420. Determine whether the running memory usage rate has reached the preset threshold, and whether the storage time of the web page resource template in the volatile memory has reached the preset effective time of the forced caching rule.

[0072] To achieve precise control, the system will judge and verify indicators in both spatial and temporal dimensions in real time: One aspect is space constraints, which means determining whether the current overall memory usage has reached the system's safety threshold, such as whether the memory usage has reached the preset dangerous threshold of 80%.

[0073] On the other hand, there is the time constraint, which is to check whether the time a specific web page resource template has resided in RAM has reached the preset effective duration (such as the lifespan set in the rule) based on the forced caching rules extracted in the previous steps.

[0074] S430. If the running memory usage rate reaches a preset threshold, or the storage duration reaches the valid duration, then the release condition is determined to be met, and the corresponding web page resource template is deleted from the volatile storage.

[0075] The aforementioned spatial and temporal conditions complement each other, forming a dual triggering mechanism. As long as either condition is met—either the system is running out of memory (e.g., memory usage is 80%) or the template data has expired—the system will immediately determine that the release conditions are met. At this point, the system will forcibly reclaim this memory, completely deleting and clearing the corresponding webpage resource template data and related cache remnants from volatile storage.

[0076] This embodiment further reveals the extreme memory management mechanism of embedded devices in the absence of local persistent storage. It comprehensively monitors memory usage and template validity duration, triggering a dual-judgment process to execute dynamic deletion. By introducing periodic cleanup in the time dimension, it effectively prevents the long-term accumulation of memory fragments and the retention of invalid data; while the spatial dimension's emergency circuit breaker mechanism ensures that when the device faces sudden high-concurrency access or requests for extremely large web resources, it frees up space for more urgent system tasks or new requests. This guarantees the long-term stable operation of the embedded web system with minimal memory overhead, completely eliminating the risk of device crashes or frequent restarts due to RAM exhaustion.

[0077] In one embodiment, the differentiated resource synchronization and chunked loading mechanism is further refined to address how the system can efficiently and reliably iterate and upgrade web page content and handle extremely large web page resources. Traditional firmware updates are similar to reinstalling the entire system; regardless of how small the changes are, the entire installation package needs to be downloaded. In IoT scenarios, this can easily lead to a large waste of bandwidth, long download times, and a high failure rate. Specifically, the method also includes the following steps: S510, in response to the update trigger command, sends a version verification request to the resource server and obtains the version metadata of the latest version.

[0078] The system update process can be initiated either through a scheduled task on the embedded device (e.g., automatically triggered every 30 minutes as shown in the example) or in response to a user-triggered update check (e.g., the user clicks the "refresh" button on the client). Once triggered, the embedded device sends a data refresh request to the resource server and retrieves the latest version of the core metadata. Current version metadata refers to lightweight characteristic information describing the state of web page components on the resource server. Its physical meaning is typically represented by, for example, the Last-Modified timestamp returned by the server (Last-Modified: 2025-12-17T08:00:00Z) or a unique file fingerprint identifier in the Hypertext Transfer Protocol (ETag: "v2.1").

[0079] S520. Compare the version metadata with the recorded historical version information, and generate an update flag when the comparison result is inconsistent; wherein, the historical version information includes the local resource version number pre-stored in the volatile memory of the embedded device, or the client local storage version number carried by the web resource request.

[0080] After obtaining the latest metadata, the system compares and verifies it with historical versions. The historical version information here can be the version number stored locally by the client browser (such as localStorage.version="v2.0"), which is passed to the device during the request; or the current version status recorded by the device itself in volatile memory.

[0081] If a difference is found between the two, the system will determine that the current resource has expired and generate a clear update flag (such as setting update_required=true).

[0082] S530: Request a list of differentiated resources from the resource server based on the update flag.

[0083] If the comparison matches, a skip flag is generated (update_required=false), terminating the update. However, when the update flag is true, the embedded device does not blindly fetch the entire webpage package; instead, it sends a directed request to the resource server for a "difference list" (e.g., sending a request GET / diff?v=2.0). The server then returns a list of specific resources that have only changed (e.g., containing only [" / js / main.js"," / css / style.css"]).

[0084] The physical meaning of a diff resource list is an incremental patch index that precisely records the minimum file paths or byte ranges that must be replaced to evolve from the current old version to the target new version. For example, in a complex monitoring page containing multiple JS logics and CSS styles, if only the sensor data display logic has changed, the diff resource list will only mark that specific JavaScript file fragment, while other static files such as the user interface (UI) framework remain unchanged.

[0085] S540. For resources to be updated in the differential resource list, implement differentiated acquisition and pass-through strategies based on resource size.

[0086] The embedded device iterates through the list of differing resources, evaluates the resource size of each file to be updated, and matches the appropriate transfer strategy: If the resource size exceeds a preset threshold: For large files such as high-definition charts, complex dynamic scripts, or large firmware, the embedded device uses the HTTP Range request directive (HTTP Range request header, e.g., Range:bytes=start-end) to initiate a segmented retrieval from the server. The server responds with a 206 PartialContent and sends out data slices. The embedded device does not perform local assembly and caching; instead, it directly passes the retrieved resource slices to the client in sequence. Finally, the client browser uses JavaScript's Promise concurrency mechanism and specific functions (such as merge Array Buffer) to merge these data slices into a complete updated resource (such as a complete Blob object) for rendering on the front end.

[0087] If the resource size does not exceed the preset threshold: For small, ordinary resources (such as small icons, short CSS styles, etc.), splitting the transmission will actually increase the handshake overhead of the network communication protocol layer. In this case, the embedded device directly performs a regular full retrieval operation from the resource server, pulls the complete updated resource at once, and directly passes it to the client for cache update.

[0088] As can be seen, this embodiment eliminates the drawback of having to download the full package for each update. This greatly saves valuable IoT communication traffic and reduces firmware-level webpage updates, which originally took several minutes, to within a dozen seconds. Furthermore, by employing an HTTP Range breakpoint-based chunked transmission mechanism for large files, it not only overcomes the physical limit of embedded device RAM capacity in buffering large files at once but also enables streaming processing with the client receiving and rendering simultaneously, significantly improving transmission reliability and first-screen loading speed in weak network environments.

[0089] Additionally, it's worth noting that, finally, due to the deep decoupling between web page resources and firmware logic, developers do not need to recompile the underlying firmware when dynamically expanding web page functionality, significantly improving the efficiency of embedded device function evolution and operational flexibility throughout its entire lifecycle.

[0090] In one embodiment, the underlying comparison logic of version metadata is further refined to ensure the system accurately determines whether the web page resources on the server side have truly undergone iteration. Specifically, step S520, which compares the version metadata with the recorded historical version information, includes the following steps: S610: Parse version metadata to extract the last modified time of the current resource and the fingerprint of the current file.

[0091] When an embedded device sends a data refresh request to a resource server and receives the latest version metadata (usually represented by HTTP response header information) from the server, the system's internal modules perform precise field parsing of this metadata. Specifically, the system extracts two key parameters: first, the "last modified time" reflecting the file's time attribute (e.g., extracting Last-Modified:2025-12-17T08:00:00Z from the response header); and second, the "current file fingerprint" reflecting the unique characteristics of the file content (e.g., extracting ETag:"v2.1").

[0092] S620: Match the last modification time and the current file fingerprint with the historical modification time and historical file fingerprint recorded in the historical version information.

[0093] After successfully extracting these two key parameters representing the latest state of the resource server, the system immediately initiates a comparison and decision-making mechanism between the local machine and the resource server. The system will match and verify the "last modified time" and "current file fingerprint" issued by the server with the historical version information recorded by the system (i.e., the historical modification time and historical file fingerprint representing the old version, such as the local storage historical version identifier localStorage.version="v2.0"). The system will make a consistency judgment based on these two indicators. Once a fingerprint string mismatch or a timestamp delay is found, it is confirmed that the resource server resources have undergone substantial updates, thereby triggering the subsequent differentiated resource retrieval process.

[0094] As can be seen, this embodiment details the specific verification dimensions for version comparison decisions. This solution simultaneously introduces file fingerprints (such as ETag) generated based on the actual content of the file, which, together with timestamps, construct a high-precision version verification defense. It can identify even a single byte of real change in resource content with extreme accuracy, much like verifying identity. This not only completely eliminates invalid pseudo-updates and avoids wasting valuable bandwidth, but also ensures that critical updates are not missed, providing the most solid and reliable data foundation for differentiated deployments.

[0095] In one embodiment, addressing the issue that traditional embedded web pages become completely unusable when the network is disconnected (e.g., causing sudden interruptions in industrial control or a severely poor smart home experience), the method further refines how the system builds an offline-available architecture based on offline caching components (such as Service Workers) on the client side. The method also includes the following steps: S710: When the client accesses the embedded device for the first time, push the offline caching component registration instruction to the client so that the client can register the offline caching component.

[0096] When a user's browser (client) visits the webpage of the embedded device for the first time, the embedded device will include a specific registration script instruction (such as loading the sw.js script) in the initial response. After receiving the instruction, the browser will register and activate an independent offline caching component in the background without the user's awareness (often called ServiceWorker in web technologies, which plays the role of offline manager).

[0097] During the installation phase, the S720 offline caching component acquires the core resources of the webpage and stores them in the client's cache space. These core webpage resources include the homepage file, the basic stylesheet, and the manifest file used to define application configuration information.

[0098] During the background installation phase, the offline caching component proactively retrieves the core assets necessary to maintain the basic operation of the web application from the resource server or embedded device. These resources do not contain large amounts of dynamic business data, but are limited to the core web page resources that ensure the basic UI framework. As an example, these core web page resources specifically include the homepage file (e.g., / index.html), the basic stylesheet (CSS) that ensures the basic visual layout, and the manifest file (e.g., / manifest.json) used to define application configuration information and offline features. These core resources are securely stored in a dedicated local cache space on the client side.

[0099] The S730 offline caching component is configured to query the cache space when a subsequent web resource request is intercepted, and if a corresponding web core resource is matched, respond to the client using the web core resource stored in the cache space; if no corresponding web core resource is matched, forward the web resource request to the embedded device.

[0100] Once activated, the offline caching component acts like a miniature gateway residing on the client's local machine, intercepting all subsequent web resource requests from the browser. When a user attempts to access a page, the offline caching component first intercepts the request and queries its local cache. If the user is requesting core web resources that have already been cached, the offline caching component will directly bypass network transmission and instantly respond to the client using the locally stored core resources.

[0101] If the requested content is not found in the local cache (e.g., the user clicks on a brand new page they have never visited before, or requests the latest real-time sensor data), the offline caching component will automatically allow the web page resource request and forward it over the network to the embedded device at the front end, which will then retrieve and return the latest resource.

[0102] In this embodiment, on the one hand, it ensures that even in extreme situations such as network fluctuations or complete network outages, the client can still rely on local resources to provide critical interface presentation and degraded services, greatly improving system availability and user experience in industrial and IoT scenarios. On the other hand, by intercepting and responding to requests at the forefront through an offline caching component, a large number of repetitive requests for core static resources are directly handled locally on the client. This greatly reduces the already weak CPU and network processing load of embedded devices, achieving a seamless interactive experience of automatic updates when online and cached usage when offline.

[0103] In one embodiment, to address the issue of ensuring that the core resources of an offline caching component (such as a Service Worker) stored locally remain consistent with those on the server during long-term operation, the interaction mechanism for background cache synchronization and condition verification is further refined. Following step SS710, i.e., after pushing the offline caching component registration instruction to the client, the method further includes the following steps: S810: Receive conditional verification requests sent by registered offline caching components after detecting that the core resources of a webpage have expired or that the network has been restored.

[0104] The offline caching component (Service Worker) acts as an offline manager residing on the client side. It not only provides degraded services during network outages but also possesses background status monitoring capabilities. When the offline caching component detects that core locally cached resources have expired (e.g., the cache's set expiration date has ended), or when the device reconnects to the network and network recovery is detected, the offline caching component automatically wakes up in the background. At this time, the offline caching component proactively sends a conditional verification request (e.g., an HTTP request carrying the local cache ETag) to the embedded device in the front end to inquire whether there are updated versions of these core assets.

[0105] S820: Based on the conditional verification request, query the resource server for the latest resource identifier of the corresponding resource.

[0106] After receiving the conditional verification request from the offline caching component, the embedded device continues to fulfill its role as a store-and-forward proxy. The embedded device then forwards or transforms the request and initiates a query to the remote resource server to specifically obtain the latest resource identifier of the corresponding webpage's core resource on the resource server (e.g., obtaining the latest ETag file fingerprint or last modified time on the server).

[0107] S830. If the latest resource identifier does not match the historical resource identifier stored in the offline caching component, the latest resource is obtained from the resource server and passed through to the client so that the offline caching component can update the stored core web page resources.

[0108] After obtaining the latest identifier from the resource server, the embedded device performs a comparison operation. If the latest resource identifier (e.g., the newly extracted ETag: "v2.1") is inconsistent with the historical resource identifier carried in the offline caching component's conditional request, it confirms that the core files on the resource server have been iterated. At this point, the embedded device will pull the latest complete resource from the resource server (e.g., a data packet accompanied by a 200 OK status code) and directly pass it to the client. Upon receiving the new resource, the offline caching component will call the local storage interface (e.g., execute the cache.put() operation) to overwrite and update its stored core web page resources.

[0109] S840. If the latest resource identifier matches the historical resource identifier stored in the offline caching component, return a status code indicating that the resource has not been modified to the client, instructing the offline caching component to continue using the stored core web page resources.

[0110] If the comparison results show that the two identifiers are completely identical, it proves that the resources on the resource server have not changed during this period. At this time, the embedded device will directly intercept the operation of retrieving the complete entity file and simply return a very lightweight resource not modified status code (such as a 304 NotModified response) to the client. After receiving this status code, the offline caching component knows that the local data is still up-to-date and safe, and thus continues to use its stored core web page resources for subsequent service responses.

[0111] As can be seen, this embodiment solves the pain points of data staleness and dead caching in traditional offline caching solutions. By silently performing conditional request verification in the background, the system only triggers actual data transmission and cache updates when there is a substantial change in the core content (i.e., when the ETag does not match). This not only ensures that embedded devices can quickly synchronize with the resource server with extremely low bandwidth costs after the network is restored, but also effectively avoids the bandwidth consumption caused by mindless full synchronization in the background for IoT communication, thus achieving a perfect balance between offline availability and data real-time performance for the entire web application.

[0112] In one embodiment, the network status awareness and offline degradation response mechanism is further refined for extreme network situations (such as sudden device network outage) when offline caching components (such as Service Workers) handle local cache misses. Traditional embedded web pages often directly throw browser error pages (such as "Unable to connect") when the network is down, leading to industrial control interruptions or a precipitous drop in user experience. To achieve true offline availability, step S730, which forwards the web page resource request to the embedded device when no corresponding core web page resource is matched, includes the following steps: S910. When no corresponding webpage core resource is matched, obtain the network connection status between the client and the embedded device.

[0113] When a client initiates a webpage request, and the offline caching component residing on the front end queries and finds that the core resources of the webpage corresponding to the request are not stored in the local cache space, the offline caching component will not immediately and blindly send out network requests. Instead, the offline caching component will first act as a network probe to obtain the real-time network connection status between the current client browser and the backend embedded device (i.e., determine whether it is currently in an "online" or "offline" environment).

[0114] S920. If the network connection status is normal, then perform the operation of forwarding the web resource request to the embedded device.

[0115] If the network connection is confirmed to be normal (online) after detection, the offline caching component will resume its transparent proxy function. The offline caching component will smoothly allow the request for the web resource that missed the cache and forward it to the embedded device's web server through the first communication link or other network channels, so that the embedded device can obtain the latest resource data from the resource server or temporary RAM for normal response processing.

[0116] S930. If the network connection is disconnected, retrieve the preset offline degradation resources stored in the cache space and respond to the client.

[0117] If the target cache is not hit and a network outage (offline) occurs simultaneously, the offline caching component will not display the native error page in the browser. Instead, it will redirect to its cache space and actively retrieve pre-set offline degradation resources (e.g., a user-friendly customized HTML prompt page saying "Device is offline, please check your network," or a degradation UI panel that retains the basic operation interface). Subsequently, the offline caching component uses these degradation resources to directly complete partial rendering and response to the client.

[0118] As can be seen, this embodiment reveals in detail the ultimate defense mechanism of the system under the dual adverse conditions of cache miss and network disconnection.

[0119] This mechanism completely changes the fragile state of traditional embedded web systems, which are completely unable to function when the network is offline. By intercepting network outages at the client-side and providing graceful offline degradation services, the system not only prevents browsers from throwing harsh error pages, but also ensures that critical user interfaces (even degradation prompts) can still be safely displayed when the network is offline.

[0120] In one embodiment, to address the issue of how a client webpage can interact bidirectionally with the underlying embedded hardware in an architecture without local storage, the closed-loop mechanism for the entire link of user interaction and control command execution is further refined. After step S150, that is, after the target webpage content is returned to the client, the following steps are also included: S1010: Receive a control command request sent by the client, which is generated by the web page script based on the user's operation.

[0121] After the target webpage content is successfully returned and rendered in the client browser, the user will perform operations through the browser interface (e.g., clicking a "Power on device" button). At this point, the webpage script (such as JavaScript) in the front-end page will convert the user's action into a standard HTTP request (e.g., generating a POST form for LED control, or initiating an XMLHTTP request) and send it to the embedded device's web server. The embedded device is responsible for receiving this control command request.

[0122] An embedded web server (also known as an HTTPD) is a lightweight software service module integrated and running within a resource-constrained microcontroller unit (MCU, such as ESP8266, STM32, or Cortex-M series) in an embedded device. In this embodiment, the server typically employs a single-file structure or a loosely coupled modular design (such as NanoHTTPD), with its core objective being to provide standard Hypertext Transfer Protocol (HTTP / HTTPS) support with extremely low hardware resource consumption.

[0123] For example, to ensure the confidentiality of data transmission, embedded devices preferably use the HTTPS protocol based on SSL / TLS for interaction with sensitive control commands involving modifications to device configuration parameters.

[0124] S1020: The control command request is parsed by calling the public gateway interface, and the parsed command data is passed to the command execution process of the embedded device through a preset call chain.

[0125] After receiving request data, the HTTP receiving module inside the embedded web server directs it to a designated Common Gateway Interface (CGI) for parsing. To bridge the gap between the web world and the underlying operating system, the system pre-defines an extremely streamlined call chain: HTTP engine → CGI → file system. Through this dedicated call chain, the specific instruction data parsed by the CGI interface can be securely and accurately transmitted to the underlying instruction execution process of the embedded device (such as the embedded device's shell process).

[0126] S1030 triggers the hardware unit corresponding to the instruction execution process to perform the operation and feeds back the execution result to the web script via the public gateway interface so that the web script can update the client display interface.

[0127] It should be noted that a hardware unit refers to a physical entity directly or indirectly driven by an embedded device. For example, hardware could be a relay, stepper motor, dimming LED light assembly, or sensor array in an industrial setting. A control command request is an asynchronous command triggered by a user on the client browser interface (such as clicking a switch button or dragging a progress bar) aimed at changing the operating state of the hardware.

[0128] This request is typically encapsulated in an HTTP / HTTPS POST message, carrying specific payload data, such as a JSON-formatted command string {"target":"relay_1","action":"on"}. The Common Gateway Interface (CGI) acts as the standard communication bridge between the web server and the external application in this process. Upon receiving the command data, the embedded shell process immediately triggers the corresponding low-level hardware driver, which in turn directs the actual hardware execution unit to perform the physical operation (e.g., actually turning a physical LED on or off). After the hardware completes the action, it returns the execution status (result data) via the same route, i.e., the result is returned to the web server via the CGI, and then transmitted back to the client via an HTTP response message. Finally, the client's web page script parses this feedback result and updates the interface display in real time accordingly (e.g., updating the button status from "On" to "On (highlighted)").

[0129] It should be noted that, in other embodiments, for control requests involving sensitive operations such as modification of device parameters, the system preferably uses a secure HTTPS connection based on the SSL / TLS protocol. By encrypting the transmission of the control payload, it is ensured that the instruction data before CGI parsing is not eavesdropped on or tampered with in public or open local area network environments, thus protecting the security and confidentiality of the underlying hardware control process.

[0130] As can be seen, this embodiment details the complete interactive control flow path from front-end user clicks to back-end hardware actions and then to front-end state updates. This mechanism establishes a real-time bidirectional communication loop between lightweight embedded devices and clients in a B / S (Browser / Server) model. The system eliminates the need to develop cumbersome cross-platform native control apps (such as dedicated iOS or Android applications), achieving deep control over the underlying physical hardware directly using standard HTML tags and scripts. This significantly reduces the development workload of multi-platform control programs and the security risks associated with app store approvals, allowing users to enjoy real-time interaction and lightning-fast hardware response comparable to native apps within a single browser.

[0131] In a further embodiment, the process of returning the target webpage content to the client for dynamic rendering is described in detail. Specifically, step S150, which involves returning the target webpage content to the client for dynamic rendering, includes the following steps: S1501. Parse the header of the first response message returned by the resource server in response to the range request, so as to extract the total resource size of the complete resource corresponding to the web page resource template; S1502. Determine the segment offset of the target webpage content in the complete resource based on the segment range corresponding to the webpage resource request. S1503. Generate a second response message header carrying the segment offset and the total resource size; S1504. Encapsulate the target webpage content in the corresponding second response message and return it to the client, so that the client can allocate storage space based on the total resource size and merge the returned target webpage content in an orderly manner according to the segment offset.

[0132] In this embodiment, the segment offset refers to the starting byte position of the currently sent webpage data block in the complete target resource file. The total resource size refers to the complete byte length of the final target webpage content after dynamic synthesis. In embedded web interaction scenarios, the size of the target webpage content (such as a page containing a large number of real-time monitoring charts) may reach the MB level (e.g., a 3MB webpage), while the RAM space of embedded devices is often less than 20KB, making it impossible to construct a complete response message in memory at once. The total resource size is extracted by the embedded device from the header of the first response message returned by the resource server for the range request.

[0133] During execution, the embedded device first parses the segment range (such as the HTTPRange header) in the client request to determine the logical position of the synthesized and sent data segment, i.e., the segment offset of the target webpage content within the complete resource. Subsequently, when generating the second response header, the embedded device fills in the segment offset and the total resource size according to a specific protocol format (such as the Content-Range field under the HTTP 206 PartialContent status code). For example, the header information can be represented as "bytes1024-2047 / 3145728", where "1024" is the segment offset and "3145728" is the total resource size of approximately 3MB.

[0134] After the embedded device encapsulates the target webpage content in a corresponding second response message and returns it to the client, the client browser receives the header information of this second response message and can pre-determine the size of the complete resource. Based on the total resource size, the client can pre-allocate sufficient and contiguous storage space in local memory or temporary storage, thereby mitigating the performance overhead caused by frequent memory reallocation when receiving subsequent data blocks. Due to the possibility of out-of-order delivery or packet loss during network transmission, the client can accurately place multiple received, non-contiguous webpage fragments into their corresponding positions in the pre-allocated space by identifying the segment offset carried by each block, ultimately achieving ordered merging.

[0135] It is worth noting that this processing mechanism is particularly important when handling industrial monitoring panels with high-frequency data updates. When web pages contain complex JavaScript logic or high-resolution UI assets, the device achieves reliable transmission of large web pages in a micro-memory environment through this streaming disassembly-client reassembly strategy.

[0136] As can be seen, this embodiment achieves distributed transmission of large-capacity data in a memory-constrained environment by determining the segment offset and the total resource size and encapsulating them in the response header. This shifts the peak memory buffer pressure, which would normally occur on the embedded device, to the client with relatively abundant storage resources, allowing the embedded device to maintain only a very small sliding window. Consequently, it significantly reduces the peak RAM usage of the embedded device when processing large web pages (e.g., 3MB in size), preventing system crashes due to memory overflow. Simultaneously, the offset-based ordered merging mechanism, combined with client-pre-allocated space, greatly improves the efficiency of data reassembly, significantly shortening the first-screen loading time of a 3MB web page and fundamentally solving the performance bottleneck of embedded web services when handling complex business logic.

[0137] In one embodiment, the process of dynamically loading the acquired webpage resource template into the random access memory (RAM) of the embedded device is further described in detail. Specifically, step S103, which involves dynamically loading the acquired webpage resource template into the RAM of the embedded device, includes the following steps: S1031. Based on the distributed loading configuration file, configure non-overlapping loading domains and running domains in RAM; S1032. The obtained web page resource template is stored in the loading domain, and the instruction segment used for executing logic or the data segment used for storing character data in the web page resource template is deployed to the running domain through address space remapping, so as to realize the real-time calling of the web page parsing engine in RAM.

[0138] Specifically, a scatter file is a logical specification file that defines the layout of embedded system code and data within physical storage space. In the chips of resource-constrained embedded devices, whose flash memory is typically less than 1MB and needs to support low-level control logic (such as industrial sampling and protocol stack management), sufficient static storage space cannot be reserved for large web applications. The load region refers to the address space where data is initially stored in physical memory, while the execution region is the logical address space where the data is actually accessed by the processor to execute tasks. An instruction segment refers to a sequence of binary machine instructions or pseudocode logic in a web resource template that has been pre-compiled or processed in a specific format and can be directly read and executed by the embedded device's processor (CPU). In this embodiment, it mainly carries the core processing logic of the web page parsing engine, such as logical instructions for identifying placeholders, performing segmented data verification, or triggering hardware interactions. The data segment refers to the static character information and attribute parameters used to form the skeleton of a web page in the web page resource template. It mainly includes HTML tag strings, CSS style sheet data, JavaScript logical constants, and preset logical placeholders (such as "TAG:Temperature").

[0139] During execution, after the embedded device starts a lightweight service instance (such as Elysian\Web\Server), the kernel reads a pre-defined scatter loading configuration file. Based on the configuration of this file, the embedded device forcibly partitions two logically isolated and non-overlapping regions within its physical RAM. When the embedded device receives on-demand web resource templates (such as HTML fragments containing declarative tags or JS script libraries) via the network protocol stack, these raw data streams are first written to the loading domain. Subsequently, instead of performing a traditional data copy operation, the embedded device uses address remapping technology to directly map the physical addresses in the loading domain to the virtual address segments of the runtime domain. The embedded device's web page parsing engine (i.e., the lightweight execution unit responsible for parsing template placeholders and composing the page) can directly read and process this data within the runtime domain, without the need for cumbersome secondary memory transfers in RAM.

[0140] It's worth noting that this memory management mechanism based on distributed loading configuration files is particularly suitable for scenarios with large fluctuations in peak memory usage. For example, when an embedded device needs to process real-time sensor sampling and highly complex web scripts simultaneously, physically isolating the loading and execution spaces in RAM can ensure that web application data does not accidentally overwrite critical control task data.

[0141] As can be seen, in this embodiment, firstly, the embedded device achieves strong constraint management of its extremely limited RAM resources by configuring non-overlapping loading and runtime domains based on a distributed loading configuration file. This is achieved by using logical partitioning to physically isolate business data from core system tasks. Based on this, it effectively solves the memory overflow or memory overload problems caused by dynamic resource loading in extremely low memory environments (such as RAM peak usage needing to be controlled within 20KB), significantly improving the robustness of the embedded device under high-concurrency webpage requests. Secondly, by deploying resources to the runtime domain through address space remapping, the instruction cycle overhead of the CPU moving large webpage templates in memory is reduced, thereby significantly improving the real-time calling speed of the embedded device's webpage parsing engine. This significantly enhances the synthesis and response efficiency of large webpages (such as those on the 3MB scale) even on MCUs with lower clock speeds, ensuring smooth web interaction.

[0142] In one embodiment, the process of dynamically synthesizing webpage resource templates using real-time data is further described in detail. Specifically, step S130, which involves dynamically synthesizing webpage resource templates using real-time data, includes the following steps: S1301. Identify preset dynamic tags from the web page resource template. The preset dynamic tags are specific character placeholders or custom HTML attribute tags embedded in the web page resource template. S1302. Establish the mapping relationship between each preset dynamic flag and the hardware registers or system global variables of the embedded device; S1303. Based on the mapping relationship, extract the real-time status parameters from the corresponding hardware registers or system global variables as real-time data. S1304. Replace the preset dynamic tags in the web page resource template with real-time data to generate target web page content containing real-time values.

[0143] In this embodiment, specifically, the preset dynamic markup refers to the logical anchor point pre-set in the HTML, CSS, or JavaScript code during the webpage front-end design stage. Specific character placeholders can be represented as strings with special prefixes.

[0144] For example, TAG:Temperature or {{temp_value}}; custom HTML attribute tags can be extended attributes conforming to the HTML5 specification, such as data-bind="cpu_load". The physical meaning of these tags is that they reserve display space for dynamically changing hardware data in the webpage structure, but they themselves do not contain specific numerical values.

[0145] The process of establishing mapping relationships in embedded devices refers to building a lookup table in the firmware logic of the embedded device that connects front-end tags with underlying data sources. The definition of the mapping relationship includes not only the tag name but also the specific physical access path. For example, the tag TAG:Voltage is mapped to the sampling register address of the ADC (Analog-to-Digital Converter), or TAG:Status is mapped to a global structure variable in the system kernel that represents the running status of a task.

[0146] When an embedded device performs dynamic data synthesis, its web page parsing engine scans the loaded template data in RAM line by line or block by block. Upon identifying a matching preset dynamic tag, the parsing engine, based on the aforementioned mapping relationship, immediately triggers a read operation on the corresponding hardware register or system global variable. For example, it reads the raw values ​​from a temperature and humidity sensor via the I2C bus and converts them into the corresponding ASCII string format as real-time data.

[0147] The process by which an embedded device replaces preset dynamic tags with real-time data is an in-situ replacement or concatenation operation performed within a RAM buffer. The parsing engine deletes the identified tag placeholders and fills in the latest real-time status parameters at those locations. Because this process is executed directly in memory and does not involve complex script parsing, it generates target webpage content containing real physical parameters. For example, dynamically updating "Current Temperature: TAG:Temp" in a template to "Current Temperature: 25.6℃".

[0148] It should be noted that, in addition to static replacement based on HTTP requests, embedded devices can also support real-time data synchronization via a WebSocket full-duplex channel. For example, when the state of hardware registers changes frequently, the embedded device can proactively push real-time status parameters to the client, thereby achieving dynamic updates of the monitoring screen without having to re-fetch the webpage template.

[0149] In this embodiment, the traditional procedural rendering process is replaced by identifying preset dynamic markers and establishing their mapping relationship with hardware registers or global variables. A simplified character replacement mechanism replaces high-power dynamic script execution (such as Node.js or heavyweight CGI). This not only reduces the computational resource consumption of embedded devices when generating dynamic web pages but also significantly improves the real-time data feedback speed. Furthermore, since the UI layer is associated with the hardware only through markers, developers do not need to recompile the underlying firmware code when modifying the web page layout, greatly enhancing the system's maintenance flexibility and shortening firmware update and maintenance time.

[0150] In one embodiment, the method further includes: in response to the client's access, obtaining a script component from the resource server in real time and transmitting it to the client, wherein the web page resource template and the corresponding script component are jointly deployed in the resource server.

[0151] In the above process, the webpage resource templates and corresponding script components (such as JavaScript dynamic scripts, ALE components, etc.) are centrally deployed on a remote resource server, rather than being permanently stored in the local Flash storage of the embedded device. This model uses the server as the core resource library for unified storage and distribution.

[0152] When a client (such as a standard browser) requests access to a webpage, the embedded device, acting as a connection bridge and a store-and-forward proxy, responds to the client's request. The embedded device uses its built-in lightweight HTTP server to request various script components (such as " / js / main.js") required for page rendering in real time from the resource server. After obtaining these script components, the embedded device performs only temporary data processing in RAM and directly passes them through (i.e., forwards them as is) to the client without any local persistent storage. Upon receiving the passed-through script components, the client browser executes the dynamic scripts using its built-in JavaScript parser, thereby achieving dynamic page rendering and real-time user interaction.

[0153] By employing the aforementioned mechanism, web page resource templates and corresponding script components are jointly deployed on the resource server and obtained and transmitted in real time through embedded devices. This overcomes the stringent limitations of local physical storage capacity on embedded devices, enabling smooth support and presentation of modern web applications with complex interactive scripts even on small devices with extremely limited storage resources such as Flash. Secondly, it significantly optimizes the system's update and maintenance mechanisms and functional scalability. Because resources are uniformly deployed on the server side, the underlying script library and web page templates can be independently upgraded and updated. When it is necessary to dynamically expand system functions or fix component vulnerabilities, developers only need to update the corresponding script files on the server side. The device can then retrieve and transmit the latest scripts in real time during subsequent client accesses, without recompiling or flashing the embedded device's local firmware. This avoids the risks of device downtime and business interruption caused by traditional firmware upgrades and flashing, achieving seamless upgrades and significantly improving the iteration efficiency and ease of maintenance of the device's web system.

[0154] In a preferred embodiment, the interception and synchronous rendering process on the client side in the above-described web resource processing method is further described in detail. The method also includes: passing an offline management script to the client so that the offline management script resides and runs in the background of the client; wherein, the offline management script is configured to build offline proxy logic on the client to intercept resource access requests in the offline state and prioritize calling the target resources cached locally on the client for rendering; in response to the synchronization request initiated by the offline management script after detecting network recovery, the corresponding updated resources are obtained from the resource server as needed and dynamically loaded into RAM for processing before being passed to the client to realize the dynamic update of the client's local cache.

[0155] Specifically, the offline management script is preferably a ServiceWorker script based on Web standards. Physically, this means a script execution environment running in the browser background, independent of the current webpage, acting as a programmable proxy between the client browser and the network (i.e., the embedded device). Static resource loading requests refer to loading instructions for files on a webpage that do not change with the device's real-time state. These mainly include Cascading Style Sheets (CSS), JavaScript logic libraries, common vector icons, and basic UI framework files.

[0156] During execution, when a user accesses the embedded device through a browser, the offline management script utilizes its built-in fetch event listener mechanism to precisely intercept all static resource requests sent to the embedded device. If a request is intercepted, the offline management script does not immediately retrieve resources from the network side, but instead prioritizes searching the client's local persistent storage space (such as cache storage). Simultaneously, the offline management script initiates parallel requests to the embedded device for the target webpage content, focusing on obtaining real-time dynamic business data from the embedded device (such as sensor sampling values ​​or device status words). Synchronous rendering refers to the process by which the offline management script logically assembles and jointly outputs the offline static resources extracted locally (as the webpage's shell) and the target webpage content obtained in real-time from the device (as the webpage's kernel) within the browser's memory. This approach allows the browser to quickly render a complete visual interface without waiting for large frame files to be transferred from the bandwidth- and memory-constrained embedded device.

[0157] In this embodiment, firstly, static requests are intercepted by an offline management script and rendered using pre-stored resources. This process utilizes the client's computing and storage resources to significantly reduce the network throughput pressure on the embedded device. As a result, the embedded device only needs to transmit a very small amount of dynamic business data when responding to requests. This not only greatly reduces the throughput load of the embedded device in network interaction, but also ensures that the page can still be activated quickly in a weak network environment, shortening the response time of the first screen of the webpage.

[0158] Secondly, the synchronous rendering mechanism effectively eliminates page white screens or interactive flickering caused by download delays of large static resources, significantly improving the smoothness of human-computer interaction and user experience in industrial monitoring scenarios. Finally, by making large UI resources offline, the requirements for local Flash space on embedded devices are further relaxed, making it possible to deploy fully functional and visually rich multimedia applications on extremely low-end chips with Flash capacity of less than 1MB.

[0159] In one embodiment, the device initialization and discovery process before receiving a web resource request from a client in the web resource processing method is further described in detail. This process specifically includes the following steps: S01. After power-on, initialize and run the embedded Web service instance to build a communication interface for responding to web resource requests; S02. Within the local area network associated with the communication interface, broadcast device identification information using a broadcast protocol, so that the resource server can establish a forwarding mapping relationship between web page resource templates and embedded web service instances based on the device identification information.

[0160] Specifically, after powering on, the embedded device first enters Soft-AP+Station mode, creating an independent AP hotspot Wi-Fi network to await client browser connections. Subsequently, the embedded device initiates the lightweight web server initialization process. This process includes configuring the sbOptions structure to set port and event handler parameters, calling core functions such as sb_new_server() to create a service instance, and then entering the sb_poll_server() event loop to build a communication interface for listening to and responding to HTTP requests. For example, the web service instance here preferably uses a lightweight kernel with a single-file structure or a loosely coupled modular design, such as NanoHTTPD, cwhttpd, or MinnowServer. Its static memory footprint is typically optimized to less than 20KB to adapt to hardware environments with extremely limited Flash and RAM resources.

[0161] Upon service startup, the embedded device can proactively broadcast its device identification information within the associated local area network using the UDP protocol. This device identification information includes metadata such as the device's unique hardware identifier, current IP address, and model characteristics. Upon receiving the broadcast packet, the resource synchronization module on the resource server (such as a central resource management system) parses the device identification and associates it with a specific web page resource template in the storage layer, thus constructing a forwarding mapping relationship. This means that when subsequent clients access the device through this communication interface, the resource server can accurately and in real-time distribute HTML / CSS template fragments adapted to that device model based on the mapping relationship.

[0162] As can be seen, this embodiment utilizes an active discovery mechanism to replace the traditional, cumbersome manual registration process, enabling the resource server to dynamically perceive the resource needs of each terminal within the network. This significantly reduces the operational complexity and manpower costs during system integration, laying the physical communication foundation for the transformation of embedded devices from storage carriers to communication proxies.

[0163] Secondly, by establishing a forwarding mapping relationship between web resource templates and Web service instances, the addressing and matching challenges in dynamic deployment environments are effectively solved. Through logical abstraction of terminal devices by a central resource management system, iterative updates of web resources only require mapping configuration on the server side, without modifying the device firmware code. This not only enables embedded devices to dynamically adapt to changes in IP addresses but also completely eliminates the update and maintenance risks caused by fixed web resources, ensuring the reliability and consistency of web resource dynamic deployments under extreme resource constraints such as 8-bit or 16-bit MCUs.

[0164] In one embodiment, a web page resource processing method is provided, including a core processing flow, an intelligent cache negotiation and management mechanism, a web page content update and cache synchronization mechanism, and an offline caching architecture based on Service Worker, which are described below.

[0165] Core processing flow: In this core processing flow, the embedded device needs to achieve dynamic resource transfer through collaborative interaction with the server. Its key processes, divided into four stages according to time sequence, include device initialization, resource preparation, page loading, and interaction control. The data flow and core interaction nodes of each stage are as follows. This method includes the following processing stages: Embedded device initialization and service startup.

[0166] After the embedded device powers on, it operates in Soft-AP+Station mode, creating an independent AP hotspot Wi-Fi network and waiting for the mobile app browser to connect. Then, it completes the lightweight web server initialization process: configuring the port and event handler parameters through the `sb_Options` structure, calling `sb_new_server()` to create a service instance, then entering the `sb_poll_server()` event loop to handle client connection requests, and finally releasing resources through `sb_close_server()`. During this stage, the embedded device discovery mechanism is also initiated, broadcasting basic device information via UDP. The resource server uses this information to build a central resource management system, realizing resource mapping between the embedded device and the resource server.

[0167] The data flow during this stage is as follows: Embedded device → (UDP broadcast) → Server-side resource management system → (mapping configuration) → Embedded device web server.

[0168] Webpage resource compilation and deployment preparation.

[0169] To achieve dynamic deployment of embedded devices without local storage, resource preprocessing needs to be completed during the development phase: Single-Page Application (SPA) assets are converted into C arrays using specialized tools, and necessary modules are extracted from the Web server library using library selection compilation technology to form lightweight embedded Web service firmware. Resource integration adopts two methods: one is to compress Web resources and applications into a single file; the other is to convert resource characters into ASCII arrays and compile them directly into the firmware to avoid runtime dependence on local storage.

[0170] The data flow during this stage is as follows: Development side → (Asset conversion / compilation) → Device firmware → (ROM loading) → Device memory.

[0171] Client requests and dynamic page generation.

[0172] After the client browser initiates a page request, the device's web server executes a dynamic content generation process: it reads the static HTML template from ROM, identifies dynamic tags such as "TAG:Temperature" and replaces them with real-time data (such as ambient temperature values), generates a complete webpage, and then sends it to the client. For large resources, a segmented loading mechanism is used: the client sends an Ajax request → the server segments the response content → the client loads the content in segment order, achieving simultaneous reception and rendering.

[0173] During this phase, the HTTP Range request interaction process includes: When requesting a large file resource, the interrupted resume download process is triggered: (1) The client records the downloaded byte position through localStorage (such as the download Position variable) and sends the Range: bytes=start-request header.

[0174] (2) The server parses the Range header and returns a 206 Partial Content response, which includes the Content-Range: bytes start-end / total header and the block data.

[0175] (3) The client concurrently receives Array Buffer blocks through Promise.all and calls the merge ArrayBuffer function to merge them into a complete Blob object by offset for rendering.

[0176] The data flow during this stage is as follows: Client → (HTTP / Ajax request) → Device Web Server → (Dynamically generated / segmented response) → Client → (Data merging) → Web page rendering.

[0177] User interaction and control command execution.

[0178] The user triggers the control flow through the browser interface, and the specific path is as follows: (1) Command generation: The web page script converts user operations into HTTP requests (such as POST forms for LED control), which are then passed to the device web server via the XMLHTTP component to specify the CGI interface.

[0179] (2) Request parsing: The HTTP receiving module of the embedded web server analyzes the request data and passes the instructions to the device shell process through the call chain of HTTP engine → CGI → file system.

[0180] (3) Execution feedback: After the hardware executes the instruction (such as LED turning on / off), the result is returned to the Web server via CGI, and then transmitted to the client via HTTP response. The script parses the response and updates the interface display.

[0181] Typical control command flow path.

[0182] User operation → Web page script conversion → HTTP request (POST / XMLHTTP) → Device web server → CGI interface → Shell process → Hardware execution → Result returned via the original path → Interface update.

[0183] The data flow at this stage is as follows: User → (Operation Input) → Client Browser → (Control Commands) → Device Web Server → (Hardware Control) → Device Execution Unit → (Result Data) → Client Interface.

[0184] Intelligent cache negotiation and management mechanism: Traditional embedded devices have to download all resources every time they access a webpage, wasting bandwidth and slowing down the process. Especially in industrial environments with unstable networks, repeated downloads can cause frequent page loading failures.

[0185] The intelligent cache negotiation and management mechanism in this application includes an intelligent cache negotiation mechanism with the following processing steps: Step 1: Initialize and configure the caching strategy.

[0186] Input: The caching strategy configuration file (cache_config.json) loaded when the embedded device starts, containing: Forced caching rule: Set max-age=86400 for static resources (.css / .js / .png).

[0187] Negotiated caching priority: ETag verification takes precedence over Last-Modified.

[0188] Operation: The device's HTTPD module parses the configuration file and sets up a memory mapping table for caching strategies. Output: Cache policy memory mapping table (RAM usage ≤ 2KB).

[0189] Step 2: Browser cache status check.

[0190] Triggering condition: The user accesses a webpage on the device (e.g., GET / index.html).

[0191] 1. The browser uses JavaScript to call caches.match(event.request) to check the local cache.

[0192] 2. The browser informs the embedded device of the cache status (existence / non-existence) through the AJAX header field X-Cache-Status: HIT / MISS.

[0193] Step 3: Embedded device cache decision response.

[0194] Input: Browser request headers (including If-None-Match / If-Modified-Since).

[0195] 1. The embedded device's HTTPD module parses the request header and queries the server's resource metadata (obtaining ETag / Last-Modified via HEAD / resource).

[0196] 2. Compare browser cache flags: If the ETag matches, a 304 Not Modified response will be returned (no response body).

[0197] If there is a discrepancy, pass the new resources to the server.

[0198] Output: HTTP response (status code + header fields).

[0199] Step 4: Cache resource release mechanism.

[0200] Triggering conditions: Cache resources reach max-age or memory usage is detected to be ≥80%.

[0201] Operation: Browsers delete expired caches using caches.delete(), while embedded devices do not perform local storage operations.

[0202] Verification: The number of cached entries was confirmed to have decreased by calling `caches.keys().then(keys => keys.length)`.

[0203] Webpage content update and cache synchronization mechanism.

[0204] Updating firmware for traditional embedded devices is like reinstalling the operating system on a mobile phone. Whether you only change an icon or update the entire interface, you have to download the complete installation package. In IoT scenarios for embedded devices, this leads to a significant waste of bandwidth and a risk of update failures. In particular, battery-powered devices may experience reduced battery life due to frequent large file transfers.

[0205] This application adopts a processing mode similar to splitting express parcels to achieve accurate updates of dynamic content: Input: Embedded device timed task (30-minute cycle) or user-triggered update check (such as clicking the refresh button).

[0206] Operation: The embedded device requests the latest version information from the resource server, obtaining the last modified time and file fingerprint (e.g., Last-Modified: 2025-12-17T08:00:00Z and ETag: "v2.1"). After comparing it with the historical version stored locally (localStorage.version = "v2.0"), if differences are found, it requests a list of differing resources, similar to buying only the parts that need to be replaced rather than the entire product when shopping online.

[0207] Output: Embedded device update flag (update_required=true) or skip flag (update_required=false), only retrieve the list of divisible resources (such as [" / js / main.js"," / css / style.css"]) when an update is needed, download them one by one and pass them through to the browser.

[0208] The processing steps include the following: Step 1: Obtain server version metadata.

[0209] Input: Embedded device timed task (30-minute cycle) or user-triggered update check (such as clicking the refresh button).

[0210] Operation: Request the resource server to refresh the data.

[0211] Output: The resource server returned Last-Modified:2025-12-17T08:00:00Z and ETag: "v2.1".

[0212] Step 2: Version comparison decision.

[0213] Input: Local storage version (localStorage.version="v2.0").

[0214] Operation: The embedded device compares the local historical version with the latest version on the resource server to detect whether the file needs to be updated.

[0215] Output: Embedded device update flag (update_required=true) or skip flag (update_required=false).

[0216] Step 3: Synchronize differentiated resources.

[0217] Input: Embedded device update flag is true.

[0218] operate: 1. Embedded device requests a list of diff resources: GET / diff?v=2.0.

[0219] 2. The resource server returns a list of resources that need to be updated (e.g., [" / js / main.js"," / css / style.css"]).

[0220] 3. The embedded device acquires new resources piece by piece and transmits them to the browser.

[0221] Output: Browser cache update (new resources + new ETag).

[0222] Offline caching architecture based on Service Worker.

[0223] This solution includes building an offline caching system to ensure that critical functions remain available even when the network is offline, including: Input: The browser is accessing the embedded device's webpage for the first time.

[0224] Operation: Register a Service Worker as an offline manager to cache core resources (such as the homepage and basic stylesheets) on the first visit. When a user visits a new page, the cached content is used first; once the network is detected to be restored, resources are automatically updated in the background.

[0225] Output: Service Worker is successfully registered and activated, enabling a seamless experience of automatic updates when online and cached usage when offline. When cached resources expire, the resource status is verified via a conditional request, and the cache is updated only when the content changes.

[0226] The processing steps include: Step 1: Service Worker registration and installation.

[0227] Input: The browser's first visit to the device's webpage.

[0228] operate: The browser loads sw.js and registers the Service Worker.

[0229] Service Worker caches core resources ( / index.html / / manifest.json) during the installation phase.

[0230] Output: Service Worker registered successfully (registration.active.state = 'activated').

[0231] Step 2: Request interception and cache matching.

[0232] Triggering condition: The user visits a new page (e.g., GET / dashboard.html).

[0233] Operation: Check if the page accessed by the user has a cache file on the local machine.

[0234] Output: Returns either the cached resource (preferred) or the new resource passed through to the embedded device.

[0235] Step 3: Cache synchronization and device interaction.

[0236] Input: Service Worker detected that the cached resource has expired (e.g., ETag has changed).

[0237] operate: 1. Send a condition request to the embedded device.

[0238] 2. Embedded devices transmit server responses transparently: If the ETag matches, a 304 Not Modified error will be returned.

[0239] If inconsistent, return the new resource (200 OK+ETag: "v2.1").

[0240] Output: Service Worker updates local cache (cache.put()).

[0241] As can be seen from the above embodiments, the technical effects brought about by the embodiments of this application include: I. Overcoming the storage limitation problem.

[0242] Addressing the limitation of local Flash storage capacity in traditional embedded devices, this application employs a server-side centralized storage and dynamic loading mechanism, combined with extreme resource optimization of a lightweight HTTP server, achieving an order-of-magnitude reduction in storage usage. For example, by storing web page resources on the server side and dynamically transmitting them in chunks, the Flash usage of the embedded device is reduced from approximately 1MB in traditional solutions to a mere 50KB HTTPD program size, completely eliminating reliance on local storage. This optimization enables small storage devices such as the ESP8266 (512KB Flash) and Cortex-M0 to run web services smoothly, while ElysianWebServer, with its extremely small footprint of ~50KB Flash and ~5KB RAM, further validates its feasibility in resource-constrained scenarios.

[0243] (1) Comparison of storage usage.

[0244] Traditional solution: web page file (3MB) + HTTPD (50KB) = 3.05MB.

[0245] This application: HTTPD (50KB) only = 50KB.

[0246] As can be seen, Flash usage has decreased by approximately 98.4%. (2) Comparison of loading speed (different webpage sizes).

[0247] |Page Size|Traditional Solution (SPIFFS Reading)|This Application (Segmented Loading)| |100KB |0.8 seconds |0.5 seconds| |1MB |4.2 seconds |2.1 seconds| |5MB |Timeout (>30 seconds) |8.3 seconds| II. Optimization of resource utilization and operational efficiency.

[0248] To address the issue of limited CPU and memory resources in embedded devices, this application's embodiments achieve a significant reduction in system overhead through task offloading and lightweight component design. Specifically, complex computational tasks such as page generation and business logic are handled by the server, while the embedded device only needs to process HTTP requests, reducing system overhead by more than 60% compared to the traditional B / S model.

[0249] Technical effectiveness verification data: III. Innovations in updating, maintenance, and expansion.

[0250] Traditional embedded web systems face risks of firmware update downtime and limitations in feature expansion. These issues are fundamentally resolved through a combination of server-side dynamic deployment and declarative web page construction. Technically, web resources can be loaded in chunks via HTTPRange requests, combined with the ALE component's network acquisition mechanism, enabling dynamic updates even without local storage and avoiding business interruptions caused by traditional firmware flashing. Simultaneously, declarative web page construction supports independent upgrades of underlying script libraries; for example, web pages and scripts can be updated separately without interrupting business operations. Furthermore, dynamic feature expansion eliminates the need to recompile firmware, significantly improving system iteration efficiency.

[0251] This application's embodiments form a complete solution through a three-level progressive strategy. The storage layer adopts centralized server-side management to solve capacity limitations (~95% reduction in Flash usage). The runtime layer reduces system overhead through task offloading and lightweight component design (60%+ resource savings). The maintenance layer relies on dynamic deployment and declarative architecture to achieve seamless upgrades. Together, these three elements construct the ability to dynamically deploy web pages in scenarios without local storage, covering all dimensions of technical needs from resource constraints to operational efficiency.

[0252] IV. Network reliability and compatibility assurance.

[0253] To address the issues of data transmission reliability and multi-platform compatibility in scenarios without local storage, this application integrates multiple mechanisms to form a protection system. At the transmission level, ElysianWebServer's exponential backoff retry mechanism and the store-and-forward protocol's 10 retransmissions + ACK confirmation mechanism effectively handle network fluctuations or temporary memory unavailability. In terms of compatibility, users can directly access the server's web application through a browser without installing a client, and publishers do not need to consider platform adaptation or app store approval, achieving a consistent experience across devices. Furthermore, dynamic domain name binding technology solves the problem of remote access failure caused by changes in terminal IP addresses, and combined with a breakpoint resume mechanism (avoiding re-downloading after network interruption), further improves the system's availability in complex network environments.

[0254] V. Performance and resource efficiency optimization.

[0255] Segmented loading and asynchronous processing mechanisms significantly improve page response speed and resource utilization efficiency. Through segmented Ajax response loading technology, the client can process content in real time while receiving the response, reducing overall loading time. This mechanism breaks down web page resources into independent units, achieving a streaming processing mode of receiving and rendering simultaneously, which is particularly suitable for embedded device interaction scenarios in low-bandwidth environments. For large file resource deployment, Promise.all concurrent requests are used to implement segmented downloads, and the mergeArrayBuffer function is used to merge data. Combined with the breakpoint resumption capability supported by HTTPRange requests, this not only overcomes the memory limitations of embedded devices but also reduces bandwidth consumption. For example, video streaming applications can buffer only specific segments instead of the entire file, further optimizing resource transmission efficiency. Asynchronous processing frameworks such as tinyweb, based on the uasyncio event-driven model, can efficiently handle concurrent HTTP requests, outperforming traditional servers in simple scenarios and fundamentally solving the request blocking problem in embedded environments.

[0256] By configuring distributed loading files, embedded devices can flexibly allocate resources according to the storage capacity of different embedded modules. For example, core functional modules can be loaded first for devices with small Flash capacity, while complete interactive interfaces can be deployed for devices with sufficient storage. This on-demand allocation mechanism avoids the loose coupling problem caused by fixed resource allocation, enabling the same set of web page resources to adapt to different specifications of storage hardware, such as 8Mbit to 128Mbit, significantly reducing the threshold for hardware selection.

[0257] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0258] In one embodiment, a dynamic web page deployment system based on the collaborative work of a client, embedded device, and resource server is described in detail. This system constructs dynamic web page deployment capabilities in scenarios without local storage through a three-level progressive strategy.

[0259] In one embodiment, a dynamic web page deployment system is provided, including a client, an embedded device, and a resource server, wherein the embedded device is used for: Receive web resource requests sent by the client; Based on the web page resource request, obtain the corresponding web page resource template from the resource server as needed; The obtained web page resource template is dynamically loaded into the volatile memory of the embedded device; The embedded device's real-time data is retrieved from the volatile memory, and the web page resource template is dynamically synthesized using the real-time data to generate the target web page content. The target webpage content is returned to the client so that the client can perform dynamic rendering; wherein, the webpage resource template is dynamically released using a preset memory management strategy.

[0260] It should be noted that more information about the dynamic deployment system of this webpage can be found in the description of the aforementioned method embodiments. It will not be fully explained here, especially the functions or steps implemented by the embedded device.

[0261] In one embodiment, a web page resource processing apparatus 20 for an embedded device is provided, which corresponds one-to-one with the web page resource processing methods described in the above embodiments. For example... Figure 2 As shown, the web page resource processing device includes a receiving module 201, an acquiring module 202, a loading module 203, a combining module 204, and a sending module 205. Detailed descriptions of each functional module are as follows: The receiving module 201 is used to receive web page resource requests sent by the client; The acquisition module 202 is used to obtain the corresponding web resource template from the resource server as needed based on the web resource request; The loading module 203 is used to dynamically load the acquired web page resource template into the volatile memory of the embedded device; The synthesis module 204 is used to acquire real-time data from the embedded device in RAM and use the real-time data to dynamically synthesize the web page resource template to generate the target web page content. The sending module 205 is used to return the target webpage content to the client so that the client can perform dynamic rendering; wherein, the webpage resource template resides only in RAM in a non-persistent manner and is dynamically released according to the memory management strategy.

[0262] Specific limitations regarding the web resource processing device for embedded devices can be found in the limitations of the web resource processing method for embedded devices described above, and will not be repeated here. Each module in the aforementioned web resource processing method device for embedded devices can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in the embedded device, or stored in software in the memory of the embedded device, so that the processor can call and execute the operations corresponding to each module.

[0263] In one embodiment, an embedded device 30 is provided, including a memory 310, a processor 320, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements a web page resource processing method for an embedded device as described in the above embodiment; to avoid repetition, this will not be repeated here. Alternatively, when the processor executes the computer program, it implements the functions of each module / unit in this embodiment of the device; to avoid repetition, this will not be repeated here.

[0264] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program implements a web page resource processing method for an embedded device as described in the above embodiment. To avoid repetition, this will not be described further here. Alternatively, when executed by a processor, the computer program implements the functions of each module / unit in the web page resource processing apparatus of the embedded device described in this embodiment. To avoid repetition, this will not be described further here.

[0265] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for processing web page resources in an embedded device, characterized in that, For use in embedded devices, the method includes: Receive web resource requests sent by the client; Based on the web page resource request, obtain the corresponding web page resource template from the resource server as needed; The obtained web page resource template is dynamically loaded into the volatile memory of the embedded device; The embedded device's real-time data is retrieved from the volatile memory, and the web page resource template is dynamically synthesized using the real-time data to generate target web page content. The real-time data includes variables characterizing the current physical state or logical parameters of the embedded device. The target webpage content is returned to the client so that the client can perform dynamic rendering; wherein, the webpage resource template is dynamically released using a preset memory management strategy.

2. The method for processing web page resources in an embedded device according to claim 1, characterized in that, The step of obtaining the corresponding webpage resource template from the resource server on demand according to the webpage resource request includes: Retrieve the cache policy memory mapping table; Obtain the cache status identifier carried in the webpage resource request, which indicates the existence status of the client's local cache; When the cache status identifier indicates that the client has a corresponding local cache, a resource metadata verification request is initiated to the resource server based on the negotiated cache priority recorded in the cache policy memory mapping table. The target resource identifier returned by the resource server is compared with the historical resource identifier carried in the web page resource request for consistency. If the comparison results match, a resource not modified status code is returned to the client to instruct the client to call the local cache; If the comparison results are inconsistent, the corresponding web page resource template is obtained from the resource server.

3. The method for processing web page resources in an embedded device according to claim 2, characterized in that, The process of obtaining the cache policy memory mapping table includes: Read the preset caching strategy configuration file; The caching policy configuration file is parsed to extract the mandatory caching rules for different resource types and the negotiated caching priority; The extracted forced caching rules and negotiated caching priorities are used to initialize and configure the memory of the embedded device in order to construct the cache policy memory mapping table.

4. The method for processing web page resources in an embedded device according to claim 3, characterized in that, The preset memory management strategy includes: Real-time monitoring of the embedded device's memory usage; Determine whether the running memory usage rate has reached a preset threshold, and whether the storage duration of the web page resource template in the volatile memory has reached the preset effective duration of the forced caching rule; If the running memory usage rate reaches the preset threshold, or the storage duration reaches the effective duration, then the release condition is determined to be met, and the corresponding web page resource template is deleted from the volatile memory.

5. The method for processing web page resources in an embedded device according to claim 1, characterized in that, The method further includes: In response to the update trigger command, a version verification request is sent to the resource server, and the version metadata of the latest version is obtained; The version metadata is compared with the recorded historical version information, and an update flag is generated when the comparison result is inconsistent; wherein, the historical version information includes the local resource version number pre-stored in the volatile memory of the embedded device, or the client local storage version number carried by the web resource request; Request a list of differing resources from the resource server based on the update flag; For the resources to be updated in the difference resource list, if the size of the resource exceeds a preset threshold, the range request command in the Hypertext Transfer Protocol is used to obtain the resource from the resource server in segments to obtain multiple resource blocks. The obtained resource blocks are then passed through to the client in sequence so that the client can merge the resource blocks into a complete updated resource. If the resource size does not exceed the preset threshold, a full acquisition operation is performed from the resource server to obtain the complete updated resource, and the complete updated resource is then passed through to the client.

6. The method for processing web page resources in an embedded device according to claim 5, characterized in that, The step of comparing the version metadata with the historical version information carried in the webpage resource request includes: Parse the version metadata to extract the last modification time of the current resource and the current file fingerprint; The last modification time and the current file fingerprint are matched with the historical modification time and historical file fingerprint recorded in the historical version information.

7. The method for processing web page resources in an embedded device according to claim 1, characterized in that, When the client first accesses the embedded device, the method further includes: Push an offline caching component registration instruction to the client so that the client registers the offline caching component; The offline caching component is used to obtain core web page resources during the installation phase and store them in the client's cache space. The offline caching component is configured to perform the following operations when subsequent web page resource requests are intercepted: The cache space is queried, and when a corresponding core webpage resource is matched, the core webpage resource stored in the cache space is used to respond to the client; If no matching webpage core resource is found, the webpage resource request is forwarded to the embedded device; The core resources of the webpage include a homepage file, a basic stylesheet, and a manifest file used to define application configuration information.

8. The method for processing web page resources in an embedded device according to claim 7, characterized in that, After pushing the offline caching component registration instruction to the client, the method further includes: Receive conditional verification requests sent by the registered offline caching component after detecting that the core resources of the webpage have expired or that the network has been restored; Based on the conditional verification request, query the resource server for the latest resource identifier of the corresponding resource; If the latest resource identifier does not match the historical resource identifier stored in the offline caching component, the latest resource is obtained from the resource server and passed through to the client so that the offline caching component can update the stored core resources of the webpage. If the latest resource identifier matches the historical resource identifier stored in the offline caching component, a resource unchanged status code is returned to the client to instruct the offline caching component to continue using the stored core webpage resource.

9. The method for processing web page resources in an embedded device according to claim 7, characterized in that, When no matching webpage core resource is found, forwarding the webpage resource request to the embedded device includes: When no matching webpage core resource is found, the network connection status between the client and the embedded device is obtained; If the network connection status is normal, then the operation of forwarding the web page resource request to the embedded device is performed; If the network connection is disconnected, the preset offline degradation resources stored in the cache space are retrieved and sent to the client in response.

10. The webpage resource processing method for an embedded device according to any one of claims 1-9, characterized in that, After returning the target webpage content to the client, the method further includes: Receive control command requests sent by the client, which are generated by the web page script based on user operations; The control command request is parsed by calling the public gateway interface, and the parsed command data is transmitted to the command execution process of the embedded device through a preset call chain. The hardware unit corresponding to the instruction execution process is triggered to perform the operation, and the execution result is fed back to the web page script via the public gateway interface so that the web page script can update the client display interface.

11. An embedded device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the web page resource processing method according to any one of claims 1 to 10.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the web page resource processing method according to any one of claims 1 to 10.

Images