Application starting method and device

Abstract

Embodiments of the present application provide an application starting method and device, and relate to the technical field of computers. The method comprises: before receiving a user operation indicating starting a first application, creating a first process of the first application and writing a first IO file of the first application to the first process. When the user indicates starting the first application, the first process with the first IO file is executed to display an application interface of the first application. The first IO file is a file required to be loaded when starting the first application. In this way, when the user starts the first application, the time for creating a process and loading the first IO file after receiving the user operation is saved, the starting delay of the application is shortened, the starting process of the application is accelerated, and the user experience is good.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an application launch method and apparatus. Background Technology

[0002] With the development of edge devices and cloud devices, various applications can be installed on each device (edge ​​device or cloud device). The response speed of the applications has become a key factor affecting system performance. In order to improve system performance, it is necessary to shorten the startup latency of applications.

[0003] Currently, one related technology offers a scheme to shorten operating system recovery latency and improve operating system restart speed by preloading files. For example, this technology analyzes user file usage habits to pre-read frequently accessed files from the disk and stores these files in a hibernation file within shared memory, thus preloading frequently accessed files. When the operating system resumes from hibernation, it can access these preloaded files from shared memory, reducing disk access.

[0004] However, when faced with application startup scenarios, the above solutions cannot effectively improve application startup speed, resulting in longer application startup latency. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides an application startup method. In this method, before receiving a user instruction to start the application, an empty process for the application is created, and the IO file required to start the application is written to this process. Thus, upon receiving a user instruction to start the application, only the process containing the written IO file needs to be executed to display the application's startup interface. Therefore, upon receiving the aforementioned instruction, there is no need to create a new application process or load the corresponding IO file into the process, shortening the application startup latency, accelerating the application startup process, and providing a better user experience.

[0006] In a first aspect, embodiments of this application provide an application startup method. The method includes: receiving a user operation instructing the startup of a first application; prior to receiving the user operation, creating a first process for the first application and writing a first I / O file corresponding to the first application to the first process, wherein the first process is an empty process upon creation; and in response to the user operation, executing the first process to display the application interface of the first application, wherein the application interface is the startup interface of the first application, and the first I / O file is a file required to be loaded when starting the first application.

[0007] In some embodiments, the first IO file is an IO file that supports pre-fetching before the first application starts. For example, the first IO file is an IO file and is not a temporary file generated during the boot process.

[0008] In existing technology, only after receiving the user's operation will the first process for creating the first application and the first I / O file corresponding to the first application be executed sequentially to complete the application startup. Thus, after the user inputs the instruction to start the application, it is necessary to wait for the complete execution of creating the first process and writing the first I / O file before the application interface can be displayed. This results in a relatively long application startup delay.

[0009] The application startup process requires reading certain I / O files to ensure its execution. In existing technologies, the necessary I / O files are read from the disk in real-time and added to the memory of the created process to start the application. However, this real-time reading of I / O files from the disk during startup takes a considerable amount of time, thus increasing the overall startup time. Furthermore, the reading of I / O files is based on the current execution progress of the application startup process, rather than reading all the necessary I / O files at once. This means that at different stages of the application startup process, multiple reads of I / O files from the disk may be required, further extending the overall startup time.

[0010] Alternatively, in existing technologies, before receiving a user instruction to launch the application, the application's I / O file can be pre-read into shared memory. Then, after receiving the user instruction, the application process is created, and subsequently, the I / O file required to launch the application is read from shared memory and written into the application process's memory. This process, after the user inputs the instruction to launch the application, requires waiting for process creation and the reading of the I / O file from shared memory, resulting in a longer application startup latency.

[0011] Unlike existing technologies, this application's embodiments, before receiving a user operation instructing the user to launch the first application, can create a process for the first application and write the IO files required to launch the first application into the application's process. After receiving the user operation, the method of this application only needs to execute the process to display the application's startup interface, thereby completing the application launch. Thus, in the process of launching the application in response to a user operation, the method of this application does not need to create an application process because the process has already been created before receiving the user operation; and in the process of launching the application in response to a user operation, the method of this application's embodiments does not need to read the application's IO files from shared memory into the application's process because the application's IO files have already been written into the application's process before receiving the user operation. This avoids the operation of reading the application's IO files from shared memory into the application's process, thereby speeding up the application launch, shortening the application launch latency, reducing the user's waiting time for the application to launch, and improving the user experience.

[0012] In one possible implementation, during the execution of the first process, the first process is the main process of the first application.

[0013] In this embodiment of the application, after receiving the user's operation, the first process is executed. At this time, the first process is the main process of the first application. The operating system will allocate the resources required for the execution of the first process (such as CPU resources, memory resources, etc.) to the first process, so that the first process can be executed to start the first application.

[0014] In one possible implementation, before receiving a user operation, the method further includes: obtaining an application list, which includes multiple applications, including a first application and a second application; creating a second process for the second application and writing a second IO file corresponding to the second application to the second process, wherein the second process is an empty process when it is created.

[0015] In this embodiment, the application list may include multiple applications. Before receiving a user operation instructing the user to launch an application from the application list, an empty process is created for each of the multiple applications, and the corresponding IO file for that application is written to the empty process. This accelerates the launch of multiple applications in the application list. After receiving a user operation instructing the user to launch any application from the application list, the method of this application only needs to respond to the user operation by executing the process corresponding to that application with the attached IO file. During the launch of any application from the application list, it is not necessary to create a process for that application, nor is it necessary to read the process's IO file from the disk into the process's memory, nor is it necessary to read the application's IO file from shared memory into the application's process. This solution can reduce the launch latency of multiple applications in the application list in batches, thereby improving the launch speed of multiple applications.

[0016] In one possible implementation, before receiving the user operation and after obtaining the application list, the method further includes: loading a common subprocess between the first application and the second application, which is a process that both the first application and the second application need to load when they start, and the first process is used to start the first application based on the subprocess.

[0017] In this embodiment of the application, after receiving a user operation to launch any application in the application list, the method of this embodiment does not need to execute the entire application launch process in response to the user operation, such as launching the first application or the second application, because the operations of some sub-processes have been completed before receiving the user operation. This reduces the sub-process loading process of each application in the application list during the launch process, further reducing the application-side phase time of each application in the application list during the launch process, thereby achieving a batch reduction in the launch latency of each application in the application list.

[0018] In one possible implementation, obtaining the application list includes: using an artificial intelligence (AI) model, based on user historical data, predicting k applications that the user expects to launch in a future time period, where k ≥ 2 and k is an integer, the user historical data indicating the historical usage data of the candidate applications, the candidate applications including the k applications; and obtaining the application list based on the k applications.

[0019] In this embodiment, an AI model can be used to predict multiple applications that a user expects to launch in the future based on historical user data. This AI model can accurately predict the k applications the user is likely to launch in the future. Then, based on these k applications, a list of applications for accelerated launch is obtained. Before receiving a user's instruction to launch any application from this list, the processes for the applications the user is likely to use in the future are created in advance, and the necessary I / O files for launching these applications are mounted to the corresponding processes. Optionally, child processes shared by these applications can also be preloaded. Thus, after receiving the user's instruction, the application can be launched directly based on the created application process and the I / O files mounted to that process, without needing to create the process and read the I / O files after receiving the user's instruction. This reduces the application launch latency and improves the application launch speed for multiple applications the user is likely to launch in the future.

[0020] In one possible implementation, the application list is obtained based on the k applications, including: selecting multiple applications from the k applications based on the device's remaining memory information and the memory usage data of the k applications to obtain the application list.

[0021] In this embodiment, when obtaining the application list based on the k applications, some or all applications can be selected from the k applications based on the device's remaining memory and the memory usage of the k applications to obtain the application list for accelerated startup. Because in the method for accelerating application startup, before receiving an instruction to start the application, a certain amount of memory space needs to be sacrificed so that the memory occupied by the application process is filled with I / O files. Therefore, in the scenario of accelerating the startup of multiple applications in the application list, to avoid excessive memory usage, all or some applications can be reasonably selected from the k applications to form the application list based on the potential memory size occupied by the k applications and the device's remaining memory. This not only accelerates the startup of multiple applications in the application list but also avoids excessive memory usage and memory lag issues, thus providing a more stable application running experience.

[0022] In one possible implementation, obtaining the application list includes: obtaining the application list at specified intervals.

[0023] In this embodiment, considering that the applications users expect to launch may differ at different times, periodically obtaining the application list ensures that the periodically obtained application list better matches the user's expectations for future applications. Thus, as time progresses, the application list obtained by the method of this embodiment may change compared to the previous period, allowing the application list to dynamically change as the applications that may be launched in future time periods change. This increases the probability that applications that preload processes and pre-fetch files are applications that users expect to launch in the future, thereby avoiding the waste of memory space caused by pre-fetching files and improving memory utilization.

[0024] In one possible implementation, the method further includes: identifying a third application that exists in the application list obtained in the previous cycle but not in the application list obtained in the current cycle; and reclaiming the memory occupied by the third application.

[0025] In some embodiments, the duration of the specified period is the duration of a future time period.

[0026] In the embodiments provided in this application, the applications whose memory is reclaimed are those that exist in the application list obtained in the previous cycle but not in the application list obtained in the current cycle. These applications have a low probability of being launched by users in the future. Reclaiming the memory of these applications with a low probability of launch can free up memory, avoid excessive memory occupation, reduce memory pressure, and allow other running applications to use memory more efficiently, thereby improving the overall performance of the system. At the same time, clearing memory fragments can keep the memory layout more compact and orderly, and can better allocate memory when a large amount of contiguous memory space is required.

[0027] In one possible implementation, the third application differs from the foreground application.

[0028] In the embodiments provided in this application, the third application differs from the foreground application, thus avoiding the reclamation of the foreground application's memory and preventing any impact on the user experience. Furthermore, frequent reclamation of the foreground application's memory can lead to system instability, increasing the probability of application crashes or anomalies. By protecting the foreground application from memory reclamation, these problems can be reduced, enhancing the overall stability of the system.

[0029] Secondly, embodiments of this application provide an application launch device. The device includes: a preprocessing module, configured to receive a user operation instructing the launch of a first application; prior to receiving the user operation, creating a first process for the first application and writing a first I / O file corresponding to the first application to the first process; the first process is an empty process upon creation; and a launch module, configured to, in response to the user operation, execute the first process to display the application interface of the first application, the application interface being the launch interface of the first application, wherein the first I / O file is a file required to be loaded when launching the first application.

[0030] In one possible implementation, during the execution of the first process, the first process is the main process of the first application.

[0031] In one possible implementation, before receiving a user operation, the device further includes: an acquisition module for acquiring an application list, the application list including multiple applications, the multiple applications including a first application and a second application; and a preprocessing module for creating a second process of the second application and writing a second IO file corresponding to the second application to the second process, the second process being an empty process at creation.

[0032] In one possible implementation, before receiving the user operation and after obtaining the application list, the device further includes a loading module for loading a common subprocess between the first application and the second application, the subprocess being a process that both the first application and the second application need to load when they start, and the first process being used to start the first application based on the subprocess.

