Application loading method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention relates to the technical field of automotive electronics, and discloses an application loading method and device, electronic equipment and a storage medium, the method comprises the following steps: monitoring a key time window during startup, the key time window being a time window from the starting moment of a system service process to the complete preparation of an activity manager service; creating an application process in the key time window; when a request for starting the target application is received, querying whether a target application process of the target application is created or not through the activity management service; if the target application process is already created, the target application process is reused through the activity management service to start the target application, and by applying the technical scheme of the invention, the first starting time of the vehicle-mounted terminal system application can be shortened.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics technology, specifically to an application loading method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the development of automotive intelligence and connectivity, in-vehicle infotainment systems (referred to as "vehicle infotainment systems") have become a core component of modern automobiles. These systems support numerous functions such as navigation, music, vehicle control, and human-machine interaction, and their user experience directly impacts driver and passenger satisfaction. Currently, most mainstream vehicle infotainment systems are developed based on deeply customized Android systems. In these technologies, when a user first clicks on such an application, the creation of the process, the initialization of the class loader, and the loading and linking of numerous SO libraries consume a significant amount of time, resulting in noticeable lag and delays during application startup. This cold start time significantly affects the interactive boot time of the vehicle infotainment system, reducing the overall user experience and making users feel that the system is "slow to respond" and has a "long boot time." Summary of the Invention

[0003] In view of the above problems, embodiments of the present invention provide an application loading method, apparatus, electronic device and storage medium to solve the problem of slow initial startup time of the desktop and core applications of in-vehicle infotainment systems in the prior art.

[0004] According to one aspect of the present invention, an application loading method is provided, the method comprising: listening to a critical time window during system startup, the critical time window being a time window from the start of a system service process to the full readiness of an Activity Manager service; creating an application process within the critical time window; when a request to start a target application is received, querying through the Activity Manager service whether the target application process has been created; if the target application process has been created, starting the target application by reusing the target application process through the Activity Manager service.

[0005] According to another aspect of the present invention, an application loading apparatus is provided, comprising: a critical time window identification module for identifying the start and end of a critical time window; an incubator module for incubating application processes that need to be pre-created; a status query module for querying, through an activity management service, whether the target application process of the target application has been created when a request to launch the target application is received; and a process reuse and launch module for launching the target application through the activity management service if the target application process has been created.

[0006] According to another aspect of the present invention, an application loading device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, which causes the processor to perform an operation of an application loading method according to the first aspect.

[0007] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein at least one executable instruction is stored therein, the executable instruction causing an application loading device / apparatus to perform an operation of an application loading method of the first aspect.

[0008] This invention significantly improves user experience by pre-creating application processes during idle time windows in the boot process. It drastically shortens the initial startup time of the in-vehicle infotainment system's desktop and applications after booting up, by pre-creating and distributing high-priority process creation and initialization operations—which would normally occur when the user actively triggers the process—to a more readily available stage when system resources are relatively idle. This staggered scheduling effectively avoids instantaneous contention and peak loads on CPU, memory, and I / O resources caused by multiple applications launching concurrently due to user actions after system startup. This allows the system to maintain a higher and more stable performance baseline after entering a usable state, improving overall system responsiveness, eliminating "lag" and "delay," and providing users with a smooth "instant" experience. By fully utilizing the CPU idle window during system service startup and interleaving loading tasks within the parallel process of system service initialization, it achieves deep optimization of system startup time without increasing the total boot time.

[0009] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0010] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This invention provides a schematic flowchart of a first embodiment of an application loading method. Figure 2 A flowchart illustrating a second embodiment of an application loading method provided by the present invention is shown; Figure 3 A schematic diagram of a newly added module in an application loading method provided by the present invention is shown; Figure 4 A timing diagram of an application loading method provided by the present invention is shown; Figure 5 A schematic diagram of an embodiment of an application loading device provided by the present invention is shown; Figure 6 A schematic diagram of an embodiment of an application loading device provided by the present invention is shown. Detailed Implementation

