Application startup optimization method and device, electronic equipment and storage medium

Abstract

The present disclosure provides an application startup optimization method and device, electronic equipment and storage medium, relates to the technical field of computers, in particular to the fields of application program startup control, task scheduling and performance optimization, and can be used in application scenarios such as mobile terminal application and network disk application startup acceleration. The specific scheme is: in response to a startup event of a target application, during the execution of the startup task, the execution time of an asynchronous task is collected, and a long-time-consuming task in the thread pool is identified and dynamically allocated according to the execution time; the time consumption data of the target application in each startup stage is collected; according to the time consumption data of each startup stage, the parallel loading strategy or the thread pool configuration is dynamically adjusted for the tasks not yet executed in the current startup. The present disclosure can adaptively optimize the startup strategy, systematically shorten the startup time, and improve the stability of the startup performance and the user experience.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of application startup control, task scheduling and performance optimization, which can be used in application scenarios such as startup acceleration of mobile terminal applications and cloud storage applications. Specifically, it relates to application startup optimization methods, devices, electronic devices and storage media. Background Technology

[0002] In the field of computer technology, application (APP) startup speed is one of the key indicators affecting user experience. Especially for large applications such as cloud storage and social networking applications, the startup phase typically involves performing numerous initialization tasks, such as loading advertising pages, initializing the homepage view, initializing various third-party software development kits (SDKs), loading routing tables, and reading configuration data. Long application startup times negatively impact user retention. Summary of the Invention

[0003] This disclosure provides an application startup optimization method, apparatus, electronic device, and storage medium.

[0004] According to a first aspect of this disclosure, an application startup optimization method is provided, comprising: in response to a startup event for a target application, during the execution of a startup task, collecting the execution time of asynchronous tasks, identifying and dynamically allocating long-running tasks in a thread pool based on the execution time; collecting time data of the target application at each startup stage; and dynamically adjusting a parallel loading strategy or thread pool configuration based on the time data of each startup stage for tasks that have not yet been executed in the current startup, wherein the parallel loading strategy includes at least the number of tasks to be executed in parallel.

[0005] According to a second aspect of this disclosure, an application startup optimization apparatus is provided, comprising: a task scheduling module, configured to respond to a startup event for a target application, collect the execution time of asynchronous tasks during the execution of startup tasks, and identify and dynamically allocate long-running tasks in a thread pool based on the execution time; a data acquisition module, configured to collect time-consuming data of the target application at each startup stage; and a strategy adjustment module, configured to dynamically adjust a parallel loading strategy or thread pool configuration based on the time-consuming data of each startup stage for tasks that have not yet been executed in the current startup, wherein the parallel loading strategy includes at least the number of tasks to be executed in parallel.

[0006] According to a third aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform any of the methods described in the embodiments of this disclosure.

[0007] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

[0008] According to a fifth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of this disclosure.

[0009] The solution disclosed herein mitigates the "longest board effect" during the startup phase by collecting asynchronous task execution time and dynamically allocating long-running tasks. Simultaneously, it collects execution time data for each stage to accurately pinpoint performance degradation phases. Furthermore, it adjusts the parallel strategies or thread pool configurations of currently running tasks in real time, forming a real-time closed-loop feedback loop. Compared to static solutions, this disclosure adaptively optimizes startup strategies, systematically shortens startup time, and improves startup performance stability and user experience.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating the application startup optimization method according to an embodiment of the present disclosure; Figure 2 This is a schematic diagram of the monitoring and parallel scheduling architecture during the application startup process according to an embodiment of the present disclosure; Figure 3 This is a flowchart of thread pool load balancing and dynamic scheduling based on task time analysis according to an embodiment of this disclosure; Figure 4 This is a schematic diagram of a closed-loop architecture for monitoring and adjusting application startup performance optimization according to an embodiment of this disclosure; Figure 5 This is a schematic diagram of the structure of an application launch optimization device according to an embodiment of the present disclosure; Figure 6 This is a schematic diagram of a scenario based on the application startup optimization method according to an embodiment of this disclosure; Figure 7 This is a structural diagram of an electronic device used to implement the application startup optimization method of the embodiments of this disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0014] Before introducing the technical solutions of the embodiments of this disclosure, the technical terms that may be used in this disclosure will be further explained: Asynchronous tasks refer to operations that do not block the main thread and are executed in a background thread. During application startup, time-consuming operations such as network requests, database loading, and SDK initialization are typically submitted to a thread pool as asynchronous tasks to avoid blocking the main thread. For example, when a cloud storage application starts, it needs to asynchronously initialize the image loading library, message push SDK, and log reporting module. These initialization operations can all be encapsulated as asynchronous tasks and submitted to a thread pool for processing.

[0015] A thread pool is a mechanism for managing and reusing threads, avoiding the overhead of frequently creating and destroying threads. A thread pool maintains several worker threads to execute submitted asynchronous tasks. In this solution, the thread pool can be a dedicated initialization thread pool used during application startup.

[0016] In related technologies, some parallel startup schemes have been proposed to address the aforementioned startup time problem. However, the following technical issues still exist in practical applications: First, the initialization of basic services suffers from the "longest board effect." When using thread pools to concurrently execute asynchronous tasks, the execution time of each task varies. If the execution time of one task significantly exceeds that of other tasks, that task will become the bottleneck of the entire startup process, dragging down the overall startup performance.

[0017] Second, the initialization overhead of basic service components is too high. For example, the page routing framework needs to generate a routing table by performing a full scan of the application code at runtime, a process that can take hundreds of milliseconds or even seconds. Another example is that Shared Preferences (SP) suffers from lock contention and input / output (I / O) blocking issues during read and write operations in a multi-threaded environment, and frequent read and write operations will significantly extend startup time.

[0018] Third, there is a lack of monitoring and adaptive adjustment mechanisms for startup performance. Existing solutions typically only achieve one-time static optimization, that is, scheduling startup tasks according to preset strategies. However, dynamic changes in the actual operating environment (such as device performance, system load, and network conditions) can cause fluctuations in startup time, making it difficult to form a closed loop for performance optimization. This can result in noticeable startup stuttering or white screen phenomena on low-end devices or in high-load scenarios.

[0019] In summary, how to further reduce startup time and improve the stability and adaptability of the startup process while ensuring the normal functioning of the application is a technical problem that urgently needs to be solved by those skilled in the art.

[0020] To at least partially address one or more of the aforementioned problems and other potential issues, this disclosure proposes an application startup optimization method. By collecting the execution time of asynchronous tasks during the target application's startup process and dynamically allocating long-running tasks from the thread pool, it alleviates the "long-board effect" in basic service initialization and prevents a single task from blocking the overall startup process. By collecting time-consuming data from each startup stage, it achieves quantitative monitoring of startup performance and precise location of degradation stages. Furthermore, based on the time-consuming data from each startup stage, it dynamically adjusts the parallel loading strategy or thread pool configuration for tasks not yet executed during the current startup phase, forming a closed-loop mechanism of "real-time optimization—data collection—feedback iteration." These three steps are organically linked. Compared to static, one-off optimization schemes in existing technologies, this disclosure enables the application to adaptively and continuously optimize its startup strategy, systematically shortening application startup time and improving the stability of startup speed and the consistency of user experience.

[0021] This disclosure provides an application startup optimization method. Figure 1This is a flowchart illustrating an application startup optimization method according to an embodiment of the present disclosure. This application startup optimization method can be applied to an application startup optimization device. The application startup optimization device is located in an electronic device. The electronic device includes, but is not limited to, fixed devices and / or mobile devices. For example, fixed devices include, but are not limited to, servers, which can be cloud servers or ordinary servers. For example, mobile devices include, but are not limited to, mobile phones, tablets, etc. In some possible implementations, the application startup optimization method can also be implemented by a processor calling computer-readable instructions stored in memory. Figure 1 As shown, the application startup optimization method includes: S101. In response to a startup event for the target application, during the execution of the startup task, the execution time of the asynchronous task is collected, and long-running tasks in the thread pool are identified and dynamically allocated based on the execution time.

[0022] S102. Collect time consumption data of the target application in each startup stage; S103. Based on the time consumption data of each startup phase, dynamically adjust the parallel loading strategy or thread pool configuration to accommodate tasks that have not yet been executed in the current startup. The parallel loading strategy shall include at least the number of tasks to be executed in parallel.

[0023] In this embodiment of the disclosure, a long-running task refers to an asynchronous task whose execution time exceeds a preset threshold. This threshold can be dynamically set according to business needs and device performance, for example, 300 milliseconds. Long-running tasks are a major factor leading to the "long-board effect" during startup. For example, when an application starts, it may need to perform encryption and decryption initialization on the local database, which may take 500 milliseconds; or it may need to retrieve remote configuration from the server, where network latency may cause the time to exceed 400 milliseconds. These tasks all fall under the category of long-running tasks.

