Application startup method and related apparatus

Abstract

An application startup method and a related apparatus, which are applied to the technical field of operating systems. The application startup method comprises: initializing a first operating system, acquiring a first image file, and on the basis of the first operating system and the first image file, restoring a second operating system to a first startup-completed state and restoring a first application to a second startup-completed state. The first image file comprises information indicating that the second operating system is in the first startup-completed state and information indicating that the first application is in the second startup-completed state, and the size of a binary file of the first operating system is smaller than the size of a binary file of the second operating system. In the present method, a first operating system having a smaller size than a second operating system is used to replace the second operating system, so that the time consumed in loading the second operating system, initializing the second operating system and loading an initial memory file system of the second operating system can be reduced, thereby shortening the latency for restoring a first application to a startup-completed state.

Description

Application startup method and related devices Technical Field

[0001] This application relates to the field of operating system technology, and in particular to an application startup method and related apparatus. Background Technology

[0002] Embedded software (also known as embedded applications) refers to software that runs on embedded systems. It is tightly integrated with the hardware and used to control, monitor, or assist the operation of embedded devices. Embedded systems are often used in critical fields such as medical devices, automotive electronics, and aerospace. Therefore, embedded software needs to possess high reliability, respond quickly and accurately to external events, and has strict real-time requirements. For example, in flight control systems in aerospace and production control equipment in industrial automation, embedded software must complete its tasks within a specified time; otherwise, serious consequences may result.

[0003] Generally, embedded software requires fast startup, with a desired startup latency of less than 5 seconds or even less. However, more complex embedded software typically uses Linux as its operating system, and Linux-based embedded software suffers from prolonged startup times, generally reaching around 15 seconds.

[0004] Therefore, a feasible solution is urgently needed to address the problem of prolonged startup time for embedded software. Summary of the Invention

[0005] This application provides an application startup method and related apparatus, which can shorten the startup latency of embedded software and solve the problem of prolonged startup time for embedded software.

[0006] In a first aspect, embodiments of this application provide an application launch method, which includes:

[0007] The process initializes a first operating system, obtains a first image file, and restores a second operating system to a first boot-complete state and a first application to a second boot-complete state based on the first operating system and the first image file. The first image file includes information about the second operating system in the first boot-complete state and information about the first application in the second boot-complete state. The size of the binary file of the first operating system is smaller than the size of the binary file of the second operating system.

[0008] This application provides an application startup method that replaces the second operating system with a first operating system that is smaller in size than the second operating system. The first operating system and a first image file are used to restore the second operating system and the first application to a startup completion state. This eliminates the time spent loading, initializing, and initializing the memory file system of the second operating system, thereby shortening the latency from the first application to the startup completion state. Optionally, when the second operating system is Linux and the first application is an embedded application, the application startup method in this application can shorten the startup latency of the embedded application, solving the problem of prolonged embedded application startup.

[0009] Optionally, initializing the first operating system may refer to initializing the data and state of the first operating system, and this application embodiment does not limit this.

[0010] Optionally, when the second operating system is Linux, the first operating system may specifically be a real-time operating system (RTOS).

[0011] Optionally, the first image file can be an image file prepared after the second operating system has finished booting and is in the first boot completion state and the first application has finished booting and is in the second boot completion state. It can be stored in a backup partition, such as in a backup swap partition.

[0012] In one possible implementation, the binary file of the first operating system includes a first function required to restore the second operating system to a first boot completion state based on the first image file and to restore the first application to a second boot completion state. The binary file of the second operating system includes a second function required to start the second operating system and the first application, and the second function is more than the first function.

[0013] In this embodiment, the binary file of the second operating system includes more functions than the binary file of the first operating system. Therefore, the size of the binary file of the first operating system is smaller than that of the binary file of the second operating system. The time required to load and initialize the first operating system is shorter. Thus, using the first operating system to replace the second operating system can shorten the latency from the first application to the startup completion state.

[0014] Optionally, the first operating system can be regarded as a lightweight operating system with reduced functionality from the second operating system. The first operating system can also be regarded as a lightweight operating system with fewer functions that is independent of the second operating system. This application embodiment does not limit this.

[0015] In one possible implementation, the second function includes the functions required to start the second operating system and the first application, as well as the functions required to support the operation of the second operating system and the first application.

[0016] In this embodiment, the second function includes not only the functions required to start the second operating system and the first application, but also the functions required to support the operation of the second operating system and the first application. The first function does not include the functions required to support the operation of the second operating system and the first application. Therefore, the size of the binary file of the first operating system is smaller than that of the binary file of the second operating system, and the time required to load and initialize the first operating system is shorter. Thus, using the first operating system to replace the second operating system can shorten the latency from the first application to the startup completion state.

[0017] In one possible implementation, the first operating system is loaded under the instruction of a first boot command before initialization, the first boot command being used to instruct the launch of a first application.

[0018] In this embodiment, the first startup instruction is used to indicate the need for rapid application startup. Therefore, under the instruction of the first startup instruction, the first operating system is loaded. Specifically, the first operating system can be loaded by a bootloader, and then the user is redirected to the program entry point of the first operating system. Compared to loading a second operating system, the time required to load the first operating system can be significantly reduced.

[0019] Optionally, loading the first operating system may refer to loading the binary file of the first operating system (e.g., the data segment and code segment of a program) into memory, and this application embodiment does not limit this.

[0020] Optionally, the first boot command may be received when the device is powered on or after the central processing unit (CPU) has been reset, thereby enabling the loading of the first operating system in response to the first boot command.

[0021] In one possible implementation, the restoration of the second operating system to the first boot completion state and the restoration of the first application to the second boot completion state can be achieved, but is not limited to, the following methods: decompressing the memory pages in the first image file and writing the decompressed data to the addresses of the memory pages in physical memory; outputting the starting address of the page table, which is used to manage the addresses of memory pages in physical memory; and indicating the entry address for jumping to the second operating system in the first boot completion state and the entry address for the first application in the second boot completion state.

[0022] In this embodiment, a possible specific implementation is provided for restoring a second operating system and a first application to a startup completion state using a first operating system and a first image file. By decompressing the memory pages in the first image file and writing the decompressed data to the corresponding address, the second operating system can be restored to a first startup completion state, and the first application can be restored to a second startup completion state, thereby achieving the purpose of quickly starting the first application.

[0023] In one possible implementation, the application startup method described above may also include, but is not limited to, the following steps: verifying the integrity check code corresponding to the decompressed data. The starting address of the output page table can be specifically implemented in ways including, but not limited to, the following manner: if the integrity check code corresponding to the decompressed data passes verification, output the starting address of the page table.

[0024] In this embodiment, the integrity of the data after decompressing the memory pages in the first image file can also be verified to ensure the correctness of restoring the second operating system to the first boot completion state and restoring the first application to the second boot completion state.

[0025] In one possible implementation, the first image file includes multiple memory pages, and the application startup method may further include, but is not limited to, the following steps: creating at least two threads. The decompression of the memory pages in the first image file and the writing of the decompressed data to the address of the memory page in physical memory can be implemented in ways including but not limited to: decompressing the first memory page in the first image file based on the first thread of the at least two threads, and writing the decompressed data to the address of the first memory page in physical memory; decompressing the second memory page in the first image file based on the second thread of the at least two threads, and writing the decompressed data to the address of the second memory page in physical memory, wherein the first thread and the second thread are different.