[0033] In one possible implementation, the acquisition module is specifically used to: predict, using an AI model and based on the user's historical data, the k applications that the user expects to launch in a future time period, where k ≥ 2 and k is an integer, the user's historical data indicating the historical usage data of the candidate applications, and the candidate applications including the k applications; and obtain the application list based on the k applications.

[0034] In one possible implementation, the acquisition module is specifically used to: select multiple applications from the k applications based on the device's remaining memory information and the memory usage data of the k applications, in order to obtain the application list.

[0035] In one possible implementation, the acquisition module is specifically used to: acquire a list of applications at specified intervals.

[0036] In one possible implementation, the device further includes: a determination module for determining a third application, which exists in the application list obtained in the previous cycle but not in the application list obtained in the current cycle; and a recycling module for recycling the memory occupied by the third application.

[0037] In one possible implementation, the third application differs from the foreground application.

[0038] The effects of launching the application interface using the above-mentioned implementation methods are similar to those of the application launch method in the first aspect or any of the implementation methods in the first aspect, and will not be elaborated further here.

[0039] Thirdly, this application provides a cloud-side device, which includes a processor and a memory. The processor executes programs or instructions stored in the memory to enable the cloud-side device to implement the methods in any of the above implementations.

[0040] The effect of the cloud-side device in this implementation is similar to that of the application startup method in the first aspect or any of the implementations of the first aspect, and will not be elaborated here.

[0041] Fourthly, this application provides an edge device including a processor and a memory, wherein the processor executes a program or instructions stored in the memory to cause the edge device to implement the method in any of the above implementations.

[0042] The effect of the end-side device in this implementation is similar to that of the application startup method in the first aspect or any of the implementations of the first aspect, and will not be elaborated here.

[0043] Fifthly, this application provides an application launching device. The application launching device includes a processor configured to execute instructions, which, when executed by the processor, perform the method described in any of the above implementations.

[0044] In some implementations, the application launching device includes a memory that can store instructions, which, when executed by the processor, are used to perform the methods in any of the above implementations.

[0045] In some other implementations, the application launch device includes one or more interface circuits; the interface circuits are used to receive signals from memory and send the signals to the processor, the signals including instructions stored in memory; when the processor executes the instructions, the processor is used to perform the method in any of the above implementations.

[0046] The effect of the application launch device in this implementation is similar to that of the application launch method in the first aspect or any of the implementations of the first aspect, and will not be described again here.

[0047] Sixthly, this application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program that, when executed on a computer or processor, causes the computer or processor to perform the methods described in any of the above implementations.

[0048] The effect of the computer-readable storage medium of this implementation is similar to that of the application startup method of the first aspect or any implementation of the first aspect, and will not be repeated here.

[0049] Seventhly, this application provides a computer program product. The computer program product includes a software program, which, when executed by a computer or processor, causes the method in any of the above implementations to be performed.

[0050] The effect of the computer program product of this implementation is similar to that of the application startup method of the first aspect or any implementation of the first aspect, and will not be described again here.

[0051] Eighthly, this application provides a chip. The chip includes a processor and a communication interface, the processor being used to call and execute instructions from the communication interface, and when the processor executes the instructions, it implements the method in any of the above implementations.

[0052] The effect of the chip implemented in this way is similar to that of the application startup method of the first aspect or any of the implementations of the first aspect, and will not be described again here. Attached Figure Description

[0053] Figure 1 This is a schematic diagram of the structure of an end-side device provided in an embodiment of this application;

[0054] Figure 2 This is a schematic diagram of the software structure of an end-side device provided in an embodiment of this application;

[0055] Figure 3 A flowchart illustrating an application startup method provided in an embodiment of this application;

[0056] Figure 4 A schematic diagram comparing the flow of an application startup method provided in this application embodiment with an existing application startup flow;

[0057] Figure 5 A flowchart illustrating another application launch method provided in an embodiment of this application;

[0058] Figure 6 A schematic diagram illustrating a memory reclamation process provided in an embodiment of this application;

[0059] Figure 7 This is a schematic diagram of the structure of an application launch device provided in an embodiment of this application;

[0060] Figure 8 This is a schematic diagram of another application launch device provided in an embodiment of this application. Detailed Implementation

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

[0062] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0063] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0064] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0065] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0066] Before describing the technical solutions of the embodiments of this application, a brief introduction to the technical background and technical terms involved in the embodiments of this application will be given first.

[0067] Application warm start: A warm start refers to launching an application while it is already running. In other words, it's the process of launching an application when a user reopens it, or when the application has already loaded some data. For example, if an application is brought back from the background to the foreground, the user can directly resume the previous screen after opening the application. In this case, since the application is already in memory, some loaded files may still reside in the application's memory. Because it doesn't need to reload all files, a warm start is usually faster than a cold start.

[0068] Application cold start: A cold start refers to starting an application from a completely shut-down state. In this case, the application needs to load all resources from scratch, initialize all necessary components, and establish the application's initial state. For example, the first application launched on a device after booting or restarting is a cold start application. During a cold start, the operating system needs to load the files required to start the application and initialize its components from scratch. This means the operating system needs to create a process for the application, allocate memory, and reload all application components, configurations, and data. Therefore, compared to a warm start, a cold start has a larger latency and a slower startup speed.

[0069] Idle state: This refers to an application in a waiting state, where the user has not performed any operation on the application or the application is not performing any background processing or data processing. In this state, the application enters idle mode or standby mode, typically ceasing some resource-intensive operations to conserve device system resources (such as CPU, memory, network bandwidth, etc.). Idle state is characterized by no user interaction, low power consumption, and possible background processing.

[0070] "No user interaction" means that the user has not triggered any clicks, swipes, or input. "Low power mode" means that the application may reduce background activity, pause animations, reduce network requests, or even enter power-saving mode to minimize the use of system resources. "Possible background processing" means that under certain circumstances, even when the application is idle, it may continue to perform some low-priority background tasks, such as data synchronization and cache clearing, but these tasks will not affect the user experience.

[0071] With the development of edge and cloud devices, various applications can be installed on each device (edge ​​or cloud). Application response speed has become a key factor affecting system performance. To improve system performance, it is necessary to shorten application startup latency. Application startup can be divided into two categories: warm start and cold start. Taking cold start as an example, when a user opens an application for the first time after the device is powered on, the application will undergo a cold start before the application interface is displayed. Therefore, to improve system performance, it is necessary to shorten the application cold start latency. Similarly, there is also a need to shorten the startup latency of warm starts.

[0072] Currently, one related technology offers a scheme to shorten operating system recovery latency and improve operating system restart speed by preloading files. For example, this technology analyzes user file usage habits to pre-read frequently accessed files from the disk and store these files in a hibernation file within shared memory, thus preloading frequently accessed files. When the operating system resumes from hibernation, it can access these preloaded files from shared memory, reducing disk access. Since the read speed of shared memory is higher than that of the disk, this reduces system startup and recovery latency, improving the operating system's startup and hibernation performance.

[0073] However, in the context of application startup, the preloaded files cached in shared memory are not directly related to the application; they are merely frequently accessed files preloaded based on file access frequency. Files relevant to application startup are not necessarily frequently accessed by the user. For example, application 1 requires file A and file B to start. File A is a frequently accessed file and is therefore preloaded into shared memory, while file B is not. Thus, when starting application 1, there is still a delay in loading file B, increasing the startup latency of application 1.

[0074] Furthermore, preloaded files may include files that are not frequently accessed, but not the files required for application startup. This not only fails to improve application startup speed, but may also lead to a waste of shared memory storage space, resulting in poor system performance when facing resource constraints or multitasking, further increasing application startup latency and reducing the overall performance of the operating system.

[0075] In view of the above problems, this application provides a method, as well as an end-side device and a cloud-side device, which can execute the method to solve the above technical problems.

[0076] End-side devices can be software, applications, browsers, in-vehicle systems, terminal devices, etc. When an end-side device is implemented as a terminal device, it can include, but is not limited to, any of the following: mobile phone, personal computer (PC), virtual reality (VR) device, augmented reality (AR) device, tablet computer, laptop computer, smart speaker, smartwatch, etc. End-side devices can also be smart TVs, mobile internet devices (MID), wearable devices (such as smartwatches, smart glasses, or smart helmets), smart cars, in-vehicle terminals, wireless terminal devices in industrial control, wireless terminal devices in self-driving, wireless terminal devices in remote medical surgery, wireless terminal devices in smart grids, wireless terminal devices in transportation safety, wireless terminal devices in smart cities, wireless terminal devices in smart homes, etc. In addition, the end-side device 100 can also be software on a terminal device, such as system services on a mobile phone or the vehicle system of a smart car.

[0077] This cloud-side device can be implemented through software or hardware.

[0078] In the first example, when the functionality of the cloud-side device is implemented through software, the cloud-side device may be, for example, an application running on a computing instance, which may be, for example, a virtual machine, a container, or a host.

[0079] In the second example, when the functionality of the cloud-side device is implemented through hardware, the cloud-side device can be implemented through at least one physical device including a processor. This physical device can be a server (e.g., a compute node (also called a compute server), a central server, or an edge server), a base station, a relay device, satellite equipment, etc., without limitation.

[0080] The processor can be a central processing unit (CPU) or a graphics processing unit (GPU), or it can be any type of processor or any combination thereof, such as an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), a system-on-chip (SoC), a software-defined infrastructure (SDI) chip, an AI chip, or a data processing unit (DPU).

[0081] Furthermore, the number of processors included in the cloud-side device can be arbitrary, and the types of processors included can be one or more. The specific number and types of processors can be set according to the actual business needs of the application, and this application does not limit this.

[0082] In the third example, when the functionality of the cloud-side device is implemented through hardware, the cloud-side device can also be a computing cluster comprising multiple computing nodes. Furthermore, these multiple computing nodes can communicate through the at least one switching node. Exemplarily, a computing node can be a computing server including an accelerator card. This accelerator card can be, for example, a deep-learning processing unit (DPU), a GPU, a neural-network processing unit (NPU), or a tensor processing unit (TPU), or other types of accelerator cards. Alternatively, a computing node can be a computing server including a general-purpose processor (such as a CPU).