[0024] In this embodiment of the disclosure, asynchronous tasks are tasks executed in background threads (without blocking the main thread) relative to the main thread. They typically refer to specific work units submitted to the thread pool, such as "initializing the routing framework (ARouter)" or "fetching advertising materials," which can be executed serially or in parallel.

[0025] In this embodiment of the disclosure, the execution time is the time taken for a single asynchronous task from start to finish (e.g., an SDK initialization task takes 350ms). This is used to identify "long-running tasks" and dynamically allocate thread pools (e.g., splitting, migrating, and adjusting concurrency) to solve the "long-board effect" at the task level.

[0026] In this embodiment of the disclosure, the parallel execution task is that multiple tasks are executed concurrently within the same time window (using a multi-core central processing unit (CPU)). The emphasis is on the concurrency relationship between tasks, which can be asynchronous tasks or multiple sub-tasks split from the main thread.

[0027] In this embodiment of the disclosure, the time consumption data is the time difference between various key nodes in the startup process (e.g., application initialization takes 150ms, and ad loading takes 200ms). It is used to quantitatively monitor the entire startup process and compare it with the baseline to identify the degradation stage, thereby adjusting the overall parallel loading strategy or thread pool configuration.

[0028] In this embodiment, the parallel loading strategy refers to a task orchestration scheme that changes multiple startup tasks that were originally executed serially into concurrent execution. Specifically, the parallel loading strategy includes, but is not limited to, the following parameters: task dependency configuration, thread pool allocation method, and task priority setting. For example, the parallel loading strategy can be configured as follows: the ad retrieval task and the homepage view creation task are executed in parallel; the ad display countdown task and the homepage data prefetching task are executed in parallel. The number of concurrent tasks or the execution order of tasks in the parallel loading strategy can be dynamically adjusted based on the collected time-consuming data.

[0029] In some specific implementations, in response to a startup event for the target application, the client creates a dedicated startup thread pool and submits all asynchronous tasks requiring pre-initialization to this pool. During task execution, the start and end timestamps of each task are recorded using instrumentation to calculate the actual execution time. The actual execution time is compared with a preset threshold (e.g., 300 milliseconds). If the threshold is exceeded, the task is marked as a long-running task. For long-running tasks, the client dynamically executes splitting logic: if the task can be decomposed into multiple subtasks (e.g., batch database operations can be split into multiple single operations), it is split into multiple short tasks and reallocated to idle threads in the thread pool for parallel execution; if the task cannot be split, additional resources are allocated to the task by dynamically adjusting thread pool parameters (e.g., increasing the number of core threads). Simultaneously, the client dynamically adjusts the allocation strategy for subsequent tasks based on the task queue length and the idle status of each thread, ensuring that long-running tasks do not block the overall startup process. By collecting the execution time of asynchronous tasks in real time and dynamically identifying long-running tasks, this step can accurately pinpoint performance bottlenecks during startup. Through task splitting and dynamic thread allocation, the "long board effect" of a single long-running task dragging down the overall startup progress is effectively avoided, making the completion time of each task in the thread pool more balanced, thereby significantly reducing the total time spent in the startup phase and improving the user's waiting experience.

[0030] In some specific implementations, multiple key time-consuming nodes are defined during the target application startup process, including: application startup entry point, application initialization completion, first frame rendering of the advertising page, homepage data loading completion, and user interactivity (homepage swipe response). The current system timestamp is recorded at each node, and the timestamp difference between adjacent nodes is used as the time consumption data for the corresponding stage.

[0031] The client compares the above time-consuming data with the baseline data cached locally in real time. The baseline data can be the average time-consuming value of the three most recent stable versions. If the time-consuming stage (such as the ad page loading stage) exceeds the preset tolerance range of the baseline (e.g., more than 20%), it is determined that performance degradation has occurred.

[0032] In response to performance degradation, the client requests the latest configuration from the server or reads the locally pre-configured degradation strategy and dynamically adjusts the parallel loading strategy accordingly. For example, adjustments may include: rescinding unnecessary tasks in the homepage task that were originally executed in parallel with the ad page (such as preloading secondary page data) to be executed with a delay; or reducing the core number of threads in the thread pool to reduce resource contention; if severe task queuing in the thread pool is detected, dynamically increasing the core number of threads or increasing the task queue capacity. The adjusted strategy takes effect immediately for the execution of subsequent tasks.

[0033] By collecting time-consuming data from key nodes and comparing it with a baseline, quantitative monitoring and degradation identification of startup performance were achieved. A closed-loop feedback mechanism was formed by dynamically adjusting parallel loading strategies or thread pool configurations based on the collected time-consuming data for each startup stage. This mechanism enables the application to adapt to different operating environments (such as low-end devices, high-load systems, network fluctuations) and performance regressions introduced by new versions, effectively preventing the accumulation of startup performance degradation and improving the long-term stability of the application and the consistency of user experience.

[0034] The technical solution of this disclosure, by collecting the execution time of asynchronous tasks during the startup task of the target application and dynamically allocating long-running tasks in the thread pool, can alleviate the "long board effect" in the initialization of basic services and avoid a single task blocking the overall startup process. By collecting the time consumption data of each startup stage, it can achieve quantitative monitoring of startup performance and accurate location of degradation stages. Furthermore, based on the time consumption data of each startup stage, it can dynamically adjust the parallel loading strategy or thread pool configuration for tasks that have not yet been executed in the current startup, forming a closed-loop mechanism of "real-time optimization - data collection - feedback iteration". The three steps are organically linked. Compared with the static and one-time optimization schemes in the prior art, this disclosure enables the application to adaptively and continuously optimize the startup strategy, systematically shorten the application startup time, and improve the stability of startup speed and the consistency of user experience.

[0035] In some embodiments, the method further includes: in response to a launch event for the target application, if the target application is cold-started, loading the advertising page and the homepage of the target application in parallel.

[0036] In this embodiment, a cold start refers to a startup method where the application process does not exist in system memory. When a user clicks the application icon for the first time or launches the application via an external link, the system needs to recreate the application process, load and initialize application resources (such as the Application object, main thread, class loader, etc.). Cold starts are the most time-consuming and usually require complete startup optimization. For example, opening a cloud storage application for the first time after a user restarts their phone, or opening the application again after manually clearing the application's background process in the task manager, both fall under cold start scenarios. In these cases, the application needs to perform complete processes such as ad loading and homepage initialization.

[0037] In this embodiment of the disclosure, the advertising page refers to a splash screen advertisement that appears before the homepage when a user launches the application. This page is typically used for brand promotion, event advertising, or commercial display, and the displayed content can be static images, dynamic videos, or interactive pages. The advertising page closes automatically after displaying, or closes in response to the user's skip action, and then the user is redirected to the application's homepage. For example, when a cloud storage application launches, a static image with the slogan "Lightning-Fast Transfer" is first displayed, with a "Skip" button below the image. After 3 seconds, the user is automatically redirected to the homepage. The interface containing this static image is the advertising page.

[0038] In this embodiment, the homepage refers to the main functional interface of the application, the core page that the user ultimately reaches after launching the application. The homepage typically includes elements such as the application's main function entry points, a content list, and user information, serving as the starting point for user interaction with the application. For example, the homepage of a cloud storage application might include a file list, upload / download buttons, a photo backup entry point, and a user center entry point. The user sees this homepage after the advertisement page ends.

[0039] In this embodiment, parallel loading refers to changing two or more loading tasks that were originally dependent or executed sequentially to be executed concurrently within the same time period, thereby shortening the overall waiting time. In this solution, parallel loading specifically refers to simultaneously executing the resource fetching / rendering of the ad page and the layout creation / data prefetching of the homepage during the startup phase. Under the traditional sequential loading method, the loading and display of the ad page must be completed first (e.g., 2 seconds) before the creation of the homepage view begins (e.g., 1 second), for a total time of 3 seconds. With parallel loading, while the ad page is loading, the background thread synchronously performs the homepage view creation and data prefetching. When the ad display ends, the homepage is ready, and the user does not need to wait additionally.

