Application starting method, electronic equipment and chip system

Abstract

The embodiment of the invention provides an application starting method, electronic equipment and a chip system, and relates to the technical field of terminals, and the method can improve the cold starting efficiency of an application. Specifically, the electronic equipment comprises a first file and a second file of a first application, a machine code used for starting an application program is stored in the first file, and a byte code of the application program is stored in the second file. The method comprises the steps that the electronic equipment receives a first request, wherein the first request is used for starting a first application; and in response to the first request, the electronic equipment determines that the version of the operating system of the electronic equipment is changed under the condition that the first file of the first application is invalid. And the electronic equipment skips the operation of verifying the byte code in the second file of the first application, compiles the byte code of the first application to obtain a machine code of the first application, and executes the machine code of the first application to start the first application.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of terminal technology, and in particular to an application startup method, an electronic device, and a chip system. Background Art

[0002] For any application, the source code written by the developer is compiled to generate bytecode, which contains the logic and instructions of the application. After the application is installed on the electronic device, the electronic device needs to compile the bytecode to obtain machine code and execute the machine code before the application can be cold started.

[0003] Currently, through Dex2oat technology, electronic devices will pre-compile bytecodes to obtain machine code and store the machine code in .odex files in advance. In this way, when the application needs to be cold-started, the electronic device can directly load and execute the machine code in the .odex file without spending time compiling the bytecode, which simplifies the execution steps, saves execution time, and is conducive to improving the cold-start efficiency of the application.

[0004] However, electronic devices may encounter situations where they cannot directly load and execute machine codes in .odex files, resulting in reduced cold start efficiency of the application. Summary of the invention

[0005] The embodiments of the present application provide an application startup method, an electronic device, and a chip system, which can improve the cold start efficiency of the application.

[0006] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0007] In a first aspect, an application startup method is provided, which is applied to an electronic device, wherein the electronic device includes a first file and a second file of a first application, wherein the first file stores a machine code for starting the application, and the second file stores a bytecode of the application. The method includes: the electronic device receives a first request, wherein the first request is used to start the first application. In response to the first request, the electronic device determines that the version of the operating system of the electronic device has changed when the first file of the first application is invalid. The electronic device skips the operation of verifying the bytecode in the second file of the first application, and the electronic device compiles the bytecode of the first application to obtain the machine code of the first application, and executes the machine code of the first application to start the first application.

[0008] In the above scheme, the electronic device skips the operation of verifying the bytecode of the application, so that the electronic device can directly compile the bytecode to obtain the machine code that the electronic device can run, and cold start the application by loading the machine code, thereby saving the application cold start time and improving the application cold start efficiency.

[0009] In a possible implementation of the first aspect, when the power of the electronic device is greater than the first threshold and / or the electronic device is in a charging state, the electronic device may precompile the bytecode of the first application in the first file of the first application to obtain the machine code of the first application, and update the second file stored in the first application. The electronic device may also precompile the bytecode of the second application in the first file of the second application to obtain the machine code of the second application, and update the second file stored in the second application.

[0010] In the above scheme, when the power of the electronic device is greater than the first threshold, and / or the electronic device is in a charging state, the electronic device can pre-compile the bytecodes corresponding to multiple applications in batches, so that when the electronic device subsequently cold-starts the application, the electronic device can directly load the machine code corresponding to the application, thereby improving the efficiency of the application cold start.

[0011] In another possible implementation of the first aspect, the electronic device determines, in response to the first request, that the version of the operating system of the electronic device has not changed when the first file is invalid. The electronic device verifies the bytecode of the first application in the second file. When the bytecode of the first application passes the verification, the electronic device compiles the bytecode of the first application to obtain the machine code of the first application, and executes the machine code of the first application to start the first application.

[0012] In the above scheme, if the first file becomes invalid due to other reasons other than the change of the operating system version, the electronic device cannot skip the verification operation of the bytecode in the second file. This can ensure the accuracy of the bytecode in the second file, effectively avoid errors in the subsequent bytecode compilation process of the electronic device, and save the computing power of the electronic device.

[0013] In another possible implementation of the first aspect, the process of the electronic device verifying the bytecode is a process of verifying the class in the bytecode. Specifically, the operation of the electronic device verifying the bytecode of the first application in the second file includes at least one of the following: the electronic device verifies whether the bytecode in the second file is legal. The electronic device verifies whether all type conversions and method calls in the second file are legal. The electronic device verifies whether all data structures and code segments in the second file are aligned and whether memory access errors occur. The electronic device verifies the entry point of the method in the second file, the initialization order of the class, and the constraints when the electronic device is running.

[0014] In the above scheme, the electronic device verifies the bytecode of the first application in the second file, which can ensure the accuracy of the bytecode, effectively avoid errors in the subsequent bytecode compilation process of the electronic device, and save the computing power of the electronic device.

[0015] In another possible implementation manner of the first aspect, when the identification of the operating system of the electronic device changes, the operating system version is upgraded, or the operating system is restored to a default version.

