Low-overhead Web runtime optimization system and method for Internet of Things equipment, computer equipment and medium

Abstract

The invention discloses a low-overhead Web runtime optimization method and system for Internet of Things equipment, computer equipment and a medium, the method is adapted to an OpenHarmony operating system, the method comprises the following steps: collecting an equipment state vector of the Internet of Things equipment, and generating an equipment performance portrait of the Internet of Things equipment based on the equipment state vector, the equipment state vector is used for reflecting the real-time resource state of the Internet of Things equipment; switching to a target operation mode based on the equipment performance portrait, and calling target resource configuration based on the target operation mode; and executing the core function component based on the target resource configuration, and performing safety and energy consumption management and control in the execution process. The invention provides a low-overhead Web runtime optimization method for Internet of Things equipment, which can realize organic unification of cross-platform deployment, dynamic performance adaptation and safe energy consumption linkage control, and can be widely applied to the fields of industrial Internet of Things real-time control, medical wearable equipment, smart city infrastructure and the like.

Description

A low-overhead Web runtime optimization system, method, computer device, and medium for Internet of Things (IoT) devices. Technical Field

[0001] This invention relates to the field of IoT device runtime optimization technology, and in particular to a low-overhead Web runtime optimization method, system, computer device, and medium for IoT devices. Background Technology

[0002] With the rapid development of Industry 4.0, mobile healthcare, and smart cities, IoT devices are exhibiting a trend towards heterogeneity, lightweight design, and high reliability. OpenHarmony, as a distributed operating system for all scenarios, has become one of the core operating systems for IoT devices. Currently, Web runtimes (especially cross-platform runtime environments based on WASM) are widely used in IoT device algorithm deployment and function expansion due to their advantages such as strong cross-platform compatibility and small code size. Typical applications include: 1. Industrial automated production lines: deploying equipment status monitoring algorithms through edge controllers to achieve real-time control functions such as weld seam recognition and part defect detection; 2. Portable medical devices: running health data analysis algorithms in devices such as blood glucose meters and electrocardiogram monitors to support long-term monitoring of chronic diseases; 3. Field environmental monitoring systems: collecting meteorological and geological data through sensor networks to achieve early warning of environmental anomalies.

[0003] However, existing Web runtime technologies face several unavoidable core problems when adapting to OpenHarmony IoT devices: low operating efficiency for resource-constrained devices, high complexity of cross-platform deployment, separation of security mechanisms and energy consumption control, and difficulty in balancing performance and energy efficiency. While existing technologies have proposed some improvements to address these core issues, such as cloud-based collaborative compilation optimization schemes and lightweight instruction set reduction schemes, they lack a closed-loop architecture that integrates device state awareness, dynamic adaptation of operating modes, and coordinated security and energy consumption control. This results in an irreconcilable conflict between cross-platform deployment and real-time performance, memory security and low energy consumption, and lightweight design and functional completeness.

[0004] Therefore, existing technologies still need improvement. Summary of the Invention

[0005] To address the aforementioned deficiencies in existing technologies, this invention provides a low-overhead Web runtime optimization method, system, computer device, and medium for IoT devices. The technical solution adopted by this invention is as follows: Firstly, this invention provides a low-overhead Web runtime optimization method for IoT devices, the method being adapted to the OpenHarmony operating system. The method includes: collecting device state vectors of IoT devices; generating a device performance profile of the IoT device based on the device state vectors, wherein the device state vectors reflect the real-time resource status of the IoT device; switching to a target operating mode based on the device performance profile; invoking a target resource configuration based on the target operating mode; and executing core functional components based on the target resource configuration, while performing security and energy consumption management during execution.

[0006] In one implementation, collecting the device state vector of an IoT device includes: collecting the CPU utilization, RAM availability, current power consumption, and device temperature coefficient of the IoT device through a kernel interface; and constructing the device state vector based on the CPU utilization, RAM availability, current power consumption, and device temperature coefficient of the IoT device.

[0007] In one implementation, generating a device performance profile of the IoT device based on the device state vector includes: determining device capability indicators based on the device state vector; constructing a device capability matrix based on the device capability indicators; and generating the device performance profile based on the device capability matrix.

[0008] In one implementation, the device capability indicators include: maximum CPU frequency, available RAM, and energy buffer coefficient, wherein the energy buffer coefficient is the ratio between the remaining battery capacity and the total capacity.

[0009] In one implementation, generating the device performance profile based on the device capability matrix includes: introducing weight vectors corresponding to the maximum CPU frequency, available RAM, and energy buffer coefficient, respectively; calculating a device performance score based on the weight vectors and the device capability matrix; and generating the device performance profile based on the device performance score.

[0010] In one implementation, generating the device performance profile based on the device capability matrix further includes: dynamically increasing the weight ratio of the energy buffer coefficient during the generation of the device performance profile to optimize the adaptability of the device performance profile.

[0011] In one implementation, switching to a target operating mode based on the device performance profile includes: comparing the device performance score corresponding to the device performance profile with a preset benchmark score to obtain a comparison result; and switching to the target operating mode based on the comparison result.

[0012] In one implementation, switching to the target operating mode based on the comparison result includes: if the comparison result is that the device performance score is greater than a preset benchmark score, then the target operating mode is determined to be the standard AOT mode, and the switch is made to the standard AOT mode; if the comparison result is that the device performance score is less than or equal to the preset benchmark score, then the target operating mode is determined to be the ultra-simplified interpreter mode, and the switch is made to the ultra-simplified interpreter mode.

[0013] In one implementation, the benchmark score is the square root of the sum of the squares of the minimum CPU frequency, the minimum available RAM, and the minimum energy buffer coefficient.

[0014] In one implementation, switching to the target operating mode based on the comparison result includes: if the comparison result is the deviation value between the device performance score corresponding to the device performance profile and a preset benchmark score, then comparing the deviation value with a preset deviation threshold; if the deviation value is greater than the deviation threshold, then determining that the target operating mode is the standard AOT mode and switching to the standard AOT mode; if the deviation value is less than or equal to the deviation threshold, then determining that the target operating mode is the ultra-simplified interpreter mode and switching to the ultra-simplified interpreter mode.

[0015] In one implementation, invoking the target resource configuration based on the target operating mode includes: obtaining the identification information corresponding to the target operating mode; and retrieving the corresponding configuration matrix as the target resource configuration based on the identification information, wherein the configuration matrix corresponding to the standard AOT mode includes the cache compilation rate, and the configuration matrix corresponding to the ultra-compact interpreter mode includes the paging compression rate.

