A program execution method and apparatus

Abstract

This application discloses a program running method and apparatus. The method and apparatus determine a target process to be allocated to a lightweight program from a preset program process, wherein each preset program process has independent running resources; the target process's running resources uniquely run the lightweight program with the allocated relationship. By limiting the number of preset program processes and ensuring that the corresponding target process exclusively occupies running resources during the lightweight program's operation, process-level isolation between different lightweight programs is achieved. A crash in a single lightweight program only affects its own process and will not cause abnormalities in the host app or other lightweight programs, thus ensuring overall operational stability. Each process uniquely runs its corresponding lightweight program, avoiding conflicts caused by multiple instances sharing process resources and improving the independence and reliability of lightweight program operation.

Description

Technical Field

[0001] This application relates to the field of software technology, and in particular to a program running method and apparatus. Background Technology

[0002] With the continuous development of computer technology, software development methods have made significant progress. Lightweight applications are those that can be used without downloading and installation, fulfilling the need for readily available applications and embodying the "use and go" philosophy. As lightweight applications are increasingly used in various fields of work and life, users are using them more and more frequently.

[0003] The applicant found that the lightweight application was prone to lag or even crashes, and that crashes could cause the entire host app or other lightweight applications to crash. Summary of the Invention

[0004] This application provides a program running method and apparatus, which solves the technical problem that lightweight programs are prone to lag or even crash, and that crashes may cause the entire host APP or other lightweight programs to crash.

[0005] In a first aspect, embodiments of this application provide a program running method, which includes:

[0006] The target process that establishes an allocation relationship with the lightweight program is determined from the preset program processes, wherein each of the preset program processes has independent running resources; The target process uniquely runs a lightweight program with allocation relationships using its runtime resources.

[0007] Secondly, embodiments of this application provide a program running apparatus, which includes: A process allocation unit is used to determine the target process that establishes an allocation relationship with the lightweight program from the preset program processes, wherein each of the preset program processes has independent running resources; The process execution unit is used to uniquely run a lightweight program with an allocation relationship using the execution resources of the target process.

[0008] Thirdly, embodiments of this application provide an electronic device, which includes: One or more processors; Memory, used to store one or more computer programs; When one or more computer programs are executed by one or more processors, an electronic device performs the program execution method as described in the embodiments of this application.

[0009] Fourthly, embodiments of this application provide a non-volatile storage medium for storing computer-executable instructions, which, when executed by a computer processor, are configured to perform the program execution method described in embodiments of this application.

[0010] In this embodiment, a target process that establishes an allocation relationship with a lightweight program is determined from preset program processes. Each preset program process has independent runtime resources. The lightweight program with the allocation relationship is uniquely run using the runtime resources of the target process. By limiting the number of preset program processes and ensuring that the target process with the allocation relationship exclusively occupies runtime resources during the operation of the lightweight program, process-level isolation between different lightweight programs is achieved. The crash of a single lightweight program only affects its own process and will not cause abnormalities in the host APP or other lightweight programs, thus ensuring overall operational stability. Each process uniquely runs its corresponding lightweight program, avoiding conflicts caused by multiple instances sharing process resources and improving the independence and reliability of the lightweight program's operation. Attached Figure Description

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

[0012] Figure 1 A flowchart illustrating the first program execution method provided in this application embodiment.

[0013] Figure 2 This is an overall framework diagram of the program execution method provided in the embodiments of this application.

[0014] Figure 3 A flowchart illustrating the second program execution method provided in this application embodiment.

[0015] Figure 4 A flowchart illustrating the third program execution method provided in this application embodiment.

[0016] Figure 5 This is a schematic diagram of the structure of a program running device provided in an embodiment of this application.

[0017] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] The following description and accompanying drawings fully illustrate specific embodiments of this application to enable those skilled in the art to practice them. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. The scope of embodiments of this application includes the entire scope of the claims and all available equivalents of the claims. In this document, each embodiment may be referred to individually or collectively by the term "invention," which is merely for convenience and is not intended to automatically limit the scope of the application to any single invention or inventive concept if more than one invention is disclosed. Relational terms such as "first" and "second" are used herein only to distinguish one entity or operation from another, without requiring or implying any actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed. The various embodiments in this document are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the structures, products, etc., disclosed in the embodiments, since they correspond to the disclosed parts, the descriptions are relatively simple; relevant details can be found in the method section.

[0019] Lightweight applications are those that can be used without downloading or installation, fulfilling the need for readily available applications and embodying the "use and go" philosophy. As lightweight applications are increasingly used in various aspects of work and life, users are using them more and more frequently.

[0020] The applicant found that the lightweight application was prone to lag or even crashes, and that crashes could cause the entire host app or other lightweight applications to crash.

[0021] To address the aforementioned technical issues, the applicant conducted an in-depth analysis of the underlying operational process of lightweight applications. The analysis revealed that in lightweight application scenarios, users are likely to launch multiple lightweight applications. Under the existing single-process architecture, there is significant overlap between the processes of different lightweight applications, and multiple lightweight applications typically run on a single-process architecture. In a single-process architecture, if any one of the multiple lightweight applications fails, it can lead to problems such as crashes spreading and resource conflicts.

[0022] To address the aforementioned technical issues and based on an analysis of the underlying causes, the applicant proposes a program execution method. This method identifies a target process from a set of preset program processes that establishes an allocation relationship with the lightweight program. Each preset program process possesses independent runtime resources. The target process's runtime resources are used to uniquely execute the lightweight program with the allocated relationship. By limiting the number of preset program processes and ensuring that the target process with the allocated relationship exclusively occupies runtime resources during the lightweight program's execution, process-level isolation between different lightweight programs is achieved. A crash in a single lightweight program only affects its own process and will not cause abnormalities in the host app or other lightweight programs, thus ensuring overall operational stability. Each process uniquely executes its corresponding lightweight program, avoiding conflicts caused by multiple instances sharing process resources and improving the independence and reliability of lightweight program execution.

[0023] The program execution method in this solution is applied to electronic devices. For example, it can be an integrated device that controls the content displayed on the screen and realizes human-computer interaction through an external device, such as a smartphone, personal computer, interactive smart tablet, etc.

[0024] In this electronic device, at least one operating system is installed locally and / or in the cloud. The operating system includes, but is not limited to, Android, Linux, Windows and HarmonyOS. It is used to control and coordinate the electronic device and external devices, so that the various independent hardware in the electronic device can work together as a stable whole.

[0025] The program execution method in this application embodiment can be implemented in an electronic device using a lightweight program platform. The actual implementation method is not limited here.

[0026] Please refer to Figure 1 This is a flowchart illustrating a program execution method provided in an embodiment of this application. Figure 1 As shown, the program running method includes, but is not limited to, steps S110-S120. The program running method provided in this application embodiment is used in the electronic device described above.

[0027] Step S110: Determine the target process that establishes an allocation relationship with the lightweight program from the preset program processes, wherein each of the preset program processes has independent running resources.

[0028] A process is the basic unit of resource allocation and isolation in an operating system. The preset program process in this embodiment is an independent resource container allocated by the operating system for lightweight programs. The preset program process can be bound to a unique process name through a process shell, such as miniapp1~miniapp4, meaning the preset number is 4. Of course, other numbers are also possible, as long as the hardware of the electronic device supports it. Each preset program process is configured with its own independent set of runtime resources, thereby providing an independent runtime environment for lightweight program instances and achieving resource isolation and stable operation of different lightweight programs. The process shell in this embodiment can be considered an empty, basic process container. It does not implement core business logic itself; it is only responsible for starting, managing, and wrapping the actual business process, essentially putting a shell around the core functionality.