[0083] The end-side device 100 of this application embodiment will now be described with reference to the accompanying drawings. Figure 1 A schematic diagram of the end-side device 100 is shown. It should be understood that... Figure 1The illustrated edge device 100 is merely an example. Optionally, the edge device 100 can be a terminal, also known as a terminal device. A terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, in-vehicle terminal, smart TV, wearable device, smart car, etc., and this application does not impose any limitations. Furthermore, the edge device 100 can also be software on a terminal device, such as system services on a mobile phone or the in-vehicle infotainment system of a smart car. It should be further noted that the edge device 100 can have more or fewer components than shown in the figure, can combine two or more components, or can have different component configurations. Figure 1 The various components shown can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0084] The end-side device 100 may include: a processor 610, an external memory interface 620, an internal memory 621, a universal serial bus (USB) interface 630, a charging management module 640, a power management module 641, a battery 642, an antenna 1, an antenna 2, a mobile communication module 650, a wireless communication module 660, an audio module 670, a speaker 670A, a receiver 670B, a microphone 670C, a headphone jack 670D, a sensor module 680, buttons 690, a motor 691, an indicator 692, a camera 693, a display screen 694, and a subscriber identification module (SIM) card interface 695, etc. The sensor module 680 may include a pressure sensor 680A, a gyroscope sensor 680B, a barometric pressure sensor 680C, a magnetic sensor 680D, an accelerometer sensor 680E, a distance sensor 680F, a proximity light sensor 680G, a fingerprint sensor 680H, a temperature sensor 680J, a touch sensor 680K, an ambient light sensor 680L, a bone conduction sensor 680M, etc.

[0085] The processor 610 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0086] The controller can serve as the central nervous system and command center of the end-side device 100. The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.

[0087] The processor 610 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 610 is a cache memory. This memory can store instructions or data that the processor 610 has just used or that are used repeatedly. If the processor 610 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 610, and thus improves the efficiency of the system.

[0088] In some embodiments, the processor 610 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0089] USB interface 630 is a USB standard compliant interface, specifically a Mini USB interface, Micro USB interface, USB Type-C interface, etc. USB interface 630 can be used to connect a charger to charge the terminal device 100, and can also be used for data transfer between the terminal device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other terminal devices, such as AR devices.

[0090] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the end-side device 100. In other embodiments of this application, the end-side device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0091] The charging management module 640 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 640 receives charging input from the wired charger via a USB interface 630. In some wireless charging embodiments, the charging management module 640 receives wireless charging input via the wireless charging coil of the end-side device 100. While charging the battery 642, the charging management module 640 can also supply power to the end-side device via the power management module 641.

[0092] The power management module 641 connects the battery 642, the charging management module 640, and the processor 610. The power management module 641 receives input from the battery 642 and / or the charging management module 640, providing power to the processor 610, internal memory 621, external memory, display screen 694, camera 693, and wireless communication module 660. The power management module 641 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 641 may also be located within the processor 610. In other embodiments, the power management module 641 and the charging management module 640 may be located in the same device.

[0093] The wireless communication function of the end-side device 100 can be implemented through antenna 1, antenna 2, mobile communication module 650, wireless communication module 660, modem processor and baseband processor, etc.

[0094] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the end-side device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0095] The mobile communication module 650 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied on the end-side device 100. The mobile communication module 650 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 650 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 650 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 650 may be housed in the processor 610. In some embodiments, at least some functional modules of the mobile communication module 650 and at least some modules of the processor 610 may be housed in the same device.

[0096] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 670A, receiver 670B, etc.) or displays images or videos through a display screen 694. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 610 and may be housed in the same device as the mobile communication module 650 or other functional modules.

[0097] The wireless communication module 660 can provide solutions for wireless communication applications on the end-side device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 660 can be one or more devices integrating at least one communication processing module. The wireless communication module 660 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 610. The wireless communication module 660 can also receive signals to be transmitted from processor 610, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0098] In some embodiments, the antenna 1 of the end-side device 100 is coupled to the mobile communication module 650, and the antenna 2 is coupled to the wireless communication module 660, so that the end-side device 100 can communicate with the network and other devices through wireless communication technology.

[0099] The edge device 100 implements display functions through a GPU, a display screen 694, and an application processor. The GPU is a microprocessor for image processing, connecting the display screen 694 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 610 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0100] Display screen 694 is used to display images, videos, etc. Display screen 694 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the end-side device 100 may include one or N displays 694, where N is a positive integer greater than 1.

[0101] The edge device 100 can perform shooting functions through an ISP, camera 693, video codec, GPU, display 694, and application processor.

[0102] Camera 693 is used to capture still images or videos. An object passes through the lens to generate an optical image that is projected onto a photosensitive element.

[0103] The external storage interface 620 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the terminal device 100. The external storage card communicates with the processor 610 through the external storage interface 620 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.

[0104] Internal memory 621 can be used to store computer executable program code, which includes instructions. Processor 610 causes terminal device 100 to execute the methods described in this embodiment by running the instructions stored in internal memory 621. Internal memory 621 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created by terminal device 100 during use (such as audio data, phonebook, etc.). Furthermore, internal memory 621 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0105] The end-side device 100 can implement audio functions, such as music playback and recording, through an audio module 670, a speaker 670A, a receiver 670B, a microphone 670C, a headphone jack 670D, and an application processor.

[0106] The audio module 670 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 670 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 670 may be located in the processor 610, or some functional modules of the audio module 670 may be located in the processor 610.

[0107] Buttons 690 include a power button, volume buttons, etc. Buttons 690 can be mechanical buttons or touch-sensitive buttons. The terminal device 100 can receive button input and generate key signal inputs related to user settings and function control of the terminal device 100.

[0108] Motor 691 can generate vibration alerts. Motor 691 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can be corresponding to touch operations applied to different applications (such as taking photos, playing audio, etc.). Motor 691 can also correspond to different vibration feedback effects for touch operations applied to different areas of the display screen 694. Different application scenarios (such as time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also be customized.

[0109] Indicator 692 can be an indicator light, used to indicate charging status, power changes, or messages, missed calls, notifications, etc.

[0110] The SIM card interface 695 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 695 to make contact with and detach from the terminal device 100. The terminal device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 695 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 695 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 695 is also compatible with different types of SIM cards. The SIM card interface 695 is also compatible with external memory cards. The terminal device 100 interacts with the network through the SIM card to realize functions such as calls and data communication. In some embodiments, the terminal device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the terminal device 100 and cannot be separated from the terminal device 100.

[0111] The software system of the terminal device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture, etc., and there is no limitation here. This application embodiment takes the layered architecture Android system as an example to illustrate the software structure of the terminal device 100.

[0112] Figure 2 This is a software structure block diagram of the end-side device 100 according to an embodiment of this application.

[0113] The layered architecture of the edge device 100 divides the software into several layers, each with a clear role and division of labor. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0114] The application layer can include a series of application packages.

[0115] like Figure 2 As shown, the application package can include applications such as gallery, SMS, navigation, music, video, reading, and ticketing.

[0116] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0117] like Figure 2 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, system services, etc.

[0118] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0119] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0120] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0121] The phone manager is used to provide communication functions for the end-side device 100. For example, it manages call status (including connection, hang-up, etc.).

[0122] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0123] The notification manager allows applications to display notifications in the status bar. These notifications can be used to convey informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of download completion or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating the device, and flashing indicator lights.

[0124] Before receiving a user's instruction to start the application, the system service can create the application's process and write the application's corresponding IO file into the process's memory. The system service can also respond to the user's operation by executing the application's corresponding process to display the application's interface. The specific implementation process of the system service will be described in detail in the following method embodiments.

[0125] The system library and runtime layer include the system libraries and the Android Runtime. The system libraries can include multiple functional modules, such as the surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), and 2D graphics engines (e.g., SGL). The 3D graphics library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing. The Android Runtime includes the core libraries and the virtual machine. The Android Runtime is responsible for the scheduling and management of the Android system. The core libraries consist of two parts: one part contains the functionalities that the Java language needs to call, and the other part contains the core Android libraries. The application layer and application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0126] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0127] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0128] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0129] A 2D graphics engine is a graphics engine for 2D drawing.

[0130] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0131] Understandable Figure 2 The components included in the system framework layer, system library, and runtime layer shown do not constitute a specific limitation on the edge device 100. In other embodiments of this application, the edge device 100 may include more or fewer components than shown, or combine some components, or split some components, or have different component arrangements.

[0132] The application launch method of this application will be illustrated below with different examples. This method can be applied to edge devices or cloud devices. The implementation process of this method will be illustrated below using an edge device (such as a mobile phone) as an example.

[0133] Example 1

[0134] Figure 3 A flowchart of an application launch method according to an embodiment of this application is illustrated. This method flow can be combined with... Figure 1 and Figure 2 Examples, but not limited to, those in conjunction with Figure 1 and Figure 2 Example.

[0135] like Figure 3 As shown, the method flow may include, but is not limited to, the following steps:

[0136] S403. Receive user operation.

[0137] For example, the mobile phone can receive the user's operation. In some embodiments, the user's operation can instruct the launch of a first application. The mobile phone has multiple applications installed, which may include the first application, such as the second application in the following embodiments, as well as other applications not listed herein, without limitation.

[0138] In an optional embodiment, the mobile phone may include a human-computer interaction component. A user triggers a user operation to launch a first application based on the human-computer interaction component, and the mobile phone receives the user operation based on the human-computer interaction component. The human-computer interaction component of the mobile phone may include a voice component, a touch component, etc. The voice component may include a microphone, and the touch component may include a touch screen.

[0139] In a specific embodiment, the user inputs a command to launch a first application based on the voice component, and this command may carry the name of the first application. For example, the voice component collects the user's voice signal used to launch the first application, and parses the voice signal to obtain the name of the application to be launched. For example, the first application is application A, and the voice signal could be "Launch application A".

[0140] In a specific embodiment, the touch component displays a shortcut (e.g., an application icon) to the first application, and the user clicks the application icon on the touch component to trigger the aforementioned user operation that instructs the user to launch the first application.

[0141] Prior to S403, the method can execute S401 and S402.

[0142] Specifically, before the phone receives the aforementioned user operation, the phone can execute S401.

[0143] S401. Create the first process for the first application.

[0144] The first application can be any application installed on the phone.

[0145] In some embodiments, the first application may be a user-specified application that needs to be launched quickly, or the first application may be an application predicted by the mobile phone. For example, the mobile phone may use the method of this application to predict the application that the user may launch in the future (e.g., the next 10 minutes starting from the current moment, without limitation).

[0146] In some embodiments, the first application may be one of a group of applications to be accelerated, which may be preset or predicted by the phone to be launched. Furthermore, if the group of applications is preset, it may include multiple applications; if the group of applications is predicted by the phone, it may include one or more applications, without limitation.

[0147] Furthermore, the number of applications in this group can be user-defined or flexibly determined by the phone based on factors such as memory.

[0148] Therefore, before the user instructs the first application to be launched, the mobile phone of this application can create a process for the first application (hereinafter referred to as the first process).

[0149] In some embodiments, the first application may be an application installed on the mobile phone that is in an idle state. In this case, the first application is running in the background and is in a waiting state, without performing data operations. The method of this application can accelerate the startup of the idle application in the hot start scenario of the application, thereby quickly switching the background application to the foreground application to reduce the hot start latency of the application (such as the first application).

[0150] In some embodiments, S401 can be executed not only before the aforementioned user operation is received, but the first application can also be an application that is closed after the phone is powered on or restarted. In this way, the method of this application embodiment can accelerate the startup of the first application in the application cold start scenario, so as to reduce the cold start latency of the application (e.g., the first application).

