Front-end task execution method, electronic equipment and vehicle

Abstract

The invention provides a front-end task execution method, electronic equipment and a vehicle, and relates to the technical field of front-end development, and the method comprises the steps: responding to a received target task request sent by a user through a front-end page of a client, and obtaining the operation environment information of the target task request; according to the running environment information, a function calling path corresponding to the target task request is determined from multiple function calling paths according to pre-constructed calling logic, a corresponding function is called from a pre-constructed mixed function interface according to the function calling path to execute the target task request, and an execution result is obtained, and displaying the execution result in a front-end page. According to the method and the device, the function calling path can be dynamically and flexibly distributed for the target task request, the execution efficiency of the target task request is improved, and smooth and non-pause front-end page service is provided for a user.

Description

Technical Field

[0001] This application relates to the field of front-end development technology, and in particular to a front-end task execution method, electronic device, and vehicle. Background Technology

[0002] As web applications become increasingly complex, the computational tasks undertaken by the front end have increased significantly, such as image / video processing, data encryption and decryption, physics simulation, machine learning inference, and large table rendering. Traditionally, these tasks rely on the scripting language JavaScript. However, as an interpreted dynamic language, JavaScript suffers from performance bottlenecks in CPU-intensive scenarios, resulting in low efficiency in executing computational tasks. Summary of the Invention

[0003] In view of this, the purpose of this application is to propose a front-end task execution method, electronic device and vehicle to solve the problem of low efficiency in executing computing tasks through JavaScript in CPU-intensive scenarios.

[0004] To achieve the above objectives, the first aspect of this application provides a front-end task execution method, comprising: In response to receiving a target task request sent by a user through the client's front-end page, obtain the runtime environment information of the target task request; Based on the runtime environment information, the function call path corresponding to the target task request is determined from a plurality of pre-built function call paths according to the pre-built call logic; wherein, the plurality of function call paths include the path corresponding to the first function and the path corresponding to the second function, and the first function is obtained by rewriting and compiling based on the business logic of the second function; The target task request is executed by calling the corresponding function from the pre-generated hybrid function interface according to the function call path, and the execution result is obtained. The execution results are displayed on the front-end page.

[0005] Optionally, the runtime environment information includes client performance information, network status information, target task request priority, and call cache information of the first function; The step of determining the function call path corresponding to the target task request from a pre-built set of function call paths according to the runtime environment information and pre-built call logic includes: Determine whether the first function has been cached in the front-end page based on the call cache information of the first function; Since the first function has been cached in the front-end page, the path corresponding to the first function is used as the function call path; In response to the first function not being cached in the front-end page, the target call path is used as the function call path based on the client performance information, the network status information, and / or the target task request priority; wherein, the target call path is the path corresponding to the first function or the path corresponding to the second function.

[0006] Optionally, the step of using the target call path as the function call path based on the client performance information, the network status information, and / or the target task request priority includes: In response to the target task request priority being preset to high priority, the path corresponding to the second function is used as the function call path; In response to the fact that the priority of the target task request is not a preset high priority, the first function is loaded, and the target call path is determined based on the loading time of the first function; In response to the target task request priority being preset to low priority, the client performance information including low-performance clients and the network status information including weak network status, the path corresponding to the second function is used as the function call path.

[0007] Optionally, determining the target call path based on the loading time of the first function includes: In response to the fact that the loading time of the first function exceeds a preset time threshold, the path corresponding to the second function is determined as the function call path; In response to the fact that the loading time of the first function does not exceed a preset time threshold, the path corresponding to the first function is determined as the function call path.

[0008] Optionally, after responding to the target task request priority being preset to high priority and using the path corresponding to the second function as the function call path, the method further includes: preloading the first function.

[0009] Optionally, the method for generating the hybrid function interface includes: Identify the target second function in the front-end code; Create a source code file based on the business logic of the target second function; The source code file is compiled to obtain the first function; The calling logic is constructed, and based on the calling logic, the first function and the second function are encapsulated using an encapsulation tool to generate the hybrid function interface.

[0010] Optionally, the target task request is executed by calling the corresponding function according to the function call path to obtain the execution result, including: In response to the function call path being the path corresponding to the first function, the first function is called to process the data in the pre-built shared memory region to obtain the execution result; wherein, the data in the shared memory region is pre-written by the second function.

[0011] Optionally, after executing the target task request by calling the corresponding function according to the function call path, the method further includes: In response to the fact that the function call path is the path corresponding to the first function, and the execution of the target task request by calling the corresponding function according to the path corresponding to the first function fails, the function call path is adjusted to the path corresponding to the second function; The target task request is executed by calling the corresponding function according to the path corresponding to the second function, and the execution result is obtained.

[0012] Based on the same inventive concept, a second aspect of this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor implements the method described above when executing the computer program.

[0013] Based on the same inventive concept, a third aspect of this application also provides a vehicle including electronic equipment as described in the second aspect.

