Android launcher multi-dimensional preloading and parallel starting method and system

Abstract

The application relates to the technical field of operating system startup optimization, and discloses an Android Launcher multi-dimensional preloading parallel startup method and system, which aims to solve the problem that the existing Android device has a relatively long first screen display time, and mainly comprises the following steps: an APK static precompilation step, in which hot code in a.dex file of the Launcher is precompiled into local machine code through AOT compilation technology; an asynchronous parallel service pulling-up step, in which non-key services are submitted to a fixed thread pool for parallel execution, so that the Launcher main thread quickly enters the onResume; a FIFO dynamic priority scheduling step, in which a high / ordinary double queue is constructed, a priority score of a resource loading task is calculated, and dynamic queuing and periodic redistribution are carried out; and a key thread priority decoding step, in which the Launcher main thread and a RenderThread are set as SCHED_FIFO real-time scheduling, precompiled local machine code is called, and hardware acceleration is enabled for decoding. The application shortens the first screen display time and is suitable for Android devices.

Description

Technical Field

[0001] This invention relates to the field of operating system startup optimization technology, specifically to an Android Launcher multi-dimensional preloading parallel startup method and system. Background Technology

[0002] In the Android system, the Launcher is the first graphical interface users interact with on their device, and its startup speed directly impacts the user's initial perception of device performance. Currently, the Launcher's startup process follows the standard Android application startup specification: after the system completes bootsuppression, the ActivityManagerService (AMS) initiates a startup request, sequentially executing process creation (Zygote fork), class loading (ClassLoader), Application initialization, Activity lifecycle callbacks, and main thread UI rendering. This process involves multiple sequential stages, and a delay in any stage can lead to a lag in the initial screen display.

[0003] However, existing launcher startup solutions have shortcomings in the following aspects:

[0004] First, just-in-time (JIT) compilation of DEX bytecode increases CPU overhead during the startup phase. When an application cold starts, the Android system typically relies on a Just-In-Time (JIT) compilation mechanism to dynamically compile the bytecode in the DEX file into native machine code. The Launcher contains a large amount of code related to UI rendering and interactive responses; JIT compilation is triggered in real-time during startup, consuming CPU resources that should be used for UI building. For embedded devices with limited processor computing power, such as smart set-top boxes and in-vehicle systems, this compilation overhead further prolongs the time from process startup to the first frame being drawn.

[0005] Secondly, non-critical services in the Launcher initialization process are executed sequentially on the main thread, blocking UI rendering. According to the Android lifecycle specification, the initialization callbacks of Application and Activity are executed sequentially on the main thread. The current solution unifies multiple tasks such as wallpaper loading, database connection, configuration reading, user profile reporting, and ad cache preloading into a single, sequential process on the main thread. Some of these tasks depend on network status or the readiness of external services, and their response times are uncertain. Slow execution of any of these tasks will result in the main thread being occupied for an extended period, preventing the timely triggering of the first frame rendering.

[0006] Third, resource loading lacks a visual priority-based scheduling strategy. The UI construction of the Launcher's home screen involves multiple tasks, including XML layout parsing, home screen icon decoding, historical data statistics, and ad creative loading. Existing solutions typically execute tasks sequentially according to their submission order or configuration file declaration order, without distinguishing the differences in contribution of each task to the user's home screen visual presentation. Under this mechanism, high-priority layout parsing and icon decoding tasks may be in the same processing queue as low-priority data statistics and ad loading, or even be delayed because the latter were submitted first.

[0007] Fourth, critical rendering threads lack effective scheduling priority guarantees. The Launcher main thread and RenderThread are responsible for tasks such as layout measurement, drawing instruction generation, and frame rendering submission. In the existing solution, these threads run at normal priority under the Linux kernel's CFS (Completely Fair Scheduler) scheduling policy. When there are a large number of I / O operations or computationally intensive tasks in the background, the CFS scheduler's time slice allocation mechanism may cause the main thread or RenderThread to be frequently preempted, making it difficult to guarantee that single-frame rendering is completed within 16ms. In addition, the image decoding process relies heavily on software implementation, failing to fully utilize hardware acceleration capabilities, further increasing the decoding time of the first screen icons.

[0008] In summary, existing launcher solutions have shortcomings in terms of compilation efficiency, initialization architecture, resource scheduling strategies, and thread scheduling mechanisms, resulting in longer initial screen display times, which particularly affects the user experience on embedded Android devices with limited hardware resources. Summary of the Invention

[0009] This invention aims to solve the problem of long initial screen display time in existing Android devices, and proposes a multi-dimensional preloading parallel startup method and system for Android Launcher.

[0010] The technical solution adopted by the present invention to solve the above-mentioned technical problems is as follows:

[0011] In a first aspect, the present invention provides a method for multi-dimensional preloading and parallel startup of Android Launcher, the method comprising:

[0012] APK static pre-compilation steps: During the system image building stage or the first installation stage, identify the hot code in the Launcher's .dex file, use Ahead-Of-Time compilation technology to call the dex2oat tool of the ART virtual machine to pre-compile the hot code into native machine code, and store the native machine code in the local storage space.

[0013] Asynchronous parallel service launch steps: Reconstruct the Launcher initialization process, create a fixed thread pool, encapsulate non-critical service tasks as Runnable objects and submit them to the fixed thread pool for parallel execution, and introduce a synchronizer to set a timeout period. The non-critical services are completed or degraded within the timeout period, and the Launcher main thread obtains idle resources and enters the onResume state.

