Application starting method, electronic device, and storage medium

Abstract

The present application provides an application starting method, an electronic device, and a storage medium. The method comprises: determining a plurality of first groups of tasks, wherein a connection point is configured for a first target group of tasks among the plurality of first groups of tasks, a second group of tasks are connected to the first target group of tasks by means of the connection point, the first groups of tasks and the second group of tasks are used for starting a first application, the first groups of tasks are system layer starting tasks of the first application, and the second group of tasks are application layer starting tasks of the first application; executing the plurality of first groups of tasks, wherein when the first target group of tasks to which the second group of tasks are connected are executed, the second group of tasks connected to the first target group of tasks are executed; and displaying an application interface of the first application. The present application can enhance the concurrent execution capability of tasks in an application starting process, thereby effectively improving the starting efficiency and performance of an application.

Description

An application startup method, an electronic device, and a storage medium

[0001] This application claims priority to Chinese Patent Application No. 202411826424.3, filed on December 11, 2024, entitled "An application startup method, electronic device and storage medium", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of terminal technology, and in particular to an application startup method, electronic device, and storage medium. Background Technology

[0003] During application startup, a series of initialization tasks typically need to be executed. If these startup tasks are placed in the onCreate lifecycle method of the application or Ability, they need to be executed sequentially on the main thread. The tasks in the current application startup process cannot be executed concurrently, thus affecting the application's startup efficiency and performance. Summary of the Invention

[0004] This application provides an application startup method, an electronic device, and a storage medium, which can enhance the concurrent execution capability between tasks during application startup and effectively improve application startup efficiency and performance.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] In a first aspect, this application provides an application startup method, the method comprising: determining a plurality of first task groups, wherein a first target task group among the plurality of first task groups is configured with an access point, and connecting a second task group to the first target task group through the access point; the first task group and the second task group are used to start a first application, wherein the first task group is a system-level startup task corresponding to the first application, and the second task group is an application-level startup task corresponding to the first application; executing the plurality of first task groups, wherein when executing a first target task group connected to the second task group, the second task group connected to the first target task group is executed; and displaying the application interface of the first application.

[0007] The application startup method provided in this application adopts a framework-based management strategy, incorporating system-level startup tasks (first task group) and application-level startup tasks (second task group) into a unified startup framework for management. Within this framework, each first target task group in multiple first task groups is configured with an access point to establish a connection channel between system-level and application-level startup tasks. This allows second task groups to select one access point to connect to the first target task group based on actual needs. This not only meets the requirements for concurrent execution and staggered operation between task groups, but also automatically triggers and executes the second task group when the startup process of the first application reaches the first target task group during the execution of the first task group, without additional monitoring or intervention. This automatic triggering mechanism simplifies the complexity of task execution, improves the flexibility and response speed of the application startup process, and provides strong support for the rapid and stable startup of applications.

[0008] Furthermore, during application development, this framework-based management approach, combined with access point configuration, ensures that tasks at both the system and application layers are managed according to a unified process, reducing execution chaos caused by differences between developers or teams. Simultaneously, the task group division enables modular application development, allowing each task group to be developed, tested, and maintained independently. This means that when adding new features or modifying existing ones, developers only need to focus on the relevant task group, eliminating the need for global modifications, thereby improving development efficiency and code maintainability.

[0009] The first application can be any application displayed on the desktop of an electronic device; it can also be an application based on a web kernel or an application embedded in other applications (such as a mini-program).

[0010] It should be understood that the startup process of the first application can be triggered by a triggering operation on the first application in the electronic device. The triggering operation can be used to trigger any control, application icon or service so that the electronic device can start the first application in response to the triggering operation.

[0011] In practical design, the specific operation that triggers any control, application icon, or service can be a click, touch, single click, double click, two-finger swipe, or long press on any control or application icon for a preset duration. It can also be one or more of the following operations: key input, gesture recognition, body language recognition, voice recognition, facial expression recognition, eye movement recognition, and face recognition. This application does not impose specific limitations on this.

[0012] For example, during the startup process of the first application, a first task group and a second task group can be obtained from the configuration file corresponding to the first application. The first task group and the second task group can be predefined during the development of the first application.

[0013] Optionally, each task group corresponds one-to-one with a configuration file. The access point for the first target task group is set in the header of the configuration file for that first target task group.

[0014] In one possible implementation of the first aspect, a first application is launched by executing multiple first task groups and second task groups in parallel by a main thread and at least one child thread, wherein the first task group is a task group executed by the main thread or a task group executed by one of the child threads.

[0015] The above solution employs a framework-based management strategy to uniformly manage the system-level and application-level startup tasks of the first application. This allows for concurrent execution of the main thread and child threads throughout the entire startup process, accelerating the application startup process and providing greater flexibility and fault tolerance. Furthermore, it allows for flexible allocation of the first task group to the main thread or a specific child thread based on actual needs, further enhancing the flexibility and efficiency of the system-level startup task execution.

[0016] In one possible implementation of the first aspect, the priority of the first target task group is determined by the priority of the second target task group, which is a task group that depends on the second task group during the startup of the first application, and the priority is used to characterize the execution order of each task group.

[0017] In the above scheme, the priority of the second target task group of the second task group is used to determine the first target task group that the second task group should connect to, so as to enable each task group to perform in an orderly manner according to logic and dependency relationship, reduce conflicts and waiting between tasks, and thus improve the overall task execution efficiency.

[0018] In one possible implementation of the first aspect, the first target task group accessed by the second task group has a higher priority than the second target task group.

[0019] In the above scheme, the first target task group that the second task group connects to has a higher priority than the second target task group, so as to ensure that the second task group can execute before the second target task group, reduce the impact of the second task group's execution on the second target task group, and improve the overall task execution efficiency.

[0020] In one possible implementation of the first aspect, the method further includes: executing the second target task group after the first target task group has been completed, based on the dependency relationship between the first target task group and the second target task group.

[0021] In the above scheme, by prioritizing the execution of the first target task group, it can be ensured that the second task group can be executed before the second target task group, thus avoiding the impact of the execution of the second task group on the second target task group and improving the overall task execution efficiency.

[0022] In one possible implementation of the first aspect, the first task group includes one or more first sub-tasks, the second task group includes one or more second sub-tasks, and the first task group, the first sub-task, the second task group, and the second sub-task each have a task identifier.

[0023] In the above scheme, the task identifiers of task groups and subtasks can ensure the uniqueness and traceability of task groups and subtasks in the task initiation process, which facilitates subsequent searching, monitoring and debugging, and avoids the repeated execution of tasks.

[0024] Optionally, the second subtask can be either a task executed by the main thread or a task executed by one of the subthreads.

[0025] In one possible implementation of the first aspect, the method further includes: obtaining the task identifier of the second task group; determining the execution status of the second task group based on the task identifier of the second task group; and executing the first target task group when the execution status of the second task group is completed.

[0026] In the above scheme, the task identifier serves as a unique identifier for the task group, acting as an index or keyword to quickly and accurately confirm the execution status of the task group, enabling timely understanding of task progress. This not only identifies and avoids duplicate task execution, promoting resource sharing in the startup process, but also prevents the execution of the first target task group before the dependent task group (i.e., the second task group) has been completed, thus avoiding task failure.