[0151] In some embodiments, the first process is an empty process when it is created. In other words, in S401, the mobile phone may create an empty process for the first application that the user may launch in the future.

[0152] An empty process is a process that remains in the operating system but does not perform any tasks. In other words, the first process in S401 is an empty process. An empty process may occupy one entry in the process table, but it does not consume central processing unit (CPU) resources, time resources, or other resources. For example, an empty process may be a process in a runnable state. Thus, the first process in S401 has not yet been executed.

[0153] In a specific embodiment, the mobile phone can create an empty process with a runnable state for the first application, which is the first process here. After the first process is created, it can have a process identifier (PID), which can uniquely identify the first process of the first application.

[0154] Similarly, before receiving the aforementioned user operation, after S401, the method can also execute S402.

[0155] S402. Write the first IO file of the first application to the first process.

[0156] In some embodiments, the first IO file is a file that needs to be loaded to start the first application.

[0157] Considering that the first application is considered to have fully started only from the moment the user operation is received until the application interface is displayed, and this application interface is the first screen displayed when the first application starts, the aforementioned first IO file may include some files necessary for the first application to start, and optionally may also include IO files used to enable the application interface to support user operations.

[0158] For example, the first interface displayed after the first application starts may include multiple components. These components can be used by the user to interact with the first application to achieve corresponding user operations. In order for the components in the first interface (i.e. the application interface mentioned above) to be operable, some IO files related to the use of these components are also files that need to be loaded to start the first application.

[0159] Furthermore, the aforementioned first IO file is an IO file that can be pre-read before the first application starts. For example, the first IO file is an IO file and is not a temporary file generated during the phone's boot process.

[0160] In a specific embodiment, the first IO file includes files necessary to launch the first application. In an optional embodiment, the first IO file may also include non-essential files for launching the first application, which are files that enable the application interface of the first application to support user operation.

[0161] For example, the first IO file may include configuration files, library files, resource files, template files, plugins, extensions, help documentation, etc. Configuration files may include, but are not limited to: initialization (ini) files, JavaScript object notation (JSON) files, and extensible markup language (xml) files; library files may include dynamic link libraries (DLLs) and static libraries (libs); resource files may include image resource files, audio resource files, and font resource files; template files may include dotx files and dot files; and help documentation may include chm files and html files.

[0162] For example, the first application could be a text-based application (such as a Word application). Optional files could include some I / O files that support the display and manipulation of the menu bar in Word. These components could include, for example, a start component, an insert component, a design component, etc., without limitation.

[0163] In an optional embodiment, the mobile phone can obtain the first IO file corresponding to the first application. The specific implementation method for obtaining the first IO file can be referred to the solutions disclosed in the relevant technology, and no limitation is made here.

[0164] Furthermore, the first IO file can be one or more files, with no specific restrictions.

[0165] In an optional embodiment, before the user requests to launch the first application, the mobile phone may create a first process for the first application and allocate memory for the first process. Then, when the mobile phone writes the first I / O file of the first application to the first process, it can write the first I / O file to the memory of the first process. For example, the mobile phone may read the first I / O file of the first application from the mobile phone's disk and write it to the memory of the first process.

[0166] The timing for allocating memory to the first process can be when the first process is created, and / or when the first I / O file is written to the first process; there are no specific restrictions.

[0167] In some embodiments, the mobile phone may allocate a fixed amount of initial memory to the first process when the first process is created. The mobile phone may then write the first I / O file corresponding to the first application into the memory of the first process. If the initially allocated memory is insufficient to write the first I / O file, the mobile phone may continue to allocate additional memory to the first process until the entire first I / O file is written into the memory of the first process.

[0168] In other embodiments, the mobile phone may allocate memory for the first process based on the size of the first IO file during the process of writing the first IO file of the first application to the first process, and write the first IO file into the memory of the first process to achieve the effect of writing the first IO file into the first process.

[0169] Before receiving the above user operation, the first process created by S401 is an empty process. S402 attaches the first IO file required for the first application to the first process. In this way, the memory of the first process has been written with the first IO file, so that the first process after S402 is no longer an empty process, but is still in a runnable state. This makes the first processes of S401 and S402 processes that have not performed any tasks, that is, processes that have not been executed (e.g., by the CPU).

[0170] Following S401, S402, and S403, the method may further execute S404. S404. In response to the user operation described in S403, a first process is executed to display the application interface of the first application (the application interface mentioned in the relevant description of S402 above).

[0171] In some embodiments, after receiving a user operation instructing the mobile phone to launch a first application, the mobile phone executes a first process to display the application interface of the first application.

[0172] This application interface is the first screen displayed after the first application is launched.

[0173] In a specific embodiment, the mobile phone (e.g., the CPU of the mobile phone) can execute the first process to read the first IO file from the memory of the first process and launch the first application based on the first IO file, thereby displaying the application interface of the first application.

[0174] This application interface is the launch screen of the first application, which is the first screen displayed after the phone launches the first application. In other words, when the phone displays this launch screen, it indicates that the first application has successfully launched.

[0175] In an optional embodiment, the operation of the first application may correspond to multiple processes, which may include a main process and child processes (e.g., multiple processes).

[0176] In an optional embodiment, during the execution of the first process in S404 above, the first process is the main process of the first application.

[0177] In a specific embodiment, before responding to a user operation, the first process is a process not executed by the phone's CPU. Following the steps S401 and S402 described above, this first process is merely a process with memory containing the first I / O file mounted; however, it is in a runnable state, waiting to be executed by the CPU at any time, but it is not yet executed. During the response to a user operation, the phone can execute this first process, making it the main process of the first application. In other words, the main process of the application refers to the process in which the application is executed.

[0178] For example, before responding to a user action, the phone creates a first process and adds it to a queue to be executed. After responding to a user action, the phone retrieves the first process from the queue to be executed and executes it.

[0179] In this embodiment of the application, after receiving the user's operation, the first process is executed. At this time, the first process is the main process of the first application. The operating system will allocate the resources required for the execution of the first process (such as CPU resources, memory resources, etc.) to the first process, so that the first process can be executed to start the first application.

[0180] Example 2

[0181] The following is combined Figure 4 Let's elaborate on the process of Example 1 above.

[0182] Figure 4 An exemplary diagram comparing the flow of the method of this application embodiment with an existing application startup flow is shown.

[0183] like Figure 4 As shown, above the dashed line Figure 4(1) The process shown is the existing application startup process, below the dashed line. Figure 4 (2) The process shown is the application startup process of this application embodiment.

[0184] Reference Figure 4 As shown in (1), the application startup process may include a wake-up phase and an application-side phase.

[0185] Specifically, the wake-up phase may include delivering application startup events (such as delivering user actions that instruct the application to start) and creating the process corresponding to the application.

[0186] As an example, the delivery of application startup events during the wake-up phase can be the implementation process of the system control block (SCB) and activity manager service (AMS).

[0187] During application startup, SCB and AMS can represent system-level hardware management and operating system-level application management, respectively. Specifically:

[0188] SCB (System Controller Block) involves hardware and system initialization, helping the system wake up from a low-power state and restore to full-function mode. AMS (Application Management System) manages the application lifecycle at the operating system level, ensuring that applications can start smoothly and performing scheduling and wake-up operations based on the system state. The cooperation between these two stages ensures that hardware and software can work in coordination during the transition from a low-power state to an active state, successfully completing the application startup process.

[0189] As an example, the process of creating the application's corresponding process during the wake-up phase is also described as appspawn. Appspawn mainly refers to the process during application startup where the operating system wakes up the application by creating a new process or instance, providing it with the necessary resources and environment so that it can move from the background or dormant state to the foreground and begin running. This process usually takes place during the application wake-up phase and involves operating system scheduling, process initialization, and necessary resource allocation.

[0190] During the wake-up phase, the application's process can be preloaded and set to a runnable state to keep the process alive.

[0191] In this context, a process being in the runnable state means that it has met the conditions required for CPU execution and is ready to run. Currently, the process is waiting for the operating system to schedule it so that CPU resources can be allocated for execution.

[0192] Continue to refer to Figure 4(1) The application-side stage may include a non-user interface (UI) stage and a UI stage. The mobile phone may load components or files unrelated to the UI in the non-UI stage, and may load components or files related to the UI in the UI stage. There is no time limit between the non-UI stage and the UI stage. That is, the mobile phone may execute the non-UI stage first and then the UI stage, or it may execute the UI stage first and then the non-UI stage.

[0193] In order to clearly explain the scheme of this application and Figure 4 The differences between the schemes shown in (1) are firstly... Figure 4 (1) The implementation details of the proposed solution and the problems that exist are explained:

[0194] Question 1, such as Figure 4 As shown in (1), in the existing application startup process, when the mobile phone receives a user operation instructing the user to start the application at time t1, after the mobile phone receives the user operation, the mobile phone (e.g., Figure 2 The system services shown will sequentially execute the wake-up phase and the application-side phase to complete the application's startup. For example, the application will finish starting and display its interface at time t3. As mentioned above, during the wake-up phase, the phone can transmit the event corresponding to the user's operation, as well as the process for creating the application. The process can only be executed during the application-side phase to launch the application. Thus, after the user inputs the instruction to launch the application, it is necessary to wait for the complete execution of both the wake-up phase and the application-side phase before the application interface can be displayed. This results in a relatively long application startup delay.

[0195] Question 2, refer to Figure 4 (1) In the existing application startup process, the application-side implementation needs to read some IO files corresponding to the application to ensure the execution of the application-side stage. In one existing implementation method 1, during the application-side stage, the mobile phone can read the required IO files from the mobile phone's disk in real time and put them into the memory of the created process to start the application. In this way, during the application startup process, the mobile phone needs to read IO files from the disk in real time, which makes the data reading time longer, thus lengthening the overall application startup time. Moreover, when reading IO files, the IO files are read according to the current execution progress of the application-side stage, rather than reading all the IO files required to start the application at once. Thus, at different execution progresses of the application-side stage, the mobile phone may need to read IO files from the disk multiple times, further lengthening the overall application startup time.

[0196] Question 3, refer to Figure 4(1) In the existing application startup process, the application-side implementation needs to read some IO files corresponding to the application to ensure the execution of the application-side phase. In one existing implementation method 2, before receiving the user operation indicating to start the application at time t1, the existing method can pre-read the application's IO files into shared memory. Then, after receiving the user operation, a wake-up phase is executed (e.g., passing the application startup event and creating the application process). After that, the IO files required to start the application are read from shared memory and written into the memory of the application process. Thus, after the user inputs the operation indicating to start the application, it is necessary to wait for the aforementioned event transmission, process creation, and the process of reading the IO files from shared memory into the application process, resulting in a long application startup latency.

[0197] Different from the above Figure 4 For the solution in (1), please refer to... Figure 4 (2) The following uses the cold start of the application (i.e., an example of the first application above) as an example. The method is the same when the application is a hot start, so it will not be repeated.

[0198] It should be understood that, in contrast to Figure 4 (1), please refer to Figure 4 (2) In this embodiment, the application startup process still includes a wake-up phase and an application-side phase. However, the timing of these phases differs from that of receiving the aforementioned user operations. Furthermore, the application-side phase of this application differs from... Figure 4 (1) The execution latency of the application-side phase is shorter.

[0199] Please refer to the following. Figure 4 (2) To illustrate the method of the embodiments of this application. For example, at time t0, the mobile phone is turned on (for example, the time when the user clicks the power button on the mobile phone is time t0); then, after the mobile phone is turned on, that is, after time t0 and before time t1 (that is, before the mobile phone receives the operation to start the application), the mobile phone can perform the wake-up phase of the application. For example, the wake-up phase may include passing an event to start the application and creating the process of the application (here, an empty process) to achieve the preloading of the process.

[0200] After the preload process, such as Figure 4 As shown in (2), the mobile phone can pre-read files. Specifically, the mobile phone can write the IO files that need to be loaded to start the process into the pre-loaded process (i.e., pre-loaded into the memory of the process).

[0201] like Figure 4As shown in (2), the process of pre-reading files can specifically include: obtaining pre-loaded process information (e.g., PID), which can obtain the process ID (i.e., PID) of the empty process of the application created during the wake-up phase; then, the IPD can be used to obtain the list of IO files corresponding to the process; after that, the IO file corresponding to the process can be read through the list of IO files, and the IO file corresponding to the process can be read from the disk into the memory of the process (i.e., the memory corresponding to the PID).

[0202] Thus, addressing problem 1 above, after powering on, before time t1, the phone has already performed the application wake-up phase and loaded the IO files required for the application's startup into the application's process. Therefore, after time t1, the phone does not need to perform the wake-up phase, and consequently, does not need to create the application's process. Before receiving a user instruction to launch the application (e.g., before time t1), the application's process is already created and ready for execution, significantly reducing application startup latency.

[0203] Continue to refer to Figure 4 (2) Optionally, this scheme may include preloading the application-side subprocesses before time t1. This scheme will be explained in detail in S503 of Example 3 below, and will not be repeated here.

[0204] Please refer to Figure 4 (2) After time t1, the mobile phone can respond to the user's operation by executing the pre-loaded application process. This process has also loaded the IO files required to start the application before time t1. Therefore, during the execution of this process, i.e., between time t1 and t3, regarding issues 2 and 3 above, this application's startup process does not require creating a process, reading the IO file from the disk, or reading the IO file from shared memory into the process. Instead, the application process is created before receiving the user's operation, and the IO files required for application startup are loaded into the process's memory. This saves the process of writing the IO file to the process memory (e.g., reading from the disk or shared memory), thereby reducing the overall execution latency of the application-side stage. Furthermore, the wake-up phase is executed before receiving the user's operation, further reducing the overall application startup latency. Figure 4 As shown in (2), in the solution of this application embodiment, the application startup delay is t2-t1, while the existing... Figure 4 (1) The application startup latency shown in the application startup process is t3-t1, and the symbol "-" is a minus sign. The reduced startup latency of the application startup process is (t3-t2), which speeds up the application startup process and improves the user experience.

[0205] Unlike existing application startup processes, this application's embodiment creates a process for the first application before receiving a user operation instructing the user to start the first application. The method then writes the I / O files required for starting the first application into the application's process. After receiving the user operation, the method only needs to execute this process to display the application's startup interface, thus completing the application startup. Therefore, during the process of starting the application in response to a user operation, the method of this application does not need to create the application's process, as the process has already been created before receiving the user operation. Furthermore, during the process of starting the application in response to a user operation, the method of this application embodiment does not need to read the application's I / O files from shared memory into the application's process, as the application's I / O files have already been written into the application's process before receiving the user operation. This avoids the operation of reading the application's I / O files from shared memory into the application's process, thereby accelerating the application startup speed, shortening the application startup latency, reducing the user's waiting time for the application to start, and improving the user experience.

[0206] In some embodiments, when the startup type of the first application is a warm start, the application process has already been created during the last application startup process. The solution provided in this application can pre-read the IO files required by the currently started application into the memory of the process before receiving user operation. After receiving user operation, the first process can be directly executed to start the first application.

[0207] In some embodiments, regarding Figure 4 (2) The process shown in the dashed box indicating the pre-read file is as follows: After the phone preloads the process, it can obtain the list of IO files corresponding to the process based on the process information of the preloaded process. The phone can then read the IO files corresponding to the process based on the IO file list and write these IO files to the memory of that process. For example, the process information can be the process identifier (ID).

[0208] In an optional embodiment, the mobile phone stores a global IO file list. The mobile phone retrieves this global IO file list, which includes process IDs of multiple processes and a list of IO files corresponding to each process ID. The mobile phone can determine the IO file list corresponding to a process based on this IO file list and the process IDs of the processes.

[0209] In a specific embodiment, the mobile phone searches the global IO file list based on the process ID of the process to determine the IO file list corresponding to the process ID in the global IO file list. The mobile phone then determines the IO file list corresponding to the process ID as the IO file corresponding to the process.

[0210] In one example, the list of global IO files is shown in Table 1 below.

[0211] Table 1

[0212] Process ID IO file list Process ID1 IO file list 1 Process ID2 IO file list 2 Process ID3 IO file list 3 …… ……

[0213] For example, if process A has a process ID of "process ID2", the phone searches the global ID file list shown in Table 1 based on "process ID2" and determines that the IO file list corresponding to "process ID2" is "IO file list 2". Therefore, the phone identifies "IO file list 2" as the IO file list of process A. The phone reads the IO files included in IO file list 2 and writes these files into the memory of process A.

[0214] In this embodiment, an empty process for the application is created before application startup, and the IO files required for application startup are written to the memory of this empty process. This ensures that the pre-read IO files are application-dependent, guaranteeing their accuracy and completeness. Furthermore, the pre-read files are neither part of the wake-up phase nor the application-side phase. However, pre-reading the IO files to the process's memory shortens the time required to read the IO files from the disk or shared memory during application startup, compared to reading the IO files from disk or shared memory during startup. This reduces application startup latency.

[0215] Example 3

[0216] This Example 3 is largely the same as Example 1 above, and the similarities with Example 1 can be found in the description of Example 2. Unlike Example 1, which accelerates the startup of a single application, this Example 3 executes the method of this embodiment on each application in the application list to accelerate the startup process of each application in the application list, thereby shortening the startup latency of each application in the application list.

[0217] In some embodiments, the method of this application embodiment can obtain an application list, which may contain only one application. In this case, the application may be the first application in Example 1 and Example 2, so as to accelerate the startup of the applications in the application list. The specific process is described in Example 1 and Example 2, and will not be repeated here.

[0218] In this embodiment, the application list may include two or more applications. For each of these applications, before receiving a user operation instructing the user to launch the application, the mobile phone may create a corresponding empty process for each application in the application list and write the corresponding IO file to the empty process. Based on this, the mobile phone of this application can accelerate the launch of two or more applications in the application list, shorten the launch latency of the two or more applications, and improve the launch speed of the two or more applications.

[0219] The following is combined Figure 5 This embodiment will now introduce the implementation process of another application startup method.

[0220] exist Figure 5 The text describes the process of a mobile phone creating a first process for a first application and writing a first I / O file to the first process before receiving a first instruction from the user to launch the application, and executing the first process based on the first I / O file written to the first process after receiving the first instruction from the user to launch the application (e.g.,...). Figure 5 S401 to S404 shown are all the same as those in Example 1. Figure 3 The implementation processes shown (e.g., S401 to S404) have the same implementation principle and achieve similar technical effects, so they will not be described in detail here.

[0221] Because of the difference Figure 3 The process shown accelerates the startup speed of an application and reduces its startup latency is as follows: Figure 5 The illustrated process can accelerate the startup of two or more applications and reduce their startup latency. Figure 5 Taking the launch of the first and second applications as an example, when the application list includes more than two applications, the accelerated launch process for other applications in the application list is similar in principle to the accelerated launch process for the first or second application described here, and will not be repeated here.

[0222] Specifically, such as Figure 5 As shown, the method flow may also include, but is not limited to, the following steps:

[0223] S400. Get the application list.

[0224] In an optional embodiment, the application list includes only one application, such as the first application in Example 1 above. The process of launching the first application on the phone is the same as that in Example 1, and will not be described again here.

[0225] In an optional embodiment, the application list may include multiple applications, including a first application and a second application.

[0226] In some embodiments, an application list may be preset, and the mobile phone or an external device communicating with the mobile phone may store the preset application list, which the mobile phone can then access.

[0227] In other embodiments, the mobile phone can predict the list of applications based on an AI model, which will be described in detail in S4501 and S452 below.

[0228] Reference Figure 5After S400 and before S403, processes S401 and S402 can be executed, as can processes S501 and S502.

[0229] S501. Create a second process for the second application.

[0230] The second application can be any application installed on the phone.

[0231] In some embodiments, the second application may be a user-specified application that needs to be launched faster. Alternatively, the second application may be an application that the user is likely to launch based on an AI model, for example, the phone may use the method of this application to predict an application that the user may launch in a future time period (e.g., the next 10 minutes starting from the current moment, without limitation).

[0232] In some embodiments, the second application may be one of a group of applications to be accelerated (i.e., the application list mentioned above), which may be a preset group of applications or applications predicted by the phone to be launched. Furthermore, if the group of applications is a preset group, it may include multiple applications; if the group of applications is an application predicted by the phone, it may include multiple applications, without limitation.

[0233] Furthermore, the number of applications in this group can be user-defined or flexibly determined by the phone based on factors such as memory.

[0234] Before the mobile phone receives a user operation instructing it to launch the second application, the mobile phone of this application can create a process for the second application (hereinafter referred to as the second process), which is an empty process when it is created.

[0235] In some embodiments, the second application may be an application installed on the mobile phone in an idle state. In this case, the second application is running in the background and is in a waiting state, without performing data operations. The method of this application can accelerate the startup of the idle application in the hot start scenario of the application, thereby quickly switching the background application to the foreground application to reduce the hot start latency of the application (such as the second application).

[0236] In some embodiments, S501 can be executed not only before the aforementioned user operation is received, but the second application can also be an application that is closed after the phone is powered on or restarted. In this way, the method of this application embodiment can accelerate the startup of the second application in the cold start scenario of the application, so as to reduce the cold start latency of the application (e.g., the second application).

[0237] In some embodiments, the second process is an empty process when it is created. For example, in S501, the mobile phone may create an empty process for a second application that the user may launch in the future.

[0238] For an explanation of empty processes, please refer to the relevant introduction to empty processes in Example 1, which will not be repeated here.

[0239] In a specific embodiment, the mobile phone can create an empty process with a runnable state for the second application, which is the second process here. After the second process is created, it can have a process identifier (PID), which can uniquely identify the second process of the second application.

[0240] Similarly, before S403 and after S501, the method can also execute S502.

[0241] S502. Write the second IO file of the second application to the second process.

[0242] In some embodiments, the second IO file is a file that needs to be loaded to start the second application.

[0243] Considering that the second application is considered to have fully started only from the moment the user operation is received until the application interface of the second application is displayed, and this application interface is the first screen displayed when the second application starts, the aforementioned second IO file may include some files necessary for the second application to start, and optionally may also include IO files used to enable the application interface to support user operations.

[0244] The relevant embodiments and descriptions of S502 can be referred to the relevant embodiments and descriptions of S402 in Example 1. The principles are the same, and will not be repeated here.

[0245] Before receiving the user operation described in S403, the second process created by S501 is an empty process. S502 attaches the second IO file required for the startup of the second application to the second process. In this way, the memory of the second process has been written with the second IO file, so that the second process after S502 is no longer an empty process, but is still in a runnable state. This makes the second processes of S501 and S502 processes that have not performed any tasks, that is, processes that have not been executed (e.g., by the CPU).

[0246] Similarly, after S400 and before S403, the phone can also execute S401 and S402. The execution process of S401 and S402 in this Example 3 is exactly the same as that of S401 and S402 in Example 1, and will not be repeated here.

[0247] In some embodiments, S402 and S502 in this example are both executed before S403. This application embodiment does not limit the execution order of S402 and S502. In practical applications, S502 can be executed before S402. In other words, this application embodiment does not limit the execution order between the process of the mobile phone writing the first IO file of the first application to the first process and the process of the mobile phone writing the second IO file of the second application to the second process.

[0248] In some embodiments, the mobile phone may serially create a corresponding process (i.e., an empty process) for each application in the application list in S400 described above.

[0249] In a specific embodiment, the mobile phone can create a first process and write a first IO file of a first application to the first process. Then, the mobile phone can create a second process and write a second IO file of a second application to the second process.

[0250] In a specific embodiment, the mobile phone may first create a first process, and then the mobile phone may create a second process. Alternatively, the mobile phone may first create a second process, and then the mobile phone may create a first process.

[0251] Next, the mobile phone can sequentially execute the process of writing the first IO file of the first application to the first process and the process of writing the second IO file of the second application to the second process, or sequentially execute the process of writing the second IO file of the second application to the second process and the process of writing the first IO file of the first application to the first process.

[0252] In other embodiments, when the phone includes multiple CPU cores, the phone can also create processes in parallel. For example, if the phone is a dual-core phone, it can use the dual-core CPU to create a first process and a second process in parallel, and execute in parallel the process of writing a first IO file of a first application to the first process and the process of writing a second IO file of a second application to the second process.

[0253] After S402 and S502, the phone can execute S403 and S404 to accelerate the launch of the first application in the application list when the user instructs to launch the first application. The implementation process of S403 and S404 is described in Example 1 and will not be repeated here.

[0254] In other embodiments, the user operation in S403 can also be a user operation that instructs the user to launch any application in the application list other than the first application. The implementation principle is similar, and the method of this application embodiment can still accelerate the launch of the application instructed by the user.

[0255] In this embodiment, the application list may include multiple applications. Before receiving a user operation instructing the user to launch an application from the application list, an empty process is created for each of the multiple applications, and the corresponding IO file for that application is written to the empty process. This accelerates the launch of multiple applications in the application list. After receiving a user operation instructing the user to launch any application from the application list, the method of this application only needs to respond to the user operation by executing the process corresponding to that application with the attached IO file. During the launch of any application from the application list, it is not necessary to create a process for that application, nor is it necessary to read the process's IO file from the disk into the process's memory, nor is it necessary to read the application's IO file from shared memory into the application's process. This solution can reduce the launch latency of multiple applications in the application list in batches, thereby improving the launch speed of multiple applications.

[0256] In other embodiments, prior to S403, the method may perform preloading processes such as those shown in S401 and S501 (e.g. Figure 4 The process shown), and the pre-read files (e.g., as described in S402 and S502) Figure 4 Please refer to the process shown below. Figure 5 As shown, before S403, the method may also include S503.

[0257] Optionally, S503. Load the common subprocess between the first application and the second application.

[0258] Reference Figure 5 Before receiving a user's instruction to launch any application in the application list, the mobile phone can load a common sub-process shared by multiple applications in the application list. This sub-process is required to be loaded when both the first and second applications are launched. In this way, when the mobile phone launches any application in the application list (i.e., in response to a user's instruction to launch any application in the application list), it is not necessary to load these common sub-processes, which can reduce the launch latency of each application in the application list and improve the launch speed of applications in the application list in batches.