[0011] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0012] In current in-vehicle infotainment systems, the on-demand startup mechanism based on standard Android has significant technical flaws. Due to the high complexity and large resource requirements of desktop applications and core functions (such as 3D car models and high-definition navigation), when a user first clicks on an application, the system needs to temporarily create a process, initialize a class loader, and load a large number of SO libraries and resource files. This series of operations extends cold start time from hundreds of milliseconds to several seconds, causing noticeable lag and delays, severely impacting the "interactive time" of the in-vehicle infotainment system. While the "snapshot hibernation" solution can achieve rapid recovery, it essentially comes at the cost of continuous power consumption, posing an inherent risk of draining the vehicle's battery. Furthermore, its implementation is extremely complex, requiring kernel-level support and significant modifications to the Android system; snapshot files can be very large, consuming considerable storage space; and the validity of snapshots may become invalid due to system updates and library version changes, resulting in high maintenance costs.

[0013] Figure 1 A flowchart of a first embodiment of the loading method of the present invention is shown, which is executed by an in-vehicle infotainment system. Figure 1 As shown, the method includes the following steps: Step S101: Listen to the critical time window during startup. The critical time window is the time window from the start of the system service process to the full readiness of the Activity Manager service.

[0014] Step S102: Pre-create the application process within the critical time window.

[0015] Step S103: When the target application is launched, query the activity management service to see if the target application process has been pre-created.

[0016] Step S104: If the target application process has been pre-created, start the target application by reusing the target application process through the activity management service.

[0017] Firstly, the Android system boot process typically involves the bootloader starting execution after the hardware powers on, and the system launcher becoming ready. Monitoring can be done using persistent flags, listening to system-wide broadcasts, or polling system services to determine their availability. The critical time window refers to the period between the start of the system service process (system_server) and the full readiness of the ActivityManagerService (AMS) (i.e., AMS.ready), during which core system services are initializing and the system load is relatively low.

[0018] In one example, a broadcast is sent when system_server starts up. When AMS is fully ready, the AMS.systemReady() function is executed, sending another broadcast within AMS.systemReady(). The receiver and permissions are declared in the Android application's core configuration file, AndroidManifest.xml. Receiving the broadcast sent when system_server starts up marks the beginning of a critical system time window, and receiving the broadcast sent in AMS.systemReady() marks the end of that critical time window.

[0019] Then, within a critical time window, the system kernel starts the user-space initialization process (init process). The init process is the first process in the Android system, working according to the script (init.rc) during boot, responsible for starting all the most core low-level processes. The init process starts the system management service (System Server) according to the preset configuration file. When it detects the system service process (system_server) starting, the incubator (Zygote) process starts. The Zygote process is a "template process" that preloads the Android application runtime environment. It quickly incubates new app processes by "copying itself". The Zygote process first loads the Android Runtime (ART) environment and preloads a set of core libraries. Once the environment is ready, Zygote uses its fork mechanism to copy itself, thereby generating a Launcher process (i.e., the desktop). It then passes startup parameters to trigger Launcher initialization and UI rendering. Upon receiving instructions, Zygote preloads the application process. Using copy-on-write, Zygote directly shares preloaded resources (such as android.os.Bundle, android.app.Activity, and other framework core classes, as well as system icons and theme resources) from its own process space with the application process to be created, without needing to re-read and load from the storage module, reducing memory usage and loading time. Next, it performs supplementary loading of application-specific resources, executing a specialized process: loading the application's own independent code and resources, and starting its own main thread and Application class. When the critical time window ends, i.e., when AMS is fully ready, any unloaded applications terminate directly.