[0027] In one possible implementation of the first aspect, the method further includes: updating the execution status of the first task group and / or the first subtask based on the task execution status of the first subtask in the first task group; and updating the execution status of the second task group and / or the second subtask based on the task execution status of the second subtask in the second task group.

[0028] In the above scheme, the execution status of the task group and / or the subtask in the task group is dynamically updated based on the task execution status of the subtask in the task group, so as to record the task progress of the task group and the subtask in a timely manner, thereby promoting resource sharing and efficiency improvement in the startup process.

[0029] In one possible implementation of the first aspect, executing a second task group accessed from a first target task group includes: obtaining a task identifier of the second task group recorded at the access point of the first target task group; obtaining a configuration file of the second task group based on the task identifier of the second task group; and executing the second task group based on the configuration file of the second task group.

[0030] In the above scheme, only the task identifier of the second task group needs to be recorded in the access point of the first target task group. This identifier allows access to the configuration file of the second task group. This not only simplifies the structure and implementation of the access point but also reduces the coupling between the first target task group and the second task group, improving the system's flexibility and maintainability.

[0031] Secondly, this application provides an electronic device configured to perform the method in any possible implementation of the first aspect.

[0032] Optionally, the electronic device may include: a processor configured to: determine a plurality of first task groups, wherein a first target task group among the plurality of first task groups is configured with an access point, and to connect a second task group to the first target task group through the access point; the first task group and the second task group are used to launch a first application, wherein the first task group is a system-level launch task corresponding to the first application, and the second task group is an application-level launch task corresponding to the first application; execute the plurality of first task groups, wherein when executing a first target task group that has a second task group connected, the second task group connected to the first target task group is executed; and display the application interface of the first application.

[0033] Thirdly, this application provides a chip system including a processor that executes a computer program stored in a memory to implement the method in any possible implementation of the first aspect.

[0034] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method in any possible implementation of the first aspect.

[0035] Fifthly, this application provides a computer program product including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method in any possible implementation of the first aspect.

[0036] The technical effects of the second to fifth aspects provided in this application can be found in the technical effects of the various possible implementations of the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0037] Figure 1 is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0038] Figure 2 is a schematic diagram of the software structure of an electronic device provided in an embodiment of this application;

[0039] Figure 3 is a flowchart illustrating an application startup process provided in an embodiment of this application;

[0040] Figure 4 is a schematic diagram of the tracking record results corresponding to a system-level startup task provided in an embodiment of this application;

[0041] Figure 5 is a class diagram of a unified modeling language for an application startup task provided in an embodiment of this application;

[0042] Figure 6 is a schematic diagram of the parallel and serial execution of system tasks at the system layer provided in an embodiment of this application;

[0043] Figure 7 is a schematic diagram of a process for the main thread to execute system tasks at the system layer, provided in an embodiment of this application.

[0044] Figure 8 is a flowchart illustrating an application startup method provided in an embodiment of this application;

[0045] Figure 9 is a schematic logic diagram of an access point provided in an embodiment of this application;

[0046] Figure 10 is a schematic logic diagram of another access point provided in an embodiment of this application;

[0047] Figure 11 is an execution logic diagram of a task group provided in an embodiment of this application;

[0048] Figure 12 is a schematic interactive diagram of an application launch method provided in an embodiment of this application. Detailed Implementation

[0049] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings and related embodiments. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. As used in the specification and appended claims of this application, the singular expressions "a," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one" and "one or more" refer to one or more (including two). The term "and / or" is used to describe the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0050] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of 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 "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0051] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0052] The application launch method provided in this application can be applied to electronic devices. For example, electronic devices may include, but are not limited to, personal computers (PCs), smartphones, netbooks, tablets, smart cameras, wearable devices, handheld computers, smart TVs, personal digital assistants (PDAs), portable multimedia players (PMPs), projection devices, smart screen devices, augmented reality (AR) / virtual reality (VR) devices, mixed reality (MR) devices, in-vehicle devices, smart screens, cloud servers, televisions, or motion-sensing game consoles in human-computer interaction scenarios. This application does not impose any limitations on the specific type of electronic device.

[0053] Referring to Figure 1, it is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application. The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 131, 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, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 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, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity 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.

[0054] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0055] For example, when the electronic device 100 is a mobile phone or a tablet computer, it may include all the components shown in the figure, or it may include only some of the components shown in the figure.

[0056] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0057] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

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

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

[0060] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU performs mathematical and geometric calculations and is used for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information. The display screen 194 is used to display images, videos, etc.

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

[0062] Internal memory 131 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 131. Internal memory 131 may include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function (such as sound playback, image playback, etc.). The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.).

[0063] In addition, the internal memory 131 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0064] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. For example, the software system of electronic device 100 can adopt a layered architecture. or Operating system (OS). In some implementations, the operating system of electronic device 100 can adopt a layered architecture.

[0065] Referring to Figure 2, it is a software structure block diagram of the electronic device 100 according to an embodiment of this application.

[0066] In some embodiments, a layered architecture can divide software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the operating system is divided into four layers, from top to bottom: the application layer, the application framework layer, the runtime and system libraries, and the kernel layer.

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

[0068] As shown in Figure 2, the application package may include applications such as camera, gallery, calendar, call, memo, navigation, WLAN, Bluetooth, music, video, and SMS.

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

[0070] As shown in Figure 2, the application framework layer may include a runtime management service, a window manager, a content provider, a view system, a phone manager, a resource manager, and a notification manager, etc.

[0071] Runtime management services are a type of service within the operating system used to manage the operation of applications, such as managing the lifecycle of activities. Most applications can contain user interface components, primarily used for user interaction, such as making phone calls, sending emails, and viewing maps. Most of the content users see in the application is provided by these components. For example, depending on the operating system, user interface components can be Ability, Activity, or UIViewController. For ease of understanding, the following text will primarily use Ability as an example.

[0072] During the application startup process, the runtime management service is mainly used to receive the application startup request in order to manage the application's lifecycle, manage the application process and the components corresponding to the process, and be responsible for scheduling the application process to adjust the application's running state.

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

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

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

[0076] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

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

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

[0079] The runtime includes the core libraries and the virtual machine. The runtime is responsible for the scheduling and management of the operating system.

[0080] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

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

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

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

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

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

[0086] To better understand the embodiments of this application, the startup process of any application on the desktop of the electronic device 100 will be described first by way of example with reference to FIG3.

[0087] When a user touches the icon of any application on the desktop of an electronic device, the application's launch process is triggered. During launch, the application (client) first sends a launch request to the runtime management service (server). As the manager of the launch process, the runtime management service creates and starts the application process upon receiving the request. This process then starts its main thread to execute the application's code. During launch, the main thread goes through a series of key stages, including system-level and application-level startup tasks, ultimately displaying the application's main interface (or homepage) on the desktop.

[0088] Figure 3 shows a flowchart of the application startup process, which includes the following:

[0089] Process creation: The system will create a new process to serve as the runtime environment for the application.

[0090] Creating an application (App): Instantiating an application object in the process of creation.

[0091] Creating a UI component model: This is used to prepare a specific UI component for the application. In some operating systems, the UI component model can be an AbilityStage.