[0259] In an optional embodiment, the application list may include a first application and a second application. The phone may load a common sub-process between the first application and the second application. Subsequently, in response to a user operation, the phone may launch the first application based on the first process and the common sub-process, and launch the second application based on the second process and the common sub-process.

[0260] This subprocess is a process that both the first and second applications need to load when they start.

[0261] Continue back Figure 4 , Figure 4(2) Before receiving a user operation instructing the launch of any application in the application list (i.e., before time t1), the method of this embodiment can also preload the sub-processes of the application-side stage. Specifically, the method can load the common sub-processes between the first application and the second application in the application list. For example, if the application-side stages of the first application and the second application have common components that need to be loaded, the processes corresponding to these common components are the sub-processes here. By preloading the common sub-processes between different applications in the application list before time t1, the operations of the application-side stage of the application launch process after time t1 can be further reduced, thereby reducing the launch latency of any application in the application list.

[0262] Thus, upon receiving a user operation to launch any application from the application list, the method of this embodiment, in responding to the user operation, such as launching the first or second application, refers to... Figure 4 In the application-side phase shown, the method of this application embodiment does not require... Figure 4 (1) The application-side phase shown in the diagram is fully executed because some subprocess operations were completed before the user operation was received (e.g., ...). Figure 4 (2) The process of loading subprocesses is shown, thereby reducing the subprocess loading process of each application in the application list during the startup process, further reducing the application-side stage time of each application in the application list during the startup process, thus achieving a batch reduction in the startup latency of each application in the application list.

[0263] Continue to refer to Figure 5 When executing S400 above, the application list can be obtained by executing S451 and S452. This can be achieved by using an AI model to predict the multiple applications that the user expects to launch in the future.

[0264] S451. Using an AI model, based on historical user data, predict the k applications that the user expects to launch within a future time period.

[0265] Here, the k applications are those that the user expects to launch within a future time period, where k ≥ 1 and k is an integer.

[0266] For example, user history data indicates historical usage data of candidate applications, which includes the k applications. Historical usage data may include the frequency of use of the candidate applications, the time period of use, and the frequency of use within a day.

[0267] Among them, the number of candidate applications is more than k or equal to k.

[0268] In some embodiments, k ≥ 2, where k is an integer.

[0269] The future time period is a specified duration starting from the current moment, such as the next 10 minutes or the next 15 minutes, without any restrictions. The length of the future time period can be related to the computing power of the device used by the method and the number of applications that need to be accelerated. For example, if the computing power is high, the length of the time period can be shorter. Similarly, if the number of applications in the application list that need to be accelerated is small, the length of the time period can be shorter.

[0270] In addition, the AI ​​model described above can run on the device to which the method is applied (e.g., a mobile phone), or the AI ​​model can be deployed on a server that communicates with the mobile phone, thereby enabling the AI ​​model to run with higher computing power and accelerate the prediction of k applications. The mobile phone can obtain the k applications predicted by the AI ​​model from the server.

[0271] In an optional embodiment, the mobile phone inputs user historical data into the AI ​​model. Based on the user historical data, the AI ​​model predicts the probability of each candidate application being launched by the user in a future time period and outputs the launch probability of each candidate application. The mobile phone obtains the launch probability of each candidate application output by the AI ​​model and arranges these candidate applications in descending order of launch probability. The mobile phone determines the top k candidate applications as the aforementioned k applications.

[0272] In an optional embodiment, the mobile phone inputs user historical data into an AI model. Based on this data, the AI ​​model predicts the probability of each candidate application being launched by the user within a future time period. The AI ​​model then ranks these candidate applications in descending order of launch probability, identifies the top k candidate applications as the k applications, and outputs application identifiers for these k applications. The mobile phone obtains the application identifiers of the k applications output by the AI ​​model and identifies the k applications based on these identifiers. The application identifier can serve as a unique identifier for each candidate application.

[0273] S452. Based on k applications, obtain the application list.

[0274] In some embodiments, the mobile phone may identify all k applications as applications included in the application list.

[0275] In other embodiments, the mobile phone can select multiple applications from the k applications based on the device's remaining memory information and the memory usage data of the k applications to obtain an application list.

[0276] For example, the remaining memory information may indicate the size of the remaining memory of the device (edge ​​device or cloud device) to which the method is applied, and optionally, it may also indicate the minimum remaining memory required by the device.

[0277] For example, the phone can determine the size of the remaining memory as the size of the available memory. Alternatively, the phone can determine the size of the remaining memory as the product of the size of the remaining memory and a first threshold.

[0278] The memory usage data for the k applications is the predicted memory usage data for each of the k applications based on the memory usage data of the k applications under historical running conditions.

[0279] In some embodiments, the memory usage data of k applications is the historical memory usage data of those k applications.

[0280] For example, an application's memory usage data can be calculated based on the application's memory usage data during previous launches. Alternatively, the application's memory usage data can be obtained manually.

[0281] For example, if application A's memory usage during a single launch is data A, the phone can determine data A as the application's memory usage. As another example, if application A's memory usage during multiple launches is data B, data C, data D, and data E respectively, the phone calculates the average of data B, C, D, and E and determines this average as the application's memory usage. Furthermore, if the mode of application A's memory usage during multiple launches is data F, the phone can determine data F as the application's memory usage. Finally, if the maximum value of application A's memory usage during multiple launches is data G, the phone can determine data G as the application's memory usage.

[0282] In a specific embodiment, if the device's remaining memory is greater than or equal to the memory usage data (i.e., the memory size) of k applications, the phone determines that these k applications are the multiple applications; that is, all k applications are applications in the application list. If the device's remaining memory is less than the memory usage size of the k applications, the phone can select some applications from the k applications to include in the application list.

[0283] In some embodiments, the phone sums the memory sizes of a subset of k applications. If the sum is less than or equal to the device's remaining memory, the phone includes that subset of applications in the application list.

[0284] In this embodiment, an AI model can be used to predict multiple applications that a user expects to launch in the future based on historical user data. This AI model can accurately predict the k applications the user is likely to launch in the future. Then, based on these k applications, a list of applications for accelerated launch is obtained. Before receiving a user's instruction to launch any application from this list, the processes for the applications the user is likely to use in the future are created in advance, and the necessary I / O files for launching these applications are mounted to the corresponding processes. Optionally, child processes shared by these applications can also be preloaded. Thus, after receiving the user's instruction, the application can be launched directly based on the created application process and the I / O files mounted to that process, without needing to create the process and read the I / O files after receiving the user's instruction. This reduces the application launch latency and improves the application launch speed for multiple applications the user is likely to launch in the future.

