Application launching method and electronic device

Abstract

Embodiments of the present application provide an application launching method and an electronic device. The method is applied to an electronic device comprising a system service process, a system interface process, and a desktop process, and the method comprises: in response to a first operation of a user, the desktop process sends a launch message to the system service process, the launch message indicating a first function of launching a first application by means of a shortcut, and an interface corresponding to the first function being an interface displayed after the first application sequentially loads n activities; in response to the launch message, the system service process launches a first activity among the n activities, and creates a first transition component, wherein in the process of launching the first activity, the system interface process adds and draws a first launch window for the first activity; in response to the first transition component being ready, the system interface process notifies the desktop process to execute the first transition component; and the desktop process executes the first transition component. The method can increase the response speed during application launching.

Description

Application startup method and electronic device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on December 29, 2023, with application number 202311867730.7 and application name “Application startup method and electronic device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of electronic technology, and in particular to an application startup method and an electronic device. Background Art

[0003] With the development of electronic devices, there are more and more types of application programs (APPs, referred to as applications) that can be installed in electronic devices, and the functions of the applications are becoming more and more abundant.

[0004] Users can launch an application by clicking a desktop icon. To provide users with a one-step experience, some applications offer quick launch methods. For example, by long-pressing an application icon on the desktop, the desktop will display some function options for the application. Clicking a function option directly opens the function in the application. This process is called quick launch of the application.

[0005] However, some applications have slow startup response during the quick startup process, which affects the user experience.

[0006] Summary of the Invention

[0007] The present application provides an application startup method and an electronic device, which can shorten the response time of application quick startup and improve user experience.

[0008] In a first aspect, the present application provides an application startup method, which is applied to an electronic device, the electronic device including a system service process, a system interface process and a desktop process, the method comprising: in response to a first operation of a user, the desktop process sends a startup message to the system service process, wherein the startup message is used to indicate that a first function of a first application is started through a shortcut, and the interface corresponding to the first function is an interface displayed after the first application loads n activities in sequence, where n is an integer greater than 1; in response to the startup message, the system service process starts the first activity of the n activities and creates a first transition component, wherein, in the process of starting the first activity, the system interface process adds and draws a first startup window for the first activity; in response to the first transition component being ready, the system interface process notifies the desktop process to execute the first transition component; in response to the notification of the system interface process, the desktop process executes the first transition component.

[0009] Optionally, the transition component is ready via the onTransactionReady() function, also known as transitionReady.

[0010] The application startup method provided in the first aspect of the present application adds and draws a first startup window for the first activity by the system interface process during the process of starting the first activity. Furthermore, the system service process creates a first transition component, which is processed by the system interface process and the desktop process and finally executed to display the transition page. The entire process of adding the first startup window and displaying the transition page is synchronized with the life cycle of the first application's process executing the activity, without relying on the life cycle of the first application, greatly shortening the response time. Moreover, in this solution, the first startup window is added earlier, so the transition component starts executing earlier, and the execution of the transition component can be executed concurrently with the process of the first application executing the activity execution life cycle. Therefore, the transition component can be executed and completed earlier. Once the application's activity is loaded and the interface is displayed, it can respond to user operations without the user having to wait, thereby improving the user experience.

[0011] In a possible implementation, the first transition component is ready between a first moment and a second moment, where the first moment is when the first startup window is added, and the second moment is when the first startup window is finished drawing.

[0012] In other words, the readiness of the first transition component need not be triggered by the first launch window completing drawing (finishDrawing). Instead, it can be triggered during the drawing process of the first launch window (onTransactionReady). This advances the time at which the first transition component is ready, further shortening the time it takes to display the transition page, further reducing the application startup response time, and further improving the user experience.

[0013] In one possible implementation, the system interface process adds and draws the first startup window for the first activity, including: the system interface process calls the addStartingWindow() function to add the first startup window; the system interface process calls the doFrame() function to draw the frame of the first startup window; after the system interface process completes drawing the frame of the first startup window, it requests the system service process to add a display to the first startup window; the system service process calls the addToDisplay() function to add a display to the first startup window; after the display is added to the first startup window, the system service process triggers the readiness of the first transition component.

[0014] In this implementation, the system service process executes addToDisplay(), that is, the first startup window is added and displayed, triggering the readiness of the first transition component, thereby advancing the time when the first transition component is ready and the time when the transition page is displayed, further shortening the response time of the application startup and further improving the user experience.

[0015] In one possible implementation, the startup message carries information about the first application, and before the system service process starts the first activity of n activities, the method also includes: if it is determined that the startup message carries the first information, the system service process determines whether the first application meets the preset conditions based on the information of the first application; the first information is used to indicate that the first function is started through a shortcut; if it is determined that the first application meets the preset conditions, the system service process sets a first identifier, and the first identifier is used to indicate that the current scene is a quick startup scene, and the currently started activity is the first activity of the application.

[0016] The first identifier may be, for example, a shortcut function ID.

[0017] In this implementation, before starting the first activity, it is determined whether the first application meets the preset conditions to determine whether it meets the quick start scenario. If the preset conditions are met, it means that the current scenario is a quick start scenario, and the first identifier is set. Moreover, this solution can set the first identifier only before starting the first activity, so the first identifier can also indicate that the activity to be started is the first activity. By setting the first identifier, it is convenient to quickly and accurately identify the quick start scenario and the first activity based on the first identifier, so that the subsequent processes of this solution can be executed more accurately, improving the operating efficiency and accuracy of the system.

[0018] In one possible implementation, the preset condition includes one or more of the following: the type of the first application is in a preset application whitelist; the package of the first application is not in a preset package blacklist; the first information is not in a function blacklist.

[0019] In this implementation, by setting up an application type whitelist and a package blacklist, it is possible to filter out applications that are not suitable for the process of this solution, preventing these applications from entering the process of this solution and being unable to execute, thereby preventing application startup failures. In other words, this approach improves the reliability and stability of system operation.

[0020] In a possible implementation manner, the first identifier is the first information.

[0021] That is, the first information carried in the startup message can be used to directly identify the current scene as a quick startup scene and the currently launched activity as the first activity of the application. This can reduce the number of identifiers, simplify the algorithm, and improve system operation efficiency.

[0022] In a possible implementation, before the system interface process adds and draws the first startup window for the first activity, the method further includes: the system service process determining that the first identifier exists.

[0023] In other words, the system service process reads the first identifier. If it does, it indicates the current scenario is a quick launch scenario and the currently launched activity is the first activity of the application. Therefore, the system interface process adds and draws the first launch window for the first activity. This further limits the addition and drawing of the first launch window to the launch of the first activity in the quick launch scenario, improving the accuracy of the launch window addition and, in turn, the accuracy and stability of application launches.

[0024] In one possible implementation, the method also includes: after the system interface process starts to add a first startup window for the first activity, the system service process determines whether the type parameter of the first startup window is the first type, and determines whether there is a first identifier, the first type indicating that the startup window has not been added; if the type parameter of the first startup window is the first type and there is a first identifier, the system service process sets a second identifier for the first startup window; if the type parameter of the first startup window is not the first type and there is a first identifier, the system service process determines whether there is a first result, the first result indicating that adding the startup window failed; if the first result exists, the system service process sets the second identifier; if the first result does not exist, the system service process clears the first identifier.

[0025] The first type may be, for example, NONE.

[0026] That is to say, if the type parameter shows that the startup window has not been added, then it means that the system's native process has not added a startup window. Further, if there is a first identifier, it means that the startup window is added for the process of this solution (i.e., the optimized process), then the system service process sets a second identifier to identify the first startup window as the startup window added for the process of this solution. This facilitates the subsequent rapid and accurate identification of the startup window, ensures the accurate management of subsequent startup windows, and improves the accuracy, reliability, and stability of the solution. Moreover, in the case where the startup window is added for the process of this solution, the first identifier is cleared, so that the subsequent process enters the system's native process, prevents application startup errors, improves the accuracy of the process execution of this solution, and thereby improves the stability of the system operation.

[0027] In a possible implementation, the method further includes: if the type parameter of the first startup window is the first type and the first identifier exists, modifying the type parameter of the first startup window to a splash type.

[0028] In this implementation, the startup window type parameter is corrected to the splash type, improving the accuracy of subsequent process execution. Moreover, the splash type startup window is applicable not only to hot starts but also to cold starts, expanding the applicability of this solution.

[0029] In one possible implementation, the method further includes: in the process of starting the first activity, if it is determined that the first identifier exists, the system service process creates a first source record corresponding to the first activity, uses the activity record of the first activity as the value of the first source record, and adds the first source record to the source record set.

[0030] The presence of the first flag indicates that the current scenario is a quick launch scenario and the currently launched activity is the first activity. In this case, a first source record is created for the first activity, assigned a value, and added to the source record set. The source record represents the source activity that launched the activity and serves as a basis for subsequently identifying whether the activity is the first activity or another activity besides the first one. It also serves as a basis for subsequent window transfers, improving the accuracy and convenience of the solution's process execution.

[0031] In one possible implementation, the electronic device also includes a process of the first application, and the method also includes: during the execution of the life cycle of the first activity, the process of the first application determines whether the interface corresponding to the first activity is a visual interface; if the interface corresponding to the first activity is a visual interface, the system service process sets the value of the visual identifier of the first activity to the first value.

[0032] The first value may be, for example, “yes” or “true”.

[0033] In one possible implementation, the method further includes: in the activity layout stage of the first activity, if it is determined that the custom interface includes a view, or it is determined that there is a background layout and the transparency is not 0, then the process of the first application determines that the interface corresponding to the first activity is a visual interface.

[0034] In one possible implementation, the method further includes: after receiving the first completion indication of the process of the first application, the system service process determines whether the delayed removal condition is met, the first completion indication is used to indicate that the first activity has completed drawing; if the delayed removal condition is met, the system service process delays the removal of the first startup window; if the delayed removal condition is not met, the system service process removes the first startup window.

[0035] Optionally, the first completion indication may be sent by the process of the first application to the system service process through the finishDrawing() function.

[0036] In a possible implementation, the delayed removal condition includes: the value of the visual identifier of the first activity is a first value, and the second identifier exists.

[0037] In the above-mentioned implementations, whether the interface corresponding to the activity is a visual interface is identified to determine whether to delay the removal of the window. If the value of the visual identifier is not the first value, and the second identifier exists, it means that the interface corresponding to the current activity is an interface that is not perceptible to the user, and the first startup window is a startup window added by the process of this solution, then there is no need to remove the startup window, and thus the removal of the startup window is delayed. If the value of the visual identifier is the first value, or the second identifier does not exist, it means that the interface corresponding to the current activity is a user-perceptible interface, or the first startup window is not a startup window added by the process of this solution, then the startup window is removed. In this way, when the first application needs to display the interface, the startup window can be removed in time to prevent disruption to the normal startup logic of the application and to prevent affecting the user experience. Moreover, the startup window added by the native process can be removed normally to prevent disruption to the normal execution logic of the native process, thereby improving system stability and reliability. In addition, the value of the visual identifier can accurately and quickly determine whether it is a visual interface, thereby improving the speed and accuracy of the execution of the process of this solution.

[0038] In a possible implementation, the delayed removal condition further includes one or more of the following: the startup window held by the first activity has not been removed; the current delayed removal times threshold is greater than 0; and the source record exists in the source record set.

[0039] The delayed removal condition in this implementation can prevent the startup window of the same activity from being delayed and removed multiple times, that is, prevent the process from being stuck at the same activity all the time, causing startup jams, and improve the user experience.

[0040] In a possible implementation, after removing the first startup window, the method further includes: clearing the first identifier, the second identifier, the source record set, and the first value.

[0041] In this implementation, after removing the launch window, clearing the various identifiers added by the process of this solution can prevent process confusion during subsequent operation and improve system stability and reliability. In addition, clearing the various identifiers added by the process of this solution can also prevent errors when quickly launching the first function of the first application next time, thereby improving the reliability of system operation.

[0042] In a possible implementation, the first transition component has a motion effect attribute.

[0043] If the first transition component has a motion effect attribute, the first transition component will be displayed with a motion effect, which can improve the vividness of the interface display and enhance the user's visual experience.

[0044] In one possible implementation, the animation corresponding to the first transition component is an icon magnification animation. The method also includes: before submitting the first transition component to the system interface process, when it is determined that the first transition component is the transition component corresponding to the first activity, the system service process cancels the transparent attribute of the first transition component.

[0045] In this implementation, before submitting the first transition component to the system interface process, the transparent property of the first transition component corresponding to the first activity is canceled, so that the desktop process can execute the icon enlargement effect, improve the effect, and enhance the user's visual experience.

[0046] In a possible implementation, the method further includes: during the process of starting the first activity, the system service process determines that the first transition component is the transition component corresponding to the first activity based on the activity record corresponding to the first activity collected in the first transition component.

[0047] In this implementation, the activity record can be used to easily and quickly determine whether the transition component is the transition component corresponding to the first activity. Specifically, if the activity record collected by the transition component records the record of the first activity, it means that the transition component is the transition component corresponding to the first activity.

[0048] In one possible implementation, the electronic device also includes a process of a first application, and the method also includes: in response to the system service process starting the first activity, the process of the first application executes the life cycle of the first activity; in the process of executing the life cycle of the first activity, the process of the first application requests the system service process to start the second activity among n activities; in response to the request of the first application process, the system service process starts the second activity and creates a second transition component; in the process of starting the second activity, the system service process passes the first startup window to the second activity.

[0049] In this implementation, when the second activity is started, the first start window is transferred from the first activity to the second activity, so that the transition page can be continuously displayed without screen flashing, thereby improving the user's visual experience.

[0050] In a possible implementation, the second activity is started after the first transition component is ready.

[0051] In this implementation, the start time of the second activity is limited to after the first transition component is ready, so as to prevent the second activity from affecting the loading of the first transition component, preventing it from affecting the display of the transition page, and thus preventing delayed start response.

[0052] In a possible implementation, the second activity is started after the layer display of the first starting window is completed.

[0053] The completion time of layer display is also the time when the showSurface() function is executed.

[0054] In this implementation, the startup time of the second activity is limited to after the completion time of the layer display of the first startup window, so as to prevent the second activity from affecting the drawing and display of the startup window, prevent affecting the display of the transition page, and thus prevent delayed startup response.

[0055] In one possible implementation, the method also includes: in the process of starting the first activity, the system service process sets a conditional variable, the conditional variable includes: the first transition component has been submitted to the system interface process, and the layer display of the first startup window has been completed; the system service process starts the second activity, including: when it is determined that the conditional variable has been unlocked, the system service process starts the second activity.