[0029] For a single pre-defined program process, different file contents can be configured through configuration files of the same format, such as XML (Extensible Markup Language) files, thus configuring a set of independent runtime resources for each pre-defined program process. The runtime resources recorded in the configuration file can include memory space, engine instances, page components, sandbox directories, etc., ensuring that the operation of different lightweight program instances does not interfere with each other. In actual operation, a process is the runtime container for a lightweight program; one process can host one or more instances of the same lightweight program.

[0030] For multiple processes, each process has its own independent sandbox directory, engine instance, and page components. Processes cannot directly access each other's runtime resources, thus achieving mutual independence of runtime resources. When there is a need for data interaction, they can interact through cross-process communication mechanisms.

[0031] When a lightweight app starts, it is assigned a corresponding process (i.e., a pre-defined app process). For a lightweight app that has been assigned a process, the assigned process is the target process. For example, miniapps1~4 described above can be assigned to four lightweight apps as their corresponding target processes. Each process establishes an association with the lightweight app through a corresponding process shell, that is, it establishes an assignment relationship. The process shell is configured with a specified process name, theme style, and adaptability to configuration changes (such as screen rotation, keyboard state changes).

[0032] When a lightweight application is launched, ordinary users do not need to concern themselves with technical details. They can launch the application through the interaction interface of the host app or the lightweight application platform. For example, in a host app based on office collaboration, after opening the host app, the user enters the lightweight application workbench page. The user finds the target lightweight application in the list of lightweight applications and clicks the icon. The host app automatically calls the interface in the background, allocates the process, and launches the lightweight application. The user can then use it after loading is complete.

[0033] In the underlying response process, the user clicks the target lightweight program icon on the host app's lightweight program workbench; or triggers a function button (e.g., annotation) in a business scenario, such as a document editing page, to initiate a launch request. The host app passes in the core parameters, triggering the launch process. It queries the list of currently launched lightweight program instances to determine if the target lightweight program has already started (to avoid duplicate launches). In an optional implementation, during the launch of the target lightweight program, the status of the base library can be checked first. If the base library is not downloaded or needs an update, the download, decompression, and loading of the base library are performed first to ensure the runtime environment is ready.

[0034] Once the runtime environment is determined, if four fixed process shells are pre-defined as described above, the corresponding process names are: miniapp1~:miniapp4. During process allocation, idle processes are used first. If no idle processes are available, the oldest process is reused. Throughout the allocation process, the total number of processes is guaranteed not to exceed four. In the specific implementation, if an idle process is allocated, it is associated with another process. If an idle process is allocated, sensitive data and resources can be forcibly cleaned up via broadcast instructions when the lightweight program is destroyed, ensuring a clean process environment. When reusing a process, there is no need to recreate the process shell; the already initialized basic resources are directly reused.

[0035] It should be noted that steps S110-S120 in this embodiment are merely a macroscopic description of the embodiment and do not imply a strict limitation on the order of steps in the specific implementation process. For example, in step S11, the preset program processes only need to ensure that the number of processes related to the lightweight program during the operation of the lightweight program remains below the preset number, and the timing of process creation is not limited.

[0036] Step S120: Run the lightweight program with allocation relationship uniquely through the running resources of the target process.

[0037] After the target process starts, core runtime resources are initialized. In the logic layer, the engine is initialized, basic libraries and lightweight programs are loaded, and global configurations are injected. In the rendering layer, pages are created and initialized.

[0038] In addition, an independent sandbox directory for this lightweight application instance is automatically generated, containing subdirectories such as store (business data) and temp (temporary files) to achieve data isolation.

[0039] After the runtime resources are loaded, a lightweight program instance is generated, and instance information (associated with appId, process identifier, startup time, etc.) is cached for subsequent scheduling and management. The rendering layer completes rendering and displays the lightweight program interface. The logic layer executes business logic (such as data processing and event response) through a JS thread, and the rendering layer and logic layer implement bidirectional communication.

[0040] Within the target process, three types of threads work in parallel. The UI thread is responsible for page rendering and displaying native components; the JS thread is responsible for executing logic layer scripts through a single-threaded pool to avoid thread switching exceptions; and the IO thread is responsible for handling time-consuming operations such as network requests and file read / write operations without blocking the UI and JS threads.

[0041] The instances in this application are interactive functional entities formed after the lightweight program loads resources within the target process. Each instance corresponds to an independent business scenario. For example, a document annotation in the document annotation lightweight program and a translation in the online translation lightweight program correspond to one instance in each of two different lightweight programs. Similarly, two consecutive translations of different texts in the translation lightweight program correspond to two instances in the same lightweight program. Each instance has its own dedicated data storage and runtime context, and is the smallest functional unit in the actual operation of the lightweight program.

[0042] An instance can be viewed as the transformation of a lightweight application from a resource package into a usable function. After scheduling and initialization, it is bound to a specific process (e.g., miniapp1) and runs. Each instance contains a complete runtime architecture combining a logic layer and a rendering layer; that is, the logic layer handles business logic, the rendering layer is responsible for UI display, and the two communicate and coordinate. The lifecycle of one or more instances created by the same lightweight application is bound to the process; that is, if the process is reused, the instance is destroyed, and if the process is alive, the instance can run.

[0043] Each instance must be bound to a target process, sharing the process's basic resources (such as engine instances and page base libraries), but possessing independent data isolation spaces. In one optional implementation, each process can host one instance by default, meaning a maximum of four instances across four processes by default. Alternatively, one process can be configured to host multiple instances, such as one process hosting two lightweight application instances. Each instance loads its corresponding lightweight application resource package and base library upon startup. Multiple instances within the same process share process-level basic resources (such as the engine and common base libraries), but each loads its own dedicated business resources to avoid redundant consumption. Each instance has an independent sandbox directory. The storage path of this independent sandbox directory, for example, includes subdirectories such as `store` (business data) and `temp` (temporary files), isolating data from other instances. Instance data is highly independent; even multiple instances of the same lightweight application are isolated through the sandbox directory and independent virtual machine partitioning mechanisms, avoiding cache overwriting and global variable conflicts.

[0044] Based on the above description of instances, the lifecycle of an instance can be defined as including creation, running, and destruction phases. In the creation phase, after the creation method is called, process allocation is completed, resources for the logic layer and rendering layer are loaded, and instance information (appId, process identifier, startup time) is cached, thus completing instance creation. In the running phase, the instance runs within the target process. The logic layer executes JavaScript and processes business logic, the rendering layer renders the page and responds to user interactions, and threads (UI thread, JS thread, IO thread) work together. In the destruction phase, when the process needs to be reused or the user closes the lightweight application, destruction is triggered via broadcast, resource release (memory reclamation, temporary file cleanup), data persistence, and cache deletion are performed, ending the instance's lifecycle.

[0045] In summary, a lightweight application is a static resource package containing code, pages, configuration, etc., while an instance is a dynamically running functional entity. That is, after the resources required by the lightweight application are loaded, a dynamic and interactive application is formed. One lightweight application can correspond to multiple instances. A process is the runtime container for an instance, providing the basic resources for its operation. An instance is the functional carrier that implements specific business logic within a process. Processes are reusable, but instances are not. When a process is reused, destroying the existing running lightweight application first will result in the destruction of the original instance first. A thread is the execution unit of an instance; for example, the UI thread renders the page, and the JS thread processes logic. An instance relies on multiple threads to run collaboratively. Threads share process resources but have independent execution contexts.