[0016] In one implementation, the core functional components are executed based on the target resource configuration, including: if the target running mode is standard AOT mode, then WASM bytecode is pre-compiled into ELF format, and high-frequency deep loop functions are compiled first according to function compilation priority to achieve on-demand loading of function-level flash memory; if the target running mode is ultra-reduced interpreter mode, then floating-point operations are removed, only the core instruction set is retained, and a statically allocated memory page pool is used to optimize the instruction execution cycle.

[0017] In one implementation, security and energy consumption management are performed during execution, including: preventing out-of-bounds access through hard address boundary checks; intercepting system calls from the WASM module, converting them into secure APIs, and achieving secure isolation through a proxy gateway; and injecting power consumption thresholds through a power management module, so that if the energy consumption of a single operation exceeds the limit, the current WASM bytecode is forced to sleep.

[0018] In one implementation, the method further includes: obtaining core data of the core functional components during execution; constructing a comprehensive energy efficiency index based on the core data; substituting the comprehensive energy efficiency index into the strategy optimization vector; and dynamically adjusting the weight vector corresponding to the device capability matrix used to construct the device performance profile through gradient descent.

[0019] In one implementation, the core data includes: execution latency, peak memory usage, and actual power consumption; the comprehensive energy efficiency index is a weighted sum of execution latency, peak memory usage, and actual power consumption.

[0020] Secondly, embodiments of the present invention also provide a low-overhead Web runtime optimization system for IoT devices, wherein the system is adapted to the OpenHarmony operating system, and the system is used to implement the steps of the low-overhead Web runtime optimization method for IoT devices described above. The system includes: a device performance profile generation module, used to collect device state vectors of IoT devices and generate a device performance profile of the IoT devices based on the device state vectors, wherein the device state vectors are used to reflect the real-time resource status of the IoT devices; a running mode switching module, used to switch to a target running mode based on the device performance profile and call a target resource configuration based on the target running mode; and a running and energy consumption management module, used to execute core functional components based on the target resource configuration and perform security and energy consumption management during execution.

[0021] Thirdly, embodiments of the present invention also provide a computer device, wherein the computer device includes a memory, a processor, and an IoT device low-overhead Web runtime optimization program stored in the memory and executable on the processor. When the processor executes the IoT device low-overhead Web runtime optimization program, it implements the steps of the IoT device low-overhead Web runtime optimization method of any of the above-described solutions.

[0022] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a low-overhead Web runtime optimization program for Internet of Things (IoT) devices, and the low-overhead Web runtime optimization program for IoT devices implements the steps of the low-overhead Web runtime optimization method for IoT devices as described in any of the above schemes on the computer-readable storage medium.

[0023] Beneficial Effects: Compared with existing technologies, this invention provides a low-overhead web runtime optimization method for IoT devices. First, this invention collects the device state vector of the IoT device and generates a device performance profile based on the device state vector, whereby the device state vector reflects the real-time resource status of the IoT device. Then, based on the device performance profile, it switches to a target operating mode and invokes target resource configuration based on the target operating mode. Finally, it executes core functional components based on the target resource configuration, and performs security and energy consumption management during execution. This invention can automatically switch operating modes according to the real-time resource status of the device, achieving low memory usage on lightweight devices and low latency on high-performance devices. Furthermore, it constructs a security and energy consumption linkage sandbox, which is beneficial for achieving coordinated control of memory isolation, API security proxy, and energy consumption circuit breaking. Attached Figure Description

[0024] Figure 1 is an application environment diagram of the low-overhead Web runtime optimization method for IoT devices provided in an embodiment of the present invention.

[0025] Figure 2 is a flowchart illustrating a preferred embodiment of the low-overhead Web runtime optimization method for IoT devices provided in this invention.

[0026] Figure 3 is a schematic diagram of the process of generating a device performance profile in the low-overhead Web runtime optimization method for IoT devices provided in an embodiment of the present invention.

[0027] Figure 4 is a schematic diagram of the process of switching to the target running mode in the low-overhead Web runtime optimization method for IoT devices provided in an embodiment of the present invention.

[0028] Figure 5 is a schematic diagram of the process of calling the target resource configuration in the low-overhead Web runtime optimization method for IoT devices provided in an embodiment of the present invention.

[0029] Figure 6 is a schematic diagram of the execution of core functional components in the low-overhead Web runtime optimization method for IoT devices provided in an embodiment of the present invention.

[0030] Figure 7 is a system block diagram of the low-overhead Web runtime optimization system for IoT devices provided in an embodiment of the present invention.

[0031] Figure 8 is a schematic block diagram of the computer device provided in an embodiment of the present invention. Detailed Implementation

[0032] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0033] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content, operations, or steps, nor does it require execution in the described order. For example, some operations or steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0034] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise. It should be understood that, for the purpose of clearly describing the technical solutions of the embodiments of the invention, the terms "first," "second," etc., are used in the embodiments of the invention to distinguish identical or similar items that have substantially the same function and effect. For example, first control information and second control information are only used to distinguish different control information and do not limit their order. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply that they are different. It should also be understood that the term "and / or" used in this specification and the appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0035] Existing Web runtime technologies face the following unavoidable core problems when adapting to OpenHarmony IoT devices: (1) Low operating efficiency of resource-constrained devices: Existing Web runtimes adopt a fixed architecture design, supporting only pre-compiled (AOT) or interpreter single mode, and cannot adapt to devices with different resource specifications. For OpenHarmony L0 level lightweight devices with RAM≤64KB, the traditional runtime suffers from increased computational efficiency and frequent memory overflows due to the fixed memory allocation mechanism and redundant instruction set. For example, a certain electrocardiogram analysis algorithm requires 136KB of RAM in the traditional interpreter mode, which cannot run on 64KB level devices, directly limiting the functional expansion of lightweight medical wearable devices.

[0036] (2) High complexity of cross-platform deployment: IoT devices have strong hardware heterogeneity (such as different architecture chips such as ESP32, RP2040, nRF5340, etc.). Existing technologies require compiling binary firmware separately for each device, which leads to an exponential increase in the complexity of the deployment process. For example, in a smart city manhole cover sensor network (containing 10,000+ nodes and covering more than 3 chip architectures), the traditional solution requires 3 independent adaptation compilations, which increases the deployment time. Furthermore, subsequent OTA upgrades require pushing exclusive firmware for different devices, resulting in extremely high operation and maintenance costs.

[0037] (3) Separation of security mechanism and energy consumption control: The existing Web runtime security sandbox only implements basic memory isolation function and is not linked with device energy consumption control, which leads to two types of risks: First, malicious WASM modules can damage the OpenHarmony kernel through infinite loops, illegal memory access and other means, causing the device to go out of control; Second, in high load scenarios (such as industrial high vibration environment, high temperature production line), the runtime will run at high power consumption, which will shorten the standby time of the device, or even trigger the device failure due to overheating.