[0014] As can be seen from the above, this application provides a front-end task execution method, electronic device, and vehicle. The method includes: in response to receiving a target task request sent by a user through a front-end page of a client, obtaining runtime environment information of the target task request. Based on the runtime environment information, determining the function call path corresponding to the target task request from a pre-built set of multiple function call paths according to pre-built call logic. The multiple function call paths include a path corresponding to a first function and a path corresponding to a second function, where the first function is rewritten and compiled based on the business logic of the second function. The multiple function call paths are pre-built, and each function call path can execute the target task request, but at different execution speeds. The first function has higher execution efficiency, while the second function has lower execution efficiency. By using runtime environment information, the actual response speed requirements of the target request task and the device network environment can be determined. Then, based on the pre-built call logic, a suitable function call path can be allocated to the target task request to maximize the execution efficiency of the target task request. Compared to the prior art, which directly determines a unique function call path based on the target task request, this application can dynamically and flexibly allocate function call paths for the target task request, improving the execution efficiency of the target task request. The target task request is executed by calling the corresponding function from the pre-built hybrid function interface according to the function call path, and the execution result is displayed on the front-end page. Because the execution efficiency of the target task request is improved, the speed at which the execution result is displayed on the front-end page is also improved, providing users with a smooth, lag-free front-end page service. Attached Figure Description

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