[0026] In this embodiment, multiple threads can be created to decompress multiple memory pages in the first image file in parallel and write them to the corresponding addresses, thereby further shortening the time for restoring the second operating system to the first boot completion state and restoring the first application to the second boot completion state, thus achieving the goal of quickly starting the first application.

[0027] Optionally, the first memory page may include one memory page or multiple memory pages, and this application embodiment does not limit this.

[0028] Optionally, the second memory page may include one memory page or multiple memory pages, and this application embodiment does not limit this.

[0029] In one possible implementation, the aforementioned at least two threads further include a third thread, and the application startup method may also include, but is not limited to, the following steps: verifying the integrity checksum corresponding to the decompressed data based on the third thread. The aforementioned output page table starting address can be implemented in ways including, but not limited to, the following manner: outputting the starting address of the page table if the integrity checksum corresponding to the decompressed data passes verification.

[0030] In this embodiment, a third thread among the multiple threads created can be used to verify the integrity check code corresponding to the decompressed data. This allows for the simultaneous decompression of multiple memory pages in the first image file in batches while verifying the integrity of the decompressed data. This further reduces the time required to restore the second operating system to the first boot completion state and the first application to the second boot completion state.

[0031] In one possible implementation, the number of threads in the at least two threads does not exceed the number of cores in the multi-core central processing unit used to execute the application startup method.

[0032] In this embodiment, since the parallel operation of multiple threads depends on the multi-core performance of the central processing unit, the number of threads of the aforementioned at least two threads does not exceed the number of cores of the multi-core central processing unit used to execute the application startup method.

[0033] In one possible implementation, the applications running on the second operating system include a first application and a second application, wherein the second application starts after the first application starts.

[0034] In this embodiment, the startup speed requirements of applications running on the second operating system are divided. Applications with fast startup requirements are classified as first applications, and other applications with low startup speed requirements are classified as second applications. By adjusting the execution order and initialization order of the startup scripts corresponding to the first and second applications, the first application can be started first and the second application can be started later.

[0035] In one possible implementation, the first image file is obtained from information about the state of the first application after it has been loaded and initialized. The first application is loaded and initialized under the instruction of a first startup script, which is used to initialize the components that the first application depends on for running.

[0036] In this embodiment, by adjusting the execution order of the startup scripts corresponding to the first application and the second application, the first application can be started first and the second application can be started later. Therefore, the first image file can be prepared immediately after the first application is started (before the second application is started), so that the first image file includes information that the first application is in the startup completed state, but does not include information that the second application is in the startup completed state. This further compresses the file size of the first image file, thereby further shortening the time required to restore the second operating system to the first startup completed state and restore the first application to the second startup completed state based on the first image file, achieving the goal of quickly starting the first application.

[0037] Optionally, the second application is loaded and initialized under the instruction of the second startup script, which is executed after the execution of the first startup script.

[0038] In one possible implementation, the size of the first image file is less than a first threshold, and / or the size of the binary file of the first operating system is less than a second threshold.

[0039] In this embodiment, when the size of the first image file is less than a certain threshold, and / or the size of the binary file of the first operating system is less than a certain threshold, the time required to restore the second operating system to the first boot completion state and the first application to the second boot completion state based on the first operating system and the first image file can be shortened, thereby enabling the first application to start faster.

[0040] Secondly, embodiments of this application provide an application launching device, which includes a unit for performing the method as described in any of the first aspects.

[0041] In one possible design, the device includes:

[0042] The processing unit is used to initialize the first operating system.

[0043] The processing unit is also used to obtain a first image file, which includes information about the second operating system being in a first boot completion state and information about the first application being in a second boot completion state. The size of the binary file of the first operating system is smaller than the size of the binary file of the second operating system.

[0044] The processing unit is also configured to restore the second operating system to the first boot completion state based on the first operating system and the first image file, and to restore the first application to the second boot completion state.

[0045] In one possible implementation, the device further includes a communication unit.

[0046] The processing unit is specifically used to obtain the first image file through the communication unit.

[0047] Regarding the processing unit and communication unit described in the second aspect and any possible implementation, the steps performed thereon can be referred to the corresponding implementations in the first aspect.

[0048] For the technical effects of the second aspect and any possible implementation, please refer to the description of the technical effects corresponding to the first aspect and the corresponding implementation.

[0049] Optionally, in the application launching device described in the second aspect above and any possible implementation:

[0050] In one implementation, the application launcher is an application launch device. When the application launcher is an application launch device, the communication unit can be a transceiver or an input / output interface; the processing unit can be at least one processor. Optionally, the transceiver can be a transceiver circuit. Optionally, the input / output interface can be an input / output circuit.

[0051] In another implementation, the application startup device is a chip (system) or circuit used in the application startup device. When the application startup device is a chip (system) or circuit used in the application startup device, the communication unit can be a communication interface (input / output interface), interface circuit, output circuit, input circuit, pin, or related circuit on the chip (system) or circuit; the processing unit can be at least one processor, processing circuit, or logic circuit.

[0052] Thirdly, embodiments of this application provide an application launching device, which includes a processor. The processor is coupled to a memory and can be used to execute instructions in the memory to implement the methods described in the first aspect and any of the possible implementations. Optionally, the application launching device further includes a memory. Optionally, the application launching device further includes a communication interface, and the processor is coupled to the communication interface.

[0053] Fourthly, embodiments of this application provide a chip, including: logic circuitry and a communication interface. The communication interface is used to receive or send information; the logic circuitry is used to receive or send information through the communication interface, causing the chip to execute the methods described in the first aspect and any of the possible implementations.

[0054] Fifthly, embodiments of this application provide a computer-readable storage medium for storing a computer program (also referred to as code or instructions); when the computer program is run on a computer, the methods described in the first aspect and any possible implementation are implemented.

[0055] Sixthly, embodiments of this application provide a computer program product, the computer program product comprising: a computer program (also referred to as code or instructions); and, when the computer program is run, causing a computer to perform the methods described in the first aspect and any possible implementation thereof.

[0056] In a seventh aspect, embodiments of this application provide a domain controller, which includes a first operating system for executing the methods described in the first aspect and any possible implementation thereof.

[0057] Optionally, the domain controller may also include a second operating system as described in the first aspect and any of the possible implementations above.

[0058] Eighthly, embodiments of this application provide a terminal that includes at least one application launcher as described in the second aspect, or the application launcher as described in the third aspect, or the chip as described in the fourth aspect, or the domain controller as described in the seventh aspect.

[0059] Optionally, the terminal can be a means of transportation, such as a car, truck, aircraft, drone, slow transport vehicle, spacecraft, or ship, or any other possible means of transportation used in any possible scenario. This application embodiment does not limit this.

[0060] Optionally, the terminal is used to implement the method described in the first aspect and any possible implementation.

[0061] Furthermore, in the process of performing the method described in the first aspect and any possible implementation above, the processes related to sending and / or receiving information in the above methods can be understood as the process of the processor outputting information, and / or the process of the processor receiving input information. When outputting information, the processor can output the information to a transceiver (or communication interface, or transmitting module) so that the transceiver can transmit it. After the information is output by the processor, it may need to undergo other processing before reaching the transceiver. Similarly, when the processor receives input information, the transceiver (or communication interface, or transmitting module) receives the information and inputs it to the processor. Furthermore, after the transceiver receives the information, the information may need to undergo other processing before being input to the processor.