[0285] Furthermore, based on the k applications that users expect to launch within a future time period obtained through AI models, the necessary resources for the launch process can be pre-allocated to these k applications, improving resource utilization efficiency and avoiding bottlenecks when multiple applications request resources.

[0286] In this embodiment, when obtaining the application list based on the k applications, some or all applications can be selected from the k applications based on the device's remaining memory and the memory usage of the k applications to obtain the application list for accelerated startup. Because in the method for accelerating application startup, before receiving an instruction to start the application, a certain amount of memory space needs to be sacrificed so that the memory occupied by the application process is filled with I / O files. Therefore, in the scenario of accelerating the startup of multiple applications in the application list, to avoid excessive memory usage, all or some applications can be reasonably selected from the k applications to form the application list based on the potential memory size occupied by the k applications and the device's remaining memory. This not only accelerates the startup of multiple applications in the application list but also avoids excessive memory usage and memory lag issues, thus providing a more stable application running experience.

[0287] In some embodiments, the mobile phone can obtain the application list at specified intervals.

[0288] For example, the duration of the specified period can be the same as the duration of the future time period in S451 above. For example, if the duration is 10 minutes, the phone can predict k applications once every 10 minutes through the AI ​​model to obtain an application list, so as to realize process preloading, file pre-reading and child process preloading (optionally) of each application in the application list, so as to accelerate the startup of any application in the application list.

[0289] In this embodiment, considering that the applications users expect to launch may differ at different times, periodically obtaining the application list ensures that the periodically obtained application list better matches the user's expectations for future applications. Thus, as time progresses, the application list obtained by the method of this embodiment may change compared to the previous period, allowing the application list to dynamically change as the applications that may be launched in future time periods change. This increases the probability that applications that preload processes and pre-fetch files are applications that users expect to launch in the future, thereby avoiding the waste of memory space caused by pre-fetching files and improving memory utilization.

[0290] In addition, based on the latest application list, the necessary resources for subsequent startup can be pre-allocated to the applications in the application list to ensure that applications with a high probability of being launched in the future can obtain the required CPU, memory and other resources, and avoid increasing the application startup latency due to resource shortage during the startup process, which would affect the user experience.

[0291] Example 4

[0292] In some embodiments, the mobile phone can periodically obtain an application list, and each application process in the application list obtained each time (i.e., each cycle) will occupy memory resources (because the IO file corresponding to the process is written). This will cause memory to be continuously occupied. To avoid excessive memory occupation, memory reclamation can be performed.

[0293] Figure 6 A schematic diagram illustrating the memory reclamation process in an embodiment of this application is provided. This process can be incorporated into any of the above embodiments.

[0294] like Figure 6 As shown, the method flow may include, but is not limited to, the following steps:

[0295] S601. Obtain the application list according to the specified period.

[0296] In combination with the above Figure 5S451 and S452 in the text refer to how the AI ​​model can predict k applications according to a specified period and obtain an application list based on these k applications, so that the application list can also be obtained according to the specified period.

[0297] S602. Compare the application list obtained in this period with the application list obtained in the previous period.

[0298] In some embodiments, the mobile phone can determine applications that exist in the application list of the current period but not in the application list of the previous period (such as the first application and the second application mentioned above) by comparing the application list of the current period with the application list of the previous period. The mobile phone then performs the following S603 and S604 on these applications (such as the first application and the second application mentioned above).

[0299] S603. Create the application process.

[0300] The specific process is similar to S401 and S501 mentioned above, and will not be described in detail.

[0301] S604. Write the application's corresponding IO file into the application's process.

[0302] The specific process is similar to S402 and S502 mentioned above, and will not be elaborated further.

[0303] To illustrate with a specific example, as shown in Table 2 below, the application list for the previous period included application 1, application 2, and applications 4 through 6, while the application list for this period includes applications 1 through 4, application 7, and application 8.

[0304] The phone determines that applications 3, 7, and 8 are applications that exist in the application list of the current cycle but not in the application list of the previous cycle. For each application in applications 3, 7, and 8, the phone creates a process corresponding to that application and writes the corresponding IO file to that application's process.

[0305] Table 2

[0306]

[0307] In other embodiments, the mobile phone can determine the applications that exist in both the current application list and the previous application list by comparing the application list of the current period with the application list of the previous period (e.g., the first application and the second application mentioned above), and the mobile phone executes S605 on these applications (e.g., the first application and the second application mentioned above).

[0308] S605. Update the application's corresponding IO file to the application's process.

[0309] In an optional embodiment, for each application that exists in the application list of the current cycle and the application list of the previous cycle, the mobile phone can determine the IO file to be updated in the memory of the application by comparing the IO file list of the application obtained in the current cycle with the IO file list of the application obtained in the previous cycle, and then update (e.g., add, delete, or modify) the IO file to be updated in memory based on the IO file list of the application obtained in the current cycle.

[0310] Based on the specific examples above, as a concrete example, the phone determines that Application 1, Application 2, and Application 4 are applications that exist in the application list of the current cycle and the application list of the previous cycle. For each application in Application 1, Application 2, and Application 4, the phone updates the corresponding IO file to the application process.

[0311] For example, taking application 1 as an example, the same logic applies to applications 2 and 4. The list of IO files for application 1 obtained by the phone in the current cycle may include IO file 1, IO file 3, IO file 4, and IO file 6. The list of IO files for application 1 obtained by the phone in the previous cycle may include IO file 1 and IO file 3. The phone can pre-read IO files 4 and IO file 6 from the disk and write them to the memory of process 1 corresponding to application 1. This is an example of adding IO files.

[0312] For example, the list of IO files for application 1 obtained by the phone in the current cycle may include IO file 1, IO file 3, IO file 4, and IO file 6. The list of IO files for application 1 obtained by the phone in the previous cycle may include IO file 1 and IO file 3'. The phone can pre-read IO files 4, 6, and 3 from the disk. For instance, if IO file 3 is an updated IO file with the same name as IO file 3', the phone can write the read IO files 4 and 6 into the memory of process 1 corresponding to application 1, and update the IO file 3' in the memory of process 1 to IO file 3. This is an example of adding and updating IO files.

[0313] For example, the list of IO files for application 1 obtained by the phone in the current cycle may include IO file 1 and IO file 3, while the list of IO files for application 1 obtained by the phone in the previous cycle may include IO file 1, IO file 3, and IO file 4. The phone can delete IO file 4 from the memory of process 1 corresponding to application 1. Here is an example of deleting an IO file.

[0314] In some other embodiments, the mobile phone can determine a third application that does not exist in the application list of the current period but exists in the application list of the previous period by comparing the application list of the previous period with the application list of the current period, and the mobile phone executes S606 on these applications.

[0315] S606. Reclaim memory from third-party applications.

[0316] Based on the specific examples above and referring to Table 2, as a specific example, if the phone determines that applications 5 and 6 are third applications that do not exist in the application list of the current cycle but exist in the application list of the previous cycle, the phone can reclaim the memory of applications 5 and 6.

[0317] Optionally, the phone can also kill the process created by application 5 in the previous cycle, and the process created by application 6 in the previous cycle.

[0318] In some embodiments, the third application is different from the foreground application.

[0319] For example, a foreground application refers to an application that has already been launched and is currently running.

[0320] In an optional embodiment, the application list obtained by the mobile phone in S601 according to a specified period does not include foreground applications.

[0321] In a specific embodiment, the mobile phone can set the foreground application as an application in the whitelist, and then the mobile phone can obtain the application list based on the whitelist, wherein the applications in the application list do not include the applications in the whitelist.

[0322] Alternatively, during AI prediction, remove the k predicted applications that are identical to those in the whitelist, resulting in k' applications. Then, based on these k' applications, obtain the application list (the principle is the same as...). Figure 5 (Same as S452);

[0323] Alternatively, after S602, the third application obtained from the comparison can be compared with the whitelist to delete the applications that match the whitelist among the multiple third applications, so that foreground applications that were accelerated in the previous cycle but were not accelerated in the current cycle but are currently running will not be reclaimed from memory.

[0324] In the process of obtaining an application list based on k applications in S452, the mobile phone can include applications that are not in the foreground among the k applications in the application list.

[0325] In an optional embodiment, before executing S606 to reclaim the memory of the third application, the phone may delete the application running in the foreground from the identified third applications. That is, if the third application is in the foreground, the phone does not reclaim the memory of the third application; if the third application is not in the foreground, the phone reclaims the memory of the third application.

[0326] In the embodiments provided in this application, the third application differs from the foreground application and can only reclaim memory from non-foreground applications, avoiding the reclamation of foreground application memory and thus preventing impact on user experience. Furthermore, frequent reclamation of foreground application memory may lead to system instability, increasing the probability of application crashes or anomalies. By protecting foreground applications from memory reclamation, these problems can be reduced, enhancing the overall stability of the system.

[0327] In the embodiments provided in this application, the applications whose memory is reclaimed are those that exist in the application list obtained in the previous cycle but not in the application list obtained in the current cycle. These applications have a low probability of being launched by users in the future. Reclaiming the memory of these applications with a low probability of launch can free up memory, avoid excessive memory occupation, reduce memory pressure, and allow other running applications to use memory more efficiently, thereby improving the overall performance of the system. At the same time, clearing memory fragments can keep the memory layout more compact and orderly, and can better allocate memory when a large amount of contiguous memory space is required.

[0328] In optional embodiments, the application launch method provided in this application can be applied to various operating systems and can also work in conjunction with various hardware devices. Applicable operating systems may include Windows, Linux, Android, etc., and working hardware may include solid-state drives (SSDs), random access memory (RAM), etc.

[0329] In optional embodiments, the method provided in this application can be used to launch various applications, such as mobile applications, desktop applications, and servers. Mobile applications refer to applications used on mobile devices, while desktop applications refer to applications used on personal computers (PCs). Mobile devices may include mobile phones, tablets, etc. For example, when the application is a mobile application, the solution provided in this application can improve the launch speed of applications such as games and social applications, enhancing user experience; when the application is a desktop application, the solution provided in this application can improve the launch speed of applications such as office software and design software, improving work efficiency; when the application is a server, the solution provided in this application can improve the launch speed of the server, thereby improving the server's response speed. The user can launch the application, thus accelerating the launch speed of applications corresponding to services purchased by the user.

[0330] In some embodiments, the startup method provided in this application may be provided to users in the form of a software license or as a system service.

[0331] In some embodiments, it can be determined whether the application launch method provided in this application has been used by at least one of the following:

[0332] 1. Open the application multiple times and observe its startup latency. If the startup latency is shortened when a specific application is launched, it can be confirmed that the application startup method described in this application is being used.

[0333] 2. Determine whether the aforementioned wake-up phase exists between receiving a user's instruction to launch the application and the completion of the launch process. This wake-up phase may include transmitting application launch events (e.g., transmitting a user's instruction to launch the application) and creating the application's corresponding process. If no wake-up phase exists, it can be determined that the application launch method of this application was used.

