CN115562743B - Application program loading method and electronic device - Google Patents

Abstract

The application discloses an application program loading method and electronic equipment, relates to the field of electronic equipment, and solves the problem that a user needs to wait for loading an application program when opening a common application program. The specific scheme is as follows: loading at least one application program onto the virtual screen, wherein after the at least one application program is loaded onto the virtual screen, the display screen does not display an interface of the at least one application program, and the at least one application program comprises a first application program; intercepting a first message and/or broadcast sent by a first application program to a receiver at a first moment; storing the first message and/or broadcast when the first message and/or broadcast is a non-timeliness message; receiving an operation of starting a first application program by a user at a second moment; and responding to the operation of starting the first application program by the user, switching the first application program from the virtual screen to the display screen, displaying the interface of the first application program on the display screen, sending the stored first message and/or broadcast to the receiver, and enabling the second moment to be later than the first moment.

Description

Application loading method and electronic device

Technical field

The present application relates to the field of electronic equipment, and in particular, to an application loading method and electronic equipment.

Background technique

With the continuous development of smart phones, their performance has been continuously upgraded and their functions have been continuously enriched. People use smart phones more and more frequently. Generally, smart phones realize rich functions through various applications (applications, APPs) installed inside. For example, users can listen to audio novels or podcasts through audiobook apps installed on smartphones. For another example, users can conduct travel navigation, check real-time traffic conditions, etc. through the navigation APP installed on their smartphones.

Smartphones currently on the market will wait for a period of time when cold-starting an application. Only after the smartphone has completed loading the application can the user's expected operable interface be displayed. Among them, the waiting time for game applications to start is as long as 15-30 seconds, which affects the user experience.

Contents of the invention

This application provides an application loading method and electronic device, which solves the problem that users need to wait for application loading when opening commonly used applications.

In order to achieve the above objectives, this application adopts the following technical solutions:

In a first aspect, this application provides an application loading method, which is applied to an electronic device. The electronic device includes a display screen and a virtual screen. The electronic device is installed with multiple applications. The method includes: loading at least one application program onto the virtual screen. , after at least one application program is loaded into the virtual screen, the display screen does not display the interface of the at least one application program, and the at least one application program includes the first application program; intercepting the first message sent by the first application program to the recipient at the first moment and/or broadcast; when the first message and/or broadcast is a non-timely message, save the first message and/or broadcast; receive the user's operation of starting the first application at the second moment; respond to the user starting the first application The operation of the application program switches the first application program from the virtual screen to the display screen, displays the interface of the first application program on the display screen, and sends the saved first message and/or broadcast to the recipient, and the second moment is later than The first moment.

Using the above technical solution, the electronic device can predict the user's operation behavior and preload the application before the user starts the application. Therefore, when the user wants to start the corresponding application program, the electronic device can directly display the operable interface of the corresponding application program on the home screen, thereby reducing the user's perceived time for starting the corresponding application program (the perceived time for starting the application program, that is, The time elapsed from the time the user launches the application to the time the electronic device displays the operable interface of the application on the home screen). In this way, the smooth experience when the user starts the application can be improved, and the response speed of the electronic device when the user starts the application can be improved. Moreover, when the application is loaded on the virtual screen, the relevant resources of the application can be managed and controlled, thereby preventing the application loaded on the virtual screen from interfering with the application normally used by the user. For example, the messages or broadcasts sent by applications loaded on the virtual screen are controlled to prevent the corresponding applications from interacting with other applications or system processes, so that the applications loaded on the virtual screen are not perceived by the user.

In one possible implementation, the display screen is an actual screen of the electronic device, and the images displayed on the display screen are visible to the user. The virtual screen is a simulated screen of the electronic device, and the images displayed on the virtual screen are invisible to the user.

Among them, there is no difference between the virtual screen and the display screen when it comes to loading applications. Applications can be loaded onto the virtual screen and display screen normally through the system startup process. It’s just that the virtual screen is a simulated screen and the images on it are not visible to the user.

In another possible implementation, the virtual screen corresponds to the display screen.

For example, the virtual screen and the display screen may have the same resolution and size.

In another possible implementation, the method further includes: intercepting a second message and/or broadcast received by the first application at a third moment, where the second moment is later than the third moment; When the broadcast is a non-timely message, save the second message and/or broadcast; after receiving the user's operation to start the first application at the second moment, the method also includes: sending the saved second message and/or to the first application. or broadcast.

In this way, the messages or broadcasts received by the applications loaded on the virtual screen can be controlled, thereby preventing the corresponding applications from interacting with other applications or system processes, so that the applications loaded on the virtual screen are not perceived by the user.

In another possible implementation, when saving the first message and/or broadcast, merge it with the previously saved message and/or broadcast; when saving the second message and/or broadcast, merge it with the previously saved message and/or broadcast. Messages and/or broadcasts of the same type are merged.

In this way, messages or broadcasts of the same type can be merged to save storage space.

In another possible implementation, when saving the first message and/or broadcast, replace the previously saved message and/or broadcast of the same type; when saving the second message and/or broadcast, replace the previous saved message and/or broadcast of the same type. messages and/or broadcasts.

In this way, messages or broadcasts of the same type can be replaced, saving storage space, and messages or broadcasts of this type can be kept as the latest news to ensure their timeliness.

In another possible implementation, the method further includes: when the first message and/or broadcast is a timely message, discarding the first message and/or broadcast; when the second message and/or broadcast is a timely message , discard the second message and/or broadcast.

In this way, since the timely message may have expired when the application is subsequently switched to the display screen, discarding the timely message or broadcast can avoid saving storage space.

In another possible implementation, before receiving the user's operation to start the first application at the second moment, the method further includes: setting the process group of the first application as a background group; The priority value is set to the first value, and the first value is smaller than the preset value. The smaller the priority value, the higher the priority of the process.

Among them, the priority value of the process can be the adj value of the process. The default value can be the adj value corresponding to the perceptible process. When the priority is higher, the process is less likely to be cleaned up in the background. Therefore, by setting the priority value of the process of the first application program to a first value smaller than the preset value, it is possible to prevent the process of the first application program from being easily cleaned up. In this way, after the application is loaded on the virtual screen, it can be set as a background group and a perceptible process to prevent the application from occupying too many system resources. The background management mechanism is cleared. That is, applications loaded on the virtual screen can be kept alive and occupy less system resources.

In another possible implementation, before receiving the user's operation to start the first application at the second moment, the method further includes: caching the notification received by the first application so that the notification is not displayed; the method further includes: : In response to the user's operation of starting the first application, display the above notification on the display screen.

In this way, the notifications received by the application loaded on the virtual screen can be controlled, thereby preventing the notification from being displayed on the notification bar displayed on the display screen and being seen by the user after the application receives the notification. This allows applications to be loaded onto the virtual screen without being perceived by the user.

In another possible implementation manner, caching the notification received by the first application program includes: intercepting the notification received by the first application program; and caching the notification.

In another possible implementation, the notification's time is erased when the notification is cached.

In this way, when the first application is subsequently switched to the display screen for display and the resource management and control on it is released, the time can be re-added to the corresponding notification, thereby preventing the time when the user sees the notification from being inconsistent with the time when it is displayed on the display screen. .

In another possible implementation, before receiving the user's operation to start the first application at the second moment, the method further includes: detecting a pop-up window of the first application; when the pop-up window is a dialog box, specifying the dialog frame to the virtual screen; when the pop-up window is a prompt pop-up window, the prompt pop-up window is discarded. The prompt pop-up window is a pop-up window that will automatically disappear after being displayed.

In this way, pop-up windows of applications loaded onto the virtual screen can be controlled. This prevents the pop-up window of the application from being displayed on the display and seen by the user. This makes it invisible to the user when the application is loaded onto the virtual screen.

In another possible implementation, assigning the dialog box to the virtual screen includes: modifying the screen parameters associated with the dialog box to the virtual screen parameters corresponding to the virtual screen.

In this way, the displayed screen can be reassigned as a virtual screen to conveniently assign the dialog box to the virtual screen.

In another possible implementation, before receiving an operation of the user to start the first application at the second moment, the method further includes: hiding the snapshot of the first application.

Usually, after an application is loaded, the electronic device saves a snapshot of the application interface so that the user can see the corresponding application when entering the multi-task management interface. Therefore, by hiding the snapshot of the first application, it is possible to prevent the user from seeing the first application loaded on the virtual screen when entering the multi-task management interface, so that the application loaded on the virtual screen is not perceived by the user.

In another possible implementation, before receiving the user's operation to start the first application at the second moment, the interface of the first application is only drawn but not rendered.

In this way, the rendering pressure of the electronic device can be reduced, thereby reducing the power consumption of the electronic device and preventing the electronic device from lagging.

In another possible implementation manner, when at least one application is loaded onto the virtual screen, the frequency increase of the processor of the electronic device is limited.

In this way, when the application program is loaded onto the virtual screen, the frequency increase of the processor of the electronic device is avoided, thereby reducing the resource usage when the application program is loaded onto the virtual screen and preventing the electronic device from lagging.

In a second aspect, embodiments of the present application provide an electronic device, including: a processor and a memory configured to store instructions executable by the processor. When the processor is configured to execute the above instructions, the electronic device implements the application loading method as described in the first aspect or any one of the possible implementations of the first aspect.

In a third aspect, embodiments of the present application provide a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed by the electronic device, the electronic device is caused to implement the application loading method as described in the first aspect or any one of the possible implementations of the first aspect.

In a fourth aspect, embodiments of the present application provide a computer program product, including a computer readable code. When the computer readable code is run in an electronic device, the electronic device enables the electronic device to implement the first aspect or the possible implementation of the first aspect. Implement the application loading method described in any of the methods.

It should be understood that the beneficial effects of the above-mentioned second to fourth aspects can be referred to the relevant descriptions in the above-mentioned first aspect, and will not be described again here.

Description of the drawings

Figure 1 is a schematic diagram of an application startup interface provided by the prior art;

Figure 2 is a schematic diagram of another application startup interface provided by the prior art;

Figure 3 is a schematic diagram of another application startup interface provided by the prior art;

Figure 4 is a schematic diagram of a scenario when an application loading method provided by the embodiment of the present application is applied;

Figure 5 is a schematic structural diagram of an electronic device provided by an embodiment of the present application;

Figure 6 is a schematic diagram of a system architecture provided by an embodiment of the present application;

Figure 7 is a flow chart for establishing a three-party feature database provided by an embodiment of the present application;

Figure 8 is another flow chart for establishing a three-party feature database provided by an embodiment of the present application;

Figure 9 is a schematic diagram of key features of an expected interface in an application loading screen provided by an embodiment of the present application;

Figure 10 is another flow chart for establishing a three-party feature database provided by an embodiment of the present application;

Figure 11 is a schematic flowchart of starting a preloading process in an application loading method provided by an embodiment of the present application;

Figure 12 is a schematic diagram of a preload preparation queue provided by an embodiment of the present application;

Figure 13 is a schematic diagram of inserting application 3 into the preload preparation queue provided by the embodiment of the present application;