[0092] Reading the startup framework configuration file: The system reads configuration files containing various parameters and settings required to start tasks. Based on these parameters and settings, the startup framework automatically orchestrates and schedules the execution order of tasks, ensuring the application starts as expected.

[0093] Task topology sorting: Sort all tasks that need to be started in a topology to ensure that tasks are executed in the correct order.

[0094] Determine the startup mode: The system checks whether the startup task is set to automatic mode. If it is in automatic mode, the startup task is executed directly; otherwise (i.e., in manual mode), the system waits for the UI components to be created before executing the startup task.

[0095] Based on Figure 3, for some operating systems, when the startup framework's startup mode is automatic, the relevant tasks of the startup framework need to be triggered through the Provider mechanism after the application is created. This limits the flexibility of the startup framework's execution and hinders concurrent execution between tasks, thus affecting the application's startup efficiency and performance. Furthermore, it restricts task updates and state changes to specific nodes, thereby limiting the developer's operational freedom during dynamic task updates.

[0096] The application startup process in Figure 3 involves application-layer startup tasks and system-layer startup tasks. Figure 4 shows a schematic diagram of the trace record results for the system-layer startup tasks. In Figure 4, the y-axis represents the number of tasks. Currently, the system-layer startup tasks adopt a serial execution mode. The execution order of several important stages of the system-layer startup tasks is as follows: basic package information query, JavaScript runtime environment (JsRuntime) initialization, additional package information query, additional package information query, and resource management initialization. Referring to Figure 4, this serial execution mode of the system-layer startup tasks leads to the problem of some tasks being executed repeatedly, such as additional package information query, which is repeatedly executed in the main process and resource management initialization stages. This will place an unnecessary burden on the system.

[0097] To address the technical problems involved in the embodiments shown in Figures 3 and 4 above, this application provides an application startup method that integrates the system-level startup process into a startup framework management system. This subdivides the originally lengthy system-level startup tasks into multiple first task groups and application-level startup tasks (second task groups) and incorporates them into the startup framework for unified management. This improvement not only identifies and eliminates invalid duplicate calls, promoting the sharing and optimization of process resources, but also enables concurrent execution of tasks during application startup, thereby improving system startup efficiency and response speed. Within this framework, by selecting one or more first target task groups from among the multiple first task groups and configuring access points, the second task group can select one access point to connect to the first target task group containing that access point according to actual needs. Thus, during the execution of the first task group, when the startup process of the first application progresses to the first target task group, the second task group can be automatically triggered and executed without additional monitoring or intervention. This not only simplifies the complexity of task execution but also improves the flexibility and response speed of the application startup process.

[0098] Referring to Figure 5, this embodiment of the application provides a Unified Modeling Language (UML) class diagram for application startup tasks. This UML class diagram intuitively illustrates the hierarchical architecture and interrelationships between the abstract definition of startup tasks (covering the StartupTask base class and its subclasses) and their concrete execution (completed through the corresponding StartupExecutor implementation class). By integrating system-level startup tasks and application-level startup tasks into a unified startup framework, with the StartupTask base class as the core, a flexible and easily extensible startup task framework system is constructed. This framework encapsulates diverse startup tasks by defining different task subclasses and matches them with corresponding executors to achieve efficient task execution. The following sections will elaborate on the hierarchical structure and execution mechanism of startup tasks in the UML class diagram.

[0099] 1. System-level startup task

[0100] The NativeStartupTask class is used to encapsulate system-side startup tasks, manage native code startup tasks, and perform native initialization operations when the application starts.

[0101] The `NativeStartupExecutor` class is used to schedule and execute native startup tasks. It can retrieve and set data for the first group of M tasks when the application starts.

[0102] 2. Application layer startup task

[0103] The JavaScript StartupTask class is used to manage a second group of tasks for JavaScript code classes, such as initializing the JavaScript environment or loading related JavaScript modules.

[0104] The JavaScript StartupExecutor class is used to schedule and execute JavaScript StartupExecutors, which execute the second task group of JavaScript code classes or request data by calling JavaScript code.

[0105] The JavaScript startup task focuses on encapsulating startup tasks at the JavaScript layer, such as loading, initializing, and configuring JavaScript code. The JavaScript startup executor then executes these tasks, ensuring the JavaScript environment is ready when the application starts. This design allows JavaScript layer tasks to integrate with system layer tasks, working together to support a smooth application startup.

[0106] The GroupStartupTask class is used for the startup logic of task groups and is responsible for loading and initializing specific task groups.

[0107] The GroupStartupExecutor class is used to schedule and execute task group startup tasks. It can obtain and set data for the second task group when the application starts.

[0108] The task group startup task allows multiple different types of startup tasks to be combined into a task group, or second task group. The task group startup executor is responsible for executing these task groups, ensuring that dependencies and execution order between tasks are handled correctly. This design not only improves the execution efficiency of startup tasks but also enhances the system's flexibility and scalability. The startup executor, located above all other executors, indicates that these executors all conform to the execution interface or framework defined by the startup executor. The aforementioned native startup executor, JavaScript startup executor, and task group startup executor are all concrete implementations of the startup executor. Throughout the startup process, dependencies can exist between the executors, and each executor coordinates the execution order of the task groups based on these dependencies. Each executor returns execution results or status feedback when executing a task to facilitate subsequent task processing or error handling.

[0109] As an example, and not a limitation, Figure 6 illustrates the parallel and sequential execution flow among multiple first task groups in a portion of the system-level startup tasks. In the application startup process, the `HandleLaunchApplication` function acts as the entry point, responsible for coordinating and guiding the entire task startup sequence. The subsequent first task groups, executed with `HandleLaunchApplication` as the entry point, include: basic package information query, JavaScript runtime creation, initialization running on the remaining App-level main thread, lifecycle management of the notification component service driver phase, querying one or more additional package information, initialization running on the remaining App-level non-main thread, and creation on the ResourceMgrNative side.

[0110] For example, in some operating systems, the component management service may be an ability manage service (AMS). In other operating systems, the component management service may be an activity manage service (AMS).

[0111] For example, the aforementioned additional packages can be shared packages within an application, shared packages between applications, system libraries, or resource replacement packages. Among these, resource replacement packages are packages developed by developers to adapt to the display styles of different products. Resource replacement packages can include image resource packages, layout resource packages, string resource packages, color and theme resource packages, etc.

[0112] The process involves the application initiator handling the application's startup request. After querying basic package information on the main thread, it executes the creation of the JavaScript runtime and the initialization running on the remaining App-level main threads. The AMS driver phase lifecycle, queries for various additional packages (as shown in Figure 6, the in-application shared package query and resource replacement package query), and the initialization running on the remaining App-level non-main threads are executed concurrently in different sub-threads, simultaneously with the main thread. Since the functionality on the ResourceMgrNative side depends on the execution result of the resource replacement package, the ResourceMgrNative side and the resource replacement package are executed through the same sub-thread. After each thread successfully completes the above tasks, the HandleLaunchAbility phase begins. It's easy to understand that the HandleLaunchAbility phase primarily loads capabilities related to the main interface. It should be understood that capabilities related to the main interface can also be called main capabilities. In summary, a main capability is a type of component in the application responsible for implementing business functions related to the user interface.