[0040] In some specific implementations, in response to a launch event triggered by a user clicking the cloud drive application icon, the client creates two independent loading tasks in parallel and submits them to a shared thread pool via the initialization method of the launch activity component. The first task is responsible for loading the ad page: this includes initiating a network request to the ad server to retrieve ad creatives (images or videos using Uniform Resource Locators, URLs), rendering and displaying them on the interface after downloading, and starting the countdown logic. The second task is responsible for loading the homepage: this includes creating the homepage's root view (such as a FrameLayout), initializing the homepage's Fragment container, and preloading the basic data required for the homepage (such as file list cache and user information). The two tasks execute concurrently in the thread pool without blocking each other. The client coordinates the completion order of the two tasks using concurrency tools to ensure synchronization and seamless loading of the ad page and homepage: after the ad page display ends (the countdown ends or the user clicks skip), the prepared homepage is displayed directly without waiting for the homepage creation process. If the homepage task is completed ahead of schedule, wait for the end signal of the ad page; if the homepage is not completed when the ad page ends, continue to complete the homepage loading and display it immediately to ensure that users do not see a blank or laggy interface.

[0041] In this way, by loading the ad page and the homepage in parallel, the drawback of the traditional serial loading mode, where ads completely block homepage creation, is overcome. This allows the homepage view creation and data prefetching to occur simultaneously within the few seconds of ad display. Compared to serial loading, this step can shorten the actual waiting time from when the user clicks the icon to when they see the homepage (the specific time depends on the ad display duration and homepage loading time), significantly improving the smoothness of the startup process, while avoiding the undesirable phenomenon of a white screen or loading message after the ad ends due to homepage loading delays.

[0042] In some embodiments, loading the target application's ad page and homepage page in parallel includes: removing the independent activity component where the ad page is located; migrating the business implementation of the ad page from the independent activity component to a fragment component; and embedding the fragment component into the main activity component for priority loading.

[0043] In this embodiment, the Activity component is one of the four main components provided by the Android operating system, used to provide a screen interface that can be interacted with by the user. Each Activity has an independent lifecycle and task stack management, and typically one page corresponds to one Activity. For example, the "login page" of a cloud storage application corresponds to a LoginActivity, and the "file list page" corresponds to a MainActivity. Each Activity is an independent interface container.

[0044] In this embodiment, an independent activity component refers to an Activity specifically designed to host an advertising page, without containing other business functions. In traditional launch schemes, this Activity is created separately to display the advertisement, and the homepage Activity is launched only after the advertisement ends; the two are different Activity instances. For example, the launch page is an independent page component containing only the logic for playing the advertisement image or video. After the advertisement display ends, a page navigation command switches to the homepage.

[0045] In this embodiment, the main activity component refers to the main Activity where the application's homepage is located, which is usually also the core interface container of the application. In this solution, the main activity component is used to carry the homepage content and also serves as the host container for advertising pages. For example, MainActivity is the homepage Activity of a cloud storage application, which contains core user interface (UI) elements such as the file list and bottom navigation bar.

[0046] In this embodiment, a Fragment is a modular UI component provided by Android that can be embedded in an Activity. It has its own lifecycle and layout, but must be attached to an Activity to exist. Fragments are lighter than Activities, making them easier to add, remove, and reuse dynamically. For example, AdFragment is an implementation class for an advertising page, containing the logic for displaying advertising images and a countdown control. This Fragment can be dynamically added to a container (such as a FrameLayout) within MainActivity.

[0047] In this embodiment of the disclosure, migration refers to transferring functionality, code, or business logic originally belonging to one component to another component, while simultaneously removing the original component. In this solution, migration specifically refers to transferring all code and resources related to ad display, countdown, skip, etc., from an independent advertising Activity to the homepage Activity.

[0048] In this embodiment of the disclosure, embedding refers to dynamically adding a Fragment component to the view hierarchy of an Activity, making it part of the Activity's interface. After embedding, the content of the Fragment will be displayed within the container area specified by the Activity.

[0049] In some specific implementations, during the code refactoring phase, developers remove the original standalone ad campaign component and its corresponding layout and manifest files. The code responsible for ad retrieval, display, countdown, and skipping logic in the original standalone ad campaign component is migrated to the homepage campaign component, and this logic is encapsulated as a fragment component. A view container to hold the ad is added to the layout file of the homepage campaign component. In the creation method of the homepage campaign component, a transaction is started via the fragment manager to dynamically add the ad fragment component instance to this container, and this fragment component is set as the priority loading view, placing it at the top of the view hierarchy, covering the original homepage content. Simultaneously, the lifecycle callbacks of the homepage campaign component are adjusted so that after the ad fragment component finishes displaying (countdown ends or the user clicks skip), a transaction to remove the fragment component is executed, exposing the homepage content to the user. Through this method, the ad page no longer exists as a standalone campaign component, but rather as a dynamically removable fragment component within the homepage campaign component, loaded with priority.

[0050] Thus, by removing the independent campaign component containing the ad page and migrating its functionality to the main campaign component, while converting the ad functionality from the campaign component to a fragment component and embedding it into the homepage, this step reduces the system resource overhead caused by creating and destroying independent ad campaign components, and alleviates task stack jumps and animation delays when switching between campaign components. The lightweight nature of the fragment component makes loading and removing ad pages more efficient, and since the ad and homepage share the same campaign component instance, a smooth transition between ad display and homepage view creation is achieved, further shortening startup time and improving visual continuity during the transition between ad display and homepage.

[0051] In some embodiments, identifying and dynamically allocating long-running tasks in the thread pool based on execution time includes: performing statistical analysis on the execution time of asynchronous tasks to identify tasks whose execution time exceeds a preset threshold as long-running tasks; splitting long-running tasks into multiple short tasks and assigning the multiple short tasks to different threads in the thread pool for parallel execution; and dynamically adjusting the task allocation of each thread in the thread pool based on the task queue length and thread idle status.

[0052] In this embodiment, the preset threshold refers to a pre-defined time threshold used to determine whether an asynchronous task belongs to the category of "long-running tasks." This threshold can be dynamically set according to business needs, device performance statistics, or historical data, and is typically set to 200-500 milliseconds. Tasks exceeding this threshold are considered potential bottlenecks in startup performance. For example, based on extensive test data, the development team set the threshold to 300 milliseconds. If a database initialization task actually takes 380 milliseconds, it is marked as a long-running task; another configuration read task takes 50 milliseconds, and therefore does not belong to the category of long-running tasks.

[0053] In this embodiment of the disclosure, task splitting refers to the process of decomposing a logically large task that could not be executed concurrently into multiple independent, parallel-executable subtasks according to certain rules. The split subtasks should not have strong dependencies on each other to ensure the safety of parallel execution. For example, there was originally a serial task of "batch initializing 20 SDKs," which took a total of 800 milliseconds. By splitting it into four subtasks, each responsible for initializing five SDKs, and then assigning them to four threads for parallel execution, the total time is reduced to approximately 200 milliseconds (ignoring thread switching overhead).

[0054] In this embodiment of the disclosure, a short task is defined in contrast to a long-running task, referring to a subtask that has been split and has a shorter expected execution time (usually much shorter than a preset threshold). Short tasks are characterized by their rapid completion, making them convenient for concurrent execution with other tasks in a thread pool. For example, a task that loads 100 image thumbnails at once can be split into 10 short tasks, each loading 10 thumbnails. The expected execution time of each short task is approximately 1 / 10 of the original task.

[0055] In this embodiment of the disclosure, the task queue is a container in the thread pool used to cache tasks waiting to be executed. When all core threads are busy, newly submitted tasks are placed in the task queue for queuing. The task queue length is the number of tasks currently waiting to be executed in the queue. For example, if the thread pool has 4 core threads and the task queue capacity is 20, and there are currently 4 tasks executing and 8 tasks waiting in the queue, then the task queue length is 8.

[0056] In this embodiment of the disclosure, the thread idle state refers to the waiting state of a worker thread in the thread pool when it has completed its current task and there are no tasks waiting to be processed in the task queue. A thread in the idle state can be reused to execute newly submitted tasks, or it can be reclaimed (if core thread timeouts are configured). For example, if there are 4 core threads in the thread pool, 3 of which are currently executing tasks, and 1 has completed its previous task and its queue is empty, then this thread is in the idle state and can be immediately assigned a new task.

[0057] In this embodiment of the disclosure, dynamically adjusting the task allocation of each thread in the thread pool includes: assigning new tasks or subtasks to be split to the most suitable thread based on the real-time task queue length and thread idle status to achieve load balancing. For example, when a thread is idle, tasks are preferentially assigned to it, and when the queue is too long, the task consumption speed is increased. For example, if it is detected that thread A in the thread pool has been idle for 2 milliseconds, while thread B is still executing a long task, newly generated short tasks are preferentially assigned to thread A to avoid thread A being idle, while relieving the burden on thread B.