[0046] Based on the differences and connections between the above concepts, multi-instance isolation enables the independent operation of different business scenarios (e.g., the expense approval example and contract signing example in a lightweight office application do not interfere with each other). Simultaneously, process reuse improves resource utilization, balancing stability and efficiency. Each instance has a unique identifier (associated with appId, process ID, and startup time) and is included in unified management, ensuring no scheduling conflicts and precise location during destruction. The specific execution process of each process is identical, and instances of different processes are isolated through independent sandboxes and memory spaces. A crash in a single instance only affects its own process and does not impact other lightweight applications or the host app. In the specific implementation, anomaly detection can also be performed during the startup process. If resource loading fails or process reuse anomalies during startup, a prompt will appear and the startup will be terminated, further ensuring operational stability.

[0047] In one optional implementation, the number of instances in the lightweight program can be set. When the lightweight program includes at least two instances, during the process where the target process with an allocation relationship uniquely runs the corresponding lightweight program, the at least two instances share basic resources and isolate instance data.

[0048] The number of lightweight program instances can be controlled by configuration parameters. With a fixed total number of processes, the number of instances per process can be configured. Multiple instances within the same process share basic resources and achieve a balanced operation by combining sandbox directories and independent virtual machine compartments to isolate instance data, thereby improving resource utilization and ensuring data security.

[0049] For instance data generated during the execution of the lightweight program, the instance data is cached when the lightweight program is running; and deleted when the lightweight program is closed. This instance data caching strategy based on the lightweight program's running state effectively reduces unnecessary cache usage and ensures efficient utilization of runtime resources.

[0050] In one optional implementation, the number of instances can be controlled by a mapping table. This configuration binds the process shell to the maximum number of instances per process, directly determining the global instance limit.

[0051] For example, the four preset process shells described above correspond to processes: miniapp1~miniapp4. The total number of processes cannot be dynamically increased or decreased to avoid excessive processes consuming system resources. The number of instances per process is configurable. For instance, a maximum number of instances can be specified for each process shell. The default configuration is 1 instance per process, with a maximum of 4 instances running globally simultaneously. Custom configurations are also supported, such as 2 instances per process shell, or different instance counts for each process shell. For example, lightweight utility programs (such as calculators and translators) can be configured with multiple instances per process to improve resource efficiency; lightweight programs with high security requirements (such as payment and office applications) can maintain 1 instance per process to maximize isolation and ensure security. Correspondingly, the global limit is the sum of the number of instances across the four processes.

[0052] When starting the lightweight program, query the number of already started instances. If the global limit has not been reached, allocate an idle process shell to start a new instance; if the limit has been reached, shut down a process, destroy its corresponding instance, reuse the process to start a new instance, and destroy existing instances via broadcast.

[0053] Within the same process, multiple instances share process-level basic resources, avoiding redundant loading and improving runtime efficiency. Multiple instances share core runtime resources, such as the shared engine instance, page base library, native components, and utility libraries (network requests, file read / write encapsulation). They also share common configurations and base libraries, such as the shared lightweight program base library (publicLib) and global configurations (such as the total number of processes threshold and debug switches), eliminating the need for each instance to repeatedly download and decompress base library resources. Furthermore, they can share process-level communication channels, such as sharing in-process communication interfaces, simplifying communication logic between instances and the native container.

[0054] While multiple instances share basic resources, data independence is ensured through two layers of isolation to avoid conflicts. The first layer of isolation is hierarchical sandbox directory isolation. The sandbox root directory consists of multiple levels, and each instance's runtime data is stored in an independent subdirectory: applet / user_id / app_id / (hierarchically categorized by user ID and lightweight application ID). Within this granular storage of instance data, the store directory stores business data, and the temp directory stores temporary files. Sandbox directories from different instances do not access each other, preventing cache overwriting and data leakage. The second layer of isolation involves multiple independent virtual machines within the engine. Each instance has its own independent virtual machine instance, forming an independent JS execution environment. Global variables and function scopes do not interfere with each other (e.g., variables in instance A will not affect instance B). Logic layer scripts execute in their respective virtual machines, avoiding variable pollution and function conflicts. Instance caching is managed independently, with each instance caching information separately (appId, startup time, process shell type). When an instance is destroyed, only its own cache is deleted, without affecting other instances.

[0055] It should be understood that when configuring the number of instances for each process, the performance impact and the performance requirements of the specific application scenario should be considered, and the resource utilization and stability should be comprehensively balanced. Ultimately, by sharing read-only and public resources (such as basic libraries and configurations) and isolating read and write data (such as business data, temporary files, and JS execution environment), resource consumption can be reduced while data security can be ensured.

[0056] In one optional implementation, the target process includes at least two threads that execute in parallel, and the threads share the runtime resources of the corresponding target process.

[0057] Multiple threads within the same process can achieve a macroscopic parallel and microscopic serial execution strategy through CPU time-slice rotation and a thread scheduler. During execution, the operating system allocates a very short CPU execution time (e.g., 10ms) to each thread, and the thread exclusively occupies the CPU to execute instructions within its time slice. After a single thread's time slice expires, the operating system's thread scheduler pauses the current thread, saves its execution state (i.e., records the context), and then switches to the next ready thread. From a macroscopic perspective, because the CPU switching speed is on the nanosecond scale, the user cannot perceive the switching; the intuitive feeling is that multiple threads are running simultaneously. Threads switch between five states in the order of creation → ready → running → blocked → terminated, and the scheduler only selects threads for execution from the ready queue.

[0058] All threads within the same process share the process's core resources because they belong to the same process address space. These shared core resources are process-level resources, such as heap memory, global variables, static variables, and other memory spaces; a heap object created by one thread can be directly accessed by other threads. Other examples include open files and network sockets (file descriptors); a file opened by thread A can be read and written by thread B. Process-level contexts, such as environment variables and command-line arguments, are shared by all threads, allowing them to access the app's startup parameters. Finally, the process's executable code segment allows all threads to execute the same program's code.

[0059] The underlying principle for achieving sharing is the process address space. The operating system allocates an independent virtual address space to each process, which is divided into kernel space (used by the operating system) and user space. User space contains the code segment, data segment (global / static variables), heap, and stack. All threads share the code segment, data segment, and heap in user space, but each thread has its own independent stack space. Each thread has a private stack, program counter, and registers, ensuring independent execution paths, preventing interference between local variables, and allowing the thread to resume its execution state during context switching.

[0060] During the operation of the lightweight program, specified public data can also be transferred between the target processes through a preset interface.

[0061] The transfer of specified public data between target processes can be achieved through a combination of data sharing and instruction passing interfaces. The former is responsible for adding, deleting, modifying, and querying structured public data, while the latter is responsible for triggering data synchronization or transmitting temporary instructions. The two work together to achieve secure and efficient cross-process data transfer.

[0062] The core of data sharing is used for the persistent sharing of structured public data (such as instance status and global configuration), supports cross-process query, insert, and update operations, and comes with built-in access control, making it suitable for high-frequency data access scenarios.

[0063] The core of instruction passing is used to transmit temporary instructions or data synchronization notifications (such as instance destruction and data update notifications). It is suitable for low-frequency, unstructured instruction transmission and works with ContentProvider to complete data linkage.

[0064] The data types transmitted in the shared public data design can include global configuration data, instance status data, cross-process collaboration data, and excluded sensitive data. Global configuration data includes, for example, the base library version number, the total number of processes threshold, and the maximum number of instances per process. Instance status data includes, for example, the appId, process identifier, startup time, and idle status of the running lightweight application. Cross-process collaboration data includes, for example, selected text shared by the lightweight document annotation application with the online translation service (non-sensitive public data). Excluded sensitive data, such as payment vouchers and user privacy information, are not transmitted through this method to ensure security.