Figure 14 is another schematic diagram of inserting application 3 into the preload preparation queue provided by the embodiment of the present application;

Figure 15 is a schematic diagram of a message queue provided by an embodiment of the present application;

Figure 16 is a schematic flowchart of controlling an application after starting the preloading process in an application loading method provided by an embodiment of the present application;

Figure 17 is a schematic flowchart of the process of controlling a preloaded application in an application loading method provided by an embodiment of the present application;

Figure 18 is a schematic flowchart of the process of controlling a preloaded application in another application loading method provided by an embodiment of the present application;

Figure 19 is a schematic flowchart of controlling notifications of preloaded applications in an application loading method provided by an embodiment of the present application;

Figure 20 is a schematic flowchart of controlling pop-up windows of preloaded applications in an application loading method provided by an embodiment of the present application;

Figure 21 is a schematic flowchart of controlling the broadcast of a preloaded application in an application loading method provided by an embodiment of the present application;

FIG. 22 is a schematic flowchart of controlling the broadcast of a preloaded application in another application loading method provided by an embodiment of the present application.

Detailed ways

Usually when a user uses an application installed on a smartphone, he or she needs to first open the application on the phone by touching and clicking. When the mobile phone receives the user's operation to open the application, the mobile phone needs to load the application. Only after the mobile phone completes loading the application, the user can use the application.

For example, when a user needs to open a video application installed on a smartphone, such as the "XX Video" application. Users can open the "XX" video by clicking on the "XX Video" application icon on the smartphone desktop. When the smart phone receives the user's click operation on the icon of the "XX Video" application, the smart phone can load and start the "XX Video" application. While the smartphone is loading the "XX Video" application, the startup page of "XX Video" will be displayed on the display interface of the smartphone (for example, an opening screen advertisement page, or a page containing the icon of the application, etc.). After the smartphone completes loading the "XX Video" application, the interface displayed on the smartphone can jump from the startup page of the "XX Video" application to the application page of the "XX Video" application (for example, the home page of the application) . Therefore, users can watch relevant video content by clicking on the relevant content in the "XX Video" application page. For example, the application page of the "XX Video" application displayed on the smartphone includes covers corresponding to video contents such as "Movie 1", "TV Series 2", "Musical 3", and "Animation 4". Users can click on these covers to make the smartphone play the corresponding video content. For example, when the user clicks on the cover of "Movie 1", the smartphone receives the user's above operation and can play the video content of "Movie 1" for the user to watch.

Another example is when the user needs to open a game application installed on the smartphone, such as the "XX Game" application. As shown in Figure 1, the user can open the "XX Game" application by clicking the icon 101 of the "XX Game" application on the desktop of the smartphone. When the smartphone receives the user's click operation on the icon 101 of the "XX Game" application, the mobile phone can load and start the "XX Game" application. During the process of loading the "XX Game" application on the smartphone, as shown in Figure 2, the startup page 202 of "XX Game" (such as an opening screen advertisement page, or as shown in the figure) will be displayed on the display interface of the smartphone. A page containing an application's icon, etc.). After the smart phone completes loading the "XX Game" application, as shown in Figure 3, the interface displayed on the smart phone can jump from the startup page 202 of the "XX Game" application to the application page 303 of the "XX Game" application. (For example, the login interface of the game). Therefore, the user can log in to the game account through the login interface and enter the game interface.

As can be seen from the above, when a user opens an application installed on a smartphone, the phone needs a certain amount of time to load. For example, after loading the application program and passing through at least one startup screen, the application interface that the user can operate (that is, the operable interface expected by the user) can be entered. In particular, the loading time will be longer when the application opened by the user takes up more resources. This will affect the user experience when launching the application.

In order to solve the above problem, embodiments of the present application provide an application loading method, which can be applied in a scenario where an electronic device starts an application.

In this embodiment of the present application, the application loading method may include: when the user uses the electronic device, the electronic device may predict the application that the user may open according to preset rules, and then preload the application into Virtual screen, so that the application can be preloaded in the virtual screen to the operable interface expected by the user (that is, the interface that can be operated by the user after the application is started). Later, when the user starts the application, if the application If the program has been preloaded in the virtual screen, the electronic device can move the application from the virtual screen to the home screen (or display screen, that is, the actual screen on which the electronic device normally displays the screen, and the displayed screen is visible to the user). Displayed for users to use the application.

Optionally, the application is preloaded (or called run) on the virtual screen to the operable interface expected by the user (which can be called the first interface), which can be the last interface where the application stays when there is no user operation after cold start. , such as login interface, main interface, etc., there are no restrictions here.

Among them, the virtual screen is a simulated screen of the electronic device, which is non-physical and has the same functions as the actual screen of the electronic device, but the screen displayed is invisible to the user. Optionally, the virtual screen can correspond to the display screen, for example, the virtual screen and the display screen are set to the same resolution, size, etc.

For example, the electronic device can predict the applications that the user may open according to preset rules. For example, if the electronic device predicts that the user may open the "XX Game" application in the future, the electronic device will use the application loading method. Preload the "XX Game" application. For example, as shown in a in Figure 4, the "XX Game" application can be loaded onto the virtual screen, so that the application can be loaded onto the user's desired operable interface 401 on the virtual screen (as shown in the figure account login interface). After that, as shown in b in Figure 4, when the user prepares to start the "XX Game" application by clicking the icon 402 of the "XX Game" application, as shown in c in Figure 4, the electronic device can directly The operable interface 401 of the "XX Game" application preloaded on the virtual screen is switched and displayed on the home screen (such as the account login interface).

Through this method, the electronic device can predict the user's operation behavior to preload an application before the user launches the application. Therefore, when the user wants to start the corresponding application program, the electronic device can directly display the operable interface of the corresponding application program on the home screen, thereby reducing the user's perceived time for starting the corresponding application program (the perceived time for starting the application program, that is, The time elapsed from the time the user launches the application to the time the electronic device displays the operable interface of the application on the home screen). In this way, the smooth experience when the user starts the application can be improved, and the response speed of the electronic device when the user starts the application can be improved.

Below, the application loading method provided by the embodiment of the present application will be described with reference to the accompanying drawings.

In the embodiment of the present application, the above-mentioned electronic device may be a mobile phone, a tablet computer, a handheld computer, a PC, a cellular phone, a personal digital assistant (PDA), or a wearable device (such as a smart watch, a smart bracelet) , smart home devices (such as televisions), car machines (such as car computers), smart screens, game consoles, smart projectors, smart TV boxes, and augmented reality (AR)/virtual reality (virtual reality, VR) equipment, etc. The embodiments of the present application do not place any special restrictions on the specific device form of the electronic device.

In this embodiment of the present application, the above-mentioned electronic device is an electronic device that can run an operating system and install applications. Optionally, the operating system running on the electronic device may be System,/> System,/> system etc.

For example, taking the electronic device as a mobile phone, FIG. 5 shows a schematic structural diagram of an electronic device provided by an embodiment of the present application. That is, as an example, the electronic device shown in FIG. 5 may be a mobile phone.

As shown in Figure 5, the electronic device may include: a radio frequency (RF) circuit 510, a memory 520, an input unit 530, a display unit 540, a sensor 550, an audio circuit 560, and a wireless fidelity (WiFi) module 570 , processor 580, power supply 590, Bluetooth module 5100 and other components. Those skilled in the art can understand that the structure of the electronic device shown in FIG. 5 does not constitute a limitation of the electronic device, and may include more or fewer components than shown, or combine certain components, or arrange different components.

The following is a detailed introduction to some components of electronic equipment in conjunction with Figure 5:

The memory 520 can be used to store software programs and modules. The processor 580 executes various functional applications and data processing of the electronic device by running the software programs and modules stored in the memory 520 . The memory 520 may mainly include a program storage area and a data storage area, where the program storage area may store an operating system, an application program required for at least one function (such as a sound playback function, an image playback function, etc.), and a boot loader. etc.; the storage data area can store data created based on the use of electronic equipment (such as audio data, phone books, etc.), etc. In addition, memory 520 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid-state storage device.

The input unit 530 may be used to receive input numeric or character information and generate key signal input related to user settings and function control of the electronic device. Specifically, the input unit 530 may include a touch panel 531 and other input devices 532 . The touch panel 531 , also known as a touch screen, can collect the user's touch operations on or near the touch panel 531 (for example, the user uses a finger, stylus, or any suitable object or accessory on or near the touch panel 531 operation), and drive the corresponding connection device according to the preset program. Optionally, the touch panel 531 may include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the user's touch orientation, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into contact point coordinates, and then sends it to the touch controller. to the processor 580, and can receive commands sent by the processor 580 and execute them. Specifically, other input devices 532 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), trackball, mouse, joystick, etc. In this embodiment of the present application, the user can input the operation of opening a file in the simulator through the computer system through the touch panel 531, mouse or keyboard.

The display unit 540 may be used to display information input by the user or information provided to the user and various menus of the electronic device. The display unit 540 may include a display panel (such as a display screen) 541. Optionally, the display panel 541 may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. Further, the touch panel 531 can cover the display panel 541. When the touch panel 531 detects a touch operation on or near it, it is sent to the processor 580 to determine the type of the touch event. The processor 580 then determines the type of the touch event. Type provides corresponding visual output on display panel 541. Although in FIG. 5 , the touch panel 531 and the display panel 541 are used as two independent components to implement the input and input functions of the electronic device, in some embodiments, the touch panel 531 and the display panel 541 can be integrated. And realize the input and output functions of electronic equipment.

The processor 580 is the control center of the electronic device. It uses various interfaces and lines to connect various parts of the entire electronic device. It runs or executes software programs or modules stored in the memory 520 and calls data stored in the memory 520 to execute Various functions of electronic equipment and processing data, thereby overall monitoring of electronic equipment. Optionally, the processor 580 may include one or more processing units; preferably, the processor 580 may integrate an application processor and a modem processor, where the application processor mainly processes operating systems, user interfaces, application programs, etc. , the modem processor mainly handles wireless communications. It can be understood that the above modem processor may not be integrated into the processor 580 .

Audio circuit 560 may include speaker 561 and microphone 562. Audio data can be played through the speaker 561, and the microphone 562 can be used to convert the sound signal into audio data.

Of course, it can be understood that the above-mentioned figure 5 is only an exemplary illustration when the device form of the terminal is a mobile phone. If the terminal is a tablet computer, handheld computer, PC, PDA, wearable device (such as smart watch, smart bracelet), smart home device (such as TV), car machine (such as car computer), smart screen, In the case of game consoles, AR/VR devices and other device forms, the structure of the terminal may include fewer structures than that shown in Figure 5 or may include more structures than that shown in Figure 5 , which is not limited here.

The methods in the following embodiments can be implemented in electronic devices with the above hardware structure. The embodiments of the present application will be described below with reference to the accompanying drawings.

In this embodiment of the present application, the electronic device can predict and preload applications based on the user's application usage habits and/or preset prediction rules.