[0058] In some implementations, during the startup of the thread pool, the client starts a lightweight monitoring thread that iterates through all executing and waiting tasks in the thread pool at fixed intervals (e.g., every 50 milliseconds), records the start timestamp of each task, and calculates its execution time in real time. When the actual execution time of a task first exceeds a preset threshold (e.g., 300 milliseconds), it is marked as a long-running task. For this long-running task, the client first determines whether it is divisible: if the task contains loop processing of independent data sets (e.g., iterating through 100 files to generate thumbnails), the original task is split into multiple shorter tasks according to a preset splitting granularity (e.g., processing 10 files at a time); if the task contains multiple independent initialization sub-operations (e.g., sequentially initializing a network library, an image library, and a log library), it is split into independent shorter tasks. The split shorter tasks are resubmitted to the same thread pool and executed in parallel by the idle threads of the thread pool. Meanwhile, the client monitors the task queue length and the busy / idle status of each worker thread in real time: when the task queue length exceeds 70% of the queue capacity, it indicates a serious backlog of tasks. In this case, the client dynamically increases the number of core threads (if the maximum number of threads has not been reached) to accelerate task consumption. When a thread is found to be idle for more than 10 milliseconds and there are still tasks waiting to be processed in the queue, the client prioritizes assigning the next task in the queue to that idle thread. The above monitoring and adjustment process continues until all started tasks have been completed.

[0059] In this way, by performing real-time statistical analysis on the execution time of asynchronous tasks and identifying long-running tasks, the bottleneck of startup performance can be accurately located. By splitting long-running tasks into multiple short tasks and distributing them to different threads for parallel execution, the overall startup process is effectively prevented from being blocked by a single long task, and the overall completion time of the tasks is significantly reduced. By dynamically adjusting the task allocation according to the task queue length and the idle state of the threads, the load of each thread in the thread pool is further balanced, avoiding the waste of resources caused by some threads being overloaded while other threads are idle, thereby maximizing the utilization of the system's multi-core processing capabilities and shortening the total time of the startup phase.

[0060] In some embodiments, the basic service components of the target application are instrumented and optimized, which includes at least one of the following: the routing table in the target application is generated and packaged into the target application at compile time; and read and write operations on shared preferences in the target application are configured to be performed through read and write methods of memory-mapped files.

[0061] In this embodiment of the disclosure, the routing table is a mapping data used to record the correspondence between page paths and target page components. The routing framework utilizes the routing table to implement page navigation and parameter passing.

[0062] In this embodiment of the disclosure, compile time refers to the stage where the source code is compiled into bytecode or machine code; runtime refers to the stage where the application is loaded into memory and executed. In traditional solutions, the routing table is dynamically generated at runtime by scanning all classes using reflection, which can take hundreds of milliseconds to seconds. To solve this problem, this disclosure moves the generation of the routing table to compile time.

[0063] In one specific implementation, during the compilation phase of the target application, developers introduce a custom compile-time plugin. This plugin registers a new route table generation task before the bytecode transformation task or resource processing task. The plugin recursively traverses all compiled class files using a bytecode manipulation framework, parsing the annotation information of each class file. When a pre-defined route annotation is detected on a class, the plugin extracts the path string and the fully qualified name of the corresponding target class from the annotation, temporarily storing them as key-value pairs in a memory-mapped table. After scanning, the plugin serializes this mapping table into a route table file in text format (e.g., object notation) and packages it into the application's resource directory. Simultaneously, the plugin adds a constant to the automatically generated mapping helper class, pointing to the storage path of the route table file.

[0064] When the target application is running, the route initialization task in the startup thread pool directly reads the pre-generated route table file through the resource manager and deserializes it into a memory-mapped object for page navigation, thereby avoiding a full reflection scan at runtime.

[0065] In this embodiment, Shared Preferences is a lightweight key-value pair storage method provided by the Android platform for storing application configuration information. However, it suffers from lock contention in a multi-threaded environment, and each write operation triggers disk I / O, resulting in low efficiency. Memory-mapped files are a technique that directly maps disk files to the virtual memory address space of a process. Read and write operations are directly mapped to memory read and write, eliminating the need for system calls and achieving extremely high I / O performance.

[0066] To improve read / write efficiency during the startup phase, this disclosure replaces read / write operations of shared preferences with read / write operations of memory-mapped files through instrumentation. Specifically, at the bytecode level, all read and write method calls to shared preferences are intercepted by a bytecode manipulation framework, redirecting the call targets to a high-performance key-value store based on memory mapping. For example, calls to obtain a shared preferences instance are replaced with calls to obtain a memory-mapped key-value store instance, and subsequent commit operations are replaced with write and synchronization operations to the memory-mapped key-value store. The above instrumentation optimizations can be performed selectively or simultaneously, depending on the configuration.

[0067] Thus, by moving routing table generation from runtime to compile time, the time-consuming operation of fully scanning the code every time the application starts can be avoided, saving hundreds of milliseconds to seconds of initialization time. By replacing shared preferences with a high-performance key-value store based on memory-mapped files, multi-threaded lock contention and disk I / O blocking issues can be alleviated, resulting in a several-fold improvement in read and write performance. The above instrumentation optimizations, together with dynamic thread pool allocation, fundamentally reduce the number of long-running tasks that need to be processed and improve the execution efficiency of the remaining tasks, thereby shortening the startup time on multiple levels.

[0068] In some embodiments, instrumentation optimization further includes setting non-essential content provider components in the target application to lazy loading mode; wherein only core content provider components are loaded during the startup phase, and non-essential content provider components are initialized on the first invocation.

[0069] In this embodiment, the ContentProvider component is one of the core components provided by the Android operating system, primarily used for data sharing and access management between or within applications. Each content provider can be registered in the manifest file and automatically initialized when the application starts (before the application instance is initialized), completing operations such as database creation and data preloading. For example, a content provider for managing user account data will create a database table at startup; a content provider for caching images will initialize a disk cache directory at startup. These content providers are all automatically instantiated by the system during the application startup phase, and their initialization methods are called.

[0070] In this embodiment of the disclosure, non-essential content providers refer to those that are not immediately used by the homepage or other core business functions after the application starts. The initialization of these content providers can be delayed until the user first accesses the relevant function, rather than being completed during the startup phase. For example, a content provider supporting push notifications is only needed when the user registers for the push service after logging in; a content provider for data tracking and reporting is only needed when the user generates a behavioral event. Initializing these content providers during the startup phase does not affect the display of the homepage, and therefore they are considered non-essential components.

[0071] In this embodiment, core content providers refer to those content providers that the application must rely on before the homepage is displayed or the user interacts with it for the first time after startup. The data or services provided by these content providers are prerequisites for the normal operation of the homepage and must be initialized during the startup phase. For example, a content provider used to store the user's login status requires the homepage to read the current user information to display the avatar and nickname; a content provider used to cache a list of files requires the homepage to load the directory structure from it. These content providers are core components and must be loaded during the startup phase.

[0072] In this embodiment, lazy loading is a delayed initialization strategy, meaning that objects or components are not created and initialized immediately upon system startup, but only when they are first actually called or used. Lazy loading can save resource overhead during the startup phase and shorten startup time. For example, if a non-essential content provider is configured for lazy loading, it will not be instantiated when the system starts; its initialization method will only be triggered to load the content provider when the user first clicks the "View Image" button and needs to access its data.

[0073] In some specific implementations, developers add custom attributes to each registered content provider node in the target application's manifest file to mark whether the content provider is lazy-loaded. Simultaneously, the application context attach method is overridden in the application's custom application instance class, using bytecode manipulation or interception techniques to intercept the automatic initialization process of content providers during system startup. Specifically, by intercepting the content provider installation method in the system component management class, a list of content providers about to be initialized by the system is obtained. This list is traversed, and unnecessary content provider components are identified based on preset markers in the manifest file and removed from the initialization list. Only core content provider components (e.g., those marked as non-lazy-loaded or without any markers) are retained and allowed to be initialized normally by the system. For the removed unnecessary content providers, an interceptor is set up in the application's global data access call layer using dynamic proxy technology. When the first data access request for a certain unnecessary content provider is detected, lazy initialization is triggered: the content provider is dynamically instantiated and its initialization method is called, then it is registered in the system component manager, and finally the original request is forwarded to the newly instantiated content provider for processing. Subsequent access to this content provider will be directly routed to the already initialized instance, without the need for repeated initialization.

[0074] Thus, by setting non-essential content provider components to lazy loading mode, full initialization of all content provider components during startup can be avoided, significantly reducing unnecessary work performed by the system in the early stages of application startup. This optimization is particularly suitable for providers used only in specific business scenarios (such as push notifications, event tracking, and third-party statistics). Meanwhile, by retaining core content provider components for startup loading, the data services necessary for homepage display remain available, without affecting the integrity of normal functionality. This lazy loading mode, in conjunction with optimizations for compile-time route table generation and / or shared preference replacement, collectively reduces initialization overhead during startup and improves overall startup performance.