[0014] FIFO dynamic priority scheduling steps: In response to the Launcher main thread entering the onResume state, a dual queue structure containing a high-priority queue and a normal queue is constructed. Based on the task type, UI layout parsing and first-screen icon decoding are marked as high priority and added to the high-priority queue, while historical data statistics and ad cache preloading are marked as normal priority and added to the normal queue. The scheduler cyclically retrieves and distributes tasks according to the following rules: When the high-priority queue is not empty, tasks are retrieved from the high-priority queue in a first-in-first-out order. The retrieved UI layout parsing task is executed by the Launcher main thread, and the retrieved first-screen icon decoding task is sent to the decoding thread. When the high-priority queue is empty, consumption of the normal queue is resumed. Normal tasks are retrieved from the normal queue in a first-in-first-out order and executed by the fixed thread pool.

[0015] The critical thread-priority decoding step is as follows: Receive the first screen icon decoding task, dynamically adjust the scheduling strategy of the Launcher main thread and RenderThread through the sched_setscheduler interface of the Linux system, set the thread scheduling strategy to real-time scheduling class and set the priority value, call the local machine code in RenderThread to execute the rendering instructions of the first screen icon decoding task, and enable the hardware acceleration instruction set to decode the first screen icon decoding task during the image decoding stage.

[0016] Furthermore, in the APK static pre-compilation step, hotspot code in the Launcher's .dex file is identified, specifically including:

[0017] Based on historical runtime logs, the number of calls to each method in the Launcher's .dex file is counted. Hotspot code is identified based on the statistical results, and methods with call counts exceeding the hotness threshold are included in the pre-compilation scope. The compilation filter is set to speed and a tiered compilation strategy is enabled to generate .oat and .vdex files. A preset compilation time threshold is set, and if the compilation time of a single compilation exceeds the compilation time threshold, the system automatically switches to background silent mode.

[0018] Furthermore, in the asynchronous parallel service startup step, the fixed thread pool size is N=4, specifically including:

[0019] The initialization call in Application.onCreate() is intercepted by reflection. Based on the preset directed acyclic graph, the task attributes are determined, and user profile reporting, advertising cache preloading, and weather data refresh are marked as non-critical services. The timeout is set to Timeout=2000ms using a CountDownLatch synchronizer. If the asynchronous task is not completed within the timeout period, a TimeoutException is triggered and an error log is recorded.

[0020] Furthermore, in the FIFO dynamic priority scheduling step, UI layout parsing and first-screen icon decoding are marked as high priority and added to the high-priority queue according to task type, while historical data statistics and ad cache preloading are marked as normal priority and added to the normal queue. This is specifically implemented using a dynamic scoring method.

[0021] Assign priority scores to each resource loading task The calculation formula is:

[0022] ;

[0023] in, This represents the percentage of the visible area, with a value ranging from 0 to 1. This indicates the estimated loading time. , Indicates the corresponding weight;

[0024] when When this happens, it is determined to be of high priority and added to the high-priority queue. When this happens, the task is classified as a normal priority and added to the normal queue.

[0025] Furthermore, the weights , .

[0026] Furthermore, the scheduler recalculates the priority score of each task at preset intervals based on the current visible area ratio of each resource loading task, and reallocates each task to a high-priority queue or a normal queue based on the recalculated priority score. After reallocation, the first-in-first-out order is still maintained within each queue.

[0027] Furthermore, the preset time is 16ms.

[0028] Furthermore, in the critical thread-first decoding step, the real-time scheduling class is set to SCHED_FIFO, and the priority value is set to 85.

[0029] Furthermore, in the critical thread-first decoding step, NEON or AVX hardware acceleration instruction sets are enabled during the image decoding stage, and the decoding time per frame is controlled within 16ms; an incremental inflate strategy is adopted for XML layout parsing, which only parses the view tree nodes in the current viewport, and hardware acceleration mode is enabled for Bitmap decoding operations using HardwareRenderer features.

[0030] In a second aspect, the present invention provides an Android Launcher multi-dimensional preloading parallel startup system for implementing the Android Launcher multi-dimensional preloading parallel startup method as described in the first aspect, the system comprising:

[0031] The APK static pre-compilation module is used to identify hotspot code in the Launcher's .dex file during the system image building stage or the first installation stage. It uses Ahead-Of-Time compilation technology to call the dex2oat tool of the ART virtual machine to pre-compile the hotspot code into native machine code and store the native machine code in local storage space.

[0032] The asynchronous parallel service launch module is used to refactor the Launcher's initialization process, create a fixed thread pool, encapsulate non-critical service tasks as Runnable objects and submit them to the fixed thread pool for parallel execution, and introduce a synchronizer to set a timeout period. The non-critical services are completed or degraded within the timeout period, and the Launcher main thread thereby obtains idle resources and enters the onResume state.

[0033] The FIFO dynamic priority scheduling module is used to respond to the Launcher main thread entering the onResume state, constructing a dual queue structure containing a high-priority queue and a normal queue. Based on the task type, UI layout parsing and first-screen icon decoding are marked as high priority and added to the high-priority queue, while historical data statistics and ad cache preloading are marked as normal priority and added to the normal queue. The scheduler cyclically retrieves and distributes tasks according to the following rules: When the high-priority queue is not empty, tasks are retrieved from the high-priority queue in a first-in-first-out order; the retrieved UI layout parsing task is executed by the Launcher main thread, and the retrieved first-screen icon decoding task is sent to the decoding thread; when the high-priority queue is empty, consumption of the normal queue is resumed, and normal tasks are retrieved from the normal queue in a first-in-first-out order, and the retrieved normal tasks are executed by the fixed thread pool.