[0113] It should be understood that the first task group division shown in Figure 6 is merely an exemplary logical division, intended to provide a possible reference. In practical applications, the division of the first or second task group should be based on actual needs to ensure that each group of tasks can be executed efficiently and orderly. This application does not impose any rigid rules or restrictions on the specific division method of task groups. Developers can flexibly adjust the task group division strategy according to factors such as application characteristics, performance requirements, and resource availability.

[0114] As another example, please refer to Figure 7, which illustrates a flowchart of the key stages experienced by the main thread during application startup when executing system-level startup tasks. Specifically, this may include the following:

[0115] Retrieving basic application information (i.e., querying basic package information): The application's context can be obtained through the `getContext()` method of the `Ability` class. Using the context object, basic application information can be obtained through the `ApplicationInfo` class. For example, basic application information includes the application's name, version, package name, etc.

[0116] Creating a JavaScript runtime: This involves initializing a JavaScript runtime environment in which JavaScript code can be executed. This typically involves setting up the necessary context and resources to support the execution of JavaScript.

[0117] The UI component model loading module primarily associates UI components with their required resources, dependencies, and configuration information, ensuring that these UI components are loaded and started at the correct time. For example, in some operating systems, the UI component model loading module may be an AbilityStageLoadModule. It should be noted that the following descriptions will use the AbilityStageLoadModule as an example when discussing UI component model loading modules.

[0118] UI Component Model: A component container used to manage the lifecycle, resource allocation, and process of UI components. Each UI component has a UI Component Model instance, responsible for managing the component's lifecycle, resource allocation, and process management at that stage. For example, in some operating systems, the UI Component Model can be an AbilityStage. In other operating systems, the UI Component Model can be a ViewController. It should be noted that in the following descriptions involving UI Component Models, the AbilityStage will be used as an example.

[0119] The UI component loading module is responsible for loading and managing UI components at different stages or states within an application or service. For example, it associates UI components with their required resources, dependencies, and configuration information, and ensures that these components are loaded and started at the correct time. For instance, in some operating systems, the UI component loading module may be an AbilityLoadModule. It should be noted that in the following descriptions involving the UI component loading module, the AbilityLoadModule will be used as an example.

[0120] UI component initialization: This is a callback method in the UI component's lifecycle, called when the UI component is created. It can perform operations such as setting the user interface, loading data, and configuring parameters. UI component initialization is a crucial node in the UI component's lifecycle, marking the beginning of capability construction and readiness for operation. For example, in some operating systems, UI component initialization may occur during capability creation (AbilityOnCreate). It should be noted that subsequent descriptions involving UI component initialization will exemplify capability creation.

[0121] When a UI component switches to the foreground: This refers to the behavior or processing logic of an application or UI component when it is in the foreground state. In the foreground, the application typically interacts directly with the user and needs to handle user input, update the interface, and perform other operations. For example, in some operating systems, a UI component switching to the foreground can be an AbilityForeground. It should be noted that subsequent descriptions involving UI component switching to the foreground will use the AbilityForeground as an example.

[0122] It should be noted that system-level startup tasks are not limited to the task groups mentioned above. For example, they can also include task groups that pre-drive the lifecycle of models and task groups that pre-drive the lifecycle of UI components. Depending on application requirements and thread configuration resources, during task configuration, task groups with no dependencies can be configured to execute on different threads to achieve task concurrency and thus improve task execution efficiency.

[0123] It should be noted that in the embodiments of this application, "application" and "application program" are the same concept, referring to the same content. One of the descriptions is used in different places, and the two can be used interchangeably.

[0124] Figure 8 is a flowchart illustrating an application launch method according to an embodiment of this application. This application launch method can be applied to electronic devices, but the electronic device is not limited to the specific order shown in Figure 8. It should be understood that in other embodiments, the order of some steps in this method can be interchanged according to actual needs, or some steps can be omitted or deleted. As shown in Figure 8, the method includes steps S801 to S804, which are explained in detail below.

[0125] S801. Identify multiple first task groups.

[0126] In this system, the first target task group within multiple first task groups is configured with an access point, through which the second task group connects to the first target task group. The first and second task groups are used to launch the first application; the first task group is the system-level launch task for the corresponding first application, and the second task group is the application-level launch task for the corresponding first application. It should be noted that there can be one or more first target task groups, and one or more second task groups. It is easy to understand that the number of first task groups can be set according to the actual situation of different applications (e.g., different functions or storage size), and the number of second task groups can be set based on a combination of the number of first target task groups and actual needs; no limitations are imposed here.

[0127] It should be understood that, in the embodiments of this application, the first application may be any of the following: a desktop application on a personal computer, an application specifically designed for electronic devices such as smartphones and tablets, an application based on a web kernel, an application embedded in other applications (such as a mini-program), or a cloud application hosted on a cloud server and accessed via the Internet.

[0128] Optionally, multiple first task groups and second task groups can be launched in parallel using a main thread and at least one child thread to start the first application. The first task group can be either executed by the main thread or by one of the child threads. This scheme employs a framework-based management strategy to uniformly manage the system-level and application-level startup tasks of the first application, enabling concurrent execution of the entire startup task by the main thread and child threads. This not only accelerates the application startup process but also provides greater flexibility and stronger fault tolerance. Furthermore, the first task group can be flexibly assigned to the main thread or a specific child thread based on actual needs, further enhancing the flexibility and efficiency of the system-level startup task execution.

[0129] In some embodiments, the access point for the first target task group is a reserved location (denoted as the reserved location) in the configuration file of the first task group for the second task group. For example, the reserved location may be located at the beginning of the configuration file of the first target task group. The task identifier of the second task group can be edited at the reserved location, so that the application can obtain the configuration file of the second task group based on the task identifier of the second task group during the startup process.