[0016] In the above scheme, the electronic device can determine whether the operating system version has changed by determining whether the operating system identifier has changed, which makes it easier for the subsequent electronic device to determine whether the reason for the invalidation of the first file is caused by the operating system change, and further facilitates the electronic device to determine whether to skip the operation of verifying the bytecode.

[0017] In another possible implementation of the first aspect, the operating system of the electronic device includes an application layer and a runtime layer, the first application is located in the application layer, and the first file management module, the second file management module and the verification module of the electronic device are located in the runtime layer. The first application responds to the first request and sends a second request to the second file management module, and the second request is used to load the second file. The second file management module responds to the second request, loads the second file, and sends a third request to the first file management module, and the third request is used to load the first file. In response to the third request, the second file management module determines whether the version of the operating system of the electronic device has changed when the first file is invalid. In the case where the version of the operating system of the electronic device has changed, the verification module skips the operation of verifying the bytecode of the first application in the second file. The second file management module compiles the bytecode of the first application to obtain the machine code of the first application, and executes the machine code of the first application to start the first application.

[0018] In the above scheme, the verification module skips the operation of verifying the bytecode of the application, so that the electronic device can directly compile the bytecode to obtain the machine code that the electronic device can run, and cold start the application by loading the machine code, which saves the application cold start time and improves the application cold start efficiency.

[0019] In a second aspect, the present application provides an electronic device, comprising: a memory and one or more processors, wherein when the processor executes one or more computer programs stored in the memory, the electronic device executes the method in the first aspect and any possible implementation thereof.

[0020] In a third aspect, the present application provides an electronic device, the electronic device comprising: a memory and one or more processors, the memory being coupled to the processor. The memory stores computer program code, the computer program code comprising computer instructions, and when the computer instructions are executed by the processor, the electronic device executes the method in the first aspect and any possible implementation thereof.

[0021] In a fourth aspect, the present application provides a chip system, which is applied to an electronic device including a memory and a display screen, and the chip system includes: a processor, when the processor executes computer instructions stored in the memory, the chip system executes the method in the first aspect and any possible implementation thereof.

[0022] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the method of the first aspect and any possible implementation thereof.

[0023] In a sixth aspect, an embodiment of the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the method of the first aspect and any possible implementation thereof. The computer may be the electronic device of the second aspect and any possible implementation thereof, the electronic device of the third aspect and any possible implementation thereof, or the chip system of the fourth aspect and any possible implementation thereof.

[0024] It can be understood that the beneficial effects that can be achieved by the electronic device of the second aspect, the electronic device of the third aspect, the chip system of the fourth aspect, the computer-readable storage medium of the fifth aspect, and the computer program product of the sixth aspect provided above can be referred to the beneficial effects in the method of the first aspect and any possible implementation thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 A schematic diagram of an electronic device operating state provided in an embodiment of the present application;

[0026] Figure 2 A schematic diagram of the principle of an application cold start method provided in an embodiment of the present application;

[0027] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0028] Figure 4 A schematic diagram of a software system architecture of an electronic device provided in an embodiment of the present application;

[0029] Figure 5 A schematic diagram of a process flow of an application cold start method provided in an embodiment of the present application;

[0030] Figure 6 A schematic diagram of another cold start method for application provided in an embodiment of the present application;

[0031] Figure 7A timing diagram of an application cold start method provided in an embodiment of the present application;

[0032] Figure 8 A timing diagram of another application cold start method provided in an embodiment of the present application;

[0033] Fig. 9 A schematic diagram of another operating status of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0034] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this embodiment, unless otherwise specified, "plurality" means two or more.

[0035] Before introducing the embodiments of the present application, in order to facilitate understanding, the following explanations are given to the relevant terms in the embodiments of the present application.

[0036] Machine code is code that can be understood and executed by the operating system on an electronic device.

[0037] Bytecode is an intermediate code. Electronic devices can obtain bytecode by compiling source code, and then obtain machine code by compiling bytecode.

[0038] Dex2oat technology is a pre-compilation technology that enables electronic devices to pre-compile bytecode into machine code. The bytecode is stored in the .dex file, and the pre-compiled machine code is stored in the .odex file. The machine code can be called local code or native code, and pre-compilation can also be called Ahead-of-Time (AOT) compilation.

[0039] Application cold start refers to the process of an application (App) starting and initializing on a device from a completely non-running state. In simple terms, it is the startup process when a user opens an app for the first time, or when the operating system of an electronic device restarts the app for some reason (such as after memory cleaning).

[0040] The following is a detailed introduction to the embodiments of the present application.

[0041] In some embodiments, the electronic device can precompile the bytecode into machine code through the Dex2oat technology, so that the electronic device can directly load the machine code during operation. For example, when the electronic device is in the process of cold starting the application, the electronic device can directly load the machine code through the Dex2oat technology to achieve the cold start of the application, and the electronic device does not need to compile the bytecode corresponding to the application. Among them, before the electronic device precompiles the bytecode, the electronic device also needs to verify the bytecode and obtain the verification result, and the electronic device stores the verification result in the .vdex file. Only when the verification is passed can the electronic device compile the bytecode to obtain the machine code.