[0034] The critical thread-priority decoding module is used to receive the first screen icon decoding task. Through the sched_setscheduler interface of the Linux system, it dynamically adjusts the scheduling strategy of the Launcher main thread and RenderThread, sets the thread scheduling strategy to real-time scheduling class and sets the priority value. In RenderThread, it calls the local machine code to execute the rendering instructions of the first screen icon decoding task, and enables the hardware acceleration instruction set to decode the first screen icon decoding task during the image decoding stage.

[0035] The beneficial effects of this invention are as follows: The Android Launcher multi-dimensional preloading parallel startup method and system provided by this invention eliminates the real-time compilation blocking during the startup process through APK static pre-compilation, enables non-critical services to execute asynchronously and release main thread resources to quickly enter the onResume state through asynchronous parallel service launch, ensures the priority loading of critical UI resources through FIFO dynamic priority scheduling, and ensures the timely completion of the first screen rendering task and the improvement of image decoding efficiency through priority decoding of critical threads. The four steps work together to shorten the first screen display time. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the standard Android Launcher startup process;

[0037] Figure 2 A flowchart illustrating an Android Launcher multi-dimensional preloading parallel startup method provided for an embodiment;

[0038] Figure 3 A flowchart illustrating another Android Launcher multi-dimensional preloading parallel startup method provided for an embodiment;

[0039] Figure 4 This is a schematic diagram of the structure of the Android Launcher multi-dimensional preloading parallel startup system provided in the embodiment. Detailed Implementation

[0040] Figure 1 This illustrates the typical Launcher startup process. The process begins with hardware power-on or booting, followed by system initialization. After system initialization, the various APK application processes are launched, including the creation of the Launcher application process. Next, the system launches the Launcher application, displaying the home attribute in the foreground, and finally loads the Launcher application's resources and displays its UI. Figure 1In the typical process shown, the Launcher's startup process follows the standard Android application startup specifications. Each initialization task is executed serially in the Launcher's main thread. It lacks asynchronous processing of non-critical services, priority differentiation of resource loading tasks, and scheduling priority guarantee of rendering threads, resulting in a long first screen display time.

[0041] Based on this, the technical solution of this invention is proposed. In this invention, through the APK static pre-compilation step, hotspot code in the Launcher's .dex file is identified and pre-compiled into native machine code during the system image building stage or the initial installation stage, eliminating real-time compilation blocking during startup and shortening the first-screen display time; through the asynchronous parallel service launch step, non-critical service tasks are submitted to a fixed thread pool for parallel execution, combined with a synchronizer timeout mechanism, ensuring that non-critical services complete or degrade within the timeout period, releasing Launcher main thread resources and allowing it to quickly enter the onResume state, avoiding serial blocking of the first-screen rendering by non-critical tasks; through FIFO dynamic priority... The scheduling process involves building high-priority and regular queues. High-priority tasks, such as UI layout parsing and first-screen icon decoding, are scheduled to be executed before regular tasks, such as historical data statistics and ad cache preloading. Regular queue consumption is forcibly paused when the high-priority queue is not empty, ensuring that critical UI resources are loaded and presented first. In the critical thread-priority decoding step, the Launcher main thread and RenderThread are adjusted to real-time scheduling classes with high priority values. Pre-compiled native machine code is called in RenderThread to execute rendering instructions, and hardware acceleration is enabled for decoding. This ensures that the first-screen rendering task is not preempted and improves decoding efficiency. These four steps work together to shorten the first-screen display time.

[0042] The technical solutions in this embodiment will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0043] To make the present invention easier to understand, the terminology involved in this embodiment is explained below.

[0044] Launcher: The desktop launcher application in Android systems, responsible for displaying icons, widgets, and handling user interactions.

[0045] APK (Android Package): The installation package file format for Android applications, which includes DEX bytecode, resource files, manifest files, etc.

[0046] FIFO (First-In-First-Out): First-in-first-out algorithm, here referring to an improved queue scheduling strategy that combines priority weights.

[0047] FCP (First Contentful Paint): The first content-rendered point in time when an application renders the first text or image on the screen.

[0048] DAG (Directed Acyclic Graph): A directed acyclic graph used to describe the dependencies between tasks and ensure the execution order without circular dependencies.

[0049] CFS (Completely Fair Scheduler): The Linux kernel's Completely Fair Scheduler, under which ordinary threads run by default.

[0050] RenderThread: The rendering thread in the Android system, responsible for submitting the drawing instructions generated by the main thread to the GPU for rendering.

[0051] CountDownLatch: A synchronization helper class in the Java concurrency package used to manage the completion status of a group of asynchronous tasks.

[0052] Figure 2 This embodiment illustrates a flowchart of a multi-dimensional preloading parallel startup method for Android Launcher. Please refer to [link / reference]. Figure 2 The method includes the following steps:

[0053] APK static pre-compilation steps: During the system image building stage or the first installation stage, hot spot code in the Launcher's .dex file is identified. Using Ahead-Of-Time compilation technology, the dex2oat tool of the ART virtual machine is called to pre-compile the hot spot code into native machine code, and the native machine code is stored in the local storage space.

[0054] In this embodiment, identifying hotspot code in the Launcher's .dex file specifically includes:

[0055] Based on historical runtime logs, the number of calls to each method in the Launcher's .dex file is counted. Hotspot code is identified based on the statistical results, and methods with call counts exceeding the hotness threshold are included in the pre-compilation scope. The compilation filter is set to speed and a tiered compilation strategy is enabled to generate .oat and .vdex files. A preset compilation time threshold is set, and if the compilation time of a single compilation exceeds the compilation time threshold, the system automatically switches to background silent mode.