[0038] (4) Difficulty in balancing performance and energy efficiency: In existing solutions, although the Ahead-of-Time (AOT) mode can improve execution speed, it has high memory consumption (requires ≥192KB RAM) and cannot run on lightweight devices; although the interpreter mode has lower memory consumption, it has high execution latency (e.g., weld seam recognition latency reaches 29ms in industrial scenarios), which cannot meet the real-time control requirements. For example, the energy consumption of WAMR running the CRC16 algorithm on the ESP32 device is 3.11mJ, which is 31 times the energy consumption of native execution (0.1mJ), which seriously restricts the battery life of battery-powered devices.

[0039] To address the problems of the aforementioned traditional technologies, two improvement schemes have been proposed in the industry, but both have significant limitations, as follows: (1) Cloud-based collaborative compilation optimization scheme: This scheme provides customized AOT compilation services for edge devices through cloud servers, attempting to solve the cross-platform adaptation problem. However, its core drawback is that the device needs to maintain a continuous 5G network connection, which completely fails in network-free scenarios such as mines and the wild or in industrial firewall isolation environments; at the same time, cloud compilation requires the transmission of device hardware information, which poses a risk of data leakage and adds extra hardware communication costs, which does not meet the low-cost requirements of IoT devices.

[0040] (2) Lightweight instruction set pruning scheme: This scheme reduces memory usage by removing some instruction sets (such as floating-point arithmetic instructions) from the interpreter, but does not consider dynamic changes in device resources. Under extreme conditions such as high vibration and high temperature, the lack of dynamic adaptation capability leads to a surge in instruction execution error rate and a reduction in the algorithm's compatibility range, making it unable to support complex data analysis functions (such as multi-sensor data fusion).

[0041] The fundamental flaw in existing technologies lies in the lack of a closed-loop architecture encompassing device status awareness, dynamic adaptation to operating modes, and coordinated control of safety and energy consumption. This leads to an irreconcilable conflict between three major contradictions: cross-platform deployment and real-time performance, memory security and low energy consumption, and lightweight design and functional completeness. These deficiencies have already caused serious consequences in critical scenarios such as the Industrial Internet of Things (IIoT) and medical devices. For example, in industrial settings, high-temperature production line environments (e.g., >45℃) increase real-time control latency fluctuations, leading to higher misjudgment rates in industrial quality inspections. In medical settings, shortened device standby time affects continuous monitoring of patients with chronic diseases and increases the risk of power outages in emergency rescue scenarios. In smart city scenarios, most sensors cannot be networked due to compatibility issues, limiting the coverage of infrastructure monitoring networks.

[0042] Therefore, there is an urgent need for a low-overhead web runtime optimization method adapted to the OpenHarmony operating system for IoT devices, achieving a unified approach to cross-platform deployment, dynamic performance adaptation, and integrated security and energy consumption control. In specific applications, this embodiment first collects the device state vector of the IoT device, and generates a device performance profile based on the device state vector, where the device state vector reflects the real-time resource status of the IoT device. Then, based on the device performance profile, it switches to a target operating mode and calls the target resource configuration based on the target operating mode. Finally, it executes core functional components based on the target resource configuration, and performs security and energy consumption management during execution. This embodiment can automatically switch operating modes according to the real-time resource status of the device, achieving low memory usage on lightweight devices and low latency on high-performance devices. Furthermore, it constructs a security and energy consumption linkage sandbox, which facilitates the coordinated control of memory isolation, API security proxy, and energy consumption circuit breaking.

[0043] The low-overhead web runtime optimization method for IoT devices in this embodiment can be applied to the application environment shown in Figure 1. Terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated on server 104, or it can be located in the cloud or on another network server. The low-overhead web runtime optimization method for IoT devices can be executed by terminal 102 or server 104, or it can be executed collaboratively by terminal 102 and server 104.

[0044] The terminal 102 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, IoT device, or portable wearable device. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices, etc.

[0045] Server 104 can be an independent physical server, a cloud server, or a service node in a blockchain system, where the service nodes in the blockchain system form a peer-to-peer network.

[0046] In addition, server 104 can also be a server cluster consisting of multiple physical servers, which can be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0047] Terminal 102 and server 104 can be connected via Bluetooth, USB (Universal Serial Bus) or network, etc., and this application does not impose any restrictions.

[0048] In some embodiments, as shown in FIG2, a low-overhead Web runtime optimization method for IoT devices is provided. This method can be applied to a terminal, which can be an intelligent product terminal such as a computer. Specifically, the method includes the following steps: Step S100: Collect the device state vector of the IoT device, and generate a device performance profile of the IoT device based on the device state vector, wherein the device state vector is used to reflect the real-time resource status of the IoT device.

[0049] In this embodiment, the CPU utilization, RAM availability, current power consumption, and device temperature coefficient of the IoT device can be collected through OpenHarmony kernel interfaces (such as / proc / stat, sysfs, etc.). Then, based on the CPU utilization, RAM availability, current power consumption, and device temperature coefficient of the IoT device, a device state vector is constructed. Specifically, the device state vector is represented as follows: Among them, the device state vector ,in, CPU utilization; RAM availability; Current device power consumption (mW); Equipment temperature coefficient. In practical applications, this embodiment can dynamically determine the equipment resource shortage status by monitoring cedar trees based on the above-mentioned equipment state vector.

[0050] The monitoring function in this embodiment:

[0051] Where α, β, and γ are weighting coefficients, and the weighting coefficients must satisfy the following conditions: , This represents the resource stress threshold. In practical applications, when the monitoring function outputs 1, it can be determined that the current IoT device is in a resource stress state, thus preparing for the subsequent switching between dual operating modes. This embodiment comprehensively depicts the real-time resource status of IoT devices through device state vectors. Compared to traditional polling mechanisms, the weighted monitoring function can reduce invalid state detection and lower energy waste; simultaneously, the standardized state parameters provide a basis for unified decision-making across devices.

[0052] Furthermore, after obtaining the above-mentioned device state vector, this embodiment can generate a device performance profile of the Internet of Things device, as shown in Figure 3. The generation of the device performance profile includes the following steps: Step S101: Determine the device capability index based on the device state vector; Step S102: Construct a device capability matrix based on the device capability index; Step S103: Generate the device performance profile based on the device capability matrix.

[0053] Specifically, this embodiment can be derived from the device state vector. In this study, three types of equipment capability indicators are extracted as the basis for equipment performance profiling: Maximum CPU frequency (MHz): This is the highest operating frequency of the device's CPU read through the OpenHarmony kernel interface, and can be used to reflect the computing power of IoT devices. Available RAM (KB): Real-time reading of the current available memory capacity of IoT devices, which can be used to reflect the memory resource status of IoT devices; Energy buffer coefficient, which is the ratio between the remaining battery capacity and the total capacity, reflects the battery life of IoT devices.