For example, in this embodiment of the present application, in order to implement the above method of providing application preloading, the electronic device may adopt a system architecture as shown in Figure 6 . As shown in Figure 6, the system architecture of the electronic device may include an application layer, a system framework layer (framework layer), a native framework (native), and a hardware layer. The application layer can be used to deploy one or more applications that can run on the electronic device. For example, in the embodiment of the present application, the application layer can be deployed with "XX Game" application, "XX Video" application, etc. The system framework layer can be deployed with real-time systems (such as the first system), non-real-time systems (such as the second system), and third-party feature libraries. The local framework can deploy acquisition systems and performance radars. The hardware layer may include hardware such as CPU and memory, where the memory may include random access memory (RAM) and external memory.

Operations that do not require high real-time performance can be processed through non-real-time systems, that is, operations that can be processed in independent processes. This avoids the problem that all functions run on the system process, causing excessive load and causing lags. Optionally, the non-real-time system may include a preloading module for verifying and constructing parameters required to preload the corresponding application, and a module for creating and managing virtual screen related parameters required for preloading the application. Virtual screen management module, a configuration management module used to maintain preset configuration parameters (such as default preloading time and other parameters), a decision-making module used to decide whether to preload an application, and a decision-making module used to determine the current location of the electronic device. The scene recognition module for scene recognition, the load monitoring module for monitoring the load of electronic equipment, and the related attributes of applications installed in electronic equipment (such as the startup method of the application, the process to be started, the process to be started, etc. The application management module that manages the startup parameters such as the interface, the loading characteristics of the application, etc.).

The real-time system can handle operations that are strongly related to application running status and processes, operations with high real-time requirements (for example, predicting applications that need to be preloaded, performing operations such as preloading of applications), and process management. Operations strongly related to system services such as service (ActivityManagerService, AMS), window management service (WindowManagerService, WMS), package management service (PackageMangerService, PMS), etc. The real-time system can run in a system process (system server). Optionally, based on the above-mentioned functions that can be realized by the real-time system, the real-time system can include a window management module for managing the display window, a proxy module for proxying relevant messages of the application after preloading, and a proxy module for predicting needs. Prediction module for preloading applications, resource management and control module for controlling the resources used by preloaded applications, preloading management module for performing application preloading, etc., used for maintaining and testing applications Dimension testing modules with preloaded functions, etc.

As an example, based on the system architecture shown in Figure 6. A three-party feature library including relevant attribute features of multiple applications can be built in advance. The three-party feature library can include the application types corresponding to each application (such as games, instant messaging, video, payment, news and other application types), the system resources consumed by application loading (such as CPU load, memory usage and power consumption, etc. ), the time it takes for the application to load to the expected interface (i.e., the operational interface) (i.e., the application loading time), etc. Optionally, a corresponding feature library can be established in the cloud server, and then synchronized to the third-party feature library of the electronic device through cloud push.

For example, the application types in the third-party signature database can be collected by screening and scanning mainstream applications.

For example, as shown in Figure 7, you can first select the top N (i.e., Top N) applications in the mainstream application market, and classify them according to the functional definition of each application (i.e., the classification label of the application in the application market). The application type of the corresponding application is screened and confirmed for the first time. Then, you can also scan the property file of each application (such as the Manifest file), and conduct a second screening and confirmation of the application type of the corresponding application based on the parameters in the property file. Thus, the application types corresponding to the selected N applications are determined. Optionally, after the application type of each application is confirmed in the second screening, each application can be manually reviewed (or called manual verification) to determine the corresponding data of the selected N applications. App types. Thus, the respective application types of the N mainstream applications can be obtained. Afterwards, the obtained application types of each of the N applications can be uploaded to the cloud server (i.e., the cloud), and then the cloud server synchronizes the respective application types of the N applications to the three-party feature library of the electronic device. Optionally, the application management module in the non-real-time system can match the application types corresponding to each installed application from the third-party feature library according to the applications installed on the electronic device.

For example, the loading time of applications in the third-party feature library can be collected by identifying the loading screen of mainstream applications.

For example, as shown in Figure 8, you can first select the top N (i.e., Top N) applications in the mainstream application market, and then separately analyze the key features of the expected interface (i.e., the loading end screen) in the loading screen of each application. Define (usually the features in the expected interface that are not easy to change with application updates can be used as key features, such as account login controls, page selection controls, etc.). After that, each application can be cold-started in turn, and the loading screen of the corresponding application during cold-start can be video recorded (the recording frame rate can be low frame rates such as 24 frames, 60 frames, etc., or 120 frames, 240 frames and other high frame rates). Then each frame in the recorded loading screen video can be identified (each frame can be identified sequentially from the middle frame of the video to both ends of the timeline, or each frame can be identified sequentially from the first frame. This (without limitation), when the key features in the loading end screen defined by the corresponding application are identified, the video duration corresponding to the frame can be used as the loading duration of the corresponding application. For example, taking the application as the "XX Game" application, as shown in Figure 9, the key features of the expected interface in the loading screen of the application can be defined as the account login control 901 and the age-appropriate prompt mark 902. Then you can cold-start the application and record the loading screen when the application is cold-started. Each frame in the recorded loading screen is then identified. When the account login control 901 and the age-appropriate prompt identification 902 shown in Figure 9 are recognized, a frame containing the account login control 901 and the age-appropriate prompt identification 902 can be determined as the expected interface, so that the video corresponding to the frame can be The duration is used as the loading duration of the "XX Game" application. Of course, in other possible implementations of the present application, the loading time of the application can also be collected and determined in other ways, which is not limited here.

Optionally, after identifying the defined key features to determine the loading time, the loading time of the application can also be manually verified. And the above method can be repeated multiple times for each application to obtain a relatively accurate loading time.

After obtaining the corresponding loading times of the selected N applications, the obtained loading times of each of the N applications can be uploaded to the cloud server (i.e., the cloud), and then the cloud server will load the respective loading times of the N applications. The duration is synchronized to the third-party feature library of the electronic device. Optionally, the application management module in the non-real-time system can match the loading time corresponding to each installed application from the third-party feature library according to the installed application on the electronic device.

For example, the system resources consumed by loading applications in the third-party signature library can be obtained by loading the mainstream applications.

For example, as shown in Figure 10, you can first select the top N (i.e. Top N) applications in the mainstream application market, and then cold-start each application in sequence. During the application startup process, the CPU load of the electronic device can be obtained periodically. Then, the process identifier (PID) of the corresponding process after the corresponding application is started is obtained, thereby obtaining load information such as memory usage of the process corresponding to the application. Thus, the CPU load, memory usage and other loading system resources consumed by each of the mainstream N applications can be obtained. Optionally, the above method can be repeated multiple times for each application to obtain more accurate and stable data on the system resources consumed by loading, which is not limited here. After that, the obtained system resources consumed by loading each of the N applications can be uploaded to the cloud server (i.e., the cloud), and then the cloud server synchronizes the system resources consumed by each loading of the N applications to the three-party characteristics of the electronic device. in the library. Optionally, the application management module in the non-real-time system can match the system resources consumed by loading corresponding to each installed application from the third-party feature library according to the applications installed on the electronic device.

In this embodiment of the present application, the system architecture shown in Figure 6 is based on the above. Electronic devices can predict the applications that users are likely to open in the future through prediction modules in real-time systems. For example, the prediction module can use high-frequency rule learning models, contextual rule learning models, etc. to convert input application logs into rule sets as filtering conditions for applications that may be launched by users, and then combine them with the current scene and other characteristics to use FP -TREE and sequential pattern mining (PrefixSpan, CM-SPADE, etc.) algorithms calculate the applications that users may use next or within the next period of time.

For example, the prediction module can learn high-frequency behavior patterns to form user behavior portraits. For example, through high-frequency behavior pattern learning, we can obtain the time when the user leaves home, the time when he or she arrives at work, etc., as well as which applications the user often opens after leaving home (such as navigation applications, taxi-hailing applications, etc.), and the time when the user arrives at the company. Which applications are frequently opened (such as clock-in applications, email applications, etc.). Therefore, the prediction module can predict the learned corresponding application as an application that the user may open when it recognizes that the user is leaving home or going to the company. Optionally, the applications that the user may open in the future may be periodically predicted (the applications that may be opened within a certain period of time in the future (such as one hour) may be predicted). The final prediction result may be the package name of the predicted application to be started (ie, the preloaded application) and the time period during which the application may be started (ie, the time period during which the application may be used by the user). The prediction results, such as the package name of the preloaded application and its corresponding time period that may be used by the user, can then be sent to the preloading module, so that the preloading module can preload and start the corresponding application based on the prediction results.

For example, the prediction module can predict that the applications that may be used by the user in the next hour are Application 1 and Application 2, and the time period in which Application 1 may be used by the user is from 9:00 to 9:10 in the morning. 2The time period that may be used by users is from 9:30 to 10:00 in the morning. At this time, the prediction module can combine the predicted package name of Application 1 and the corresponding time period from 9:00 to 9:10 that may be used by the user, and the predicted package name of Application 2 and the corresponding The time period from 9:30 to 10:00 in the morning that may be used by the user is sent to the preloading module.

For example, the prediction module can also learn contextual behavior rules to form a user behavior profile. For example, through contextual behavior rule learning, we can learn the contextual habits of users who often open another application after opening one application (for example, when users open a conferencing application, they will also open a recording application, etc.). Therefore, when the prediction module recognizes that the user has opened application 1, it can predict application 2 associated with application 1 in the learned contextual habits as an application that the user may open.

Optionally, when the prediction module predicts an application that the user may open and the prediction accuracy reaches a threshold, the prediction module can proactively notify the preloading module to preload the corresponding application.

Alternatively, the prediction module may provide a query interface to the preloading module for the preloading module to query applications predicted to be likely to be opened by the user. This facilitates the preloading module to prepare for preloading the corresponding application.

In some possible implementations, the software system as shown in Figure 6 can also include an artificial intelligence (Artificial Intelligence, AI) module to predict the applications that the user may open in the future through the artificial intelligence module, thereby improving Prediction application accuracy. Optionally, in some other embodiments of the present application, only the AI module may be included and the prediction module may not be included. There is no limitation here. The content of the prediction results predicted by the AI module can be the same as that of the prediction module, and also include predicted applications that may be used by users in a period of time in the future and the corresponding time periods that may be used by users.

After the preloading module obtains the application that needs to be preloaded, the decision-making module can first base on the current scene of the electronic device, the current load of the electronic device, and the application type, loading time, and loading time corresponding to the corresponding application to be preloaded. System resources, etc. are used to make comprehensive decisions to determine whether the corresponding application needs to be preloaded. For example, the load monitoring module in the above system architecture can monitor the current CPU load, memory usage, power information, etc. of the electronic device in real time or periodically. The scene recognition module can identify the current usage scenario of electronic devices in real time or periodically through existing Java or Android mechanisms such as registration, callback, and broadcast. For example, identify whether the current electronic device is charging, whether the screen is turned off, whether it is remotely controlled, whether it is started for the first time, whether it is continuously started, whether it is in a split-screen state, whether it is set to multiple screens, whether it is in a screen casting state, and whether a user Switch etc. According to the foregoing, the application management module manages the application type, loading time, system resources consumed by loading, etc. corresponding to each installed application. Therefore, the decision-making module can obtain the above information from the load monitoring module, scene recognition module and application management module respectively, and then determine whether the current electronic device is based on the current load condition of the electronic device, as well as the time required to load the corresponding application and the system resources consumed. When the conditions for preloading the corresponding application are met, the decision-making module can also make a comprehensive judgment on whether to preload the corresponding application based on the current scenario of the electronic device. For example, the application does not need to be preloaded when the screen is off. For another example, when the scene is split screen, multi-screen or screencasting, it is difficult to determine whether the user needs to open certain applications as usual, so the application does not need to be preloaded at this time.

When the decision-making module determines that an application needs to be preloaded, it is based on the system architecture shown in Figure 6 above. The decision-making module can notify the preloading module of the non-real-time system to preload the application. Therefore, the preloading module can obtain the corresponding virtual screen parameters from the virtual screen management module, and then transfer the virtual screen parameters and information about the application program to be preloaded to the preloading management module of the real-time system. Then, the preloading management module can preload the corresponding application program onto the virtual screen according to the virtual screen parameters and the information of the application program to be preloaded. Among them, when the preloading module obtains the virtual screen parameters, if the virtual screen is not created in the virtual screen management module, the virtual screen management module can first create the virtual screen, and then return the corresponding virtual screen parameters to the preloading module. It should be noted that the virtual screen generally has the same parameters as the main screen, so that the application preloaded on the virtual screen can adapt to the main screen when the application is switched to the main screen.

Optionally, after the corresponding application is preloaded into the virtual screen, the window management module in the real-time system can maintain and proxy all window displays of the preloaded application in the virtual screen. For example, delay the effectiveness of Toast pop-ups, Notify notifications, game assistant pop-ups, etc. of preloaded applications. This prevents pop-up windows, notifications, etc. of applications preloaded to the virtual screen from being displayed on the home screen and affecting the user's normal use of the application being used.

Optionally, after the corresponding application is preloaded into the virtual screen, the agent module in the real-time system can also receive and send broadcasts after the application preloaded in the virtual screen is started, its binder communication with external applications, and its The monitored alarm clock function (alarm) messages and other messages are proxied and the corresponding messages are cached. When the user starts the corresponding application and the application switches to the home screen display, the time-sensitive messages are re-sent or received.

In this embodiment of the present application, the resources of the application program preloaded to the virtual screen can be managed and controlled through the resource management and control module. For example, the audio resources of an application preloaded to the virtual screen can be controlled so that the audio information output by it is not output by the electronic device, thereby avoiding affecting the normal use of the application being used by the user. For another example, the electronic device can be controlled to only draw the display screen of the application preloaded to the virtual screen without rendering, thereby reducing the rendering synthesis pressure of the electronic device and avoiding lagging. For another example, when there are multiple applications preloaded to the virtual screen, the resource management and control module can also freeze and dump the applications that have a reduced probability of being opened by the user among the preloaded applications, thereby further controlling the electronic device. CPU load and memory usage.

Optionally, when the user performs a startup operation on one of the preloaded applications (for example, clicks the icon of the corresponding application), or another application calls one of the preloaded applications, the electronic The device can then switch the display interface of the corresponding application from the virtual screen to the home screen.

For example, when the user clicks the icon of the corresponding application, the system process can notify the preload management module to start the corresponding application. Therefore, the preloading management module can determine whether the corresponding application has been preloaded on the virtual screen. If it has been preloaded on the virtual screen, the preloading management module can notify the resource management and control module to release the resource management and control of the corresponding application and notify the window. The management module releases the window management of the corresponding application program, and notifies the agent module to release the agent management of the message of the corresponding application program. Moreover, the preloading management module can transfer the corresponding application program from the virtual screen to the home screen (ie, the screen currently used to display the screen).

Based on the foregoing embodiments, combined with the system architecture shown in Figure 6, the electronic device can start a preloading process for the application program that needs to be preloaded, so that the application program that needs to be preloaded can be started in the virtual screen. For example, FIG. 11 shows a schematic flowchart of starting a preloading process in an application loading method provided by an embodiment of the present application. As shown in Figure 11, the method of starting the preloading process may include the following S1101-S1127.

When the prediction module and/or the AI module predicts an application that needs to be preloaded, the preloading module can be notified to preload the corresponding application. For example, taking the prediction module as an example (the following is used as an example), the following S1101 can be executed.

S1101. The prediction module predicts the application that needs to be preloaded, and predicts the results, such as the package name of the application that needs to be preloaded and the time period in which the application may be used by the user (or called the preloaded application). usage period) is sent to the preload module.