[0042] However, the machine code generated by the electronic device through Dex2oat technology matches the current operating system version of the electronic device. For example, when the operating system version of the electronic device is upgraded, or the operating system of the electronic device is restored to a lower version, the machine code will become invalid and the electronic device cannot directly load the machine code. In this case, the electronic device will re-verify the bytecode. If the verification is passed, the electronic device will recompile the bytecode to obtain the machine code that the electronic device can run directly. This process leads to reduced efficiency when the application is cold started for the first time.

[0043] Specifically, before the operating system version changes, when the machine code obtained by the electronic device through the Dex2oat technology matches the current operating system version, the electronic device does not need to verify the bytecode class during the cold start of the application. The electronic device can directly determine that the verification result is correct, and the time for the electronic device to determine the verification result is short. For example, the electronic device only needs 1ms to determine the verification result.

[0044] Figure 1 This is a schematic diagram of an electronic device operating state provided in an embodiment of the present application. Figure 1 As shown in (b), at time t1, after the electronic device receives the operation of the user clicking the application icon, the electronic device executes the function corresponding to the cold start of the application. In the process of executing the function corresponding to the cold start of the application, the electronic device first initializes the class corresponding to the function. In the process of initializing the class, the electronic device needs to determine the verification result of the class. When the machine code matches the current operating system version, that is, when the machine code is valid, the electronic device can directly determine that the verification result of the class is correct, wherein the time for the electronic device to determine the verification result is relatively short. Then at time t2, the electronic device completes the cold start of the application. Among them, there may be an interval of 800ms between t1 and t2.

[0045] However, after the operating system version changes, when the machine code obtained by the electronic device through the Dex2oat technology does not match the current operating system version, during the cold start process of the electronic device, the electronic device needs to perform a verification operation and calculate the verification result. The verification time is relatively long. For example, the electronic device needs 30ms to complete the verification.

[0046] like Figure 1 As shown in (a), at time t3, after the electronic device receives the operation of the user clicking the application icon, the electronic device executes the function corresponding to the cold start of the application. In the process of executing the function corresponding to the cold start of the application, the electronic device first initializes the class corresponding to the function. In the process of initializing the class, the electronic device needs to perform a verification operation on the class and obtain the verification result. The verification process takes a long time. Then at time t4, the electronic device completes the cold start of the application. Among them, there may be an interval of 1000ms between t3 and t4.

[0047] from Figure 1 As can be seen from (a) and (b) in the figure, after the operating system version of the electronic device changes, the application cold start time becomes longer, which in turn leads to lower application cold start efficiency.

[0048] In some embodiments, Figure 2 A schematic diagram of the principle of a cold start method for application provided in an embodiment of the present application. Figure 2 In (a), in order to solve the problem of reduced application cold start efficiency, after the operating system version of the electronic device is updated, the updated operating system version is installed, and the electronic device is restarted, and before the application is cold started for the first time, that is, after time t5 and before time t6, the electronic device can batch precompile the bytecodes corresponding to each application in the electronic device through the Dex2oat technology, so that after the application is cold started for the first time, that is, after time t6, the electronic device can directly load the precompiled machine code, and the machine code matches the current operating system version of the electronic device.

[0049] However, in this embodiment, before the electronic device precompiles the bytecodes corresponding to each application in batches, when the application is cold started for the first time, the electronic device still cannot directly load the machine code, and the cold start efficiency of the application still cannot be improved.

[0050] In other embodiments, Figure 2In (b), after the operating system version of the electronic device is updated and the updated operating system version is installed, and the electronic device is restarted, that is, after time t7, the electronic device can verify the bytecode of the application when the application is cold-started for the first time at time t8. If the verification passes, the electronic device compiles the bytecode through the Dex2oat technology to obtain the machine code that matches the current operating system version.

[0051] However, in this embodiment, during the first cold start process of an application on an electronic device, the electronic device not only needs to re-verify the machine code, but also needs to obtain the machine code through the Dex2oat technology and cold start the application by loading the machine code. The efficiency of the first cold start of the application is still not improved.

[0052] To this end, the present application provides an application cold start method. In the case where the machine code corresponding to the application on the electronic device becomes invalid due to a change in the operating system version, the bytecode of the application is still valid. Therefore, the electronic device can skip the operation of verifying the bytecode of the application, so that the electronic device can directly compile the bytecode to achieve a cold start of the application, thereby improving the efficiency of the cold start of the application.

[0053] Exemplarily, the electronic device may be a mobile phone, a tablet computer, a smart remote controller, a wearable device (such as a smart bracelet, a smart watch or smart glasses), a PDA, an augmented reality (AR) / virtual reality (VR) device. Alternatively, the mobile phone 500 may also be other types of electronic devices such as a portable multimedia player (PMP), a media player, etc. The embodiments of the present application do not impose any restrictions on the specific types of electronic devices.