[0054] In addition, for energy-sensitive devices such as ESP32 and nRF5340, energy consumption stability verification can be added during the indicator extraction process: if the power consumption fluctuation of the device is ≥20% for 5 consecutive sampling periods, then... The weight is dynamically increased to prioritize ensuring battery life.

[0055] Furthermore, after obtaining the above three types of equipment capability indicators, this embodiment constructs a 3×3 equipment capability matrix P, with the following matrix form:

[0056] In this model, the row vectors correspond to the computing power dimension, memory capacity dimension, and energy efficiency dimension, respectively. The third column of the column vector represents the actual indicator value, while the first two columns are placeholders used for subsequent weighted projection calculations. Next, this embodiment introduces the weights for the maximum CPU frequency, available RAM, and energy buffer coefficient, respectively. , as well as Then, construct the corresponding weight vector. Next, assign values ​​to the weight vector, i.e. At this time, the maximum CPU frequency The weight is 0.4, reflecting the impact of computing power on the operating mode; available RAM The weight is 0.4, highlighting the constraints of memory resources on runtime; energy buffer coefficient. The weight is 0.2 to balance energy efficiency requirements. This embodiment can calculate the equipment performance score based on the weight vector and the equipment capability matrix. This embodiment can calculate the equipment performance score based on a weighted Euclidean distance method, i.e.:

[0057] in, =0.4, =0.4, =0.2. Next, based on the device performance score, the device performance profile is generated. The device performance profile in this embodiment includes: device type label, resource level, and recommended operating mode. This recommended operating mode provides a basis for subsequent switching between dual operating modes. Furthermore, during the generation of the device performance profile, this embodiment can dynamically increase the weighting of the energy buffer coefficient to optimize the adaptability of the device performance profile.

[0058] Step S200: Based on the device performance profile, switch to the target operating mode and call the target resource configuration based on the target operating mode.

[0059] In this embodiment, the engine can be selected through dual-mode operation, and the device performance score corresponding to the device performance profile can be used. Compared with the preset benchmark score Based on the comparison results, the system dynamically switches to the target operating mode and calls the corresponding target resource configuration from the resource adaptation strategy library. The benchmark score in this embodiment is the square root of the sum of the squares of the minimum CPU frequency, minimum available RAM, and minimum energy buffer coefficient.

[0060] The decision function of the dual-mode runtime selection engine in this embodiment is: .

[0061] In practical applications, as shown in Figure 4, when switching to the target operating mode in this embodiment, the following steps are included: Step S201: Compare the device performance score corresponding to the device performance profile with the preset benchmark score to obtain the comparison result; Step S202: Based on the comparison result, switch to the target operating mode.

[0062] In practical applications, if the comparison result is the device performance score... Greater than the preset benchmark score If the comparison result shows that the device performance score is less than or equal to a preset benchmark score, then the target operating mode is determined to be the standard AOT mode, and the system switches to the standard AOT mode. The standard AOT mode (Ahead-of-Time Compilation, pre-compiled mode) in this embodiment is one of the two core operating modes of the lightweight WASM module in this technical solution. It is specifically designed for medium-to-high performance OpenHarmony devices with >192KB of available RAM and strong CPU performance. Its core objective is to achieve high-performance, low-latency operation of WASM bytecode through pre-compilation and on-demand loading, while deeply integrating OpenHarmony system security and resource scheduling capabilities. If the comparison result shows that the device performance score is less than or equal to a preset benchmark score, then the target operating mode is determined to be the ultra-reduced interpreter mode, and the system switches to the ultra-reduced interpreter mode. Both the standard AOT mode and the ultra-reduced interpreter mode ensure that resource-constrained devices can always run the WASM module.

[0063] In another implementation, if the comparison result is the deviation between the device performance score corresponding to the device performance profile and a preset benchmark score, then the deviation value is compared with a preset deviation threshold. If the deviation value is greater than the deviation threshold, the target operating mode is determined to be the standard AOT mode, and the system switches to the standard AOT mode. If the deviation value is less than or equal to the deviation threshold, the target operating mode is determined to be the ultra-simplified interpreter mode, and the system switches to the ultra-simplified interpreter mode.

[0064] Furthermore, the resource adaptation strategy library pre-stores configuration matrices for two types of operating modes. During dual-mode runtime, the selection engine retrieves the corresponding configuration matrix as the target resource configuration based on the identifier information of the target operating mode. In practical applications, as shown in Figure 5, the process includes the following steps: Step S21: Obtain the identifier information corresponding to the target operating mode; Step S22: Based on the identifier information, retrieve the corresponding configuration matrix as the target resource configuration. The configuration matrix for the standard AOT mode includes the cache compilation rate, and the configuration matrix for the ultra-compact interpreter mode includes the paging compression rate.

[0065] The configuration matrix corresponding to the standard AOT mode in this embodiment is as follows: The configuration matrix corresponding to the ultra-compact interpreter mode: ,in, For pagination compression ratio, This refers to the compilation cache rate.

[0066] The core configurations of the standard AOT mode configuration matrix include: enabling the WASM→ELF pre-compilation pipeline to support function-level parallel compilation; retaining the OpenHarmony secure boot chain verification function to ensure the integrity of compiled instructions; and the compilation cache rate. This means caching the most recent 5% of frequently compiled results to balance cache usage and compilation speed. The core configurations of the ultra-compact interpreter mode configuration matrix include: disabling floating-point operations (OPCODE) and retaining only core instruction sets such as integer and logical operations; enabling a 4KB static memory page pool and employing stack-based memory compression technology to achieve high page compression rates. The instruction decoding mode is configured as "4-byte instruction bundle decoding" to reduce CPU decoding overhead.

[0067] Step S300: Execute core functional components based on the target resource configuration, and perform security and energy consumption control during the execution process.

[0068] The core functional component of this embodiment is the lightweight WASM execution unit. The lightweight WASM execution unit is the core functional component of this invention, executing WASM bytecode in either ultra-reduced interpreter mode or standard AOT mode, depending on the target resource configuration. During execution, as shown in Figure 6, the following steps are included: Step S301: If the target running mode is standard AOT mode, the WASM bytecode is pre-compiled into ELF format, and high-frequency deep loop functions are compiled first according to function compilation priority to achieve on-demand loading of function-level flash memory; Step S302: If the target running mode is ultra-reduced interpreter mode, floating-point operations are removed, only the core instruction set is retained, and a statically allocated memory page pool is used to optimize the instruction execution cycle.

[0069] In practical applications, the standard AOT mode is designed for OpenHarmony devices with RAM > 192KB and strong CPU performance. The core optimization goal is "high speed and low latency". The execution process is as follows: 1. Pre-compilation conversion: After loading the configuration matrix CAOT, the WASM bytecode is pre-compiled into the ELF format that is natively executable by the OpenHarmony device. During the pre-compilation process, instruction rearrangement and register allocation optimization are completed to reduce runtime overhead.