[0016] Figure 1 This is a flowchart illustrating the front-end task execution method according to an embodiment of this application; Figure 2 This is a schematic diagram of the front-end task execution device according to an embodiment of this application; Figure 3 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0017] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0018] As described in the background section, traditional methods primarily rely on JavaScript (JS) for front-end interaction. JavaScript is an interpreted / just-in-time (JIT) compiled dynamically typed scripting language specifically designed for front-end web pages and is also the default scripting language for browsers. However, with the increasing complexity of Web (World Wide Web) applications, the computational tasks undertaken by the front end have significantly increased, such as image / video processing, data encryption and decryption, physics simulation, machine learning inference, and rendering of large tables. As an interpreted dynamic language, JavaScript exhibits performance bottlenecks in CPU (Central Processing Unit) intensive scenarios. These bottlenecks are mainly manifested in the following ways: JavaScript lacks fixed data types (e.g., it doesn't require pre-declaration of whether a variable is a number or a string) and cannot directly manipulate memory. Even with JIT compilation optimizations, it's difficult to achieve optimal performance, resulting in slow speeds during complex calculations. JavaScript automatically cleans up unused memory (garbage collection), but this process is uncontrollable and can be triggered suddenly. If a large amount of useless memory is encountered during cleanup, it can block page rendering, causing UI (User Interface) lag (e.g., buttons become unresponsive, and the page doesn't scroll). JavaScript is inherently single-threaded (it can only do one thing at a time). Although Web Workers can create "background threads" to share tasks, the core main thread (responsible for UI rendering and user interaction) is still easily blocked by complex calculations, causing the page to freeze. Furthermore, different browsers have different JavaScript engine optimization strategies, resulting in significant differences in the speed and stability of the same computational task across different browsers.

[0019] To address the aforementioned issues, the existing solution employs a "full migration" strategy, rewriting the entire front-end module as WebAssembly (WASM). This involves rewriting the entire JavaScript module in languages ​​like C / C++ / Rust and then compiling it into WASM. WASM is a lightweight, portable binary instruction format natively supported by all major browsers. WASM cannot be written directly by hand; it must be compiled from languages ​​like C / C++ / Rust. WASM boasts near-native code execution speed and extremely high efficiency. Its strongly typed system allows for greater optimization during compilation. Memory management is developer-controlled, eliminating unpredictable garbage collection and preventing sudden stutters. It is portable, small in size, and loads quickly, exhibiting consistent performance across different browsers, but it cannot directly manipulate the DOM (Document Object Model) and requires a JavaScript intermediary. Compiling the entire module into WASM means front-end developers need to master compiled languages ​​supported by WASM and modify the logic of existing JavaScript code, leading to higher development costs. Furthermore, because WASM is a binary format, it is more difficult to troubleshoot issues compared to JavaScript text code. WASM was designed for fast computational tasks and cannot directly manipulate page elements (such as modifying button text or rendering tables). It must be handled through JavaScript. A full migration would increase the interaction cost between JavaScript and WASM. Furthermore, once a full migration is implemented, the cost of subsequent modifications and iterations will also increase. Therefore, a full migration is not suitable.

[0020] In view of this, this application proposes a front-end task execution method that does not require recompiling all JS code into WASM. Instead, it selects only the functions required for time-consuming computational tasks from the JS code and compiles them into WASM form, while the remaining functions retain their JS code form. This way, when processing time-consuming computational tasks, calling WASM-form functions can improve the computational efficiency. Furthermore, the method of this application can dynamically select the function call path based on the runtime environment of the task request to meet the actual execution efficiency requirements of the task request. This not only improves the execution speed of task requests but also reduces development and maintenance costs.

[0021] In in-vehicle applications, the client can be an in-vehicle infotainment system or an in-vehicle central control system. In-vehicle scenarios require high performance, strong compatibility, and high stability. The front-end task execution method provided in this application dynamically determines the function call path based on the runtime environment information, taking into account the device performance of the client and the network status of the vehicle under different vehicle models, maximizing the execution efficiency of the target task request, and meeting the high performance and strong compatibility requirements of the in-vehicle side. The binary file size of the JS function is smaller than that of the WASM function, making it suitable for scenarios with relatively limited in-vehicle hardware resources and reducing the occupation of in-vehicle resources. The JS function and the WASM function share linear memory, reducing the memory occupation of the in-vehicle device and alleviating the memory pressure on the in-vehicle device. After a JS function call fails, an exception fallback mechanism can be triggered, continuing the execution of the target task request by calling the WASM function, ensuring uninterrupted execution of the target task request, achieving a seamless front-end service experience for the user, and meeting the high stability requirements of the in-vehicle side.

[0022] The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0023] This application proposes a front-end task execution method, applied to the client side, see reference. Figure 1 This includes the following steps: Step 102: In response to receiving a target task request sent by the user through the client's front-end page, obtain the runtime environment information of the target task request.

[0024] Specifically, in this embodiment, the client can be a computer, laptop, mobile device (such as a mobile phone, tablet, etc.), in-vehicle computer, etc. The front-end page is the human-computer interaction interface of the client, such as a page opened in the client's browser or application. The user can trigger a target task request through the front-end page. The target task request can be a task request such as adding a filter to an uploaded image or processing image pixels. The target task request is a task request that requires calling a performance bottleneck function in the front-end code. The performance bottleneck function is a function related to loop-intensive operations, mathematical operations, and large data processing, and its runtime is relatively long. For example, the user opens the front-end page in the browser. After the page loads, the user clicks the "Image Blur" button, thus triggering the target task request. The current target task request is to blur the uploaded image.

[0025] Once the client confirms receipt of the target task request from the user, it obtains the runtime environment information for the target task request. This runtime environment information includes the client's performance, network status, and priority of the target task request. Client performance is determined by the number of CPU cores, memory size, memory pressure, and the JavaScript execution benchmark score. For example, if the number of CPU cores is less than 4, the client is considered a low-performance device; if the number of CPU cores is 4 or greater, the client is considered a high-performance device. Memory size refers to the maximum JavaScript heap memory allocated by the browser / engine to the JavaScript engine; it is the static memory limit threshold. If the memory size is less than 1GB, the client is considered a low-end device; if the memory size is greater than 4GB, the client is considered a high-end device. Memory pressure refers to the degree of memory resource consumption on the client during the execution of the computation task, and whether this consumption exceeds the client's memory capacity, leading to issues such as lag and crashes. Memory pressure can be assessed by obtaining the total physical memory of the client. If the returned total physical memory is less than 4GB, the client is considered a low-memory device; if the returned total physical memory is between 4GB and 7GB, the client is considered a medium-memory device. When the returned total physical memory of the client is greater than 7GB, the client is determined to be a high-memory device. The JS execution benchmark score is a quantitative indicator measuring the execution efficiency of the client's JS engine, used to evaluate the performance level of the client running JS code. The JS execution benchmark score can be obtained through third-party benchmark libraries or custom simple test cases. When the JS execution benchmark score is below 40, the client is determined to be a low-end device; when the JS execution benchmark score is above 80, the client is determined to be a high-end device. The number of CPU cores, memory size, memory pressure, and JS execution benchmark score of the client determine the client's performance, i.e., whether the client is a low-end, mid-range, or high-end device. The network status is determined by the network type and download bandwidth. For example, when the network type is 2G, the network status is determined to be a weak network status. When the network type is 5G / Wi-Fi, the network status is determined to be a strong network status. When the download bandwidth is less than 1.5Mbps, the network status is determined to be a weak network status; otherwise, it is a strong network status.

[0026] The priority of a target task request is predetermined based on its immediate response requirements. For example, a target task requesting the addition of a blur filter to an image has a high priority. A target task requesting the generation of thumbnails in the background has a low priority. A target task requesting the export of a PDF document has a medium priority. By comprehensively evaluating the execution efficiency requirements of the target task request and the response rate that the client can provide, runtime environment information can be used to assign an appropriate and matching function call path to the target task request.

[0027] Step 104: Based on the runtime environment information, determine the function call path corresponding to the target task request from multiple pre-built function call paths according to the pre-built call logic; wherein, the multiple function call paths include the path corresponding to the first function and the path corresponding to the second function, and the first function is rewritten and compiled based on the business logic of the second function.

[0028] Specifically, each function call path in the multiple function call paths is pre-built, and the function corresponding to each function call path can execute the target task request, but their execution efficiency varies. The pre-built call logic is a rule used to determine the function call path corresponding to the target task request based on the runtime environment information. This call logic can be used to assign a matching function call path to the target task request.

[0029] Multiple function call paths include the call path corresponding to the first function and the call path corresponding to the second function. The second function refers to the complete code logic written in JavaScript that can complete the target request task. The first function refers to the complete binary file written in WASM that can complete the target request task. The first function is obtained by rewriting and compiling based on the business logic of the second function. Compared to the second function, the first function executes the target task request faster. Based on runtime environment information and call logic, it can be determined whether the function call path corresponding to the target task request is the call path corresponding to the first function or the call path corresponding to the second function. Dynamically selecting the optimal function call path under the current circumstances, combined with runtime environment information, balances client performance and robustness.

[0030] Step 106: Call the corresponding function from the pre-generated hybrid function interface according to the function call path to execute the target task request and obtain the execution result.

[0031] Specifically, after determining the function call path, the corresponding function is called from the pre-generated hybrid function interface to execute the target task request. The hybrid function interface is a front-end proxy function that packages the call logic, the first function, and the second function into a unified interface using a wrapper tool. It serves as the scheduling entry point for the first and second functions.

[0032] Furthermore, the method for generating the hybrid function interface includes: Identify the target second function in the front-end code; Create a source code file based on the business logic of the target second function; The source code file is compiled to obtain the first function; The calling logic is constructed, and based on the calling logic, the first function and the second function are encapsulated using an encapsulation tool to generate the hybrid function interface.

[0033] Specifically, in this embodiment, the target second function is a performance bottleneck function in the front-end code, such as functions with intensive loops, numerous mathematical operations, or large-scale data processing, which have a long runtime. Performance bottleneck functions can be located using the Performance API (Application Programming Interface) or the Lighthouse tool. After locating the bottleneck function using this tool, if the function's runtime exceeds a threshold (e.g., 16ms), then that function is identified as a performance bottleneck.

[0034] A source code file is created based on the business logic of the target second function in the front-end code. This source code file is written in a native code language, such as C, C++, or Rust. The business logic of the second function is rewritten using this native code language, including the input parameter format (e.g., pointer + length), the core algorithm, and the final return data. This forms the source code file. The source code file is then compiled into the first function using a compiler. For example, the wasm-pack command is used to call the compiler, which compiles the source code file into a binary form of the first function (a WASM function). This embodiment replaces only the performance bottleneck function with a WASM function, avoiding the "full migration" required in existing technologies and significantly reducing development costs.

[0035] After compilation, in addition to generating the first function of the WASM language in binary form, JS glue code is also generated. The JS glue code acts as a bridge connecting the JS environment and the WASM module. At runtime, the first function needs to go through the process of "downloading the binary file → parsing the bytecode → instantiating the environment" before it can be used. The JS glue code automatically encapsulates this process, implementing the loading and instantiation of the WASM module. WASM only supports a limited number of basic data types (such as integers, floating-point numbers, pointers, etc.) and does not support complex JS types (such as arrays, objects, strings, etc.). The JS glue code is responsible for handling the type mapping and conversion between the two, allowing parameters to be seamlessly connected. WASM memory needs to be manually allocated / released; the glue code automatically encapsulates the memory management details to avoid memory leaks. The glue code also encapsulates the WASM module into a camelCase interface that conforms to JS development habits, shielding the underlying WASM call details, allowing the business layer to call WASM function functionality just like calling JS functions.

[0036] The invocation logic is constructed by determining the function call path corresponding to the target task request based on runtime environment information. Runtime environment information includes client performance information, network status information, target task request priority, and the call cache information of the first function. Different runtime environment information determines the corresponding function call path matching the target task request. Combining the target task request under all runtime environment information and the determined function call paths yields the invocation logic. For example, the invocation logic may include: if the call cache information of the first function is not cached, and the target task request priority is high, the function call path is determined to be the path corresponding to the second function. If execution failure or error occurs after calling the function according to the path corresponding to the first function to execute the target task request, the function call path is adjusted to the path corresponding to the second function, and the function is called again to execute the target task request. The purpose of constructing the invocation logic is to allocate the function call path with the highest execution efficiency for the target task request for each type of runtime environment information.

[0037] Based on the calling logic, a wrapper tool is used to encapsulate the first and second functions, ensuring their function signatures are consistent to guarantee uniform parameter and return value types. The first and second functions are then integrated to generate a hybrid function, exposing a unified business interface (i.e., the hybrid function interface), thus completing the encapsulation. Subsequent business layer calls only require replacing the original frontend code function path corresponding to the target task request with the hybrid function path. When calling the hybrid function path, the client's scheduling engine further determines whether to use the first or second function path within the hybrid function based on the calling logic.

[0038] In this embodiment, the first function is compiled, enabling high-performance computing for the front-end page. For computationally intensive tasks, it significantly reduces execution time, meeting the real-time requirements of scenarios such as automotive applications and solving the problem of low computational efficiency in existing technologies. The binary size of the WASM module is much smaller than that of JS code with equivalent execution functionality, resulting in lower memory consumption and better adaptation to resource-constrained clients. By encapsulating the hybrid function, front-end developers do not need to understand the underlying algorithm details and can independently integrate the hybrid function interface, improving development efficiency. The target second function is rewritten and compiled into the first function. During function calls, the WASM function is implemented as an acceleration function, while the JS function remains the main function, reducing later maintenance costs. Compared to existing technologies that rewrite and compile all second functions into the first function, this embodiment only rewrites and compiles the target second function into the first function, significantly reducing development costs.

[0039] The target task request is executed by calling the corresponding function from the hybrid function interface according to the function call path. That is, the calculation process of the target task request is realized by running the function, and the execution result is obtained. For example, the execution result can be the blurred image information returned after performing an image blurring operation.

[0040] Step 108: Display the execution result on the front-end page.

[0041] Specifically, after obtaining the execution result, it can be displayed on the front-end page using tools such as image rendering. For example, using canvas as the image rendering carrier, the pixel data returned after execution (the execution result) is written into the canvas's pixel buffer, and finally rendered as a visual image displayed on the page. Here, Canvas is a container object in the Unity engine used to hold UI components.

[0042] Based on steps 102 to 108 above, this embodiment provides a front-end task execution method, including: in response to receiving a target task request sent by a user through a front-end page of a client, obtaining runtime environment information of the target task request. According to the runtime environment information, determining the function call path corresponding to the target task request from a pre-built set of multiple function call paths according to pre-built call logic, wherein the multiple function call paths include a path corresponding to a first function and a path corresponding to a second function, where the first function is rewritten and compiled based on the business logic of the second function. The multiple function call paths are pre-built, and each function call path can execute the target task request, but at different execution speeds. The first function has higher execution efficiency, while the second function has lower execution efficiency. By using the runtime environment information, the actual response speed requirements of the target request task and the device network environment can be determined. Then, according to the pre-built call logic, a suitable function call path can be allocated to the target task request to maximize the execution efficiency of the target task request. Compared to the prior art, which directly determines a unique function call path based on the target task request, this application can dynamically and flexibly allocate function call paths for the target task request, improving the execution efficiency of the target task request. The target task request is executed by calling the corresponding function from the pre-built hybrid function interface according to the function call path, and the execution result is displayed on the front-end page. Because the execution efficiency of the target task request is improved, the speed at which the execution result is displayed on the front-end page is also improved, providing users with a smooth, lag-free front-end page service.

[0043] In some embodiments, the runtime environment information includes client performance information, network status information, target task request priority, and call cache information of the first function; The step of determining the function call path corresponding to the target task request from a pre-built set of function call paths according to the runtime environment information and pre-built call logic includes: Based on the call caching information of the first function, determine whether the first function has been cached in the front-end page; in response to the first function being cached in the front-end page, use the path corresponding to the first function as the function call path; in response to the first function not being cached in the front-end page, use the target call path as the function call path based on the client performance information, the network status information, and / or the target task request priority; wherein, the target call path is the path corresponding to the first function or the path corresponding to the second function.

[0044] Specifically, the call cache information for the first function includes cached and uncached entries. If the first function has already been loaded, its call cache information is cached; if it hasn't been loaded, its call cache information is uncached. After the first function is loaded, its loading status can be cached, recording whether the loading was successful. This cached data can then be used to determine whether the first function is cached.

[0045] If the first function is cached in the front-end page, and due to its high execution speed, its path is directly used as the function call path upon receiving the target task request, ensuring efficient execution of the target task request. If the first function is not cached in the front-end page, the function call path needs to be determined based on client performance information, network status information, and / or the target task request priority. In this case, the function call path could be either the path corresponding to the first function or the path corresponding to the second function. Determining the function call path requires considering not only the target task request priority but also the client device's performance capabilities and the current network status. The more suitable function call path for the current situation is selected from the paths corresponding to the first and second functions.

[0046] This embodiment implements a scheme to dynamically determine the function call path based on runtime environment information. When the first function has already been loaded, the path corresponding to the first function is preferentially used, which can significantly improve the execution efficiency of the target task request, thereby increasing the client's response speed and providing users with better front-end page services. When the first function has not been loaded, the function call path is dynamically selected to maximize the execution efficiency of the target task request.

[0047] In some embodiments, the step of using the target call path as the function call path based on the client performance information, the network status information, and / or the target task request priority includes: In response to the target task request priority being preset to high priority, the path corresponding to the second function is used as the function call path; In response to the fact that the priority of the target task request is not a preset high priority, the first function is loaded, and the target call path is determined based on the loading time of the first function; In response to the target task request priority being preset to low priority, the client performance information including low-performance clients and the network status information including weak network status, the path corresponding to the second function is used as the function call path.

[0048] Specifically, if the first function is not cached on the front-end page, and the target task request priority is preset high priority, it indicates that the execution efficiency requirement of the target task request is high, and the front-end page needs to provide a fast response to the user. If the first function is loaded for the first time in this case, it will prolong the execution time of the target task request. Therefore, the path corresponding to the second function is directly used as the function call path, that is, the second function (JS function) is directly called to execute the target task request. For example, the preset high priority target task request could be a user interaction response request, such as a user's click or drag operation on the front-end page. Directly calling the second function can avoid the user waiting for the loading process of the first function, ensuring the execution speed of the target task request. If the target task request priority is not preset high priority, it indicates that the execution efficiency requirement of the target task request is not high, and the user can wait for a certain period of time, with less need for immediate feedback. In this case, the first function can be loaded. If loading is successful, the first function will be used to execute the target task request; if loading fails, the second function will be used to execute the target task request. For example, the target task request with a priority that is not preset high priority could be a background data processing task or a pre-computation task.

[0049] Furthermore, determining the target call path based on the loading time of the first function includes: In response to the fact that the loading time of the first function exceeds a preset time threshold, the path corresponding to the second function is determined as the function call path; In response to the fact that the loading time of the first function does not exceed a preset time threshold, the path corresponding to the first function is determined as the function call path.

[0050] Specifically, if the loading time of the first function exceeds a preset time threshold, it indicates that the first function has timed out or failed to load. In this case, the path corresponding to the second function is used as the function call path, and the target task request is executed by calling the second function. For example, the preset time threshold can be 2 seconds. If the loading time of the first function does not exceed the preset time threshold, it means that the first function has loaded successfully and has not exceeded the threshold. Since the execution efficiency of the first function is higher than that of the second function, the path corresponding to the first function is used as the function call path. The target task request is executed by calling the first function. Dynamically adjusting the function call path based on the loading time of the first function ensures that the function that executes fastest for the target task in the current scenario is always selected, thereby maximizing the execution efficiency of the target task request.

[0051] Furthermore, if the target task request priority is a preset low priority, the client performance information includes low-performance clients, and the network status information includes a weak network state, the path corresponding to the second function is used as the function call path. A preset low priority for the target task request indicates that the execution efficiency requirement of the target task request is low, and the user does not need to provide immediate feedback on the execution result on the front-end page. The client performance information including low-performance clients and the network status information including a weak network state indicates that neither the current client nor the network state can support high-performance computing tasks. Therefore, the loading process of the first function is skipped directly, saving network bandwidth and client memory, avoiding lag due to insufficient resources on low-performance clients, and maximizing execution efficiency under low-performance client and weak network conditions.

[0052] The following examples illustrate how to filter function call paths: 1. When a user clicks the "High-Definition Filter" function button on the front-end page to add a high-definition filter to an image, this is a high-priority task. The client is a high-performance device with a 5G network. At this time, the corresponding function call path is the path of the second function, while the first function is loaded.

[0053] 2. The user triggers a task request to generate thumbnails in the backend on the front-end page. This task request is a low-priority task, the client is a low-performance device, and the network type is 2G. At this time, the corresponding function call path is the path of the second function, and the first function is not loaded.

[0054] 3. The user triggers a task request to export a PDF document on the front-end page. This task request is a medium-priority task, the client is a high-performance device, and the network type is WiFi. At this time, the corresponding function call path is the path of the first function. If the first function has not been loaded, the first function will be loaded. After the first function is loaded within the preset time threshold, the first function will be called through the path of the first function.

[0055] 4. When a user visits the image processing page for the first time on the front-end page, the task request has a medium priority, the client's performance is a mid-range device, and the network type is 4G. To quickly respond to the user's initial visit, the function call path is determined to be the path corresponding to the second function, and the first function is loaded simultaneously so that it can be directly called via the path corresponding to the first function on subsequent visits.

[0056] Additionally, if the client's battery is too low after the user triggers the target task request, the path corresponding to the second function can be used as the function call path to conserve battery power and reduce client power consumption. If the client supports SIMD (Single Instruction Multiple Data) instruction set, the path corresponding to the first function can be used as the function call path. SIMD is a hardware-level parallel computing technology; if the client supports SIMD, calling WASM functions can achieve a higher task processing rate.

[0057] This embodiment balances client compatibility with the high-performance requirements of target task requests. It dynamically selects function call paths based on runtime environment information, providing the most suitable function call path for each target task request. For high-performance clients and high-priority target task requests, the function call path is determined with the goal of rapid response, improving the response speed of the front-end page. For low-priority target task requests and low-performance clients, the method flexibly selects matching function execution paths with the goal of maximizing execution efficiency, optimizing client resource utilization efficiency and reducing client load.

[0058] In some embodiments, after the path corresponding to the second function is used as the function call path in response to the target task request priority being preset to high priority, the method further includes: preloading the first function.

[0059] Specifically, when the first function is not loaded, to ensure the response rate of high-priority target task requests, the path corresponding to the second function is used as the function call path. This ensures the smooth execution of target task requests and avoids delays caused by waiting for the first function to load. Simultaneously, the first function is preloaded so that when a user sends the same target task request again, the first function can be directly called through its corresponding path, accelerating the execution efficiency of the target task request.

[0060] Furthermore, when a user triggers the same target task request a second time, since the first function had already begun loading after the first trigger, the user can attempt to call the first function via its path. If the first function is not fully loaded, a short wait can be made, and it can be called immediately once loaded. Subsequently, when the same target task request is triggered again, the first function can be continuously called via its corresponding path. This preloading method in this embodiment improves the execution efficiency of the target task request when the same request is triggered, making the task execution smoother and providing a better front-end service experience for the user.

[0061] In some embodiments, the target task request is executed by calling the corresponding function according to the function call path to obtain the execution result, including: In response to the function call path being the path corresponding to the first function, the first function is called to process the data in the pre-built shared memory region to obtain the execution result; wherein, the data in the shared memory region is pre-written by the second function.

[0062] Specifically, the performance bottleneck function in the front-end code is rewritten and compiled into a first function (WASM function), while other functions retain the form of a second function (JS function). When calling the second function, it is necessary to read the data passed through the first function to complete the calculation process of the second function. If the data passed through the second function is passed to the first function through data copying, it will generate a large amount of data copying overhead and also affect the execution efficiency of the first function. Therefore, in this embodiment, data sharing is achieved by sharing linear memory between the first and second functions. In specific implementation, the JS module can actively create a linear memory instance (such as creating a linear memory instance through WebAssembly.Memory, where WebAssembly.Memory is a built-in constructor provided by the WASM specification) and pass it to the WASM module to form the same memory block that can be accessed by both JS and WASM. The memory block is a contiguous memory region in bytes. The JS module requests a shared memory region in the memory block through the memory allocation function exposed by the WASM module and obtains the starting address and length of the shared memory region. A memory view is created using a tool (such as TypedArray). This view directly points to the start and length of the shared memory region. The JS module writes the data it needs to pass directly into this memory view, without needing to copy data. The JS module passes the start pointer and length of the shared memory region to the WASM module. The WASM module uses functions provided by the native code language (such as Rust's std::slice::from_raw_parts_mut) to convert the pointer and length into operable memory slices. WASM directly reads / modifies the slice content. After reading / modifying, it doesn't need to return the complete data; it only needs to return the memory pointer of the read / modified result to the JS module. After receiving the memory pointer from WASM, the JS module creates another memory view using a tool. This view directly maps to the data region processed by WASM. The JS module can directly read or render the data in the processed data region without needing to copy data. After the data is used, the shared memory is released using the memory release function exposed by the WASM module to avoid memory leaks. The above process completes the zero-copy / minimum copy data process, where data is stored only once in the shared memory area. The JS module and WASM module directly manipulate the data through views / pointers, avoiding the performance loss of data copying and passing in traditional methods. This method is particularly suitable for large-scale data scenarios (such as images, hidden areas, and large-scale computations), and can significantly improve data interaction efficiency.

[0063] In some embodiments, after executing the target task request by calling the corresponding function according to the function call path, the method further includes: In response to the fact that the function call path is the path corresponding to the first function, and the execution of the target task request by calling the corresponding function according to the path corresponding to the first function fails, the function call path is adjusted to the path corresponding to the second function; The target task request is executed by calling the corresponding function according to the path corresponding to the second function, and the execution result is obtained.

[0064] Specifically, when the first function fails to load or is called incorrectly, resulting in a failure to call the first function via its corresponding path, this embodiment provides an exception rollback mechanism. In this case, the function call path is switched to the path corresponding to the second function, and the target task request is executed by calling the second function to obtain the execution result. This ensures uninterrupted execution of the target task request, achieving a seamless user experience. The input parameters, output format, and functional logic of the first and second functions are identical, providing a basis for seamless switching in the exception rollback mechanism. During the execution of the target task request via the first function, all exceptions in the WASM module from loading to execution are captured in real time. Once an exception is detected, the exception rollback mechanism is immediately triggered, switching the path from the first function to the second function. For example, exceptions may include WASM download failure, instantiation failure, loading timeout, and execution exceptions. The exception rollback mechanism provided in this embodiment ensures that the target task request will resume normally after execution, avoiding interruption. In complex scenarios, the exception rollback mechanism can improve the fault tolerance of the target task execution process and reduce the failure rate.

[0065] It should be noted that the method in this embodiment can be executed by a single device, such as a computer or server. The method can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the method described.

[0066] It should be noted that some embodiments of this application have been described above. In some cases, the actions or steps described in the above embodiments can be performed in a different order than that shown in the above embodiments and the desired result can still be achieved. In addition, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0067] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides a front-end task execution device.

[0068] refer to Figure 2 The front-end task execution device includes: The acquisition module 202 is configured to acquire the runtime environment information of the target task request in response to receiving a target task request sent by a user through the front-end page of the client. The determination module 204 is configured to determine the function call path corresponding to the target task request from a plurality of pre-built function call paths according to the runtime environment information and in accordance with the pre-built call logic; wherein, the plurality of function call paths include the path corresponding to the first function and the path corresponding to the second function, and the first function is obtained by rewriting and compiling according to the business logic of the second function; Module 206 is configured to call the corresponding function from the pre-generated hybrid function interface according to the function call path to execute the target task request and obtain the execution result. Display module 208 is configured to display the execution result on the front-end page.

[0069] In some embodiments, the runtime environment information includes client performance information, network status information, target task request priority, and call cache information of the first function; the determining module 204 is configured to Based on the call caching information of the first function, determine whether the first function has been cached in the front-end page; in response to the first function being cached in the front-end page, use the path corresponding to the first function as the function call path; in response to the first function not being cached in the front-end page, use the target call path as the function call path based on the client performance information, the network status information, and / or the target task request priority; wherein, the target call path is the path corresponding to the first function or the path corresponding to the second function.

[0070] In some embodiments, the determining module 204 is configured to: in response to the target task request priority being a preset high priority, use the path corresponding to the second function as the function call path; in response to the target task request priority not being a preset high priority, load the first function and determine the target call path based on the loading time of the first function; in response to the target task request priority being a preset low priority, the client performance information including low-performance clients and the network status information including weak network status, use the path corresponding to the second function as the function call path.

[0071] In some embodiments, the determining module 204 is configured to determine the path corresponding to the second function as the function call path in response to the loading time of the first function exceeding a preset time threshold; and to determine the path corresponding to the first function as the function call path in response to the loading time of the first function not exceeding the preset time threshold.

[0072] In some embodiments, after determining the path corresponding to the second function as the function call path in response to the target task request priority being preset to high priority, the determining module 204 is configured to preload the first function.

[0073] In some embodiments, a generation module is further included, configured to: determine a target second function in the front-end code; create a source code file based on the business logic of the target second function; compile the source code file to obtain a first function; construct calling logic; and based on the calling logic, encapsulate the first function and the second function using an encapsulation tool to generate the hybrid function interface.

[0074] In some embodiments, the calling module 206 is configured to call the first function to process data in a pre-built shared memory region in response to the function call path being the path corresponding to the first function, thereby obtaining the execution result; wherein the data in the shared memory region is pre-written by the second function.

[0075] In some embodiments, after executing the target task request by calling the corresponding function according to the function call path, the calling module 206 is configured to, in response to the fact that the function call path is the path corresponding to the first function and the execution of the target task request by calling the corresponding function according to the path corresponding to the first function fails, adjust the function call path to the path corresponding to the second function; execute the target task request by calling the corresponding function according to the path corresponding to the second function, and obtain the execution result.

[0076] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0077] The apparatus described above is used to implement the corresponding front-end task execution method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0078] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the front-end task execution method described in any of the above embodiments.