[0056] In this implementation, by setting the conditional variable, the start timing of the second activity can be accurately limited, further preventing the display of the transition page from being affected.

[0057] In one possible implementation, the method further includes: the system service process sets the effective duration during the process of starting the first activity; if the condition variable is satisfied within the effective duration from the moment the condition variable is set, the system service process determines that the condition variable has been unlocked; if the condition variable is still not satisfied after the effective duration from the moment the condition variable is set, the system service process unlocks the condition variable.

[0058] In this implementation, by setting an effective duration, if the condition variable is not satisfied after the effective duration, the condition variable is automatically unlocked. This can prevent the condition variable from being unlocked due to process execution anomalies, which in turn prevents subsequent activities from being started, thereby improving system stability.

[0059] In one possible implementation, before the system service process passes the first startup window to the second activity, the method further includes: in the process of starting the second activity, when it is determined that a source record exists in the source record set, the system service process sets a second source record corresponding to the second activity and assigns a value to the second source record; the source record is used to represent the previous activity that starts the third activity, and the third activity is any one of n activities; and the second source record is added to the source record set.

[0060] In this implementation, by setting the second source record, it is convenient to quickly and accurately determine whether the activity is the first activity or another activity.

[0061] In one possible implementation, assigning a value to the second source record includes: the system service process transfers the value of the first source record to the second source record, where the first source record is the source record corresponding to the first activity; if the transferred value is empty, the system service process uses the activity record of the fourth activity as the value of the second source record, where the fourth activity is the activity currently holding the first startup window.

[0062] In this implementation, if the value passed is null, the source record of the activity holding the launch window in the source record set is used as the value of the source record of the new activity. Therefore, regardless of the source record value, the activity corresponding to the source record value in the process of this application solution always holds the launch window. Therefore, the source record can accurately obtain the activity currently holding the launch window, and thus accurately transfer the launch window to the new activity, improving the accuracy of the launch window transfer and the reliability of the optimization process.

[0063] In a possible implementation, the system service process transfers the first startup window to the second activity, including: obtaining a second source record from the source record set; and transferring the first startup window from the first activity to the second activity according to a value of the second source record.

[0064] In this implementation, the launch window is delivered based on the source record, so that the launch window can be delivered to the current activity quickly and accurately.

[0065] In one possible implementation, the method also includes: before submitting the second transition component to the system interface process, when it is determined that the second transition component is other transition components, the system service process cancels the animation attribute of the second transition component, and the other transition components refer to activities other than the first activity among n activities.

[0066] In other words, the transition component corresponding to the first activity has animation properties, while the transition components corresponding to subsequent activities do not. This prevents screen flashing caused by frequent animation switching when launching activities across the task stack, thus improving the display quality. Furthermore, since only the first transition component has animation properties, the animation execution time is shorter, preventing the application's activities from loading before the animation is completed. This prevents the application's interface from becoming unresponsive to user operations, thus improving the user experience.

[0067] In a possible implementation, the method further includes: during the process of starting the second activity, the system service process determines that the second transition component is another transition component based on the activity record corresponding to the second activity collected in the second transition component.

[0068] In this implementation, the activity records can be used to easily and quickly determine whether the transition component is another transition component corresponding to another activity. Specifically, if the activity records collected by the transition component record records of other activities, it means that the transition component is a transition component corresponding to another activity.

[0069] In one possible implementation, after the system service process passes the first startup window to the second activity, the method further includes: in the process of starting the second activity, if the first activity and the second activity do not belong to the same task stack, the system service process increases the layer level of the first startup window by one layer.

[0070] In this implementation, when launching an activity across task stacks, the first launch window is moved up one level. This prevents the native process from adding a launch window if it successfully does so, preventing the original launch window from overwriting the first launch window added by the process in this solution. This prevents the first launch window from being obscured, preventing it from affecting the transition page and improving the user experience.

[0071] In one possible implementation, the method also includes: during the execution of the life cycle of the second activity, the process of the first application determines whether the interface corresponding to the second activity is a visual interface; if the interface corresponding to the second activity is a visual interface, the system service process sets the value of the visual identifier of the second activity to the first value.

[0072] In one possible implementation, the method further includes: after receiving the second completion indication, the system service process determines whether a delayed removal condition is met, and the second completion indication is used to indicate that the second activity has completed drawing; if the delayed removal condition is met, the system service process delays the removal of the first startup window; if the delayed removal condition is not met, the system service process removes the first startup window.

[0073] Optionally, the second completion indication may be sent by the process of the first application to the system service process through the finishDrawing() function.

[0074] The specific process of identifying whether the interface corresponding to the second activity is a visual interface and triggering the delayed removal judgment when the second activity is drawn is similar to that of the first activity, and the beneficial effects are similar, so I will not repeat them here.

[0075] The subsequent third activity, fourth activity, etc. are executed in a similar process to the second activity. The main difference is that the third and subsequent activities do not need to determine whether to unlock the condition variable.

[0076] In a second aspect, the present application provides a device, which is included in an electronic device and has the function of implementing the electronic device behavior described in the first aspect and possible implementations of the first aspect. The function can be implemented through hardware or through hardware executing corresponding software implementations. The hardware or software includes one or more modules or units corresponding to the above functions. For example, a receiving module or unit, a processing module or unit, etc.

[0077] In a third aspect, the present application provides an electronic device, which includes: a processor, a memory, and an interface; the processor, the memory, and the interface cooperate with each other so that the electronic device executes any one of the methods in the technical solution of the first aspect.

[0078] In a fourth aspect, the present application provides a chip including a processor, wherein the processor is configured to read and execute a computer program stored in a memory to perform the method of the first aspect and any possible implementation thereof.

[0079] Optionally, the chip also includes a memory, and the memory is connected to the processor via circuits or wires.

[0080] Further optionally, the chip also includes a communication interface.

[0081] In a fifth aspect, the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the processor executes any one of the methods in the technical solution of the first aspect.

[0082] In a sixth aspect, the present application provides a computer program product, which includes: a computer program code, which, when the computer program code runs on an electronic device, enables the electronic device to execute any one of the methods in the technical solution of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0083] FIG1 is a schematic diagram of an application scenario of an application startup method provided in an embodiment of the present application;

[0084] FIG2 is a schematic diagram of an application scenario of another application startup method provided in an embodiment of the present application;

[0085] FIG3 is a schematic structural diagram of an electronic device 100 provided in an embodiment of the present application;

[0086] FIG4 is a software structure block diagram of an electronic device 100 provided in an embodiment of the present application;

[0087] FIG5 is a timing diagram of an application startup method provided in an embodiment of the present application;

[0088] FIG6 is a schematic diagram of the software architecture of another electronic device provided in an embodiment of the present application;

[0089] FIG7 is a timing diagram of an application startup method provided in an embodiment of the present application;

[0090] FIG8 is a schematic diagram showing a response time comparison example provided in an embodiment of the present application;

[0091] FIG9 is a timing diagram of another application startup method provided in an embodiment of the present application;

[0092] FIG10 is a flow chart of an example application startup method provided in an embodiment of the present application;

[0093] FIG11 is a flow chart of another example of an application startup method provided in an embodiment of the present application;

[0094] FIG12 is a timing diagram of another example of an application startup method provided in an embodiment of the present application;

[0095] FIG13 is a flow chart of another example of an application startup method provided in an embodiment of the present application;

[0096] FIG14 is a schematic diagram of an interface change example provided in an embodiment of the present application;

[0097] FIG15 is a schematic diagram showing a comparison of interfaces for quickly launching an application based on an optimized process and a native process, provided in an embodiment of the present application;

[0098] FIG16 is a schematic diagram showing a comparison of interfaces for quickly launching an application based on an optimized process and a native process, provided in an embodiment of the present application;

[0099] FIG17 is a timing diagram of another example of an application startup method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0100] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings in the embodiments of the present application. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships can exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0101] In the following, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the quantity of the technical features indicated. Therefore, a feature specified as "first," "second," or "third" may explicitly or implicitly include one or more of the features.

[0102] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of the present application include a particular feature, structure, or characteristic described in conjunction with that embodiment. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in other embodiments" appearing in different places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0103] To better understand the embodiments of the present application, the terms or concepts that may be involved in the embodiments are explained below.

[0104] 1. Interface, activity, and window

[0105] Electronic devices can install and run applications. When an electronic device runs any application, such as application A, in the foreground, the electronic device's display shows the interface (also called a page) of application A, and the user of the electronic device can interact with the interface of application A. When the electronic device runs application A in the background, the electronic device no longer displays the interface of application A, and the user of the electronic device cannot interact with the interface of application A.

[0106] After receiving a command to launch an application, an electronic device creates a process corresponding to that application. It then loads an activity based on that process. Activities are responsible for displaying the application's interface, interacting with the user, and handling business logic. It's understood that while an application is running, there's only one process corresponding to that application in the system. However, multiple processes can be loaded sequentially during the process's execution, depending on user actions or the application's pre-configured display logic. Different activities can correspond to different interfaces.

[0107] An interface is composed of views. When displaying an interface and interacting with the user, an activity can internally hold a window object to help it manage its view. When an application is launched, the system creates a window for the activity to display the views in the interface. Therefore, from another perspective, a window is a carrier and container for views.

[0108] 2. Task stack (taskstack)

[0109] A task stack, also known as a task, is a container for activity instances. When you start an application, the system creates a task stack for that application. In other words, each application has a corresponding task stack.

[0110] In real-world applications, during application startup or operation, some screen transitions may occur. These screens can be accessed through activities in other applications. This means that displaying these screens requires loading activities across task stacks. For example, when application A starts, it needs to transition from screen a1 to screen b1, and then to screen c1. The activities corresponding to screens a1 and b1 are in application A's task stack, while the activity corresponding to screen c1 is in application B's task stack. Therefore, the transition from screen b1 to screen c1 requires loading activities across task stacks.

[0111] 3. Transition Page

[0112] It can be understood that during the process of application startup, that is, from the user executing the operation of starting the application to the display of a certain interface to be displayed in the application (hereinafter referred to as the target interface) on the screen, the terminal device needs to go through a series of processing operations, and the user needs to wait for a certain time. In order to reduce the user's waiting time and to improve the user's visual experience, the electronic device can display some transition interfaces during this period. These interfaces are called transition pages (or transition pages, startup pages, dynamic effect pages or startup dynamic effects). Optionally, the transition page can be an icon page, an advertising page, a blank page, a logo page, and a snapshot page. Optionally, the dynamic effect attribute of the transition page can be set as needed. If the dynamic effect attribute is set to "yes" (for example, true), the transition page presents an animation effect (abbreviated as dynamic effect). If the dynamic effect attribute is set to "no" (for example, false), the transition page presents a static effect. In other words, the transition page can be a static display interface or a dynamic effect interface. The dynamic effect displayed in the dynamic effect interface can be, for example, the gradual enlargement of the icon, or the appearance of text in sequence, etc.

[0113] The system can trigger the execution of the transition component by adding a startup window to achieve the display of the transition page. Transition, hereinafter referred to as transition, is used to achieve the display of transition effects in the window, for example, to achieve the display of animation effects.

[0114] 4. Cold start, warm start and hot start

[0115] It's understandable that after an app is launched, its process continues to run in the background, and its activities are placed in the task stack. However, after an app transitions from the foreground to the background, its process may be destroyed and its activities recycled, meaning that the app's process no longer exists in the system background.

[0116] Depending on whether there is an application process in the system background and whether there is an activity of the application when the application is started, the application startup can be divided into cold start, warm start and hot start.

[0117] When a user clicks an app icon to launch it, there's no background process for that app. The system then creates and starts a process for that app. After that process is complete, the system uses it to load the app's activity. After the activity is successfully loaded, the app's interface is displayed. This startup process is called a cold start.

[0118] After an app is launched, it can transition from the foreground to the background. While in the background, the app's process can still exist in the system. If the user clicks the app's icon to bring it back to the foreground, the system no longer needs to create and start a process for the app because the process already exists in the background. If the app's activity still exists in system memory, the app doesn't need to reload the activity. Instead, the app displays the interface corresponding to the activity in the app's task stack in the foreground. This startup process is called a hot start.

[0119] After the application goes from running in the foreground to running in the background, the application process may be killed in the background (for example, the application process is destroyed), the activity is recycled, and the application process no longer exists in the system background. However, after the process is killed, the application may still have self-starting behavior, that is, the application can request the system to create and start a process for the application in the background. If the application process is successfully created and started in the system background, and the user clicks the application icon to bring the application back to the foreground, the system no longer needs to create and start a process for the application because the application process exists in the system background. However, since the application activity has been recycled, the system needs to load the application activity through the application process until the activity is successfully loaded and the application interface is displayed. This startup process can be called a warm startup.

[0120] 5. Start activity, execute activity life cycle and load activity

[0121] In the embodiment of the present application, starting an activity refers to a process in which a system server process processes an activity start request or an activity start transaction, that is, a process in which the activity starts. Starting an activity can be implemented by the startActivity() function.

[0122] The execution of the activity lifecycle refers to the process of the application process executing the activity startup (activityStart), loading the activity layout (activityResume), drawing the frame, and finishing the drawing (finishDrawing). In other words, the launch of the activity is controlled by the system server, but the actual startup action is performed by the application process.

[0123] In the embodiment of the present application, loading an activity refers to the process from starting the activity to completing the life cycle of the activity.

[0124] The application scenarios and technical issues of this application are explained below.

[0125] To facilitate users in launching applications, the system of electronic devices provides a mechanism for launching applications through shortcuts (i.e., quick launch). Applications can design quick launches of different functions according to their own needs, allowing users to directly display the interface of the required function in one step.

[0126] For example, Figure 1 is a schematic diagram of an application scenario of an application startup method provided in an embodiment of the present application. In this embodiment, a user can quickly start a function of an application by long pressing the application icon on the desktop, and directly display the interface of the function. Specifically, taking the electronic device as a mobile phone as an example, as shown in Figure 1 (a), multiple application icons are displayed on the desktop of the mobile phone. Taking the payment application as an example, the user can long press the payment application icon 101. In response to the user's operation, the function options of the payment application are displayed on the desktop, such as: more settings function option 1011, receive money function option 1012, pay function option 1013 and scan function option 1014, as shown in Figure 1 (b). When the user clicks on a function option, the function is started and the interface corresponding to the function is displayed. For example, the user clicks on the receive money function option 1012. In response to the user's operation, the payment function of the payment application is started and the payment code interface 102 is displayed, as shown in Figure 1 (c).