[0075] In some embodiments, time-consuming data of the target application at each startup stage is collected, including: time-consuming data of the application initialization node, the advertising page loading node, the home page loading node, and the user-interactive node.

[0076] In this embodiment of the disclosure, the application initialization node refers to the point in time from when the user triggers application startup to when the application instance object is created and its initialization callback method is executed. This node indicates that the application-level basic environment (such as logging system, global configuration, exception handling) is ready. For example, the timestamps of the start and end of application context attachment, as well as the timestamps of the start and end of the application instance initialization method, are recorded, and the time consumed in these two intervals is used as the time consumed in the application initialization phase.

[0077] In this embodiment of the disclosure, the ad page loading node refers to the point in time from the start of creating the view of the ad page to the first time the ad content is drawn onto the screen. This node indicates that the user is already able to see the ad image or video. For example, the start time is recorded at the beginning of the view creation method of the ad fragment, and the end time is recorded at the global layout listener callback of the ad image in the view creation completion callback. The difference between the two is the ad page loading time.

[0078] In this embodiment of the disclosure, the homepage loading node refers to the point in time from the start of creating the homepage's view structure to the completion of loading the core data of the homepage and the first presentation of the list or content. This node indicates that the user can already see the basic framework and some content of the homepage. For example, the start time is recorded at the beginning of the main interface creation method, and the end time is recorded after the list view adapter inside it first completes data binding and triggers an update.

[0079] In this embodiment of the disclosure, the user-interactive node refers to the point in time when the homepage has been fully loaded and the user can click, swipe, or perform other operations on the controls on the interface (such as buttons and list items). This node is the final milestone in the startup process, indicating that the application is fully usable. For example, listening to the window focus change callback of the homepage root view indicates that the user can interact with the interface when it gains focus; or listening to the layout completion event of the list view to ensure that all views have been measured and laid out.

[0080] In this way, by collecting time-consuming data of key nodes such as application initialization, ad loading, homepage loading, and user interaction, the startup process can be finely broken down and quantitatively monitored, making the performance bottleneck location more precise from the vague "slow overall startup" to the specific stage of degradation.

[0081] In some embodiments, the parallel loading strategy or thread pool configuration is dynamically adjusted based on the time consumption data of each startup phase, including: comparing the collected time consumption data with preset baseline data to identify performance degradation phases; receiving dynamic adjustment configuration information sent by the server when a performance degradation phase is identified; and adjusting the number of parallel tasks in the parallel loading strategy or the number of core threads in the thread pool based on the dynamic adjustment configuration information.

[0082] In this embodiment of the disclosure, the baseline data refers to a pre-set standard time consumption value used as a performance comparison reference. The baseline can be set based on the average time consumption of historical stable versions or the upper limit of acceptable performance for the business, and is used to determine whether the startup performance of the current version has degraded. For example, the average time consumption of the application initialization node of the three most recent online stable versions, 150 milliseconds, is taken as the baseline; if the application initialization node consumption of the current version exceeds 120% of 150 milliseconds (i.e., 180 milliseconds), it is considered degraded.

[0083] In this embodiment of the disclosure, the performance degradation stage refers to the stage in the entire startup process where the time taken for one or more sub-stages significantly exceeds the baseline data. Identifying the specific degradation stage helps to pinpoint the root cause of the problem (such as slower loading due to an upgrade of the advertising SDK, or the addition of encryption logic during database initialization), thereby enabling targeted optimization. For example, if the monitoring dashboard shows that the time taken for the "homepage loading node" suddenly increases from the historical average of 200 milliseconds to 500 milliseconds, then this stage is marked as a performance degradation stage, prompting developers to check the homepage data prefetching logic or thread blocking.

[0084] Initialize a global performance monitoring manager at the entry point of the target application's startup code. This manager has four built-in key timestamp recording points: First, a first timestamp is recorded when the application's base context attachment begins execution, and a second timestamp is recorded when the application creation callback method completes execution. The difference between the second and first timestamps is calculated as the application initialization node time. Second, a third timestamp is recorded when an ad page fragment is created, and a fourth timestamp is recorded when the ad view completes its layout and rendering for the first time. The difference between the fourth and third timestamps is calculated as the ad page loading node time. Third, a fifth timestamp is recorded when a homepage activity component is created, and a sixth timestamp is recorded when the homepage's root view completes its data population and drawing for the first time. The difference between the sixth and fifth timestamps is calculated as the homepage page loading node time. Fourth, a seventh timestamp is recorded when the window gains focus in the homepage activity component's window focus change callback method. The difference between the seventh and sixth timestamps is calculated as the user-interactive node time.

[0085] The monitoring manager assembles the time-consuming data from the four nodes, along with information such as device model, application version number, and system version, into a structured data format and reports it to the server-side monitoring dashboard via asynchronous network requests. Simultaneously, the client locally caches the latest baseline data. After each data collection, the client compares the time-consuming data of the current node with the corresponding baseline: if the time-consuming data of a node exceeds the baseline's set tolerance range, a degradation flag is appended to the node's reported data, and local logging is triggered to facilitate problem localization. Upon receiving the data, the server-side monitoring dashboard aggregates and displays the time-consuming curves of each node by version and device dimension, automatically marking degradation stages and issuing alarms.

[0086] In this embodiment, the dynamically adjusted configuration information sent by the server refers to a set of remotely updatable parameters calculated or preset in real time by the cloud server based on the client's startup performance data (such as the time consumed at each stage, device model, and system version). This configuration is pushed to the client via Hypertext Transfer Protocol (HTTP) / Hypertext Transfer Protocol Secure (HTTPS), taking effect without requiring the user to update the application version, and is used to dynamically adjust local startup optimization strategies. For example, if the server detects that a large number of low-end devices report excessive homepage loading times, analysis reveals that the cause is insufficient core threads in the thread pool, leading to task queuing. The server then sends data containing adjusted configuration information, such as increasing the core thread count to a set value and increasing the maximum number of tasks executed simultaneously to a set value. Upon receiving this, the client immediately adjusts the thread pool parameters.

[0087] In this embodiment, the number of tasks executed in parallel refers to the maximum number of startup tasks that can be executed concurrently at the same time. This parameter is determined by the parallel loading strategy and affects the resource consumption during the parallel execution of multiple tasks. Properly setting the concurrency level can balance CPU load and task completion efficiency, avoiding performance degradation due to excessively high concurrency leading to increased resource contention. For example, if the initial concurrency level is set to 4, it means that a maximum of 4 startup tasks can be executed in the thread pool simultaneously. When an increase in startup time is detected, the server-side configuration adjusts the concurrency level to 2, reducing resource contention and lowering the context switching overhead for each task, thereby accelerating the overall completion time.

[0088] In this embodiment, the core thread count refers to the number of worker threads that are always alive in the thread pool, even if these threads are idle, they will not be reclaimed. The core thread count determines the basic processing capacity of the thread pool. Increasing the core thread count can improve task parallelism, but it will also increase memory usage and CPU context switching overhead. For example, the thread pool is initially set to have 4 core threads and a maximum of 8 threads. When the server issues a configuration to adjust the core thread count to 6, the thread pool will immediately create 2 new core threads (if the current thread count is less than 6), thereby improving parallel processing capacity; when the workload decreases, the extra threads will not be reclaimed, maintaining stable processing capacity.

[0089] In the startup performance monitoring module of the target application, a configuration receiver is set up. After each startup, this receiver packages the collected time-consuming data for each node (such as application initialization, ad loading, homepage loading, and user interactivity) along with device information (model, memory size, number of CPU cores) and the current application version number, and sends it to the server's configuration interface. The server generates dynamically adjusted configuration information based on a pre-defined rule engine (e.g., triggering a degradation strategy if homepage loading time exceeds a set value and device memory is less than a set value) or based on real-time test results. This configuration contains the following adjustable parameters in a structured data format: maximum number of parallel tasks, core thread count of the thread pool, maximum number of threads, task queue capacity, etc. The client receives the configuration via long-connection polling or push channel. When the configuration receiver receives a new configuration, it immediately verifies the configuration's validity (e.g., parameter range, signature). If valid, it stores it in the local cache and marks the effective time. When launching tasks, the launch manager prioritizes reading dynamically adjusted configuration information from the local cache, overriding the default static configuration. During thread pool initialization, it creates the thread pool based on the core and maximum thread counts configured. When submitting parallel tasks (such as ad loading or homepage loading), it uses semaphores or a custom rate limiter to control the maximum number of parallel tasks, ensuring that the number of concurrent tasks does not exceed the configured value. If the configuration includes adjustments to multiple parameters, the client applies them sequentially according to priority: first adjusting the core thread pool parameters, then adjusting the task concurrency. Simultaneously, the client records the effective configuration version and adjustment logs for subsequent performance evaluation.