[0130] For example, by reserving a space at the beginning of the configuration file of the first target task group for editing the task identifier of the second task group (such as TASK_GROUP_ID="), the task identifier of the second task group can be added to the right of "=".

[0131] In one implementation, the first task group includes one or more first subtasks, and the second task group includes one or more second subtasks. Each of the first task group, first subtask, second task group, and second subtask has a unique task identifier. This ensures the uniqueness and traceability of the task group and subtasks during task initiation, facilitating subsequent searching, monitoring, and debugging, and preventing duplicate task execution.

[0132] Optionally, the task identifier for a task group or subtask can be a unique and descriptive name, number, or a specific sequence of characters.

[0133] As an example, two different category identifiers can be used to distinguish between system-level startup tasks and application-level startup tasks. For instance, the category identifier for system-level startup tasks can be represented as "Native," while the category identifier for application-level startup tasks can be represented as "Group." The first task group can use a combination of the system-level startup task's category identifier and a number as its task identifier. Different first task groups use different numbers in their task identifiers, such as Native1, Native2, etc., to ensure that each first task group has a unique task identifier. Alternatively, the system-level startup task's category identifier can be used combined with a universally unique identifier (UUID). The same applies to application-level startup tasks, which will not be elaborated further here.

[0134] As another example, for the subtasks contained in each task group, the task group task identifier + number can be used. For example, for the first subtask in the first task group Native1, Native1001, Native1002, etc. can be used as the task identifiers for different first subtasks in Native1.

[0135] In this embodiment, the second subtasks in the second task group can be executed using the same thread or different threads. For example, second subtasks with dependencies can be executed using the same thread, while second subtasks without dependencies can be executed concurrently using different threads.

[0136] In this embodiment, the second task group can be connected to the first target task group in the main thread or the first target task group in the child thread.

[0137] As an example, the first target task group can be a task group that is at a critical point in the application startup process among the various task groups on the main thread. For example, referring to Figure 9, access points can be configured as the first target task group at the capability stage, capability creation time, and capability foreground on the main thread, which are respectively the access point for the application startup framework capability stage, the access point for the application startup framework capability creation time, and the access point for the application startup framework capability foreground.

[0138] In some embodiments, the priority of the first target task group is determined by the priority of the second target task group, which is a task group that depends on the second task group during the startup of the first application. The priority is used to characterize the execution order of each task group. This is to ensure that each task group can execute in an orderly manner according to logic and dependencies, reduce conflicts and waiting between tasks, and thus improve the overall efficiency of task execution.

[0139] Optionally, the second target task group can be either the first task group or the second task group.

[0140] It should be understood that the second target task group depends on the second task group, meaning that the execution order of the second target task group is after the second task group, that is, the execution of the second target task group depends on the execution result of the second task group.

[0141] In some embodiments, based on the dependency relationship between the second task group and the second target task group, the second task group can be referred to as the "preceding task group," which refers to a task group that must be completed before another task group. Its execution result or output is a prerequisite or necessary condition for the subsequent task group to begin execution. The second target task group can be referred to as the "subsequent task group," which depends on the task group completed by the preceding task group; its execution requires data, resources, or specific conditions provided by the preceding task group. It should be noted that the "preceding task group" is relative to the "subsequent task group," indicating that it precedes the subsequent task group in the execution order and is the foundation upon which the subsequent task group can execute.

[0142] Understandably, higher priority tasks are executed earlier in the execution order. For example, if task group A has a higher priority than task group B, then task group A will be executed before task group B. In other words, the dependency relationship between task A and task B is that task B depends on task A, and the execution order of task groups is determined by the dependencies between them.

[0143] Optionally, the first target task group that the second task group connects to has a higher priority than the second target task group. This is to ensure the smooth execution of the second target task group and improve the overall task execution efficiency.

[0144] In some embodiments, different second task groups connect to different first target task groups. For example, suppose there is a second task group A1, a second task group A2, and a first target task group B1; if the second task group A1 connects to the first target task group B1, then the second task group A2 cannot connect to the first target task group B1.

[0145] It is understandable that the second task group connects to the first target task group, and the second target task group depends on the second task group. Therefore, it can be concluded that the first target task group and the second target task group also have a dependency relationship, namely, the second target task group depends on the first target task group.

[0146] Optionally, the task identifier, as a unique identifier for the task group, can serve as an index or keyword to quickly and accurately confirm the execution status of the task group. This allows for timely understanding of task progress, not only identifying and preventing duplicate task execution and promoting resource sharing in the startup process, but also preventing task failures caused by executing the first target task group before the dependent task group has been completed. Therefore, based on the dependency relationship between the first and second target task groups, the second target task group is executed after the first target task group has been completed.

[0147] For example, in Figure 9, the other first task groups of the second task group accessed during the capability dependency phase are all executed after the capability phase. For instance, the second task group that the capability phase loading module depends on can access the capability phase. Similarly, the first task groups of the second task group accessed during capability dependency creation are all executed after capability creation. The same applies to other first target task groups, which will not be elaborated further here.

[0148] Understandably, in order to improve the startup speed of the first application, when determining the first target task group to which the second task group is connected, the execution order of other task groups that depend on the second task group (i.e., the second target task group) and the execution order of the first target task group can be used. For example, the execution of the first target task group to which the second task group is connected takes precedence over the execution of other task groups. This avoids other task groups having to wait because the second task group has not yet completed when executing other task groups that depend on the second task group, thus affecting the overall task execution progress.

[0149] As another example, when there are no dependencies between the first task groups in the system-level startup task, the first task groups can be set to execute concurrently on different threads.

[0150] For example, based on Figure 7 above and referring to Figure 10, the startup task of the first application also includes the following first task groups executed by the sub-thread: first task group 2.1, early stage lifecycle task group, first task group 5.1, first task group 6.1, and early Ability lifecycle task group.

[0151] Since Task Group 2.1 has no dependencies on the JavaScript runtime creation and capability stage loading modules, it can be run in a sub-thread to achieve concurrent execution with them. Similarly, since the pre-driven Stage lifecycle has no dependencies on either the capability stage loading module or Task Group 2.1, it can be run on a different sub-thread than Task Group 2.1 to achieve concurrent execution with both. Likewise, Task Group 6.1 depends on Task Group 5.1, but neither Task Group 5.1 nor Task Group 6.1 has any dependencies on the capability loading module or capability creation module. Therefore, Task Groups 5.1 and 6.1 can be run on the same sub-thread and concurrently with the capability loading module and capability creation module.

[0152] In some embodiments, depending on the application startup requirements, the first task group executed on the main thread can be selected as the first target task group in the system-level startup task, or the first task group executed on the child thread can be selected as the first target task group. This application embodiment does not limit this.

[0153] Referring to Figure 10, an access point can be set in the task group for obtaining basic App information on the main thread (i.e., the access point for the task group for obtaining basic App information in the application startup framework) and the capability loading module (i.e., the access point for the task group for obtaining basic App information in the application startup framework). Alternatively, an access point can be set in the first task group 2.1 of the sub-thread (i.e., the access point for the first task group 2.1 of the application startup framework).

[0154] For example, the first task group 2.1 may include one or more first sub-tasks such as loading configuration files, initializing database connections, loading cached data, and initializing the logging system. The first task group 5.1 may include one or more first sub-tasks such as loading application-specific resources (e.g., images, translation files), initializing network communication modules, starting scheduled tasks or background services, and initializing user interface elements. The first task group 6.1 may include one or more first sub-tasks such as initializing interfaces with external systems (e.g., payment systems, push services), loading user data, initializing security modules (e.g., encryption, authentication), and loading the application's initial state data, in order to provide support and assurance for the subsequent functions of the first application.

[0155] It should be noted that the above description is only an example of concurrent execution between task groups and selecting the first target task group in the first task group. In actual applications, tasks can be flexibly executed in a child thread or the main thread according to specific needs.

[0156] In some embodiments, the first task group and the second task group corresponding to the first application can be obtained from the configuration file corresponding to the first application. In practical applications, the first task group and the second task group can be predefined in the configuration file of the first application. In other possible implementations, the task group and the second task group can also be user-defined. For example, under the "ets / startup" path, configuration files for each task group and a common startup parameter configuration file are set, and the names of each file are unique. The common startup parameter configuration file can be a configuration file that centrally manages startup tasks, containing shared parameters (such as task identifiers for task groups or subtasks) and settings required by all startup tasks (including task groups and subtasks), thereby avoiding the duplication of the same parameters in the configuration files of each individual task group or subtask, thus improving maintainability and consistency.

[0157] It should be understood that the number of subtasks in different task groups may be the same or different. This application does not impose any restrictions on this.

[0158] In some embodiments, multiple subtasks in each task group (such as multiple first subtasks in a first task group or multiple second subtasks in a second task group) may have the same task type, that is, the subtasks in each task group belong to the same task type.

[0159] Since tasks of the same type often have similar execution requirements and / or similar modules that need to be loaded, grouping tasks of the same type into the same task group can centrally process subtasks of the same type, optimize the order and parallelism of task execution, reduce unnecessary waiting time, and further accelerate the overall startup speed of the application.

[0160] Furthermore, this setup improves code organization and maintainability, enabling developers to more clearly understand and manage the logical relationships and dependencies between task groups and subtasks. A unified error handling mechanism and performance monitoring can also be implemented later, allowing for rapid location and resolution of problems during program execution, as well as performance evaluation and optimization of each task group.

[0161] In some embodiments, the same task group may also include one or more subtasks of different task types. It should be noted that when the task group is a first task group, the subtask is the first subtask; when the task group is a second task group, the subtask is the second subtask.

[0162] Based on the above scheme, multiple subtasks in the task group can be sorted according to task type. For example, subtasks with the same task type can be executed first (or last). In this way, multiple subtasks with the same task type can be executed together, minimizing the problem of low subtask execution efficiency caused by confusion in task types.

[0163] As an example, and not a limitation, suppose task group A (which could be either the first or second task group) includes three subtasks: Task 1, Task 2, and Task 3. These three subtasks have the same task type (e.g., all are performance monitoring and optimization subtasks). During application startup, these three subtasks can be executed sequentially. In practical applications, due to application upgrades or other reasons, Task 4 can be added to task group A. The task type of Task 4 can be different from the three subtasks mentioned above; for example, Task 4 could be a subtask for asynchronous task processing. Then, during application startup, for Tasks 1, 2, 3, and 4 in task group A, Tasks 1, 2, and 3 can be executed first, followed by Task 4; or Task 4 can be executed first, followed by Tasks 1, 2, and 3. This approach maintains the execution order of Tasks 1, 2, and 3 with the same task type while also ensuring the execution of Task 4, thus improving the efficiency of executing these multiple subtasks.

[0164] The subtasks in the above task group may include: error handling, security checks, permission checks, loading of asynchronous tasks (such as AsyncTask, Loader, etc.), callbacks and listeners, loading of resources corresponding to language and locale settings, component initialization, debugging, logging, performance monitoring and optimization, etc.

[0165] The main thread can execute not only one or more of the multiple first subtasks (corresponding to one or more subtasks in the example above), but also other tasks required to start the first application. For example, other tasks required to start the first application may include one or more of the following subtasks: window creation, view management (e.g., measurement, layout, drawing), initialization operations (e.g., initializing database connections, initializing global variables or network requests), message loop processing, and lifecycle callbacks.

[0166] In some embodiments, the electronic device can trigger the startup process of the first application in response to a user's trigger operation on the first application. The trigger operation can be used to trigger any control, application icon, or service, so that the electronic device can respond to the trigger operation and execute the application startup methods provided in the various embodiments of this application to launch the first application.

[0167] It should be understood that the specific operation that triggers any control, application icon, or service can be a click, touch, single click, double click, two-finger swipe, or long press on any control or application icon for a preset duration. It can also be one or more of the following operations: key input, gesture recognition, body language recognition, voice recognition, facial expression recognition, eye movement recognition, and face recognition. This application embodiment does not specifically limit these operations.

[0168] S802. Execute multiple first task groups, wherein if a first target task group with access to a second task group is executed, the second task group accessed by the first target task group is executed.

[0169] In some embodiments, by encapsulating all tasks of the second task group and integrating them into the first target task group as a group, the second task group can be managed and executed as an independent entity within the first target task group. This allows for independent development and maintenance of both the first target task group and the second task group integrated into it, reducing coupling between them and simplifying the overall maintenance of the application startup task.

[0170] Understandably, the second task group connects to the first target task group through a predefined access point, and the first target task group does not need to know the internal details of the second task group. After the thread executes the first task group, it can directly trigger the execution of the second task group without needing to listen to determine the execution progress of the task.

[0171] In one implementation, executing the second task group accessed in the first target task group includes: obtaining the task identifier of the second task group through the access point of the first target task group; obtaining the configuration file of the second task group based on the task identifier of the second task group; and executing the second task group based on the configuration file of the second task group.

[0172] In the above scheme, only the task identifier of the second task group needs to be recorded in the access point of the first target task group. This identifier allows access to the configuration file of the second task group. This not only simplifies the structure and implementation of the access point but also reduces the coupling between the first target task group and the second task group, improving the system's flexibility and maintainability.

[0173] It should be understood that the details of the access point can be found in the relevant content of the foregoing embodiments, and will not be repeated here.

[0174] Optionally, when a thread executes the Kth first target task group, it checks whether a task identifier for the second task group exists at the reserved location (i.e., access point) within that first target task group to determine if the first target task group should be connected to the second task group. If it exists, the configuration file for the second task group is obtained using the task identifier at the reserved location. The configuration file for the second task group records a list of one or more subtasks and the execution mechanism (such as dependencies) of each subtask. Here, K ≤ X, and K is a positive integer.

[0175] As an example, the file path of the second task group can be obtained through the task identifier of the second task group in the aforementioned public startup parameter configuration file, and the configuration file of the second task group can be obtained based on the file path.

[0176] In some embodiments, when a thread executes the Kth first target task group, it retrieves the configuration file of the second task group. This configuration file contains one or more second subtasks and their dependencies. Based on these dependencies, one or more second subtasks are executed. If the Kth first target task group depends on the second task group, the Kth first target task group is executed after the second task group has finished executing. If the Kth first target task group does not depend on the second task group, the Kth first target task group and the second task group can be assigned to different threads for concurrent execution.

[0177] Optionally, at least two second subtasks that do not have dependencies may be executed concurrently through different threads.

[0178] As an example, referring to Figure 11, an execution logic diagram of a task group is provided. The first task group includes Native1, Native2, Native3, Native4, Native5, Native6, and Native7; the second task group includes the task group identified as Group. The dependencies between the task groups (including the first and second task groups) are as follows: Native7 depends on Native6 and Group; Native6 depends on Native5; Native5 depends on Native3 and Native4; Native3 and Native4 both depend on Native2; and Group and Native2 both depend on Native1.

[0179] Based on the above task groups, we can conclude that Group can be executed concurrently with Native2, Native3, Native4, Native5, and Native6, and Native3 can be executed concurrently with Native4.

[0180] In the above startup framework, assuming Native7 is the first target task group, and Group can be the second task group to access Native7. Since Native7 depends on Group, the access point can be set at the beginning of Native7's configuration file to avoid affecting Native7's task execution. It should be understood that when Group accesses Native7, it can be understood that Native7 depends on Native1.

[0181] Therefore, after Native1 completes execution, Native7 is executed. By obtaining the configuration file of Native7, the task identifier of the Group can be obtained. Based on this task identifier, the configuration file of the Group can be retrieved, revealing that the second subtasks within this Group include: GroupInit, Group1, Group2, Group4, Group5, and GroupFinish. The dependencies between these second subtasks are also determined: GroupFinish and Group4 both depend on Group1, Group5 depends on Group4, and Group1 and Group2 both depend on GroupInit. GroupInit, as the starting task of the second task group, depends on Native1. It should be noted that the completion of GroupFinish indicates the completion of the Group's execution.

[0182] Understandably, by establishing dependencies between the second subtasks within a Group, it can be determined that Group5 and Group4 can be executed concurrently in different threads from GroupFinish.

[0183] In one possible implementation, the task identifier of the second task group is obtained; the execution status of the second task group is determined based on the task identifier; when the execution status of the second task group is completed, the first target task group is executed.

[0184] The above solution confirms the execution status of the second task group by identifying the task identifier of the second task group. This not only helps to identify and avoid duplicate execution of tasks and promotes resource sharing in the startup process, but also prevents the first target task group from failing when dependent tasks have not yet been completed.

[0185] In some embodiments, a fourth target task group that the third target task group depends on is identified; the third target task group is the currently executing task group among all task groups, and the fourth target task group is the task group that the third target task group depends on among all task groups, and all task groups include all first task groups and second task groups; the execution status of the fourth target task group is determined according to the task identifier of each fourth target task group; if the execution status of the fourth target task group is completed, the third target task group is executed.

[0186] Optionally, the number of fourth target task groups can be one or more.

[0187] It should be noted that the third target task group depends on the fourth target task group, meaning that the execution order of the fourth target task group is before that of the third target task group.

[0188] Understandably, whether the third target task group is a system-level task group or an application-level task group, when executing the third target task group, the execution status of the fourth target task group can be determined by the task identifier of the fourth target task group it depends on. If the fourth target task group has been executed before and its execution status is completed, then the third target task group will be executed directly.

[0189] In some embodiments, each task group and each subtask has a status identifier, which is used to characterize its execution status, such as "pending execution", "in execution", "completed", "failed", etc. The status identifier is recorded according to the task execution status of each task group and subtask, and a status identifier is maintained for each subtask or task group. For example, the status identifier for "pending execution" is "00", the status identifier for "in execution" is "01", the status identifier for "completed" is "02", and the status identifier for "failed" is "03".

[0190] Before executing a task group or subtask, check its execution status. If it is already completed or in progress, skip that task group or subtask. As an example, a database can be used to store the execution records of each task group and subtask. These records can include the task identifier, execution time, and status information of each task group and subtask. Before execution, query the database to determine if each task group or subtask has already been executed. Similarly, when executing task groups or subtasks, taking task group A as an example, check if the execution status of the task groups or subtasks that task group A depends on is "completed." If the execution status of the task groups or subtasks that task group A depends on is "pending execution" or "in progress," wait for their execution status to be completed. If the execution status of the task groups or subtasks that task group A depends on is "completed," then execute task group A. Subtasks follow the same logic and will not be elaborated further here.

[0191] It should be understood that the status identifier in the database can also be replaced with the execution status, and the database can directly store task execution records, including the execution time and execution status of each task group and subtask.

[0192] For example, based on Figure 11, if there are other first or second task groups that depend on Group after Native7, then if the execution status of Group in the database is found to be completed before executing other first or second task groups, the other first or second task groups will be executed directly without re-executing Group. Similarly, if there are other first or second task groups that depend on Native6 after Native7, then if the execution status of Group in the database is found to be completed before executing other first or second task groups, the other first or second task groups will be executed directly without re-executing Native6.

[0193] Optionally, the execution status of each task group and / or each subtask within each task group can be updated based on the task execution status of each task group and / or each subtask within each task group. Specifically, the execution status of the first task group and / or the first subtask can be updated based on the task execution status of the first subtask within the first task group; similarly, the execution status of the second task group and / or the second subtask can be updated based on the task execution status of the second subtask within the second task group.

[0194] In the above scheme, the execution status of the task group and / or the subtask in the task group is dynamically updated based on the task execution status of the subtask in the task group, so as to record the task progress of the task group and subtask in a timely manner, thereby promoting resource sharing and efficiency improvement in the startup process.

[0195] It should be understood that when the current task execution status of each task group and / or each subtask in each task group is inconsistent with the recorded status identifier, the recorded status identifier of each task group and / or each subtask in each task group will be updated to the status identifier corresponding to the current task execution status.

[0196] As an example, referring to Figure 11, for a Group, based on the dependencies between GroupInit, Group1, and GroupFinish, when the execution status of GroupFinish is "completed," the execution status of the Group can be represented as "completed," without needing to determine the execution status of the three subtasks, GroupInit, Group1, and GroupFinish, to obtain the execution status of the Group. It should be understood that the execution status of Group2, Group4, and Group5 does not affect the execution status of the Group.

[0197] S803, Display the application interface of the first application.

[0198] Understandably, once both the first and second task groups have been completed, the first application will be launched and its interface will be displayed.

[0199] The application startup method provided in this application adopts a framework-based management strategy, incorporating system-level startup tasks (first task group) and application-level startup tasks (second task group) into a unified startup framework for management. Within this framework, each first target task group in multiple first task groups is configured with an access point to establish a connection channel between system-level and application-level startup tasks. This allows second task groups to select one access point to connect to the first target task group based on actual needs. This not only meets the requirements for concurrent execution and staggered operation between task groups, but also automatically triggers and executes the second task group when the startup process of the first application reaches the first target task group during the execution of the first task group, without additional monitoring or intervention. This automatic triggering mechanism simplifies the complexity of task execution, improves the flexibility and response speed of the application startup process, and provides strong support for the rapid and stable startup of applications.

[0200] Furthermore, during application development, this framework-based management approach, combined with access point configuration, ensures that tasks at both the system and application layers are managed according to a unified process, reducing the likelihood of task execution chaos caused by differences between developers or teams. Simultaneously, the division of task groups enables modular application development, allowing each task group to be developed, tested, and maintained independently. This means that when adding new features or modifying existing ones, developers only need to focus on the relevant task group, eliminating the need for global modifications, thereby improving development efficiency and code maintainability.

[0201] Based on the application startup method shown in Figure 8, Figure 12 illustrates a data interaction process corresponding to the application startup method provided in this embodiment of the application. It mainly involves data interaction between four types of components: the main thread (MainThread), the startup manager (StartupManager) class, the startup task (StartupTask) class, and the startup task scheduler (StartupDispatcher) class. Referring to Figure 12, the data interaction process may specifically include:

[0202] S1201: The main thread initializes tasks, obtains multiple initial task groups, and transfers these initial task groups to the startup manager.

[0203] Optionally, the initial task group is the system-level startup task.

[0204] It should be understood that during task initialization, the main thread divides the tasks in the application startup process into different task groups. Each task group contains a set of related initialization tasks, such as the creation of user interface (UI) components, resource loading, configuration settings, etc. Task groups can be organized logically or functionally; for example, all network-related tasks can be placed in one group, and all UI initialization tasks can be placed in another group.

[0205] S1202: The startup management class verifies multiple initial task groups. After the verification is successful, multiple first task groups are obtained and transmitted to the main thread.

[0206] It should be understood that once multiple initial task groups have passed verification, the initial task group becomes the first task group.

[0207] Optionally, when validating multiple initial task groups, the startup manager constructs a dependency graph based on the dependencies between these groups. For example, this dependency graph could be a directed acyclic graph (DAG) to represent the dependencies and execution order between task groups. After constructing the dependency graph, the startup manager verifies the accuracy of the dependencies between the initial task groups. This verification includes checking for circular dependencies, missing dependencies, or incorrect dependency order. If any dependency anomalies are found, the startup manager will throw corresponding exceptions or error messages so that developers can fix them promptly. In addition to validating dependencies, the startup manager can also dynamically adjust the execution order of the initial task groups based on the dependency graph to ensure that the task groups execute in the correct order, thereby avoiding problems caused by incorrect execution order.

[0208] S1203, The main thread transfers the first task group to the startup task class.

[0209] Optionally, during the creation of the first task group, if the first task group needs to be connected to the second task group as the first target task group, then an access point is configured for the first target task group, and the task identifier of the second task group is configured at the access point.

[0210] S1204. The task class will return the creation result to the main thread.

[0211] It should be understood that by looping through S1203 and S1204, multiple first task groups are eventually created. Different startup task classes are used to start different task groups.

[0212] S1205, The main thread sends a run message to the startup management class.

[0213] The run message is an instruction to start execution or startup, used to notify the startup management class that its scheduled operation or process can begin.

[0214] Understandably, the Run message can carry multiple first task groups as well as some additional data or parameters, such as a list of dependencies, environment variables, and other necessary data for the startup management class to execute its tasks.

[0215] S1206. The startup management class performs topological sorting on multiple first task groups to determine the execution order of the first task groups.

[0216] S1207. The startup management class sends a run message to the startup task scheduler class, where the run message carries the execution order of the first task group.

[0217] S1208. The startup task scheduling class determines the scheduling strategy according to the execution order, selects the first task group to be executed based on the scheduling strategy, and transmits the Execute message to the startup task class that executes the first task group.

[0218] S1209. Start the task class to execute the first task group and return the execution result to the start task scheduler class.

[0219] It should be noted that when the startup task class executes the first target task group, it also needs to execute the second task group connected to the first target task group.

[0220] It should be understood that by repeatedly executing S1208 and S1209, the execution of multiple first task groups and one or more second task groups is eventually completed.

[0221] Optionally, the loop execution logic is as follows: The task scheduler class selects the next task group to be executed according to the scheduling policy. The task scheduler class sends an Execute message to the selected task class. The task class receives and parses the Execute message and begins executing the task. After the task is completed, the task class sends a completion signal to the task scheduler class. The task scheduler class receives the completion signal and continues to schedule and execute the next task group as needed.

[0222] Furthermore, it is understood that the data interaction flow diagram shown in Figure 12 above, corresponding to the above application startup method, is merely an example, and the flow diagram provided in this application embodiment does not constitute a specific limitation on the processing flow for launching the first application.

[0223] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0224] Based on the application launch methods provided in the above embodiments, this application also provides the following:

[0225] This application provides an application launch device and / or electronic device for executing the above-described application launch method, achieving the same effect as the above-described implementation method.

[0226] When using an integrated unit, the application launch device and / or electronic device may include a processor (or processing module) and a display (or display module), wherein the processor may implement or execute various exemplary application launch methods described in conjunction with the disclosure of this application. The display may be used to display the user interface corresponding to the application in the foregoing embodiments.

[0227] Optionally, the application initiation device and / or electronic device described above may also include a memory (or storage module), which can be used to store computer programs or instructions.

[0228] This application provides a computer program product, which includes a program that, when run by an electronic device, enables the application launch method shown in the above embodiments of the electronic device.

[0229] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the application startup methods shown in the above embodiments.

[0230] This application provides a chip including a memory and a processor. The processor executes a computer program stored in the memory to control the electronic device to execute the application startup method shown in the above embodiments.

[0231] It should be understood that the processor mentioned in the embodiments of this application can be a CPU, or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0232] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0233] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. In the above embodiments, the descriptions of each embodiment have different focuses; parts not described in detail or recorded in a certain embodiment can be referred to in the relevant descriptions of other embodiments.

[0234] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software 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, but such implementation should not be considered beyond the scope of this application.

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

[0236] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

[0238] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying the computer program code to a large-screen device, a recording medium, a computer memory, a read-only memory, a random access memory, an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some examples, the computer-readable medium cannot be an electrical carrier signal or a telecommunication signal.