[0065] Public data transmission can occur in various scenarios. For example, during a query for public configuration data (such as the base library version), the data provider stores configuration data, such as the base library version number (e.g., 1.0.0) and storage path, in an internal database or memory cache. The data querying party (target process) accesses the configuration data via a URI, without direct interaction; cross-process communication is achieved through the system's underlying mechanisms. Regarding access control, access permissions are configured, allowing only pre-defined program processes within the host app to access the data, preventing unauthorized external calls.

[0066] For example, during the synchronization of instance state data (such as adding instance cache), when an instance is created and the new lightweight application instance starts, the instance information (appId, process ID: miniapp1, startup time) is inserted into the data storage. When it is necessary to determine whether the total number of instances has reached the limit, other target processes obtain a list of all started instances, eliminating the need to traverse each process and efficiently synchronizing the state. When it is determined that an instance will be destroyed, the cache record of the corresponding instance is deleted using the remove method, ensuring that the state data obtained by each process is consistent.

[0067] For example, during data synchronization triggered by broadcast (such as configuration updates), when the global configuration (such as the number of instances per process) is modified, the initiator sends a broadcast carrying a configuration update identifier. Each target process receives the broadcast, triggers a query, retrieves the latest configuration data, and completes local configuration synchronization. During broadcast-triggered data synchronization, the broadcast only transmits the update command; the specific configuration data is queried separately, avoiding performance degradation caused by broadcasting large amounts of data.

[0068] For example, during cross-process collaborative data transmission, the data sender stores the selected common text data in a temporary data table, generating a unique identifier ID. A broadcast is sent carrying this data ID to inform the receiver that new data is available to read. Upon receiving the broadcast, the data receiver queries the corresponding text data based on the ID, processes it, and then calls the `delete` method to delete the temporary data, avoiding redundancy.

[0069] Throughout the public data synchronization process, the core management class provides standardized interfaces such as insertApp (insert instance), queryApp (query instance), and removeApp (delete instance) to simplify cross-process data access. When transmitting command-type data, broadcasts carry key parameters (such as appId and data ID), and the actions are fixed to ensure consistent receiving logic across processes. Data sending operations run on the main thread by default. If a large amount of data querying or writing is involved, it is switched to the IO thread (Dispatchers.IO) via a coroutine to avoid blocking the UI thread.

[0070] During public data synchronization, data transmission supports batch querying and structured data storage, which is more efficient than file sharing, concisely encapsulated, and suitable for frequent query scenarios in lightweight applications with multiple processes. Relying on native Android system components, it implements cross-process communication at the underlying level, eliminating the need for manual serialization / deserialization handling and reducing data transmission anomalies. When adding new public data types, only the URI and data fields need to be extended; no modification to the transmission framework is required, ensuring compatibility with subsequent feature iterations.

[0071] The program execution method in the embodiments of this application can be further referred to Figure 2 The overall framework diagram presented as an example is used for understanding. Figure 2 The core hierarchy of the overall framework diagram shown is divided from top to bottom. The overall framework diagram is divided into four layers according to the calling relationship and functional responsibilities. Each layer of modules has its own responsibilities and depends on each other at each level, forming a complete closed loop.

[0072] The top-level host app layer serves as the entry point, with its core module being the KMM collaboration app. Its primary function is to act as the runtime environment for lightweight programs, providing user interaction entry points (such as a workbench). It triggers the startup of lightweight programs by calling the SDK entry class, acting as the container shell for the entire framework. The host app layer only directly interfaces with the next layer and does not participate in the internal logic of lightweight programs, ensuring a low coupling between the host app and the lightweight programs.

[0073] Below the host app layer is the SDK entry point and core module layer, whose core function is scheduling and support. The core modules are the SDK entry point and various core functional modules that implement various management functions, including multi-process and instance management, package management, and page management. The SDK entry point serves as the unified entry point, accepting calls from the host app and distributing startup requests to the corresponding core functional modules. These core functional modules cover key capabilities throughout the entire lifecycle of the lightweight application, including process scheduling, resource loading, communication, routing, and state management, forming the framework's central system. These core functional modules connect to the SDK entry point at the top and support resource initialization and execution at the runtime layer at the bottom. Modules can interact across layers (such as multi-process management and scheduling of the rendering / logic layer).

[0074] The runtime layer is the lowest-level execution layer. Its core modules include the rendering layer, logic layer, and native container-related components. Within these core modules, the rendering layer, through the lightweight application page, is responsible for UI rendering and user interaction display. The logic layer executes JavaScript through the engine, handling business logic, data calculations, and communication commands. The native container provides native components (Toast / ActionSheet) and utility classes (file I / O, network requests) to support the basic functionality of the lightweight application. The runtime layer relies on the core module layer for resource loading (package management), scheduling (multi-process management), and communication; it is the actual execution unit for the lightweight application.

[0075] Additionally, an auxiliary module layer may be included. This layer provides global assurance and primarily includes monitoring and logging. Core modules within the auxiliary module layer include logging and performance monitoring (APM). The auxiliary module layer does not participate in business logic execution; its core role is global monitoring and problem tracing, such as outputting runtime logs and collecting performance data (startup time, lag), ensuring system stability and debuggability. The runtime layer interfaces across layers with the core module layer and has no reverse dependencies; it is considered an external assurance system.

[0076] exist Figure 2The overall framework diagram shows that the responsibilities of each functional layer and module are clearly defined due to layered decoupling. Each module focuses only on its core responsibilities (e.g., the core module layer is responsible for scheduling, and the runtime layer is responsible for execution), and modules communicate with each other through standardized interfaces (e.g., process scheduling interfaces) to avoid functional coupling. For the host app, there is no need to worry about the process allocation of the lightweight program; it only needs to call the SDK entry point. The SDK entry point does not need to worry about page rendering; it only needs to schedule the multi-process management and package management modules.

[0077] The multi-process and instance management in the core module layer serves as the core of the framework, providing multi-process support and balancing isolation and efficiency during the execution of lightweight programs. By using a fixed number of processes, lightweight program instances can be run in isolation, and the crash of a single instance will not affect other modules or the host APP.

[0078] The rendering layer, logic layer, and process are bound to the runtime layer. Each process independently initializes the page and engine. Data security is ensured through process isolation, and process reuse is achieved through core module scheduling.

[0079] The core module layer encapsulates bidirectional cross-layer data communication between the rendering layer, logic layer, and native container. The logic layer calls native APIs, and the rendering layer passes page state, both relying on standardized interfaces.

[0080] Please refer to Figure 3 This is a flowchart illustrating the second program execution method provided in this application embodiment. In this application embodiment, based on the previous embodiment, it is explained that the preset program process is directly initialized in the electronic device, and subsequently scheduled directly from these processes during the use of the lightweight program. For example... Figure 3 As shown, the program running method in the embodiments of this application includes, but is not limited to, steps S210-S230.

[0081] Step S210: Initialize the preset program processes and configure independent running resources for each preset program process.

[0082] The default program process can be initialized when the electronic device starts running, or it can be initialized when any lightweight program's launch request is received. The allocation of runtime resources has been mentioned earlier and will not be elaborated upon here.

[0083] Step S220: When the lightweight program is started, determine the target process to be assigned to the currently started lightweight program based on the idle state of the preset program process.

[0084] In an optional implementation, the step of determining the target process for establishing an allocation relationship with the currently launched lightweight program based on the idle state of the preset program process when the lightweight program is launched includes: when the lightweight program is launched and there is an idle process in the preset program process, determining an idle process as the target process for establishing an allocation relationship with the currently launched lightweight program; when the lightweight program is launched and there is no idle process in the preset program process, releasing the allocation relationship of a preset program process and using it as the target process for establishing an allocation relationship with the currently launched lightweight program.