[0090] Thus, by receiving dynamically adjusted configurations from the server, this step enables remote control and dynamic iteration of startup optimization strategies. Fine-tuning can be performed for different device models and operating environments without waiting for application version releases. For example, for low-end models, the number of parallel tasks can be reduced to alleviate CPU contention, while for high-end models, the number of core threads in the thread pool can be increased to fully utilize multi-core performance. Combined with time-consuming data collection and comparison, this step forms a real-time closed loop of "collection-identification-deployment-adjustment," enabling the application to adaptively correct performance degradation on tasks not yet executed during startup, significantly reducing the long tail of startup time and improving user experience consistency and satisfaction. Compared to static preset strategies, this dynamic adjustment mechanism greatly improves the flexibility and coverage of optimization strategies.

[0091] In some embodiments, the parallel loading strategy may further include at least one of the following: the types of tasks to be executed in parallel, the priority of tasks to be executed in parallel, and the dependencies between tasks to be executed in parallel.

[0092] In this embodiment, task type refers to the category identifier obtained after classifying startup tasks according to function or business type. Different types of tasks have different dependencies, resource requirements, and timeliness requirements in the startup process. The parallel loading strategy can specify which types of tasks can be executed in parallel and which must be executed serially or with a delay. For example, startup tasks can be divided into "network request type" (such as ad retrieval, configuration update), "UI rendering type" (such as homepage view creation, ad view rendering), "data prefetching type" (such as file list caching, user information loading), and "SDK initialization type" (such as push SDK, event tracking SDK). The strategy can be set such that ad retrieval (network type) and homepage view creation (UI type) can be executed in parallel, while before the ad is displayed, homepage data prefetching (depending on network type) can be executed in parallel with the ad countdown, but homepage user interaction can only respond after the data prefetching is completed.

[0093] In this embodiment, task priority refers to the relative importance or urgency assigned to each initiated task, used for decision-making in the thread pool or scheduler: when multiple tasks are waiting to be executed, tasks with higher priority are allocated thread resources first or executed first. Priority can prevent tasks on the critical path from being delayed due to blocking by low-priority tasks. For example, "ad first frame rendering" is set to high priority, "homepage skeleton layout" is set to medium priority, and "secondary page preloading" is set to low priority. When thread pool resources are scarce, high-priority tasks will preempt or be scheduled first to ensure that users see the ad as soon as possible; low-priority tasks can be postponed until the ad display ends.

[0094] In this embodiment, task dependencies refer to the fact that the execution of certain tasks depends on the results or states of other tasks. Dependencies are typically directional; for example, task B can only begin execution after task A is completed. In a parallel loading strategy, explicitly defining dependencies ensures the correctness of task scheduling and avoids errors or data inconsistencies caused by disordered execution. For example, the "display ads" task depends on the result of the "fetch ad creatives" task, and "homepage data rendering" depends on the completion of the "homepage data prefetching" task. A dependency graph can be defined in the strategy, and the scheduler automatically determines the task startup timing based on dependencies: subsequent tasks can only start after all preceding tasks are completed, while tasks that do not depend on each other can be executed in parallel.

[0095] In the target application's startup scheduling center, metadata is configured for each startup task, including task type (e.g., network, UI, data), priority (e.g., high, medium, low), and dependency list (e.g., "homepage rendering" depends on "data prefetching completion"). The parallel loading strategy defines this information in the form of configuration files or code annotations and is parsed by the scheduler at startup. The scheduler groups tasks according to type: tasks of the same type without mutual dependencies are grouped into the same batch for parallel execution, while tasks of different types that can be parallelized (e.g., network and UI tasks) are assigned to different threads. The priority mechanism is implemented through a priority queue in the thread pool: when multiple tasks are ready simultaneously, the scheduler prioritizes scheduling high-priority tasks, ensuring that critical paths (e.g., ad display) are not blocked by low-priority tasks. Dependencies are implemented through counters or listeners: each task maintains a dependency count; the task is submitted to the thread pool only when the count reaches zero after all dependent tasks are completed. The scheduler dynamically adjusts parameters during runtime: for example, when ad display delays are detected, the priority of ad rendering-related tasks is temporarily increased, or the priority of unnecessary preloading tasks is decreased.

[0096] Thus, by further defining task types, priorities, and dependencies in the parallel loading strategy, we can more finely control task scheduling behavior during the startup phase, reducing resource contention or logical errors caused by simple concurrency. Task classification allows different types of tasks (such as network, UI, and data) to be combined and executed in parallel as needed, improving resource utilization efficiency; the priority mechanism ensures that critical path tasks (such as the first frame of an advertisement and the homepage skeleton) are executed promptly, reducing the user's perceived waiting time; dependency management guarantees the correct order of task execution, avoiding data loss or interface anomalies caused by out-of-order execution. The combination of these methods with a real-time adjustment mechanism enables the parallel loading strategy to dynamically adapt to complex business needs and operating environments, further shortening startup time and improving stability.

[0097] In some embodiments, the application launch optimization method includes: in response to the target application being launched via an external link or protocol, determining whether the target redirect page is strongly associated with the advertising business; if there is no strong association, skipping the loading and display of the advertising page and directly entering the target redirect page.

[0098] In this embodiment of the disclosure, an external link refers to a Uniform Resource Locator (URL) from outside the target application, typically provided by other applications, web pages, SMS messages, push notifications, or other channels. After a user clicks the link, the operating system attempts to open the corresponding target application based on the link's protocol (HTTP / HTTPS) and redirects the user to the specified page. For example, if a user sees a cloud storage sharing link in their browser, clicking it will launch the cloud storage application and directly take them to the file details page, rather than the application's homepage.

[0099] In this embodiment of the disclosure, the protocol (or custom protocol) is a mechanism for implementing page navigation and data transfer in mobile applications. Applications can register custom URLs, which other applications or web pages can use to launch the application and pass parameters. For example, a cloud storage application registers the "pan: / / " protocol. When a user clicks an external link such as "pan: / / open?file_id=123", the operating system launches the cloud storage application and passes the parameter "file_id=123" to it. The application then navigates to the corresponding file preview page based on this parameter.

[0100] In this embodiment of the disclosure, "launching" refers to the process by which the operating system starts or wakes up a target application based on an external link or protocol, and passes the parameters in the link to the application. Launching can be a cold start (application not running) or a warm start (application in the background). For example, if a user clicks a link in a text message, and the cloud storage application is not running, the system first creates the application process and then opens it; if it is already in the background, it is switched to the foreground and the redirect is handled.

[0101] In this embodiment of the disclosure, the target redirect page refers to a specific page that is intended to be opened directly by an external link or protocol, rather than the application's default advertising page or homepage. This page is typically an interface with a clear business intent, such as a file details page, an event page, or a user homepage. For example, a file preview page launched via a share link, a message details page launched via a push notification, or a product event page launched via an advertisement.

[0102] In this embodiment, a strong association refers to a necessary dependency between the target redirect page and the advertising business; that is, the display of the advertisement is a prerequisite for the normal display of the redirect page or the completeness of its business logic. If no strong association exists, the advertisement display is not necessary and can be skipped to improve the user experience. For example, an activity page launched through an external advertising link is itself part of the advertisement; the advertisement material must be displayed before the activity content can be shown, thus demonstrating a strong association. Conversely, if a user directly views a file shared by another person through a shared link, and this file page has no direct relationship with the advertising business, then there is no strong association, and the user should skip the advertisement and go directly to the file page.

[0103] At the target application's launch entry point, the launch source information is parsed. Specifically, the intent object used to launch the application is obtained, its Uniform Resource Identifier (URI) and additional parameters are extracted, and the launch source category is determined: if the intent action is a view operation and the URI is not empty, it is determined that the application was launched via an external link or protocol. Next, the identifier of the target redirect page (e.g., page path, identifier, or route string) is extracted from the URI or parameters, and a locally pre-configured association table is queried (this table can be dynamically updated via the server). This configuration table defines which target pages have a strong association with the advertising business (e.g., activity landing page, ad landing page) and which pages do not have a strong association (e.g., file preview page, user homepage, settings page). If the query results show that the current target redirect page does not have a strong association, a global flag is set to indicate that the subsequent launch process should skip the loading, rendering, and display logic of the ad page and directly redirect to the target redirect page. If the target redirect page has a strong association, the normal ad loading process is maintained, and the redirection occurs after the ad is displayed. If it cannot be determined, the normal ad process is executed by default.