[0062] Based on the above principles, for example, the information sent mentioned in the aforementioned method can be understood as information output by the processor. Similarly, the information received can be understood as information received by the processor from input.

[0063] Optionally, unless otherwise specified, or unless they contradict their actual function or internal logic in the relevant description, the operations of the processor, such as transmitting, sending, and receiving, can be more generally understood as processor output and receiving, input, and other operations.

[0064] Optionally, in performing the methods described in the first aspect and any possible implementation above, the processor may be a processor specifically designed to perform these methods, or it may be a processor that performs these methods by executing computer instructions stored in memory, such as a general-purpose processor. The memory may be a non-transitory memory, such as read-only memory (ROM), which may be integrated with the processor on the same chip or disposed on different chips. This application does not limit the type of memory or the arrangement of the memory and processor.

[0065] In one possible implementation, at least one of the aforementioned memories is located outside the device.

[0066] In yet another possible implementation, at least one of the aforementioned memories is located within the device.

[0067] In another possible implementation, a portion of the memory of the at least one memory is located inside the device, while another portion is located outside the device.

[0068] In this application, the processor and memory may also be integrated into a single device, that is, the processor and memory can be integrated together. Attached Figure Description

[0069] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0070] Figure 1 is a schematic diagram of an application startup process provided in an embodiment of this application;

[0071] Figure 2 is a schematic diagram of another application startup process provided in an embodiment of this application;

[0072] Figure 3 is a schematic diagram of the architecture of an application startup system provided in an embodiment of this application;

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

[0074] Figure 5 is a flowchart illustrating another application launch method provided in an embodiment of this application;

[0075] Figure 6 is a flowchart illustrating another application startup method provided in an embodiment of this application;

[0076] Figure 7 is a schematic diagram of a process for preparing an image file according to an embodiment of this application;

[0077] Figure 8 is a schematic diagram of an application launch device provided in an embodiment of this application;

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

[0079] Figure 10 is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0080] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described below with reference to the accompanying drawings.

[0081] The terms "first" and "second," etc., used in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0082] The term "embodiment" as used herein means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that, unless otherwise specified or logically conflicting, the terminology and / or descriptions between the various embodiments of this application are consistent and can be mutually referenced, and technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0083] It should be understood that in this application, "at least one (item)" means one or more, "more than one" means two or more, "at least two (items)" means two or three or more, and "and / or" is used to describe the relationship between related objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0084] It should be noted that, in this application, "instruction" can include direct instruction, indirect instruction, explicit instruction, and implicit instruction. When describing a certain instruction information for the purpose of instructing A, it can be understood that the instruction information carries A, directly instructs A, or indirectly instructs A.

[0085] In this application, the information indicated by the instruction information is called the information to be instructed. In specific implementations, there are many ways to indicate the information to be instructed, such as, but not limited to, directly indicating the information to be instructed, such as the information to be instructed itself or its index. It can also indirectly indicate the information to be instructed by indicating other information, where there is a correlation between the other information and the information to be instructed. It can also indicate only a part of the information to be instructed, while the other parts are known or pre-agreed upon. For example, the instruction of specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement of various information, thereby reducing instruction overhead to some extent. The information to be instructed can be sent as a whole or divided into multiple sub-information units, and the sending period and / or timing of these sub-information units can be the same or different. This application does not limit the specific sending method. The sending period and / or timing of these sub-information units can be predefined, for example, according to a protocol, or configured by the transmitting device by sending configuration information to the receiving device.

[0086] It should be noted that in this application, "send" can be understood as "output" and "receive" can be understood as "input". "Send information to A", where "to A" simply indicates the direction of information transmission, and A is the destination, does not limit "send information to A" to a direct transmission over the air interface. "Send information to A" includes sending information directly to A, as well as sending information indirectly to A through a transmitter. Therefore, "send information to A" can also be understood as "outputting information destined for A". Similarly, "receive information from A" indicates that the source of the information is A, including receiving information directly from A, as well as receiving information indirectly from A through a receiver. Therefore, "receive information from A" can also be understood as "inputting information from A".

[0087] This application provides an application startup method and related apparatus, applicable to the field of operating system technology, such as application startup methods in embedded operating systems (e.g., Linux). To better understand the technical solution of this application, the relevant terms and concepts that may be involved in the embodiments of this application are introduced below.

[0088] An operating system (OS) is a computer program that manages and controls computer hardware and software resources. It is the most basic system software that runs directly on the "bare metal," and all other software or systems must run with the support of the operating system. The operating system is the interface between the user and the computer, as well as the interface between the computer hardware and other software. The functions of an operating system include managing the computer system's hardware, software, and data resources; controlling program execution; improving the human-computer interface; providing support for other application software; maximizing the utilization of all computer system resources; providing various forms of user interfaces to create a good working environment for users; and providing necessary services and corresponding interfaces for the development of other software.

[0089] Linux is an open-source, multi-user, multi-tasking operating system widely used in servers, embedded systems, scientific research, education, and many other fields. Its main components include the kernel, system tools and libraries, the shell, and applications. The kernel is the core of the Linux system, responsible for managing the system's hardware resources, such as CPU, memory, and hard disk, providing functions such as process management, memory management, file system management, and device drivers; it is the foundation for system operation. System tools and libraries include various command-line tools, system management tools, and programming language libraries, providing interfaces for users and applications to interact with the kernel, facilitating system management and software development. The shell is the user interface for interacting with the Linux system; users enter commands through the shell, the system passes the commands to the kernel for execution, and returns the results to the user. Applications are various applications developed based on the Linux system, covering various fields such as office software, graphical interface software, network applications, and database management systems, meeting diverse user needs.

[0090] Linux's hibernation feature, also known as "hibernation," is a power management function that allows the system to save its current running state to disk, then completely shut down, and quickly resume from the state before power-off when power is restored.

[0091] Quick-start applications: Applications that are relatively sensitive to startup time and require to start quickly when the operating system starts up (after power-on) can be called quick-start applications.

[0092] Slow-start applications: Applications that are relatively insensitive to startup time and do not require rapid startup can be called slow-start applications.

[0093] Embedded software, also known as embedded applications, refers to software running on embedded systems. It is tightly integrated with the hardware and used to control, monitor, or assist the operation of embedded devices. Embedded systems are often used in critical fields such as medical devices, automotive electronics, and aerospace. Therefore, embedded software needs to possess high reliability, respond quickly and accurately to external events, and has strict real-time requirements. For example, in flight control systems in aerospace and production control equipment in industrial automation, embedded software must complete its tasks within a specified time; otherwise, serious consequences may result.

[0094] Generally, embedded software requires fast startup, with a desired startup latency of less than 5 seconds or even less. However, more complex embedded software typically uses Linux as its operating system, and Linux-based embedded software suffers from prolonged startup times, generally reaching around 15 seconds.

[0095] Please refer to Figure 1, which is a schematic diagram of an application startup process provided in an embodiment of this application.

[0096] As shown in Figure 1, taking Linux application startup as an example, the main steps include, but are not limited to, the following:

[0097] After power-on, the Linux kernel is loaded and initialized, followed by the initialization RAM file system (initramfs). At this point, Linux has successfully started. Next, the startup script is executed, creating processes to load and initialize applications. The applications have now started.