[0085] In another optional implementation, the step of releasing the allocation relationship of a preset program process includes: releasing the allocation relationship of the preset program process with the earliest most recent running time.

[0086] In another optional implementation, the step of removing the allocation relationship of the preset program process with the earliest most recent execution time among the preset program processes includes: determining the preset program process with the earliest most recent execution time from the preset program processes as the reassignment target; sending a shutdown command to the lightweight program that has an allocation relationship with the reassignment target to shut down the corresponding lightweight program.

[0087] Step S230: Run the lightweight program with allocation relationship uniquely using the running resources of the target process.

[0088] The above is an overall description of the second method of running the program. The following section will explain in detail the implementation process of the second method of running the program, taking into account specific application scenarios and exemplary lightweight program running requirements.

[0089] In the host APP (KMM Collaboration APP), configure 4 process shells (i.e., the default number is 4), and bind them to fixed process names: miniapp1~:miniapp4 respectively, and clarify the default rule of 1 process 1 instance (configured through miniAppConfig).

[0090] When the host app starts, it initializes four processes, each automatically allocated independent runtime resources. These resources include: memory space (each process has its own independent heap memory to avoid resource contention); a sandbox directory (each process has its own independent sandbox path, e.g., miniapp1 corresponds to / data / data / ... / mini_app / applet / user123 / app_id1 / ); core components (each process initializes its own dedicated engine instance, basic page components, and communication interfaces); and basic libraries (preloaded common basic libraries, stored in a separate directory for each process). The result of this initialization is that all four processes (miniapp1~4) are in an idle state, runtime resources are ready, and they are waiting for the lightweight app to start. At this point, the instance cache queue (appQueue) is empty.

[0091] The user clicks on the lightweight document annotation program (appId: ax123) on the KMM collaboration APP workbench. This is the first time the lightweight program is launched, and there are still idle processes. Querying the appQueue reveals that there are no launched instances, and the number of instances (0) < the process limit (4). Traversing the appShell (i.e., the process shell list), all processes are found to be idle. The first idle process shell is selected and bound to the target process: miniapp1. Next, the document annotation instance is launched through the independent resources of: miniapp1. The specific process includes: using the engine of: miniapp1 in the logic layer; using the page of: miniapp1 in the rendering layer for loading; and storing the instance data in the dedicated sandbox store directory of: miniapp1. To achieve process management, the instance information (appId: ax123, process identifier:: miniapp1, launch time: 10:00) also needs to be stored in the cache queue appQueue.

[0092] The user continues to click on the lightweight online translation program (appId: ax456). This is to start the second lightweight program, and there are still idle processes. Querying the appQueue, it is found that the number of instances (1) < 4, and the remaining three process shells in appShell are still idle. Allocate the second idle process shell, bind the target process: miniapp2, and use its independent resources to start the online translation instance. Store the instance information (appId: ax456, process ID: :miniapp2, start time: 10:05) into the appQueue. At this time, there are 2 instances in the appQueue. :miniapp1 and :miniapp2 are in running state, while :miniapp3 and :miniapp4 are still idle.

[0093] The user launches the contract signing (:miniapp3) and task management (:miniapp4) in sequence. At this time, all four processes are occupied (appQueue instance count = 4). Then, the user clicks the attendance check-in lightweight program (appId: ax789), which is the fifth lightweight program. At this time, there are no idle processes, so the process is reused. Querying the appQueue, it is found that the instance count (4) = the process limit (4), and there are no idle processes. In one optional implementation, the oldest instance destruction logic is executed, that is, the oldest instance at the head of the queue is taken out, which is the document annotation (startup time: 10:00). Then the host APP sends a broadcast with appId: ax123 to notify the :miniapp1 process to close the document annotation instance, release resources and clean up data accordingly, that is, reclaim the engine memory and page resources occupied by the instance; delete the temporary files in the sandbox temp directory, persist the business data in the store directory; and delete the document annotation instance from the appQueue.

[0094] The attendance check-in instance is launched using the independent runtime resources of this process (initialized engine, pages, sandbox directory), without the need to recreate the process and initialize basic resources. The new instance information (appId: ax789, process ID: :miniapp1, startup time: 10:30) is stored in the appQueue. At this time, the :miniapp1 process runs the attendance check-in, and the original document comment instance has been destroyed.

[0095] Additionally, it should be noted that the oldest instance destruction logic can also take the most recent usage time as a reference. Considering that users may use lightweight programs interchangeably, the earliest started lightweight program may be used multiple times later. After the fourth started lightweight program, it is possible that only the fourth started lightweight program is no longer used. In this case, the fourth started lightweight program (i.e., task management) can be directly cleaned up and released, and then allocated to the attendance check-in lightweight program.

[0096] Based on the above processing, each process's engine, page, and sandbox directory are completely independent. Although document annotations and attendance tracking reuse the `:miniapp1` process, runtime resources do not interfere with each other, and data storage is isolated. When reusing `:miniapp1`, the basic library (publicLib) and engine are pre-loaded, significantly shortening the startup time of a new instance compared to creating a new process, thus improving the user experience. Furthermore, reusing objects are selected by sorting by the most recent runtime, preventing critical lightweight programs from being accidentally destroyed.

[0097] Please refer to Figure 4This is a flowchart illustrating the third program execution method provided in this application. In this application embodiment, based on the preceding embodiments, it is explained that preset program processes are initialized one by one as the lightweight program is launched during the use of the electronic device. After the number of initialized preset program processes reaches a preset number, scheduling is performed directly from these processes during the use of the lightweight program. Figure 4 As shown, the program running method in the embodiments of this application includes, but is not limited to, steps S310-S330.

[0098] Step S310: If the number of preset program processes does not reach the preset number, a new preset program process is created as the target process to be assigned to the currently started lightweight program.

[0099] Step S320: When the number of preset program processes reaches a preset number, release the allocation relationship of one preset program process and use it as the target process to establish an allocation relationship with the currently started lightweight program.

[0100] In step S320, the step of releasing the allocation relationship of a preset program process includes: releasing the allocation relationship of the preset program process with the earliest most recent execution time among the preset program processes. In an optional implementation, releasing the allocation relationship of the preset program process with the earliest most recent execution time among the preset program processes includes: determining the preset program process with the earliest most recent execution time from the preset program processes as the reassignment target; sending a shutdown command to the lightweight program that has an allocation relationship with the reassignment target to shut down the corresponding lightweight program.

[0101] Step S330: Run the lightweight program with allocation relationship uniquely using the running resources of the target process.

[0102] The above is an overall description of the third method of running programs. The following section will provide a detailed explanation of the implementation process of the third method of running programs, taking into account specific application scenarios and exemplary lightweight program running requirements.

[0103] Taking the KMM Collaboration App as an example, which initializes four preset program processes (miniapp1~4) one by one, the process is not initialized in advance. Instead, a new process is dynamically created when a new lightweight program is launched, and the old process is reused when the number of launched lightweight programs reaches the preset number. The entire process is scheduled according to the number of processes and the idle state, which satisfies the needs of multiple instances in parallel while controlling resource consumption.

[0104] When starting the lightweight program, it first checks if the number of created processes has reached 4. If not, it creates a new process; if it has, it destroys the oldest instance and reuses its process. When creating a new process, it binds to a corresponding process shell. Each process shell is associated with a unique process name and automatically configures independent running resources (sandbox directory, engine, pages, etc.) after creation.

