Cloud rendering mini-program processing

Abstract

Disclosed in embodiments of the present description are a cloud rendering mini-program processing method and apparatus, and a device, applied to a cloud. The method comprises: acquiring an original browser kernel, and by using the browser kernel to dynamically run a first target mini-program, pruning the browser kernel to generate a preliminary browser kernel; selecting an mini-program target adaptation capability, and fusing the mini-program target adaptation capability with the preliminary browser kernel to obtain a fused browser kernel; generating a lightweight kernel container on the basis of the fused browser kernel; receiving operation information sent by a remote user terminal, starting and running a second target mini-program within the kernel container, and for the operation information, generating a corresponding response rendering result; and returning the response rendering result to the user terminal, so that the user terminal displays the response rendering result.

Description

Cloud rendering mini-program processing Technical Field

[0001] This manual relates to the field of cloud technology, and in particular to cloud rendering of mini-programs. Background Technology

[0002] Currently, not only are various applications emerging and growing explosively, but large and medium-sized applications, especially some leading applications, are also embedding more and more mini programs. Many of these mini programs are becoming increasingly large in size. The execution of these mini programs on users' mobile phones brings a significant processing burden, especially for users with relatively low-configuration mobile phones, where this processing burden is more obvious and will affect the running efficiency of mini programs.

[0003] Based on this, the applicant considered adopting a cloud rendering solution, which does not actually run the rendering of the mini-program content on the user's local phone. The user only needs to send the mini-program operation to the cloud from the local phone, and the cloud will respond, run the rendering, and return the response result to the user, who can then directly display the rendering result on the local phone. In this way, the processing power of the cloud is utilized, effectively reducing the burden on the user's mobile phone.

[0004] During testing, it was found that the cloud rendering solution consumed a lot of cloud resources and had mediocre performance. It also lacked compatibility with some mini-programs, which affected the user experience.

[0005] Therefore, for mini-program scenarios, a better cloud rendering solution is needed to help improve the user experience. Summary of the Invention

[0006] This specification provides one or more embodiments of a cloud rendering method, apparatus, and device for processing mini-programs, in order to solve the following technical problem: for mini-program scenarios, a better cloud rendering solution is needed to help improve the user experience.

[0007] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows.

[0008] This specification provides one or more embodiments of a cloud rendering mini-program processing method applied in the cloud. The method includes: obtaining the original browser kernel, dynamically running a first target mini-program using the browser kernel, trimming the browser kernel to generate a browser pre-kernel; filtering the mini-program target adaptation capabilities, and fusing the mini-program target adaptation capabilities with the browser pre-kernel to obtain a browser fused kernel; generating a lightweight kernel container based on the browser fused kernel; receiving operation information sent by a remote user terminal, starting and running a second target mini-program in the kernel container, generating a corresponding response rendering result for the operation information; and returning the response rendering result to the user terminal for display.

[0009] This specification provides one or more embodiments of a cloud rendering mini-program processing device applied in the cloud. The device includes: a kernel trimming module, which obtains the original browser kernel and trims it by dynamically running a first target mini-program using the browser kernel to generate a browser pre-kernel; a capability fusion module, which filters the mini-program target adaptation capabilities and fuses the mini-program target adaptation capabilities with the browser pre-kernel to obtain a browser fused kernel; a container generation module, which generates a lightweight kernel container based on the browser fused kernel; a response rendering module, which receives operation information sent by a remote user terminal, starts and runs a second target mini-program in the kernel container, and generates a corresponding response rendering result for the operation information; and a result return module, which returns the response rendering result to the user terminal for display.

[0010] This specification provides one or more embodiments of a cloud rendering mini-program processing device applied in the cloud. The device includes: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor, which, when executed, enable the at least one processor to perform the following: obtaining an original browser kernel, dynamically running a first target mini-program using the browser kernel, trimming the browser kernel to generate a preliminary browser kernel; filtering mini-program target adaptation capabilities, and fusing the mini-program target adaptation capabilities with the preliminary browser kernel to obtain a fused browser kernel; generating a lightweight kernel container based on the fused browser kernel; receiving operation information sent by a remote user terminal, starting and running a second target mini-program in the kernel container, generating a corresponding response rendering result for the operation information; and returning the response rendering result to the user terminal for display.

[0011] The above-mentioned at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects: For the browser kernel used to run and render the content of the mini-program in the cloud, the browser kernel is customized and tailored to adapt to the running conditions of the target mini-program, so as to reduce resource consumption and improve running rendering efficiency. Moreover, in order to improve the adaptability to the mini-program, some mini-program adaptation capabilities will be selected and integrated into the browser kernel, which will also help to further improve the running rendering performance and better bring out the functional potential of the target mini-program. Therefore, it helps to improve the user experience. Attached Figure Description

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

[0013] Figure 1 is a flowchart illustrating a cloud rendering applet processing method provided in one or more embodiments of this specification.

[0014] Figure 2 is a flowchart illustrating a partial scheme for browser kernel trimming provided in one or more embodiments of this specification.

[0015] Figure 3 is a flowchart illustrating a portion of the scheme for the fusion processing of mini-program target adaptation capabilities provided in one or more embodiments of this specification.

[0016] Figure 4 is a schematic diagram of the system framework corresponding to the method of Figure 1 provided in one or more embodiments of this specification in a real-world scenario.

[0017] Figure 5 is a flowchart illustrating an AI interaction extension scheme for cloud rendering provided by one or more embodiments of this specification.