[0334] 3. Check the number of idle processes in the Task Manager. Before receiving the user's instruction to start the application, a large number of idle processes are created. Without using the method of this embodiment, very few empty processes are created (e.g., one or two) before receiving the user's instruction to start the application. Furthermore, if the number of empty processes decreases after receiving the aforementioned user instruction, it can be determined that the application startup method of this application has been used.

[0335] 4. Observe the memory usage of the empty process. If the memory usage of the empty process is significantly greater than the memory usage of the process itself, it can be confirmed that the application startup method of this application is being used.

[0336] 5. If no user operation is received, but the CPU load is high or the device power consumption is high, it can be determined that the application startup method of this application is used.

[0337] Of course, the above detection method using the application launch method of this application is merely exemplary, and this application does not impose any limitations on it.

[0338] Corresponding to the above application launch method, this application also provides an application launch device. Figure 7 For an exemplary schematic diagram of an application launch device 700, please refer to... Figure 7 The application startup device 700 includes:

[0339] The preprocessing module 701 is used to receive a user operation that instructs the startup of a first application. Before receiving the user operation, the preprocessing module creates a first process of the first application and writes a first IO file corresponding to the first application to the first process. The first process is an empty process when it is created. The startup module 702 is used to respond to the user operation and execute the first process to display the application interface of the first application. The application interface is the startup interface of the first application. The first IO file is a file that needs to be loaded when the first application is started.

[0340] In one possible implementation, during the execution of the first process, the first process is the main process of the first application.

[0341] In one possible implementation, before receiving a user operation, the application launch device 700 further includes: an acquisition module (not shown) for acquiring an application list, which includes multiple applications, including a first application and a second application; the preprocessing module 701 is further used to create a second process of the second application and write a second IO file corresponding to the second application to the second process, wherein the second process is an empty process when it is created.

[0342] In one possible implementation, before receiving the user operation and after obtaining the application list, the application launch device 700 further includes a loading module (not shown) for loading a common subprocess between the first application and the second application. This subprocess is a process that both the first application and the second application need to load when they start, and the first process is used to launch the first application based on this subprocess.

[0343] In one possible implementation, the acquisition module is specifically used to: predict, using an AI model and based on the user's historical data, the k applications that the user expects to launch in a future time period, where k ≥ 2 and k is an integer, the user's historical data indicating the historical usage data of the candidate applications, the candidate applications including the k applications; and obtain the application list based on the k applications.

[0344] In one possible implementation, the acquisition module is specifically used to: select multiple applications from the k applications based on the device's remaining memory information and the memory usage data of the k applications, in order to obtain the application list.

[0345] In one possible implementation, the acquisition module is specifically used to: acquire a list of applications according to a specified period.

[0346] In one possible implementation, the application launch device 700 further includes: a determination module (not shown) for determining a third application, which exists in the application list obtained in the previous cycle but not in the application list obtained in the current cycle; and a recycling module (not shown) for recycling the memory occupied by the third application.

[0347] In one possible implementation, the third application differs from the foreground application.

[0348] The effect of the application launch device 700 described above is similar to that of the application launch method executed by the mobile phone in the above embodiments, and will not be described again here.

[0349] It is understood that, in order to achieve the above-mentioned functions, the application launch device includes hardware and / or software modules corresponding to the execution of each function. Based on the algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

[0350] In one example, Figure 8 The diagram shows a schematic block diagram of an application launch device 800 according to an embodiment of the present application. The application launch device 800 may include: a processor 801, optionally a transceiver / transceiver pin 802, and optionally a memory 803.

[0351] The various components of the application startup device 800 are coupled together via bus 804, which includes a data bus, a power bus, a control bus, and a status signal bus. However, for clarity, all buses are referred to as bus 804 in the figure.

[0352] Optionally, the memory 803 can be used for the instructions in the foregoing method embodiments. The processor 801 can be used to execute the instructions in the memory 803 to implement the foregoing method. Furthermore, the processor 801 can be used to control the receive pin to receive signals and to control the transmit pin to transmit signals.

[0353] Optionally, the processor 801 is used to run computer programs or software code or instructions 508 therein to implement the application startup methods provided in the embodiments of this application.

[0354] For example, the structure of the client in this application may not be subject to... Figure 8 The client 800 can be a standalone device or part of a larger device. For example, the application launcher 800 can be implemented as follows:

[0355] (1) A standalone integrated circuit IC, or chip, or chip system or subsystem; (2) A collection of one or more ICs, optionally including storage components for storing data or instructions; (3) A module that can be embedded in other devices; (4) Vehicle equipment, etc.; (5) Others, etc.

[0356] When the application startup device 800 is implemented as a chip or chip system, the chip or chip system may include a processor and an interface. The number of processors may be one or more, and the number of interfaces may be multiple. Optionally, the chip or chip system may include a memory 803. The processor is used to call and execute instructions from the interface, and when the processor executes the instructions, it can implement the steps of the above method embodiments.

[0357] The application startup device 800 can be the end-side device or the chip of the end-side device in the above method embodiments.

[0358] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0359] This embodiment also provides a computer storage medium storing computer instructions. When the computer instructions are executed on the terminal device, the terminal device performs the above-described related method steps to implement the application startup method in the above embodiment.

[0360] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the application startup method described in the above embodiment.

[0361] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component, or module. The apparatus may include a connected processor and a memory; wherein the memory is used to store computer execution instructions, and when the apparatus is running, the processor may execute the computer execution instructions stored in the memory to cause the chip to execute the application startup method in the above method embodiments.

[0362] In this embodiment, the client, computer storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0363] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0364] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0365] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0366] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0367] Any content in the various embodiments of this application, as well as any content in the same embodiment, can be freely combined. Any combination of the above content is within the scope of this application.

[0368] The steps of the methods or algorithms described in conjunction with the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0369] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

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

Claims

1. An application launch method, characterized in that, Applied to edge-side devices or cloud-side devices, the method includes: Receive user operation, the user operation instructs to start a first application. Before receiving the user operation, create a first process of the first application and write a first input / output IO file corresponding to the first application to the first process. The first process is an empty process when it is created. In response to the user operation, the first process is executed to display the application interface of the first application, the application interface being the startup interface of the first application, wherein the first IO file is a file required to be loaded when starting the first application.

2. The method according to claim 1, characterized in that, During the execution of the first process, the first process is the main process of the first application.

3. The method according to claim 1 or 2, characterized in that, Before receiving a user action, the method further includes: Obtain an application list, which includes multiple applications, including the first application and the second application; A second process for the second application is created, and a second IO file corresponding to the second application is written to the second process. The second process is an empty process when it is created.

4. The method according to claim 3, characterized in that, Before receiving the user action and after obtaining the application list, the method further includes: Load a common subprocess between the first application and the second application. The subprocess is a process that both the first application and the second application need to load when they start. The first process is used to start the first application based on the subprocess.

5. The method according to claim 3, characterized in that, The process of obtaining the application list includes: Using an artificial intelligence (AI) model, based on user historical data, predict the k applications that the user expects to launch in a future time period, where k ≥ 2 and k is an integer. The user historical data indicates the historical usage data of the candidate applications, and the candidate applications include the k applications. Based on the k applications, the application list is obtained.

6. The method according to claim 5, characterized in that, The process of obtaining the application list based on the k applications includes: Based on the device's remaining memory information and the memory usage data of the k applications, multiple applications are selected from the k applications to obtain the application list.

7. The method according to any one of claims 3 to 6, characterized in that, The process of obtaining the application list includes: Retrieve the application list at a specified interval.

8. The method according to claim 7, characterized in that, The method further includes: A third application is identified, which exists in the application list obtained in the previous period but does not exist in the application list obtained in the current period. Reclaim the memory occupied by the third application.

9. The method according to claim 8, characterized in that, The third application is different from the foreground application.

10. An application initiation device, applied to an end-side device or a cloud-side device, characterized in that, The application launch device includes: The preprocessing module is used to receive user operations, the user operations instructing the launch of a first application. Before receiving the user operations, the module creates a first process of the first application and writes a first input / output (IO) file corresponding to the first application to the first process. The first process is an empty process when it is created. A startup module is used to respond to the user operation by executing the first process to display the application interface of the first application, wherein the application interface is the startup interface of the first application, and the first IO file is a file that needs to be loaded when starting the first application.

11. The apparatus according to claim 10, characterized in that, During the execution of the first process, the first process is the main process of the first application.

12. The apparatus according to claim 10 or 11, characterized in that, The device further includes: The acquisition module is used to acquire an application list, which includes multiple applications, including the first application and the second application. The preprocessing module is also used to create a second process of the second application and write a second IO file corresponding to the second application to the second process. The second process is an empty process when it is created.

13. The apparatus according to claim 12, characterized in that, The device further includes: A loading module is used to load a common sub-process between the first application and the second application. The sub-process is a process that needs to be loaded when both the first application and the second application start. The first process is used to start the first application based on the sub-process.

14. The apparatus according to claim 12, characterized in that, The acquisition module is specifically used for: Using an artificial intelligence (AI) model, based on user historical data, predict the k applications that the user expects to launch in a future time period, where k ≥ 2 and k is an integer. The user historical data indicates the historical usage data of the candidate applications, and the candidate applications include the k applications. Based on the k applications, the application list is obtained.

15. The apparatus according to claim 14, characterized in that, The acquisition module is specifically used for: Based on the device's remaining memory information and the memory usage data of the k applications, multiple applications are selected from the k applications to obtain the application list.

16. The apparatus according to any one of claims 12 to 15, characterized in that, The acquisition module is specifically used for: Retrieve the application list at a specified interval.

17. The apparatus according to claim 16, characterized in that, The device further includes: The determination module is used to determine a third application, which exists in the application list obtained in the previous period but does not exist in the application list obtained in the current period. The recycling module is used to reclaim the memory occupied by the third application.

18. The apparatus according to claim 17, characterized in that, The third application is different from the foreground application.

19. A cloud-side device, comprising a processor and a memory, characterized in that, The processor executes programs or instructions stored in the memory to cause the cloud-side device to implement the method described in any one of claims 1 to 9.

20. An edge device, comprising a processor and a memory, characterized in that, The processor executes a program or instructions stored in the memory to cause the end device to implement the method described in any one of claims 1 to 9.

21. An application activation device, characterized in that, The application launch device includes a processor and a memory, the processor being configured to execute instructions stored in the memory, and when the instructions are executed by the processor, the processor being configured to perform the method as described in any one of claims 1 to 9.

22. A computer-readable storage medium, characterized in that, Includes a computer program that, when running on a computer or processor, causes the computer or processor to perform the method as described in any one of claims 1 to 9.

23. A computer program product, characterized in that, The computer program product includes a software program that, when executed by a computer or processor, causes the steps of the method described in any one of claims 1 to 9 to be performed.

24. A chip, characterized in that, The chip includes a processor and a communication interface, wherein the processor is configured to call and execute instructions from the communication interface, and when the processor executes the instructions, it implements the method as described in any one of claims 1 to 9.

Images