Among them, the prediction module can periodically learn the recorded user behaviors to obtain user behavior portraits and store the user behavior portraits. Thus, the applications that users may use in the future (such as one hour, etc.) can be predicted based on user behavior portraits, and then the predicted applications that users may use in the future and the corresponding time periods in which they may be used can be predicted. as a prediction result. That is, the predicted applications that users may use in the future are used as applications that need to be preloaded.

Usually, the prediction module predicts multiple applications that need to be preloaded. Of course, in some other possible implementations, the prediction module can also predict only one application that needs to be preloaded at a certain moment. There is no limitation here. .

It should be noted that the prediction module may send the prediction result to the preloading module when the preloading module obtains it, or the prediction module may send the prediction result proactively. There is no limit here. For example, after the prediction module predicts the applications that users may use in the future (such as one hour), it can proactively send the package names of these applications and the corresponding time periods that may be used by users to the preloading module. For another example, when the electronic device detects that the foreground application has changed and the foreground application is Launcher, thereby determining that the current electronic device has returned to the desktop, or detects that the electronic device triggers a screen unlock event (such as listening to the broadcast of the system's ACTION_USER_PRESENT event), Or when it is detected that the electronic device enters the multi-tasking window, the preloading module can actively obtain from the prediction module the package names of the applications that the user may use in a future period of time (such as one hour) and the corresponding time period in which they may be used. For example, the preloading module obtains the prediction results from the prediction module by: the preloading module sends an acquisition request to the prediction module, and after receiving the request, the prediction module sends the corresponding application package name and the corresponding time period that may be used to the preloading module. . Alternatively, the prediction module provides a query interface for the preloading module, so that the preloading module queries the corresponding application package name and the corresponding time period in which it may be used through the query interface.

For example, the prediction module can predict at 8:50 that the applications that the user may use in the next hour include application 1 that may be used from 9:00 to 9:15, and application 1 that may be used from 9:10 to 9:20. Application 2 is used and Application 3 may be used between 9:15 and 9:20. Therefore, at 8:50, the prediction module can predict the package name of application 1 and its corresponding usage time period (9:00 to 9:15), the package name of application 2 and its corresponding usage time. segment (9:10 to 9:20), the package name of application 3 and its corresponding used time period (9:15 to 9:20) are sent to the preloading module as prediction results. This facilitates the preloading module to subsequently preload the corresponding application based on the prediction result.

Correspondingly, the preloading module may execute S1102 as follows.

S1102. The preloading module performs input parameter validity verification on multiple applications that need to be preloaded.

Usually, when the prediction module and/or the AI module predicts an application that needs to be preloaded, it also predicts a time period during which the application that needs to be preloaded may be used by the user. Therefore, the preloading module's verification of the validity of the input parameters of the application that needs to be preloaded may include verification of the time period during which the application may be used by the user. For example, verify whether the current time has exceeded the time period in which the corresponding application that needs to be preloaded may be used by the user. If it has not exceeded, the verification is passed. Therefore, it is possible to avoid the preloading module from preloading the corresponding application when the current time has exceeded the time period that may be used by the user, thereby reducing the situation of preloading applications that no longer need to be preloaded.

For example, based on the above example in S1101, when the prediction result sent by the prediction module includes the package name of application 1 and its corresponding usage time period (9:00 to 9:15), the package name of application 2 and its corresponding The used time period (9:10 to 9:20), the package name of application 3 and its corresponding used time period (9:15 to 9:20). The preloading module can separately verify the usage time periods of Application 1, Application 2 and Application 3 based on the current time. That is, if the current time does not exceed the time period from 9:00 to 9:15, the verification of application 1 passes. When the current time does not exceed the time period from 9:10 to 9:20, the verification of application 2 passes. If the time does not exceed the time period from 9:15 to 9:20, the application 3 verification passes.

Generally, the prediction results sent by the prediction module and/or the AI module to the preloading module can be sent in the form of a message in a specific format (such as a string). Therefore, the validity verification of the input parameters performed by the preloading module can also be a verification of the size of the message sent by the prediction module and whether the information format meets the presets. For example, when the size of the message is larger than the preset value, or when the information format of the message is inconsistent with the preset information format, the verification fails. This reduces the probability of suffering malicious attacks from messages sent by external applications, and avoids the situation where external applications try to preload specified applications through the method of the embodiment of the present application.

Of course, in some possible implementations, the preloading module can separately verify the size of the message sent by the prediction module, the consistency of the information format, and the time period during which the application that needs to be preloaded may be used by the user predicted by the prediction module. When these parameters all pass the verification, it is determined that the input parameter validity verification has passed.

After the preloading module has verified the validity of input parameters for each application predicted by the prediction module that needs to be preloaded, the preloading module can traverse each application that has passed the verification and needs to be preloaded according to the following S1103-S1108. .

S1103. The preloading module obtains one of the application programs that need to be preloaded that passes the verification (for example, the application program 1 illustrated in S1101, etc.).

It should be noted that since it is traversing all the applications that have passed the verification and need to be preloaded, the one application obtained each time is the one that has not been obtained before.

What is usually obtained is the package name of the corresponding application that needs to be preloaded and its corresponding usage time period.

For example, an application can be randomly obtained from the applications that pass the verification and need to be preloaded. You can also first obtain an application with a earlier usage time period from among the applications that have passed the verification and need to be preloaded in accordance with the order of usage time periods corresponding to each application. There is no limit here.

S1104. The preloading module determines whether the applications currently being preloaded and the applications to be preloaded exceed the preset number.

It should be noted that the application program to be preloaded may be an application program that is determined to be preloaded after the preloading module verifies and determines the application program according to S1103-S1108. That is, the application program to be preloaded is an application program that is determined to be preloaded. The application is loaded and ready for preloading. The application currently being preloaded may be the application that the AMS is loading onto the virtual screen.

Among them, the preset number can be set according to the load capacity of the electronic device, etc. When the preset number is exceeded, the preloading module can wait for a certain period of time before re-executing this step. When the preset number is not exceeded, subsequent steps can be executed. This avoids the excessive number of applications that are currently being preloaded, causing the electronic device to freeze or the system to become clogged.

It should be noted that in this embodiment of the present application, a preloading preparation queue (such as preloadready list) may be set, and all applications to be preloaded may be arranged in the queue. For example, as shown in Figure 12, when Application 1 and Application 2 are both applications ready to be preloaded, Application 1 and Application 2 can be arranged in the preloading preparation queue so that they can be followed in accordance with the queue's instructions. The applications to be preloaded are preloaded in order from the head of the queue.

Correspondingly, the preloading module can determine the number of applications currently ready to be preloaded by querying the number of applications in the preloading preparation queue.

Optionally, in this embodiment of the present application, a preloading queue (such as preloadingmap) can also be set, and all preloading applications can be added to the queue.

You can also set up a completed preloading queue (such as preloaded map), and all preloaded applications can be added to the queue. The preloaded application may be an application that has been loaded on the virtual screen.

S1105. The preloading module requests the application management module to verify whether the application (that is, one of the applications that need to be preloaded obtained in S1103) is installed.

Correspondingly, the application management module can return the verification result of whether the application is installed to the preloading module.

For example, the preloading module may send a message to the application management module requesting verification of installation, and the message may include the package name of the application. The application management module can match whether the received package name is in the installed application list stored by the application management module. If it can be matched, the application management module can return to the preloading module a verification result indicating that the application has been installed. Therefore, when the application is installed, the preloading module performs subsequent steps. If the application is not installed, the preloading module can no longer process the application and re-execute S1103 to obtain another application that needs to be preloaded.

S1106. The preloading module determines whether the application is being preloaded, has been preloaded, or is already running in the foreground.

For example, in the embodiment of the present application, if there is a preloading queue (such as preloading map) and a completed preloading queue (such as preloaded map) in the previous example. At this time, the preloading module can separately query the above two queues according to the package name of the application to determine whether the application is being preloaded or has been preloaded. The preloading module can also determine whether the application is already running in the foreground through the foreground process. Therefore, when the application is being preloaded or has been preloaded or is already running in the foreground, the preloading module can no longer process it, but re-execute S1103 to obtain another application that needs to be preloaded. When the application is not preloading, has not completed preloading, and is not running in the foreground, the preloading module can perform subsequent steps.

S1107. The preloading module determines whether the application is an application to be preloaded.

For example, when a preloading preparation queue is set, the preloading module can query the preloading preparation queue according to the package name of the application to determine whether the application is in the preloading preparation queue, thereby determining whether it is Prepare preloaded applications. Therefore, when the application is ready to be preloaded, the preloading module may no longer process it, but re-execute S1103 to obtain another application that needs to be preloaded. When the application is not ready to be preloaded, the preloading module can perform subsequent steps.

It should be noted that in the embodiment of the present application, there is no restriction on the execution order of S1104-S1107.

S1108. The preloading module sets the application in the queue of applications to be preloaded based on the timeliness of the application.

For example, when a preload preparation queue is set, the timeliness of the application can be determined based on its corresponding usage period, and then inserted into the head, middle, or tail of the queue in the preload preparation queue. For example, if the current time is about to reach the usage period corresponding to the application (for example, when the time required for the current time to reach the usage period is less than or equal to the preset time threshold), it can be determined that the preloading of the application is relatively urgent (i.e. timeliness is urgent), the application can be inserted into the head of the preload preparation queue. In other cases, the application can be inserted into the tail of the preloading preparation queue so that all applications ready to be preloaded will be preloaded in the order of the queue. For example, you can set the preset time threshold to 10 minutes. Based on the preload preparation queue shown in Figure 12, if the application is application 3, and the corresponding usage time period is 9:15 to 9:20, and The current time is 9:10, which is 5 minutes different from the usage time period and is less than the preset time threshold. Therefore, the timeliness of the application can be determined to be urgent. As shown in Figure 13, the application (ie Application 3) can be inserted into the head of the preload preparation queue. Or, if the current time is 8:50, the difference from the usage time period is 25 minutes, which is greater than the preset time threshold, so the timeliness of the application can be determined to be non-urgent. As shown in Figure 14, the application (ie application 3) can be inserted into the end of the preload preparation queue.

Optionally, in some other implementations of the embodiments of this application, the prediction module may also determine the timeliness (urgent or non-urgent) of the application based on its corresponding usage time period in the prediction results, and then determine the timeliness (urgent or non-urgent) of the application. Mark the timeliness, for example, add the timeliness identifier of the corresponding application to the prediction result, and then send the identifier to the preloading module along with the package name and time period. Therefore, the preloading module can directly determine the timeliness of the corresponding application based on the timeliness identifier.

After the preloading module sets an application to the queue of the application to be preloaded, the preloading module can send the MSG_PRELOAD_APP message (or the first message) to the message queue through the system process so that the decision-making module can send the message from the message queue. Perform subsequent steps when the MSG_PRELOAD_APP message is received according to the message timing. That is, as shown in Figure 15, as the preloading module traverses the predicted applications that need to be preloaded, it usually sends multiple MSG_PRELOAD_APP messages, and the message queue will include multiple MSG_PRELOAD_APP messages arranged in chronological order. For example, message 1, message 2, message 3, etc., the decision-making module can receive and process the messages in sequence from the message queue according to the sending time of the MSG_PRELOAD_APP message. For example, when the decision-making module receives and processes a MSG_PRELOAD_APP message from the message queue each time, it will execute the following S1409-S1417. Optionally, the number of messages in the message queue corresponds to (ie is the same as) the number of applications to be preloaded (eg, the number of applications in the preloading preparation queue). This ensures that when the decision-making module and the preloading module are processed by multiple processes, the decision-making module can process all applications to be preloaded without omitting them.

Optionally, the message queue can be set up to be cached in memory within the system process. Alternatively, in the system architecture as shown in Figure 6, a message module can also be set up to create and manage the message queue. There is no restriction here.

S1109. The decision-making module obtains the application at the head of the queue of applications to be preloaded (for example, application 3 shown in Figure 13, or application 1 shown in Figure 14).

Usually, the decision-making module obtains the package name of the application and its corresponding usage time period. For example, when a preload preparation queue is set, the decision module may obtain the application at the head of the queue from the preload preparation queue.

Optionally, the decision-making module can also obtain an application from the queue of applications to be preloaded according to other orders or randomly, without limitation here.

S1110. The decision-making module performs legal verification on the application program (that is, the application program at the head of the team obtained by the decision-making module).

For example, considering that there is a queuing time when an application to be preloaded is waiting in the queue to be processed by the decision-making module, after the decision-making module obtains the application, it can verify the usage time period corresponding to the application based on the current time. If the current time has exceeded the usage time period, the verification will not pass. If it has not exceeded the usage time period, the verification will pass. Therefore, it is avoided that the application to be preloaded is preloaded after the usage time period has elapsed due to waiting to be processed by the decision-making module.

Optionally, the decision-making module can also obtain the time required for loading the application from the application management module, and then when the current time plus the time required for loading does not exceed the application usage time period, the verification passes. That is, when the application is preloaded from the current time, if it does not exceed the usage time period, subsequent steps can be performed to preload it. Otherwise, it means that the time after the preloading is completed will exceed the application usage time period, which is invalid preloading. , so if the verification fails, it will no longer be processed.

S1111. The decision-making module determines the importance of the application.

Among them, if the application is an application that the user has a high probability of using in the future, or will use immediately, the application can be considered an important application. Optionally, the prediction module can also identify the importance of the application through importance identification in the prediction results based on the application's usage time period, usage scenarios, predicted probability, etc., along with the package name and usage time period, etc. It is sent to the preloading module together, so that when the preloading module adds the application to the queue of applications to be preloaded, the applications in the queue can carry the importance identifier. Furthermore, the decision-making module can obtain the importance identifier of the application program when acquiring the application program at the head of the queue, so as to determine the importance of the application program based on the importance identifier.

When the decision-making module determines that the importance of the application is non-important, the following S1112-S1114 may be executed.

S1112. The decision-making module obtains the system resources consumed by the application when loading from the application management module.

Among them, based on the aforementioned description of the application management module, the application management module will pre-store the loading time corresponding to each installed application, the system resources consumed during loading, etc.

Correspondingly, when the decision-making module obtains the system resources consumed when the application is loaded, the application management module may return the system resources consumed when the application is loaded to the decision-making module.

For example, the decision-making module can send a request to the application management module to obtain the system resources consumed during loading, and carry the package name of the application. Since the application management module has matched the loading system resources corresponding to each installed application from the third-party feature library, the application management module can find the loading system resources corresponding to the corresponding application according to the package name and return it to the decision-making module.

S1113. The decision-making module obtains the system resources of the current electronic device from the load monitoring module.

It should be noted that, based on the foregoing description of the load monitoring module, the load monitoring module can detect the system resources of the electronic device periodically or in real time, so as to facilitate returning the current electronic device to the decision-making module when the decision-making module obtains the current system resources of the electronic device. system resources.

For example, the decision-making module can send a request to obtain system resources to the load monitoring module.

Correspondingly, the load monitoring module may return the system resources of the current electronic device to the decision-making module.

S1114. The decision-making module determines whether the current system resources support preloading of the application based on the system resources of the current electronic device and the system resources consumed when the application is loaded (that is, whether the current system resources are sufficient to be consumed when the application is loaded, and if so, then Support preloading the application), if supported, perform subsequent steps, if not supported, delay the preset time and send the MSG_PRELOAD_APP message to the message queue, and then the decision-making module can re-obtain a message from the message queue so that the subsequent decision-making module can based on the message queue message in to restart S1109 and subsequent steps. This avoids system lags caused by preloading the application when system resources do not support preloading it.

Among them, because the decision-making module delays for a certain period of time before sending a message to the message queue and re-preloads an application in the preload preparation queue, the number of applications in the preload preparation queue does not change due to the fact that an application is loaded into the virtual screen and decrease. Therefore, the decision-making module here sends messages to the message queue to ensure that the number of messages in the message queue is consistent with the number of applications in the preloading preparation queue.

If the current system resources support preloading the application, you can perform the next steps.

For example, based on the system resources of the current electronic device and the system resources consumed when the application is loaded, determining whether the current system resources support preloading the application may be: when the system resource is a CPU load, determining the current load and the time consumed by loading. Whether the sum of loads is greater than the preset threshold 1, if it is greater, it is determined that the current system resources do not support loading of the application, otherwise it is determined that the current system resources support loading of the application. When the system resources are memory occupied, it is determined whether the current memory occupied minus the memory occupied by loading is less than the preset threshold 2. If it is less than the preset threshold 2, it is determined that the current system resources do not support loading the application, otherwise it can be determined that the current system resources support Load the application.

It should be noted that when the decision-making module determines that the importance of an application is important, the decision-making module may not consider whether the current system resources support preloading the application. That is, the above-mentioned S1112-S1114 are not executed.

S1115. The decision-making module obtains the time required for preloading the last preloaded application (ie, the time required for loading, or the loading time) from the application management module.

Among them, based on the aforementioned description of the application management module, the application management module will pre-store the loading time corresponding to each installed application, the system resources consumed during loading, etc.

Correspondingly, when the decision-making module obtains the time required for preloading the application (ie, the time required for loading), the application management module may return the time required for loading the application to the decision-making module.

For example, the decision-making module can send a request to obtain the loading time to the application management module, and carry the package name of the last preloaded application (the package name of the last preloaded application can be obtained from the preloading module). Since the application management module has matched the loading time corresponding to each installed application from the third-party feature library, the application management module can find the loading time corresponding to the corresponding application based on the package name and return it to the decision-making module.

S1116. The decision-making module determines based on the current time, the time required to load the last preloaded application, and the time when the last preloaded application started preloading (optionally, the last preloaded application can be recorded in the preloading module). The package name of the program and the time when preloading started, so that the decision-making module can obtain the time when the last preloaded application started preloading from the preloading module), and determine whether the last preloaded application is loading (that is, determine Whether there is currently an application being preloaded), if it is not being preloaded, perform subsequent steps, if it is loading, delay the preset time and send the MSG_PRELOAD_APP message to the message queue, and then the decision-making module can re-obtain a message from the message queue for The subsequent decision-making module restarts S1109 and subsequent steps based on the message in the message queue. This avoids preloading the application from affecting the application being preloaded.