[0056] Specifically, this step addresses the issue of Just-In-Time (JIT) compilation consuming CPU resources during startup. In the standard Android startup process, DEX bytecode needs to be compiled into native machine code by JIT upon first execution. This process occurs on the startup path, and for applications like Launcher that contain a large amount of UI code, the compilation overhead significantly prolongs the first screen display time.

[0057] Please see Figure 3 This step involves pre-compiling during the system image building or initial installation phase, moving the aforementioned overhead out of the boot path. Before compilation, it's necessary to determine which code is worth pre-compiling, i.e., identifying hot code. This embodiment uses a statistical method based on historical runtime logs: counting the number of calls to each method in the Launcher's .dex file, and identifying methods with a call frequency exceeding a hot threshold (more than 50 calls) as hot code. The hot threshold of 50 calls is set based on experimental data, covering most high-frequency execution paths while avoiding excessive compilation that could lead to a large image size. During compilation, a speed-priority filter is set to ensure execution speed, and a tiered compilation strategy allows for further optimization at runtime. The generated .oat file contains native machine code, and the .vdex file contains verification information for direct loading at startup. The preset compilation time threshold ensures that the compilation process will not block the system image building due to excessively long single-run times.

[0058] Asynchronous parallel service launch steps: Reconstruct the Launcher initialization process, create a fixed thread pool, encapsulate non-critical service tasks as Runnable objects and submit them to the fixed thread pool for parallel execution, and introduce a synchronizer to set a timeout period. The non-critical services are completed or degraded within the timeout period, and the Launcher main thread thereby obtains idle resources and enters the onResume state.

[0059] In this embodiment, the size of the fixed thread pool is N=4; the asynchronous parallel service start-up step specifically includes:

[0060] The initialization call in Application.onCreate() is intercepted by reflection. Based on the preset directed acyclic graph, the task attributes are determined, and user profile reporting, advertising cache preloading, and weather data refresh are marked as non-critical services. The timeout is set to Timeout=2000ms using a CountDownLatch synchronizer. If the asynchronous task is not completed within the timeout period, a TimeoutException is triggered and an error log is recorded.

[0061] Specifically, this step addresses the issue of non-critical services executing sequentially on the main thread, blocking the initial screen rendering. In the Android lifecycle, both Application and Activity initialization are performed on the main thread; any time-consuming task will postpone the arrival of the onResume state.

[0062] Please see Figure 3 This step divides the initialization tasks into critical and non-critical paths. Critical path tasks are essential for the initial screen display and are executed synchronously by the main thread; non-critical path tasks do not affect the initial screen display and are stripped to a background thread pool. The division is based on intercepting initialization calls using reflection and combining this with a directed acyclic graph (DAG). If a task is not depended upon by any critical path task, it is considered a non-critical service. A fixed thread pool size of 4 is determined based on the number of CPU cores in a typical embedded device, fully utilizing multi-core parallel capabilities while avoiding context switching overhead. A CountDownLatch synchronizer uniformly manages the completion status of asynchronous tasks, with a timeout of 2000ms ensuring sufficient execution time for non-critical services while preventing abnormal services from blocking indefinitely. Degradation handling after timeout (logging errors and continuing execution) ensures the robustness of the startup process.

[0063] FIFO dynamic priority scheduling steps: In response to the Launcher main thread entering the onResume state, a dual queue structure containing a high-priority queue and a normal queue is constructed. UI layout parsing and first-screen icon decoding are marked as high priority and added to the high-priority queue according to task type, while historical data statistics and ad cache preloading are marked as normal priority and added to the normal queue. The scheduler retrieves and distributes tasks cyclically according to the following rules: When the high-priority queue is not empty, tasks are retrieved from the high-priority queue in a first-in-first-out order. The retrieved UI layout parsing task is executed by the Launcher main thread, and the retrieved first-screen icon decoding task is sent to the decoding thread. When the high-priority queue is empty, consumption of the normal queue is resumed. Normal tasks are retrieved from the normal queue in a first-in-first-out order and executed by the fixed thread pool.

[0064] In this embodiment, in the FIFO dynamic priority scheduling step, UI layout parsing and first-screen icon decoding are marked as high priority and added to the high-priority queue according to the task type, while historical data statistics and ad cache preloading are marked as normal priority and added to the normal queue. This is specifically implemented using a dynamic scoring method.

[0065] Assign priority scores to each resource loading task The calculation formula is:

[0066] ;

[0067] in, This represents the percentage of the visible area, with a value ranging from 0 to 1. This indicates the estimated loading time. , Indicates the corresponding weight; , .

[0068] when When the task is classified as high priority, it is added to the high priority queue. When this happens, the task is classified as a normal priority and added to the normal queue.

[0069] The scheduler recalculates the priority score of each task at preset intervals based on the current visible area ratio of each resource loading task, and then reallocates each task to a high-priority queue or a normal queue based on the recalculated priority score. After reallocation, the first-in-first-out order is still maintained within each queue. The preset interval is 16ms.

[0070] Specifically, this step addresses the issues of disordered competition among resource loading tasks and the blocking of critical UI elements by non-critical tasks. Traditional solutions execute tasks sequentially according to their submission order, which may delay the decoding of the first-screen icons due to earlier-submitted advertisements.

[0071] Please see Figure 3 This step constructs two independent queues: high-priority and normal-priority. Enqueueing is determined using a dynamic scoring method, as the urgency of the same task may change with UI status; icons at the screen edge may move to the center after the user scrolls, increasing their urgency. The priority score calculation formula combines two factors: the visible area percentage reflects the task's contribution to the currently visible content, and the estimated loading time reflects the task's time consumption characteristics. Weighted priority ensures that visible area content is loaded first. A threshold of 0.5 transforms consecutive priority scores into a binary decision between high-priority and normal-priority tasks.