[0127] For example, FIG2 is a schematic diagram of an application scenario of another application startup method provided by an embodiment of the present application. In this embodiment, a user can launch a function of an application through a shortcut icon of the application on the desktop, and the interface of the function is displayed. As shown in FIG2 (a), continuing with the example of the payment application, the desktop includes an icon for the payment application. The user can long-press the icon of the payment application. In response to the user's operation, the desktop displays the function options of the payment application, such as the more settings function option 1011, the collect money function option 1012, the payment function option 1013, and the scan function option 1014, as shown in FIG2 (b). The user can long-press a function option and drag it to the desktop to form a shortcut icon on the desktop. Continuing with the example of the collect money function option 1012, the user long-presses and drags the collect money function option 1012 to a certain location on the desktop and then raises his hand. After the user raises his hand, the interface displays the shortcut icon 201 corresponding to the collect money function option 1012, as shown in FIG2 (c).

[0128] The user clicks the shortcut icon 201. In response to the user's operation, the mobile phone starts the payment function of the payment application and displays the payment code interface 102, as shown in Figure 2 (d).

[0129] It should be noted that the above two application scenarios are explained by taking the quick launch of the application from the desktop as an example. In actual use, the application can also be launched through shortcuts from other entrances. For example, the application can also be launched through a shortcut on the negative one screen. The embodiment of the present application does not impose any restrictions on the specific entrance of the quick launch, the specific triggering method of the quick launch, etc. It can be understood that no matter which quick launch method is used, the process of launching the application by the electronic device is the same or similar.

[0130] The inventors have discovered that in the related art, some functions of some applications have a long response time, that is, a slow response problem, during the quick startup process. The response time of an application is also called response delay or startup time, which refers to the time from the user executing the operation of starting the application (for example, clicking on the function option or clicking on the shortcut icon in the above embodiment) to the time when the first frame related to the application is displayed on the screen. Among them, the first frame related to the application can be the interface of the application itself or a transition page of the application.

[0131] Specifically, in the related art, some functions of some applications do not have transition pages during the quick launch process, which not only leads to a long application launch response time, but also poor user visual effects. Some functions of some applications have transition pages during the quick launch process, but the response time is also relatively long, which also brings a poor user experience. For example, launching Alipay through a shortcut When using the payment function, the response time is about 621 milliseconds (ms); when launching Alipay through the shortcut When using the scan function, the response time is about 447ms; when launching WeChat through the shortcut When using the payment function, the response time is about 600ms; start WeChat through the shortcut When using the scan function, the response time is about 155ms.

[0132] In light of this, embodiments of the present application provide an application launch method that can identify quick launch scenarios. In these scenarios, a launch window is added to the first activity of the application upon loading, a transition page is displayed, and the launch window is passed to subsequent activities. This significantly reduces response time and provides a better visual experience for users with transition pages. Overall, this method can improve user experience.

[0133] The hardware structure and software architecture of the electronic device to which this method is applicable are introduced below with reference to the accompanying drawings.

[0134] The application startup method provided in the embodiments of the present application can be applied to electronic devices that can install application programs (APPs), such as mobile phones, tablet computers, wearable devices, in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, laptop computers, ultra-mobile personal computers (UMPCs), netbooks, and personal digital assistants (PDAs). The embodiments of the present application do not impose any restrictions on the specific types of electronic devices.

[0135] For example, FIG3 is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of the present application. The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0136] It should be understood that the structures illustrated in the embodiments of the present application do not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

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

[0138] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0139] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly retrieve it from the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

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

[0141] Electronic device 100 implements display functionality through a GPU, display screen 194, and an application processor. A GPU is a microprocessor for image processing that connects display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or modify display information.

[0142] Display screen 194 is used to display images, videos, and the like. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-oLed, or a quantum dot light-emitting diode (QLED). In some embodiments, electronic device 100 may include one or N display screens 194, where N is a positive integer greater than one.

[0143] The touch sensor 180K is also called a "touch panel." The touch sensor 180K can be disposed on the display screen 194. The touch sensor 180K and the display screen 194 form a touch screen, also called a "touch screen." The touch sensor 180K is used to detect touch operations applied thereto or in the vicinity thereof. The touch sensor can transmit the detected touch operations to the application processor to determine the type of touch event. Visual output related to the touch operations can be provided via the display screen 194. In other embodiments, the touch sensor 180K can also be disposed on the surface of the electronic device 100, in a location different from that of the display screen 194.

[0144] The software system of the electronic device 100 can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. In the embodiment of the present application, the Android system with a layered architecture is used as an example to illustrate the software structure of the electronic device 100.

[0145] Figure 4 is a block diagram of the software structure of the electronic device 100 according to an embodiment of the present application. The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers: the application layer, the application framework (FWK) layer, the Android runtime and system libraries, and the kernel layer.

[0146] As shown in Figure 4, the application layer may include a series of application packages, which are applications that can start one or more functions through shortcuts, and are collectively shown as applications (APP) in the figure. It is understood that these applications can be system applications or third-party applications, such as video, camera, gallery, payment applications, etc. In the embodiment of the present application, the application layer may also include Android system applications such as the desktop launcher (launcher), system user interface (systemUI) and mobile manager.

[0147] Generally, after the Android system is started, the launcher can be resident in the Android system as a core application and run. The startup icon of the application is generally set in the launcher. Specifically, the launcher can monitor the user's operation on the application icon through the application monitoring process (apTouchDaemon) (not shown in Figure 4). When apTouchDaemon detects that the user clicks on the startup icon of a certain application, apTouchDaemon generates an input event and reports the input event to the launcher. The launcher distributes and processes the input event, generates an application startup message and sends it to the relevant services in the application framework layer, starts the application process of the application through these services, and loads the activity. SystemUI is responsible for drawing the startup window or the application window, etc. It should be understood that when the user clicks on the icons of different applications, the launcher will generate startup messages for different applications, thereby starting the application processes corresponding to different applications.

[0148] Mobile Manager is a system used to manage electronic devices.

[0149] The application framework layer provides an application programming interface (API) and programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0150] As shown in Figure 4, in an embodiment of the present application, the application framework layer may include a system service (systemserver) process, a systemUI process, a Zygote process, and a surfaceflinger process, etc. Specifically, the application framework layer may include a Java framework layer and a native framework layer (also known as a C++ framework layer). The systemserver process, the systemUI process, and the Zygote process may run in the Java framework layer. The surfaceflinger process runs in the native framework layer. In addition, after the mobile phone manager application is started, the Java framework layer may also include a mobile phone manager process.

[0151] Among them, the systemserver process can provide almost all system services for applications in the application layer, such as activity manager service (AMS), window manager service (WMS), package manager service (PMS), and resource manager service (RMS). These system services can reside in the systemserver process in the form of threads. Among them, AMS is responsible for unified scheduling and management of activities of all processes in the system. WMS is responsible for managing window views, such as the position, size, and layout of application windows. PMS is responsible for installing, managing, and uninstalling application packages in the system. Specifically, PMS can identify all components of an application, such as activities, and assign corresponding permissions to these components. RMS is responsible for unified management, scheduling, and optimization of resources in the system.

[0152] The Zygote process is a daemon service in the Android system. Almost all application processes are forked from the Zygote process. Because each application is written in Java, it must run as a process in its own independent virtual machine. When an application starts, it forks its own virtual machine through the Zygote process and shares the virtual machine's memory and services provided by the system server process.

[0153] The surfaceflinger process is responsible for rendering the interface and application graphics. For example, the window drawn by the systemUI process can be rendered and displayed by the surfaceflinger process.

[0154] Typically, in response to a user clicking on an application icon, the launcher can send a startup message of the application to the systemserver process. If the application process of the application does not exist in the current application process, then an application process needs to be created for the application. The systemserver process can call AMS to communicate with the Zygote process and request the Zygote process to create a corresponding application process for the application. After receiving the request, the Zygote process creates application process 1 in response to the request. Application process 1 includes the main thread (activityThread) of the application. In order to start running the application code normally, application process 1 needs to initialize the main thread of the application first and load the class file of the application into memory. Among them, the main thread can complete the initialization of the main thread by executing the main function of activityThread.

[0155] The Mobile Manager process is a process forked by the Zygote process when the Mobile Manager app is launched. It manages the various applications, functions, and data running in the system. The Mobile Manager process can also run a non-real-time processing subsystem, including a configuration processing module. This module processes configuration information for applications or activities.

[0156] The application startup method provided in the embodiments of the present application can be implemented through the cooperation of the apTouchDaemon process, the launcher process, the Zygote process, the mobile phone manager process, the systemserver process, the systemUI process, the surfaceflinger process, etc. Among them, the apTouchDaemon process, the launcher process, the systemserver process, the systemUI process, the surfaceflinger process, and the mobile phone manager process can communicate with each other based on the binder mechanism. The systemserver process and the Zygote process can communicate based on the socket mechanism.

[0157] The Android runtime includes the core library and the virtual machine. The Android runtime is responsible for scheduling and management of the Android system.

[0158] The core library consists of two parts: one is the function that needs to be called by the Java language, and the other is the Android core library.

[0159] The application layer and application framework layer run in a virtual machine. The virtual machine executes Java files in the application layer and application framework layer as binary files. The virtual machine manages object lifecycles, stack management, thread management, security and exception management, and garbage collection.

[0160] The system library can include multiple functional modules, such as a surface manager, media libraries, a 3D graphics processing library (such as OpenGL ES), and a 2D graphics engine (such as SGL).

[0161] The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

[0162] The media library supports playback and recording of a variety of common audio and video formats, as well as static image files. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

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

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

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

[0166] The following will introduce the native process of application startup based on the software architecture provided in Figure 4 and in conjunction with Figure 5. This native process can be applied to the scenario examples shown in Figures 1 and 2. Taking the example of launching function a of application A through a shortcut, assuming that the interface of function a is the interface corresponding to the nth activity (i.e., the target interface) is interface a, the system needs to load the 1st to nth activities in sequence and then display the target interface a. Among them, function a can be, for example, the payment function of a payment application, and the target interface a can be the payment code interface 102 shown in Figure (c) of Figure 1 and Figure (d) of Figure 2.

[0167] Figure 5 is a timing diagram of an example of an application startup method provided by an embodiment of the present application. As shown in Figure 5, taking function a of application A cold-started through a shortcut as an example, the startup process includes:

[0168] ① In response to the occurrence of the up event in the quick launch operation, the launcher process calls the startShortcut() function to send a startup message to the systemserver process.

[0169] Optionally, the quick launch operation may be, for example, the operation of clicking on a desktop shortcut icon, or long pressing an application icon and then clicking on a function option. Specifically, apTouchDaemon detects the user's quick launch operation, and detects that the quick launch operation has been lifted (i.e., a lift event occurs), and generates an input event. apTouchDaemon calls the InputEvent() function to report the input event to the launcher process. After receiving the input event, the launcher process determines the application (application A) corresponding to the input position and the interface (interface a) corresponding to the function to be launched. Afterwards, the launcher process sends a launch message to the AMS in the systemserver process through the startShortcut() function based on the binder mechanism. The launch message is used to request to launch function a of application A in a shortcut manner. Optionally, the launch message may carry information about the application to be launched (i.e., application A) and information about the function to be launched (i.e., function a). The application information may include, for example, one or more of the application package name, the package identity document (ID), etc. The information of the function to be started may include, for example, one or more of the name of the function to be started, the ID of the function to be started (also called the ID of the quick start function or the first information, hereinafter referred to as the quick function ID), etc. The quick function ID is used to mark the unique identity of the function to be started.

[0170] ②The systemserver process responds to the startup message and requests the Zygote process to fork the process of application A. The Zygote process responds to the request and forks the process of application A.

[0171] Specifically, the AMS in the systemserver process responds to the startup message and requests the Zygote process to fork the process of application A through the socket communication mechanism. The Zygote process responds to the request of the AMS and forks the process of application A.

[0172] ③The systemserver process handles the startup transaction of the first activity. At the same time, the systemserver process collects the activity record (activityRecord) corresponding to the first activity of application A.

[0173] As you can understand, the Active Directory Management Service (AMS) in the systemserver process is responsible for managing and scheduling activities and handling activity-related transactions, such as start requests. While the AMS is processing activity transactions, the WMS can collect the activity's status information to facilitate subsequent management of the activity's operation, determine the participants in subsequent transition page animations, assign layers to participants, and draw animations. Activity status information can be maintained using activityRecords. ActivityRecords are the smallest unit of activity management, and each activityRecord corresponds to an activity in the application process.

[0174] In this step, in response to the start message, the systemserver process defaults to starting the first activity of application A. Therefore, after the process of application A forks, the AMS handles the start transaction of the first activity. At the same time, the WMS collects the activityRecord corresponding to the first activity to record the status of the activity.

[0175] ④The systemserver process calls the activityPaused() function to notify the activity in the launcher process to enter the pause state. At the same time, the systemserver process collects the launcher's activityRecord.

[0176] In this step, the activity in the launcher process enters the pause state, so AMS records the status of the activity in the launcher process by collecting activityRecord.

[0177] Optionally, when pausing the activity in the launcher process, the participants of the animation may also involve wallpaper or the leftmost home screen, so the activityRecord of the wallpaper or the leftmost home screen may also be collected. This application does not make specific restrictions on this.

[0178] It is understood that when other activities are started or paused, the WMS also collects activityRecords until the transaction is ready. This will not be described in detail in the subsequent embodiments.

[0179] ⑤The systemserver process instructs the process of application A to execute the life cycle of the first activity. In response to the instruction of the systemserver process, the process of application A executes the life cycle of the first activity.

[0180] Specifically, the activity lifecycle includes starting the activity using the activityStart() function, loading the activity layout using the activityResume() function, drawing the frame using the doFrame() function, and completing the drawing using the finishDrawing() function, etc. (not all of which are shown in Figure 5). After the frame drawing is completed using the doFrame() function, Application A's process can request the systemserver process to add a display. The systemserver process uses addToDisplay() to add the activity to the display.

[0181] ⑥ During the execution of the first activity's lifecycle, application A's process calls the startActivity() function to request the system server process to start the second activity. The system server process handles the second activity's start request and collects the activityRecord corresponding to the second activity.

[0182] Optionally, the process of application A can request to start the second activity during the activityStart phase or activityResume phase of the first activity lifecycle.