[0104] In this way, by parsing externally invoked links or protocols and determining whether to skip ads based on whether the target page is strongly related to the advertising business, this step avoids the extra waiting time and operational interference caused by forcibly displaying ads when users have clear page requests (such as viewing shared files or opening push notifications). For scenarios without strong correlation, users can directly enter the target page, shortening the startup path from "click link → ad display → target page" to "click link → target page," significantly improving the response speed and user experience in externally invoked scenarios, while not affecting the normal operation of business scenarios that require ad display (such as ad campaign pages), thus achieving a balance between ad display and fast user access.

[0105] In some embodiments, the application startup optimization method includes: if the target application is a hot start or is in the login / registration process, skipping the loading and display of the advertising page and directly entering the homepage.

[0106] In this embodiment of the disclosure, a warm start means that the application process still exists in system memory (i.e., the application is already running in the background). When the user switches back to the application, the system only needs to bring the application from the background to the foreground, without recreating the process or initializing the Application. A warm start typically does not display advertisements and directly restores the interface from when the user left. For example, if a user is using a cloud storage application, temporarily switches to another application to reply to messages, and then returns to the cloud storage application through multitasking or by clicking an icon, the application does not need to reload advertisements and the homepage; it directly displays the previously viewed file list interface.

[0107] In this embodiment of the disclosure, the login / registration process refers to the interactive process of a user registering an account when using the application for the first time, or an already registered user verifying their identity. For example, when a user opens the cloud storage application for the first time, they enter their account and password on the login page while not logged in; or a user has logged out and re-enters the login page. In these processes, the application should directly display the login / registration interface, rather than displaying an advertisement first and then redirecting the user.

[0108] At the target application's startup entry point, the current startup type and user status are first obtained. The startup type is determined by checking if the application process already exists, for example, by checking if the application's process ID is present in the system process manager, or by using a static flag variable to record whether it's the first startup. If the application process is newly created and hasn't undergone initialization, it's considered a cold start; otherwise, it's considered a warm start. The user status is determined by reading the locally stored user login identifier, such as login credentials or a user token. If no valid login information is stored, it's determined that the user is currently in the login / registration process.

[0109] For warm start scenarios, the launch manager directly redirects to the homepage (usually the last left page or the default homepage), completely skipping the loading and display logic of the ad page. For login / registration processes (regardless of whether the login state is lost during a cold start or a warm start), the launch manager also skips the ads, directly redirects to the login / registration page, and clears the pending queue of ad-related tasks. Only when the application is in a cold start state and the user is already logged in will the complete steps of loading the ad page and homepage in parallel be executed.

[0110] Thus, by distinguishing between cold starts and warm starts, and between login / registration processes and normal login startups, this step avoids executing the ad loading process in unnecessary scenarios (such as warm start recovery or user registration / login), effectively reducing user wait time and irrelevant information interference. For warm starts, users expect to quickly return to the previously viewed interface; skipping ads can reduce startup time from several seconds to milliseconds, significantly improving the experience. For login / registration processes, skipping ads allows users to complete account operations faster, avoiding process interruptions caused by ads. This compatibility handling, combined with parallel loading logic, ensures that ads are only displayed in scenarios where they are needed (cold start and already logged in), satisfying advertising business needs while optimizing startup efficiency in unnecessary scenarios.

[0111] Figure 2 This diagram illustrates a monitoring and parallel scheduling architecture for the application startup process, which is divided into two main parts: the monitoring layer and the client startup process.

[0112] The monitoring layer comprises four core modules: Time-consuming data collection: Responsible for collecting performance data at each stage of client startup.

[0113] Monitoring dashboard: Used to visually display the collected time-consuming metrics.

[0114] Anomaly Alarm: When an anomaly is detected (such as time exceeding the threshold), an alarm notification is issued.

[0115] Dynamic adjustment: affects the scheduling strategy of the parallel scheduling center.

[0116] The client startup process begins with the user clicking the icon and proceeds sequentially as follows: Application initialization: Completes the initialization of the application's basic environment.

[0117] The parallel scheduling center, as the core scheduling node, is responsible for coordinating the parallel execution of the following three modules: Advertising module: Performs ad retrieval and ad display.

[0118] Homepage module: Completes Activity creation and homepage loading.

[0119] Basic service module: includes thread pool management, ARouter route initialization, Provider / SP components, etc.

[0120] User-interactive: The final state is one where users can interact with the content.

[0121] The interaction between the monitoring layer and the startup process includes: time-consuming data collection from each stage of the client startup process, reporting to the monitoring dashboard; and anomaly alarms triggering dynamic adjustments that influence the scheduling strategy of the parallel scheduling center, forming a closed-loop optimization. Overall, this achieves observability, alarming, and adaptive adjustment of startup performance.

[0122] Figure 3 A flowchart illustrating thread pool load balancing and dynamic scheduling based on task latency analysis is shown below: The process starts with an asynchronous task queue. First, the task time is analyzed for the tasks in the queue. Based on the expected execution time, the tasks are divided into three levels: short tasks (<10ms), medium tasks (10-50ms), and long tasks (>50ms).

[0123] Subsequently, different types of tasks are assigned to different thread pools: short tasks go into a shared thread pool, medium tasks go into a regular thread pool, and long tasks go into a dedicated thread pool. This classification and isolation can prevent long tasks from blocking short tasks.

[0124] During task execution, the load monitoring module monitors the running status of each thread pool in real time and judges the thread load. When an overload is detected in a thread, a task migration mechanism is triggered to migrate some tasks to idle threads to achieve load balancing. If problems still exist after load balancing, the number of threads can be dynamically adjusted (e.g., increasing or decreasing the thread pool capacity).

[0125] Under normal circumstances, tasks are executed as originally assigned until the task is completed; if a task migration occurs, execution continues after the migration and eventually reaches the task completion state.

[0126] Overall, Figure 3 An adaptive asynchronous task scheduling strategy is described: by classifying tasks through time consumption analysis, isolating them with dedicated thread pools, monitoring real-time load, and dynamically migrating tasks and elastically scaling up / down the thread pool, the system can maintain efficient and balanced execution even under high concurrency or uneven task distribution.

[0127] Figure 4 This diagram illustrates a closed-loop architecture for monitoring and tuning to optimize application startup performance. The overall structure is top-leveled by a "tuning layer," which includes "advertising SDK iteration" as a proactive optimization measure. Below this are three core layers: Collection layer: Responsible for collecting key performance indicators during the startup process, including: Application initialization time, ad loading time, homepage loading time, and user interaction time.

[0128] Processing layer: Aggregates and analyzes the collected data, compares it with preset thresholds, and performs anomaly detection to identify performance degradation or bottlenecks.

[0129] Alarm layer: The results of the processing layer are visualized through a monitoring dashboard, and alarm notifications can be sent via instant messaging tools.

[0130] The overall process forms a closed loop from data collection, analysis and processing to alarm feedback. Combined with top-level adjustments such as "advertising SDK iteration", it enables continuous monitoring and dynamic optimization of application startup performance.

[0131] It should be understood that Figures 2 to 4 The schematic diagrams shown are merely illustrative and not limiting, and are scalable; those skilled in the art can use them as a basis. Figures 2 to 4 Even with various obvious changes and / or substitutions to the examples, the resulting technical solutions still fall within the scope of this disclosure.

[0132] This disclosure provides an application startup optimization device, such as... Figure 5As shown, the device may include: a task scheduling module 501, used to respond to a startup event for a target application, collect the execution time of asynchronous tasks during the execution of startup tasks, identify and dynamically allocate long-running tasks in the thread pool based on the execution time; a data acquisition module 502, used to collect the time consumption data of the target application at each startup stage; and a strategy adjustment module 503, used to dynamically adjust the parallel loading strategy or thread pool configuration based on the time consumption data of each startup stage for tasks that have not yet been executed in the current startup.