[0054] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0055] The electronic device 300 may include a processor 310, an external memory interface 320, an internal memory 321, a universal serial bus (USB) interface 330, a charging management module 340, a power management module 341, a battery 342, an antenna 1, an antenna 2, a mobile communication module 350, a wireless communication module 360, an audio module 370, a sensor module 380, cameras 1~N393, and display screens 1~N394.

[0056] It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the electronic device 300. In other embodiments of the present application, the electronic device 300 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0057] The processor 310 may include one or more processing units, for example, the processor 310 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0058] The controller may be the nerve center and command center of the electronic device 300. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0059] The processor 310 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 310 is a cache memory. The memory may store instructions or data that the processor 310 has just used or cyclically used. If the processor 310 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 310, and thus improves the efficiency of the system.

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

[0061] The wireless communication function of the electronic device 300 can be implemented through the antenna 1, the antenna 2, the mobile communication module 350, the wireless communication module 360, the modem processor and the baseband processor.

[0062] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device 300 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of the antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0063] The display screen 394 is used to display images, videos, etc. The display screen 394 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 300 may include 1 or N display screens 394, where N is a positive integer greater than 1.

[0064] Video codecs are used to compress or decompress digital videos. The electronic device 300 may support one or more video codecs. Thus, the electronic device 300 may play or record videos in a variety of coding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0065] NPU is a neural network (NN) computing processor. By drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, it can quickly process input information and can also continuously self-learn. Through NPU, applications such as intelligent cognition of the electronic device 300 can be realized, such as image recognition, face recognition, voice recognition, text understanding, etc.

[0066] The external memory interface 320 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 300. The external memory card communicates with the processor 310 through the external memory interface 320 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0067] The internal memory 321 can be used to store computer executable program codes, and the executable program codes include instructions. The processor 310 executes various functional applications and data processing of the electronic device 300 by running the instructions stored in the internal memory 321. The internal memory 321 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the electronic device 300 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 321 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0068] Figure 4 A schematic diagram of a software system architecture of an electronic device provided in an embodiment of the present application.

[0069] The software system of the electronic device may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present invention takes the Android system of the layered architecture as an example to exemplify the software structure of the electronic device.

[0070] The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: application layer, application framework layer, runtime layer, and kernel layer.

[0071] The application layer may include a series of application packages.

[0072] like Figure 4 As shown, the application layer may include: system applications and third-party applications. System applications may include: camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications. Third-party applications may include: shopping applications, dating applications, etc., which are not shown one by one in the figure.

[0073] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0074] like Figure 4 As shown, the application framework layer may include: a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, etc., which are not shown one by one in the figure.

[0075] The runtime layer may include: a first file management module, a second file management module, and a verification module.

[0076] The first file management module is used to determine whether the machine code in the first file is invalid.

[0077] The second file management module is used to obtain the bytecode in the second file.

[0078] The verification module is used to verify the bytecode and obtain the verification result.

[0079] The kernel layer is the layer between hardware and software. The kernel layer includes memory drivers, etc. Among them, the memory driver is responsible for managing operations related to memory (such as hard disks, SSDs, etc.). The memory driver enables electronic devices to access data on the memory by providing a series of interfaces. These interfaces include data reading and writing, device initialization, device control, etc.

[0080] like Figure 4As shown, the hardware on the electronic device may include a memory, and the memory may include a first file and a second file. The electronic device may read the first file and the second file in the memory through a memory driver, wherein the first file stores a machine code for starting an application, and the second file stores a bytecode of the application. In the case where the electronic device uses the Dex2oat technology, the electronic device may precompile the bytecode in the second file to obtain the bytecode and store it in the first file. The first file may be a .dex file, and the second file may be a .odex file.

[0081] The application cold start method of the present application is described in detail below with reference to specific drawings.

[0082] Figure 5 A schematic diagram of a process flow of an application cold start method provided in an embodiment of the present application. Figure 5 As shown, the application cold start method includes the following steps:

[0083] Step 501: The electronic device receives a first request, where the first request is used to start a first application.

[0084] In this embodiment, the first request may be generated based on a touch operation received by the electronic device, or may be generated based on a voice operation received by the electronic device. In the embodiments of the present application, there is no limitation on the method for generating the first request.

[0085] For example, after the electronic device receives a touch operation on the icon of the first application from the user, the electronic device obtains a first request based on the touch operation to start the first application.

[0086] The first application may be a system application on the electronic device or a third-party application. The system application may be a camera, a video recorder, or other system application, and the third-party application may be a video application, a shopping application, or the like.

[0087] Step 502: In response to the first request, the electronic device determines that the version of the operating system of the electronic device has changed when the first file of the first application is invalid.

[0088] After receiving the first request, the electronic device determines that the first application needs to be started. The electronic device can determine whether the first file of the first application is invalid. In the case where the first file of the first application is invalid, the electronic device can determine the reason for the invalidation of the first file. In the case where the invalidation reason is caused by a change in the version of the operating system of the electronic device, the electronic device performs the following step 503.

[0089] The electronic device may indicate the reason why the first file is invalid through a preset state or a preset value. For example, the electronic device may indicate that the first file is invalid due to a change in the version of the operating system by setting the kOatBootImageOutOfDate state.