[0183] After determining that Application A's process has completed the lifecycle of the first activity, the systemserver process calls the activityPaused() function to notify Application A's process to pause the first activity and instruct it to execute the lifecycle of the second activity. In response to the instruction from the systemserver process, Application A's process executes the lifecycle of the second activity.

[0184] And so on, until the process of application A executes the life cycle of the n-1th activity.

[0185] ⑧ During the lifecycle of the n-1th activity, application A's process calls the startActivity() function to request the system server process to start the nth activity. The system server process handles the start request for the nth activity and collects the activityRecord corresponding to the nth activity.

[0186] ⑨ When processing the start request for the nth activity, the systemserver process notifies the systemUI process to add the startup window. The systemUI process calls the addStartingWindow() function to create the startup window, uses the doFrame() function to draw the startup window view, and then uses the finishDrawing() function to indicate that the startup window drawing is complete. After the systemserver process determines that the startup window drawing is complete, the application is ready (applyReady).

[0187] ⑩ After determining that application A's process has completed the lifecycle of activity n-1, the systemserver process calls the activityPaused() function to notify application A's process to pause activity n-1 and instruct application A's process to execute the lifecycle of activity n. In response to the instruction from the systemserver process, application A's process executes the lifecycle of activity n.

[0188] After confirming that the startup window has finished drawing, the systemserver process notifies the systemUI process that the transaction is ready. The systemUI process executes the transaction ready through the onTransactionReady() function.

[0189] Transaction ready indicates that the transition is ready and can be executed.

[0190] In other embodiments, transaction ready (onTransactionReady) may also be referred to as transition ready (transitionReady).

[0191] It can be understood that when the systemserver process notifies the systemUI process that the transaction is ready to execute, the ready transition can be submitted to the systemUI process. After being processed by the systemUI process, the launcher process is further notified to execute the animation.

[0192] After the transaction is ready and executed, the systemUI process notifies the launcher process to execute the animation. The launcher process starts the animation using the startAnimation() function and executes the animation using the animator() function, executing the transition to display the transition page. The transition is generated based on the activityRecords collected from each activity.

[0193] After determining that the process of application A has completed the life cycle of the nth activity, the systemserver process calls showSurface() to display the layer corresponding to the nth activity, that is, to display the target interface a.

[0194] The systemserver process calls the removeStartingWindow() function to remove the startup window and display the interface of application A in the window of application A.

[0195] It should be noted that if the target interface a of application A is drawn during the animation process, the interface can be displayed, but at this time, the animation layer is on the upper layer and the interface cannot respond to user operations. After the animation is completed, the interface displayed in the window can respond to user operations.

[0196] As can be seen from the above description, in the native process, the quick launch of Application A requires jumping through multiple activities. The time between the user executing the quick launch operation and the display of the transition page (i.e., the response time) is relatively long. This response time is approximately equal to the sum of the lifecycles of all activities in Application A. In other words, the native process requires all screens preceding the target screen (called intermediate screens) to be ready before responding. Therefore, the response time depends on the lifecycle of Application A's intermediate screens, resulting in a slow response.

[0197] The following is an analysis of the reasons why the native process responds slowly.

[0198] The display of the transition page depends on the startup window. Only when the startup window is successfully added can the transition page be displayed normally.

[0199] In some embodiments, when cold-starting an application from the desktop (i.e., clicking an application icon on the desktop) without using a shortcut, a partial process of adding a startup window is as follows:

[0200] It can be seen that when the application is started without a shortcut, the startup window can be added through the related process of addStartingWindow to display the transition page.

[0201] In some other embodiments, when cold starting an application from the desktop via a shortcut, a partial process of adding a startup window is as follows:

[0202] It can be seen that when quickly launching an application, adding a startup window through the addStartingWindow() function returns false, which means that adding the startup window is blocked.

[0203] Analysis revealed that the themes for these blocked activities were empty. This was because the activities had a transparent attribute (windowIsTranslucent was set to true). However, the native system does not add a launch window to activities with a transparent attribute.

[0204] Further analysis revealed that the multiple activities loaded during the application launch process are in different task stacks, meaning that the quick launch process involves loading activities across different task stacks. For example, in the aforementioned embodiment, when quickly launching the payment application's cash collection function, n activities may be located in different task stacks. However, the native system lacks a mechanism for maintaining launch windows across task stacks. When loading activities across task stacks, the system attempts to add a launch window for each activity in each task stack. This results in frequent switching of launch windows when switching task stacks, which can lead to screen flashing. To address this issue, the application sets the windowIsTranslucent property to true for the activities corresponding to the screen preceding the target screen for quick launch. This allows the native system to intercept the launch windows of these activities, thus preventing screen flashing when quickly launching a specific application function. It should be noted that although the launch windows of these activities are intercepted, the system still loads transitions for these activities, but without the launch window, the transition cannot be ultimately displayed.

[0205] In other words, the native system does not support maintaining the startup window across task stacks, which can cause screen splashing. To avoid screen splashing, applications set the transparency attribute of the activity to intercept the startup window. Ultimately, the startup window cannot be added when the application is quickly launched, or the startup window is added only when the last activity is started. As a result, the application's response time depends on the life cycle of the activity corresponding to the intermediate interface, resulting in a slow response.

[0206] Based on the above analysis, the present application provides an application startup method, which adds a startup window addition process based on the native system. Specifically, when processing the first activity startup transaction of the application (that is, before the first activity is started), the startup window is added. This addition process is triggered by the systemserver process and executed by the systemUI process. It does not require the participation of the application process and does not involve the application's activity. Therefore, it will not be intercepted by the system due to issues such as the activity's transparent attribute. The startup window is added before the first activity is started. After the window is drawn and the transition is loaded, the transition page can be displayed. In this way, the display of the transition page does not need to rely on the application activity life cycle, which not only greatly shortens the application's response time, but also improves the interface response time and improves the user experience. In addition, when a quick launch is identified, each activity and transition of the application is identified, and a startup window is added for the first activity. For the activities after the first activity and before the activity corresponding to the target interface, the startup window is passed to these activities in sequence. After the activity corresponding to the target interface is loaded, the startup window is removed. In this way, the continuity of the transition page display is guaranteed, and screen flashing caused by frequent switching of the startup window is prevented.

[0207] The following describes the improvements to the software architecture involved in the embodiments of the present application based on the software architecture shown in FIG4 .

[0208] It can be understood that each system service running in the systemserver process can be regarded as a software module, which can provide corresponding services and implement corresponding functions. Based on this, each system service can include a module for implementing a part of the functions (i.e., sub-functions) of the system service functions to implement the application startup method of this application. The same is true for other modules. The following describes the functional modules related to the application startup method provided by this application contained in each system service and related modules.

[0209] For the sake of convenience of description, the process of the quick launch application method that can shorten the response time provided in the embodiment of the present application is referred to as the optimization process, and the quick launch function corresponding to the optimization process is referred to as the optimization launch function.

[0210] For example, Figure 6 is a schematic diagram of the software architecture of another electronic device provided in an embodiment of the present application. Referring to Figure 6 , in an embodiment of the present application, the configuration processing module may include a configuration parsing module. The configuration parsing module is used to read and parse relevant configurations of the optimized startup function, including but not limited to the optimized startup function switch, the delayed removal time of the startup window, the delayed removal threshold, the application type whitelist, the package blacklist, etc. The optimized startup function switch is used to control the turning on and off of the optimized startup function, that is, to control whether the optimization process is executed or not. When the switch is on, the system executes the optimization process. When the switch is off, the system does not execute the optimization process and executes the native process instead. The delayed removal time of the startup window refers to the length of time the startup window is delayed, that is, the time after which the startup window is removed. The delayed removal threshold refers to the maximum number of times the startup window can be delayed, such as 5 times, 8 times, etc. The application type whitelist includes information on application types allowed to be launched through the optimized process. For example, the application type whitelist may include video applications, audio applications, instant messaging applications, payment applications, etc. The package blacklist includes information on application packages that are not allowed to be launched through the optimized process. The package blacklist may include, for example, package a, package b, package c...

[0211] RMS includes a cache configuration module, which is used to cache the configuration information parsed by the parsing configuration module to support the optimized startup function.

[0212] The PMS may include a quick launch identification module. The quick launch identification module is used to identify whether the application launch is a quick launch, that is, whether it is launched via a shortcut. Furthermore, the quick launch identification module is used to filter quick launch applications or application functions based on the application type whitelist and package blacklist cached in the cache configuration module to determine whether the current launch meets the execution scenario of the optimization process provided in this application.

[0213] WMS may include an activity identification module, a transition identification module, a startup window management module, and a transition component management module. The activity identification module is used to identify the various activities requested to be loaded during the application startup process to determine whether each activity is the first activity in the quick startup scenario or another activity. The transition identification module is used to identify the various transitions loaded by WMS to determine whether each transition is the first transition (also known as the first transition component) in the quick startup scenario or another transition. The startup window management module is used to manage the startup window based on the identification results of the activity identification module and the transition identification module, including but not limited to requesting to add a startup window, transferring a startup window, removing a startup window, etc. The transition component management module is used to manage transitions, including but not limited to creating transitions, controlling the execution timing of transitions, setting transition parameters, etc. The parameters of transitions may include, for example, animation attributes. If the animation attribute is set to "yes" (for example, true), the transition is displayed in the form of animation, that is, there is animation; if the animation attribute is set to "no" (for example, false), the transition is not displayed in the form of animation, that is, there is no animation.

[0214] The following will take an electronic device having the structure shown in Figures 3 and 6 as an example, combined with the accompanying drawings and application scenarios, to specifically explain the application startup method provided in the embodiment of the present application.

[0215] Figure 7 is a timing diagram of an example of an application startup method provided by an embodiment of the present application. As shown in Figure 7, continuing to take function a of application A cold-started through a shortcut as an example, the startup process includes:

[0216] ① In response to the occurrence of the up event in the quick launch operation, the launcher process calls the startShortcut() function to send a startup message to the systemserver process.

[0217] ②The systemserver process responds to the startup message and requests the Zygote process to fork the process of application A. The Zygote process responds to the request and forks the process of application A.

[0218] ③The systemserver process handles the launch of the first activity and collects the activityRecord corresponding to application A's first activity. The systemserver process then calls the activityPaused() function to notify the launcher process to pause the activity and instructs application A's process to execute the lifecycle of the first activity. Simultaneously, the systemserver process collects the launcher's activityRecord.

[0219] ④ After the systemserver process handles the startup transaction for the first activity, it notifies the systemUI process to add the startup window. The systemUI process calls addStartingWindow() to create the startup window, uses doFrame() to draw the startup window view, and then uses finishDrawing() to indicate that the startup window drawing is complete. After the systemserver process determines that the startup window drawing is complete, it declares the application ready (applyReady).

[0220] ⑤While the systemUI process creates the startup window, the application A process responds to the instructions of the systemserver process and executes the life cycle of the first activity.

[0221] ⑥ After confirming that the startup window has finished drawing, the systemserver process notifies the systemUI process that the transaction is ready. The systemUI process executes the transaction ready through the onTransactionReady() function.

[0222] ⑦After the transaction is ready and executed, the systemUI process notifies the launcher process to execute the animation. The launcher process starts the animation through the startAnimation() function and executes the animation through the animator() function, that is, executing the transition to display the transition page.

[0223] ⑧ While Application A's process is executing the lifecycle of the first activity, it calls the startActivity() function to request the systemserver process to start the second activity (not shown in Figure 7). The systemserver process handles the start request for the second activity and collects the corresponding collectactivityRecord for the second activity (not shown in Figure 7). After determining that Application A's process has completed the lifecycle of the first activity, the systemserver process calls the activityPaused() function to notify Application A's process to pause the first activity and instruct Application A's process to execute the lifecycle of the second activity. This continues in this manner, executing Application A's third, ..., and nth activities.

[0224] ⑨ After determining that the process of application A has completed the life cycle of the nth activity, the systemserver process calls showSurface() to display the layer corresponding to the nth activity, that is, to display the target interface a.

[0225] ⑩The systemserver process calls the removeStartingWindow() function to remove the startup window and display the interface of application A in the window of application A.

[0226] Comparing Figure 5 and Figure 7, and combining them with Figure 8, we can see that in the native process, the startup window is added after the process of application A requests to start the nth activity. Therefore, the addition of the startup window and the display of the transition page need to be done after the previous n-1 activities are started, which depends on the life cycle of the activity in the application's intermediate interface. In the optimized process, the systemserver process adds the startup window when processing the startup transaction of the first activity of application A, that is, when the systemserver process starts the first activity. After adding the startup window and completing the drawing of the startup window, the transaction is ready. The transition page can be displayed after the systemUI process executes the onTransactionReady() function. The entire process of adding the startup window and displaying the transition page can be synchronized with the execution of the activity life cycle by the application A process, without relying on the life cycle of the application A activity, which greatly shortens the response time. Simply put, the optimized process is equivalent to moving the execution timing of step ⑨ in the native process from starting the nth activity to starting the first activity, and the subsequent steps and The responses are also moved forward in sequence, thus greatly shortening the response time and effectively improving the user experience.

[0227] Continuing with Figures 5, 7, and 8, in the native process, the application interface is displayed before the animation is complete. However, the interface is unresponsive to user actions, resulting in a poor user experience. In the optimized process, the animation is executed earlier and concurrently with the loading of application A's activity. As a result, the animation is completed earlier, and the application's activity is loaded and ready to respond to user actions as soon as the interface begins to display, eliminating the need for users to wait and improving the user experience.

[0228] The optimization process is summarized above with reference to the accompanying figures to illustrate how the method provided by this application reduces response time from a timing perspective. The specific implementation of the optimization process is further described below with reference to Figure 6 to clarify the execution details of the process, explaining how to transfer and manage the startup window after it is added, and how to manage transitions to improve the smoothness of the transition page display.

[0229] First, the process of parsing the configuration module in the mobile phone manager process to parse the relevant configuration of the optimization startup function is explained.

[0230] The parsing configuration module is initialized when the electronic device is turned on, and reads and parses the configuration related to the optimized startup function. Optionally, the name of the configuration related to the optimized startup function can be, for example, "AwareAddStartWindow". Through parsing, the corresponding type (type) of the function, the switch of the optimized startup function (switch), the delayed removal time (delayTime) of the startup window, the delay removal threshold (delayCount), the application type whitelist (also known as the support type supportType), and the package blacklist (pkgBlacklist) can be obtained.

[0231] It is understood that if an application type belongs to the application type whitelist and the application package is not in the package blacklist, it means that the application is suitable for the optimization process and can be quickly launched through the optimization process. Otherwise, it means that the application is not suitable for the optimization process and can be launched through the native process.