[0098] In the above application startup process, on the one hand, the Linux image is large in size. Even after trimming, the total size of the two parts of the Linux image, kernel and initramfs, is generally tens of megabytes or even more. This results in a long time to load the Linux kernel, initialize the Linux kernel, and load the initramfs.

[0099] On the other hand, the startup process of applications developed based on Linux is relatively complex. It generally involves several stages, such as executing the startup script, creating a process to load the application, and initializing the application. If it needs to access certain devices or read and write files on the storage medium, the application startup process also needs to load device drivers and mount the file system, which takes a long time.

[0100] Please refer to Figure 2, which is a schematic diagram of another application startup process provided in an embodiment of this application.

[0101] As shown in Figure 2, taking Linux application startup as an example, the main steps include, but are not limited to, the following:

[0102] After power-on, the Linux kernel is loaded, initialized, and the memory file system is mounted and initialized, at which point Linux has completed its startup. Next, it determines whether fast application startup is needed. If not (Case 1), the startup script is executed, a process is created to load the application, and the application is initialized, at which point the application has completed its startup. It is understood that Case 1 is similar to the application startup process in Figure 1 above, and will not be elaborated further here.

[0103] If a quick application launch is required (Scenario 2), the image file is read from the backup swap partition, and the application is restored to its boot-complete state. This image file can be created using Linux's hibernation feature. Specifically, during the power-down process, the application is in a boot-complete state, and an image file is created and saved to the backup swap partition. Then, during the power-on process, the image file is read from the backup swap partition, and the application is restored to its boot-complete state before power-down.

[0104] It is understandable that, compared with the application startup process in Figure 1 above, the optimization effect of this second scenario on application startup latency is reflected in the following: In the power-on process, the method of obtaining the image file from the backup swap partition and restoring the application to the startup completion state based on the image file is adopted, which replaces the normal startup, loading, initialization and other operations of the application, greatly shortening the application startup time.

[0105] However, this second scenario still cannot avoid the Linux kernel loading, Linux kernel initialization, and initramfs loading processes shown in Figure 1. These processes typically take more than 5 seconds to execute, and the larger the Linux image, the longer the process takes. Furthermore, the application startup process shown in Figure 2 only creates the image file and saves it to the backup swap partition after the application is fully initialized. At this point, all application processes have been created and initialized, and all drivers have been loaded. These operations allocate a large amount of memory resources, resulting in a very large final image file. Consequently, restoring the application to its startup state based on this image file still takes a considerable amount of time.

[0106] Therefore, a feasible solution is urgently needed to address the problem of prolonged startup time for embedded software.

[0107] In view of this, embodiments of this application provide an application startup system, and based on the architecture of the application startup system, provide a new application startup method, which is applied to the field of operating system technology, such as the application startup method in embedded operating systems (e.g., Linux), and can shorten the startup latency of embedded software and solve the problem of prolonged startup time of embedded software.

[0108] Please refer to Figure 3, which is a schematic diagram of the architecture of an application startup system provided in an embodiment of this application.

[0109] As shown in Figure 3, the system that this application starts up mainly includes, but is not limited to, the Linux system, disk, and memory.

[0110] The disk includes a backup swap partition used to store the created image files. When an application is in a completed startup state, information about its startup status is recorded in memory. Linux systems include a hibernation feature, which can be used to quickly launch applications.

[0111] Figure 3 shows the process of creating an image file after the application has started and is in the startup complete state, and then saving the created image file to the backup swap partition. Figure 3 also shows the process of reading the image file from the backup swap partition during startup and restoring the application to the startup complete state based on the image file.

[0112] Based on the architecture of this application startup system, the application startup method provided in this application can be executed to shorten the startup latency of embedded software and solve the problem of prolonged startup time for embedded software.

[0113] Please refer to Figure 4, which is a flowchart illustrating an application startup method provided in an embodiment of this application. This application startup method is applied in the field of operating system technology, such as application startup methods in embedded operating systems (e.g., Linux).

[0114] Specifically, the application launch method includes, but is not limited to, the following steps:

[0115] S401: The application startup device initializes the first operating system.

[0116] It is understood that the application startup device in the embodiments of this application can be a device equipped with a processor / chip that can execute computer execution instructions, or it can be a processor / chip that can execute computer execution instructions. Optionally, the application startup device can be an electronic device, or it can be a processor / chip within an electronic device. Optionally, the application startup device can also be a first operating system, used to execute the application startup method in the embodiments of this application, so as to shorten the startup latency of embedded software and solve the problem of prolonged startup time of embedded software.

[0117] Optionally, the application launching device and application launching method in the embodiments of this application can be applied to, but are not limited to, vehicle systems. The vehicle equipped with the vehicle system is an intelligent driving vehicle and can be replaced by a terminal device. The terminal device can be, but is not limited to, vehicles such as commercial vehicles, passenger cars, trains, industrial vehicles (such as forklifts, trailers, tractors, etc.), engineering vehicles (such as excavators, bulldozers, cranes, etc.), robots, etc. The embodiments of this application do not specifically limit this.

[0118] Optionally, initializing the first operating system may refer to initializing the data and state of the first operating system, and this application embodiment does not limit this.

[0119] Optionally, initializing the first operating system may also refer to initializing the functions of the first operating system, including but not limited to initializing memory management functions, initializing thread scheduling functions, initializing inter-thread synchronization functions, etc. This application embodiment does not limit this.

[0120] S402: The application boot device obtains the first image file.

[0121] The first image file includes information about the second operating system being in the first boot completion state and information about the first application being in the second boot completion state. The size of the binary file of the first operating system is smaller than the size of the binary file of the second operating system.

[0122] Optionally, when the second operating system is Linux, the first operating system may specifically be a real-time operating system (RTOS).

[0123] Optionally, the first image file can be an image file prepared after the second operating system has finished booting and is in the first boot completion state and the first application has finished booting and is in the second boot completion state. It can be stored in a backup partition, such as in a backup swap partition.

[0124] S403: The application startup device restores the second operating system to the first startup completion state and the first application to the second startup completion state based on the first operating system and the first image file.

[0125] Optionally, the size of the first image file is less than a first threshold, and / or the size of the binary file of the first operating system is less than a second threshold.

[0126] Optionally, the first threshold and / or the second threshold are not fixed values ​​and can be adjusted according to different application startup speed requirements. This application embodiment does not limit this.

[0127] It is understandable that when the size of the first image file is less than a certain threshold, and / or the size of the binary file of the first operating system is less than a certain threshold, the time required to restore the second operating system to the first boot completion state and the first application to the second boot completion state based on the first operating system and the first image file can be shortened, thereby making the first application start faster.

[0128] By employing a first operating system, smaller in size than the second operating system, to replace the second operating system in this embodiment, and restoring the second operating system and the first application to the boot completion state using the first operating system and the first image file, the time spent loading, initializing, and loading the initialization memory file system of the second operating system can be eliminated, thereby shortening the latency from the first application to the boot completion state. Optionally, when the second operating system is Linux and the first application is an embedded application, the application startup method in this embodiment can shorten the startup latency of the embedded application, solving the problem of prolonged embedded application startup.

[0129] In one possible embodiment, the binary file of the first operating system includes a first function required to restore the second operating system to a first boot completion state based on the first image file and to restore the first application to a second boot completion state. The binary file of the second operating system includes a second function required to start the second operating system and the first application. The second function is more than the first function.