[0072] The scheduling rules ensure that high-priority tasks have absolute priority. When a high-priority queue is not empty, normal queues suspend consumption. Within the same priority level, tasks follow a FIFO (First-In, First-Out) order, guaranteeing that tasks of the same level are executed in the order of arrival. Every 16ms (one frame), the scheduler recalculates the priority score of each task based on real-time changes in the visible area and reallocates queues, ensuring timely priority adjustments after UI changes. After reallocation, each queue still maintains a FIFO order.

[0073] The critical thread-priority decoding step is as follows: Receive the first screen icon decoding task, dynamically adjust the scheduling strategy of the Launcher main thread and RenderThread through the sched_setscheduler interface of the Linux system, set the thread scheduling strategy to real-time scheduling class and set the priority value, call the local machine code in RenderThread to execute the rendering instructions of the first screen icon decoding task, and enable the hardware acceleration instruction set to decode the first screen icon decoding task during the image decoding stage.

[0074] In this embodiment, the real-time scheduling class is set to SCHED_FIFO, and the priority value is set to 85. During the image decoding stage, NEON or AVX hardware acceleration instruction sets are enabled, and the decoding time for a single frame is controlled within 16ms. An incremental inflate strategy is used for XML layout parsing, parsing only the view tree nodes within the current viewport, and hardware acceleration mode is enabled for Bitmap decoding operations using HardwareRenderer features.

[0075] Specifically, this step addresses the issue of UI rendering critical threads being preempted by system background tasks, resulting in low decoding efficiency. In the standard Linux kernel, ordinary threads run under the CFS scheduling policy, and background I / O tasks may cause the main thread or RenderThread to be frequently preempted, making it impossible to guarantee that rendering will be completed within a 16ms cycle.

[0076] Please see Figure 3 This step uses the `sched_setscheduler` interface to set the Launcher main thread and RenderThread to the SCHED_FIFO real-time scheduling policy. Once a thread acquires the CPU, it will continue to run until it voluntarily yields, avoiding interruption by ordinary background tasks. The priority value of 85 is in the mid-to-high range of real-time priorities (1-99), higher than most ordinary real-time tasks while still allowing for higher-priority interruptions. RenderThread calls pre-compiled native machine code to perform rendering, avoiding runtime compilation overhead. Hardware-accelerated instruction sets (NEON or AVX) utilize the CPU's SIMD capabilities to process image data in parallel. The incremental inflate strategy only parses view tree nodes within the current viewport, reducing layout parsing computation. The HardwareRenderer feature allows Bitmap decoding to directly utilize GPU capabilities.

[0077] The four steps described above are activated sequentially along the startup timeline. Static pre-compilation of the APK provides pre-compiled native machine code for priority decoding by critical threads, eliminating the need for immediate compilation during rendering by the RenderThread. The asynchronous parallel service launches and releases main thread resources, allowing it to quickly enter the onResume state, which is the trigger condition for FIFO dynamic priority scheduling. FIFO dynamic priority scheduling sends the first-screen icon decoding task to the decoding thread, where the critical thread prioritizes decoding and optimizes scheduling. These four steps respectively affect the compilation preparation, initialization, scheduling, and decoding stages, collectively shortening the first-screen display time.

[0078] Example 1: The following uses a smart TV (equipped with Android 11, quad-core Cortex-A53, 2GB RAM) as an example to illustrate the specific implementation of this example.

[0079] During the firmware packaging stage, the system integrates a custom plugin to scan the Launcher's APK package, analyze historical runtime logs, extract a list of methods called more than 50 times, and generate a configuration file. The system calls the dex2oat tool, specifies the compilation filter as speed, loads the configuration file, and pre-compiles the identified hotspot code into native machine code, generating .oat and .vdex files which are stored in local storage. A preset compilation time threshold is set; if a single compilation takes longer than this threshold, it automatically switches to background silent mode to avoid blocking the firmware build process. In this embodiment, the actual compilation time was 12 seconds, and the switch was not triggered.

[0080] Upon initial device power-on, the Launcher process starts, and the system refactors the initialization process in `Application.onCreate()` using a distribution manager. Initialization calls are intercepted via reflection, and based on a predefined directed acyclic graph, the 12 initialization tasks are reclassified: three critical path tasks (theme engine, icon caching, database connection, etc.) are synchronously waited for by the Launcher main thread; five non-critical path tasks (user profile reporting, ad cache preloading, weather data refreshing, etc.) are marked as non-critical services, encapsulated as `Runnable` objects, and submitted to a fixed thread pool of size 4 for asynchronous execution. A `CountDownLatch` synchronizer with a timeout of 2000ms is introduced, and the Launcher main thread only waits for the three critical path tasks to complete (approximately 150ms) before entering the `onResume` state. The ad cache preloading timeout (2100ms) due to network latency triggers a `TimeoutException`, which is logged and then downgraded without blocking the main process.