[0020] Finally, when a user clicks the icon of a target application, the system AMS receives the intent to launch the application. In response, the AMS checks in the background whether the target application's process has been pre-created. If the target application's process has been pre-created, the AMS will find that the application's process already exists and its core resources have been loaded. There's no need to request Zygote to fork a new process and perform time-consuming loading operations again; instead, it directly reuses this "pre-warmed" process and immediately begins creating Activities and rendering the UI. An Activity is the first and most crucial visual and interactive component to be created after the application process completes initialization. Because the most time-consuming resource loading and initialization are completed in the pre-creation stage, the creation and rendering of the new Activity will be very fast. Simultaneously, the cache pool is updated, and the target application process is removed from the "waiting process pool" and becomes an active foreground process.

[0021] This embodiment provides an application loading method that, through idle resource identification, utilizes idle system resources for preloading, converting previously idle hardware resources (idle CPU, memory) into preload computing power, improving system resource utilization and avoiding resource waste. The system monitors suitable idle time windows, namely the critical time window of this embodiment, and leverages the very low system load during these windows. It proactively utilizes Android's Zygote process mechanism to pre-fork applications that need preloading, shortening application startup time, optimizing vehicle-to-everything (V2X) interaction response, and replacing scattered reading with centralized preloading. This reduces overall system energy consumption, adapts to the low-power requirements of the V2X system, and transforms the scattered I / O readings from multiple user application launches (such as reading framework libraries and application dex files each time) into a single centralized preloading during idle periods, avoiding resource contention during concentrated application launches and reducing high-frequency CPU scheduling. After system startup, the most time-consuming steps, such as forking processes, loading APKs, and initializing virtual machines, are skipped. This shifts computationally intensive tasks from peak user interaction periods to the idle period during system startup, smoothing out system load. Avoiding repetitive I / O operations and CPU-intensive initialization helps reduce overall system power consumption. The essence of process reuse is "space for time" and "task pre-processing." By consuming a portion of memory in advance to cache "warm-up" processes, and then efficiently converting these cached processes into foreground processes through a "cleanup and reset" step when needed by the user, the startup experience is greatly optimized.

[0022] Figure 2 A flowchart of another embodiment of the application loading method of the present invention is shown, which is performed by an in-vehicle infotainment system. For example... Figure 2 As shown, the method includes the following steps: Step S201: Monitor a critical time window during system startup. The critical time window is the period from the start of the system service process to the full readiness of the Activity Manager service. For details, please refer to [link to relevant documentation]. Figure 1 Step S101 of the illustrated embodiment will not be described again here.

[0023] Step S202: Pre-create the application process within the critical time window.

[0024] Specifically, step S202 includes: Step S2021: Determine the current time period used to represent the work status within the critical time window; Step S2022: If the current time period is the first time period, then the application process creation task is executed within the first time period.

[0025] Step S2023: If the current time period is the second time period, then the application process creation task is paused during the second time period, which is the package management service's package scanning time period. Specifically, in this embodiment of the invention, the "first time period" specifically refers to the time period when the system is idle and can be used to execute pre-creation tasks; while the "second time period" specifically refers to the time period when the Package Manager Service (PMS) is performing application scanning and parsing (i.e., "package scanning"). When the system_server process starts, the first time period begins, and the application process is preloaded through Zygote's fork method. When the start of the package scanning time period managed by the package service is detected, the second time period begins, and the system will immediately pause the creation of the application process currently being created by Zygote's fork. The entire sequence is as follows. Figure 3 As shown, when the monitoring (such as monitoring the persistent flag of the scan process lifecycle of the package service management, receiving global broadcast notifications issued by the system, or detecting that the system service status has become available through polling) reaches the end of the package service management scan time period, the second time period ends, and the application process creation process continues until the Activity Manager service is fully ready, marking the end of the first time period. The first time period and the second time period do not overlap.

[0026] Step S203: Upon receiving the request to launch the target application, query the Activity Management Service to see if the target application process has been pre-created. For details, please refer to [link to relevant documentation]. Figure 1 Step S103 of the illustrated embodiment will not be described again here.

[0027] Step S204: If the target application process has already been pre-created, start the target application by reusing the target application process through the activity management service. For details, please refer to [link to relevant documentation]. Figure 1 Step S104 of the illustrated embodiment will not be described again here.