[0232] The parsing configuration module caches the parsing results in the RMS in the systemserver process. When the optimization startup function is turned on, the optimization process runs. During the optimization process, each module can obtain corresponding parameters from the RMS as needed.

[0233] The following describes the implementation of the optimization process. This embodiment continues to use the quick launch of application A as an example. In the following description, the fork process of application A is not repeated. In addition, for ease of understanding, the method provided in this embodiment of the application is described according to the launch process of the first activity of the application (referred to as the first stage) and the launch process of the second and subsequent activities (referred to as the second stage).

[0234] 1. Phase 1

[0235] The first phase involves launching the app's first activity. Before launching the app's first activity, the quick launch scenario is identified. When processing the first activity's launch transaction, the first activity is identified to ensure that the activity to be launched is the app's first activity in the quick launch scenario, accurately adding a launch window to the first activity. Furthermore, the first transition is identified to set its properties and improve the display quality of the transition page. This is explained below with reference to the accompanying figures.

[0236] FIG9 is a timing diagram of another example of an application startup method provided in an embodiment of the present application. FIG10 is a flow diagram of an example of an application startup method provided in an embodiment of the present application. Please refer to FIG9 and FIG10 together. The method includes:

[0237] S101. In response to the occurrence of an up event in a quick start operation, the launcher process calls a startShortcut() function to send a start message to the systemserver process.

[0238] Optionally, the startup message carries information of the application to be started (application A) and information of the function to be started (function a). In this embodiment, the information of the function to be started is taken as a shortcut function ID as an example for description.

[0239] Optionally, the launcher process may also pass the information of the application to be launched and the shortcut function ID to the systemserver process through an intent.

[0240] S102 : The quick launch identification module in the PMS of the systemserver process responds to the launch message, and if it is determined that the current launch is a quick launch and the information of application A meets the preset conditions, the quick function ID is stored in the cache.

[0241] Determining whether an application meets the preset conditions is essentially filtering the application. Therefore, this step can be simply called identifying and filtering quick launches.

[0242] Optionally, the quick launch identification module can determine whether the current launch is a quick launch based on whether the launch message carries a quick function ID. Specifically, the quick launch identification module obtains application information and a quick function ID from the intent in response to the launch message. If the quick function ID is obtained from the intent, it indicates that the current launch is a quick launch, that is, the current scene is a quick launch scene; otherwise, it indicates that the current launch is not a quick launch, and the current scene is not a quick launch scene.

[0243] The preset conditions may include, for example, that the type of application A is in the application type whitelist, and the package of application A is not in the package blacklist. Specifically, when it is determined that the current startup is a quick startup, the quick startup identification module can obtain the application type whitelist and package blacklist from the configuration cache module, and determine whether the class of application A is in the application type whitelist and whether the package of application A is in the package blacklist based on the information of application A carried in the startup message, thereby determining whether application A meets the preset conditions. If the type of application A is in the application type whitelist, and the package of application A is not in the package blacklist, it is determined that the information of application A meets the preset conditions. Otherwise, it means that the information of application A does not meet the preset conditions.

[0244] If the current startup is a quick startup, and the information of application A meets the preset conditions, it means that the current scenario is a quick startup scenario, and quick startup can be performed according to the optimization process in the current scenario, so the quick function ID is stored in the cache of the systemserver process. In this way, on the one hand, the quick function ID in the cache is used as the identifier of the scene to mark that the current scene can be quickly started through the optimization process. On the other hand, the quick function ID in the cache is used as the identifier of the first activity to mark the activity to be started at the current moment as the first activity of application A. It should be noted that in other embodiments, the above two aspects can also be marked by other identification information, such as preset characters, preset numbers, preset text, etc. The embodiment of the present application does not impose any limitation on this and can be set according to actual needs.

[0245] If the current launch is not a quick launch and / or App A's information does not meet the preset conditions, the optimized process is not suitable for quick launch in the current scenario, so the quick function ID is not cached. If the quick function ID cannot be identified from the cache in subsequent processes, the process automatically switches to the native process for execution.

[0246] In this step, by identifying quick launches, the optimization process is limited to those scenarios, improving the accuracy of process execution. Furthermore, by setting up an application type whitelist and package blacklist, applications that are not suitable for the optimization process can be filtered out, preventing these applications from entering the optimization process and being unable to execute, ensuring the normal startup of these applications through the native process.

[0247] In other embodiments, during the execution of the optimization process, the quick function IDs that have startup anomalies can be collected and added to the function blacklist. In this case, the preset conditions can further include: the quick function ID is not located in the function blacklist. The fact that the quick function ID is not located in the function blacklist further indicates that function a of application A is suitable for quick startup through the optimization process, and the quick function ID is cached. In this way, the functions to be started that are not suitable for the optimization process are further filtered to prevent quick startup errors and improve the user experience.

[0248] S103: The AMS in the systemserver process starts processing the startup transaction of the first activity, and the transition component management module in the WMS in the systemserver process collects the activityRecord corresponding to the first activity.

[0249] S104. The activity identification module in the WMS identifies the first activity according to the shortcut function ID. After identifying the first activity, the source record (sourceRecord) of the first activity (also called the first sourceRecord) is set to the activityRecord corresponding to the first activity, and the first sourceRecord is added to the sourceRecord collection.

[0250] This step can be simply called identifying the first activity and setting the sourceRecord.

[0251] Specifically, the activity recognition module reads the shortcut function ID from the cache. If the read is successful, the currently launched activity is determined to be the first activity launched in the quick launch scenario, i.e., the first activity has been identified. Optionally, the activity recognition module can add an identifier to the first activity to indicate that it is the first activity, making it easier to quickly determine whether the activity is the first activity later. For example, the identifier for the first activity could be "first."

[0252] After identifying the first activity, the activity recognition module sets the value of the first sourceRecord to the activityRecord corresponding to the first activity and adds the first sourceRecord to the sourceRecord set.

[0253] SourceRecord is used to indicate the source of the activity that started it, that is, the previous activity that started the currently started activity. In this embodiment of the application, a corresponding sourceRecord is set for each activity and a value is assigned to the sourceRecord. The collection of sourceRecords corresponding to multiple activities is called a sourceRecord collection.

[0254] Specifically, after identifying the first activity, assign a value to the sourceRecord (i.e., the first) corresponding to the first activity. Optionally, the value of the sourceRecord corresponding to the first activity can be set to its (first activity) activityRecord. For any activity started after the first activity, perform the sourceRecord value transfer operation. For ease of explanation, the next activity to be started is called the new activity. The activity that requests to start the new activity is called the old activity or the source activity. In a specific embodiment, the old activity passes the sourceRecord value to the new activity, that is, the sourceRecord of the old activity is used as the value of the sourceRecord of the new activity. In this way, the old activity that starts the new activity can be determined by the value of the sourceRecord.

[0255] In this embodiment, each activity is identified and a corresponding sourceRecord value is assigned to it. This facilitates the subsequent use of the sourceRecord as the basis for delivering the launch window. Specifically, the sourceRecord value of the new activity is obtained. In most cases, the old activity corresponding to this value is the activity currently holding the launch window. Therefore, based on the sourceRecord value, the activity holding the launch window can be found, and the launch window can be obtained from this activity and delivered to the activity requesting launch. The delivery of the launch window will be further explained in step S208 of the subsequent embodiment.

[0256] On the other hand, the optimization process of this solution identifies each activity and sets the corresponding sourceRecord for the activity, which is not available in the native process. Then, conversely, if there is a sourceRecord in the sourceRecord set, then the sourceRecord is set by the optimization process of this solution, indicating that the current scenario is a quick start scenario, and at least the first activity has been started. Therefore, in the subsequent process, sourceRecord will also be used as the basis for identifying other activities after the first activity. Specifically, if there is a sourceRecord in the sourceRecord set, it means that the currently started activity is the second activity in the quick start scenario or the activity after the second activity (called other activities). Other activities will be further explained in step S205 in the subsequent embodiments.

[0257] In some embodiments, when launching a cross-process, such as launching WeChat In mini-programs, or other special scenarios, when a request is made to start an activity that's already started, the system reuses the already started activity. In this case, the activity holding the launch window isn't actually the old activity that requested the new activity, but the reused activity. Therefore, when passing the sourceRecord value according to the above logic, the value passed may be null. This can cause subsequent launch window delivery or activity identification failures, leading to optimization failure. To address this situation, the optimization solution allows for null sourceRecord values ​​when launching a new activity, and if the sourceRecord value passed is null and the activity holding the launch window exists in the collected sourceRecord collection, this indicates a special scenario like a cross-process launch. Therefore, the activityRecord corresponding to the activity holding the launch window can be used as the sourceRecord value for the new activity. This ensures the correct assignment of the sourceRecord value, prevents subsequent launch window delivery or activity identification failures, and ensures the reliability of the optimization process.

[0258] Of course, in some other embodiments, other methods may be used to assign values ​​to the sourceRecord of each activity, and the embodiments of the present application do not impose any limitation on this.

[0259] S105 . The activity identification module in the WMS of the systemserver process sets a condition variable and a valid duration of the condition variable.

[0260] This step can be simply called setting the conditional variables.

[0261] The conditional variable is used to limit the startup timing of the second activity of application A to prevent the startup of the second activity from affecting the loading of the first transition and thus affecting the display of the transition page.

[0262] Optionally, the conditional variables may include two: conditional variable 1 and conditional variable 2. Conditional variable 1 is: the first transition has been submitted to the systemUI process. Conditional variable 1 indicates that the first transition has been handed over to the systemUI process for processing, and the processing of the first transition no longer occupies the systemserver process. Therefore, starting the second activity of application A and creating a second transition (also called the second transition component) will not affect the loading of the first transition, and thus will not affect the display of the transition page. Conditional variable 2 is: the layer display (showSurface) of the startup window has been completed. The layer display of the startup window has been completed, and the processing of the startup window of the first activity no longer occupies the systemserver process. Therefore, starting the second activity of application A and creating a second transition will not affect the loading of the first transition, and thus will not affect the display of the transition page.

[0263] The validity period of a condition variable indicates how long the condition variable is valid after the setting time. For example, a condition variable can be 20ms, which means that the condition variable is valid for 20ms after the setting time.

[0264] If the condition variable is unlocked within the valid time, the start request of the second activity of application A is triggered. This will not affect the processing of the transition page, so that the transition page can be displayed as soon as possible, thereby minimizing the response time of the application quick start.

[0265] If the condition variable is not unlocked within the validity period, it will be automatically unlocked when the validity period expires. This can prevent the condition variable from being unlocked due to process execution exceptions, which can cause subsequent activities to be unable to start, thereby improving system stability.

[0266] The unlocking of the conditional variable and the process after unlocking can refer to steps S202 to S204 in the subsequent embodiments.

[0267] S106 . The transition component management module in the WMS of the systemserver process creates the first transition according to the activityRecord corresponding to the collected first activity.

[0268] S107 . The transition component identification module in the WMS of the systemserver process identifies the first transition according to the activityRecord in the first transition.

[0269] This step can be simply called identifying the first transition.

[0270] Specifically, as in step S104 above, the activity identification module has identified the first activity. Therefore, the transition component identification module determines whether the activityRecord collected in the current transition is the activityRecord corresponding to the first activity, and further determines whether the current transition is the first transition.

[0271] Optionally, the transition component identification module may add a transition identifier 1 to the identified first transition, where the transition identifier 1 is used to indicate that the transition is the first transition.

[0272] S108. The startup window management module in the WMS of the systemserver process requests the systemUI process to add a startup window (also called the first startup window) for the first activity.

[0273] As a possible implementation method, after identifying the first transition and before requesting the systemUI process to add a startup window (i.e., after step S107 and before step S108), the activity identification module in the WMS of the systemserver process can also execute step S104 again, i.e., identify the first activity and set the sourceRecord corresponding to the first activity. As mentioned above, in some cases, the system may reuse activities, so the first activity may be a reused activity. After identifying the first transition and before requesting to add a startup window, the systemserver process executes step S104 again, which can further accurately identify the first activity, thereby further ensuring the correct assignment of sourceRecord, preventing subsequent startup window delivery failure or activity recognition failure, and ensuring the reliability of the optimization process.

[0274] S109 . The systemUI process starts adding and drawing a startup window in response to a request from the startup window management module.

[0275] Specifically, the systemUI process calls the addStartingWindow() function to create the startup window and uses the doFrame() function to draw the startup window frame. After the frame drawing is completed, the systemUI process requests the WMS in the systemserver process to add the startup window to the display.

[0276] After the startup window is drawn, the systemUI process calls the finishDrawing() function to indicate to the systemserver process that the startup window drawing is complete. The WMS in the systemserver process displays the startup window layer using showSurface().

[0277] Steps S108 and S109 may be simply referred to as adding a startup window.

[0278] S110: The AMS in the systemserver process calls the activityPaused() function to notify the launcher process to enter a paused state, and instructs the process of application A to execute the lifecycle of the first activity. The transition component management module in the WMS in the systemserver process collects the launcher's activityRecord.

[0279] It can be understood that step S110 can be executed after the above steps S102 to S109, or can be executed simultaneously with the above steps S102 to S109.

[0280] S111 . The process of application A responds to an instruction from the AMS and starts executing the life cycle of the first activity.

[0281] S112. After the systemUI process starts adding a startup window, the startup window management module identifies whether the startup window is a startup window added through the optimization process; if so, execute step S113; if not, execute step S114.

[0282] S113: The startup window management module adds an optimized window identifier to the startup window and saves the optimized window identifier to a cache. The optimized startup identifier is used to indicate that the currently added startup window is a startup window added through an optimization process.

[0283] S114: Start the window management module to clear the identification information added through the optimization process.

[0284] The above steps S112 to S114 can be simply referred to as identifying the optimization window.

[0285] As analyzed in the above embodiment, when an application's activity starts, the native system may add a startup window to the activity. If the application sets the transparency attribute for the activity, or if the application sets code to reject the addition of a startup window, the native system will fail to add the startup window. However, in actual use, if the application's actual business requires adding a startup window to the first activity, the application no longer sets the transparency attribute for the activity. In this case, the native system's process will successfully add a startup window to the first activity. In this case, it is necessary to abandon the optimized process of this application and run according to the native process to prevent disruption to the application's original startup logic.