[0105] The user clicks on the lightweight document annotation program (appId: ax123) on the KMM Collaboration APP workbench. This is the first time the lightweight program is launched, and no preset program processes have been initialized yet. A query reveals that no processes or instances have been created (appQueue is empty). Checking that the number of processes (0) is less than the preset limit (4), the logic for creating a new process is executed, that is, the first process shell is selected and started, and the system automatically creates the corresponding :miniapp1 process. After the process is created, the independent running resources are automatically initialized: a dedicated sandbox directory is generated ( / data / data / ... / mini_app / applet / user123 / ax123 / ), the engine is started, and page components are initialized. The lightweight document annotation program resources are loaded, the instance is started, and the instance information (appId: ax123, process identifier: :miniapp1, start time: 9:00) is stored in the cache queue appQueue. At this time, the status is: the miniapp1 process has created and is running the document annotation instance, and the number of processes created = 1.

[0106] Users sequentially click on online translation (ax456), contract signing (ax789), and task management (ax012). Each launch triggers the same scheduling logic for the lightweight document annotation program. Before each launch, the number of created processes (1→2→3) is checked and found to be less than 4. Then, three new processes are created sequentially: miniapp2 (bound to the second process shell), miniapp3 (bound to the third process shell), and miniapp4 (bound to the fourth process shell). Each new process is configured with an independent sandbox directory, engine, and page, and runs its corresponding lightweight program instance. Instance information is stored sequentially in the appQueue. At this point, all four processes (:miniapp1~4) are created, each running one instance, bringing the total number of created processes to four, reaching the preset limit.

[0107] With all four processes occupied, if a user clicks on the lightweight attendance tracking app (appId: ax345), this launches the fifth lightweight app. At this point, the process limit is reached, so the process is reused. Checking the appQueue reveals that the number of created processes is 4 (reaching the limit), and there are no idle processes, so the process reuse logic is executed. The oldest instance is selected: the oldest instance at the head of the queue, namely the document annotation (startup time: 9:00, process ID: :miniapp1). Then, the host app sends a broadcast with appId: ax123, notifying the :miniapp1 process to close the document annotation instance, releasing engine memory, cleaning sandbox temporary files, persisting business data, and deleting the instance's cache.

[0108] Without needing to recreate the process (the process shell already exists), the attendance check-in instance is launched directly using the independent runtime resources of the :miniapp1 process (the initialized sandbox directory, engine, and pages). The dedicated resource package for attendance check-in is loaded, the instance cache is updated, and the new instance information (appId: ax345, process ID: :miniapp1, startup time: 10:30) is stored in the appQueue. At this point, the :miniapp1 process is successfully reused and the attendance check-in instance is running. Other processes (:miniapp2~4) continue to run their original instances, maintaining a total of four created processes.

[0109] It should be understood that, as described above, the oldest instance destruction logic can also take the most recent usage time as a reference, directly clean up the lightweight program that has not been used for the longest time, and allocate it to the attendance check-in lightweight program.

[0110] In this embodiment, there is no need to pre-initialize the process, avoiding resource consumption when starting the host app. It is created only when needed, adapting to scenarios with low-frequency, lightweight program startup. Even when reusing processes, each process's sandbox directory, engine, and pages remain independent, and the data of new instances is completely isolated from the data of destroyed instances, conforming to document sandbox design. When reusing processes, basic resources (engine, basic library) do not need to be re-initialized, and the startup time of a new instance is significantly shorter than that of a newly created process, improving the user experience.

[0111] Based on the above processing steps and the development, testing, and operation of the lightweight program, it can be seen that the program operation method in this embodiment is developed using a layered architecture of the lightweight program platform. The overall framework clearly defines the rendering layer, logic layer, and core module layer, with clear module responsibilities. Developers do not need to worry about low-level logic such as cross-process communication and thread switching, and can focus on business function development. Furthermore, it provides standardized interfaces such as JSBridge encapsulation and native component APIs, eliminating the need for redevelopment of communication between the logic layer and the rendering layer and native containers; data transfer can be achieved simply by calling preset interfaces. The ratio of processes to instances can be flexibly adjusted according to the type of lightweight program (lightweight tools / high-security office), adapting to different needs without refactoring the architecture during development. A sandbox directory hierarchical storage design avoids data conflicts during development.

[0112] During testing, the logic layer supports debugging engine scripts, and the rendering layer allows direct debugging of the page. In multi-process scenarios, it can distinguish between miniapp processes 1-4, accurately locating cross-process and cross-layer bugs. The APM performance monitoring module collects data such as startup time, lag, and resource usage, allowing for intuitive identification of performance bottlenecks (such as JS thread blocking and low process reuse efficiency) during testing. Furthermore, the solution is compatible with different system versions and browser versions, and the debugger supports multi-environment adaptation, enabling verification of the lightweight program's stability across different devices and browsers during testing.

[0113] During the operation of lightweight programs according to the embodiments of this application, the process reuse mechanism avoids frequent process creation, the preloading of basic libraries reduces redundant resource loading, and the startup speed of new instances is faster than that of a single-process architecture, reducing user waiting time. The multi-process isolation design ensures that the crash of a single lightweight program only affects its own process and will not cause the host APP or other instances to crash; the combination of broadcast instructions and resource release also effectively avoids memory leaks. Limiting the process limit also prevents too many processes from consuming system resources, and the single-process multi-instance configuration allows lightweight programs to share basic resources, balancing performance and resource consumption. Through cross-process public data transmission, collaboration between lightweight programs is supported (e.g., document annotation → online translation), and data isolation ensures privacy and security.

[0114] In an optional implementation, while the above implementation program is running, the running process of the layer in the thread can be further monitored; the thread containing the layer whose running process meets the preset sleep trigger condition is switched to sleep state.

[0115] In the example description above, the lightweight program is divided into at least three layers: a rendering layer, a logic layer, and a native container. Each layer is bound to an independent thread within the target process (e.g., the rendering layer corresponds to the UI thread, the logic layer corresponds to the JS thread, and the native container corresponds to the IO thread). Multiple threads within the target process share the process's runtime resources, but each thread has an independent execution context. The state switching of a single thread (e.g., sleeping) will not affect the operation of other threads or the entire process. A thread is the dedicated execution unit of a lightweight program layer, and the execution process of a layer depends entirely on the execution of instructions from the corresponding thread. The two are bound one-to-one.

[0116] During the monitoring of the layer's operation in its corresponding thread, real-time monitoring is employed throughout the entire process. This monitoring can be performed by the thread monitoring module of the lightweight application platform, covering the entire lifecycle of the layer's operation. Monitoring content may include, but is not limited to: the layer's business execution status, i.e., whether there is active user interaction (such as page clicks in the rendering layer, business logic calculations in the logic layer, and file read / write / network requests in the native container); the thread's resource usage status, i.e., the corresponding thread's CPU utilization, memory usage, and instruction execution frequency (such as whether the JS thread is executing scripts, or whether the IO thread is transmitting data); the layer's event triggering status, i.e., whether external events (such as instructions from the host APP, or communication instructions from other layers) trigger the layer's business logic; and the thread's ready status, i.e., whether the thread is in a cycle between ready and running states, or in an idle waiting state without instruction execution. Specifically, monitoring can be implemented by combining the operating system's thread scheduling interface with a custom monitoring script from the lightweight application platform to sample thread operation metrics (sampling frequency is configurable, such as 100ms / time), and the sampled data is synchronized in real-time to the thread monitoring module's status cache, providing data for subsequent sleep determination.