[0028] The packet scanning or application scanning phase of Packet Service Management (PMS) is a CPU and I / O intensive operation that consumes significant hardware resources and may cause brief system lags during application startup or installation. This embodiment provides an application loading method that serializes resource contention, ensuring system stability and smoothness at critical moments. It avoids intense competition for limited system I / O bandwidth and CPU computing resources, which could drastically reduce the loading speed of all processes and even cause system lag. By allowing pre-loading processes to wait for the PMS process to complete, the system can centrally allocate resources to a single process, enabling it to quickly complete loading and release resources. This not only avoids congestion and shortens the loading time of individual processes but also ensures the smoothness of the overall system response, effectively preventing avalanche effects caused by resource contention, especially in high-load vehicle infotainment systems.

[0029] In one optional implementation, step S2021 includes: Step a1: Listen to the preset flag bit within the key time window; Step a2: Define the time period corresponding to the first value of the preset flag as the first time period. The preset flag is controlled by the package management service and is used to indicate the status of the package management service. The first value indicates that the package management service is in a non-running state. Step a3: Define the time period corresponding to the second value of the preset flag as the second time period. The second value indicates that the packet management service is in the packet scanning state.

[0030] In one example, firstly, in the vehicle's persistent storage space (such as SharedPreferences in Android or a local file), there is a specific key-value pair. This key-value pair is the first value of a preset flag, which has an initial state (e.g., not started). When the critical time window begins, the system starts listening to this preset flag. At this time, the preset flag is at the first value, and the application process creation process begins. When the PMS (Package Management System) scanning period begins, the flag is changed to the second value. After the system detects this change, it immediately pauses the application process creation, indicating that PMS scanning is in progress. After the PMS scanning ends, the flag is reset to the first value, and the process pre-creation process resumes execution, continuing until the critical time window ends.

[0031] Through the above steps, this embodiment of the invention can utilize persistent flags to clearly monitor the system's state, enabling the system to remember its state and dynamically adjust its strategies. This makes the pre-incubation behavior of the process incubator no longer static, accurately starting and pausing the aforementioned application creation process. When the flag changes, the monitoring mechanism can immediately trigger the pause or continuation of the pre-incubation process, thereby achieving precise and intelligent resource allocation, avoiding resource conflicts, and maximizing the startup acceleration effect.

[0032] In one alternative implementation, the steps of creating an application process include: Step b1: Send an incubation instruction to the process incubator through the first service. The first service is a service developed independently within the system service process.

[0033] Step b2: In response to the incubation command, the application process is created through the process incubator.

[0034] Specifically, in this embodiment of the invention, a new or extended optimization service is first added to the system_server, such as... Figure 3 and Figure 4 As shown, PreLoadManager, as the first newly added service, sends a special incubation instruction to the Zygote process incubator through a preset communication channel (such as a dedicated interface based on Binder) after detecting the opening of a critical time window. The instruction includes the priority identifier of the target application (such as "vehicle system core application"), the scope of preloaded resources (such as framework shared libraries, high-frequency application dex cache path) and startup timing parameters (such as "idle resource threshold trigger"), triggering Zygote to complete the preloading of the core resources of the specified application process in advance during the system resource idle period, thereby shortening the actual startup time of the application.

[0035] Afterwards, the process incubator receives the incubation instruction sent by the optimization service and completes the application process creation according to the preset logic. The process incubator first extracts the package name, resource path and priority parameters of the target application through the instruction parsing module, and then calls the "fork() system call" based on the copy-on-write mechanism to create an independent child process. After the process initialization is completed, Zygote sends a process creation ready signal to the optimization service through Binder communication, and at the same time transfers the process control to the application main thread to complete the incubation and creation of the application process.