[0130] It is understandable that the binary file of the second operating system contains more functions than the binary file of the first operating system. Therefore, the size of the binary file of the first operating system is smaller than that of the binary file of the second operating system. The time required to load and initialize the first operating system is shorter. Therefore, using the first operating system to replace the second operating system can shorten the latency from the first application to the startup completion state.

[0131] Optionally, the first operating system can be regarded as a lightweight operating system (generally less than 100KB) after functional reduction of the second operating system. The first operating system can also be regarded as a lightweight operating system with fewer functions that is independent of the second operating system. This application embodiment does not limit this.

[0132] Optionally, the second function mentioned above includes the functions required to start the second operating system and the first application, as well as the functions required to support the operation of the second operating system and the first application.

[0133] It is understandable that the second function includes not only the functions required to start the second operating system and the first application, but also the functions required to support the operation of the second operating system and the first application. The first function does not include the functions required to support the operation of the second operating system and the first application. Therefore, the size of the binary file of the first operating system is smaller than that of the binary file of the second operating system, and the time required to load and initialize the first operating system is shorter. Thus, using the first operating system to replace the second operating system can shorten the latency from the first application to the startup completion state.

[0134] In one possible embodiment, prior to step S401 described above, the first operating system is loaded under the instruction of the first boot command.

[0135] The first startup instruction is used to instruct the startup of the first application.

[0136] Optionally, the first startup instruction is used to indicate that the application needs to be launched quickly, so the first operating system is loaded under the instruction of the first startup instruction.

[0137] Optionally, loading the first operating system may refer to loading the binary file of the first operating system (e.g., the data segment and code segment of a program) into memory, and this application embodiment does not limit this.

[0138] Optionally, the bootloader can load the first operating system and then jump to the program entry point of the first operating system.

[0139] It is understandable that, since the size of the binary file of the first operating system is smaller than that of the binary file of the second operating system, the time required to load the first operating system can be greatly reduced compared to loading the second operating system.

[0140] Optionally, the first boot command may be received when the device is powered on or after the central processing unit (CPU) has been reset, thereby enabling the loading of the first operating system in response to the first boot command.

[0141] Optionally, please refer to Figure 5, which is a flowchart illustrating another application launch method provided in an embodiment of this application. It is understood that the steps in the embodiments of this application can be regarded as reasonable modifications or supplements to the embodiments in Figure 4 above; or, it is understood that the application launch method in the embodiments of this application can also be regarded as an embodiment that can be executed independently, and this application does not limit it.

[0142] As shown in Figure 5, after powering on, it is determined whether the application needs to be launched quickly.

[0143] Optionally, the decision on whether to quickly launch the application can be made based on the first startup instruction mentioned above.

[0144] If a fast application startup is not required, the process proceeds sequentially: loading the Linux kernel, initializing the Linux kernel, mounting and initializing the memory file system, executing the startup script, creating a process to load the application, and initializing the application. At this point, the application has finished starting. This is similar to the application startup process shown in Figure 1 above, and will not be elaborated further here.

[0145] If you need to launch the application quickly, perform the following steps in sequence, including but not limited to:

[0146] Step 1: Load the mini OS.

[0147] Optionally, the micro OS can be found in the description of the first operating system mentioned above, which will not be repeated here.

[0148] Alternatively, the bootloader can load the micro OS into memory and then jump to the program entry point of the micro OS.

[0149] Step 2: Initialize the micro OS.

[0150] Optionally, the details of step two can be found in the description of step S401 above, and will not be repeated here.

[0151] Step 3: Read the image file from the backup swap partition and restore the application to the boot completed state.

[0152] Understandably, the application has now started successfully.

[0153] Alternatively, this situation is similar to the application startup process in Figure 4 above, and will not be described again here.

[0154] By using the embodiments of this application, a micro OS that is smaller than Linux is used to replace Linux, and the micro OS and image files are used to restore Linux and applications to the boot-up state. This can save the time spent loading Linux, initializing Linux, and loading the initial memory file system of Linux, thereby shortening the startup latency of embedded applications and solving the problem of prolonged startup time of embedded applications.

[0155] In one possible embodiment, step S403 described above can be implemented in ways including but not limited to the following:

[0156] The application boot device decompresses the memory pages in the first image file and writes the decompressed data to the address of the memory page in physical memory.

[0157] The application startup device outputs the starting address of the page table, which is used to manage the addresses of memory pages in physical memory.

[0158] The application startup device instructs a jump to the entry address of the second operating system in the first startup completion state, and the entry address of the first application in the second startup completion state.

[0159] It is understandable that by decompressing the memory pages in the first image file and writing the decompressed data to the corresponding address, the second operating system can be restored to the first boot completion state, and the first application can be restored to the second boot completion state, thereby achieving the goal of quickly launching the first application.

[0160] Optionally, after the application startup device decompresses the memory pages in the first image file, it can also verify the integrity checksum corresponding to the decompressed data. Accordingly, if the integrity checksum corresponding to the decompressed data passes verification, the application startup device outputs the starting address of the page table.

[0161] Understandably, by verifying the integrity of the data after decompressing the memory pages in the first image file, the correctness of restoring the second operating system to the first boot completion state and restoring the first application to the second boot completion state can be guaranteed.

[0162] In one possible embodiment, the first image file includes multiple memory pages. In this case, the application startup method can use a multi-threaded approach to decompress the multiple memory pages in the first image file in parallel, as specifically implemented below:

[0163] The application launcher creates at least two threads.

[0164] The application startup device, based on the first thread of at least two threads, decompresses the first memory page in the first image file and writes the decompressed data to the address of the first memory page in physical memory.

[0165] The application launch device decompresses the second memory page in the first image file based on the second thread of at least two threads, and writes the decompressed data to the address of the second memory page in physical memory. The first thread and the second thread are different.

[0166] Optionally, the first memory page may include one memory page or multiple memory pages, and this application embodiment does not limit this.

[0167] Optionally, the second memory page may include one memory page or multiple memory pages, and this application embodiment does not limit this.

[0168] Optionally, the number of threads in the aforementioned at least two threads does not exceed the number of cores in the multi-core central processing unit used to execute the application startup method.

[0169] It is understandable that, since the parallel operation of multiple threads depends on the multi-core performance of the central processing unit, the number of threads in the above-mentioned at least two threads shall not exceed the number of cores of the multi-core central processing unit used to execute the application startup method.

[0170] It is understandable that by creating multiple threads and using these threads to decompress multiple memory pages in the first image file in parallel and write them to their corresponding addresses, the time required to restore the second operating system to the first boot completion state and the time required to restore the first application to the second boot completion state can be further shortened, thereby achieving the goal of quickly starting the first application.

[0171] Optionally, the application launcher can also verify the integrity checksum corresponding to the decompressed data based on a third thread out of at least two threads. If the integrity checksum verification of the decompressed data passes, the starting address of the page table is output.

[0172] Understandably, by utilizing a third thread among the multiple threads created to verify the integrity check code corresponding to the decompressed data, it is possible to decompress multiple memory pages in the first image file in batches while simultaneously verifying the integrity of the decompressed data. This can further shorten the time required to restore the second operating system to the first boot completion state and restore the first application to the second boot completion state.