[0079] Figure 3 This embodiment illustrates a more specific hardware structure of an electronic device. The device may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0080] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0081] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0082] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0083] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0084] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0085] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0086] The electronic devices described above are used to implement the corresponding front-end task execution methods in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0087] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides a vehicle including the electronic equipment described in the foregoing embodiments.

[0088] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium that stores computer instructions for causing the computer to execute the front-end task execution method as described in any of the above embodiments.

[0089] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0090] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the front-end task execution method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0091] Based on the same concept, corresponding to any of the above embodiments, this application also provides a computer program product, including computer program instructions, which, when run on a computer, cause the computer to perform the method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0092] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application is limited to these examples; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in detail for the sake of brevity.

[0093] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0094] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0095] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of this application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A front-end task execution method, characterized in that, include: In response to receiving a target task request sent by a user through the client's front-end page, obtain the runtime environment information of the target task request; Based on the runtime environment information, the function call path corresponding to the target task request is determined from a plurality of pre-built function call paths according to the pre-built call logic; wherein, the plurality of function call paths include the path corresponding to the first function and the path corresponding to the second function, and the first function is obtained by rewriting and compiling based on the business logic of the second function; The target task request is executed by calling the corresponding function from the pre-generated hybrid function interface according to the function call path, and the execution result is obtained. The execution results are displayed on the front-end page.