[0018] Figure 6 is a schematic diagram of the structure of a cloud rendering applet processing device provided in one or more embodiments of this specification.

[0019] Figure 7 is a structural schematic diagram of a cloud rendering applet processing device provided in one or more embodiments of this specification. Detailed Implementation

[0020] This specification provides a cloud rendering applet processing method, apparatus, device, and storage medium through its embodiments.

[0021] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0022] The cloud rendering method previously considered by the applicant in the background technology refers specifically to a pure web-based cloud rendering solution, where a browser (such as Chrome) loads web pages in the cloud and displays them to remote users. However, the current browsers using this solution are based on the original browser kernel and have not been adequately modified to suit the mini-program scenario. From the perspective of the mini-program scenario, the applicant believes that such a browser kernel, carrying a large number of redundant functional modules at runtime, causes high resource consumption, with memory usage often remaining high and CPU utilization frequently in overload range, directly increasing device operating costs.

[0023] Furthermore, typical web containers lack effective integration with the native capabilities of mini-programs, making it difficult to natively load mini-programs and fully utilize their functionality.

[0024] The current mini-program operation solution does not actually deeply integrate AI intelligent services with cloud rendering and mini-program capabilities. Business operations rely on manual completion, which is inefficient and lacks sufficient intelligence, and the user experience needs to be improved.

[0025] To address these issues, this application proposes a deep customization of the original browser kernel (primarily using the Chromium kernel as an example) to create a lightweight, small kernel container. This reduces resource consumption and costs while integrating native capabilities for high-performance mini-program loading. Furthermore, it innovatively combines AI big data models to endow mini-programs with the intelligence to understand business semantics and automatically execute complex processes, while Docker ensures a stable and efficient cloud runtime environment. These improvements help overcome the bottlenecks in integrating the existing mini-program ecosystem with the AI ​​ecosystem, expand the application boundaries of mini-programs, and meet the market's urgent demand for low-cost, high-performance, and intelligent operation of mini-programs across various devices.

[0026] Based on this overall approach, the solution proposed in this application will be further explained below.

[0027] Figure 1 is a flowchart illustrating a cloud-rendered mini-program processing method provided in one or more embodiments of this specification. This method can be applied to the cloud. It should be noted that sub-solutions in this method, such as modifying the browser kernel, can also be applied to various other devices (especially user-end devices) besides cloud devices to run mini-programs more efficiently.

[0028] The process shown in Figure 1 includes the following steps.

[0029] S102: Obtain the original browser kernel, and dynamically run the first target applet using the browser kernel to trim the browser kernel and generate a browser pre-processing kernel (referring to other improvements or further measures).

[0030] The original browser kernel refers to a relatively standard or conventional browser kernel that can be used out of the box. This application, however, modifies and customizes the original browser kernel to create a non-conventional one. The original browser kernel could be the Chromium kernel; some of the following embodiments are illustrated using this scenario. Of course, for other similar browser kernels that also include the corresponding modules targeted by the improvements in this application, some sub-solutions from this application may also be used to modify and customize those other browser kernels.

[0031] In one or more embodiments of this specification, the modified mini-program to be actually used for operation is referred to as the second target mini-program. The first target mini-program and the second target mini-program can be the same mini-program; or, the first target mini-program can be a mini-program similar to the second target mini-program. For example, the first target mini-program can be obtained by simplifying the second target mini-program (e.g., prioritizing the retention of functional modules with high resource and efficiency requirements and optimizing some other modules; or retaining a key logic branch in a functional logic and optimizing some bypass branches); or, for example, a mini-program with similar business functions to the second target mini-program can be selected as the first target mini-program; and so on.

[0032] This application employs a precise and meticulous kernel trimming scheme to accurately identify and remove redundant code modules and non-critical components in the Chromium kernel, constructing a lightweight kernel container that maintains good support for web technology stacks such as HTML, CSS, and JavaScript while reducing resource requirements, thus helping to solve the high-cost dilemma of cloud rendering.

[0033] The kernel pruning scheme mainly comprises two parts: pruning based on static code analysis and real-time data analysis of dynamic mini-program execution; and layered pruning for multiple sub-engines and the network stack. In addition, the following processing was implemented: a hierarchical memory pool design and a multi-level caching architecture were adopted, using intelligent pre-fetching mechanisms and adaptive caching strategies to achieve memory defragmentation and pre-allocation optimization, helping to reduce memory consumption; a process priority-based resource scheduling algorithm was implemented, using on-demand loading, predictive loading, and intelligent resource release mechanisms, combined with process management optimization and resource limitation strategies, to help improve system stability.

[0034] It should be noted that the trimming mentioned in this application, in addition to removing certain content, can also be supplemented with corresponding logical additions and modifications, with the aim of improving the loading and running efficiency of the mini program, and should not be narrowly interpreted as simply reducing the amount of code.

[0035] S104: Filter the target adaptation capabilities of the mini-program and fuse the target adaptation capabilities of the mini-program with the browser pre-engine to obtain the browser fusion engine.

[0036] In one or more embodiments of this specification, through an innovative kernel fusion mechanism, the native capabilities that mini-programs rely on (such as native C++ capabilities) and some optional extended and enhanced capabilities are deeply embedded in the kernel container as mini-program target adaptation capabilities. This enables the kernel container to have the professional ability to directly load (or even load more efficiently) mini-programs. Compared with traditional web containers, this can improve the startup speed and running performance of mini-programs and help reduce memory consumption and CPU usage.

[0037] In addition, the fusion process may also involve trimming and modifying the browser kernel, and these actions can work together.