[0070] 2. Function compilation priority sorting: according to the priority formula: Sort the functions in the WASM module, where: : Function call depth (the deeper the call level, the higher the priority, such as the recursive function δ(f)=3); : Number of function loops (the more frequent the loop, the higher the priority, such as the loop detection function ω(f)=1000 in real-time control); : Function body size (the smaller the function size, the higher the priority, such as utility function τ(f) = 16 bytes).

[0071] 3. Function-level Flash Loading on Demand: Employing a "page-aligned" mechanism (dividing function modules into 4KB pages), only functions required by the current execution flow are loaded. Uncalled functions are temporarily stored in flash memory, not occupying RAM. For example, in a weld seam recognition module in industrial control, initialization functions are loaded only when the equipment starts up, and core recognition functions are loaded during real-time detection, significantly reducing flash memory usage. Example: Running the weld seam recognition WASM algorithm in an automotive production line edge controller (ARM Cortex-M7 chip, RAM=256KB), the standard AOT mode significantly reduces execution latency and significantly improves cache hit rate for loop execution.

[0072] The ultra-compact interpreter mode is designed specifically for OpenHarmony devices with RAM ≤ 64KB and low CPU frequency. Its core optimization goals are low memory footprint and low power consumption. The execution flow is as follows: 1. Instruction set pruning: After loading the configuration matrix Cmin, floating-point operation OPCODEs and exception handling instruction sets are automatically removed, retaining only 32 core instructions (such as MOV, ADD, AND, etc.), reducing the instruction set size by 68%; 2. Memory allocation: A 4KB memory page pool is statically allocated, following the principle of "stack priority, heap minimization." The page pool is divided into "instruction area (2KB), data area (1.5KB), and temporary cache area (0.5KB)" to avoid memory fragmentation; 3. Instruction decoding and execution: A 4-byte instruction bundle decoding technology is used to package and decode consecutive 4-byte WASM instructions, saving 75% of decoding time compared to traditional byte-by-byte parsing. The instruction execution cycle is based on... Optimization, among which Let be the number of bytes in the i-th instruction. It uses RISC-V instruction cycles (compatible with mainstream OpenHarmony chip architectures). Example: Running the ECG analysis WASM module in a blood glucose meter (RAM=64KB, OpenHarmony L0 level), the ultra-simplified interpreter mode significantly reduces memory usage and power consumption per analysis.

[0073] Furthermore, this embodiment also implements security and energy consumption management during execution. This embodiment employs a security verification sandbox technology, which provides end-to-end control over the operation of the WASM execution unit, achieving triple protection of memory security, API security, and energy consumption security, including: memory isolation protection, system API security proxy, and energy consumption circuit breaker control. Specifically, hard address boundary checks prevent out-of-bounds access; then, system calls from the WASM module are intercepted, converted into secure APIs, and securely isolated through a proxy gateway. Finally, a power consumption threshold is injected through the power management module; if the energy consumption of a single operation exceeds the limit, the current WASM bytecode is forced to sleep.

[0074] Specifically, in performing memory isolation protection, this embodiment prevents the WASM module from accessing memory beyond its bounds through hard address boundary checks. The core constraint is: ,in : is the WASM memory base address. : Allocate size for the page. When a WASM command attempts to access... When the address is outside the specified range, the sandbox immediately triggers a memory exception interrupt, terminates the execution of the current instruction, and records the exception information through the OpenHarmony system log. The log can be encrypted using the SHA-256 algorithm to prevent tampering.

[0075] When performing system API security proxying, this embodiment constructs an API proxy gateway to intercept all system calls from the WASM module and convert them into OpenHarmony secure APIs. The specific process is as follows: 1. The WASM module initiates a system call (such as file read / write, network communication); 2. The proxy gateway intercepts the call request and parses the call intent and parameters; 3. The call request is mapped to the corresponding OpenHarmony secure API (e.g., file read / write is converted to ohos.file.security_read, network communication is converted to ohos.net.hichain_send); 4. The OpenHarmonyTEE (Trusted Execution Environment) is called to complete identity verification (e.g., hichain certificate verification). After successful verification, the API operation is executed, and the result is returned to the WASM module.

[0076] This mechanism prevents the WASM module from directly accessing the system's underlying interfaces, thus preventing malicious code from damaging the OpenHarmony kernel through system calls.

[0077] In this embodiment, when performing energy consumption circuit breaker control, a power consumption threshold Ψ = 10mJ (maximum energy consumption for a single operation) is injected through the OHOS power management module. The energy consumption circuit breaker condition is as follows: Where t0: operation start time; Δt: operation duration; P(t): real-time power consumption (mW). This indicates the maximum energy consumption for a single operation. When the energy consumption of the WASM module exceeds 10mJ (or continuous current > 10mA) in a single operation, the sandbox forces the current WASM bytecode to hibernate, and resumes execution after the device power consumption drops to a safe threshold (< 5mA). For example, in a smart city manhole cover sensor network, if malicious mining code attempts to occupy the CPU for continuous operation, the energy consumption circuit breaker mechanism can terminate its execution in a short time to prevent the battery from running out.

[0078] Furthermore, to improve adaptability across different scenarios, this invention constructs a performance feedback closed loop. Specifically, this embodiment can also acquire core data of core functional components during execution. A comprehensive energy efficiency index is constructed based on this core data, and this index is substituted into the strategy optimization vector. Gradient descent is then used to dynamically adjust the weight vector corresponding to the device capability matrix used to construct the device performance profile. The core data in this embodiment includes: execution latency, peak memory usage, and actual power consumption; the comprehensive energy efficiency index is a weighted sum of execution latency, peak memory usage, and actual power consumption.

[0079] Specifically, the comprehensive energy efficiency index is expressed as: α, β, and γ are energy efficiency weighting coefficients (default α=0.3, β=0.4, γ=0.3), reflecting the priority requirements for latency, memory, and energy consumption in different scenarios. Furthermore, this embodiment also constructs a strategy optimization vector, specifically represented as follows:

[0080] in, The execution delay represents the total time from the start of execution of the WASM instruction to the return of the result; Peak memory usage represents the maximum RAM capacity used during execution. This represents the actual power consumption, indicating the total energy consumption of a single operation. This represents the learning rate, used to control the step size for weight adjustment. This represents the momentum factor, which maintains strategy stability and avoids high-frequency oscillation switching. This is the weight vector before adjustment. Then, the comprehensive energy efficiency index is substituted into the strategy optimization vector, and the weight vector corresponding to the device capability matrix used to construct the device performance profile is dynamically adjusted through gradient descent. For example, in industrial high-temperature scenarios (t>45℃), if the comprehensive energy efficiency index E remains high (due to increased power consumption caused by excessive temperature), the feedback loop will dynamically increase the energy buffer coefficient. Weighting, reducing maximum CPU frequency The weight of these factors should be prioritized to ensure device battery life and stability.