[0117] To determine whether the running process meets the preset sleep triggering conditions, the thread monitoring module can match the sampled monitoring data with the preset sleep triggering conditions. If any condition is met, it is determined that sleep needs to be triggered. The sleep triggering conditions are a combination of thresholds / states that can be configured by the platform. In this embodiment of the application, combined with the application scenario of lightweight programs, the preset sleep triggering conditions can be a single condition or a combination of multiple single conditions. Optional single conditions include: idle time threshold, i.e., the duration for which the corresponding thread of a layer has no continuous execution of any business instructions, no user interaction, and no external event triggering reaches a preset value (e.g., 5s, 10s; the threshold can be shorter for lightweight utility programs and slightly longer for office applications); resource usage threshold, i.e., the thread's CPU usage rate is continuously sampled below a preset value (e.g., 5%) and memory usage does not increase, indicating that the thread has no effective workload; business scenario trigger, i.e., after the layer completes its current core business logic, there are no subsequent tasks to be executed (e.g., after the native container completes a network request, there are no new request instructions; after the rendering layer completes page rendering, there are no page refresh / interaction instructions); host APP instruction trigger, i.e., the host APP sends a low-power scheduling instruction, requiring idle layer threads to sleep. The design of sleep trigger conditions needs to consider that sleep trigger conditions only apply to idle layer threads and will not trigger sleep for threads that are executing business logic, ensuring that the normal business operation of the lightweight program is not affected.

[0118] When a running process is determined to meet the sleep trigger conditions, the thread containing that layer can be switched to a sleep state. This state switching can be accomplished collaboratively by the operating system's thread scheduler and the thread state management module of the lightweight application platform. The thread state management module sends a sleep command to the thread scheduler, which then performs the actual state switch. During the switch, the thread's current execution context (such as the program counter, register data, and unfinished temporary instructions) is first saved to ensure restoration to the pre-sleep state upon subsequent wake-up. Then, the thread is removed from the operating system's ready queue and placed in the sleep queue, CPU time slice allocation to the thread is paused, and instruction execution is stopped. Finally, non-core resources temporarily occupied by the thread (such as temporary memory cache and file handles) are released, retaining only the basic resources and context data for layered operation. Under this processing logic, the sleep of a single layered thread only affects the corresponding layer; other threads within the target process (e.g., if a logic layer thread sleeps, the rendering layer thread continues to run normally) and the entire process remain unaffected. Sleeping threads do not consume CPU resources, only a small amount of memory for storing context, significantly reducing system resource consumption.

[0119] In another alternative implementation, in addition to state switching, the process to which the dormant thread belongs can be restarted or shut down based on the usage status of the lightweight program that has an allocation relationship with the process to which the dormant thread belongs.

[0120] Based on the monitored usage status of the lightweight program, a two-option scheduling strategy is determined: restart and shutdown are mutually exclusive strategies, corresponding to different usage scenarios.

[0121] When the usage status of a lightweight application meets any of the following exemplary conditions, a process shutdown operation can be performed. The core purpose is to completely reclaim the process's runtime resources: all threads corresponding to all layers of the lightweight application are in a dormant state, and the dormant duration reaches the preset process shutdown threshold (e.g., 30 seconds, 1 minute), with no user interaction or external event triggering; the user has actively exited the lightweight application's interactive interface, and the lightweight application has no background business logic to be executed (e.g., no background network requests, data calculations); the instance of the lightweight application is confirmed to be in a state to be destroyed, or the host APP has sent a shutdown command for the lightweight application; the dormant thread ratio in the target process reaches 100%, and the overall idle time of the lightweight application exceeds the preset value, indicating that the user will not use it again in the short term.

[0122] When the lightweight application's usage state meets any of the following exemplary conditions, a process restart operation can be performed. The core purpose is to repair the abnormal state of the process and restore the normal operating efficiency of the lightweight application: The lightweight application still has user interaction needs (e.g., a user clicks on the lightweight application interface), but multiple hierarchical threads within the target process are in a dormant state, and waking from dormancy fails (e.g., unable to restore thread context, thread unresponsive after waking); The target process has dormant threads, and the process itself exhibits minor operational anomalies (e.g., memory leaks, slow increase in resource consumption, thread scheduling lag), but the lightweight application still has usage needs; restarting the process can repair the anomalies; Some hierarchical threads of the lightweight application are dormant, while others are running normally, but resource scheduling conflicts occur within the process (e.g., basic resources occupied by dormant threads cannot be accessed by normally running threads); restarting the process can reinitialize resources and restore scheduling order; After the platform performs low-power scheduling, the dormant state of the process's threads causes a significant decrease in the lightweight application's response speed (e.g., the response time of user operations exceeds a preset threshold); restarting the process can reinitialize threads and improve response efficiency.

[0123] The specific restart or shutdown process can be found in the details of process lifecycle handling in related technologies, and will not be elaborated here. In this embodiment, long-term idle processes are shut down to fully reclaim system resources, avoid excessive system load caused by processes occupying resources idly, and improve the overall operating efficiency of electronic devices; abnormally dormant processes are restarted to fix process running abnormalities, restore the responsiveness and stability of the lightweight program, and solve the lag and unresponsiveness problems caused by thread dormancy; process scheduling is performed based on the actual usage status of the lightweight program, taking into account resource conservation and user experience, avoiding meaningless process restarts / shutdowns, ensuring the normal use of the lightweight program, and achieving optimized allocation of system resources.

[0124] Overall, in this program execution method, a target process that establishes an allocation relationship with the lightweight program is determined from preset program processes. Each preset program process has independent runtime resources. The lightweight program with the allocation relationship is uniquely executed using the runtime resources of the target process. By limiting the number of preset program processes and ensuring that the target process with the allocation relationship exclusively occupies runtime resources during the execution of the lightweight program, process-level isolation between different lightweight programs is achieved. A crash in a single lightweight program only affects its own process and will not cause abnormalities in the host app or other lightweight programs, thus ensuring overall operational stability. Each process uniquely executes its corresponding lightweight program, avoiding conflicts caused by multiple instances sharing process resources and improving the independence and reliability of lightweight program execution.

[0125] Please refer to Figure 5 This is a schematic diagram of the structure of a program running device provided in an embodiment of this application, such as... Figure 5 As shown, the program running device includes a process allocation unit 510 and a process running unit 520.

[0126] The process allocation unit 510 is used to determine the target process that establishes an allocation relationship with the lightweight program from the preset program processes, and each of the preset program processes has independent running resources; the process running unit 520 is used to uniquely run the lightweight program with the allocation relationship through the running resources of the target process.

[0127] Based on the above embodiments, the program running device further includes: An initialization unit is used to initialize the preset program processes before determining the target process to be allocated to the lightweight program from the preset program processes, and to configure independent running resources for each preset program process.

[0128] Based on the above embodiments, the process allocation unit 510 includes: The allocation module is used to determine the target process to be allocated to the currently running lightweight program based on the idle state of the preset program process when the lightweight program is started.

[0129] Based on the above embodiments, the allocation module is activated, including: The first allocation submodule is used to determine an idle process as the target process for establishing an allocation relationship with the currently launched lightweight program when the lightweight program is started and there is an idle process in the preset program process. The second allocation submodule is used to release the allocation relationship of a preset program process when the lightweight program is started and there is no idle process in the preset program process, and use it as the target process to establish an allocation relationship with the currently started lightweight program.

[0130] Based on the above embodiments, the process allocation unit includes: The process creation module is used to create a new preset program process as the target process to be allocated to the currently started lightweight program when the number of preset program processes does not reach the preset number. The reallocation module is used to, when the number of preset program processes reaches a preset number, release the allocation relationship of one preset program process and use it as the target process to establish an allocation relationship with the currently started lightweight program.