[0133] In some embodiments, the application startup optimization apparatus further includes: a parallel loading module 504 ( Figure 5 (not shown in the image) is used to respond to a launch event for the target application. If the target application is cold-started, the target application's advertising page and homepage are loaded in parallel.

[0134] In some embodiments, the parallel loading module 504 includes: a merging unit for removing the independent activity component where the advertising page is located; and a fragmentation unit for migrating the business implementation of the advertising page from the independent activity component to the fragment component, and embedding the fragment component into the main activity component for priority loading.

[0135] In some embodiments, the task scheduling module 501 includes: a time consumption identification unit, used to perform statistical analysis on the execution time of asynchronous tasks and identify tasks whose execution time exceeds a preset threshold as long-time tasks; a task splitting unit, used to split long-time tasks into multiple short tasks and allocate the multiple short tasks to different threads in the thread pool for parallel execution; and a dynamic allocation unit, used to dynamically adjust the task allocation of each thread in the thread pool according to the task queue length and the thread idle state.

[0136] In some embodiments, the application launch optimization apparatus further includes: a plug-in optimization configuration module 505 ( Figure 5 (Not shown in the image), used to perform instrumentation optimization on the underlying service components of the target application, the instrumentation optimization including at least one of the following: The routing table in the target application is generated and packaged into the target application during compilation. In the target application, read and write operations on shared preferences are configured to be performed via read and write operations on memory-mapped files.

[0137] In some embodiments, the instrumentation optimization configuration module 505 is further configured to: set non-essential content provider components in the target application to lazy loading mode, load only the core content provider components during the startup phase, and initialize the remaining provider components when they are first called.

[0138] In some embodiments, the instrumentation optimization configuration module 505 is further configured to intercept operations calling the shared preference read / write interface in the target application via instrumentation; and to delegate the intercepted read / write operations to a memory-mapped key-value store to perform data processing. In some embodiments, the strategy adjustment module 503 includes: a node collection unit, used to collect time consumption data of application initialization nodes, advertising page loading nodes, homepage page loading nodes, and user-interactive nodes.

[0139] In some embodiments, the strategy adjustment module 503 further includes: a comparison and identification unit, used to compare the collected time-consuming data with preset baseline data to identify the performance degradation stage; a configuration receiving unit, used to receive dynamic adjustment configuration information sent by the server when the performance degradation stage is identified; and a parameter adjustment unit, used to adjust the number of parallel tasks executed in the parallel loading strategy or adjust the number of core threads in the thread pool according to the dynamic adjustment configuration information.

[0140] In some embodiments, the application startup optimization device further includes: an external pull-up processing module 506 ( Figure 5 (Not shown in the image) is used to respond to the target application being launched via an external link or protocol, and to determine whether the target redirect page is strongly related to the advertising business; if there is no strong relationship, the loading and display of the advertising page is skipped, and the target redirect page is entered directly.

[0141] In some embodiments, the application startup optimization device further includes: a startup scene determination module 507 ( Figure 5 (Not shown in the image) is used to trigger the parallel loading module 504 to perform the operation of loading the advertising page and the homepage in parallel when the target application is in a cold start; when the target application is in a hot start or is in the login / registration process, the loading and display of the advertising page is skipped and the homepage is entered directly.

[0142] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0143] The application startup optimization device in this embodiment alleviates the "long board effect" during startup by collecting asynchronous task latency and dynamically allocating long-running tasks; simultaneously, it collects latency data for each stage to accurately pinpoint performance degradation phases; and then adjusts the parallel strategy or thread pool configuration of currently running tasks in real time, forming a real-time closed-loop feedback. Compared to static solutions, this disclosure can adaptively optimize startup strategies, systematically shorten startup time, and improve startup performance stability and user experience.

[0144] This disclosure provides a scenario illustration of an application startup optimization method, such as... Figure 6 As shown.

[0145] As previously described, the application startup optimization method provided in this disclosure is applied to electronic devices. Electronic devices are intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers.

[0146] Specifically, the electronic device may perform the following operations: In response to a startup event for the target application, during the execution of the startup task, the execution time of asynchronous tasks is collected, and long-running tasks in the thread pool are identified and dynamically allocated based on the execution time. The time data of the target application in each startup stage is collected, and the parallel loading strategy or thread pool configuration is dynamically adjusted based on the time data of each startup stage to be used for tasks that have not yet been executed in the current startup.

[0147] It should be understood that Figure 6 The scene diagrams shown are merely illustrative and not restrictive; those skilled in the art can interpret them based on... Figure 6 Even with various obvious changes and / or substitutions to the examples, the resulting technical solutions still fall within the scope of this disclosure.

[0148] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0149] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0150] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0151] like Figure 7As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded from storage unit 708 into random access memory (RAM) 703. The RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. An input / output (I / O) interface 705 is also connected to bus 704.

[0152] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0153] The computing unit 701 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as application startup optimization methods. For example, in some embodiments, the application startup optimization method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the application startup optimization method described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform an application startup optimization method by any other suitable means (e.g., by means of firmware).

[0154] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0155] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0156] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EPROM), flash memory, optical fiber, compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0157] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0158] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0159] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0160] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0161] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. An application startup optimization method, comprising: In response to a startup event for a target application, during the execution of the startup task, the execution time of asynchronous tasks is collected, and long-running tasks in the thread pool are identified and dynamically allocated based on the execution time. Collect time consumption data for each startup phase of the target application; Based on the time consumption data of each startup phase, the parallel loading strategy or thread pool configuration is dynamically adjusted to accommodate tasks that have not yet been executed during the current startup. The parallel loading strategy includes at least the number of tasks to be executed in parallel.

2. The method according to claim 1, wherein, Also includes: In response to a launch event for the target application, if the target application is in a cold start, the advertising page and homepage of the target application are loaded in parallel.

3. The method according to claim 2, wherein, The parallel loading of the target application's advertising page and homepage includes: Remove the standalone activity component containing the aforementioned ad page; The business implementation of the advertising page is migrated from the independent activity component to the fragment component, and the fragment component is embedded in the main activity component for priority loading.

4. The method according to claim 1, wherein, The step of identifying and dynamically allocating long-running tasks in the thread pool based on execution time includes: The execution time of the asynchronous tasks is statistically analyzed, and tasks whose execution time exceeds a preset threshold are identified as long-running tasks. The long-running task is split into multiple short tasks, and the multiple short tasks are assigned to different threads in the thread pool for parallel execution; The task allocation of each thread in the thread pool is dynamically adjusted based on the task queue length and thread idle status.

5. The method according to claim 1, wherein, The basic service components of the target application have undergone instrumentation optimization, which includes at least one of the following: The routing table in the target application is generated and packaged into the target application during compilation. The read / write operations for shared preferences in the target application are configured to be performed via read / write operations on memory-mapped files.

6. The method according to claim 5, wherein, The instrumentation optimization further includes setting non-essential content provider components in the target application to lazy loading mode; wherein, only the core content provider components are loaded during the startup phase, and the non-essential content provider components are initialized when they are first called.

7. The method according to claim 1, wherein, The collection of time-consuming data for each startup phase of the target application includes: Collect time data for application initialization nodes, advertising page loading nodes, homepage loading nodes, and user-interactive nodes.

8. The method according to claim 7, wherein, The step of dynamically adjusting the parallel loading strategy or thread pool configuration based on the time consumption data of each startup phase includes: The collected time-consuming data is compared with the preset baseline data to identify the stage of performance degradation. Upon identifying the performance degradation stage, receive dynamic adjustment configuration information from the server; Based on the dynamically adjusted configuration information, the number of tasks executed in parallel in the parallel loading strategy can be adjusted, or the number of core threads in the thread pool can be adjusted.

9. The method according to claim 1, wherein, The parallel loading strategy also includes at least one of the following: the types of tasks to be executed in parallel, the priority of tasks to be executed in parallel, and the dependencies between tasks to be executed in parallel.

10. The method according to claim 2, wherein, Also includes: In response to the target application being launched via an external link or protocol, determine whether the target redirect page is strongly related to the advertising business; If there is no strong association, the loading and display of the advertisement page will be skipped, and the user will directly enter the target redirect page.

11. The method according to claim 2, wherein, Also includes: If the target application is in a hot start or is in the login / registration process, skip the loading and display of the advertising page and go directly to the homepage.

12. An application startup optimization device, comprising: The task scheduling module is used to respond to the startup event of the target application. During the execution of the startup task, it collects the execution time of the asynchronous task, identifies and dynamically allocates long-running tasks in the thread pool based on the execution time. The data acquisition module is used to collect the time consumption data of the target application at each startup stage; The strategy adjustment module is used to dynamically adjust the parallel loading strategy or thread pool configuration based on the time consumption data of each startup stage, so as to use the tasks that have not yet been executed in the current startup. The parallel loading strategy includes at least the number of tasks to be executed in parallel.

13. An electronic device, comprising: At least one processor; as well as A memory that is communicatively connected to at least one processor; wherein, The memory stores instructions that can be executed by at least one processor to enable the at least one processor to perform the method of any one of claims 1-11.

14. A non-transitory computer-readable storage medium storing computer instructions, wherein, Computer instructions are used to cause a computer to perform the method according to any one of claims 1-11.

15. A computer program product comprising a computer program stored on a storage medium, wherein the computer program, when executed by a processor, implements the method according to any one of claims 1-11.

Images