[0081] After the Launcher main thread enters the onResume state, the scheduler constructs a high-priority queue and a normal queue. The icon loader class is overridden to calculate a priority score P for each resource loading task among the 36 application icons on the first screen. Icons located in the center of the screen have a visible area ratio V=1.0, and based on historical data, the estimated loading time S=0.6, so P=0.7×1.0+0.3×0.6=0.88. They are marked as P_level=1, determined to be high priority, and added to the high-priority queue. Icons located at the edge of the screen have V=0.3, S=0.5, and P=0.36. They are marked as P_level=2, determined to be normal priority, and added to the normal queue. UI layout parsing tasks calculate the P score based on the view's visible proportion and add them to the corresponding queues. The scheduler utilizes a vertical synchronization signal monitoring mechanism to enforce priority processing of high-priority tasks (P>0.8) at the beginning of each frame: UI layout parsing tasks are retrieved from the high-priority queue in a first-in-first-out (FIFO) order and executed by the Launcher main thread; the first-screen icon decoding task is retrieved and sent to the decoding thread; when the high-priority queue is empty, normal queue consumption resumes. After the user scrolls the screen, the scheduler recalculates the P score every 16ms based on the current visible area proportion of each task and reassigns queues. After an icon originally located at the edge is moved to the center, V increases from 0.3 to 1.0, and P increases from 0.36 to 0.88, and the icon is reassigned to the high-priority queue. The FIFO order is maintained within each queue after reassignment.

[0082] After the decoding thread receives the task of decoding the first screen icon, the system sets the scheduling policy of the Launcher main thread and RenderThread to SCHED_FIFO and the priority value to 85 through the sched_setscheduler interface. In RenderThread, the local machine code stored in the APK static pre-compilation step is called to execute rendering instructions. The NEON hardware acceleration instruction set is enabled during the image decoding stage to ensure that the decoding time per frame is controlled within 16ms. An incremental inflate strategy is used for XML layout parsing, parsing only the view tree nodes within the current viewport, and hardware acceleration mode is enabled for Bitmap decoding operations using HardwareRenderer features.

[0083] According to tests, in this embodiment, the time from clicking the power button to the first screen content being displayed was reduced from 9.2 seconds before optimization to 3.8 seconds.

[0084] Example 2: The following uses an in-vehicle infotainment system (Android Automotive OS, octa-core processor, 4GB memory) as an example to illustrate the specific implementation of this example.

[0085] The system performs static pre-compilation of the APK during the factory setup. The basic framework code is pre-compiled at the factory: historical runtime logs are analyzed, the call count of each method in the Launcher's .dex file is counted, and hot methods with a call frequency exceeding 50 times are included in the pre-compilation scope. The dex2oat tool is called, the compilation filter is set to speed, and a tiered compilation strategy is enabled to generate local machine code stored locally. For plug-in code configured for specific vehicle models, which may change due to OTA upgrades, pre-compilation is not performed at the factory. Instead, it is triggered by a background daemon during idle charging periods after the initial installation to avoid affecting subsequent user launches. A preset compilation time threshold is set; if the vehicle starts during compilation, the current compilation is paused, switching to a silent background mode and gradually completing the compilation during subsequent idle periods.

[0086] When a vehicle starts, the system builds upon dependency management based on a directed acyclic graph (DAG). Immediately after the Launcher process starts, it initiates an asynchronous connection request to the vehicle property manager. This request is marked as a non-critical service task and executed asynchronously in a separate IO thread pool. The Launcher main thread does not block while waiting for vehicle data to be ready; instead, it first loads the local default UI skeleton. Initialization calls in `Application.onCreate()` are intercepted via reflection. Based on the DAG, user profile reporting, ad cache preloading, weather data refreshing, and vehicle service connections are marked as non-critical services and submitted to a fixed thread pool for parallel execution. A CountDownLatch synchronizer is used to set the timeout to 2000ms. Vehicle CAN bus data returns with a 2.5-second delay due to the initial startup; a timeout triggers a `TimeoutException` and logs the error. The UI is subsequently updated via a message sending mechanism. The Launcher main thread enters the `onResume` state approximately every 200ms.

[0087] After the Launcher main thread enters the onResume state, the scheduler detects that the vehicle is in driving mode (D gear) and automatically adjusts the weighting parameters in the scoring formula, increasing the weight of the visible area occupancy V. The weight of the estimated loading time S was increased from 0.7 to 0.9. The priority score was reduced from 0.3 to 0.1. The navigation card loading task (V=1.0, S=0.5, P=0.9×1.0+0.1×0.5=0.95, previously 0.85) was added to the high-priority queue. The multimedia recommendation task (V=0.8, S=0.9, P=0.9×0.8+0.1×0.9=0.81, previously 0.83) remained high-priority. Driving-related cards received a higher priority score due to the weight adjustment and remained at the head of the high-priority queue. Every 16ms, the scheduler recalculated the P score based on the current visible area percentage of each task and reassigned queues, maintaining a first-in, first-out order within each queue after reassignment.

[0088] After the decoding thread receives the task of decoding the first screen icon, the system sets the scheduling policy of the Launcher main thread and RenderThread to SCHED_FIFO and the priority value to 85 through the sched_setscheduler interface. For high-resolution wallpapers, a block decoding strategy is adopted, decoding only the layers required for the current resolution at a time to avoid memory jitter caused by loading 4K images all at once. In RenderThread, the local machine code stored in the APK static pre-compilation step is called to execute rendering instructions. The NEON hardware acceleration instruction set is enabled during the image decoding stage, keeping the single-frame decoding time within 16ms.

[0089] According to tests, in this embodiment, when the vehicle is just started and the bus data is busy, the Launcher's first screen display time is controlled within 2.5 seconds, and there is no obvious frame drop when switching applications to return to the desktop while driving.