[0038] S106: Generate a lightweight kernel container based on the browser fusion kernel.

[0039] Based on the customized browser fusion kernel, a kernel container with additional advantages is generated, which is especially suitable for loading and running target mini-programs. It can be deployed in the cloud or on other devices with corresponding needs.

[0040] S108: Receive operation information sent by a remote user terminal, start and run a second target applet in the kernel container, and generate a corresponding response rendering result for the operation information.

[0041] This application adopts a cloud-rendered mini-program architecture. Specifically, it employs a cloud-dominated operating mode, where the client on the user's terminal can be simplified to a window displaying the cloud rendering results and an event transmission endpoint. User clicks, swipes, and other operation events on the client are instantly transmitted to the cloud. Key operations such as loading the mini-program (i.e., the second target mini-program), processing complex business logic, and rendering are completed more efficiently with the support of optimized computing resources in the cloud.

[0042] The architecture of this application is particularly well-suited for low- to mid-range machines, freeing them from performance bottlenecks. Mini programs that were originally unable to run smoothly due to insufficient local performance can now achieve smooth interaction with the help of cloud rendering. For example, users can enjoy mini program services on smartphones and tablets with lower configurations.

[0043] S110: Return the response rendering result to the user terminal so that the user terminal can display it.

[0044] The user terminal can directly display the response rendering result; or the response rendering result can be adaptively processed before displaying. In the latter case, the resources consumed by the adaptive processing are less than those consumed by the corresponding cloud-based rendering; thus, only the user terminal needs to complete a lightweight task.

[0045] Using the method shown in Figure 1, the browser kernel used to run and render mini-program content in the cloud is customized to adapt to the running conditions of the target mini-program. This reduces resource consumption and improves rendering efficiency. Furthermore, to enhance adaptability to mini-programs, some mini-program adaptation capabilities are selected and integrated into the browser kernel, which also helps to further improve rendering performance and better unleash the functional potential of the target mini-program. Therefore, it helps to improve the user experience.

[0046] It should be noted that the applicant also attempted a local off-screen rendering solution for mini-programs; however, compared to the optimized cloud rendering solution in this application, it has significant shortcomings. Under the local off-screen rendering solution, after the local terminal application receives an operation command, it launches the mini-program off-screen on the current terminal. Multiple commands can open multiple mini-programs; however, on low-end and mid-range devices, opening multiple mini-programs can lead to serious performance issues for the terminal application running off-screen. Furthermore, the terminal can also connect to the cloud for data reporting and operation command parsing and execution. This also presents the same problems as the original cloud rendering solution. Therefore, the advantages of the optimized cloud rendering solution in this application are clearly demonstrated.

[0047] Based on the method in Figure 1, this specification also provides some specific implementation schemes and extension schemes of the method, which will be further explained below.

[0048] Figure 2 is a flowchart illustrating a partial browser kernel trimming scheme provided in one or more embodiments of this specification. It belongs to the trimming process based on static code analysis and real-time data analysis of the dynamic operation of the mini-program described above. In addition, there are many other trimming schemes. Specifically, other trimming schemes can be further implemented based on the scheme in Figure 2.

[0049] The process shown in Figure 2 includes the following steps.

[0050] S202: By performing static code analysis on the browser kernel, a module dependency graph is generated and its weights are calculated.

[0051] Static code analysis is performed using existing tools or a custom abstract syntax tree parser to parse the browser kernel's code structure, identify dependencies between modules, and express them in the form of a module dependency graph for efficient subsequent processing.

[0052] For module dependency graphs, an initial dependency graph can be constructed, where nodes are modules and edges represent dependencies. Weights can be calculated based on factors such as call count, code complexity, and the number of dependent modules; more detailed considerations can also be taken into account, such as module size or execution path frequency.

[0053] S204: Dynamically run the first target applet using the browser kernel. During the running process, calculate the module call frequency and resource consumption data based on the module dependency graph and weights.

[0054] The first target mini-program can represent the situation of the second target mini-program to a certain extent, so it can be used as a reference for trial operation. Especially when the second target mini-program is simplified and customized based on the first target mini-program, it can better highlight the key operational needs and operational characteristics of the first target mini-program.

[0055] Based on module call frequency and resource usage data (which can be more intuitively represented by heatmaps, etc.), we can try to identify the key and / or non-key content of the browser kernel for the target mini-program, in order to guide the trimming tendency and prioritize trimming of non-key content.

[0056] S206: Based on the module call frequency and resource usage data, trim the browser kernel.

[0057] In one or more embodiments of this specification, the first target applet is controlled to switch between running multiple business logics. The module call frequency and resource consumption data corresponding to running different business logics are compared to determine the switching change data of module call frequency and resource consumption data. Based on the switching change data, non-critical content in the browser kernel for at least most of the multiple business logics is identified, and the browser kernel is trimmed for the non-critical content.