[0090] Step 503: The electronic device skips the operation of verifying the bytecode in the second file of the first application, compiles the bytecode of the first application, obtains the machine code of the first application, and executes the machine code of the first application to start the first application.

[0091] Electronic device verification of bytecode refers to the process in which the electronic device verifies the classes in the bytecode to ensure that the design and implementation of the classes meet the expected requirements and satisfy specific standards or specifications.

[0092] When the operating system version changes, although the machine code becomes invalid, the bytecode remains valid, and the verification result of the bytecode remains unchanged. Therefore, when the first file becomes invalid due to a change in the operating system version, the electronic device can skip the operation of verifying the bytecode of the first application, directly compile the bytecode, obtain the machine code that matches the current operating system version, and start the first application by loading the machine code of the first application, so as to improve the startup efficiency of the first application.

[0093] Among them, the solution of the present application can be applied to the first cold start after the application is installed after the operating system version of the electronic device changes. Alternatively, the solution of the present application can also be applied to the cold start of the application again after the application is cold started for the first time and closed after the operating system version of the electronic device changes. Alternatively, the solution of the present application can also be applied to the first cold start of the application after the operating system version of the electronic device changes and the electronic device is restarted.

[0094] According to the method provided in the embodiment of the present application, the electronic device skips the operation of verifying the bytecode of the application, so that the electronic device can directly compile the bytecode to obtain the machine code that can be run by the electronic device, and cold-start the application by loading the machine code, thereby saving the application cold-start time and improving the application cold-start efficiency.

[0095] Based on the above description, it can be known that the electronic device skips the bytecode verification operation when the operating system version changes, making the machine code invalid. The following specifically describes how the electronic device determines that the operating system version has changed.

[0096] In some embodiments, when the identification of the operating system of the electronic device changes, the operating system version is upgraded, or the operating system is restored to a default version.

[0097] The operating system identifier is used to identify the current version of the operating system, and the operating system identifier may include at least one of the name of the operating system, the ID of the operating system, etc. When the operating system version changes, the operating system identifier will also change.

[0098] In this embodiment, the electronic device can determine whether the operating system version has changed by determining whether the operating system identifier has changed, which makes it easier for the subsequent electronic device to determine whether the reason for the failure of the first file is caused by the operating system change, and further facilitates the electronic device to determine whether to skip the operation of verifying the bytecode.

[0099] In some embodiments, the electronic device may further include multiple applications. After the operating system version changes, the electronic device may also re-precompile the bytecodes corresponding to the multiple applications on the electronic device in batches to obtain the machine code corresponding to each application.

[0100] Specifically, in some embodiments, when the power of the electronic device is greater than the first threshold, and / or the electronic device is in a charging state, the electronic device can precompile the bytecode of the first application in the first file of the first application to obtain the machine code of the first application, and update the second file stored in the first application. The electronic device can also precompile the bytecode of the second application in the first file of the second application to obtain the machine code of the second application, and update the second file stored in the second application.

[0101] Figure 6 A schematic diagram of another cold start method for application provided in an embodiment of the present application. Figure 6 In the example, after the application is cold-started for the first time, that is, after time t9, the electronic device can batch-recompile the bytecodes corresponding to multiple applications in the background to obtain the machine code corresponding to each application that matches the current operating system version. After the electronic device generates the machine code corresponding to each application that matches the current operating system version, the application is cold-started again, that is, at time t10, the electronic device can directly load the newly generated machine code to improve the efficiency of the application cold-start.

[0102] The electronic device may compile the bytecode of the first application and the bytecode of the second application at the same time. The electronic device may also compile the bytecode of the first application first and then the bytecode of the second application in a compilation order. The electronic device may also compile the bytecode of the second application first and then the bytecode of the first application. In the embodiments of the present application, no restriction is imposed on the compilation and execution order of the applications in the electronic device.

[0103] When the electronic device consumes less power, such as less than 2% of the total power, or when the power is greater than a first threshold, such as greater than 60% of the total power, or when the electronic device is in a charging state, the electronic device can recompile the bytecodes corresponding to multiple applications.

[0104] It can be understood that in this embodiment, when the power of the electronic device is greater than the first threshold, and / or the electronic device is in a charging state, the electronic device can pre-compile the bytecodes corresponding to multiple applications in batches, so that when the electronic device subsequently cold-starts the application, the electronic device can directly load the machine code corresponding to the application, thereby improving the efficiency of the application cold start.

[0105] Based on the above description, in some embodiments, in addition to the failure of the first file caused by the change of the operating system version, the failure of the first file may also include multiple reasons, such as: the failure of the first file caused by file damage, the failure of the first file caused by machine code storage failure, the failure of the first file caused by the update of the second file, etc. In this application, no limitation is made on the reasons for the failure of the first file.

[0106] The failure of the first file due to the update of the second file may specifically mean that after the second file is updated, the corresponding second file is not updated synchronously, and the checksums of the first file and the second file do not match. In this case, the first file is invalid. The failure of the first file due to file damage may specifically mean that the first file or the second file cannot be opened due to file damage.