2. The method according to claim 1, characterized in that, The runtime environment information includes client performance information, network status information, target task request priority, and call cache information of the first function; The step of determining the function call path corresponding to the target task request from a pre-built set of function call paths according to the runtime environment information and pre-built call logic includes: Determine whether the first function has been cached in the front-end page based on the call cache information of the first function; Since the first function has been cached in the front-end page, the path corresponding to the first function is used as the function call path; In response to the first function not being cached in the front-end page, the target call path is used as the function call path based on the client performance information, the network status information, and / or the target task request priority; wherein, the target call path is the path corresponding to the first function or the path corresponding to the second function.

3. The method according to claim 2, wherein the step of using the target call path as the function call path based on the client performance information, the network status information, and / or the target task request priority includes: In response to the target task request priority being preset to high priority, the path corresponding to the second function is used as the function call path; In response to the fact that the priority of the target task request is not a preset high priority, the first function is loaded, and the target call path is determined based on the loading time of the first function; In response to the target task request priority being preset to low priority, the client performance information including low-performance clients and the network status information including weak network status, the path corresponding to the second function is used as the function call path.

4. The method according to claim 3, wherein determining the target call path based on the loading time of the first function includes: In response to the fact that the loading time of the first function exceeds a preset time threshold, the path corresponding to the second function is determined as the function call path; In response to the fact that the loading time of the first function does not exceed a preset time threshold, the path corresponding to the first function is determined as the function call path.