[0058] When switching between different data, special attention should be paid to situations where the peak values ​​of the corresponding call frequency and resource consumption are high, but the changes are drastic. This indicates that the data may only be needed in specific business logic within the target mini-program. In such cases, depending on the importance of that specific business logic, the corresponding content in the browser kernel may be considered non-critical, rather than necessarily critical. In this situation, cloud support for the target mini-program may be incomplete (this part can be scheduled to execute locally on the user's terminal), but this could result in a significant improvement in efficiency.

[0059] In one or more embodiments of this specification, the layered pruning process for multiple sub-engines and the network stack has also been mentioned above. This process can be performed independently or based on the process shown in Figure 2; the latter case will be taken as an example.

[0060] Layered clipping processing includes, for example, identifying the target objects for layered clipping within the browser kernel, which include the front-end script execution engine, the rendering engine, and the network stack; and clipping the compiler enabling logic of the front-end script execution engine, the loading logic and corresponding DOM tree of the rendering engine, and the loading logic of the network stack based on non-critical content identified from the browser kernel.

[0061] For the Chromium kernel, the front-end script execution engine can include the V8 engine, which can be used to execute JavaScript, and the rendering engine can include the Blink rendering engine. By layering and modifying the V8 engine's JIT compiler selectively, loading rendering modules on demand, optimizing the DOM tree accordingly, and dynamically loading network components, operational efficiency can be improved. Based on this idea, a specific implementation includes: performing a first pruning process on the compiler-direct execution logic of the front-end script execution engine's compiler-enabled logic, so that the interpreter execution logic corresponding to the compiler-enabled logic is used to execute non-critical content identified from the browser kernel; determining the degree of performance reduction compared to using the compiler-direct execution logic based on the execution results; adapting to the execution of the interpreter execution logic, attempting one or more different second pruning processes on the rendering engine's loading logic and the corresponding DOM tree, and determining the degree of performance improvement brought by each second pruning process; and determining whether to prune the non-critical content by comparing the degree of performance reduction with the degree of performance improvement. For example, if the improvement in execution efficiency can outweigh the adverse effects of the decrease in execution efficiency, non-critical content can be retained to support more potential functions of the mini-program. However, if the decrease in execution efficiency is relatively greater, non-critical content can be considered for removal.

[0062] Figure 3 is a flowchart illustrating a portion of the scheme for the fusion processing of mini-program target adaptation capabilities provided in one or more embodiments of this specification.

[0063] The process shown in Figure 3 includes the following steps.

[0064] S302: Define rendering extension capabilities and component bridging capabilities as the target adaptation capabilities for mini programs.

[0065] S304: Regarding the rendering extension capability, the rendering layer of the browser's pre-kernel is located, and a rendering process manager and a UI thread scheduler are integrated into the rendering layer to separate the logic layer and view layer of the target mini-program for separate operation.

[0066] For the Chromium kernel, the Blink engine can be extended in the rendering layer to implement a dual-threaded (e.g., logic thread and view thread) rendering architecture. An additional render process manager and UI thread scheduler can be built; for example, the render process manager can be responsible for creating and managing multiple render processes or threads, while the UI thread scheduler can be responsible for coordinating task scheduling and communication between the logic thread and the view thread.

[0067] In one or more embodiments of this specification, the JavaScript of the logic layer can run in a separate worker thread during the rendering process, while the view layer runs on the main thread. The logic layer communicates with the view layer via message passing, and the view layer is responsible for updating and rendering the DOM.

[0068] Accordingly, the Blink engine can be extended to support separating the JavaScript execution environment into logic threads and view threads, and establishing a communication mechanism. For example, the script execution module of the Blink engine can be modified so that the JavaScript code of the mini-program's logic layer runs in a worker thread, while the JavaScript of the view layer runs in the main thread. Considering that the mini-program may completely separate the logic layer and the view layer, with the view layer only performing data binding and rendering and not executing business logic, a new execution context can be created in the Blink engine specifically for the logic layer, running in an independent thread. The view layer retains its existing main thread execution environment, but restricts it to performing only rendering-related operations, such as DOM updates and style calculations. Communication between the two needs to be through serialized messages; for example, data changes from the logic layer are passed to the view layer via messages, and the view layer updates the DOM based on these changes.

[0069] The render process manager is responsible for creating and managing logic threads and view threads. Additionally, the UI thread scheduler may need to coordinate task priorities between the two threads; for example, when the view thread is busy, the logic thread's tasks can be appropriately scheduled to avoid blocking.

[0070] S306: For the component bridging capability, the component layer of the browser's pre-kernel is located, and a native component bridging layer is integrated into the component layer. In the native component bridging layer, the native binding mechanism is used to connect native component capabilities, thereby constructing a unified rendering pipeline and component lifecycle management system for the target mini-program.

[0071] In one or more embodiments of this specification, the component layer may include modules from the Blink engine, such as the DOM and the render tree. Considering that the Chromium kernel itself already has a relatively mature rendering pipeline, native components may not be directly integrated; therefore, a bridging layer is constructed to connect them.

[0072] For a unified rendering pipeline, the Chromium kernel's rendering process includes steps such as style calculation, layout, drawing, and compositing. However, native components may need to bypass certain steps and be processed directly by the GPU. In such cases, a bridging layer can integrate native components into the existing rendering pipeline and process these native components at the compositor stage to ensure that they can be correctly composited with other layers.

[0073] Regarding component lifecycle management: Native components may require lifecycle events such as initialization, updating, and destruction. The bridging layer can pass these events from the Blink engine to the native code to ensure proper resource management and avoid memory leaks. Based on this, a component lifecycle management system can be designed to track the state of each component and trigger the corresponding methods at the appropriate time.

[0074] In addition to the mini-program target adaptation capabilities shown in Figure 3, other capabilities can also be integrated. For example, the custom security environment capability can be defined as the mini-program target adaptation capability; for the mini-program target adaptation capability, the focus is on the content shell layer of the browser pre-kernel, where the permission management system and resource access controller are integrated; an independent front-end script engine instance and content isolation are implemented in the front-end script execution engine of the browser pre-kernel; based on the integrated and implemented content, a custom security environment is built for the target mini-program in the browser pre-kernel.

[0075] For the Chromium kernel, based on the ability to customize security environments, such as the ability to implement a custom mini-program security sandbox environment, the target mini-program can be run directly in the Chromium kernel through the mini-program security sandbox environment, achieving a more secure isolation and control effect.

[0076] It should be noted that, in addition to the improvements in the above-mentioned trimming and capability fusion processing, more improvements have been introduced, which will be described in conjunction with Figure 4. Figure 4 is a schematic diagram of the system framework corresponding to the method of Figure 1 provided by one or more embodiments of this specification in a real-world scenario.

[0077] In Figure 4, given the lack of intelligent automation in the original cloud rendering solution, an AI large model is introduced to work collaboratively with the cloud rendering mini-program. This enables automated conversion and precise execution of business semantic understanding and atomic operations within the mini-program. Intelligent algorithms optimize the instruction issuance and execution process, ensuring efficient and accurate business process advancement. This breaks the traditional mini-program operation and business operation model, opening up a new path for intelligent automation. See Figure 5 for a more intuitive and exemplary representation.

[0078] Figure 5 is a flowchart illustrating an AI interaction extension scheme for cloud rendering provided by one or more embodiments of this specification. In the scenario of Figure 5, the aforementioned mini-program target adaptation capability includes AI interaction extension capability, and the aforementioned operation information includes business semantics expressed by the user in natural language (e.g., natural user statements such as "Help me book a nearby hotel", as the intent / event in the figure), which are transmitted to the cloud rendering mini-program system through the message channel module.

[0079] S502: When generating the corresponding response rendering result for the operation information, the operation information is specifically provided to the edge AI big model, which is also deployed on the cloud and is outside the browser fusion kernel, through the AI ​​interaction extension capability. This allows the edge AI big model to decompose the business semantics into multiple atomic instructions defined by the AI ​​interaction extension capability (such as operation instructions, call instructions, request instructions, etc. in the AI ​​interaction extension module in the figure).

[0080] In one or more embodiments of this specification, the first target applet can be simplified and reconstructed based on atomic instructions. In this case, the browser kernel can be trimmed to generate multiple different browser pre-kernels for different atomic instructions; the kernel containers corresponding to the different browser pre-kernels are used to run the corresponding atomic instructions among the multiple atomic instructions, so as to isolate execution with finer granularity. In this way, overall, it can handle and respond to users more efficiently, with better decoupling and security, and also facilitates efficient local adjustments.

[0081] S504: Through the AI ​​interaction extension capability, the multiple atomic instructions are converted into corresponding native operation instructions for the mini-program (i.e., Native operation instructions in the diagram, etc.). The native operation instructions for the mini-program drive the target mini-program running in the cloud to complete the business process.

[0082] S506: In the kernel container, the corresponding native operation instructions of the target applet are executed through the second target applet to generate the corresponding response rendering result.

[0083] For example, the intelligent service module can return the information to the terminal to realize the intention completion status and result output.

[0084] Based on the solution in Figure 5, business semantics can be automatically parsed and atomic commands can be executed efficiently, simplifying the originally cumbersome manual operation into a single command-driven process, greatly improving business operation efficiency, and optimizing user experience and business processing capabilities.

[0085] As shown in Figure 4, Docker technology is used to build a dedicated Linux runtime environment for mini-programs in the cloud. All dependencies, configurations, and minimal core containers required for mini-program operation are packaged into independent Docker images. When deploying a new mini-program instance, simply pull the image from the image repository and start the container; deployment can be completed within seconds, achieving rapid deployment. Each mini-program runs in an independent Docker container, with fine-grained isolation of file systems, networks, and system resources between containers to ensure stability and security. Simultaneously, the intelligent scheduling system monitors the resource usage and business load of mini-programs within each container in real time, dynamically adjusting resource allocation to improve cloud resource utilization.

[0086] In addition, the atomic capabilities of mini-programs have been expanded, including: a customized Chromium-based development underlying support, endowing mini-programs with rich and practical self-executing atomic capabilities, covering functions such as opening and closing specified mini-programs, precise screenshots, smooth swiping, simulated clicks, intelligent input, fast navigation, and dumping page DOM information. These atomic capabilities work in conjunction with cloud rendering and AI services, playing a key role in diverse scenarios such as automated testing and business process automation, further expanding the functional boundaries of mini-programs and enhancing their flexibility in responding to complex business needs.

[0087] Based on the same approach, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, as shown in Figures 6 and 7. The apparatus and devices are capable of executing the above methods and related optional solutions accordingly.

[0088] Figure 6 is a schematic diagram of a cloud rendering mini-program processing device provided in one or more embodiments of this specification. Applied to the cloud, the device includes: a kernel trimming module 602, which obtains the original browser kernel and trims it by dynamically running a first target mini-program using the browser kernel to generate a browser pre-kernel; a capability fusion module 604, which filters the mini-program target adaptation capabilities and fuses them with the browser pre-kernel to obtain a browser fused kernel; a container generation module 606, which generates a lightweight kernel container based on the browser fused kernel; a response rendering module 608, which receives operation information sent by a remote user terminal, starts and runs a second target mini-program in the kernel container, and generates a corresponding response rendering result for the operation information; and a result return module 610, which returns the response rendering result to the user terminal for display.

[0089] Optionally, the kernel trimming module 602 performs static code analysis on the browser kernel to generate a module dependency graph and calculate weights; dynamically runs the first target applet using the browser kernel; during the running process, calculates module call frequency and resource consumption data based on the module dependency graph and weights; and trims the browser kernel based on the module call frequency and resource consumption data.

[0090] Optionally, the kernel trimming module 602 controls the first target mini-program to switch between running multiple business logics; compares the module call frequency and resource consumption data corresponding to running different business logics to determine the switching change data of the module call frequency and resource consumption data; identifies non-critical content in the browser kernel for at least most of the multiple business logics based on the switching change data; and trims the browser kernel for the non-critical content.

[0091] Optionally, the kernel trimming module 602 determines the layered trimming target object in the browser kernel, the layered trimming target object including the front-end script execution engine, the rendering engine, and the network stack; based on the non-critical content identified from the browser kernel, it trims the compiler enabling logic of the front-end script execution engine, trims the loading logic and corresponding DOM tree of the rendering engine, and trims the loading logic of the network stack.

[0092] Optionally, the kernel trimming module 602 performs a first trimming process on the compiler direct execution logic of the compiler enabling logic of the front-end script execution engine, so as to use the interpreter execution logic corresponding to the compiler enabling logic to execute non-critical content identified from the browser kernel. Based on the execution result, it determines the degree of execution efficiency reduction compared to execution using the compiler direct execution logic. Adapting to the execution status of the interpreter execution logic, it attempts to perform one or more different second trimming processes on the loading logic of the rendering engine and the corresponding DOM tree, and determines the degree of execution efficiency improvement brought by each second trimming process. By comparing the degree of execution efficiency reduction with the degree of execution efficiency improvement, it determines whether to trim the non-critical content.

[0093] Optionally, the first target mini-program and the second target mini-program are the same mini-program; or, the first target mini-program is a simplified version of the second target mini-program.

[0094] Optionally, the capability fusion module 604 determines the rendering extension capability and component bridging capability as the target adaptation capabilities of the mini-program; for the rendering extension capability, it is located at the rendering layer of the browser's pre-kernel, and a rendering process manager and a UI thread scheduler are integrated into the rendering layer to separate the logic layer and view layer of the target mini-program for separate operation; for the component bridging capability, it is located at the component layer of the browser's pre-kernel, and a native component bridging layer is integrated into the component layer, and a native binding mechanism is used to connect native component capabilities in the native component bridging layer to build a unified rendering pipeline and component lifecycle management system for the target mini-program.

[0095] Optionally, the capability fusion module 604 determines the custom security environment capability as the target adaptation capability of the mini-program; for the target adaptation capability of the mini-program, it locates the content shell layer of the browser pre-kernel, and integrates the permission management system and resource access controller into the content shell layer; it implements an independent front-end script engine instance and content isolation in the front-end script execution engine of the browser pre-kernel; based on the fused content and the implemented content, it builds a custom security environment for the target mini-program in the browser pre-kernel.

[0096] Optionally, the target adaptation capability of the mini-program includes AI interaction extension capability, and the operation information includes business semantics expressed by the user in natural language; the response rendering module 608 provides the operation information to the edge AI large model deployed in the cloud outside the browser fusion kernel through the AI ​​interaction extension capability, so that the edge AI large model decomposes the business semantics into multiple atomic instructions defined by the AI ​​interaction extension capability; through the AI ​​interaction extension capability, the multiple atomic instructions are converted into corresponding mini-program native operation instructions; in the kernel container, the second target mini-program executes the corresponding mini-program native operation instructions to generate the corresponding response rendering result.

[0097] Optionally, the first target mini-program is simplified and reconstructed based on the atomic instructions; after the kernel trimming module 602 decomposes the multiple atomic instructions defined by the AI ​​interaction extension capability, it trims the browser kernel to generate multiple different browser pre-kernels for different atomic instructions; and uses the kernel containers corresponding to the different browser pre-kernels to run the corresponding atomic instructions among the multiple atomic instructions.

[0098] Optionally, the browser engine includes the Chromium engine.

[0099] Figure 7 is a schematic diagram of the structure of a cloud rendering mini-program processing device provided in one or more embodiments of this specification, applied in the cloud. The device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to perform: obtaining the original browser kernel, and dynamically running a first target mini-program using the browser kernel to trim the browser kernel and generate a browser pre-kernel; filtering the mini-program target adaptation capabilities and fusing the mini-program target adaptation capabilities with the browser pre-kernel to obtain a browser fused kernel; generating a lightweight kernel container based on the browser fused kernel; receiving operation information sent by a remote user terminal, starting and running a second target mini-program in the kernel container, and generating a corresponding response rendering result for the operation information; and returning the response rendering result to the user terminal for display.

[0100] Based on the same approach, one or more embodiments of this specification also provide a non-volatile computer storage medium applied in the cloud. The medium stores computer-executable instructions configured to: obtain the original browser kernel, dynamically run a first target applet using the browser kernel, trim the browser kernel to generate a preliminary browser kernel; filter the applet's target adaptation capabilities, and fuse the applet's target adaptation capabilities with the preliminary browser kernel to obtain a fused browser kernel; generate a lightweight kernel container based on the fused browser kernel; receive operation information sent by a remote user terminal, start and run a second target applet in the kernel container, generate a corresponding response rendering result for the operation information; and return the response rendering result to the user terminal for display.

[0101] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0102] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0103] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0104] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0105] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0106] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0107] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0108] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0109] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0110] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0111] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0112] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0113] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0114] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0115] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0116] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A cloud-rendered mini-program processing method, applied in the cloud, the method comprising: Obtain the original browser kernel, and dynamically run the first target applet using the browser kernel to trim the browser kernel and generate a browser pre-kernel; The target adaptation capabilities of the mini-program are selected, and the target adaptation capabilities of the mini-program are fused with the browser pre-engine to obtain the browser fusion engine; A lightweight kernel container is generated based on the browser fusion kernel. Receive operation information sent by a remote user terminal, start and run a second target applet in the kernel container, and generate a corresponding response rendering result for the operation information; The response rendering result is returned to the user terminal for display.