[0081] Compared with the prior art, the present invention has the following significant advantages: (1) The cross-platform adaptability is greatly improved: Through the standardization of device performance profiles and the dual-mode runtime design, the same WASM bytecode can run on heterogeneous OpenHarmony devices such as ESP32, RP2040, and nRF5340 without modification. Cross-platform deployment does not require repeated compilation, reducing deployment costs by 57% and improving OTA upgrade efficiency. For example, the deployment time of a smart city manhole cover sensor network (10,000+ nodes) is greatly shortened.

[0082] (2) Significantly optimized operating efficiency of resource-constrained devices: The ultra-simplified interpreter mode reduces the memory usage and energy consumption of the WASM module on L0 level devices with RAM≤64KB through instruction set pruning, 4KB memory compression, and other technologies, thus solving the problem that lightweight devices cannot run complex algorithms.

[0083] (3) Breakthrough in real-time performance of medium and high-performance equipment: The standard AOT mode reduces the execution latency of the WASM module by 79% (29ms→6ms) through pre-compilation, function-level on-demand loading and hotspot optimization, and improves the cache hit rate, meeting the high-performance requirements of industrial real-time control, edge computing and other applications. For example, the misjudgment rate of weld seam recognition in automobile production lines has been greatly reduced.

[0084] (4) Coordinated control of security and energy consumption: The security verification sandbox achieves triple protection of memory isolation, API proxy and energy consumption circuit breaking, which significantly reduces the success rate of malicious code attacks and extends the battery life of devices. For example, the average number of times medical wearable devices are charged per day has been reduced from 3 to 1, and the battery life of field environmental monitoring devices has been extended from 7 days to 21 days.

[0085] (5) Strong scenario adaptability and outstanding scalability: The closed-loop architecture of this invention can dynamically optimize the weight vector through performance feedback closed loop, adapting to extreme scenarios such as high temperature, high vibration, and no network in the field. At the same time, it can be used to develop extended solutions such as cell micro short circuit detection network for new energy vehicle battery management system (BMS) and mine environment monitoring system, covering multiple fields such as intelligent manufacturing, mobile medical care, and smart cities.

[0086] Based on the above embodiments, the present invention also provides a low-overhead Web runtime optimization system for IoT devices. This system is adapted to the OpenHarmony operating system and is used to implement the steps in the above method embodiments. Specifically, as shown in FIG7, the system of this embodiment includes: a device performance profile generation module 10, a running mode switching module 20, and a running and energy consumption management module 30. Specifically, the device performance profile generation module 10 is used to collect device state vectors of IoT devices and generate a device performance profile of the IoT devices based on the device state vectors, wherein the device state vectors are used to reflect the real-time resource status of the IoT devices. The running mode switching module 20 is used to switch to a target running mode based on the device performance profile and call a target resource configuration based on the target running mode. The running and energy consumption management module 30 is used to execute core functional components based on the target resource configuration and perform security and energy consumption management during execution.

[0087] In one implementation, the device performance profile generation module 10 includes: a data acquisition unit, used to acquire the CPU utilization, RAM availability, current device power consumption, and device temperature coefficient of the IoT device through a kernel interface; and a device state vector construction unit, used to construct the device state vector based on the CPU utilization, RAM availability, current device power consumption, and device temperature coefficient of the IoT device.

[0088] In one implementation, the device performance profile generation module 10 further includes: a device capability index determination unit, used to determine device capability indexes based on the device state vector; a device capability matrix construction unit, used to construct a device capability matrix based on the device capability indexes; and a device performance profile generation unit, used to generate the device performance profile based on the device capability matrix.

[0089] In one implementation, the device capability indicators include: maximum CPU frequency, available RAM, and energy buffer coefficient, wherein the energy buffer coefficient is the ratio between the remaining battery capacity and the total capacity.

[0090] In one implementation, the device performance profile generation unit includes: a weight vector introduction subunit, used to introduce weight vectors corresponding to the maximum CPU frequency, available RAM, and energy buffer coefficient respectively; a device performance score calculation subunit, used to calculate a device performance score based on the weight vectors and the device capability matrix; and a performance profile generation subunit, used to generate the device performance profile based on the device performance score.

[0091] In one implementation, the device performance profile generation unit further includes a performance profile optimization subunit, which dynamically increases the weight ratio of the energy buffer coefficient during the generation of the device performance profile to optimize the adaptability of the device performance profile.

[0092] In one implementation, the operating mode switching module includes: a comparison unit, used to compare the device performance score corresponding to the device performance profile with a preset benchmark score to obtain a comparison result; and a switching unit, used to switch to the target operating mode based on the comparison result.

[0093] In one implementation, the switching unit includes: a standard AOT mode switching unit, configured to determine the target operating mode as standard AOT mode and switch to standard AOT mode if the comparison result is that the device performance score is greater than a preset benchmark score; and an ultra-simplified interpreter mode switching unit, configured to determine the target operating mode as ultra-simplified interpreter mode and switch to ultra-simplified interpreter mode if the comparison result is that the device performance score is less than or equal to a preset benchmark score.

[0094] In one implementation, the benchmark score is the square root of the sum of the squares of the minimum CPU frequency, the minimum available RAM, and the minimum energy buffer coefficient.

[0095] In one implementation, the switching unit further includes: a deviation comparison unit, configured to compare the deviation value with a preset deviation threshold if the comparison result is a deviation value between the device performance score corresponding to the device performance profile and a preset benchmark score; a standard AOT mode switching subunit, configured to determine the target operating mode as standard AOT mode and switch to standard AOT mode if the deviation value is greater than the deviation threshold; and an ultra-simplified interpreter mode switching subunit, configured to determine the target operating mode as ultra-simplified interpreter mode and switch to ultra-simplified interpreter mode if the deviation value is less than or equal to the deviation threshold.

[0096] In one implementation, the running mode switching module further includes: an identification information acquisition unit, used to acquire identification information corresponding to the target running mode; and a target resource configuration retrieval unit, used to retrieve the corresponding configuration matrix as the target resource configuration based on the identification information, wherein the configuration matrix corresponding to the standard AOT mode includes the cache compilation rate, and the configuration matrix corresponding to the ultra-compact interpreter mode includes the paging compression rate.