5. The method according to claim 3, after setting the path corresponding to the second function as the function call path in response to the target task request priority being preset to high priority, the method further includes: Preload the first function.

6. The method according to claim 1, wherein the method for generating the hybrid function interface comprises: Identify the target second function in the front-end code; Create a source code file based on the business logic of the target second function; The source code file is compiled to obtain the first function; The calling logic is constructed, and based on the calling logic, the first function and the second function are encapsulated using an encapsulation tool to generate the hybrid function interface.

7. The method according to claim 1, wherein the target task request is executed by calling the corresponding function according to the function call path to obtain the execution result, includes: In response to the function call path being the path corresponding to the first function, the first function is called to process the data in the pre-built shared memory region to obtain the execution result; wherein, the data in the shared memory region is pre-written by the second function.

8. The method according to claim 1, after executing the target task request by calling the corresponding function according to the function call path, further comprising: In response to the fact that the function call path is the path corresponding to the first function, and the execution of the target task request by calling the corresponding function according to the path corresponding to the first function fails, the function call path is adjusted to the path corresponding to the second function; The target task request is executed by calling the corresponding function according to the path corresponding to the second function, and the execution result is obtained.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 8.

10. A vehicle, characterized in that, The vehicle includes the electronic equipment as described in claim 9.

Images