2. The method as described in claim 1, wherein dynamically running the first target applet using the browser kernel and trimming the browser kernel specifically includes: By performing static code analysis on the browser kernel, a module dependency graph is generated and its weights are calculated. The browser kernel is used to dynamically run the first target mini-program. During the running process, the module call frequency and resource consumption data are calculated based on the module dependency graph and weight. Based on the module call frequency and resource consumption data, the browser kernel is trimmed.

3. The method as described in claim 2, wherein trimming the browser kernel based on the module call frequency and resource consumption data specifically includes: Control the first target mini-program to switch between running in various business logics; Compare the module call frequency and resource usage data corresponding to running different business logics to determine the switching and change data of the module call frequency and resource usage data; Based on the switching change data, identify non-critical content in the browser kernel that relates to at least most of the business logic among the various business logics; For the non-critical content, the browser kernel is trimmed.

4. The method as described in claim 1 or 3, wherein the trimming of the browser kernel specifically includes: Identify the layered clipping target object in the browser kernel, wherein the layered clipping target object includes the front-end script execution engine, the rendering engine, and the network stack; Based on non-critical content identified from the browser kernel, the compiler enabling logic of the front-end script execution engine is trimmed, the loading logic of the rendering engine and the corresponding DOM tree are trimmed, and the loading logic of the network stack is trimmed.