Among them, because the decision-making module delays for a certain period of time before sending a message to the message queue and re-preloads an application in the preload preparation queue, the number of applications in the preload preparation queue does not change due to the fact that an application is loaded into the virtual screen and decrease. Therefore, the decision-making module here sends messages to the message queue to ensure that the number of messages in the message queue is consistent with the number of applications in the preloading preparation queue.

For example, determining whether the last preloaded application is loading based on the current time, how long it took for the last preloaded application to load, and the time when the last preloaded application started preloading may be: Determine the last Whether the time when the preloaded application starts preloading plus the time it takes to load is less than or equal to the current time. If it is less than or equal to, it means it is not loading. If it is greater, it means it is loading.

Through this step, it can be determined whether there is currently an application being preloaded, thereby avoiding impact on the application being preloaded when loading the application. Of course, in some other possible implementations of the present application, other methods can be used to determine whether there is an application being preloaded, which is not limited here.

S1117. The decision-making module sends the package name of the application to the preloading module.

S1118. The preloading module obtains virtual screen parameters from the virtual screen management module.

For example, the preloading module sends a request to obtain virtual screen parameters to the virtual screen management module.

Correspondingly, the virtual screen management module will return the virtual screen parameters to the preloading module. The virtual screen parameters may include a virtual screen unique code (identity document, ID).