[0107] The electronic device may indicate the reason for the failure of the first file through different preset states or different preset values. For example, the electronic device may indicate that the failure of the first file is due to file damage through the kOatCannotOpen state, the electronic device may indicate that the failure of the first file is due to storage failure through the kOatContextOutOfDate state, and the electronic device may indicate that the failure of the first file is due to the update of the second file through the kOatDexOutOfDate state.

[0108] Except for the case where the first file becomes invalid due to a change in the operating system version, the electronic device needs to re-verify the bytecode during the cold start process.

[0109] Specifically, in some embodiments, the electronic device responds to the first request, and when the first file is invalid, the electronic device determines that the version of the operating system of the electronic device has not changed. The electronic device verifies the bytecode of the first application in the second file. When the bytecode of the first application passes the verification, the electronic device compiles the bytecode of the first application to obtain the machine code of the first application, and executes the machine code of the first application to start the first application.

[0110] It is understandable that, except for the first file being invalidated due to changes in the operating system version, the electronic device cannot skip the verification operation of the bytecode in the second file if the first file is invalidated due to other reasons. This can ensure the accuracy of the bytecode in the second file, effectively avoid errors in the subsequent bytecode compilation process of the electronic device, and save the computing power of the electronic device.

[0111] The following is a detailed description of the process of how electronic devices verify bytecodes.

[0112] In some embodiments, the process of verifying the bytecode by the electronic device is a process of verifying the class in the bytecode. Specifically, the operation of the electronic device verifying the bytecode of the first application in the second file includes at least one of the following: the electronic device verifies whether the bytecode in the second file is legal. The electronic device verifies whether all type conversions and method calls in the second file are legal. The electronic device verifies whether all data structures and code segments in the second file are aligned and whether memory access errors occur. The electronic device verifies the entry point of the method in the second file, the initialization order of the class, and the constraints when the electronic device is running.

[0113] Among them, the types in the second file are used to define the types of data that can be stored or processed by variables, function return values, data structures, etc. The types can include basic data types, composite data types, reference types, etc. Type conversion refers to the process of converting the value of one data type to the value of another data type.

[0114] The electronic device verifies whether all type conversions in the second file are legal, which means: the electronic device verifies whether the data type conversion process of the second file is compliant. For example, when the electronic device converts an integer type in a basic data type to a floating-point type in a basic data type, the type conversion is not compliant.

[0115] Method call refers to the process of executing a defined method (function). The electronic device verifies whether the method call in the second file is legal, which means: the electronic device verifies whether the process of executing the method (function) is compliant.

[0116] The data structure in the second file refers to the arrangement of data in the second file. The electronic device verifies whether all the data structures in the second file are aligned, which means: the electronic device verifies whether the arrangement of data in the second file is aligned.

[0117] The electronic device may also verify whether all code segments in the second file are aligned.

[0118] The electronic device may also verify whether there is an error in accessing the second file.

[0119] The entry point of a method refers to the starting point of program execution when the method is called. The initialization order of a class is used to determine the initialization timing of static members, non-static members, properties, code blocks, constructors and other elements in the class. The constraints of electronic devices during operation refer to the various constraints that electronic devices are subject to during operation. These constraints are used to ensure the normal operation of electronic devices and extend the service life of electronic devices.

[0120] The electronic device verifies the entry point of the method in the second file, the initialization order of the class, and the constraints during the operation of the electronic device, which means: the electronic device verifies whether the entry point of the method in the second file is correct, whether the initialization order of the class is correct, and whether the electronic device complies with the constraints during operation.

[0121] In this embodiment, if the bytecode in the second file is legal, all type conversions and method calls in the second file are legal, all data structures and code segments in the second file are aligned, no memory access errors occur, the entry point of the method in the second file is correct, the class initialization order is correct, and the electronic device runs in accordance with the constraints, the electronic device passes the verification of the bytecode of the first application in the second file. Otherwise, the electronic device fails the verification of the bytecode of the first application in the second file.

[0122] It can be understood that the electronic device verifies the bytecode of the first application in the second file, which can ensure the accuracy of the bytecode, effectively avoid errors in the subsequent bytecode compilation process of the electronic device, and save the computing power of the electronic device.

[0123] In combination with the above Figure 4 The software modules and timing diagrams provide a more specific description of the embodiments of the present application.

[0124] The following first describes in detail the process of an electronic device skipping the bytecode verification operation.

[0125] In some embodiments, the first application responds to the first request and sends a second request to the second file management module, where the second request is used to load the second file. The second file management module responds to the second request, loads the second file, and sends a third request to the first file management module, where the third request is used to load the first file. In response to the third request, the second file management module determines whether the version of the operating system of the electronic device has changed when the first file is invalid. In the case where the version of the operating system of the electronic device has changed, the verification module skips the operation of verifying the bytecode of the first application in the second file. The second file management module compiles the bytecode of the first application, obtains the machine code of the first application, and executes the machine code of the first application to start the first application.