[0131] Based on the above embodiments, the step of releasing the allocation relationship of a preset program process includes: Remove the allocation relationship of the preset program process with the earliest most recent execution time from the preset program processes.

[0132] Based on the above embodiments, the allocation relationship of the preset program process with the earliest most recent execution time is released from the preset program process, including: The preset program process with the earliest most recent execution time among the preset program processes is selected as the reallocation target; Send a shutdown command to the lightweight program that has an allocation relationship with the redistribution target to shut down the corresponding lightweight program.

[0133] Based on the above embodiments, the process execution unit 520 includes: The multi-instance running module is used to ensure that, when the lightweight program includes at least two instances, the running resources of the target process with an allocation relationship are used to run the lightweight program uniquely, while the instances share basic resources and isolate instance data.

[0134] Based on the above embodiments, the target process includes at least two threads that execute in parallel, and the threads share the running resources of the corresponding target process.

[0135] Based on the above embodiments, the lightweight program includes at least two layers; the layers run through different threads in the target process.

[0136] Based on the above embodiments, the layering includes a rendering layer, a logic layer, and a native container.

[0137] Based on the above embodiments, the program running device further includes: The process monitoring unit is used to monitor the execution process of the layer in the thread; The state switching unit is used to switch the thread of the layer whose operation process meets the preset sleep trigger conditions to a sleep state.

[0138] Based on the above embodiments, the program running device further includes: The process adjustment unit is used to restart or shut down the process to which the dormant thread belongs, based on the usage status of the lightweight program that has an allocation relationship with the process to which the dormant thread belongs.

[0139] Based on the above embodiments, the program running device further includes: The data transmission unit is used to transmit specified public data between the target processes through a preset interface.

[0140] Based on the above embodiments, the program running device further includes: A data caching unit is used to cache instance data of the lightweight program when the lightweight program is started. The cache cleanup unit is used to delete the instance data of the lightweight program when the lightweight program is closed.

[0141] The program running device provided in this embodiment of the invention is included in an electronic device and can be used to execute any of the program running methods provided in the above embodiments, and has corresponding functions and beneficial effects.

[0142] It is worth noting that in the embodiments of the above-mentioned program running device, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of the present invention.

[0143] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device includes a processor 610 and a memory 620. In one possible form of the electronic device, it may also include an input device 630, an output device 640, and a communication device 650. The number of processors 610 in the electronic device can be one or more. Figure 6 Taking a processor 610 as an example; the processor 610, memory 620, input device 630, output device 640, and communication device 650 in the electronic device can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0144] The memory 620, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the program execution method in the embodiments of this application. The processor 610 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory 620, thereby implementing the above-described program execution method.

[0145] The memory 620 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 620 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 620 may further include memory remotely located relative to the processor 610, which can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0146] Input device 630 can be used to receive network configuration information. Output device 640 may include electronic devices such as a display screen.

[0147] The aforementioned electronic devices can be used to execute any program running method and have corresponding functions and beneficial effects.

[0148] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and equipment can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0149] Furthermore, embodiments of this application also provide a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are used to perform relevant operations in the program running method provided in any embodiment of this application, and have corresponding functions and beneficial effects.

[0150] Those skilled in the art will understand that embodiments of this application may be provided as methods, systems, or computer program products.

[0151] Therefore, this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may 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. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should 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, produce implementations of the flowchart... Figure 1 One or more processes and / or boxes Figure 1 The 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 operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. 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, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0152] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent memory 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.

[0153] 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 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.

[0154] 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 process, method, article, or apparatus. Unless otherwise specified, 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 that element.

[0155] The above specific embodiments have further detailed the purpose, technical solution, and beneficial effects of this application. It should be understood that the above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application for those skilled in the art.

Claims

1. A program execution method characterized by comprising: include: The target process that establishes an allocation relationship with the lightweight program is determined from the preset program processes, wherein each of the preset program processes has independent running resources; The target process uniquely runs a lightweight program with allocation relationships using its runtime resources.

2. The program execution method according to claim 1, wherein Before determining the target process from the preset program processes that establishes an allocation relationship with the lightweight program, the process further includes: Initialize the preset program processes and configure independent running resources for each preset program process.

3. The program execution method according to claim 2, wherein The step of determining the target process from the preset program processes that establishes an allocation relationship with the lightweight program includes: When the lightweight program is started, the target process that establishes an allocation relationship with the currently started lightweight program is determined based on the idle state of the preset program process.

4. The program execution method according to claim 3, wherein When the lightweight program is started, determining the target process to establish an allocation relationship with the currently started lightweight program based on the idle state of the preset program process includes: When the lightweight program is started and there is an idle process in the preset program process, an idle process is determined as the target process to establish an allocation relationship with the currently started lightweight program. If the lightweight program is started and there are no idle processes in the preset program processes, the allocation relationship of one preset program process is terminated, and it is used as the target process to establish an allocation relationship with the currently started lightweight program.

5. The program execution method according to Claim 1, wherein The step of determining the target process from the preset program processes that establishes an allocation relationship with the lightweight program includes: If the number of preset program processes does not reach the preset number, a new preset program process is created as the target process for establishing an allocation relationship with the currently launched lightweight program. When the number of preset program processes reaches a preset number, the allocation relationship of one preset program process is terminated, and it is used as the target process to establish an allocation relationship with the currently launched lightweight program.

6. The program execution method according to claim 4 or 5, characterized by, The process of releasing the allocation relationship of a preset program process includes: Remove the allocation relationship of the preset program process with the earliest most recent execution time from the preset program processes.

7. The program execution method according to claim 6, wherein The step of removing the allocation relationship of the preset program process with the earliest most recent execution time in the preset program processes includes: The preset program process with the earliest most recent execution time is determined from the preset program processes and used as the reallocation target; Send a shutdown command to the lightweight program that has an allocation relationship with the redistribution target to shut down the corresponding lightweight program.

8. The program execution method according to any one of claims 1 to 5, characterized by, The process of uniquely running a lightweight program with allocation relationships through the runtime resources of the target process includes: When the lightweight program includes at least two instances, during the process of the target process with an allocation relationship running the lightweight program exclusively, the instances share basic resources and isolate instance data.

9. The program execution method according to any one of claims 1 to 5, characterized by, The target process includes at least two threads that execute in parallel, and the threads share the runtime resources of the corresponding target process.

10. The program executing method according to Claim 9, wherein The lightweight program comprises at least two layers; the layers run through different threads in the target process.

11. The program executing method according to Claim 10, wherein The layering includes a rendering layer, a logic layer, and a native container.

12. The program execution method according to claim 10, wherein Also includes: Monitor the execution process of the layer within the thread; The thread containing the layer whose operation meets the preset sleep trigger conditions is switched to sleep state.

13. The program execution method according to claim 12, characterized in that, Also includes: Based on the usage status of lightweight programs that have an allocation relationship with the process to which the dormant thread belongs, restart or shut down the process to which the dormant thread belongs.

14. The program execution method according to any one of claims 1-5, characterized in that, Also includes: Specified public data is transmitted between the target processes through a preset interface.

15. The program execution method according to any one of claims 1-5, characterized in that, Also includes: When the lightweight program is started, cache the instance data of the lightweight program; If the lightweight program is turned off, delete the instance data of the lightweight program.

16. A program execution device, characterized in that, include: A process allocation unit is used to determine the target process that establishes an allocation relationship with the lightweight program from the preset program processes, wherein each of the preset program processes has independent running resources; The process execution unit is used to uniquely run a lightweight program with an allocation relationship using the execution resources of the target process.

Images