[0036] This invention, through the priority identifier of "core in-vehicle applications" in the instructions, can selectively list high-frequency applications such as navigation, voice control, and music as pre-loading targets. Combined with Zygote's resource pre-loading capabilities, resource utilization efficiency is maximized, avoiding hardware idle waste. The optimized service can dynamically judge the system load (such as CPU idle rate, memory idle time) and start pre-loading, converting originally idle hardware resources into pre-loaded computing power. At the same time, it avoids competing for resources with critical applications when resources are scarce, ensuring that the in-vehicle system runs smoothly without lag or delay. The pre-loading scope is controllable, reducing system memory overhead. Zygote only loads core necessary resources, not all resources, and reuses shared resources through the "copy-on-write" mechanism, further reducing memory redundancy when multiple applications run simultaneously, adapting to the limited hardware resource environment of the in-vehicle system. Service logic is decoupled. The newly added "PreLoadManager" is an independent service, decoupled from the core logic of AMS and Zygote. If the preloading strategy needs to be adjusted in the future (such as adding high-frequency applications or modifying resource thresholds), only the service configuration and command parameters need to be updated. There is no need to modify the underlying code of AMS or Zygote, which reduces the system iteration and maintenance costs. At the same time, it supports the customization of personalized preloading schemes for different vehicle models.

[0037] In one alternative implementation, step b1 includes: Step b11: Obtain the list of preset applications through the first service.

[0038] Step b12 involves generating incubation instructions for applications configured in the preset application list via the first service and sending these instructions to the process incubator. Specifically, this involves obtaining the system's built-in configurable "high-priority application list" through PreLoadManager, such as... Figure 4 As shown, Preloadlist.txt is the configurable "high-priority application list." This table is a preset application list used to define which applications need to be pre-initialized, such as desktop, 3D car model, navigation, etc. Each record in this list can include, for example, package name and priority. The configured application list is located in the PreLoadManager module of the system, as shown below. Figure 4 As shown, when the incubation process begins, incubation instructions are generated based on the data in the list, and special incubation instructions are sent to the incubator.

[0039] This invention provides core advantages such as flexible configuration and proactive resource allocation by allowing the process incubator to pre-incubate applications through a preset application list. The system can pre-complete some initialization steps (such as pre-loading class loaders or key classes) based on user habits or scenario requirements (e.g., preset navigation, music, and other commonly used applications), achieving an instant "click-to-open" startup experience. This strategy transforms resource allocation from passive response to proactive management, significantly improving the responsiveness and user experience of the vehicle's infotainment system.

[0040] In one alternative implementation, an application process is created via a process incubator in response to an incubation command, including: Step c1: Create at least one of the following: a class loader for the application process, a Java class, and a native .so library.

[0041] In one example, the process incubator responds to an incubation command by creating an application-specific class loader. After the incubator forks a child process, it retrieves application information within the newly created application process. The system parses the target application's package name, data directory, and other information from the incubation command, constructs a class loader to load and initialize key Java classes, and loads necessary Java classes sequentially. Specifically, the system first loads, instantiates, and calls the `onCreate()` method of the `Application` class declared in the target application's manifest file as the application-level initialization entry point, performing global initialization work (such as initializing third-party SDKs). Subsequently, the main component classes are loaded, and the system loads the root `Activity` class that will be launched soon. This process involves class linking (verification, preparation, and resolution) and initialization (execution of static code blocks). Additionally, if the application contains native code, the system loads the corresponding shared object (.so) library. After completing the code environment initialization, a resource manager is created; for example, the system constructs the resource manager by creating `ResourcesManager` and `Resources` objects. This manager loads the resources.arsc resource index table from the target APK, establishes a mapping between resource IDs and specific content, and automatically selects the most suitable resource version based on the current device configuration (such as screen density, language, etc.). It also loads system framework resources to ensure that the application can correctly reference and use the system's standard themes and styles.

[0042] Based on the above technical means, this embodiment of the invention achieves rapid application process startup through an efficient reuse mechanism. The process incubator preloads the core libraries and resources of the Android framework at startup. When a new process is created in response to the incubation command, based on the already prepared shared memory state inherited by the forked child process, only the application-specific parts (such as business Java classes and SO libraries) need to be incrementally loaded and initialized. The process preloading method provided by this embodiment of the invention minimizes repetitive overhead, enabling new application processes to skip a large amount of basic preparation work and directly enter the running state, thereby significantly improving the response speed of application cold starts in the vehicle system.