[0239] Finally, it should be noted that the above description is only a specific implementation of this application, but the protection scope of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the protection scope of this application.

Claims

A method for starting an application, characterized in that The method comprises: determining a plurality of first task groups, a first target task group in the plurality of first task groups being configured with an access point through which a second task group is accessed into the first target task group; the first task group and the second task group being used to start a first application, the first task group being a system layer start task corresponding to the first application, and the second task group being an application layer start task corresponding to the first application; executing the plurality of first task groups, wherein in a case that the first target task group accessed with the second task group is executed, the second task group accessed in the first target task group is executed; displaying an application interface of the first application. The application starting method according to claim 1, characterized in that, The plurality of first task groups and the second task group are executed in parallel by a main thread and at least one sub-thread to start the first application, the first task group being a task group executed by the main thread or a task group executed by one of the sub-threads. The application starting method according to claim 1 or 2, characterized in that, A priority of the first target task group is determined by a priority of a second target task group, the second target task group being a task group dependent on the second task group in a start process of the first application, and the priority being used to represent an execution order of each task group. The application starting method according to claim 3, characterized in that, The priority of the first target task group accessed by the second task group is higher than the priority of the second target task group. The application starting method according to claim 3 or 4, characterized in that, The method further comprises: based on a dependency relationship between the first target task group and the second target task group, executing the second target task group after the first target task group is executed. The application starting method according to any one of claims 1-5, characterized in that, The first task group comprises one or more first sub-tasks, the second task group comprises one or more second sub-tasks, and the first task group, the first sub-tasks, the second task group, and the second sub-tasks have task identifications respectively. The application starting method according to claim 6, characterized in that, The method further comprises: obtaining a task identification of the second task group; determining an execution state of the second task group according to the task identification of the second task group; when the execution state of the second task group is completed, executing the first target task group. The application starting method according to claim 6 or 7, wherein The method further comprises: updating an execution state of the first task group and / or the first sub-tasks according to a task execution condition of the first sub-tasks in the first task group; updating an execution state of the second task group and / or the second sub-tasks according to a task execution condition of the second sub-tasks in the second task group. The application starting method according to any one of claims 1-8, characterized in that, The execution of the second task group accessed in the first target task group comprises: obtaining a task identification of the second task group through an access point of the first target task group; obtaining a configuration file of the second task group according to the task identification of the second task group; executing the second task group according to the configuration file of the second task group. An electronic device, characterized by comprising: The electronic device is configured to execute the method of any one of claims 1 to 9. A chip system, characterized by The chip system comprises a processor which executes a computer program stored in a memory to implement the method of any one of claims 1 to 9. A computer-readable storage medium, characterized by, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the method in any one of claims 1 to 9.

Images