5. The method as described in claim 4, wherein the step of trimming the compiler enabling logic of the front-end script execution engine and the loading logic and corresponding DOM tree of the rendering engine based on non-critical content identified from the browser kernel specifically includes: The compiler-enabled logic of the front-end script execution engine is first trimmed to allow the interpreter execution logic corresponding to the compiler-enabled logic to execute non-critical content identified from the browser kernel. Based on the execution result, the degree of reduction in execution efficiency compared to using the compiler-enabled logic is determined. Depending on the execution status of the interpreter's execution logic, one or more different second pruning processes are attempted on the rendering engine's loading logic and the corresponding DOM tree, and the degree of execution efficiency improvement brought about by each second pruning process is determined. By comparing the degree of decrease in execution efficiency with the degree of increase in execution efficiency, it is determined whether the non-critical content should be cut out.

6. The method as described in claim 1, wherein the first target mini-program and the second target mini-program are the same mini-program; or, the first target mini-program is obtained by simplifying the second target mini-program.

7. The method as described in claim 1, wherein the step of filtering the target adaptation capabilities of the mini-program and fusing the target adaptation capabilities of the mini-program with the browser pre-kernel specifically includes: Rendering extension capabilities and component bridging capabilities are identified as the target adaptation capabilities for mini-programs. Regarding the rendering extension capability, it is located at the rendering layer of the browser's pre-kernel. In the rendering layer, a rendering process manager and a UI thread scheduler are integrated to separate the logic layer and view layer of the target mini-program for separate operation. For the component bridging capability, it is located at the component layer of the browser's pre-kernel. In the component layer, a native component bridging layer is integrated. In the native component bridging layer, the native binding mechanism is used to connect native component capabilities, thereby constructing a unified rendering pipeline and component lifecycle management system for the target mini-program.