[0286] Based on this, in this embodiment, after the startup window begins to be added, it is further identified whether the startup window is the startup window added by the optimization process. If the startup window is the startup window added by the optimization process, the optimization window identifier is added. The optimization window identifier can be used as a basis for determining whether to remove the startup window later. For details, see subsequent steps S209 to S212. If the startup window is not the startup window added by the optimization process, all marking information added by the optimization process is cleared, including but not limited to the shortcut function ID, sourceRecord collection, conditional variables, the effective duration of the conditional variables, etc. In addition, if the first activity and the first transition are identified and marked, these identifiers are also cleared. In this way, the subsequent process enters the native process to prevent disruption to the original startup logic of the application, improve the accuracy of the execution of the optimization process, and thereby improve the stability of the system operation.

[0287] It's understandable that regardless of whether the startup window is added by the optimization process, the drawing startup window will continue to be added. That is, after steps S113 and S114, the drawing startup window will continue to be added. The difference is that after S113, the other steps of the optimization process will continue, while after S114, the native process will be executed.

[0288] The specific method for identifying whether the first startup window is a startup window added by the optimization process will be further described in subsequent embodiments.

[0289] S115. The WMS in the systemserver process responds to the request from the systemUI process by calling the addToDisplay() function to start adding the window display. After the window display is added, the applyReady function is triggered. The transition component management module in the WMS prepares the first transition. After the first transition is prepared and before submitting it to the systemUI process, the transition component management module in the WMS removes the transparency attribute of the first transition.

[0290] Before the first transition is submitted to the systemUI process, that is, before the systemserver process requests the systemUI process to execute the transaction ready (onTransactionReady).

[0291] Specifically, as mentioned above, after the systemUI process completes drawing the frame of the startup window through the doFrame() function, it requests the WMS in the systemserver process to add the startup window to the display. In response to the request of the systemUI process, the WMS in the systemserver process calls the addToDisplay() function to add the startup window to the display. After the startup window is added and displayed, the WMS is triggered to enter the apply ready (applyReady) stage, and the WMS prepares for the transition. After the transition preparation is completed, the WMS executes the application transaction ready (AppTransitionReady), and then submits the transition to the systemUI process for processing. In other words, adding the display (addToDisplay) to the startup window triggers transitionReady, and therefore, it enters the transitionReady stage before the startup window finishes drawing (finishDrawing). In the native process, transitionReady is triggered by finishDrawing of the startup window. In other words, the optimization process advances transitionReady so that transitionReady is between the moment the startup window is added (addStartingWindow) and the moment the startup window finishes drawing (finishDrawing). In this way, the animation effect is displayed earlier, the response time of the application quick launch is further shortened, and the user experience is improved.

[0292] It should be noted that triggering transitionReady in advance can be performed as an optional solution. In other embodiments, transitionReady can also be triggered by completing drawing (finishDrawing) of the startup window as shown in Figure 7. The embodiments of the present application do not impose any restrictions on this.

[0293] To cancel the transparent property of a transition, for example, the transparent property value of the transition may be set to false.

[0294] S116. The transition component management module in the WMS of the systemserver process submits the first transition after the transparent attribute is canceled to the systemUI process for processing. After the systemUI process completes the processing, it submits the first transition after the transparent attribute is canceled to the launcher process, notifying the launcher process to execute the first transition. The launcher process executes the first transition to display the transition page.

[0295] Steps S115 and S116 can be simply referred to as the control of the first motion effect.

[0296] Specifically, the transition component management module submits the first transition after removing the transparent attribute to the systemUI process for processing and calls the onTransactionReady() function to request transaction readiness. The systemUI process calls the onTransactionReady() function to execute the transaction. After the transaction is ready, the systemUI process submits the first transition to the launcher process, notifying the launcher process to execute the transition. The launcher process starts the animation using the startAnimation() function and executes the animation using the animator() function to display the transition page.

[0297] If the transition has the transparency attribute, the system cannot generate the icon enlargement animation. Therefore, in this step, the transparency attribute of the first transition is removed. This will pass the transition without the transparency attribute to the systemUI process for processing, and then further submit it to the launcher process. This way, the launcher process can execute the icon enlargement animation, improving the animation effect and enhancing the user's visual experience.

[0298] S117. During the execution of the life cycle of the first activity, the process of application A determines, in the activityResume phase, whether the interface corresponding to the first activity is a user-perceivable (ie, visual) interface, and sets a visual identifier for the first activity based on the determination result.

[0299] Specifically, if either of the following conditions 1 and 2 are met, the interface corresponding to the first activity can be determined to be a user-perceivable interface. Condition 1: Ensure that the activity's customized layout contains at least one view. Condition 2: Ensure that a background layout exists and its transparency is not 0.

[0300] The visualization flag is used to identify whether the interface corresponding to the activity is visualized, that is, whether it is an interface perceptible to the user. The visualization flag can default to "no" (for example, false). If it is determined that the interface corresponding to the first activity is a user-perceivable interface, the visualization flag is set to "yes" (for example, true, also known as the value of the visualization flag is the first value). If it is determined that the interface corresponding to the first activity is not a user-perceivable interface, the visualization flag is maintained at no.

[0301] The visual indicator can be used as a basis for determining whether to remove the launch window in subsequent processes. Specifically, if the visual indicator is "yes," it indicates that the interface corresponding to the activity is a user-perceivable interface and should be displayed normally, so the launch window should be removed. This will be further explained in the following examples.

[0302] It is understood that step S117 can be executed by a functional module running in the system framework within the process of application A. In other words, the present application can add a module for determining whether an activity is visible to the application layer on the system side without changing the execution logic of application A itself, which facilitates maintenance and improves the security of the application and system.

[0303] S118. During the life cycle of the first activity executed by the process of application A, in the addToDisplay phase of requesting the WMS in the systemserver process to add a display, the visual identifier of the first activity is passed to the WMS along with the parameters. The startup window management module in the WMS saves the visual identifier to the activityRecord corresponding to the first activity.

[0304] Steps S117 and S118 can be simply called visual recognition.

[0305] Optionally, WMS can save the visual identifier to the activityRecord corresponding to the first activity when creating the window state (WindowState).

[0306] The following describes the process of identifying the startup window added by the optimization process.

[0307] Referring to FIG. 11 , in one embodiment, after the systemUI process starts adding a startup window in step S112 , the startup window management module identifies whether the startup window is a startup window added by the optimization process, including:

[0308] S1121: Determine whether the launch window type parameter is NONE (also called the first type) and the currently launched activity is the first activity in the quick launch scenario. If so, determine that the launch window is a launch window added by the optimization process; if not, execute step S1122.

[0309] In the native process, a type parameter is set for the startup window. The type parameter of the startup window represents the type of the added startup window. Optionally, the type of the startup window can be a snapshot type or a splash type. When adding a startup window, set the type parameter to one of the above two types as needed. When the system does not need to add a startup window for a certain activity, the type parameter can be set to NONE. That is to say, when the type parameter of the startup window is NONE, it represents that the native process does not add a startup window to the activity. In this case, if it is further determined that the currently launched activity is the first activity in the quick startup scenario, it means that the current startup window is the startup window added by the optimization process of this application.

[0310] As described in the above embodiment, whether the currently launched activity is the first activity in the quick launch scenario can be determined by whether the cache includes the quick function ID.

[0311] S1122: Determine whether the window addition result is failure to add (also referred to as the first result) and the currently launched activity is the first activity in the quick launch scenario. If so, determine that the launch window is a launch window added by the optimization process; if not, determine that the launch window is not a launch window added by the optimization process.

[0312] The window addition result indicates the result of adding a startup window to a native process. The window addition result can be either a successful addition or a failed addition. A successful addition can be indicated by returning a true value, while a failed addition can be indicated by returning a false value.

[0313] As mentioned above, when the native system adds a launch window to an activity, if the activity has a transparent attribute or the application has configured code to deny the addition of a launch window, the native system fails to add the launch window and returns a "false" value. In this case, if the currently launched activity is further determined to be the first activity in the quick launch scenario, then the current launch window is the launch window added by the optimization process of this application.

[0314] Otherwise, it means that the current startup window is not the startup window added by the optimization process.

[0315] In this embodiment, the type parameter of the startup window and the window adding result can accurately determine whether the startup window is added by the optimization process, thereby improving the accuracy of the optimization process execution and thus improving the stability of the system.

[0316] Continuing to refer to FIG. 11 , in one embodiment, if the judgment result of step S1121 is “yes”, step S1123 is executed.

[0317] S1123. Modify the type parameter of the startup window to the splash type.

[0318] In other words, if the native process doesn't have a launch window, and the launch window is added by the optimized process, the launch window's type parameter is corrected to match the type of the launch window added by the optimized process. This ensures accurate addition of subsequent launch windows. Furthermore, setting the launch window's type parameter to the splash type, compared to the snapshot type, makes the launch window applicable not only to hot starts but also to cold starts, thus expanding the applicability of the optimized process.

[0319] 2. Second stage

[0320] In the second phase, the second and subsequent activities of the application are launched sequentially, and the added launch window is passed to each of these activities. Furthermore, when an activity completes drawing (finishDrawing), a decision is made whether to remove the launch window based on the activity's visual identity. Furthermore, transition properties are managed. These measures ensure stable and smooth display of transition pages, eliminating screen flickering and other issues, further improving the user's visual experience. This is described below with reference to the accompanying figures.

[0321] FIG12 is a timing diagram of another example of an application startup method provided in an embodiment of the present application, and FIG13 is a flow diagram of another example of an application startup method provided in an embodiment of the present application. Please refer to FIG12 and FIG13 together. The method includes:

[0322] S201. During the execution of the first activity life cycle, the process of application A calls the startActivity() function to request the AMS in the systemserver process to start the second activity.

[0323] S202. The AMS in the systemserver process determines in real time whether the condition variable is unlocked and whether the valid time of the condition variable has been exceeded; if the condition variable is not unlocked and the valid time of the condition variable has not been exceeded, step S203 is executed; if the condition variable has not been exceeded and the condition variable is unlocked, or if the condition variable is not unlocked and the valid time of the condition variable has been exceeded, step S204 is executed.

[0324] S203: The AMS in the systemserver process blocks the start of the second activity.

[0325] Blocking the second activity means not processing the start request of the second activity.

[0326] S204 , the AMS in the systemserver process starts processing the start request of the second activity, and the transition component management module in the WMS in the systemserver process collects the activityRecord corresponding to the second activity.

[0327] Steps S202 to S204 may be simply referred to as unlocking of the conditional variable.

[0328] As described in step S105 above, the condition variables may include condition variable 1 and condition variable 2. Determining whether to unlock the condition variables is to determine whether both condition variables are unlocked, that is, to determine whether the transition corresponding to the first activity has been submitted to the systemUI process and the layer display of the startup window is completed.

[0329] Determine whether the valid duration of the condition variable has been exceeded, that is, determine whether the time from the current moment to the moment when the condition variable is set exceeds the valid duration.

[0330] If the time difference between the current moment and the condition variable moment does not exceed the valid duration of the condition variable, and either of the two condition variables is not unlocked, the startup of the second activity is blocked.

[0331] If the time difference between the current moment and the condition variable moment does not exceed the condition variable's validity duration, and both condition variables are unlocked (i.e., they are unlocked within the validity duration), then launching application A's second activity and creating a second transition will not affect the display of the transition page. AMS then begins processing the second activity's launch request. This prevents the second activity and transition from affecting the processing of the transition page, allowing the transition page to display as quickly as possible, thereby minimizing the response time for quick application launches.

[0332] It should be noted that the unlocking order of the two condition variables is not restricted. Condition variable 1 can be unlocked first, or condition variable 2 can be unlocked first, or both condition variables can be unlocked at the same time.

[0333] If the time difference between the current moment and the condition variable moment exceeds the condition variable's validity period, and at least one of the two condition variables is not unlocked, the condition variable is automatically unlocked, and AMS begins processing the second activity's launch request. This prevents the condition variable from being unlocked due to process execution anomalies, which in turn prevents subsequent activities from consistently starting, thereby improving system stability.

[0334] S205. After the AMS starts processing the start request of the second activity, the activity identification module in the WMS identifies the second activity as an other activity in the quick start scenario based on the sourceRecord set, uses the first sourceRecord as the sourceRecord value of the second activity, and adds the sourceRecord to the sourceRecord set; at the same time, sets the value of the source (from) parameter of the second activity to the value of the sourceRecord of the second activity.

[0335] This step can be simply called identifying other activities and setting sourceRecord.

[0336] As described in step S104 above, sourceRecord can be used as a basis for identifying an activity. Therefore, if sourceRecord exists in the sourceRecord set, it means that the activity currently requested to be started is the second activity or an activity after the second activity in the quick start scenario, that is, other activities.

[0337] In this step, when another activity is identified, the sourceRecord value is passed to the other activity, and the from parameter value of the other activity is changed. The from parameter is a parameter in the native system that marks the source of an activity, that is, the value of the from parameter represents the old activity that requested the new activity to be launched. Unlike the sourceRecord in this application, the native system does not have a maintenance mechanism for launching windows across task stacks, so the from parameter is only valid for activities within the same task stack. Specifically, if the new activity and the old activity are in the same task stack, the value of the from parameter is the information of the old activity. If the new activity and the old activity are in different task stacks, the value of the from parameter is NONE, indicating that the activity has no source. In this embodiment, after determining the sourceRecord of another activity, the value of the sourceRecord of the other activity is written into the from parameter of the other activity. In this way, by rewriting the value of the from parameter, the launch window can be accurately transmitted through the from parameter in subsequent processes, preventing the failure of the launch window transmission to cause screen flashing, etc., improving the stability of the launch window display, and enhancing the user's visual experience.

[0338] S206 . The transition component management module in the WMS of the systemserver process creates a second transition according to the collected activityRecord corresponding to the second activity.

[0339] S207 . The transition identification module in the WMS of the systemserver process identifies the second transition as another transition based on the activityRecord in the second transition.

[0340] This step can be simply called identifying other transitions.

[0341] Other transitions refer to the second transition or the transitions after the second one.

[0342] Specifically, in step S203 above, the activity identification module has identified that the activity currently requested to start is another activity. Therefore, the transition component identification module determines whether the activityRecord collected in the current transition is the activityRecord corresponding to the other activity, and further determines whether the current transition is another transition.

[0343] Optionally, if the transition identification module determines that the current transition is other transition, an identifier may be added to the current transition to facilitate subsequent search. The identifier added to the other transition may be, for example, "other".

[0344] S208. The startup window management module in the WMS of the systemserver process obtains the sourceRecord corresponding to the second activity, and passes the startup window to the second activity according to the value of the sourceRecord corresponding to the second activity.