[0173] Optionally, please refer to Figure 6, which is a flowchart illustrating another application launch method provided in an embodiment of this application. It is understood that the steps in the embodiments of this application can be regarded as reasonable modifications or supplements to the embodiments in Figures 4 and 5 above; or, it is understood that the application launch method in the embodiments of this application can also be regarded as an embodiment that can be executed independently, and this application does not limit it.

[0174] As shown in Figure 6, in order to fully utilize the parallel processing capabilities of multi-core CPUs and shorten the time for restoring the application to its startup state, this embodiment creates N auxiliary threads, the same number as the CPU cores, to work in parallel with the main thread to complete processes such as reading, decompressing, and verifying the integrity of the image file. Specifically, this includes, but is not limited to, the following steps:

[0175] Step 1: Extract image parameters from the image file. These image parameters include, but are not limited to: the total number of memory pages contained in the image file, the integrity checksum of all memory pages, the starting address of the memory management unit (MMU) page table, and the address of the entry program that returns the application startup completion status.

[0176] Step 2: Read the write address information corresponding to all memory pages from the image file, that is, the address of each memory page in the physical memory region.

[0177] Step 3: Create N auxiliary threads 1 to N, which are the same number of CPU cores.

[0178] Step 4: The main thread reads memory page data in batches from the image file and notifies auxiliary threads 1 to N-1 to process them one by one. Optionally, after each batch of memory page data is read, an auxiliary thread can be selected sequentially from auxiliary threads 1 to N-1 and notified to perform decompression processing.

[0179] Step 5: Auxiliary threads 1 to N-1 decompress each batch of memory page data, write the decompressed data to the corresponding address, and notify auxiliary thread N to verify.

[0180] Step 6: The auxiliary thread N iteratively calculates the integrity check code for each batch of decompressed memory page data.

[0181] Step 7: Check the final calculated integrity check code. Optionally, the final calculated integrity check code can be compared with the check code extracted from the image file header to verify the integrity of the decompressed data.

[0182] Step 8: Restore the MMU page table. Optionally, the starting address of the MMU page table can be assigned to the page table pointer register for use by the CPU or other electronic components.

[0183] Step 9: Jump to the entry point of the application in the completed startup state and continue running the application.

[0184] It is understood that by using multiple threads to decompress multiple memory pages in the image file in parallel and write them to the corresponding addresses through the embodiments of this application, the time to restore the application to the startup completion state can be further shortened, thereby achieving the purpose of quickly starting the application.

[0185] In one possible embodiment, the applications running on the second operating system include the first application and the second application.

[0186] The second application starts after the first application starts.

[0187] Optionally, the first application may refer to the description of fast-start applications above, and the second application may refer to the description of slow-start applications above.

[0188] It is understandable that the startup speed requirements of applications running on the second operating system can be divided, with applications requiring fast startup classified as first applications and other applications with low startup speed requirements classified as second applications. By adjusting the execution order and initialization order of the startup scripts corresponding to the first and second applications, the first application can be started first and the second application can be started later.

[0189] Optionally, in the vehicle field, the aforementioned first application may include, but is not limited to, surround view quick start application, vehicle history record (VHR) service application, etc.

[0190] The VHR service application is a closed-loop vehicle data service system driven by vehicle component data, encompassing multiple stages from data collection, processing, insight analysis, fault diagnosis, and risk prediction. It provides services such as component status monitoring, alarm management, remote diagnostics, intelligent analysis, and fault / risk warnings based on vehicle component data. Therefore, it is relatively sensitive to startup time, requiring rapid startup when the operating system begins operation (after power-on). The surround-view quick-start application is a function for vehicle-assisted driving, primarily providing real-time images of the vehicle's surroundings to help drivers better observe obstacles and the environment, thereby reducing collision risks and improving driving safety. Therefore, it is also relatively sensitive to startup time, requiring rapid startup when the operating system begins operation (after power-on). By adopting the application startup method in this application, the startup latency of applications such as the surround-view quick-start application and the VHR service application can be shortened, solving the problem of prolonged application startup.

[0191] Understandably, in the vehicle field, fast-start applications based on domain controllers such as intelligent cockpit domain controllers and chassis domain controllers are of great necessity.

[0192] The intelligent cockpit domain controller integrates multiple functions such as the infotainment system, navigation system, and instrument panel display. Quick-start applications enable these functions to be ready immediately after vehicle startup. For example, quick-start navigation allows drivers to immediately obtain route planning and navigation information without waiting for system initialization, improving travel efficiency. Quick-start music applications allow users to enjoy music immediately upon entering the car, creating a comfortable driving atmosphere and avoiding the unpleasant experience of long waits associated with traditional startup methods. In emergency situations, quick-start applications can quickly provide safety-related information and functions. For instance, in the event of a collision or other emergency, the quick-start emergency call application based on the intelligent cockpit domain controller can quickly dial rescue calls and send critical information such as vehicle location to rescue personnel, buying valuable time for rescue. Simultaneously, the quick-start tire pressure monitoring display application allows drivers to immediately understand tire conditions after starting the vehicle, promptly identifying potential safety hazards. Since the intelligent cockpit domain controller needs to handle multiple tasks simultaneously, quick-start applications can optimize system resource allocation, ensuring that critical applications start quickly and operate stably. For example, when the vehicle starts, the quick-start voice assistant application can load rapidly and be ready to receive user commands at any time, without affecting the normal operation of other basic functions such as displaying vehicle status information, thus achieving efficient collaboration of multiple tasks and improving the operating efficiency of the entire cockpit system.

[0193] The chassis domain controller is responsible for controlling the vehicle's chassis system, including the suspension and braking systems. Quick-start applications are crucial for real-time monitoring and adjustment of the chassis system. For example, the Quick-start Electronic Stability Control (ESC) system quickly engages after vehicle startup, monitoring the vehicle's driving status in real time. It intervenes promptly in dangerous situations such as skidding or fishtailing, helping the driver stabilize the vehicle and prevent accidents by applying brakes to individual wheels. The Quick-start Adaptive Suspension system can quickly adjust suspension stiffness and height based on road conditions and driving mode after vehicle startup. For instance, when entering a curve, the adaptive suspension system responds quickly, automatically adjusting suspension parameters to maintain better stability and handling, enhancing the driving experience. For new energy vehicles, the chassis domain controller also involves energy management-related functions such as the battery management system. The Quick-start Battery Management application can immediately monitor and evaluate the battery's status after vehicle startup, including parameters such as battery charge, temperature, and voltage. This provides accurate data for energy distribution and range estimation, helping to optimize energy use, improve energy efficiency, and extend driving range.

[0194] Optionally, the first image file is obtained from information about the state of the first application after it is loaded and initialized. The first application is loaded and initialized under the instruction of the first startup script, which is used to initialize the components that the first application depends on for running.

[0195] Optionally, the second application is loaded and initialized under the instruction of the second startup script, which is executed after the execution of the first startup script.

[0196] Optionally, the loading and initialization of the first and second applications, as instructed by their respective startup scripts, can be performed by the second operating system.

[0197] It is understandable that by adjusting the execution order of the startup scripts corresponding to the first and second applications, the first application can be started first and the second application can be started later. Therefore, the first image file can be prepared immediately after the first application is started (before the second application is started), so that the first image file includes information that the first application is in the startup completed state, but does not include information that the second application is in the startup completed state. This further compresses the file size of the first image file, thereby further shortening the time spent restoring the second operating system to the first startup completed state and restoring the first application to the second startup completed state based on the first image file, achieving the goal of quickly starting the first application.