[0097] In one implementation, the operation and energy management module includes: a standard AOT mode operation unit, used to pre-compile WASM bytecode into ELF format and prioritize the compilation of high-frequency deep loop functions according to function compilation priority, so as to realize on-demand loading of function-level flash memory if the target operation mode is standard AOT mode; and an ultra-reduced interpreter mode operation unit, used to remove floating-point operations, retain only the core instruction set, and optimize the instruction execution cycle by using statically allocated memory page pools if the target operation mode is ultra-reduced interpreter mode.

[0098] In one implementation, the operation and energy consumption management module further includes: a memory isolation protection unit, used to prevent out-of-bounds access through hard address boundary checks; a system API security proxy unit, used to intercept system calls of the WASM module, convert them into secure APIs, and achieve security isolation through a proxy gateway; and an energy consumption circuit breaker control unit, used to inject power consumption thresholds through the power management module, and if the energy consumption of a single operation exceeds the upper limit, the current WASM bytecode will be forced to sleep.

[0099] In one implementation, the system further includes: a core data acquisition unit, used to acquire core data of core functional components during execution; and an energy consumption optimization unit, used to construct a comprehensive energy efficiency index based on the core data, substitute the comprehensive energy efficiency index into the strategy optimization vector, and dynamically adjust the weight vector corresponding to the device capability matrix used to construct the device performance profile through gradient descent.

[0100] In one implementation, the core data includes: execution latency, peak memory usage, and actual power consumption; the comprehensive energy efficiency index is a weighted sum of execution latency, peak memory usage, and actual power consumption.

[0101] In some embodiments, a computer device is provided, which may be a terminal, and its internal structure diagram may be as shown in Figure 8. The computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are connected to the system bus via the input / output interface. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface of the computer device is used for exchanging information between the processor and external devices. The communication interface of the computer device is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a low-overhead web runtime optimization method for Internet of Things (IoT) devices. The display unit of the computer device is used to form a visually visible image. It can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0102] Those skilled in the art will understand that the structure shown in Figure 8 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or may combine certain components, or may have different component arrangements.

[0103] In some embodiments, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following steps: acquiring a device state vector of an Internet of Things (IoT) device; generating a device performance profile of the IoT device based on the device state vector, wherein the device state vector is used to reflect the real-time resource status of the IoT device; switching to a target operating mode based on the device performance profile; invoking a target resource configuration based on the target operating mode; and executing core functional components based on the target resource configuration, while performing security and energy consumption management during execution.

[0104] In one implementation, collecting the device state vector of an IoT device includes: collecting the CPU utilization, RAM availability, current power consumption, and device temperature coefficient of the IoT device through a kernel interface; and constructing the device state vector based on the CPU utilization, RAM availability, current power consumption, and device temperature coefficient of the IoT device.

[0105] In one implementation, generating a device performance profile of the IoT device based on the device state vector includes: determining device capability indicators based on the device state vector; constructing a device capability matrix based on the device capability indicators; and generating the device performance profile based on the device capability matrix.

[0106] In one implementation, the device capability indicators include: maximum CPU frequency, available RAM, and energy buffer coefficient, wherein the energy buffer coefficient is the ratio between the remaining battery capacity and the total capacity.

[0107] In one implementation, generating the device performance profile based on the device capability matrix includes: introducing weight vectors corresponding to the maximum CPU frequency, available RAM, and energy buffer coefficient, respectively; calculating a device performance score based on the weight vectors and the device capability matrix; and generating the device performance profile based on the device performance score.

[0108] In one implementation, generating the device performance profile based on the device capability matrix further includes: dynamically increasing the weight ratio of the energy buffer coefficient during the generation of the device performance profile to optimize the adaptability of the device performance profile.

[0109] In one implementation, switching to a target operating mode based on the device performance profile includes: comparing the device performance score corresponding to the device performance profile with a preset benchmark score to obtain a comparison result; and switching to the target operating mode based on the comparison result.

[0110] In one implementation, switching to the target operating mode based on the comparison result includes: if the comparison result is that the device performance score is greater than a preset benchmark score, then the target operating mode is determined to be the standard AOT mode, and the switch is made to the standard AOT mode; if the comparison result is that the device performance score is less than or equal to the preset benchmark score, then the target operating mode is determined to be the ultra-simplified interpreter mode, and the switch is made to the ultra-simplified interpreter mode.

[0111] In one implementation, the benchmark score is the square root of the sum of the squares of the minimum CPU frequency, the minimum available RAM, and the minimum energy buffer coefficient.

[0112] In one implementation, switching to the target operating mode based on the comparison result includes: if the comparison result is the deviation value between the device performance score corresponding to the device performance profile and a preset benchmark score, then comparing the deviation value with a preset deviation threshold; if the deviation value is greater than the deviation threshold, then determining that the target operating mode is the standard AOT mode and switching to the standard AOT mode; if the deviation value is less than or equal to the deviation threshold, then determining that the target operating mode is the ultra-simplified interpreter mode and switching to the ultra-simplified interpreter mode.

[0113] In one implementation, invoking the target resource configuration based on the target operating mode includes: obtaining the identification information corresponding to the target operating mode; and retrieving the corresponding configuration matrix as the target resource configuration based on the identification information, wherein the configuration matrix corresponding to the standard AOT mode includes the cache compilation rate, and the configuration matrix corresponding to the ultra-compact interpreter mode includes the paging compression rate.

[0114] In one implementation, the core functional components are executed based on the target resource configuration, including: if the target running mode is standard AOT mode, then WASM bytecode is pre-compiled into ELF format, and high-frequency deep loop functions are compiled first according to function compilation priority to achieve on-demand loading of function-level flash memory; if the target running mode is ultra-reduced interpreter mode, then floating-point operations are removed, only the core instruction set is retained, and a statically allocated memory page pool is used to optimize the instruction execution cycle.

[0115] In one implementation, security and energy consumption management are performed during execution, including: preventing out-of-bounds access through hard address boundary checks; intercepting system calls from the WASM module, converting them into secure APIs, and achieving secure isolation through a proxy gateway; and injecting power consumption thresholds through a power management module, so that if the energy consumption of a single operation exceeds the limit, the current WASM bytecode is forced to sleep.

[0116] In one implementation, the method further includes: obtaining core data of the core functional components during execution; constructing a comprehensive energy efficiency index based on the core data; substituting the comprehensive energy efficiency index into the strategy optimization vector; and dynamically adjusting the weight vector corresponding to the device capability matrix used to construct the device performance profile through gradient descent.

[0117] In one implementation, the core data includes: execution latency, peak memory usage, and actual power consumption; the comprehensive energy efficiency index is a weighted sum of execution latency, peak memory usage, and actual power consumption.

[0118] It should be noted that the user information (including but not limited to user device function information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0119] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0120] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0121] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

[0122] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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; and these 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 the present invention.

Claims