[0345] This step can be simply called starting the window transfer.

[0346] As described in step S104 above, sourceRecord can serve as the basis for window transfer. Specifically, in step S205 above, a value has been set for the sourceRecord corresponding to the second activity and added to the sourceRecord collection. Therefore, in this step, the value of the sourceRecord corresponding to the second activity can be obtained, and based on this value, the old activity (i.e., the source activity) that launched the activity can be determined. Referring to the explanation of step S104 above, in most cases, the activity holding the launch window is the old activity. However, in some cases where the activity holding the launch window is not the source activity, if the passed value is empty, the sourceRecord of the activity holding the launch window in the sourceRecord collection is used as the sourceRecord value of the new activity. Therefore, regardless of the sourceRecord value in the optimization process of this application, the activity corresponding to the sourceRecord value holds the launch window. Therefore, through sourceRecord, the activity currently holding the launch window can be accurately obtained, and the launch window can be accurately transferred to the new activity, improving the accuracy of launch window transfer and the reliability of the optimization process.

[0347] As an optional implementation, after identifying other transitions and before launching the window (i.e., after step S207 and before step S208), step S205 can be performed again to identify other activities and set the sourceRecord corresponding to them. This allows for more accurate identification of other activities, further ensuring the correct assignment of sourceRecord, preventing subsequent launch window delivery failures or activity identification failures, and ensuring the reliability of the optimization process.

[0348] As an optional implementation, when transferring the launch window, you can further determine whether it is a cross-task stack transfer, that is, whether the second activity and the first activity are in the same task stack. If not, the launch window is transferred across the task stack. In this case, the launch window layer can be moved up one level. This prevents the launch window from overlapping the launch window added by the optimization process of this solution if the native system successfully adds the launch window. This prevents the launch window added by the optimization process of this solution from being obscured, preventing the transition page effect from being affected, and improving the user experience.

[0349] S209. The process of application A continues to execute the life cycle of the first activity. After the frame of the first activity is drawn, the finishDrawing() function is used to indicate to the WMS that the interface drawing is complete. In response to the instruction, the startup window management module in the WMS obtains the visual identifier of the first activity from the activityRecord of the first activity and obtains the optimized window identifier from the cache.

[0350] As described in steps S117 and S118 above, during the activityStart phase of the first activity, a visual identifier is set for the activity, and the visual identifier is passed and saved to the activityRecord of the first activity. Therefore, this step can obtain the visual identifier of the first activity.

[0351] As described in steps S112 and S113 above, the startup window management module recognizes that the startup window is a startup window added through the optimization process, and then adds an optimized window identifier to the startup window. Therefore, if the startup window is the startup window passed by the first activity, the optimized window identifier can be obtained.

[0352] S210, the startup window management module determines whether the delayed removal condition is met based on the visual identifier of the first activity and the acquisition result of the optimized window identifier; if the delayed removal condition is met, execute step S211; if the delayed removal condition is not met, execute step S212.

[0353] S211 : The startup window management module delays removing the startup window.

[0354] S212: The startup window management module removes the startup window and clears all identification information added through the optimization process.

[0355] Steps S209 to S212 may be simply referred to as removing the activation window.

[0356] The conditions for delayed removal can include at least: the first activity's visual indicator is "No" and the presence of an optimization window indicator. In other words, if the first activity's corresponding interface is not visible to the user and the current launch window is a launch window added by the optimization process, indicating that the first activity's interface does not need to be displayed, the launch window can be delayed for removal.

[0357] In another embodiment, the delayed removal condition may further include at least one of the following: the launch window held by the activity has not been delayed removed before, and the current delayed removal count threshold is greater than 0. Setting "the launch window held by the activity has not been delayed removed before" in the delayed removal condition can prevent the launch window of the same activity from being delayed removed multiple times, thereby preventing the process from being stuck at the same activity and causing startup lag, thereby improving the user experience.

[0358] As described in the above embodiment, when the electronic device is powered on, the configuration can be parsed to obtain the delay removal times threshold value, and cached in the cache configuration module. It can be understood that within a quick startup cycle, each time the WMS delays the removal of the startup window, the cache configuration module will reduce the delay removal times threshold value by 1 until the delay removal times threshold value is 0. When the startup window management module needs to determine whether the delay removal conditions are met, it can obtain the latest delay removal times threshold value from the cache configuration module. "Delay removal times threshold value is greater than 0" is set in the delay removal conditions, that is, when the delay removal times is 0, the removal cannot be delayed any further. This can prevent the startup window from being removed indefinitely, prevent the transition page from being displayed on the screen for a long time, cause startup jams, and improve the user experience.

[0359] It is understood that in some embodiments, the delayed removal condition may further include: determining that sourceRecord exists in the sourceRecord collection and determining that a startup window currently exists. Determining that sourceRecord exists in the sourceRecord collection also determines that the current scenario is a quick launch scenario and that the current startup process is an optimized process. By determining that sourceRecord exists in the sourceRecord collection and determining that a startup window currently exists, the determination of the delayed removal window is further enhanced, improving system reliability and further improving the user experience.

[0360] Optionally, when the delayed removal condition is met, the window management module can obtain the delayed removal time of the startup window from the configuration cache module, and can delay the removal of the startup window by delaying the removal and recalling the delayRemoveCallback() function. The Callback time is the time from the current moment to the moment when the delayed removal time of the startup window is reached. Taking the delayed removal time of the startup window as 500ms as an example, after 500ms, the process of removing the startup window is restarted. However, within these 500ms, through the execution of subsequent steps in the optimization process, the startup window may have been passed to the subsequent activity (see step S208). Therefore, the startup window removal in the Callback process fails, which ensures the normal execution of the subsequent process and further ensures the normal display of the transition page. If the startup window is not passed out after 500ms, the startup window is removed to prevent the transition page from being displayed on the screen for a long time, causing startup jams, and improving the user experience.

[0361] Based on this, as a possible implementation, in step S208, after the startup window is successfully delivered, if there is a callback for removing the delayed startup window, the callback is canceled. This eliminates the need to return to remove the startup window, saving process and reducing power consumption.

[0362] If the conditions for delayed removal are not met (that is, the current launch window visibility flag is "yes," the optimized window flag does not exist, the launch window held by the activity has been delayed before, or the current delayed removal threshold is 0), the launch window is removed normally. This allows the application interface to display normally and respond to user operations normally, ensuring normal switching between the launch window and the application window.

[0363] After removing the launch window, all identification information added by the optimization process is cleared, including but not limited to the shortcut function ID, sourceRecord collection, conditional variables, the effective duration of the conditional variables, the optimization window identifier, the identifiers of each activity, and the identifiers of each transition. After removing the launch window, the system will continue to run according to the application's process or native process. Clearing the identification information added by the optimization process can prevent process disruptions during subsequent operations and improve system stability and reliability. In addition, clearing the identification information added by the optimization process can also prevent errors the next time you quickly launch the same function in the application, improving system reliability.

[0364] S213. After determining that the life cycle of the first activity is completed, the AMS in the systemserver process calls the activityPaused() function to notify the process of application A to pause the first activity and instruct the process of application A to execute the life cycle of the second activity.

[0365] S214: The AMS in the systemserver process instructs the process of application A to pause the first activity and begin the lifecycle of the second activity. During the lifecycle of the second activity, during the activityResume phase, the process of application A determines whether the interface corresponding to the second activity is user-perceivable and sets the visual identifier of the second activity based on the determination result.

[0366] S215. During the life cycle of the second activity executed by the process of application A, in the addToDisplay phase of requesting WMS in the systemserver process, the visual identifier of the second activity is passed to the WMS along with the parameters. The startup window management module in the WMS saves the visual identifier to the activityRecord corresponding to the second activity.

[0367] Steps S214 and S215 can be simply called visual recognition.

[0368] The specific execution of steps S214 and S215 is similar to the above steps S117 and S118 and will not be repeated here.

[0369] S216. The WMS in the systemserver process responds to the request of the systemUI process and calls the addToDisplay() function to start the window adding display. After the window adding display is completed, the apply ready (applyReady) is triggered. The transition component management module in the WMS prepares the second transition. After the second transition is prepared and before the second transition is submitted to the systemUI process, the transition component management module in the WMS of the systemserver process sets the animation attribute of the second transition to "no" (that is, cancels the animation attribute).

[0370] It's understandable that during the second and subsequent activity startups, the app process requests the system server process to pause the activity (activityPause), triggering the WMS to enter the applyReady phase, after which WMS prepares for the transition. In other words, activityPause triggers onTransactionReady.

[0371] S217. The transition component management module in the WMS submits the second transition with the animation attribute of "No" to the systemUI process for processing. After the systemUI process is processed, it submits the second transition with the animation attribute of "No" to the launcher process, notifying the launcher process to execute the second transition. The launcher process executes the second transition to continue displaying the transition page.

[0372] The above steps S216 and S217 can be simply referred to as the control of other motion effects.

[0373] It can be understood that each transition after the second transition sets the animation attribute to "No" before being submitted to the systemUI process. In other words, the first transition has the animation attribute, and the transitions after the first one do not have the animation attribute, and the first transition can be an animation of icon enlargement. In this way, the display effect presented on the screen is: the icon gradually enlarges, and then the interface after the icon is enlarged is maintained. The following will be explained in conjunction with the accompanying drawings. In this way, it is possible to prevent screen flashing caused by frequent switching of animations when starting activities across task stacks, thereby improving the display effect. In addition, only the first transition is an animation, and the animation execution time is short. There will be no situation where the animation execution time is too long, resulting in the application's activity having been loaded but the animation has not yet been executed. Therefore, it can prevent the phenomenon that the interface cannot respond to user operations, thereby improving the user experience.

[0374] Steps S201 to S217 above describe the process associated with launching the second activity. It's understood that each subsequent activity will follow these steps. This allows the second and subsequent activities to sequentially pass the launch window and display a static image until an activity fails to meet the deferred removal criteria, or until the last activity of application A has finished loading. At this point, the launch window is removed, and target screen a is displayed.

[0375] It should be noted that, in the above embodiment, the optimization process is described by taking a cold start as an example, but the optimization process provided in this application is applicable to cold start, warm start, and hot start.

[0376] The interface change process of the first and second stages mentioned above will be described below with reference to the accompanying drawings.

[0377] For example, FIG14 is a schematic diagram of an interface change provided by an embodiment of the present application. Continuing with the quick start of the payment function of the payment application as an example, as shown in FIG14 (a), in response to the user clicking the shortcut icon of the payment function on the desktop, the electronic device creates a payment application process and then starts the first activity of the payment application. In the process of starting the first activity, the electronic device adds a startup window and draws the startup window, preparing to display the transition page. Taking the first transition with a motion effect attribute, and the motion effect is icon enlargement as an example, after the startup window is drawn, the motion effect is executed, and the screen presents the effect of icon enlargement, as shown in FIG14 (b). Afterwards, the icon continues to enlarge, as shown in FIG14 (c), until the motion effect is played. The second transition and subsequent transitions cancel the motion effect attribute, so it does not affect the motion effect playback of the icon enlargement, and after the motion effect is played, if the activity has not been loaded, a static picture, such as a blank picture, is displayed in the transition page, as shown in FIG14 (d). After that, when the content that the payment application needs to display is ready, the startup window is removed and the payment application interface, such as the payment application logo page, is displayed, as shown in Figure 14 (e). Then, the interface jumps to the payment code interface, as shown in Figure 14 (f).

[0378] As can be seen from Figure 14, by optimizing the process, the preset functions of the application can be quickly started, and the transition page during the startup process can be displayed smoothly and stably without problems such as screen flashing, effectively improving the user's visual experience.

[0379] The response time of the optimization process is further explained below.

[0380] For example, Figures 15 and 16 are schematic diagrams comparing interfaces of quick application launches based on optimized processes and native processes provided in an embodiment of the present application, with Figure 16 (a) continuing from Figure 15 (b). In each group of figures in Figures 15 and 16, the left figure is the interface of an electronic device running an optimized process, and the right figure is the interface of an electronic device running a native process. As shown in Figure 15 (a), at the same time T1, the payment application is launched simultaneously through shortcuts via the optimized process and the native process. As shown in Figure 15 (b), at time T2, a transition page is displayed in the interface of the device running the optimized process, showing the effect of icons gradually being released, while the device running the native process is unresponsive. As shown in Figure 16 (a), at time T3, the device running the optimized process has removed the startup window and displayed the Logo page of the payment application, while the device running the native process is still unresponsive. As shown in Figure 16 (b), at time T4, the interface of the device running the optimized process has displayed the interface of the payment function, while the device running the native process begins to include a logo page displaying the payment application.

[0381] It is clear from Figures 15 and 16 that the optimized process significantly reduces response time. Furthermore, in the native process, there is no animation during the startup process, resulting in a poor visual effect.

[0382] In addition, experimental test data also shows that the various quick start response times of various applications under the optimization process of this application are greatly reduced. For example: launching Alipay through shortcuts When using the payment function, the response time is shortened to 84ms; start Alipay through the shortcut When using the scan function, the response time is shortened to 80ms; start WeChat through the shortcut When using the payment function, the response time is shortened to 90ms; start WeChat through the shortcut When the scan function is used, the response time is shortened to 80ms. It can be seen that the optimization process of this application can shorten the response time by up to 537ms compared with the related art.

[0383] In addition, from the description of the first and second stages above, it can be seen that the application startup method provided in this application improves the native process on the system side, without changing the original startup logic of the application, which facilitates the maintenance of the optimized process and has high security.

[0384] Next, the update of the function blacklist is explained.

[0385] Optionally, during the optimization process, if the following conditions occur, the currently enabled function can be added to the function blacklist:

[0386] If the old activity is paused before the new activity is requested to start, delay transaction readiness (onTransactionReady); where the old activity is the second activity or an activity after the second activity.

[0387] As described in the above embodiment, while an activity (i.e., the old activity) is running, if another activity (i.e., a new activity) needs to be started after the old activity, a request to start the new activity can be made to the system server process during the old activity's start (activityStart) phase. The system server process then processes the start request, pauses the old activity after the old activity's lifecycle completes, and starts the new activity. As can be seen, the request to start the new activity occurs before the old activity is paused.

[0388] As shown in Figure 17, in practice, for the second and subsequent activities, the application process may execute the FinishActivity action on the old activity. After completing the FinishActivity action, the old activity is paused. Subsequently, a request to start a new activity may be made, resulting in the new activity being started after the old activity is paused. In this case, while the old activity is paused, the system server process has not yet been requested to start the new activity, and thus the launch window transfer operation is not triggered. Therefore, the launch window is still held by the old activity.