[0198] Optionally, please refer to Figure 7, which is a schematic flowchart of an image file preparation process provided in an embodiment of this application. It is understood that the steps in the embodiments of this application can be regarded as reasonable modifications or supplements to the embodiments in Figures 4, 5, and 6 above; or, it is understood that the image file preparation process in the embodiments of this application can also be regarded as an embodiment that can be executed independently, and this application does not limit it.

[0199] As shown in Figure 7, the process of restoring the application to the startup completion state using the image file is closely related to the size of the image file; the smaller the image file, the shorter the time required.

[0200] Therefore, in this embodiment of the application, applications are divided into fast-start applications (i.e., the first application mentioned above) and slow-start applications (i.e., the second application mentioned above) according to whether they need to start quickly. By creating an image file from only the state of the fast-start application after it has started, the size of the image file is reduced.

[0201] Furthermore, this application embodiment further divides the startup script into a first startup script and a second startup script. The first startup script is used to initialize the components upon which the quick-start application depends, while the second startup script is used to initialize other components.

[0202] Specifically, the process of creating an image file may include, but is not limited to, the following steps:

[0203] Step 1: Execute the first startup script to complete the initialization of the components that the Quick Start application depends on, such as loading the device drivers that the Quick Start application needs to access and loading the file system that the Quick Start application needs to access.

[0204] Step 2: Load and initialize the Quick Start application.

[0205] Step 3: Initiate Hibernation, prepare the image file, and write the prepared image file to the backup swap partition.

[0206] Step 4: Execute the second startup script to complete the initialization of other components.

[0207] Step 5: Load and initialize the slow-start application.

[0208] It is understood that by adjusting the execution order of the startup scripts corresponding to fast-start and slow-start applications through the embodiments of this application, the fast-start application can be started first and the slow-start application can be started later. Therefore, an image file can be prepared immediately after the fast-start application is started (before the slow-start application is started), so that the image file includes information about the fast-start application being in the startup completed state, but does not include information about the slow-start application being in the startup completed state. This further compresses the file size of the image file, thereby further shortening the time taken to restore the fast-start application to the startup completed state based on the image file, and achieving the purpose of fast application startup.

[0209] The methods of the embodiments of this application have been described in detail above. The following provides an apparatus for implementing any one of the methods in the embodiments of this application. For example, an apparatus is provided that includes a unit (or means) for implementing the steps performed by the device in any of the above methods.

[0210] Please refer to Figure 8, which is a schematic diagram of the structure of an application launch device provided in an embodiment of this application.

[0211] As shown in Figure 8, the application launch device 80 may include a communication unit 801 and a processing unit 802. The communication unit 801 and the processing unit 802 may be software, hardware, or a combination of software and hardware.

[0212] The communication unit 801 can implement sending and / or receiving functions, and can also be described as a transceiver unit. The communication unit 801 can also be a unit integrating an acquisition unit and a sending unit, wherein the acquisition unit is used to implement the receiving function, and the sending unit is used to implement the sending function. Optionally, the communication unit 801 can be used to receive information sent by other devices, and can also be used to send information to other devices.

[0213] In one possible design, the application launch device 80 may correspond to the application launch device in the method embodiments shown in Figures 4 to 7. For example, the application launch device 80 may be an electronic device or a chip within an electronic device. The application launch device 80 may include units for performing the operations performed by the application launch device in the method embodiments shown in Figures 4 to 7, and each unit in the application launch device 80 is for implementing the operations performed by the application launch device in the method embodiments shown in Figures 4 to 7. The descriptions of each unit are as follows:

[0214] Processing unit 802 is used to initialize the first operating system.

[0215] The processing unit 802 is also used to obtain a first image file, which includes information about the second operating system being in a first boot completion state and information about the first application being in a second boot completion state. The size of the binary file of the first operating system is smaller than the size of the binary file of the second operating system.

[0216] The processing unit 802 is also configured to restore the second operating system to the first boot completion state based on the first operating system and the first image file, and to restore the first application to the second boot completion state.

[0217] In one possible implementation, the device further includes a communication unit 801.

[0218] The processing unit 802 is specifically used to obtain the first image file through the communication unit 801.

[0219] Regarding the communication unit 801 and processing unit 802 described in this design, the steps they perform can be referred to the implementation methods corresponding to the application launch device in the method embodiments shown in Figures 4 to 7 above.

[0220] Regarding the technical effects of the implementation methods performed by the communication unit 801 and the processing unit 802 described in this design, please refer to the description of the technical effects corresponding to the method embodiments shown in Figures 4 to 7 above.

[0221] According to embodiments of this application, the various units in the device shown in FIG8 can be individually or entirely merged into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effect of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the electronic device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0222] It should be noted that the implementation of each unit can also refer to the corresponding descriptions of the method embodiments shown in Figures 4 to 7 above.

[0223] The application startup device 80 described in Figure 8 can shorten the startup delay of embedded software and solve the problem of prolonged startup time for embedded software.

[0224] If the application startup device 80 mentioned above can be an electronic device, please refer to the structural schematic diagram of the electronic device shown in Figure 9.

[0225] It should be understood that the electronic device 90 shown in FIG9 is only an example. The electronic device in the embodiments of this application may also include other components, or include components that have similar functions to the various components in FIG9, or may not include all the components in FIG9.

[0226] The electronic device 90 includes a transceiver interface 901 and at least one processor 902.

[0227] The electronic device 90 can correspond to an application startup device. The transceiver interface 901 is used for transmitting and receiving signals, and at least one processor 902 executes program instructions, causing the electronic device 90 to implement the corresponding process of the method executed by the corresponding device in the above method embodiments.

[0228] In one possible design, the electronic device 90 may correspond to the application launch device in the method embodiments shown in Figures 4 to 7 above. For example, the electronic device 90 may be an application launch device or a chip within an application launch device. The electronic device 90 may include components for performing the operations performed by the application launch device in the above method embodiments, and each component in the electronic device 90 is specifically designed to implement the operations performed by the application launch device in the above method embodiments. Specifically, it may be as follows:

[0229] Processor 902 is used to initialize the first operating system.

[0230] The processor 902 is also used to acquire a first image file, which includes information about the second operating system being in a first boot completion state and information about the first application being in a second boot completion state. The size of the binary file of the first operating system is smaller than the size of the binary file of the second operating system.

[0231] The processor 902 is also used to restore the second operating system to the first boot completion state based on the first operating system and the first image file, and to restore the first application to the second boot completion state.

[0232] In one possible implementation, the device further includes a transceiver interface 901.

[0233] The processor 902 is specifically used to obtain the first image file through the transceiver interface 901.

[0234] Regarding the transceiver interface 901 and at least one processor 902 described in this design, the steps performed can be referred to the implementation corresponding to the application startup device in the method embodiments shown in Figures 4 to 7 above.

[0235] For the technical effects of the implementation methods performed by the transceiver interface 901 and at least one processor 902 described in this design, please refer to the description of the technical effects corresponding to the method embodiments shown in Figures 4 to 7 above.

[0236] In the electronic device 90 described in Figure 9, the startup delay of embedded software can be shortened, thus solving the problem of prolonged startup time for embedded software.

[0237] If the application startup device 80 mentioned above can be a chip or a chip system, please refer to the schematic diagram of the chip structure shown in Figure 10.