[0126] Specifically, Figure 7 A timing diagram of an application cold start method provided in an embodiment of the present application. Figure 7 As shown,

[0127] Step 701: The first application sends a request to start the first application to the second file management module.

[0128] Step 702: The second file management module responds to the request to start the first application and opens the second file.

[0129] In some embodiments, regardless of whether the electronic device can directly load the machine code in the first file, the electronic device will open the second file when starting the first application. For example, the electronic device can open the second file through the openDexFileNative() function.

[0130] Step 703: The second file management module sends a request to the first file management module to obtain the first file.

[0131] In some embodiments, after the electronic device opens the second file, the second file management module sends a request to the first file management module to obtain the first file, so as to obtain and load the machine code in the first file. For example, the electronic device can obtain the first file through the openDexFileFromOat() function.

[0132] Step 704: The second file management module responds to the request for obtaining the first file and sends a request for initializing the class to the verification module.

[0133] In some embodiments, the electronic device may initialize the class through an InitializeClass() function, where the class is a class of the bytecode in the second file.

[0134] Step 705: The verification module responds to the request to initialize the class and verifies the class.

[0135] In some embodiments, when the electronic device initializes the class, it needs to verify the correctness of the class. For example, the electronic device can verify the class through the VerifyClass() function.

[0136] Step 706: The verification module verifies the class through the first file management module.

[0137] For example, the verification module verifies the class through the first file management module through the VerifyClassUsingOatFile() function.

[0138] Step 707: The first file management module determines whether the first file is invalid.

[0139] In some embodiments, the electronic device can determine whether the first file is invalid through the GetOatClassStatus() function. When the first file is valid, or the first file is invalid due to a change in the operating system version, the verification module does not need to verify the class.

[0140] Step 708: When the first file fails, the first file management module determines the failure reason of the first file.

[0141] For example, the electronic device may determine the reason why the first file is invalid through the IsDexChanged() function. When the result returned by the IsDexChanged() function is kOatBootImageOutOfDate and the second file is not modified, the electronic device executes the following step 709 .

[0142] Step 709: When the first file becomes invalid due to a change in the operating system version, a verification result is returned to the verification module.

[0143] Among them, the verification result can be represented by the KVerified state.

[0144] Step 710: The verification module determines the verification result of the class.

[0145] The following is a detailed description of the process in which the electronic device does not skip the bytecode verification operation.

[0146] Specifically, Figure 8 A timing diagram of another cold start method provided in an embodiment of the present application. Figure 8 shown.

[0147] Step 801: The first application sends a request to start the first application to the second file management module.

[0148] Step 802: The second file management module responds to the request to start the first application and opens the second file.

[0149] Step 803: The second file management module sends a request to the first file management module to obtain the first file.

[0150] Step 804: The second file management module responds to the request for obtaining the first file and sends a request for initializing the class to the verification module.

[0151] Step 805: The verification module responds to the request to initialize the class and verifies the class.

[0152] Step 806: The verification module verifies the class through the first file management module.

[0153] Step 807: The first file management module determines whether the first file is invalid.

[0154] Step 808: When the first file is invalid and the reason for the invalidation of the first file is not due to a change in the operating system version, the verification module verifies the class.

[0155] For example, when the first file is invalid and the reason for the invalidation of the first file is not due to a change in the operating system version, the first file management module returns kVerifiedNeedsAccessChecks to the verification module, and the verification module verifies the class through the ComputeClassStatus() function.

[0156] Step 809: The verification module determines the verification result of the class.

[0157] Understandably, Fig. 9 Another schematic diagram of the operating status of an electronic device provided in an embodiment of the present application. Fig. 9 In the present invention, after the operating system version of the electronic device changes, before the electronic device obtains the machine code matching the current operating system version through the Dex2oat technology, the electronic device receives the operation of the user clicking the application icon at time t11, and during the process of the electronic device executing the application cold start function, after the electronic device initializes the class, the electronic device skips the class verification operation of the bytecode, and the electronic device directly compiles the bytecode to realize the cold start of the application, then the solution of the present application is used.

[0158] Alternatively, when the electronic device cannot directly load the machine code that matches the current operating system version, the electronic device skips the class verification operation on the bytecode, and the electronic device directly compiles the bytecode to implement a cold start of the application, using the solution of the present application.

[0159] In summary, in the solution of the present application, during the cold start process of the application, the electronic device improves the efficiency of the cold start of the application by skipping the process of verifying the bytecode.

[0160] Some other embodiments of the present application provide an electronic device, which may include: a memory and one or more processors. When the processor executes one or more computer programs stored in the memory, the electronic device performs the functions or steps in the above method embodiments. The structure of the electronic device can refer to Figure 3 and Figure 4 The structure of the electronic device 300 is shown.

[0161] Some other embodiments of the present application provide an electronic device, which may include: a memory and one or more processors, wherein the memory and the one or more processors are coupled. The memory is used to store computer program code, and the computer program code includes computer instructions. When the computer instructions are executed by the processor, the electronic device performs each function or step in the above method embodiment. The structure of the electronic device can refer to Figure 3 and Figure 4 The structure of the electronic device 300 is shown.