Optionally, when the preloading module obtains the virtual screen parameters, if the virtual screen management module determines that the virtual screen does not exist, the virtual screen management module will create a virtual screen and then return the virtual screen parameters of the virtual screen to the preloading module (such as virtual screen ID). When the preloading module obtains the virtual screen parameters, if the virtual screen management module determines that the virtual screen is not open, the virtual screen management module will open the virtual screen and return the virtual screen parameters of the virtual screen to the preloading module. Among them, the creation and opening of the virtual screen can be realized through the screen management service (DisplayManagerService, DMS). For example, the virtual screen management module can send a request to create or open a virtual screen to the DMS. After receiving the request, the DMS can create or open the virtual screen and return the virtual screen parameters of the virtual screen to the virtual screen management module.

S1119. The preloading module obtains the startup parameters required to start the application from the application management module.

Correspondingly, the application management module can return startup parameters to the preloading module.

Among them, the startup parameters can include the startup mode (such as standard mode (standard), stack top reuse mode (singleTop), in-stack reuse mode (singleTask), singleton mode (singleInstance), etc.), the process to be started, the process to be started interface, etc.

Optionally, after obtaining the virtual screen parameters and/or startup parameters, the preloading module can also update the latest preloaded application (that is, the application currently processed by the decision-making module, that is, the second application) according to the current time. The start loading time, and the package name of the latest preloaded application. This is convenient for use when the decision-making module executes S1116 next time. You can also remove the application from the queue of applications ready to be preloaded and place it in the queue of applications being preloaded.

S1120. The preloading module sends a request to start the interface of the application program (such as startActivity) to the AMS. The request may carry the startup parameters obtained in S1119 and the virtual screen parameters obtained in S1118.

S1121. The AMS sends a request to start the interface of the application program to the preloading management module.

S1122. The preloading management module determines that the request is a request for a preloading module.

For example, when the preloading module sends a request to AMS to launch the interface of the application, the request may carry corresponding source information, so that the preloading management module can determine the request based on the source information in the request forwarded by AMS. Whether the request is a request sent by a preloaded module.

S1123. The preload management module determines that the application is a cold start.

For example, the preload management module may determine whether the application is a cold start based on whether a process of the application currently exists. That is, when there is currently no process for the application, it can be determined that the application is a cold start. Therefore, it is possible to avoid launching the corresponding application interface to the virtual screen based on the request to start the application interface initiated when switching interfaces within the application.

S1124. The preloading management module determines that the virtual screen specified in the request to start the interface of the application program exists.

For example, the preload management module can determine whether the virtual screen exists through DMS. For example, the preload management module can send a request carrying virtual screen parameters to the DMS to confirm whether the virtual screen exists. The DMS can determine whether the corresponding virtual screen exists based on the received virtual screen parameters and return it to the preload management module.

S1125. The preload management module determines that the number of applications on the virtual screen does not reach the threshold. An example threshold may be 5. Optionally, the number of application programs on the virtual screen can be determined based on the number of application program interfaces displayed on the virtual screen, or the number of applications in the preloading queue.

When it is determined that the applications on the virtual screen have not reached the threshold before performing subsequent steps, this can avoid excessive system resource usage affecting foreground applications due to too many applications being launched on the virtual screen.

Optionally, the preload management module can save the currently used virtual screen parameters. In order to record the virtual screen currently being used to preload the application.

S1126. The preloading management module sends an instruction to the AMS to determine the interface for starting the application.

S1127. The AMS starts the interface of the application program to the virtual screen according to the virtual screen parameters and startup parameters carried in the request to start the interface of the application program sent by the preloading module.

Usually, when an application is launched to a virtual screen through AMS, the application can be run on the virtual screen and displayed to the first interface. The first interface is the interface expected by the user, which can be the case without user operation after the application is cold-started. The final interface to stay on, such as the main interface or login interface, etc.

Correspondingly, when the application is launched on the virtual screen, the number of applications on the virtual screen will be increased by 1 accordingly.

Optionally, when AMS starts the interface of the application to the virtual screen, it can also instruct ActivityRecord to display the window of the application (such as sending a showStartingWindow() instruction) to instruct it not to display the startup effect of the application. In this way, the startup animation will not be displayed when the application is preloaded on the virtual screen, thereby reducing the system load when the application is preloaded.

Optionally, after S1126, the preloading management module may also move the application from the queue of preloading applications into the queue of applications that have completed preloading.

Alternatively, when AMS starts the application's interface to the virtual screen, a preloading label (flag) can be set for the ActivityRecord object corresponding to the Activity of the application started by AMS to indicate that the application is an application preloaded to the virtual screen. program. For example, when the preloading tag is a default value (such as 0), it means that the application is not preloaded to the virtual screen. When the preloading tag is a specified value (such as 1), it means that the application is preloaded to the virtual screen. program.

After the application is preloaded on the virtual screen and the user launches the corresponding application (for example, the user clicks on the icon of the corresponding application), the corresponding application can be switched from display on the virtual screen to display on the home screen. Therefore, when an application preloaded on the virtual screen is actively launched by the user, the interface of the corresponding application can be directly displayed on the home screen without the user waiting, thereby improving the user experience when launching the application.

Optionally, in this embodiment of the present application, when the electronic device starts the process of the corresponding application program to the virtual screen, the application program started in the virtual screen may send some messages, broadcasts or notifications, etc., and may also have pop-up messages. Windows etc. These messages, broadcasts, notifications or pop-ups may affect the current applications displayed on the home screen of the current electronic device. Therefore, in order to prevent the user from being aware of the application being preloaded on the virtual screen, when the electronic device starts the process of the corresponding application to the virtual screen, the related resources of the preloaded and started application can also be managed and controlled to prevent the application from being preloaded. The preloading affects the normal use of the currently used application by the user. For example, FIG. 16 shows a schematic flowchart of managing a preloaded application in an application loading method provided by an embodiment of the present application. As shown in Figure 16, the process of managing the preloaded application may include the following S1601-S1606.

Based on the method shown in Figure 11, after AMS preloads and starts the corresponding application, the following S1601 can be executed to determine the application to be preloaded on the virtual screen.

S1601. The AMS notifies the preload management module that the preloading and startup of the corresponding application program (such as the first application program among at least one application program loaded on the virtual screen) is completed.

Correspondingly, the preloading management module can determine that the corresponding application is preloaded on the virtual screen, that is, the application that is preloaded on the virtual screen is determined based on the notification from the AMS.

The completion of application preloading and startup may refer to the completion of AMS starting the process of the corresponding application.

For example, after the AMS starts preloading the corresponding application, when notifying the preloading management module, the AMS can carry a preloading tag associated with the corresponding application to mark the corresponding application as an application preloaded to the virtual screen, thereby In subsequent steps, the application can be determined based on this identification as an application preloaded on the virtual screen. The preloading tag may be to set a preloading tag (flag) for the ActivityRecord object corresponding to the activity of the application started by AMS when the AMS starts the interface of the application to the virtual screen. For example, when the preloading tag is a default value (such as 0), it means that the application is not preloaded to the virtual screen. When the preloading tag is a specified value (such as 1), it means that the application is preloaded to the virtual screen. program.

S1602. The preloading management module notifies the resource management and control module to set the process of the corresponding application as a background group and perceptible process. For example, the preload management module can send the package name of the corresponding application to the resource management and control module, so that the resource management and control module can manage and control the corresponding application.

Typically, the system provides various groupings of an application's processes. For example, background grouping (THREAD_GROUP_BACKGROUND), foreground grouping (THREAD_GROUP_FOREGROUND) and other groups, in which the priority of the foreground grouping is higher than that of the background grouping, that is, the process in this grouping and its corresponding thread will most likely run on the ultra-large core. When the system loads an application, after the corresponding process is started, the system usually determines whether the application has an interface to display. If so, the corresponding process will be set to a higher priority group, and will be accompanied by a frequency increase operation. Since the interface of the application preloaded to the virtual screen will be displayed on the virtual screen, its process will be set as a high-priority group according to the current system process. Therefore, in order not to interfere with the application currently being used by the user as much as possible, after the application preloading is started, the grouping of the corresponding process can be set as a background grouping with a lower priority, so that the system can adjust the background process according to the background grouping. The policy handles the corresponding process.

For example, as shown in Figure 17, the resource management and control module can determine whether the corresponding application is an application preloaded to the virtual screen after receiving a notification from the preload management module (for example, based on the example in S1601, it can be based on Whether the notification includes an identifier used to mark the corresponding application as an application preloaded to the virtual screen is used to determine whether the corresponding application is an application preloaded to the virtual screen). When it is determined that the application is preloaded to the virtual screen, the resource management and control module can set the group of the corresponding process as a background group. When it is determined that the application is not preloaded to the virtual screen, the resource management and control module may not control the corresponding process, so that the corresponding process can be processed according to the normal process of the system.