[0389] After an activity is paused, a transaction may be ready (onTransactionReady). If the launch window is still held by the old activity when the old activity is paused, the launch window will be hidden when the old activity is paused. The launch window will be displayed again after it is transferred to the new activity, causing screen flickering and affecting the user experience.

[0390] In view of this, the optimization process provided by the embodiment of the present application, on the one hand, for this scenario, delays the transaction readiness (onTransactionReady) of the transition corresponding to the old activity, that is, delays the transition readiness transitionReady, waits for the old activity to request the systemserver process to start the new activity, and passes the startup window, and then executes the transaction readiness (onTransactionReady). In this way, the startup window can be passed to the next activity while always being displayed, preventing screen flashing and improving user experience. On the other hand, the shortcut function ID of such scenarios is added to the function blacklist. In this way, the function of the application will not be allowed to be executed according to the optimization process during the next quick startup, further preventing screen flashing and improving system reliability.

[0391] The following is a further summary and explanation of the application startup method provided in the embodiments of the present application.

[0392] The application startup method provided in an embodiment of the present application, when determining that the current scenario is suitable for quick startup through an optimized process, firstly, adds a startup window during the launch of the first activity to display a transition page, thereby shortening response time. Secondly, when launching the second and subsequent activities, the startup window is passed to ensure that the transition page is continuously displayed. Thirdly, when determining that the application interface needs to be displayed, the startup window is removed to ensure normal display of the application interface.

[0393] Then, when implementing the above three solutions, it is necessary to identify the activity in the quick start scenario and determine whether the activity is the first activity or the second and subsequent activities (i.e., other activities). In the embodiment of the present application, on the one hand, by setting a first identifier (for example, a quick function ID), the quick start scenario and the first activity are marked, so that the first activity in the quick start scenario can be accurately and quickly identified, and the startup window can be accurately added. On the other hand, by setting sourceRecord, the source activity of the startup activity is marked, so that other activities in the quick start scenario can be accurately and quickly identified, and the startup window can be accurately transferred. On the other hand, by assigning a value to the visual identifier of each activity, whether the interface corresponding to the activity is visible is marked, so that it can be accurately determined whether the application interface needs to be displayed, and whether the startup window needs to be removed. Moreover, by adding a second identifier (for example, an optimization window identifier) ​​to the startup window added by the optimization process, the startup window added by the optimization process is marked, so that it can be accurately removed when the startup window is removed, preventing the startup window added by the native process from being removed, improving the accuracy of the process operation, and thus improving the stability of the system operation.

[0394] In addition, the optimization process also identifies the first transition, as well as the second and subsequent transitions (i.e., other transitions). On the one hand, the transparency attribute of the first transition is canceled, so that the icon magnification effect can be executed, improving the effect. On the other hand, the transparency attribute of other transitions is canceled, so that the screen flashing caused by frequent switching of effects can be prevented, thereby improving the display effect. Moreover, the execution time of the effect is shortened, and the situation where the application activity has been loaded but the effect has not been executed due to the long execution time of the effect will not occur. Therefore, it can prevent the application interface from being unable to respond to user operations and improve the user experience.

[0395] In addition, the optimization process limits the startup timing of the second activity by setting conditional variables to prevent affecting the loading of the first transition and the display of the transition page.

[0396] In summary, the application startup method provided in the embodiment of the present application can not only shorten the response time when the application is quickly started, but also make the transition page display smoothly and steadily, thereby improving the user experience.

[0397] The above describes in detail an example of an application startup method provided by an embodiment of the present application. It is understandable that, in order to implement the above functions, the electronic device includes hardware and / or software modules corresponding to the execution of each function. Those skilled in the art should easily appreciate that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software driven hardware manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered to be beyond the scope of this application.

[0398] The embodiment of the present application can divide the functional modules of the electronic device according to the above method example. For example, each function can be divided into various functional modules, such as a detection unit, a processing unit, a display unit, etc., or two or more functions can be integrated into one module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of a software functional module. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0399] It should be noted that all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0400] The electronic device provided in this embodiment is used to execute the above-mentioned application startup method, and thus can achieve the same effect as the above-mentioned implementation method.

[0401] When integrated, the electronic device may also include a processing module, a storage module, and a communication module. The processing module may be used to control and manage the operation of the electronic device. The storage module may be used to support the execution of program code and data stored in the electronic device. The communication module may be used to support communication between the electronic device and other devices.

[0402] The processing module may be a processor or a controller. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, and so on. The storage module may be a memory. The communication module may specifically be a device that interacts with other electronic devices, such as a radio frequency circuit, a Bluetooth chip, or a Wi-Fi chip.

[0403] In one embodiment, when the processing module is a processor and the storage module is a memory, the electronic device involved in this embodiment may be a device having the structure shown in FIG. 3 .

[0404] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the processor executes the application startup method of any of the above embodiments.

[0405] An embodiment of the present application further provides a computer program product. When the computer program product is run on a computer, the computer is caused to execute the above-mentioned related steps to implement the application startup method in the above-mentioned embodiment.

[0406] In addition, an embodiment of the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer execution instructions, and when the device is running, the processor can execute the computer execution instructions stored in the memory to enable the chip to execute the application startup method in the above-mentioned method embodiments.

[0407] Among them, the electronic device, computer-readable storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0408] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0409] 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 merely schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0410] Units described as separate components may or may not be physically separate, and components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0411] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0412] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0413] The above content is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A method for starting an application, characterized in that Applied to an electronic device, the electronic device includes a system service process, a system interface process, and a desktop process. The method includes: In response to a first operation of the user, the desktop process sends a start message to the system service process. The start message is used to indicate starting a first function of a first application through a shortcut. The interface corresponding to the first function is the interface displayed after the first application loads n activities in sequence, where n is an integer greater than 1; In response to the start message, the system service process starts the first activity among the n activities and creates a first transition component. During the process of starting the first activity, the system interface process adds and draws a first start window for the first activity; In response to the first transition component being ready, the system interface process notifies the desktop process to execute the first transition component; In response to the notification of the system interface process, the desktop process executes the first transition component.

2. The method according to claim 1, characterized in that, The moment when the first transition component is ready is between a first moment and a second moment. The first moment is the moment when the first start window is added, and the second moment is the moment when the drawing of the first start window is completed.

3. The method according to claim 2, characterized in that, The system interface process adding and drawing a first start window for the first activity includes: The system interface process calls the addStartingWindow() function to add the first start window; The system interface process calls the doFrame() function to draw the frame of the first start window; After the frame of the first start window is drawn, the system interface process requests the system service process to add the display of the first start window; The system service process calls the addToDisplay() function to add the display of the first start window; After the display of the first start window is added, the system service process triggers the readiness of the first transition component.

4. The method according to any one of claims 1 to 3, characterized in that, The start message carries information of the first application. Before the system service process starts the first activity among the n activities, the method further includes: If it is determined that the start message carries a first piece of information, the system service process determines whether the first application meets a preset condition according to the information of the first application. The first piece of information is used to indicate starting the first function through a shortcut; If it is determined that the first application meets the preset condition, the system service process sets a first identifier, and the first identifier is used to indicate that the current scenario is a quick start scenario and the currently started activity is the first activity of the application.

5. The method according to claim 4, characterized in that, The preset condition includes one or more of the following: The type of the first application is in a preset application whitelist; The package of the first application is not in a preset package blacklist; The first piece of information is not in a function blacklist.

6. The method according to claim 4 or 5, characterized in that, The first identifier is the first piece of information.

7. The method according to any one of claims 4 to 6, characterized in that Before the system interface process adds and draws a first start window for the first activity, the method further includes: The system service process determines the existence of the first identifier.

8. The method according to claim 7, wherein The method further includes: After the system interface process starts adding the first startup window for the first activity, the system service process determines whether the type parameter of the first startup window is of the first type and determines whether the first identifier exists, where the first type represents that no startup window is added; If the type parameter of the first startup window is of the first type and the first identifier exists, the system service process sets a second identifier for the first startup window; If the type parameter of the first startup window is not of the first type and the first identifier exists, the system service process determines whether a first result exists, where the first result represents that adding the startup window fails; If the first result exists, the system service process sets the second identifier; If the first result does not exist, the system service process clears the first identifier.

9. The method according to claim 8, wherein The method further includes: If the type parameter of the first startup window is of the first type and the first identifier exists, modify the type parameter of the first startup window to the splash type.

10. The method according to claim 8 or 9, characterized in that The method further includes: During the process of starting the first activity, if it is determined that the first identifier exists, the system service process creates a first source record corresponding to the first activity, takes the activity record of the first activity as the value of the first source record, and adds the first source record to the source record set.

11. The method according to claim 10, characterized in that, The electronic device further includes the process of the first application, and the method further includes: During the process of executing the life cycle of the first activity, the process of the first application determines whether the interface corresponding to the first activity is a visual interface; If the interface corresponding to the first activity is a visual interface, the system service process sets the value of the visual identifier of the first activity to a first value.

12. The method according to claim 11, wherein The method further includes: During the activity layout stage of the first activity, if it is determined that the custom interface includes views, or if it is determined that there is a background layout and the transparency is not 0, the process of the first application determines that the interface corresponding to the first activity is a visual interface.

13. The method according to claim 11 or 12, characterized in that, The method further includes: After receiving a first completion indication from the process of the first application, the system service process determines whether a delay removal condition is met, where the first completion indication is used to indicate that the first activity has completed drawing; If the delay removal condition is met, the system service process delays removing the first startup window; If the delay removal condition is not met, the system service process removes the first startup window.

14. The method according to claim 13, characterized in that The delay removal condition includes: the value of the visual identifier of the first activity is not the first value, and the second identifier exists.

15. The method according to claim 14, characterized in that, The delay removal condition further includes one or more of the following: The startup window held by the first activity has not been removed before; The current delay removal count threshold is greater than 0; There is a source record in the source record set.

16. The method according to any one of claims 13 to 15, characterized in that, After removing the first startup window, the method further includes: Clearing the first identifier, the second identifier, the source record set, and the first value.

17. The method according to any one of claims 1 to 16, characterized in that The first transition component has an animation attribute.

18. The method according to claim 17, wherein The animation effect corresponding to the first transition component is an icon magnification animation effect, and the method further includes: Before submitting the first transition component to the system interface process, when it is determined that the first transition component is the transition component corresponding to the first activity, the system service process cancels the transparency attribute of the first transition component.

19. The method according to claim 18, characterized in that The method further includes: During the process of starting the first activity, the system service process determines that the first transition component is the transition component corresponding to the first activity according to the activity record corresponding to the first activity collected in the first transition component.

20. The method according to any one of claims 1 to 19, characterized in that The electronic device further includes the process of the first application, and the method further includes: In response to the system service process starting the first activity, the process of the first application executes the life cycle of the first activity; During the process of executing the life cycle of the first activity, the process of the first application requests the system service process to start the second activity among the n activities; In response to the request of the first application process, the system service process starts the second activity and creates a second transition component; During the process of starting the second activity, the system service process transfers the first startup window to the second activity.

21. The method according to claim 20, wherein The startup moment of the second activity is after the moment when the first transition component is ready.

22. The method according to claim 21, wherein The startup moment of the second activity is after the completion moment of the layer display of the first startup window.

23. The method according to claim 22, wherein The method further includes: During the process of starting the first activity, the system service process sets a condition variable, and the condition variable includes: the first transition component has been submitted to the system interface process, and the layer display of the first startup window has been completed; The system service process starting the second activity includes: When it is determined that the condition variable has been unlocked, the system service process starts the second activity.

24. The method according to claim 23, wherein The method further includes: The system service process sets an effective duration during the process of starting the first activity; If the condition variable is satisfied within the effective duration starting from the moment when the condition variable is set, the system service process determines that the condition variable has been unlocked; If the condition variable is still not satisfied after the effective duration starting from the moment when the condition variable is set, then the system service process unlocks the condition variable.

25. The method according to any one of claims 20 to 24, characterized in that Before the system service process transfers the first startup window to the second activity, the method further includes: During the process of starting the second activity, when it is determined that there is a source record in the source record set, the system service process sets the second source record corresponding to the second activity and assigns a value to the second source record; the source record is used to represent the previous activity that starts the third activity, and the third activity is any one of the n activities; Add the second source record to the source record set.

26. The method according to claim 25, wherein The assigning a value to the second source record includes: The system service process transfers the value of the first source record to the second source record, and the first source record is the source record corresponding to the first activity; If the passed value is empty, the system service process uses the activity record of the fourth activity as the value of the second source record, where the fourth activity is the activity currently holding the first startup window.

27. The method according to claim 25 or 26, characterized in that, The system service process passing the first startup window to the second activity includes: Obtaining the second source record from the set of source records; According to the value of the second source record, passing the first startup window from the first activity to the second activity.

28. The method according to any one of claims 20 to 27, characterized in that, The method further includes: Before submitting the second transition component to the system interface process, when it is determined that the second transition component is another transition component, the system service process cancels the animation attribute of the second transition component, where the other transition component refers to an activity other than the first activity among the n activities.

29. The method according to claim 28, wherein The method further includes: During the process of starting the second activity, the system service process determines that the second transition component is the other transition component according to the activity record corresponding to the second activity collected in the second transition component.

30. The method according to any one of claims 20 to 29, characterized in that, After the system service process passes the first startup window to the second activity, the method further includes: During the process of starting the second activity, if the first activity and the second activity do not belong to the same task stack, the system service process increases the layer level of the first startup window by one layer.

31. The method according to any one of claims 20 to 30, characterized in that, The method further includes: During the process of executing the life cycle of the second activity, the process of the first application determines whether the interface corresponding to the second activity is a visual interface; If the interface corresponding to the second activity is a visual interface, the system service process sets the value of the visual identifier of the second activity to the first value.

32. The method according to any one of claims 20 to 31, characterized in that, The method further includes: After receiving the second completion indication, which is used to indicate that the second activity has completed drawing, the system service process determines whether the delayed removal condition is met; If the delayed removal condition is met, the system service process delays removing the first startup window; If the delayed removal condition is not met, the system service process removes the first startup window.

33. An electronic device, characterized in that, Including: A processor, a memory, and an interface; The processor, the memory, and the interface cooperate with each other to enable the electronic device to execute the method according to any one of claims 1 to 32.

34. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, and when the computer program is executed by the processor, the processor executes the method according to any one of claims 1 to 32.

Images