[0162] Some other embodiments of the present application provide a chip system, which is applied to an electronic device including a memory and a display screen, and the chip system includes: a processor. When the processor executes the computer instructions stored in the memory, the chip system performs the various functions or steps in the above method embodiments. The structure of the electronic device can refer to Figure 3 and Figure 4 The structure of the electronic device 300 is shown.

[0163] An embodiment of the present application also provides a computer storage medium, which includes computer instructions. When the computer instructions are executed on the above-mentioned electronic device, the electronic device executes each function or step executed by the electronic device in the above-mentioned method embodiment.

[0164] The embodiment of the present application also provides a computer program product. When the computer program product is run on a computer, the computer executes each function or step executed by the electronic device in the above method embodiment.

[0165] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0166] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0167] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0168] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0169] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0170] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, a data center, etc. that contains one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk), etc.

[0171] Those skilled in the art can understand that to implement all or part of the processes in the above-mentioned embodiments, the processes can be completed by computer programs to instruct related hardware, and the programs can be stored in computer-readable storage media. When the programs are executed, they can include the processes of the above-mentioned method embodiments. The aforementioned storage media include: ROM or random access memory RAM, magnetic disk or optical disk and other media that can store program codes.

[0172] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for starting an application, characterized in that: Applied to an electronic device, the electronic device includes a first file and a second file of a first application, the first file stores a machine code for starting the application, and the second file stores a bytecode of the application; the method includes: receiving a first request, where the first request is used to start the first application; In response to the first request, when the first file is invalid, determining that a version of the operating system of the electronic device has changed; The operation of verifying the bytecode of the first application in the second file is skipped, the bytecode of the first application is compiled to obtain the machine code of the first application, and the machine code of the first application is executed to start the first application.

2. The method according to claim 1, characterized in that The electronic device further includes a first file and a second file of a second application, and the method further includes: When the power level of the electronic device is greater than a first threshold and / or the electronic device is in a charging state, the bytecode of the first application in the first file of the first application is precompiled to obtain the machine code of the first application, and the machine code of the first application is updated and stored in the second file of the first application; the bytecode of the second application in the first file of the second application is precompiled to obtain the machine code of the second application, and the machine code of the second application is updated and stored in the second file of the second application.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: In response to the first request, when the first file is invalid, determining that a version of the operating system of the electronic device has not changed; verifying the bytecode of the first application in the second file; When the bytecode of the first application passes verification, the bytecode of the first application is compiled to obtain the machine code of the first application, and the machine code of the first application is executed to start the first application.

4. The method according to any one of claims 1 to 3, characterized in that The operation of verifying the bytecode of the first application in the second file includes at least one of the following: Verifying whether the bytecode in the second file is legal; Verify whether all type conversions and method calls in the second file are legal; Verify whether all data structures and code segments in the second file are aligned and whether memory access errors occur; Verify the entry point of the method in the second file, the initialization order of the class, and the constraints of the electronic device when it is running.

5. The method according to any one of claims 1 to 4, characterized in that Determining that the version of the operating system of the electronic device has changed includes: When the identification of the operating system of the electronic device changes, the operating system version is upgraded, or the operating system is restored to a default version.

6. The method according to any one of claims 1 to 5, characterized in that The operating system of the electronic device includes an application layer and a runtime layer, the first application is located in the application layer, and the first file management module, the second file management module and the verification module of the electronic device are located in the runtime layer; In response to the first request, the first application sends a second request to the second file management module, where the second request is used to load the second file; The second file management module responds to the second request, loads the second file, and sends a third request to the first file management module, where the third request is used to load the first file; The second file management module determines, in response to the third request, whether a version of the operating system of the electronic device has changed when the first file is invalid; In the case where the version of the operating system of the electronic device is changed, the verification module skips the operation of verifying the bytecode of the first application in the second file; The second file management module compiles the bytecode of the first application to obtain the machine code of the first application, and executes the machine code of the first application to start the first application.

7. An electronic device, characterized in that: The electronic device comprises: one or more processors; when the processor executes one or more computer programs stored in a memory, the electronic device executes the method according to any one of claims 1 to 6.

8. An electronic device, characterized in that: The electronic device comprises: one or more processors; a memory; wherein the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code comprises computer instructions, and the one or more processors call the computer instructions so that the electronic device executes the method as described in any one of claims 1-6.

9. A chip system, characterized in that: The chip system is applied to an electronic device including a memory and a display screen; the chip system includes: a processor; when the processor executes computer instructions stored in the memory, the electronic device executes the method as described in any one of claims 1-6.

10. A computer-readable storage medium comprising instructions, characterized in that: When the instructions are executed on an electronic device, the electronic device is caused to execute the method as claimed in any one of claims 1 to 6.

11. A computer program product comprising instructions, characterized in that When the computer program product is executed on an electronic device, the electronic device is enabled to execute the method according to any one of claims 1 to 6.

Images