[0043] In an optional implementation, step S203 further includes: Step d1: If the target application process has not been created, notify the process incubator to create the target application process through the activity management service, and start the target application based on the target application process.

[0044] Specifically, when the system determines that the target application process has failed to complete creation, the system's activity management service issues an explicit instruction to the process incubator, which is responsible for process management, notifying it to create a brand new process for the target application. Upon receiving the instruction, the process incubator performs a series of low-level operations, such as allocating memory space and initializing the runtime environment, thereby completing the creation of the target application process. Once this process is ready, the system then starts and runs the target application based on this newly created process.

[0045] In this embodiment of the invention, by coordinating and scheduling among core services, the problem of process creation failure or delay is proactively intervened and resolved, thereby ensuring the robustness of the application startup process and the interactive experience of the end user.

[0046] Figure 5 A schematic diagram of an embodiment of an application loading device according to the present invention is shown. Figure 5 As shown, the device 500 includes: The critical time window identification module 501 is used to listen for critical time windows during startup. The critical time window is the time window from the start of the system service process to the full readiness of the Activity Manager service.

[0047] Incubator module 502 is used to incubate application processes that need to be created in advance.

[0048] The status query module 503 is used to query whether the target application process has been created by the activity management service when a request to start the target application is received.

[0049] The process reuse and startup module 504 is used to reuse the target application process and start the target application through the activity management service if the target application process has already been created.

[0050] In one alternative embodiment, incubator module 502 includes: The status monitoring unit is used to determine the current time period used to represent the working status within a critical time window.

[0051] The process creation unit is used to execute the application process creation task within the first time period if the current time period is the first time period.

[0052] The resource avoidance unit is used to pause the application process creation task during the second time period if the current time period is the second time period, which is the packet scanning time period of the packet management service.

[0053] In one alternative approach, the status monitoring unit includes: The flag monitoring subunit is used to monitor preset flags within a critical time window.

[0054] The first time period determination subunit is used to define the time period corresponding to the first value of the preset flag bit as the first time period. The preset flag bit is controlled by the package management service and is used to indicate the status of the package management service. The first value indicates that the package management service is in a non-running state.

[0055] The second time period determination subunit is used to define the time period corresponding to the preset flag bit as the second value as the second time period. The second value indicates that the packet management service is in the packet scanning state.

[0056] In an alternative factual approach, the incubator module 502 further includes: The first incubation instruction sending unit is used to send incubation instructions to the process incubator through the first service, which is a service independently developed within the system service process.

[0057] The incubation instruction response unit is used to create application processes in response to incubation instructions via the process incubator.

[0058] In an alternative embodiment, the first incubation instruction sending unit further includes: The "Get Preset Application List" unit is used to obtain a preset application list through the first service.

[0059] The instruction generation and second incubation instruction sending unit is used to generate incubation instructions for applications configured in the preset application list through the first service, and send the incubation instructions to the process incubator.

[0060] In one alternative approach, the responding unit to the incubation instruction includes: A loading unit is used to create at least one of the following: a class loader for the application process, a Java class, and a native .so library.

[0061] In one alternative implementation, after the status query module, the system further includes: The application startup module is used to notify the process incubator to create the target application process if the target application process has not been created, and to start the target application based on the target application process.

[0062] Improve startup and response speed by preloading core application classes, resources, or data into memory, eliminating the need for lengthy initialization processes when users click, achieving a "lightning-fast" experience. Optimize system resource utilization by preloading when the system is relatively idle, avoiding multiple applications competing for CPU and I / O resources during peak periods, and smoothing system load.

[0063] Figure 6 The diagram shows a structural schematic of an embodiment of an application loading device according to the present invention. The specific embodiments of the present invention do not limit the specific implementation of an application loading device.