The system usually also sets a corresponding adj value (or priority value) for the application process to identify the priority of the corresponding process through the adj value. Generally, the adj values from high to low are native process (-1000), system process (-900), resident process (-800), foreground application (0), recently displayed application in the foreground (50), visible application (100) ), AService (500), perceptible process (700), B Service (800), useless process (950), etc. The higher the adj value, the lower the priority, and the corresponding process is easier to be cleaned up by the system memory. After the application is loaded, the adj value of the process of the loaded application may be updated based on changes in the scene. Usually the adj value of the process of the application preloaded to the virtual screen will be judged to be 950 (useless process). Therefore, it is necessary to set the adj value of the corresponding process to a relatively low value after the process of the preloaded application is started. value (if it is lower than the preset value, the preset value can be set according to the actual situation). For example, the default value can be the value corresponding to B Service, such as 800. Therefore, the adj value of the process of the application preloaded on the virtual screen can be set to the value corresponding to the perceptible process, such as 700, or the value corresponding to the visible application, such as 100, etc. This prevents the corresponding process from affecting the normal applications used by users and prevents the corresponding process from being easily cleaned up due to low priority.

For example, as shown in Figure 18, the resource management and control module can detect that the adj value of the process is updated (for example, the adj value of the corresponding process will be updated in scenarios such as Activity switching, binding services, unbinding services, and the user interface is visible), Determine whether the process that updates the adj value is the process of the application preloaded to the virtual screen. If so, update the adj value of the process to the value corresponding to the perceptible process. And determine whether the grouping of the process is a background grouping, and if not, set its grouping to a background grouping. If the process that updates the adj value is not the process of the application preloaded to the virtual screen, the resource management and control module may not control the update of the adj value of the process, so that the corresponding process updates the adj value according to the normal process of the system.

Optionally, in order to prevent the CPU from increasing the frequency when AMS preloads and launches applications to the virtual screen, affecting the user's ability to use the application in use. When AMS loads a startup application, AMS can determine whether the corresponding application is a preloaded application (for example, based on S1120 in the method shown in Figure 11, AMS can determine whether the startup request is specified in the received startup request. Virtual screen to determine whether the application currently to be launched is a preloaded application). When an application is determined to be preloaded, AMS can instruct the resource management module to prohibit the CPU from performing frequency increase operations. When it is determined that the application is not preloaded, AMS can process it according to the normal application startup process.

Optionally, when the corresponding application is preloaded, the resource management and control module can also limit the resources used by it, such as prohibiting the application's related processes from being bound to the processor's large core, and prohibiting the processor from increasing the frequency for a certain amount of time. Duration (such as the time required to preload the corresponding application), that is, limiting the processor frequency increase when preloading the application.

S1603. The preload management module instructs the window management module to cache the notification of the corresponding application.

Usually the notification bar displayed on the home screen of an electronic device will display notifications received by all applications. Therefore, when a preloaded application is launched, if the application receives a notification, the notification will also be displayed in the notification bar of the home screen. middle. Therefore, in order to prevent notifications received by applications preloaded to the virtual screen from being displayed in the notification bar of the home screen, the notifications of the preloaded application need to be cached so that they are not displayed temporarily until the user actively launches the application. (For example, when the electronic device receives the user's operation to start the corresponding application) the notification is then displayed on the notification bar.

For example, the window management module can control notifications received by the corresponding application indicated by the preload management module. As shown in Figure 19, when the window management module receives (ie intercepts) a notification from a corresponding application, the window management module can cache the notification. In order for subsequent users to actively start the application, and when the application is switched from the virtual screen to the home screen, the window management module releases the notification to display it on the notification bar of the home screen.

Optionally, when the window management module caches the notification of the application, the time of the notification can be erased, so that when the notification is subsequently released to the notification bar, the time displayed is the current time.

S1604. The preload management module notifies the window management module to control the pop-up window of the corresponding application.

Pop-up windows in general applications include dialog boxes (Dialog) that require user operations and prompt pop-up windows (Toast) that disappear automatically after being displayed for a short period of time. Usually, after an application is started, its pop-up window will be assigned to a default screen for display, such as the home screen in the embodiment of this application. Therefore, in order to prevent the pop-up windows of applications preloaded to the virtual screen from being displayed on the home screen and affecting the user's use of the application being used, it is necessary to control the pop-up windows.

For example, the window management module can monitor the pop-up window of the corresponding application according to the notification of the preload management module (for example, the pop-up window can be monitored when processing the AMS task of switching the Activity of the corresponding application to Resumed), As shown in Figure 20, when the corresponding application is monitored to display a pop-up window, the window management module can control the pop-up window according to the type. For example, when the pop-up window is a dialog box, the window management module can assign it to be displayed on the virtual screen (for example, modify the screen parameters of the screen specified by the dialog box to the virtual screen parameters corresponding to the virtual screen, so that it can be displayed on the virtual screen. screen instead of the main screen), that is, the dialog box is turned to the virtual screen. When the pop-up window is a prompt pop-up window, since the pop-up window will disappear automatically after being displayed for a short period of time, the window management module can directly discard the pop-up window so that the prompt pop-up window of the corresponding application does not need to be displayed.

S1605. The preload management module notifies the agent module to host binder messages, alarm messages, broadcasts, etc. associated with the corresponding application.

Take broadcasting as an example (other binder messages, alarm messages, etc. can refer to the broadcasting example). After the preloaded application is started, it may trigger the sending of some broadcasts, thereby causing some other processes (or receivers) to ) performs corresponding operations when listening to the corresponding broadcast. In addition, after the preloaded application is started, it may also register to listen to some broadcasts, so that when it listens (that is, receives) the corresponding broadcast, it will perform corresponding operations.

For example, the application preloaded on the virtual screen may be a shopping application. After the application is loaded on the virtual screen, at the first moment, the shopping application may send a message to the payment application indicating that it has Started broadcast. This makes it easier for payment applications to start when receiving the broadcast. This enables users to open payment applications faster and more conveniently when using shopping applications.

Therefore, in order to prevent the preloaded application from being detected by other applications or processes after it is launched, it can be hosted through the proxy module until the preloaded application is switched from the virtual screen to the home screen, and then the corresponding hosting is released. For example, to intercept the first message and/or broadcast sent by the first application to the recipient, such as other applications or processes, at the first moment, the first message and/or broadcast can be hosted through the proxy module (specific hosting The strategy can be shown in Figure 21 below). When the electronic device receives the user's operation to start the first application program at the second moment (the second moment is later than the first moment), the electronic device switches the first application program from the virtual screen to the main screen (i.e., the display screen), and displays the first application program. When an application interface is provided, the electronic device can then send the hosted first message and/or broadcast to the recipient. For another example, if the second message and/or broadcast received by the first application is intercepted at the third moment, the second message and/or broadcast can be hosted through the proxy module (the specific hosting policy can be as shown in Figure 22 below ). When the electronic device receives the user's operation to start the first application program at the second moment (the second moment is later than the third moment), the electronic device switches the first application program from the virtual screen to the main screen (i.e., the display screen), and displays the first application program. When an application interface is provided, the electronic device may then send the hosted second message and/or broadcast to the first application program.

For example, assuming that the application preloaded on the virtual screen is a shopping application, the electronic device can intercept and store the broadcast sent by the shopping application to the payment application at the first moment. This prevents payment applications from being started due to receiving this broadcast. When the electronic device receives the user's operation to start the shopping application at the second moment, the electronic device then sends the stored broadcast sent by the shopping application at the first moment to the payment application, so that the payment application can It is started after receiving the broadcast when the user actively starts the shopping application. This enables users to open payment applications faster and more conveniently when using shopping applications.

For example, for the broadcast sent by the application, the proxy module can intercept the broadcast sent by the corresponding application notified by the preload management module. As shown in Figure 21, when the application sends a broadcast, the proxy module intercepts the broadcast and hosts the broadcast according to a certain hosting policy. For example, according to the timeliness of the broadcast, when the broadcast is timely (that is, with a short timeliness), it means that the broadcast is likely to have expired when the hosting is subsequently released, so the agent module can directly discard the broadcast. When the broadcast is not timely (that is, non-timely), it means that the broadcast will still be valid when the hosting is subsequently released. Therefore, the proxy module can cache the broadcast and wait until the hosting is released before sending the broadcast. Optionally, after the agent module caches the broadcast, it can also determine whether the broadcast can be merged with the previously cached broadcast (for example, broadcasts of the same type can be merged, etc., or the previously cached broadcast of the same type can be replaced, and the latest broadcast of this type can always be retained. ), if it can be merged, when the broadcast is cached, it can be directly merged and stored with the corresponding previously cached broadcast.

It should be noted that the electronic device can determine whether the broadcast is a timely broadcast according to the type of the broadcast. For example, when the type of broadcast is a periodically sent broadcast such as Wi-Fi signal notification, the broadcast may be determined to be a timely broadcast. Correspondingly, when the broadcast type is a broadcast that notifies other applications or processes to start, the broadcast can be determined to be a non-timely broadcast.

As another example, for the broadcast that the application is registered to listen to, the proxy module can obtain the broadcast event that the corresponding application is registered to listen to notified by the preload management module. Then intercept the broadcast corresponding to the broadcast event. As shown in Figure 22, when the corresponding broadcast is intercepted, the broadcast can be hosted according to a certain hosting policy. For example, according to the timeliness of the broadcast, when the broadcast is a timely broadcast, it means that the broadcast is likely to have expired when the hosting is subsequently released, so the agent module can directly discard the broadcast. When the broadcast is not a timely broadcast, it means that the broadcast will still be valid when the hosting is subsequently released, so the proxy module can cache the broadcast and wait until the hosting is released before sending the broadcast. Optionally, after the proxy module caches the broadcast, it can also determine whether the broadcast can be merged or replaced with the previously cached broadcast (for example, broadcasts of the same type can be merged, etc., or the previously cached broadcast of the same type can be replaced, always keeping the latest version of the type) broadcast), if it can be merged, then when the broadcast is cached, it can be directly merged and stored with the corresponding previously cached broadcast.

S1606. The preload management module notifies the recent task management module (Recents) to hide the snapshot of the corresponding application.

Among them, Recents can manage snapshots of all running applications (in the background and foreground), so that when the user switches the interface of the electronic device's home screen to the multitasking interface, the multitasking interface can display snapshots of all running applications (i.e. Application interface thumbnail). Therefore, in order to prevent the user from seeing the snapshot of the application preloaded on the virtual screen in the multitasking interface so that the user is unaware, the snapshot of the application preloaded on the virtual screen needs to be hidden.

In the embodiment of this application, for applications preloaded to the virtual screen, Recents will generally take a snapshot of the application currently displayed on the virtual screen when preloading the next application, or when the virtual screen is closed. , since the application on the virtual screen will be in a stopped state, Recents will save a snapshot of the corresponding application, or when the user starts an application preloaded on the virtual screen, the application will be restarted from The virtual screen switches to the home screen and displays the startup animation, so Recents will save a snapshot of the application and use the saved snapshot as the picture in the startup animation to achieve an effect similar to a hot startup animation.