8. The method as described in claim 1 or 7, wherein the step of filtering the target adaptation capabilities of the mini-program and fusing the target adaptation capabilities of the mini-program with the browser pre-kernel specifically includes: Define the ability to customize the security environment as a target adaptation capability for mini programs; For the target adaptation capability of the mini program, the content shell of the browser's pre-kernel is located, and the permission management system and resource access controller are integrated into the content shell. Implement independent front-end script engine instances and content isolation within the front-end script execution engine of the browser's pre-engineered kernel; Based on the integrated content and the implemented content, a custom security environment is built for the target mini-program in the browser's pre-kernel.

9. The method as described in claim 1, wherein the mini-program target adaptation capability includes AI interaction extension capability, and the operation information includes business semantics expressed by the user in natural language; The generation of corresponding response rendering results for the operation information specifically includes: The operation information is provided to the edge AI big model, which is also deployed on the cloud and is outside the browser fusion kernel, through the AI ​​interaction extension capability, so that the edge AI big model can decompose the business semantics into multiple atomic instructions defined by the AI ​​interaction extension capability. Through the AI ​​interaction extension capability, the multiple atomic instructions are converted into corresponding native operation instructions of the mini program; Within the kernel container, the second target mini-program executes the corresponding native operation instructions to generate the corresponding response rendering results.

10. The method of claim 9, wherein the first target applet is obtained by simplified reconstruction based on the atomic instructions; After the decomposition into multiple atomic instructions defined by the AI ​​interaction extension capability, the method further includes: The browser kernel is trimmed to generate multiple different browser pre-kernels for different atomic instructions; Using different browser pre-processing kernels corresponding to the kernel containers, the corresponding atomic instructions among the multiple atomic instructions are executed.

11. The method of claim 1, wherein the browser kernel comprises the Chromium kernel.