[0238] As shown in Figure 10, chip 100 includes processor 1001 and interface 1002. The number of processors 1001 can be one or more, and the number of interfaces 1002 can be multiple. It should be noted that the functions of processor 1001 and interface 1002 can be implemented through hardware design, software design, or a combination of both; no restrictions are placed here.

[0239] Optionally, the chip 100 may also include a memory 1003 for storing necessary program instructions and data.

[0240] In this application, processor 1001 can be used to call the implementation program of the application startup method provided in one or more embodiments of this application in the application startup device from memory 1003, and execute the instructions included in the program. Interface 1002 can be used to output the execution result of processor 1001. In this application, interface 1002 can be specifically used to output various messages or information of processor 1001.

[0241] The application launch method provided by one or more embodiments of this application can be referred to the various embodiments shown in Figures 4 to 7 above, and will not be repeated here.

[0242] The processor in this application embodiment can be a central processing unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0243] The memory in this application embodiment is used to provide storage space, in which data such as operating system and computer programs can be stored. The memory includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM).

[0244] According to the method provided in the embodiments of this application, the embodiments of this application also provide a computer-readable storage medium storing a computer program. When the computer program is run on one or more processors, it can implement the method shown in Figures 4 to 7.

[0245] According to the method provided in the embodiments of this application, the embodiments of this application also provide a computer program product, which includes a computer program. When the computer program runs on a processor, it can implement the methods shown in Figures 4 to 7.

[0246] This application also provides a domain controller, which includes a first operating system for executing the methods shown in Figures 4 to 7 above.

[0247] Optionally, the domain controller may also include a second operating system as shown in the methods of Figures 4 to 7 above.

[0248] This application embodiment also provides a terminal, the mobile terminal including at least one application launching device 80, or electronic device 90, or chip 100, or the above-mentioned domain controller.

[0249] Optionally, the terminal can be a means of transportation, such as a car, truck, aircraft, drone, slow transport vehicle, spacecraft, or ship, or any other possible means of transportation used in any possible scenario. This application embodiment does not limit this.

[0250] Optionally, the terminal is used to implement the methods shown in Figures 4 to 7 above.

[0251] This application also provides a processing apparatus, including a processor and an interface; the processor is used to execute the method in any of the above method embodiments.

[0252] It should be understood that the above-described processing device can be a chip. The units in the various device embodiments and the electronic devices in the method embodiments correspond completely, with corresponding modules or units executing corresponding steps. For example, the communication unit (transceiver) executes the receiving or sending steps in the method embodiments, while other steps besides sending and receiving can be executed by the processing unit (processor). The specific functions of each unit can be found in the corresponding method embodiments. There can be one or more processors.

[0253] It is understood that in the embodiments of this application, the electronic device may perform some or all of the steps in the embodiments of this application. These steps or operations are merely examples, and the embodiments of this application may also perform other operations or variations thereof. Furthermore, the steps may be performed in different orders as presented in the embodiments of this application, and it is not necessarily necessary to perform all the operations in the embodiments of this application.

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

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

[0256] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0257] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the contributing part, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0258] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. An application launch method, characterized in that, The application launch method includes: Initialize the first operating system; Obtain a first image file, which includes information about the second operating system being in a first boot completion state and information about the first application being in a second boot completion state. The size of the binary file of the first operating system is smaller than the size of the binary file of the second operating system. Based on the first operating system and the first image file, restore the second operating system to the first boot completion state, and restore the first application to the second boot completion state.

2. The application launch method according to claim 1, characterized in that, The binary file of the first operating system includes a first function required to restore the second operating system to the first boot completion state based on the first image file and to restore the first application to the second boot completion state. The binary file of the second operating system includes a second function required to start the second operating system and the first application. The second function is more than the first function.

3. The application launch method according to claim 2, characterized in that, The second function includes the functions required to start the second operating system and the first application, as well as the functions required to support the operation of the second operating system and the first application.

4. The application launch method according to any one of claims 1 to 3, characterized in that, Before initializing the first operating system, the first operating system is loaded under the instruction of a first startup command, which is used to instruct the first application to be launched.

5. The application launch method according to any one of claims 1 to 4, characterized in that, The process of restoring the second operating system to the first boot completion state and restoring the first application to the second boot completion state includes: The memory pages in the first image file are decompressed, and the decompressed data is written to the address of the memory page in physical memory. Output the starting address of the page table, which is used to manage the addresses of the memory pages in physical memory; The instruction jumps to the entry address of the second operating system in the first startup complete state, and the entry address of the first application in the second startup complete state.

6. The application launch method according to claim 5, characterized in that, The application launch method also includes: Verify the integrity check code corresponding to the decompressed data; The starting address of the output page table includes: If the integrity check code corresponding to the decompressed data passes the verification, the starting address of the page table is output.

7. The application launch method according to claim 5 or 6, characterized in that, The first image file includes multiple memory pages, and the application startup method further includes: Create at least two threads; The step of decompressing the memory pages in the first image file and writing the decompressed data to the address of the memory pages in physical memory includes: Based on the first thread of the at least two threads, the first memory page in the first image file is decompressed, and the decompressed data is written to the address of the first memory page in physical memory; Based on the second thread of the at least two threads, the second memory page in the first image file is decompressed, and the decompressed data is written to the address of the second memory page in physical memory. The first thread is different from the second thread.

8. The application launch method according to claim 7, characterized in that, The at least two threads also include a third thread, and the application startup method further includes: Based on the third thread, the integrity check code corresponding to the decompressed data is verified; The starting address of the output page table includes: If the integrity check code corresponding to the decompressed data passes the verification, the starting address of the page table is output.

9. The application launch method according to claim 7 or 8, characterized in that, The number of threads in the at least two threads does not exceed the number of cores in the multi-core central processing unit used to execute the application startup method.

10. The application launch method according to any one of claims 1 to 9, characterized in that, The applications running on the second operating system include the first application and the second application, with the second application starting after the first application.

11. The application launch method according to any one of claims 1 to 10, characterized in that, The first image file is obtained from the information of the state of the first application after it is loaded and initialized. The first application is loaded and initialized under the instruction of the first startup script, which is used to initialize the components that the first application depends on for running.

12. The application launch method according to any one of claims 1 to 11, characterized in that, The size of the first image file is less than a first threshold, and / or the size of the binary file of the first operating system is less than a second threshold.

13. An application activation device, characterized in that, Includes units for performing the method as described in any one of claims 1 to 12.

14. An application activation device, characterized in that, Includes a processor for performing the method as described in any one of claims 1 to 12.

15. A chip, characterized in that, It includes logic circuits and interfaces, wherein the logic circuits and the interfaces are coupled; The interface is used for inputting and / or outputting information, and the logic circuit is used for performing the method as described in any one of claims 1 to 12.

16. A domain controller, characterized in that, Includes a first operating system, the first operating system being used to perform the method as described in any one of claims 1 to 12.

17. The domain controller according to claim 16, characterized in that, The domain controller further includes a second operating system as described in any one of claims 1 to 12.

18. A terminal, characterized in that, This includes the application launch device as described in claim 13, or the application launch device as described in claim 14, or the chip as described in claim 15, or the domain controller as described in claim 16.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program, which, when executed, performs the method as described in any one of claims 1 to 12.

20. A computer program product, characterized in that, The computer program product includes a computer program, which, when executed, performs the method as described in any one of claims 1 to 12.

Images