[0090] In summary, the Android Launcher multi-dimensional preloading parallel startup method provided in this embodiment, through the APK static pre-compilation step, pre-compiles the hot-spot code in the Launcher's .dex file into native machine code during the system image building stage or the initial installation stage, eliminating the immediate compilation blocking during the startup process; through the asynchronous parallel service launch step, non-critical service tasks are submitted to a fixed thread pool for parallel execution and combined with a synchronizer timeout mechanism, so that non-critical services complete or degrade within the timeout period, releasing the Launcher's main thread resources and allowing it to quickly enter the onResume state; through the FIFO dynamic priority scheduling step, a high-priority queue is constructed. The system employs a combination of queues and regular queues to prioritize high-priority tasks such as UI layout parsing and first-screen icon decoding over regular tasks like historical data statistics and ad cache preloading. Priority scores are dynamically adjusted based on visible area percentages at preset intervals to ensure critical UI resources are always loaded first. In the critical thread-priority decoding step, the scheduling strategy for the Launcher main thread and RenderThread is set to SCHED_FIFO with a priority value of 85, preventing preemption of first-screen rendering tasks. Simultaneously, pre-compiled native machine code is used to execute rendering instructions, and hardware-accelerated instruction sets are enabled for decoding, improving image decoding efficiency. These four steps work together to shorten the first-screen display time. Experimental data shows that after applying this solution, the first-screen display time for smart TVs is reduced from 9.2 seconds to 3.8 seconds, and the stable first-screen display time for in-vehicle systems is controlled within 2.5 seconds, significantly improving the user experience.

[0091] Based on the above technical solutions, this embodiment also proposes an Android Launcher multi-dimensional preloading parallel startup system to implement the Android Launcher multi-dimensional preloading parallel startup method as described in the embodiment. Please refer to [link to relevant documentation]. Figure 4 The system includes:

[0092] The APK static pre-compilation module is used to identify hotspot code in the Launcher's .dex file during the system image building stage or the first installation stage. It uses Ahead-Of-Time compilation technology to call the dex2oat tool of the ART virtual machine to pre-compile the hotspot code into native machine code and store the native machine code in local storage space.

[0093] The asynchronous parallel service launch module is used to refactor the Launcher's initialization process, create a fixed thread pool, encapsulate non-critical service tasks as Runnable objects and submit them to the fixed thread pool for parallel execution, and introduce a synchronizer to set a timeout period. The non-critical services are completed or degraded within the timeout period, and the Launcher main thread thereby obtains idle resources and enters the onResume state.

[0094] The FIFO dynamic priority scheduling module is used to respond to the Launcher main thread entering the onResume state, constructing a dual queue structure containing a high-priority queue and a normal queue. Based on the task type, UI layout parsing and first-screen icon decoding are marked as high priority and added to the high-priority queue, while historical data statistics and ad cache preloading are marked as normal priority and added to the normal queue. The scheduler cyclically retrieves and distributes tasks according to the following rules: When the high-priority queue is not empty, tasks are retrieved from the high-priority queue in a first-in-first-out order; the retrieved UI layout parsing task is executed by the Launcher main thread, and the retrieved first-screen icon decoding task is sent to the decoding thread; when the high-priority queue is empty, consumption of the normal queue is resumed, and normal tasks are retrieved from the normal queue in a first-in-first-out order, and the retrieved normal tasks are executed by the fixed thread pool.

[0095] The critical thread-priority decoding module is used to receive the first screen icon decoding task. Through the sched_setscheduler interface of the Linux system, it dynamically adjusts the scheduling strategy of the Launcher main thread and RenderThread, sets the thread scheduling strategy to real-time scheduling class and sets the priority value. In RenderThread, it calls the local machine code to execute the rendering instructions of the first screen icon decoding task, and enables the hardware acceleration instruction set to decode the first screen icon decoding task during the image decoding stage.

[0096] It is understood that since the Android Launcher multi-dimensional preloading parallel startup system described in this embodiment is a system for implementing the Android Launcher multi-dimensional preloading parallel startup method described in the embodiment, the system disclosed in the embodiment is relatively simple to describe because it corresponds to the method disclosed in the embodiment. For relevant parts, please refer to the description of the method, and it will not be repeated here.

Claims

1. A method for multi-dimensional preloading and parallel startup of Android Launcher, characterized in that, The method includes: APK static pre-compilation steps: During the system image building stage or the first installation stage, identify the hot code in the Launcher's .dex file, use Ahead-Of-Time compilation technology to call the dex2oat tool of the ART virtual machine to pre-compile the hot code into native machine code, and store the native machine code in the local storage space. Asynchronous parallel service launch steps: Reconstruct the Launcher initialization process, create a fixed thread pool, encapsulate non-critical service tasks as Runnable objects and submit them to the fixed thread pool for parallel execution, and introduce a synchronizer to set a timeout period. The non-critical services are completed or degraded within the timeout period, and the Launcher main thread obtains idle resources and enters the onResume state. FIFO dynamic priority scheduling steps: In response to the Launcher main thread entering the onResume state, a dual queue structure containing a high-priority queue and a normal queue is constructed. Based on the task type, UI layout parsing and first-screen icon decoding are marked as high priority and added to the high-priority queue, while historical data statistics and ad cache preloading are marked as normal priority and added to the normal queue. The scheduler cyclically retrieves and distributes tasks according to the following rules: When the high-priority queue is not empty, tasks are retrieved from the high-priority queue in a first-in-first-out order. The retrieved UI layout parsing task is executed by the Launcher main thread, and the retrieved first-screen icon decoding task is sent to the decoding thread. When the high-priority queue is empty, consumption of the normal queue is resumed. Normal tasks are retrieved from the normal queue in a first-in-first-out order and executed by the fixed thread pool. The critical thread-priority decoding step is as follows: Receive the first screen icon decoding task, dynamically adjust the scheduling strategy of the Launcher main thread and RenderThread through the sched_setscheduler interface of the Linux system, set the thread scheduling strategy to real-time scheduling class and set the priority value, call the local machine code in RenderThread to execute the rendering instructions of the first screen icon decoding task, and enable the hardware acceleration instruction set to decode the first screen icon decoding task during the image decoding stage.