12. A cloud-rendered mini-program processing device, applied in the cloud, the device comprising: The kernel trimming module obtains the original browser kernel and trims it by dynamically running the first target applet using the browser kernel to generate a browser pre-kernel. The capability fusion module filters the target adaptation capabilities of the mini-program and fuses the target adaptation capabilities of the mini-program with the browser pre-kernel to obtain the browser fusion kernel; The container generation module generates a lightweight kernel container based on the browser fusion kernel. The response rendering module receives operation information sent by a remote user terminal, starts and runs a second target applet in the kernel container, and generates corresponding response rendering results for the operation information. The result return module returns the response rendering result to the user terminal for display.

13. The apparatus of claim 12, wherein the kernel trimming module generates a module dependency graph and calculates weights by performing static code analysis on the browser kernel; The browser kernel is used to dynamically run the first target mini-program. During the running process, the module call frequency and resource consumption data are calculated based on the module dependency graph and weight. Based on the module call frequency and resource consumption data, the browser kernel is trimmed.

14. The apparatus of claim 13, wherein the kernel trimming module controls the first target applet to switch between running in multiple business logics; Compare the module call frequency and resource usage data corresponding to running different business logics to determine the switching and change data of the module call frequency and resource usage data; Based on the switching change data, identify non-critical content in the browser kernel that relates to at least most of the business logic among the various business logics; For the non-critical content, the browser kernel is trimmed.

15. The apparatus of claim 12 or 14, wherein the kernel trimming module determines a layered trimming target object in the browser kernel, the layered trimming target object including a front-end script execution engine, a rendering engine, and a network stack; Based on non-critical content identified from the browser kernel, the compiler enabling logic of the front-end script execution engine is trimmed, the loading logic of the rendering engine and the corresponding DOM tree are trimmed, and the loading logic of the network stack is trimmed.

16. The apparatus of claim 15, wherein the kernel trimming module performs a first trimming process on the compiler direct execution logic of the compiler enabling logic of the front-end script execution engine, so as to use the interpreter execution logic corresponding to the compiler enabling logic to execute non-critical content identified from the browser kernel, and determines the degree of reduction in execution efficiency compared to using the compiler direct execution logic based on the execution result; Depending on the execution status of the interpreter's execution logic, one or more different second pruning processes are attempted on the rendering engine's loading logic and the corresponding DOM tree, and the degree of execution efficiency improvement brought about by each second pruning process is determined. By comparing the degree of decrease in execution efficiency with the degree of increase in execution efficiency, it is determined whether the non-critical content should be cut out.

17. The apparatus of claim 12, wherein the first target mini-program and the second target mini-program are the same mini-program; or, the first target mini-program is obtained by simplifying the second target mini-program.

18. The apparatus of claim 12, wherein the capability fusion module determines the rendering extension capability and component bridging capability as the target adaptation capability of the mini-program; Regarding the rendering extension capability, it is located at the rendering layer of the browser's pre-kernel. In the rendering layer, a rendering process manager and a UI thread scheduler are integrated to separate the logic layer and view layer of the target mini-program for separate operation. For the component bridging capability, it is located at the component layer of the browser's pre-kernel. In the component layer, a native component bridging layer is integrated. In the native component bridging layer, the native binding mechanism is used to connect native component capabilities, thereby constructing a unified rendering pipeline and component lifecycle management system for the target mini-program.

19. The apparatus as described in claim 12 or 18, wherein the capability fusion module determines the custom security environment capability as the target adaptation capability of the mini-program; For the target adaptation capability of the mini program, the content shell of the browser's pre-kernel is located, and the permission management system and resource access controller are integrated into the content shell. Implement independent front-end script engine instances and content isolation within the front-end script execution engine of the browser's pre-engineered kernel; Based on the integrated content and the implemented content, a custom security environment is built for the target mini-program in the browser's pre-kernel.

20. The apparatus of claim 12, wherein the mini-program target adaptation capability includes AI interaction extension capability, and the operation information includes business semantics expressed by the user in natural language; The response rendering module provides the operation information to the edge AI big model, which is also deployed on the cloud and is outside the browser fusion kernel, through the AI ​​interaction extension capability, so that the edge AI big model can decompose the business semantics into multiple atomic instructions defined by the AI ​​interaction extension capability. Through the AI ​​interaction extension capability, the multiple atomic instructions are converted into corresponding native operation instructions of the mini program; Within the kernel container, the second target mini-program executes the corresponding native operation instructions to generate the corresponding response rendering results.

21. The apparatus of claim 20, wherein the first target applet is obtained by simplified reconstruction based on the atomic instructions; The kernel trimming module, after decomposing the kernel into multiple atomic instructions defined by the AI ​​interaction extension capability, trims the browser kernel to generate multiple different browser pre-kernels for different atomic instructions. Using different browser pre-processing kernels corresponding to the kernel containers, the corresponding atomic instructions among the multiple atomic instructions are executed.

22. The apparatus of claim 12, wherein the browser kernel comprises the Chromium kernel.

23. A cloud-rendered mini-program processing device, applied in the cloud, the device comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: Obtain the original browser kernel, and dynamically run the first target applet using the browser kernel to trim the browser kernel and generate a browser pre-kernel; The target adaptation capabilities of the mini-program are selected, and the target adaptation capabilities of the mini-program are fused with the browser pre-engine to obtain the browser fusion engine; A lightweight kernel container is generated based on the browser fusion kernel. Receive operation information sent by a remote user terminal, start and run a second target applet in the kernel container, and generate a corresponding response rendering result for the operation information; The response rendering result is returned to the user terminal for display.

Images