1. A low-overhead Web runtime optimization method for Internet of Things (IoT) devices, characterized in that, The method is adapted to the OpenHarmony operating system and includes: collecting device state vectors of IoT devices; generating a device performance profile of the IoT devices based on the device state vectors, wherein the device state vectors are used to reflect the real-time resource status of the IoT devices; switching to a target operating mode based on the device performance profile; calling a target resource configuration based on the target operating mode; executing core functional components based on the target resource configuration, and performing security and energy consumption management during the execution process.

2. The low-overhead Web runtime optimization method for IoT devices according to claim 1, characterized in that, Collecting the device state vector of IoT devices includes: collecting the CPU utilization, RAM availability, current power consumption, and device temperature coefficient of the IoT devices through the kernel interface; and constructing the device state vector based on the CPU utilization, RAM availability, current power consumption, and device temperature coefficient of the IoT devices.

3. The low-overhead Web runtime optimization method for IoT devices according to claim 2, characterized in that, Generating a device performance profile of the IoT device based on the device state vector includes: determining device capability indicators based on the device state vector; constructing a device capability matrix based on the device capability indicators; and generating the device performance profile based on the device capability matrix.

4. The low-overhead Web runtime optimization method for IoT devices according to claim 3, characterized in that, The device capability indicators include: maximum CPU frequency, available RAM, and energy buffer coefficient, where the energy buffer coefficient is the ratio between the remaining battery capacity and the total capacity.

5. The low-overhead Web runtime optimization method for IoT devices according to claim 4, characterized in that, Based on the device capability matrix, the device performance profile is generated, including: introducing weight vectors corresponding to the maximum CPU frequency, available RAM, and energy buffer coefficient respectively; calculating the device performance score based on the weight vectors and the device capability matrix; and generating the device performance profile based on the device performance score.

6. The low-overhead Web runtime optimization method for IoT devices according to claim 5, characterized in that, The process of generating the device performance profile based on the device capability matrix also includes: dynamically increasing the weight of the energy buffer coefficient during the generation of the device performance profile to optimize the adaptability of the device performance profile.

7. The low-overhead Web runtime optimization method for IoT devices according to claim 6, characterized in that, Based on the device performance profile, switching to the target operating mode includes: comparing the device performance score corresponding to the device performance profile with a preset benchmark score to obtain a comparison result; and based on the comparison result, switching to the target operating mode.

8. The low-overhead Web runtime optimization method for IoT devices according to claim 7, characterized in that, Based on the comparison results, switching to the target operating mode includes: if the comparison result is that the device performance score is greater than a preset benchmark score, then the target operating mode is determined to be the standard AOT mode, and the switch is made to the standard AOT mode; if the comparison result is that the device performance score is less than or equal to the preset benchmark score, then the target operating mode is determined to be the ultra-simplified interpreter mode, and the switch is made to the ultra-simplified interpreter mode.

9. The low-overhead Web runtime optimization method for IoT devices according to claim 8, characterized in that, The benchmark score is the square root of the sum of the squares of the minimum CPU frequency, the minimum available RAM, and the minimum energy buffer coefficient.

10. The low-overhead Web runtime optimization method for IoT devices according to claim 7, characterized in that, Based on the comparison result, switching to the target operating mode includes: if the comparison result is the deviation value between the device performance score corresponding to the device performance profile and the preset benchmark score, then comparing the deviation value with the preset deviation threshold; if the deviation value is greater than the deviation threshold, then determining that the target operating mode is the standard AOT mode and switching to the standard AOT mode; if the deviation value is less than or equal to the deviation threshold, then determining that the target operating mode is the ultra-simplified interpreter mode and switching to the ultra-simplified interpreter mode.

11. The low-overhead Web runtime optimization method for IoT devices according to claim 8 or 10, characterized in that, The method of calling the target resource configuration based on the target operating mode includes: obtaining the identification information corresponding to the target operating mode; and retrieving the corresponding configuration matrix as the target resource configuration based on the identification information, wherein the configuration matrix corresponding to the standard AOT mode includes the cache compilation rate, and the configuration matrix corresponding to the ultra-compact interpreter mode includes the paging compression rate.

12. The low-overhead Web runtime optimization method for IoT devices according to claim 11, characterized in that, Based on the target resource configuration, the core functional components are executed, including: if the target running mode is standard AOT mode, the WASM bytecode is pre-compiled into ELF format, and high-frequency deep loop functions are compiled first according to function compilation priority to achieve on-demand loading of function-level flash memory; if the target running mode is ultra-reduced interpreter mode, floating-point operations are removed, only the core instruction set is retained, and a statically allocated memory page pool is used to optimize the instruction execution cycle.

13. The low-overhead Web runtime optimization method for IoT devices according to claim 12, characterized in that, Security and energy consumption management are implemented during execution, including: preventing out-of-bounds access through hard address boundary checks; intercepting system calls from the WASM module, converting them into secure APIs, and achieving secure isolation through a proxy gateway; and injecting power consumption thresholds through the power management module, so that if the energy consumption of a single operation exceeds the limit, the current WASM bytecode is forced to sleep.

14. The low-overhead Web runtime optimization method for IoT devices according to claim 13, characterized in that, The method further includes: acquiring core data of core functional components during execution; constructing a comprehensive energy efficiency index based on the core data; substituting the comprehensive energy efficiency index into the strategy optimization vector; and dynamically adjusting the weight vector corresponding to the device capability matrix used to construct the device performance profile through gradient descent.

15. The low-overhead Web runtime optimization method for IoT devices according to claim 14, characterized in that, The core data includes: execution latency, peak memory usage, and actual power consumption; the comprehensive energy efficiency index is a weighted sum of execution latency, peak memory usage, and actual power consumption.

16. A low-overhead Web runtime optimization system for Internet of Things (IoT) devices, characterized in that, The system is adapted to the OpenHarmony operating system and is used to implement the steps of the low-overhead Web runtime optimization method for IoT devices according to any one of claims 1-15. The system includes: a device performance profile generation module, used to collect device state vectors of IoT devices and generate a device performance profile of the IoT devices based on the device state vectors, wherein the device state vectors are used to reflect the real-time resource status of the IoT devices; a running mode switching module, used to switch to a target running mode based on the device performance profile and call a target resource configuration based on the target running mode; and a running and energy consumption management module, used to execute core functional components based on the target resource configuration and perform security and energy consumption management during execution.

17. A computer device, characterized in that, The computer device includes a memory, a processor, and an IoT device low-overhead web runtime optimization program stored in the memory and executable on the processor. When the processor executes the IoT device low-overhead web runtime optimization program, it implements the steps of the IoT device low-overhead web runtime optimization method as described in any one of claims 11-16.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an IoT device low-overhead web runtime optimization program, which implements the steps of the IoT device low-overhead web runtime optimization method as described in any one of claims 11-16 on the computer-readable storage medium.

Images