2. The Android Launcher multi-dimensional preloading parallel startup method according to claim 1, characterized in that, In the APK static pre-compilation step, hotspot code in the Launcher's .dex file is identified, specifically including: Based on historical runtime logs, the number of calls to each method in the Launcher's .dex file is counted. Hotspot code is identified based on the statistical results, and methods with call counts exceeding the hotness threshold are included in the pre-compilation scope. The compilation filter is set to speed and a tiered compilation strategy is enabled to generate .oat and .vdex files. A preset compilation time threshold is set, and if the compilation time of a single compilation exceeds the compilation time threshold, the system automatically switches to background silent mode.

3. The Android Launcher multi-dimensional preloading parallel startup method according to claim 1, characterized in that, In the asynchronous parallel service startup step, the fixed thread pool size is N=4, specifically including: The initialization call in Application.onCreate() is intercepted by reflection. Based on the preset directed acyclic graph, the task attributes are determined, and user profile reporting, advertising cache preloading, and weather data refresh are marked as non-critical services. The timeout is set to Timeout=2000ms using a CountDownLatch synchronizer. If the asynchronous task is not completed within the timeout period, a TimeoutException is triggered and an error log is recorded.

4. The Android Launcher multi-dimensional preloading parallel startup method according to claim 1, characterized in that, In the FIFO dynamic priority scheduling step, UI layout parsing and first-screen icon decoding are marked as high priority and added to the high-priority queue according to task type, while historical data statistics and ad cache preloading are marked as normal priority and added to the normal queue. This is specifically implemented using a dynamic scoring method. Assign priority scores to each resource loading task The calculation formula is: ； in, This represents the percentage of the visible area, with a value ranging from 0 to 1. This indicates the estimated loading time. , Indicates the corresponding weight; when When this happens, it is determined to be of high priority and added to the high-priority queue. When this happens, the task is classified as a normal priority and added to the normal queue.

5. The Android Launcher multi-dimensional preloading parallel startup method according to claim 4, characterized in that, The weight , .

6. The Android Launcher multi-dimensional preloading parallel startup method according to claim 4, characterized in that, The scheduler recalculates the priority score of each task at preset intervals based on the current visible area ratio of each resource loading task, and reallocates each task to a high-priority queue or a normal queue based on the recalculated priority score. After reallocation, the first-in-first-out order is still maintained within each queue.

7. The Android Launcher multi-dimensional preloading parallel startup method according to claim 6, characterized in that, The preset time is 16ms.

8. The Android Launcher multi-dimensional preloading parallel startup method according to claim 1, characterized in that, In the critical thread-first decoding step, the real-time scheduling class is set to SCHED_FIFO, and the priority value is set to 85.

9. The Android Launcher multi-dimensional preloading parallel startup method according to claim 1, characterized in that, In the critical thread-first decoding step, NEON or AVX hardware acceleration instruction sets are enabled during the image decoding stage, and the decoding time per frame is controlled within 16ms. An incremental inflate strategy is adopted for XML layout parsing, which only parses the view tree nodes in the current viewport, and hardware acceleration mode is enabled for Bitmap decoding operations using HardwareRenderer features.

10. An Android Launcher multi-dimensional preloading parallel startup system, characterized in that, For implementing the Android Launcher multi-dimensional preloading parallel startup method as described in any one of claims 1 to 9, the system comprises: The APK static pre-compilation module is used to identify hotspot code in the Launcher's .dex file during the system image building stage or the first installation stage. It uses Ahead-Of-Time compilation technology to call the dex2oat tool of the ART virtual machine to pre-compile the hotspot code into native machine code and store the native machine code in local storage space. The asynchronous parallel service launch module is used to refactor the Launcher's initialization process, create a fixed thread pool, encapsulate non-critical service tasks as Runnable objects and submit them to the fixed thread pool for parallel execution, and introduce a synchronizer to set a timeout period. The non-critical services are completed or degraded within the timeout period, and the Launcher main thread thereby obtains idle resources and enters the onResume state. The FIFO dynamic priority scheduling module is used to respond to the Launcher main thread entering the onResume state, constructing a dual queue structure containing a high-priority queue and a normal queue. Based on the task type, UI layout parsing and first-screen icon decoding are marked as high priority and added to the high-priority queue, while historical data statistics and ad cache preloading are marked as normal priority and added to the normal queue. The scheduler cyclically retrieves and distributes tasks according to the following rules: When the high-priority queue is not empty, tasks are retrieved from the high-priority queue in a first-in-first-out order; the retrieved UI layout parsing task is executed by the Launcher main thread, and the retrieved first-screen icon decoding task is sent to the decoding thread; when the high-priority queue is empty, consumption of the normal queue is resumed, and normal tasks are retrieved from the normal queue in a first-in-first-out order, and the retrieved normal tasks are executed by the fixed thread pool. The critical thread-priority decoding module is used to receive the first screen icon decoding task. Through the sched_setscheduler interface of the Linux system, it dynamically adjusts the scheduling strategy of the Launcher main thread and RenderThread, sets the thread scheduling strategy to real-time scheduling class and sets the priority value. In RenderThread, it calls the local machine code to execute the rendering instructions of the first screen icon decoding task, and enables the hardware acceleration instruction set to decode the first screen icon decoding task during the image decoding stage.

Images