For example, the preload management module can send a request to Recents to hide the snapshot of the corresponding application, and then Recents can hide the saved snapshot of the corresponding application according to the request.

Optionally, a frame of the application interface generally requires all corresponding views to be drawn first, and then rendered for final display. Since the application preloaded to the virtual screen will not be seen by the user, as long as the view of the corresponding interface can be drawn, in order to reduce the occupation of system resources by rendering and reduce the pressure of rendering synthesis, the preloaded application can be made only Draw the interface without rendering. The interface can be rendered after subsequent users start the corresponding application and the application switches from the virtual screen to the home screen to save system resources consumed when preloading the application.

For example, when the AMS preloads and starts an application, it can set an associated identifier for the corresponding application to mark the corresponding application as an application preloaded to the virtual screen. Therefore, when the interface is displayed after the application is loaded and started, if the application queries its associated identifier and determines that it is a preloaded application, the application can only draw the interface according to the normal process without rendering it.

Optionally, the preloading management module can also preload the application to the virtual screen according to the time required for preloading the corresponding application, or according to the preset time, after the time required for preloading the corresponding application meets the above time. Set a stop state and freeze it to save system resource consumption of electronic devices.

It should be noted that when the electronic device starts the process of the corresponding application to the virtual screen, and also manages and controls the related resources of the preloaded application through the method shown in Figure 16, if the user preloads When the application program on the virtual screen performs a startup operation (such as when the electronic device receives the user's startup of the corresponding application program, such as the operation of the first application program), or other applications call a preloaded application program, the electronic device will respond accordingly When a preloaded application is switched from the virtual screen to the home screen, it is also necessary to release the control of the application's related resources. For example, display cached notifications, etc.

Based on the foregoing implementation, the electronic device can predict the user's operation behavior to preload an application to the virtual screen before the user starts the application. Therefore, when the user wants to start the corresponding application program, the electronic device can directly switch the operable interface of the corresponding application program from the virtual screen to display on the home screen, thereby reducing the user's perceived time to start the corresponding application program (the time it takes to start the application program). Perceived time, that is, the time elapsed from when the user launches the application to when the operable interface of the application is displayed on the home screen of the electronic device). In this way, the smooth experience when the user starts the application can be improved, and the response speed of the electronic device when the user starts the application can be improved.

Corresponding to the method in the foregoing embodiments, embodiments of the present application also provide an application loading device. This device can be applied to the above-mentioned electronic equipment to implement the method in the foregoing embodiments. The function of the device can be realized by hardware, or it can be realized by hardware executing corresponding software. Hardware or software includes one or more modules corresponding to the above functions. For example, the device may include a prediction module, a preloading module, a preloading management module, a resource management module, a window management module, a proxy module, a recent task management module and other modules in the system architecture shown in Figure 6 . The methods in the foregoing embodiments can be implemented by the cooperation of the above modules. For example, reference may be made to the methods shown in FIG. 11 and FIG. 16 in the aforementioned embodiments.

It should be understood that the division of units or modules (hereinafter referred to as units) in the above device is only a division of logical functions, and may be fully or partially integrated into a physical entity during actual implementation, or may be physically separated. And the units in the device can all be implemented in the form of software calling through processing components; they can also all be implemented in the form of hardware; some units can also be implemented in the form of software calling through processing components, and some units can be implemented in the form of hardware.

For example, each unit can be a separate processing element, or it can be integrated and implemented in a certain chip of the device. In addition, it can also be stored in the memory in the form of a program, and a certain processing element of the device can call and execute the unit. Function. In addition, all or part of these units can be integrated together or implemented independently. The processing element described here can also be called a processor, and can be an integrated circuit with signal processing capabilities. During the implementation process, each step of the above method or each unit above can be implemented by an integrated logic circuit of hardware in the processor element or implemented in the form of software calling through the processing element.

In one example, the units in the above device may be one or more integrated circuits configured to implement the above method, such as: one or more ASICs, or one or more DSPs, or one or more FPGAs, or a combination of at least two of these integrated circuit forms.

For another example, when the unit in the device can be implemented in the form of a processing element scheduler, the processing element can be a general processor, such as a CPU or other processor that can call a program. For another example, these units can be integrated together and implemented in the form of a system-on-a-chip (SOC).

In one implementation, the unit for the above device to implement each corresponding step in the above method can be implemented in the form of a processing element scheduler. For example, the device may include a processing element and a storage element, and the processing element calls a program stored in the storage element to execute the method described in the above method embodiment. The storage element may be a storage element on the same chip as the processing element, that is, an on-chip storage element.

In another implementation, the program for performing the above method may be in a storage element on a different chip from the processing element, that is, an off-chip storage element. At this time, the processing element calls or loads the program from the off-chip storage element to the on-chip storage element to call and execute the method described in the above method embodiment.

For example, embodiments of the present application may also provide a device, such as an electronic device, which may include a processor and a memory configured to store instructions executable by the processor. When the processor is configured to execute the above instructions, the electronic device implements the application loading method implemented by the electronic device in the previous embodiment. The memory may be located within the electronic device or external to the electronic device. And the processor includes one or more.

In yet another implementation, the unit for implementing each step in the above method may be configured as one or more processing elements. These processing elements may be disposed on corresponding electronic equipment as described above. The processing elements here may be integrated circuits. , for example: one or more ASICs, or one or more DSPs, or one or more FPGAs, or a combination of these types of integrated circuits. These integrated circuits can be integrated together to form a chip.

For example, embodiments of the present application also provide a chip system, which can be applied to the above-mentioned electronic devices. The chip system includes one or more interface circuits and one or more processors; the interface circuit and the processor are interconnected through lines; the processor receives and executes computer instructions from the memory of the electronic device through the interface circuit to implement the electronic devices in the above method embodiments. Device-related methods.

An embodiment of the present application also provides a computer program product, including computer instructions run by an electronic device, such as the above-mentioned electronic device.

Through the above description of the embodiments, those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above functional modules is used as an example. In actual applications, the above functions can be allocated as needed. It is completed by different functional modules, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, for example, multiple units or components may be The combination can either be integrated into another device, or some features can be omitted, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated. The components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place, or they may be distributed to multiple different places. . Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application can be integrated into one processing unit, each unit can exist physically alone, or two or more units can be integrated into one unit. The above integrated units can be implemented in the form of hardware or software functional units.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it may be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of the present application are essentially or contribute to the existing technology, or all or part of the technical solution can be embodied in the form of a software product, such as a program. The software product is stored in a program product, such as a computer-readable storage medium, and includes a number of instructions to cause a device (which can be a microcontroller, a chip, etc.) or a processor (processor) to execute all of the methods described in various embodiments of this application. or partial steps. The aforementioned storage media include: U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk and other media that can store program codes.

For example, embodiments of the present application may also provide a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed by the electronic device, the electronic device is caused to implement the application loading method as described in the foregoing method embodiments.

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be covered by the protection scope of the present application. . Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims (16)

1. An application loading method, characterized in that it is applied to an electronic device, the electronic device includes a display screen and a virtual screen, the electronic device is installed with multiple application programs, the method includes: Load at least one application program onto the virtual screen. After the at least one application program is loaded onto the virtual screen, the display screen does not display the interface of the at least one application program. The at least one application program includes first application; Intercept the first message and/or broadcast sent by the first application to the recipient at the first moment; When the first message and/or broadcast is a non-timely message, save the first message and/or broadcast; An operation by the user to launch the first application is received at the second moment; In response to the user's operation of starting the first application program, switching the first application program from the virtual screen to the display screen, and displaying the interface of the first application program on the display screen, and sends the saved first message and/or broadcast to the recipient, and the second time is later than the first time. 2. The method of claim 1, wherein the display screen is an actual screen of the electronic device, the screen displayed by the display screen is visible to the user, and the virtual screen is a simulated screen of the electronic device. , the picture displayed on the virtual screen is invisible to the user. 3. The method of claim 2, wherein the virtual screen corresponds to the display screen. 4. The method according to claim 1, characterized in that, the method further comprises: The second message and/or broadcast received by the first application is intercepted at a third time, and the second time is later than the third time; When the second message and/or broadcast are non-timely messages, save the second message and/or broadcast; After receiving the user's operation to start the first application at the second moment, the method further includes: The saved second message and/or broadcast is sent to the first application. 5. The method according to claim 4, characterized in that, when saving the first message and/or broadcast, it is merged with previously saved messages and/or broadcasts of the same type; and when saving the second message and/or broadcast, When/or broadcasting, merge it with previously saved messages and/or broadcasts of the same type. 6. The method according to claim 4, characterized in that, when saving the first message and/or broadcast, replace the previously saved message and/or broadcast of the same type; and when saving the second message and/or broadcast, or broadcast, replace previously saved messages and/or broadcasts of the same type. 7. The method according to any one of claims 4 to 6, characterized in that the method further includes: When the first message and/or broadcast is a timely message, discard the first message and/or broadcast; When the second message and/or broadcast is a timely message, the second message and/or broadcast is discarded. 8. The method according to any one of claims 1 to 6, characterized in that, before receiving a user's operation to start the first application at the second moment, the method further includes: Set the process group of the first application as a background group; The priority value of the process of the first application is set to a first value, the first value is smaller than a preset value, and the smaller the priority value is, the higher the priority of the process is. 9. The method according to any one of claims 1 to 6, characterized in that, before receiving the user's operation to start the first application program at the second moment, the method further includes: Caching notifications received by the first application so that the notifications are not displayed; The method further includes displaying the notification on the display screen in response to an operation by the user to launch the first application. 10. The method according to any one of claims 1 to 6, characterized in that, before receiving a user's operation to start the first application program at the second moment, the method further includes: A pop-up window of the first application is detected; When the pop-up window is a dialog box, assign the dialog box to the virtual screen; When the pop-up window is a prompt pop-up window, the prompt pop-up window is discarded. The prompt pop-up window is a pop-up window that will automatically disappear after being displayed. 11. The method of claim 10, wherein assigning the dialog box to the virtual screen includes: Modify the screen parameters associated with the dialog box to the virtual screen parameters corresponding to the virtual screen. 12. The method according to any one of claims 1 to 6, characterized in that, before receiving a user's operation to start the first application program at the second moment, the method further includes: Hide the first application's snapshot. 13. The method according to any one of claims 1 to 6, characterized in that, before receiving the user's operation to start the first application program at the second moment, the interface of the first application program is only drawn but not rendered. . 14. The method according to any one of claims 1 to 6, characterized in that when loading at least one application program onto the virtual screen, limiting the frequency increase of the processor of the electronic device. 15. An electronic device, characterized in that it includes: a processor, a memory configured to store instructions executable by the processor, and when the processor is configured to execute the instructions, the electronic device implements the following steps: The method described in any one of claims 1 to 14. 16. A computer-readable storage medium with computer program instructions stored thereon; characterized in that, when the computer program instructions are executed by an electronic device, the electronic device implements the method described in any one of claims 1 to 14 method.