[0064] like Figure 6 As shown, the application loading device may include: a processor 602, a communications interface 604, a memory 606, and a communications bus 608.

[0065] The processor 602, communication interface 604, and memory 606 communicate with each other via communication bus 608. Communication interface 604 is used to communicate with other network elements such as clients or other servers. The processor 602 executes program 610, specifically performing the steps described above in an embodiment of an application loading method.

[0066] Specifically, program 610 may include program code, which includes computer-executable instructions.

[0067] Processor 602 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. An application loading device may include one or more processors of the same type, such as one or more CPUs; or it may include processors of different types, such as one or more CPUs and one or more ASICs.

[0068] Memory 606 is used to store program 610. Memory 606 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0069] This invention provides a computer-readable storage medium storing at least one executable instruction that, when executed on an application loading device / apparatus, causes the application loading device / apparatus to perform an application loading method according to any of the above method embodiments.

[0070] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Furthermore, the embodiments of this invention are not directed to any particular programming language.

[0071] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. Similarly, for the sake of brevity and to aid in understanding one or more aspects of the invention, in the description of exemplary embodiments of the invention above, various features of the embodiments are sometimes grouped together in a single embodiment, figure, or description thereof. The claims, which follow the detailed description, are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0072] Those skilled in the art will understand that the modules in the device of the embodiment can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiment can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components, except that at least some of such features and / or processes or units are mutually exclusive.

[0073] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. An application loading method, characterized in that, The method includes: Listen for a critical time window during startup, which is the time window from the start of the system service process to the full readiness of the Activity Manager service; Create the application process within the critical time window; When a request to launch the target application is received, the activity management service is used to query whether the target application process has been created. If the target application process has already been created, the target application is started by reusing the target application process through the activity management service.

2. The method according to claim 1, characterized in that, Creating the application process within the critical time window includes: Within the critical time window, determine the current time period used to represent the work status; If the current time period is the first time period, then the application process creation task is executed within the first time period; If the current time period is the second time period, then the application process creation task is paused during the second time period, which is the package management service's package scanning time period.

3. The method according to claim 2, characterized in that, Within the critical time window, the current time period used to represent the work status is determined, including: Listen to the preset flag bit within the key time window; The time period corresponding to the first value of the preset flag bit is defined as the first time period. The preset flag bit is controlled by the package management service and is used to indicate the status of the package management service. The first value indicates that the package management service is in a non-running state. The time period corresponding to the preset flag bit and the second value is defined as the second time period, and the second value indicates that the package management service is in the package scanning state.

4. The method according to claim 1 or 2, characterized in that, Creating the application process within the critical time window includes: Send incubation instructions to the process incubator through the first service, which is a service developed independently within the system service process; The application process is created by the process incubator in response to the incubation instruction.

5. The method according to claim 4, characterized in that, Sending incubation instructions to the process incubator via the first service includes: Obtain a list of preset applications through the first service; The first service generates the incubation instruction for the application configured in the preset application list and sends the incubation instruction to the process incubator.

6. The method according to claim 4, characterized in that, The process incubator creates the application process in response to the incubation instruction, including: Create at least one of the following: a class loader, a Java class, and a native .so library, which includes the application process.

7. The method according to claim 1, characterized in that, After querying the activity management service to see if the target application process has been created when a request to launch the target application is received, the method further includes: If the target application process has not been created, the process incubator is notified through the activity management service to create the target application process, and the target application is launched based on the target application process.

8. An application loading device, characterized in that, The device includes: The critical time window identification module is used to identify the start and end of critical time windows; The incubator module is used to incubate application processes that need to be created; The status query module is used to query whether the target application process of the target application has been created through the activity management service when a request to start the target application is received. The process reuse and startup module is used to start the target application by reusing the target application process through the activity management service if the target application process has been created.

9. An electronic device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation of an application loading method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores at least one executable instruction, which, when executed on an application loading device / apparatus, causes the application loading device / apparatus to perform the operation of an application loading method as described in any one of claims 1-7.

Images