Processing method of application and related device

Abstract

Embodiments of the present application provide a kind of application processing method and related device, it is related to terminal technical field.The method comprises the following steps: at the first time, the first application of the nth version is run by electronic equipment, and the first application is associated with the first hotspot function set;At the second time, the first hotspot function set is updated based on the running of the first application, and the second hotspot function set is obtained;At the third time, the electronic equipment determines to upgrade to the jth version of operating system;At the fourth time, the electronic equipment receives the information of the jth version of operating system, and the information of the jth version of operating system includes the first hotspot function set;At the fifth time, the electronic equipment is restarted to upgrade to the jth version of operating system;At the sixth time, the electronic equipment completes restart, deletes the second hotspot function set, and is compiled based on the file for guiding compilation optimization associated with the first hotspot function set, to realize the upgrade of the first application to the mth version.Such, it is favorable to improve the performance of application.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a processing method and related apparatus for an application. Background Technology

[0002] With the development of terminal technology, electronic devices can be equipped with various system applications. For example, electronic devices may include desktop applications, negative one screen, system user interface (UI), telephone applications, SMS applications, contact applications, and camera applications, among other system applications.

[0003] Currently, the performance of system applications installed on electronic devices is poor. For example, electronic devices may experience lag, frame drops, and high power consumption when running system applications, which affects the user experience. Summary of the Invention

[0004] This application provides an application processing method and related apparatus, which are applied in the field of terminal technology and are beneficial to improving the performance of system applications.

[0005] In a first aspect, embodiments of this application provide an application processing method applied to an electronic device. The method includes: a first moment, the electronic device running a first application of version n, the electronic device's operating system being an operating system of version i, and the first application being associated with a first hotspot function set; a second moment, the electronic device updating the first hotspot function set based on the running of the first application to obtain a second hotspot function set, the second moment being later than the first moment; a third moment, the electronic device determining to upgrade to an operating system of version j, in which the version of the first application is version m, and version m is higher than version n, the third moment being later than the second moment; a fourth moment, the electronic device receiving information from the operating system of version j, the information of the operating system of version j including the first hotspot function set, the fourth moment being later than the third moment; a fifth moment, the electronic device restarting to upgrade to the operating system of version j, the fifth moment being later than the fourth moment; a sixth moment, the electronic device completing the restart, deleting the second hotspot function set, and compiling based on files associated with the first hotspot function set used to guide compilation optimization, thereby upgrading the first application to version m, the sixth moment being later than the fifth moment.

[0006] When an electronic device upgrades from operating system version i to operating system version j, it will reboot. Since the operating system upgrade causes the first application to upgrade from version n to version m, the second hotspot function set will become invalid. The electronic device can delete the second hotspot function set. When the electronic device upgrades to operating system version j, the information in operating system version j includes the first hotspot function set. Therefore, the electronic device can compile based on the files associated with the first hotspot function set that guide compilation optimization, thus achieving the upgrade of the first application to version m.

[0007] In this way, although upgrading the first application version will cause the second hot function set to become invalid, it can be compiled using the files associated with the first hot function set that guide compilation optimization. Compared with the method of interpreting and JIT compilation, this is beneficial to improving the performance of the application.

[0008] In one possible implementation, the fit between the first hotspot function set and the m-th version is greater than a first threshold.

[0009] If the compatibility of the first set of hotspot functions with version m is greater than the first threshold, it indicates that the first set of hotspot functions is compatible not only with version n but also with version m. In this way, different versions of the first application can correspond to the same set of hotspot functions, eliminating the need to set up a separate set for each version, reducing the time spent collecting hotspot function sets, and simplifying implementation.

[0010] In one possible implementation, the fit between the first hotspot function set and version m is greater than a first threshold under at least one of the following conditions: the difference between the version number of version m and the version number of version n is less than the difference threshold; the number of hotspot functions in the first hotspot function set that fail in version m is less than the number threshold; or, the failure rate of hotspot functions in the first hotspot function set in version m is less than the failure threshold.

[0011] In one example, if the difference between the version number of version m and the version number of version n is less than the difference threshold, it can be said that the fit between the first hotspot function set and version m is greater than the first threshold.

[0012] In this way, the difference in version numbers reflects the degree of version upgrade. The larger the difference in version numbers, the higher the degree of version upgrade, and the less compatible the first hot function set is with the m-th version. The smaller the difference in version numbers, the lower the degree of version upgrade, and the more compatible the first hot function set is with the m-th version. This method is simple to implement.

[0013] In another example, if the number of hot functions in the first hot function set that fail in version m is less than the number threshold, it can be said that the fit between the first hot function set and version m is greater than the first threshold.

[0014] In this way, by counting the number of failed hot functions, the fit between the first set of hot functions and the m-th version can be reflected. Compared with the difference in version number, the fit can be fed back, which helps to improve the accuracy of calculation.

[0015] In another example, the failure rate of hot functions in the first hot function set in version m is less than the failure threshold, which indicates that the fit between the first hot function set and version m is greater than the first threshold.

[0016] In this way, reflecting the fit between the first set of hot functions and the m-th version by statistically analyzing the failure rate of hot functions is more conducive to improving the accuracy of calculation than simply counting the number of failures.

[0017] In one possible implementation, the method further includes: at a seventh moment, the electronic device runs the first application of version m, the operating system of the electronic device is the operating system of version j, and the first application is associated with a first hotspot function set; at an eighth moment, the electronic device updates the first hotspot function set based on the running of the first application to obtain a third hotspot function set, the eighth moment being later than the seventh moment; at a ninth moment, the electronic device determines to upgrade to the operating system of version k, in which the version of the first application is version m, the ninth moment being later than the eighth moment; at a tenth moment, the electronic device receives information from the operating system of version k, which includes the first hotspot function set, the tenth moment being later than the ninth moment; at an eleventh moment, the electronic device restarts to upgrade to the operating system of version k, the eleventh moment being later than the tenth moment; at a twelfth moment, the electronic device completes the restart, merges the first hotspot function set and the third hotspot function set to obtain a fourth hotspot function set, and compiles based on the file associated with the fourth hotspot function set used to guide compilation optimization, thereby running the first application, the twelfth moment being later than the eleventh moment.

[0018] In this way, since the first application version has not been upgraded, there are two hot function sets, namely the first hot function set and the third hot function set. Electronic devices can merge the first hot function set and the third hot function set to obtain a more comprehensive hot function set, which is beneficial to improving the performance of the application.

[0019] In one possible implementation, the target file is obtained by compiling a file associated with the first hotspot function set to guide compilation optimization; the method also includes: the electronic device locking the target file in memory.

[0020] Electronic devices can lock target files using memory locking mechanisms to prevent related data from being swapped out of memory when the first application is running in the background. This helps reduce system application stuttering or frame drops and can improve application performance.

[0021] Secondly, embodiments of this application provide a processing method for an application, applied to a processing device. The method includes:

[0022] The processing device may be the aforementioned electronic device or a server, and this application embodiment does not limit this.

[0023] The processing device acquires a first file associated with the first application of version n. The first file is used to guide compilation optimization and includes a first set of hot-spot functions. The processing device converts the first file into a second file. The second file is readable and is not used to guide compilation optimization. The second file also includes the first set of hot-spot functions. When the first application is upgraded from version n to version m, the processing device determines whether the compatibility between the first set of hot-spot functions and version m is greater than a first threshold. If the compatibility between the first set of hot-spot functions and version m is greater than the first threshold, the processing device converts the second file into a third file. The third file is used to guide compilation optimization and includes the first set of hot-spot functions. The processing device associates version m with the third file.

[0024] The first file is used to guide compilation optimization, and the first set of hot functions is bound to version n of the first application. The processing device converts the first file into a second file, which is readable and not used to guide compilation optimization. This is equivalent to unbinding the first set of hot functions from version n of the first application, allowing the first set of hot functions to be bound to any subsequent version of the first application.

[0025] If the compatibility between the first hotspot function set and the m-th version is greater than the first threshold, the processing device can convert the second file into a third file and associate the third file with the m-th version, thus binding the first hotspot function set with the m-th version.

[0026] In this way, the first application of different versions can correspond to the same set of hot functions, eliminating the need to collect a set of hot functions for each version, reducing the time spent collecting hot functions, and simplifying the implementation.

[0027] In one possible implementation, the fit between the first hotspot function set and version m is greater than a first threshold under at least one of the following conditions: the difference between the version number of version m and the version number of version n is less than the difference threshold; the number of hotspot functions in the first hotspot function set that fail in version m is greater than the number threshold; or, the failure rate of hotspot functions in the first hotspot function set in version m is greater than the failure threshold.

[0028] Thirdly, embodiments of this application provide a processing apparatus for an application. This processing apparatus may be a processing device, or a chip or chip system within a processing device. The processing apparatus may include a processing unit and a receiving unit. When the processing apparatus is a processing device, the processing unit may be a processor. The processor executes processing steps to enable the processing device to implement an application processing method described in any one of the possible implementations of any aspect. The processing apparatus may also include a storage unit, which may be a memory. The storage unit stores instructions, and the processing unit executes the instructions stored in the storage unit to enable the processing device to implement an application processing method described in any one of the possible implementations of any aspect. When the processing apparatus is a chip or chip system within a processing device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit to enable the processing device to implement an application processing method described in any one of the possible implementations of any aspect. The storage unit can be a storage unit within the chip (e.g., a register, cache, etc.) or a storage unit located outside the chip within the processing device (e.g., a read-only memory, random access memory, etc.).

[0029] In one example, the processing unit is configured to: 1) run version n of a first application at a given time, with the processing device running version i of the operating system, and the first application associated with a first hotspot function set; 2) update the first hotspot function set based on the running of the first application to obtain a second hotspot function set, the second time being later than the first time; 3) determine to upgrade to version j of the operating system, where the first application is version m, which is higher than version n, the third time being later than the second time; 4) receive information from the operating system of version j at a given time, including the first hotspot function set, the fourth time being later than the third time; 5) restart the application to upgrade to version j of the operating system at a given time, the fifth time being later than the fourth time; 6) complete the restart, delete the second hotspot function set, and compile the application based on the files associated with the first hotspot function set used to guide compilation optimization, thereby upgrading the first application to version m, the sixth time being later than the fifth time.

[0030] In one possible implementation, the fit between the first hotspot function set and the m-th version is greater than a first threshold.

[0031] In one possible implementation, the fit between the first hotspot function set and version m is greater than a first threshold under at least one of the following conditions: the difference between the version number of version m and the version number of version n is less than the difference threshold; the number of hotspot functions in the first hotspot function set that fail in version m is less than the number threshold; or, the failure rate of hotspot functions in the first hotspot function set in version m is less than the failure threshold.

[0032] In one possible implementation, the processing unit is further configured to: at a seventh time, run the first application of version m, the operating system of the processing device is the operating system of version j, and the first application is associated with a first hotspot function set; at an eighth time, based on the running of the first application, update the first hotspot function set to obtain a third hotspot function set, the eighth time being later than the seventh time; at a ninth time, determine to upgrade to the operating system of version k, in the operating system of version k, the version of the first application is version m, the ninth time being later than the eighth time; the receiving unit is configured to: at a tenth time, receive information of the operating system of version k, the information of the operating system of version k includes the first hotspot function set, the tenth time being later than the ninth time; the processing unit is further configured to: at an eleventh time, restart to upgrade to the operating system of version k, the eleventh time being later than the tenth time; at a twelfth time, complete the restart, merge the first hotspot function set and the third hotspot function set to obtain a fourth hotspot function set, and compile based on the file associated with the fourth hotspot function set for guiding compilation optimization, thereby running the first application, the twelfth time being later than the eleventh time.

[0033] In one possible implementation, the target file is obtained by compiling a file associated with the first hotspot function set to guide compilation optimization; the processing unit is also used to: lock the target file in memory.

[0034] In another example, a receiving unit is used to obtain a first file associated with the first application of version n, the first file being used to guide compilation optimization, and the first file including a first hotspot function set; a processing unit is used to convert the first file into a second file, the second file being readable and not used to guide compilation optimization, the second file including the first hotspot function set; when the first application is upgraded from version n to version m, it is determined whether the compatibility between the first hotspot function set and version m is greater than a first threshold; if the compatibility between the first hotspot function set and version m is greater than the first threshold, the second file is converted into a third file, the third file being used to guide compilation optimization, the third file including the first hotspot function set; and version m is associated with the third file.

[0035] In one possible implementation, the fit between the first hotspot function set and version m is greater than a first threshold under at least one of the following conditions: the difference between the version number of version m and the version number of version n is less than the difference threshold; the number of hotspot functions in the first hotspot function set that fail in version m is greater than the number threshold; or, the failure rate of hotspot functions in the first hotspot function set in version m is greater than the failure threshold.

[0036] Fourthly, embodiments of this application provide a processing device including one or more processors and a memory; the memory is coupled to one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and one or more processors call the computer instructions to cause the processing device to perform the methods described in any one or any possible implementation of any aspect.

[0037] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed on a processing device, cause the processing device to perform the method described in any aspect or any possible implementation of any aspect.

[0038] Sixthly, embodiments of this application provide a computer program product, which includes computer program code that, when executed on a processing device, causes the processing device to perform the methods described in any aspect or any possible implementation of any aspect.

[0039] In a seventh aspect, this application provides a chip or chip system applied to a processing device, the chip or chip system including at least one or more processors, the one or more processors being configured to invoke computer instructions to perform the methods described in any aspect or any possible implementation of any aspect.

[0040] In one possible implementation, the chip or chip system described above in this application further includes at least one memory storing instructions. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0041] It should be understood that the third to seventh aspects of this application correspond to the technical solutions of the first and second aspects of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0042] Figure 1 This is a schematic diagram illustrating a motion effect stuttering provided in an embodiment of this application;

[0043] Figure 2 This is a schematic diagram illustrating another instance of motion effect stuttering provided in an embodiment of this application;

[0044] Figure 3 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0045] Figure 4 This is a schematic diagram of the software structure of an electronic device provided in an embodiment of this application;

[0046] Figure 5 This is a module interaction diagram of a processing method for an application provided in an embodiment of this application;

[0047] Figure 6 This is a schematic diagram of a communication system provided in an embodiment of this application;

[0048] Figure 7 This is a module interaction diagram of a method for obtaining a profile file provided in an embodiment of this application;

[0049] Figure 8 This is a schematic flowchart illustrating a processing method for an application provided in an embodiment of this application;

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

[0051] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0052] 1. Hardware over the air (HOTA) upgrade

[0053] HOTA (Hardware Over-The-Air) upgrades refer to upgrades to the hardware firmware and system software of electronic devices via wireless means (such as Wi-Fi, cellular networks, etc.). Hardware firmware can include the baseband firmware of electronic devices, the firmware of routers, etc. System software can include the operating system, security patches, performance improvements, and new features.

[0054] HOTA upgrades give electronic devices a new version number, indicating the updated firmware and system software version.

[0055] 2. Interpreter

[0056] Interpreted execution is a basic execution method where electronic devices interpret and execute code instruction by instruction. In other words, interpreted execution translates bytecode into machine code and executes it simultaneously. This method is fast to start but inefficient to execute.

[0057] 3. Just-in-time (JIT) compilation

[0058] Just-in-Time (JIT) compilation is the process by which an electronic device converts frequently executed bytecode into machine code while running code. This allows the electronic device to directly use the machine code when it is executed again, thus improving execution speed.

[0059] 4. Ahead-of-time (AOT) compilation

[0060] AOT compilation can be understood as compilation during installation. When an electronic device obtains the code, it generates an executable (odex) file, which includes machine code. When this code is run again, the electronic device can directly execute the machine code in the odex file. This helps improve the execution speed of the code.

[0061] 5. Compilation Level

[0062] The compiler level indicates the degree of optimization applied by the compiler when compiling code.

[0063] Electronic devices can include three compilation levels: verify, speed, and speed-profile.

[0064] `verify` is used only for verifying the Dalvik executable (DEX) code. `speed` can run DEX code verification and perform AOT compilation on all methods. `speed-profile` can run DEX code verification and perform AOT compilation on the methods listed in the configuration file. The configuration file can be called a profile file.

[0065] `speed` performs AOT compilation on all methods, offering the highest level of optimization. `speed-profile` performs AOT compilation on some methods, offering the next highest level of optimization. `verify` does not perform AOT compilation, offering the lowest level of optimization.

[0066] 6. Desktop Application (Launcher)

[0067] Launcher is the desktop display service in the Android system, primarily responsible for managing and displaying the device's main interface and application list. If an electronic device runs the Android system, Launcher can be responsible for displaying the home screen, application icons, wallpapers, and widgets, thus it can be used to create animations.

[0068] For example, the animations displayed by the electronic device in response to the unlocking operation, the animations displayed in response to the triggering of the application icon, and the animations displayed in response to the return to the main interface can all be drawn on the Launcher.

[0069] Launcher is a system-level process that starts when an electronic device boots up and continues to run; it is a constantly active process.

[0070] 7. Condition variables

[0071] Condition variables allow one or more threads to wait for a certain condition to be met before continuing execution, thus avoiding busy waiting. The principle behind condition variables is based on a wait queue mechanism. When a thread executes a function that calls a wait function, it adds itself to the condition variable's wait queue. When the condition is met, the wake-up function selects one or more threads from the wait queue and wakes them up.

[0072] For example, when thread A is waiting for a condition variable to be woken up, thread A needs to pause its task and enter a waiting state; that is, thread A can add itself to the condition variable's waiting queue. When other threads wake up the condition variable by executing other tasks, these other threads can send a wake-up broadcast to all threads in the condition variable's waiting queue. Thread A receives the wake-up broadcast and continues executing its corresponding task.

[0073] 8. Memory swapping and input / output blocking (I / O blocking)

[0074] Swap memory can describe the process of exchanging data in memory to swap space.

[0075] Swap space is a region on the hard drive used to temporarily store data that is not frequently accessed in memory, in order to free up physical memory for other processes that need it more.

[0076] When an electronic device is running and memory usage is under pressure, it triggers memory reclamation, swapping some data from memory to the swap space. This process is called "swap out" or "exchange". When memory usage is less under pressure, the electronic device can reload data from the swap space back into memory. This process is called "swap in" or "exchange".

[0077] Because swap space is accessed and written to via disk, its access speed is slower than memory operations. When an electronic device reloads data from swap space into memory, it may encounter I / O blocking issues. In other words, there may be a delay in reloading data from swap space into memory, causing lag or stuttering.

[0078] 9. Beta users

[0079] In software development, "Beta users" refer to users who participate in public testing before the official release of the software. They use the test version of the software and provide feedback and opinions to help the development team identify and resolve issues.

[0080] 10. Other terms

[0081] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. For example, "first version" and "second version" are merely used to distinguish different versions and do not limit their order. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0082] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0083] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one 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 of a, b, or c can represent: a, b, c, ab, a--c, bc, or abc, where a, b, and c can be single or multiple.

[0084] 11. Electronic equipment

[0085] The electronic devices in this application embodiment may include handheld devices, in-vehicle devices, etc., with application programs. For example, some electronic devices include: mobile phones, tablets, PDAs, laptops, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving vehicles, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to wireless modems, in-vehicle devices, wearable devices, terminal devices in 5G networks, or future evolution of public land mobile communication networks. Terminal devices in a network (PLMN), etc., are not limited to this in the embodiments of this application.

[0086] By way of example and not limitation, in this embodiment, the electronic device can also be a wearable device. Wearable devices, also known as wearable smart devices, are a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Wearable devices are portable devices that are worn directly on the body or integrated into the user's clothing or accessories. Wearable devices are not merely hardware devices, but also achieve powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include those that are feature-rich, large in size, and can achieve complete or partial functions without relying on a smartphone, such as smartwatches or smart glasses, as well as those that focus on a specific type of application function and require the use of other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0087] Furthermore, in this embodiment of the application, the electronic device can also be a terminal device in the Internet of Things (IoT) system. IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection.

[0088] The electronic devices in this application embodiment can also be referred to as: terminal equipment, user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device, etc. Currently, the performance of system applications installed on electronic devices is poor, affecting the user experience.

[0089] Poor performance of system applications installed on electronic devices may be due to several reasons:

[0090] On the one hand, the way system applications are compiled results in poor performance of system applications installed on electronic devices.

[0091] Electronic devices come pre-installed with system applications, which are compiled at the verify level. When an electronic device is first started, because the system applications are compiled at a lower level, the device can use an interpreted + JIT compilation method, which results in a slower compilation speed.

[0092] When an electronic device is running system applications, it can store some frequently accessed functions in a profile file. When the number of these functions in the profile file reaches a preset threshold, the electronic device can upgrade its compilation level to speed-profile. When the electronic device is idle, it uses AOT (Asynchronous Over-The-Air) compilation to generate an odex file. Idleness can be defined as the electronic device being in a locked state and / or charging state.

[0093] However, the generated odex file is generally used when the system application restarts. When the system application, such as a desktop application, is a keep-alive application, even if an odex file is generated, the electronic device cannot call the generated odex file before the system application restarts, and thus continues to use the interpreted execution + JIT compilation method, which cannot improve the compilation speed of the system application.

[0094] In some examples, in response to instructions used to view the build level of a desktop application, the electronic device can display the desktop application's build level, the application installer, and build files related to optimization and operation. The instruction for viewing the desktop application's build level can be `dumpsys package dexopt-pkcom.hihonor.android.launcher`. The desktop application level displayed by the electronic device can be `speed-profile`. The application installer can include .APK files. Build files related to optimization and operation can include .vdex files.

[0095] If the odex file is not included in the compilation files related to optimization and operation, it means that although the desktop application's compilation level is speed-profile and the odex file is compiled when idle, it is not loaded on the electronic device.

[0096] When an electronic device undergoes a HOTA upgrade, the system applications restart. However, the HOTA upgrade changes the system version, and the system applications within that version may also be upgraded. There may be a mismatch between the odex files of the system applications before the HOTA upgrade and those after the upgrade. Consequently, the previous odex files become invalid and cannot be loaded. This causes the electronic device to continue using the interpreted execution + JIT compilation method during the HOTA upgrade, failing to improve the compilation speed of the system applications.

[0097] This prevents electronic devices from performing AOT (Ahead-of-Time) compilation. Prolonged compilation using interpreted execution combined with JIT (Just-In-Time) compilation leads to issues such as lag, high load, and high power consumption when running system applications. Poor system application performance negatively impacts the user experience.

[0098] To better understand why the compilation method of system applications leads to poor performance, the following explanation uses desktop applications as an example.

[0099] Desktop applications (launchers) can be used to draw animations. For example, animations displayed by an electronic device in response to unlocking, in response to triggering an application icon, and in response to returning to the home screen can all be drawn on the launcher.

[0100] In one scenario, when an electronic device displays a corresponding animation in response to an action that triggers an application icon, it experiences lag.

[0101] For example, Figure 1 This diagram illustrates a situation where a motion effect stutters. For example... Figure 1 As shown, in response to triggering an application icon, the electronic device can display animations via the Launcher process's main thread. While the Launcher process's main thread displays the animations, the JIT thread is used to compile functions using JIT compilation. Figure 1 In the image, the black-filled portion represents the runtime, and the white-filled portion represents the lag duration.

[0102] like Figure 1 As shown, the electronic device experiences a lag when executing the main thread of the Launcher process, and the lag lasts for a considerable period of time. This causes the electronic device to need a longer time to display animations, resulting in animation lag.

[0103] like Figure 1 As shown, during the Launcher process's runtime pause, the JIT thread compiles function A, and during the compilation of function A, it executes the `jit_lock_` method. After the `jit_lock_` method completes, the Launcher process's main thread can continue executing subsequent processes.

[0104] from Figure 1 As can be seen, the JIT thread holding the lock blocked the main thread of the Launcher process, causing the animation to stutter.

[0105] In another scenario, when a user triggers a return to the main screen, the electronic device displays a stutter when showing the corresponding animation.

[0106] For example, Figure 2 This diagram illustrates another instance of motion effects stuttering. Figure 2The scenario shown represents an electronic device displaying animations in response to a user's action of returning to the main interface. Before displaying the animations, the electronic device can render them. The thread used for rendering the animations in the electronic device can be represented as a render thread. A JIT thread is used to compile functions using the JIT compilation method. Figure 2 In the image, the black-filled portion represents the runtime, and the white-filled portion represents the lag duration.

[0107] like Figure 2 As shown, when the electronic device is executing the rendering thread, it experiences a lag, which causes the electronic device to need a longer time to display animation effects, resulting in animation lag.

[0108] like Figure 2 As shown, when the rendering thread lags, the JIT thread is compiling function B. During the compilation of function B, the JIT condition variable blocks the rendering thread, causing the animation to stutter.

[0109] From the above Figure 1 and Figure 2 It can be seen that the stuttering animations are due to the use of JIT compilation. JIT compilation is used because electronic devices cannot perform AOT compilation, thus the compilation method of system applications leads to poor performance.

[0110] On the other hand, lock file failure leads to poor performance of system applications.

[0111] To ensure normal system operation, in some scenarios, when system applications run in the background, electronic devices can swap the application data out of memory. To avoid I / O file blocking during swapping into memory, electronic devices can use file locking to lock certain important data of the system application in physical memory, preventing this data from being swapped out. This minimizes the probability of I / O file blocking while ensuring normal system operation. Specifically, file locking uses the filename to lock the odex file corresponding to the data.

[0112] When the system application's compilation level is raised to speed-profile, a corresponding profile file is created. This file can be updated as the electronic device is used. After the electronic device detects an update to the profile file, it can generate a new odex file when idle, and the old odex file is renamed to "garbled suffix + temp".

[0113] For example, before a new odex file is generated, the odex file name can be launcher.APK@classes.dex. After a new odex file is generated, the odex file name can be represented as launcher.APK@classes.dex.ZGHslQQ.temp.

[0114] Because the lock file locks the odex file corresponding to the data by its filename, when a new odex file is generated, the filename of the old odex file changes. This causes the lock file to become invalid, leading to the electronic device still swapping system application data out of memory when running system applications, resulting in I / O file blocking and poor system application performance.

[0115] In view of this, embodiments of this application provide an application processing method and processing apparatus that can solve the above problems.

[0116] 1) Electronic devices come pre-installed with system applications, which are compiled at the speed-profile level, meaning each system application has a corresponding profile file. When the electronic device is first started, because the system applications have a higher compilation level, AOT (Ahead-of-Time) compilation can be used. Compared to interpreted execution + JIT (Just-In-Time) compilation, this improves the performance of the system applications.

[0117] 2) The profile file corresponding to the application is preset before the electronic device leaves the factory. The methods in the profile file are obtained through extensive statistical analysis. The probability of the electronic device updating the profile file based on user usage is relatively small, and the probability of generating a new odex file is also small. Therefore, the probability of old files being renamed is low, and consequently, the probability of file lock failure is low. When the electronic device runs system applications, it will not swap system application data out of memory, reducing the probability of I / O file blocking and improving system application performance.

[0118] 3) When electronic devices undergo HOTA upgrades, the system applications will restart. If the system applications are upgraded, the profile file before the HOTA upgrade will become invalid. The upgraded system applications have a default profile file, and the electronic devices can generate odex files based on this profile file. This eliminates the need to use the interpreted execution + JIT compilation method due to the invalidation of the profile file before the HOTA upgrade, which is beneficial to improving the performance of the system applications.

[0119] The method provided in this application can be applied to electronic devices with applications installed, such as mobile phones or tablets. For ease of understanding, the hardware structure of the electronic device according to this application embodiment is described below.

[0120] For example, Figure 3 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, and a display screen 194, etc.

[0121] Optionally, the aforementioned sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0122] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0123] In this embodiment, the touch sensor 180K can detect when a user triggers an operation to install an application and transmits this operation to the processor 110. The processor 110 can then execute the method provided in this embodiment in response to the application installation operation.

[0124] The software system of an electronic device can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. A layered architecture can use the Android system, the Apple iOS system, or other operating systems; this application embodiment does not limit this. The following uses a layered Android system as an example to illustrate the software structure of the electronic device.

[0125] Figure 4This is a schematic diagram of the software structure of an electronic device to which this application applies. A layered architecture can divide the software system of an electronic device into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system can be divided into four layers, from top to bottom: applications, application framework, Android runtime and system libraries, and kernel.

[0126] The application layer can include a series of application packages. The application layer runs applications by calling the application programming interface (API) provided by the application framework layer. For example... Figure 4 As shown, the application package can include desktop applications, system UI, negative one screen, phone, SMS, contacts, camera, music, maps, and chat applications.

[0127] The application framework layer provides APIs and a programming framework for applications within the application layer. The application framework layer includes predefined functions. For example... Figure 4 As shown, the application framework layer can include a memory management module and an Android runtime service (ArtService). ArtService includes ArtManagerLocal, DexoptHelper, Dexopter, and IArtd.

[0128] ArtService is a thread within the system server process that manages and optimizes the runtime environment of Android applications. ArtManagerLocal, or local Android runtime management, provides local management of the Android runtime environment within the Android system. DexoptHelper, or Dex optimizer, is a tool or component used to optimize Dex files. DexoptHelper, Dexopter, and IArtd enable compilation optimization. The memory management module is used for file locking.

[0129] The Android runtime consists of the core libraries and the virtual machine. The Android runtime is responsible for scheduling and managing the Android system. The core libraries comprise two parts: one part contains the functionalities that Java needs to call, and the other part is the Android core library itself. The application layer and application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection. System libraries can contain modules with multiple functionalities, such as surface managers, media libraries, and 3D graphics processing libraries.

[0130] The virtual machine includes artd. Responding to instructions from ArtService to perform compilation optimizations, artd can be used to implement compilation optimizations via dex2oat. dex2oat is a compilation function that performs compilation optimization operations on executable files (dex files) in the installation package, generating optimized compilation files.

[0131] The kernel layer is the layer between hardware and software. It drives the hardware, enabling it to function. The kernel layer includes at least display drivers, fingerprint drivers, camera drivers, and Bluetooth drivers, but this application does not limit this specific component.

[0132] To better understand the embodiments of this application, the methods provided in the embodiments of this application will be described first.

[0133] For example, Figure 5 This diagram illustrates a module interaction diagram of a processing method for an application provided in an embodiment of this application. This method can be applied to electronic devices. The hardware structure of the electronic device can be as described above. Figure 3 As shown above, the software architecture can be as described above. Figure 4 As shown, however, the embodiments of this application do not limit this. The embodiments of this application use the software architecture of an electronic device as described above. Figure 4 The following example illustrates this. The Android runtime service process can include threads such as ArtManagerLocal, DexoptHelper, Dexopter, and IArtd. The code for the artd process runs in the artd.cc file.

[0134] like Figure 5 As shown, the method may include the following steps:

[0135] After S501 and HOTA upgrades, the compilation optimization is triggered upon boot. ArtManagerLocal can determine whether the system application undergoing compilation optimization has a pre-built profile file.

[0136] When an electronic device undergoes a HOTA upgrade, it retrieves a new system version from the server and then runs the new system version upon startup. This HOTA upgrade triggers compilation optimizations during startup.

[0137] The new system version may include multiple system applications, and one or more of these applications may have pre-installed profile files. After an electronic device undergoes a HOTA upgrade, booting up can trigger the compilation and optimization of each system application.

[0138] During the compilation and optimization process of electronic devices, ArtManagerLocal can determine whether the system application being optimized has a pre-built profile file. If the system application has a pre-built profile file, it means that the compilation level of the system application is speed-profile. If the system application does not have a pre-built profile file, it means that the compilation level of the system application is verify.

[0139] If the system application has a pre-built profile file, the electronic device can execute... Figure 5 The subsequent process is shown below. If the system application does not have a pre-built profile file, the electronic device performs verify-level compilation optimizations, specifically implemented in... Figure 5 Not shown in the image.

[0140] In this embodiment, the system application has a pre-built profile file, which can also be referred to as the system application having a preset profile file, or the system application having a corresponding profile file. This embodiment does not limit this.

[0141] There can be one or more system applications that undergo compilation optimization. The processing procedure is the same for each system application undergoing compilation optimization. This application uses one system application undergoing compilation optimization as an example for illustration.

[0142] In some examples, the system application can be the system UI. ArtManagerLocal can check if a profile file exists and its acquisition path is under the path `$project_work_path+ci_odex_dependencies / system_profile`. The system UI's profile file can be represented as `SystemUI.prof`, and the acquisition path for the profile file can be `system / priv-app / SystemUI / SystemUI.prof`.

[0143] S502. If the system application has a pre-built profile file, ArtManagerLocal can determine whether the profile file before the HOTA upgrade is valid.

[0144] HOTA upgrades may result in version upgrades for one or more system applications. If the version number of a system application in the new system version differs from that in the old system version, it indicates that the system application has been upgraded. System application version upgrades can cause incompatibility between the pre-upgrade profile file and the new version of the system application. Therefore, when an electronic device undergoes a HOTA upgrade, it will determine whether the versions of each system application have been upgraded.

[0145] If the system application version has been upgraded, the profile file of the old version of the system application before the HOTA upgrade can be deleted.

[0146] If the system application version has not been upgraded, the profile file of the old version of the system application before the HOTA upgrade can be retained.

[0147] S503. If the profile file before the HOTA upgrade is valid, ArtManagerLocal can merge the old version profile file before the HOTA upgrade and the new version profile file to obtain a new profile file.

[0148] If the profile file before the HOTA upgrade is valid, and there are old and new version profile files, ArtManagerLocal can merge these two profile files to obtain a new profile file.

[0149] In this embodiment, merging two profile files to obtain a new profile file allows the profile file to include more content, reducing the probability of the electronic device updating the profile file based on user usage and generating a new odex file. This also reduces the probability of the old file being renamed, and consequently, the probability of the lock file becoming invalid. Furthermore, the electronic device will not swap system application data out of memory when running system applications, reducing the probability of I / O file blocking and thus lowering the likelihood of system application lag.

[0150] In one example, ArtManagerLocal might merge two profile files according to the following rule: only one copy of the content common to both profile files is kept, while all content that differs between the two profile files is retained. This helps save memory.

[0151] S504. After generating the new profile file, ArtManagerLocal can instruct DexoptHelper to perform compilation optimization based on the new profile file.

[0152] In some examples, ArtManagerLocal can call DexoptHelper to perform compilation optimizations based on the new profile file.

[0153] Optionally, ArtManagerLocal in S501 to S505 above can all be implemented using the dexoptPackage() function.

[0154] S505, DexoptHelper, Dexopter, and IArtd can set compilation optimization parameters based on the new profile file.

[0155] In one example, compiler optimization parameters may include the number of threads, cache settings, memory configuration, and code optimization. Memory configuration can be the amount of memory available. Code optimization can involve removing redundant code logic.

[0156] DexoptHelper can call Dexopter, which in turn can call IArtd to set compilation optimization parameters based on the new profile file.

[0157] S506 and IArtd can instruct artd to perform compilation optimizations based on compilation optimization parameters.

[0158] In one example, IArtd and artd can communicate via binder to instruct artd to perform compilation optimizations based on parameters.

[0159] S507 and artd can perform speed-profile level compilation optimization based on compilation optimization parameters, generating odex files.

[0160] In one example, the artd thread can perform speed-profile level compilation optimizations using the Artd:dexopt() function to generate odex file 1. Alternatively, the artd thread can create dex2oat and use it for compilation optimizations.

[0161] The above S504 to S507 describe the process of performing speed-profile level compilation optimization based on the new profile file. The process is similar to the process of performing speed-profile level compilation optimization based on the old profile file, and will not be described in detail here.

[0162] After S508 and artd generate odex file 1, they can transmit an instruction message indicating that compilation and optimization are complete to ArtManagerLocal. This instruction message may include the file name of odex file 1.

[0163] Optionally, the indication information may also include the file size of odex file 1.

[0164] S509. In response to the indication that compilation optimization is complete, ArtManagerLocal can transmit information to the memory management module to lock odex file 1.

[0165] The information that locks odex file 1 can include the file name of odex file 1, or it can include the file name and size of odex file 1.

[0166] S510. In response to the information that odex file 1 is locked, the memory management module can use the memory locking mechanism to lock odex file 1.

[0167] The memory management module uses a memory-locking file mechanism to lock the odex file 1, which can include a variety of possible implementations.

[0168] In one possible implementation, in response to the information that odex file 1 is locked, the memory management module can unbind the system application from the previous odex file and then bind it to odex file 1, thus locking odex file 1.

[0169] This reduces the interaction between the memory management module and ArtManagerLocal, making the implementation simple.

[0170] In another possible implementation, ArtManagerLocal can transmit unbinding information to the memory management module. In response to this unbinding information, the memory management module can unbind the system application from the previous odex file. ArtManagerLocal can also transmit locking information to the memory management module. In response to locking information for odex file 1, the memory management module can bind the system application to odex file 1, thus locking odex file 1.

[0171] In this way, the memory management module does not need to determine whether to unbind or bind; it only needs to operate according to the instructions, which reduces the requirements for the memory management module.

[0172] In this embodiment of the application, locking the odex file 1 prevents the electronic device from swapping the system application's data out of memory when running the system application, thus reducing the probability of I / O file blocking and helping to lower the probability of system application lag.

[0173] S511. If the number of profile files is 1, then ArtManagerLocal, DexoptHelper, Dexopter, IArtd and the memory management module can use the pre-made profile file to perform speed-profile level compilation optimization, generate odex file 2, and use the memory locking file mechanism to lock odex file 2.

[0174] For specific implementation details, please refer to S504 to S510 above, which will not be repeated here.

[0175] From the above Figure 5 It can be seen that the system application has a pre-built profile file with a compilation optimization level of speed-profile. Compared with the verification level compilation optimization, this is beneficial to improving the compilation speed and the performance of the system application.

[0176] If the system application has a pre-built profile file and the application version hasn't been upgraded, the profile file before the HOTA upgrade remains valid. After the HOTA upgrade, the electronic device can merge the pre-built profile file with the one before the upgrade to obtain a new profile file. This allows the profile file to include more content, reducing the likelihood of subsequent updates based on user activity and the generation of new odex files. This also reduces the probability of old files being renamed and, consequently, file invalidation. Furthermore, the electronic device won't swap system application data out of memory when running system applications, minimizing I / O file blocking and improving application performance.

[0177] After performing speed-profile level compilation optimization and generating the odex file, the memory locking mechanism is used to lock odex file 2. When the electronic device runs this system application, the system application's data will not be swapped out of memory, reducing the probability of I / O file blocking and improving the system application's performance.

[0178] In the above Figure 5 The example shown uses a HOTA upgrade scenario for illustration. This embodiment is also applicable to the scenario of the first startup of an electronic device after it leaves the factory.

[0179] In this scenario, after booting up and triggering compilation optimization, the electronic device can determine whether the system application undergoing compilation optimization has a pre-built profile file. If a profile file is pre-built, it uses the pre-built profile file to perform speed-profile level compilation optimization, generates an odex file, and uses a memory file locking mechanism to lock the odex file. The effect in this scenario is the same as before, and will not be elaborated further here.

[0180] The embodiments of this application are also applicable to scenarios involving version updates of third-party applications.

[0181] In this scenario, the electronic device can obtain a new software version from the third-party application's server. When updating the software version and performing compilation optimization, it checks whether the third-party application has a pre-built profile file. If a profile file is pre-built, it uses the pre-built profile file to perform speed-profile level compilation optimization, generates an odex file, and uses a memory file locking mechanism to lock the odex file. The effect in this scenario is the same as before, and will not be elaborated further here.

[0182] Electronic devices utilize pre-built profile files to perform speed-profile level compilation optimizations, which helps reduce power consumption compared to using verify level compilation optimizations.

[0183] For example, Table 1 shows a data table comparing power consumption at different compilation levels.

[0184] Table 1

[0185]

[0186] The system application tested in this embodiment is the negative one screen. In Table 1, "normal installation" indicates that the negative one screen uses verify-level compilation optimization, and "optimized installation" indicates that the negative one screen uses speed-profile-level compilation optimization. The testing methods and tools are the same. Four sets of tests were performed for each scenario, and the average power consumption was calculated based on the results of the four sets of tests.

[0187] As shown in Table 1, when there are 0 applications running in the background, the power consumption of the optimized installation of the negative one screen is 537.173, while the power consumption of the normal installation is 600.43. Since 537.173 is less than 600.43, it indicates that the power consumption of the optimized installation of the negative one screen is lower than that of the normal installation. When multiple applications are running in the background, the power consumption of the optimized installation of the negative one screen is 532.763, while the power consumption of the normal installation is 577.885. Again, since 532.763 is less than 600.43, it indicates that the power consumption of the optimized installation of the negative one screen is lower than that of the normal installation.

[0188] As shown in Table 1, using a pre-built profile file to perform speed-profile level compilation optimization is more effective in reducing the power consumption of electronic devices compared to using verify level compilation optimization.

[0189] In the method described above, the system application can have a pre-built profile file. The source of the profile file will be explained in detail below.

[0190] For example, Figure 6 A schematic diagram of a communication system is shown. For example... Figure 6 As shown, the communication system includes multiple test devices 610, a server 620, and an electronic device 630. The electronic device 630 can be any of the electronic devices described above. The server 620 can include one or more servers, but this embodiment does not limit the specific type. Figure 6 In this embodiment of the application, server 620, including server 621, server 622 and server 623, is used as an example for illustration.

[0191] This application embodiment can utilize the communication system to obtain the system application profile file. The process of obtaining the system application profile file using this communication system will be described below:

[0192] 1) Each of the multiple test devices 610 can deploy one or more system applications, and the software version of the same system application is the same across different test devices. For example, each of these multiple test devices 610 deploys desktop application 3.1, negative one screen 2.1, and system UI 1.5.

[0193] Each of these multiple test devices 610 can collect hot-spot functions of the system application based on the usage of simulated users, and generate a profile file. The profile file includes the collected hot-spot functions. Simulated users can be either lab users or beta users. Hot-spot functions are those frequently called during program execution.

[0194] This application example illustrates the deployment of a system application using multiple test devices 612.

[0195] 2) Server 621 can obtain the system application profile files from these multiple test devices 610.

[0196] The profile file of a system application is bound to the application's version information. This version information can also be referred to as APK version information. In one example, the application's version information may include a version number and a version name.

[0197] Server 621 can convert the system application's profile file into a readable hotspot function file for the system application. The readable hotspot function file is unrelated to version information. Converting the system application's profile file into a readable hotspot function file can be understood as server 621 unbinding the profile file from version information. Subsequent readable hotspot function files can be bound to any version information. Here, "readable hotspot function file" indicates a file where hotspot functions are readable. In some examples, the format of the readable hotspot function file can be a .txt file. In some examples, after obtaining the system application's profile file, server 621 can use the system application's version information to convert the corresponding profile file into a readable hotspot function file for the system application. The system application's version information can be obtained by server 621 from test device 610, from other servers, or input by testers; this embodiment does not limit this.

[0198] Server 621 can send readable hotspot function files of system applications to server 622.

[0199] 3) Server 622 receives readable hotspot function files from server 621 for the system application. If the system application needs to be upgraded, server 622 can calculate the number of hotspot functions included in the readable hotspot function files of the old version of the system application that are invalid in the new version of the system application. If the number is greater than or equal to a threshold, it indicates that the compatibility between the readable hotspot function files of the old version and the new version is low, and it is necessary to re-collect data through multiple test devices.

[0200] If the value is less than the threshold, it indicates a high degree of compatibility between the old version's readable hotspot function files and the new version, eliminating the need for re-collection through multiple testing devices. Server 622 can convert the readable hotspot function files of the old version of the system application into profile files.

[0201] In this way, it is not necessary to collect data through multiple testing devices again to configure the corresponding profile file for the new version of the system application, which helps to shorten the time for obtaining the profile file.

[0202] For system applications that do not require upgrades, the server 622 can convert readable hotspot function files into profile files.

[0203] Server 622 can send the system application profile file to server 623.

[0204] 4) Server 623 can archive the profile files of system applications. If a system application needs to be upgraded, server 623 can bind the profile file of the system application to the application package (Android application package, APK) of the new version of the system application. If the system application does not need to be upgraded, server 623 can bind the profile file of the system application to its corresponding APK for subsequent use by electronic device 630.

[0205] 5) When electronic device 630 requests HOTA upgrade from server 623, server 623 can send a new system version to electronic device 630. This new system version includes the profile file and APK of the system application. Electronic device 630 can then use the aforementioned... Figure 5 The method shown is used for compilation optimization.

[0206] The system applications are updated frequently. For example, on January 1st, Desktop Application 3.1 was updated to Desktop Application 3.2, Negative One Screen 2.1 was updated to Negative One Screen 2.2, and System UI 1.5 was updated to System UI 1.6. On March 1st, Desktop Application 3.2 was updated to Desktop Application 3.3, Negative One Screen 2.2 was updated to Negative One Screen 2.3, and System UI 1.6 was updated to System UI 1.7. If data is collected using multiple testing devices each time, the efficiency is slow. In this embodiment, when a new version update exists, the server 622 can use the same readable hotspot function file or profile file, provided that the readable hotspot function file of the old version has a high degree of compatibility with the new version. This avoids changing the readable hotspot function file or profile file with each version update, thus improving efficiency.

[0207] Alternatively, if the system application does not need to be upgraded, the server 623 may not send the system application's APK to the electronic device, and the electronic device can use the existing system application's APK.

[0208] To better understand the method for obtaining the profile file described above, the following will combine... Figure 7 This section provides a detailed explanation of how to obtain the profile file.

[0209] For example, Figure 7 A module interaction diagram illustrating a method for obtaining profile files is shown. This method can be applied to the above... Figure 6 The communication system shown. (As shown) Figure 7 As shown, the method may include the following steps:

[0210] S701, in multiple test devices 610, each test device runs test cases and generates a profile file.

[0211] Different system applications can have different test cases or the same test cases; this application embodiment does not limit this. When a system application undergoes a major version upgrade, such as from 1.0 to 2.0, or updates important features, each of the multiple test devices 610 can run test cases and generate a profile file.

[0212] In one example, each of the multiple test devices 610 can generate a profile file in response to a command to generate a profile file. The command to generate the profile file can be something like `adb shell cmd packagesnapshot-profile`. <pkgname>.

[0213] S702, In response to the instruction to extract the profile file, each of the multiple test devices 610 can send the profile file to the server 621.

[0214] After receiving multiple profile files, S703 and server 621 can determine whether the received multiple profile files are empty.

[0215] If the profile file is empty, the data collection will fail. If the profile file is not empty, the subsequent processes can proceed.

[0216] S704. If the profile file is not empty, server 621 can convert the profile file into a readable hotspot function set file.

[0217] In one example, if the profile file is not empty, server 621 can use the profman tool to convert the profile file into a readable hotspot function file.

[0218] Understandably, server 621 can obtain multiple profile files, thus obtaining multiple readable hotspot function files. Server 621 can then merge these multiple readable hotspot function files to obtain a readable hotspot function set file.

[0219] Server 621 can merge multiple readable hotspot function files using the following rule: only one copy of the common content among the multiple readable hotspot function files is kept, while all different content among the multiple readable hotspot function files is kept. This helps save memory.

[0220] Optionally, the hotspot function set file is readable, thus allowing developers to view it. This embodiment of the application supports developers manually updating the contents of the hotspot function set file.

[0221] In one example, the hotspot function set file stores the method signatures of hotspot functions in a readable format. When developers manually update the contents of the hotspot function set file, they can simply use the same method signatures.

[0222] For example, the method signature for saving hot functions can be:

[0223] HPLandroidx / collection / LongSparseArray;->put(JLjava / lang / Object;)V.

[0224] Following S704 above, server 621 can obtain multiple profile files. Server 621 can convert these multiple profile files into readable hotspot function files, obtain multiple readable hotspot function files, and then merge these multiple readable hotspot function files.

[0225] In another example, after S704 above, server 621 can obtain multiple profile files. Server 621 can merge these multiple profile files and then convert them into a readable hotspot function file.

[0226] S705, Server 621 sends a readable hotspot function set file to Server 622.

[0227] Sending a readable hotspot function set file directly from server 621 to server 622 is just one example.

[0228] In another example, server 621 can store a readable hotspot function set file at a specified path, which server 621 can send to server 622. Server 622 can then retrieve the readable hotspot function set file from that path.

[0229] The readable hotspot function set file is large and consumes a lot of resources. Sending the path helps to save interaction resources.

[0230] S706 and server 622 detected a version upgrade of the system application.

[0231] In one example, server 622 receives an instruction from the system application to upgrade its version, and can determine that the system application needs to be upgraded.

[0232] S707 and Server 622 determine whether the number of hot functions in the old version's readable hot function set file that are invalid in the new version is greater than or equal to a threshold.

[0233] If the number of hot functions in the old version's readable hotspot function set file that are no longer valid in the new version is greater than or equal to a threshold, it indicates that the compatibility between the old version's readable hotspot function set file and the new version is low. If the number of no longer valid functions is less than the threshold, it indicates that the compatibility between the readable hotspot function set file and the new version is high.

[0234] S708. If the number of failures is less than the threshold, server 622 can obtain the APK of the new version of the system application.

[0235] Server 622 can obtain the APK of the new version of the system application in several ways.

[0236] In one possible approach, server 622 can obtain the binary file of the system application's APK. This eliminates the need to obtain the original code, simplifying the implementation.

[0237] In another possible implementation, server 622 can obtain the non-binary file (e.g., raw code) of the system application's APK, and then compile it into a binary file. This yields a more raw non-binary file, allowing for more operations compared to directly obtaining the binary file.

[0238] S709 and Server 622 can use the APK of the new version of the system application to convert readable hotspot function set files into profile files.

[0239] This step can be understood as binding the readable hotspot function set file to the software version.

[0240] As can be seen from S706 to S709 above, a readable hotspot function set file stores hotspot functions in a readable format and is independent of version information and system version. Therefore, when the hotspot functions do not change significantly between different versions, server 622 can configure different software versions and / or system versions for the readable hotspot function set file.

[0241] For example, if the readable hotspot function set file is obtained from version 1.0, server 622 can configure the APK of version 1.0 for the readable hotspot function set file. When upgrading from version 1.0 to version 1.1, since the hotspot functions do not change much between version 1.0 and version 1.1, server 622 can also configure the APK of version 1.1 for it.

[0242] S710 and server 622 can send profile files to server 623.

[0243] S711 and server 623 can send a system version to electronic device 630, which may include a profile file and the APK of system applications.

[0244] Server 623 can send a system version to electronic device 630. The system version includes the APK and profile files of various system applications, so as to update the various system applications when updating the system version in electronic device 630.

[0245] Optionally, server 623 may send profile files and APKs of system applications to electronic device 630 to update system applications in electronic device 630 separately.

[0246] Electronic device 630 can be based on the above Figure 5 The method shown updates the system version.

[0247] The method provided in this application unbinds the profile file obtained by the testing device from the software version, so that after the software version is upgraded, the new software version can be configured for the profile file. In this way, different software versions can correspond to one profile file, eliminating the need to extract the profile file for each software version, which helps to improve the efficiency of obtaining the profile file.

[0248] To better understand the methods provided in the embodiments of this application, two scenarios are constructed in the embodiments of this application.

[0249] In one scenario, for example, Figure 8 A schematic diagram of a processing method for an application provided in an embodiment of this application is shown. For example... Figure 8 As shown, the method may include the following steps:

[0250] S801. At the first moment, the electronic device runs the first application of version n, the operating system of the electronic device is the operating system of version i, and the first application is associated with the first hotspot function set.

[0251] In this embodiment, the hotspot function set can be understood as the hotspot functions in the aforementioned profile file. The i-th version of the operating system can also be referred to as system version i. The first application can be a system application or a third-party application; this embodiment does not limit this. If the first application is a system application, it can be a constantly active application.

[0252] The first application is associated with a first set of hot functions, and electronic devices can perform speed-profile level compilation optimizations based on the first set of hot functions.

[0253] S802, at the second moment, the electronic device updates the first hotspot function set based on the operation of the first application to obtain the second hotspot function set. The second moment is later than the first moment.

[0254] The first hotspot function set and the second hotspot function set are used to represent different profile files.

[0255] S803, at the third moment, the electronic device determines to upgrade to the j-th version of the operating system. In the j-th version of the operating system, the version of the first application is the m-th version, which is higher than the n-th version. The third moment is later than the second moment.

[0256] Operating system version j can also be called system version j. If the first application upgrades from version n to version m, then version n can be understood as the old version, and version m as the new version.

[0257] S804, at the fourth moment, the electronic device receives information from the j-th version of the operating system. The information from the j-th version of the operating system includes the first hotspot function set. The fourth moment is later than the third moment.

[0258] The information for the j-th version of the operating system includes the first hotspot function set, which can be understood as the first application having the first hotspot function set pre-installed.

[0259] S805, at the fifth moment, the electronic device restarts to upgrade to the j-th version of the operating system. The fifth moment is later than the fourth moment.

[0260] S806, at the sixth moment, the electronic device completes the restart, deletes the second hotspot function set, and compiles based on the file associated with the first hotspot function set that guides compilation optimization, thereby upgrading the first application to version m. The sixth moment is later than the fifth moment.

[0261] When an electronic device upgrades from operating system version i to operating system version j, it will reboot. Since the operating system upgrade causes the first application to upgrade from version n to version m, the second hotspot function set will become invalid. The electronic device can delete the second hotspot function set. When the electronic device upgrades to operating system version j, the information in operating system version j includes the first hotspot function set. Therefore, the electronic device can compile based on the files associated with the first hotspot function set that guide compilation optimization, thus achieving the upgrade of the first application to version m.

[0262] This method can be referred to above. Figure 5 S501, S502 and S511 are shown.

[0263] In this way, although upgrading the first application version will cause the second hot function set to become invalid, it can be compiled using the files associated with the first hot function set that guide compilation optimization. Compared with the method of interpreting and JIT compilation, this is beneficial to improving the performance of the application.

[0264] In the above scenario, the electronic device updates the first hotspot function set based on the operation of the first application to obtain the second hotspot function set. In one example, the first hotspot function set is more comprehensive, and the electronic device may update the first hotspot function set without being based on the operation of the first application.

[0265] In another scenario, the method provided in this application embodiment may include: an electronic device running a first application of version n, the electronic device's operating system being an operating system of version i, and the first application being associated with a first hotspot function set; the electronic device determining to upgrade to an operating system of version j, in which the version m of the first application is higher than version n; the electronic device receiving information from the operating system of version j, the information of the operating system of version j including the first hotspot function set; the electronic device restarting to upgrade to the operating system of version j; the electronic device completing the restart, deleting the first hotspot function set, and compiling based on the files associated with the first hotspot function set used to guide compilation optimization, thereby achieving the upgrade of the first application to version m.

[0266] When an electronic device upgrades from operating system version i to operating system version j, it will reboot. Since the operating system upgrade causes the first application to upgrade from version n to version m, the first hotspot function set will become invalid. The electronic device can delete the first hotspot function set. When the electronic device upgrades to operating system version j, the information in operating system version j still includes the first hotspot function set. Therefore, the electronic device can compile based on the files associated with the first hotspot function set that guide compilation optimization, thus achieving the upgrade of the first application to version m.

[0267] In this way, although upgrading the first application version will cause the first hot function set to become invalid before the upgrade, it can be compiled using the files associated with the first hot function set in the operating system information that guide compilation optimization. Compared with the method of interpreting and JIT compilation, this is beneficial to improving the performance of the application.

[0268] Optionally, in the above two scenarios, the information of the j-th version of the operating system includes the first hotspot function set because the first hotspot function set has a greater compatibility with the m-th version than the first threshold.

[0269] If the fit between the first hotspot function set and the m-th version is greater than the first threshold, it can be concluded that the first hotspot function set is not only compatible with the n-th version, but also compatible with the m-th version.

[0270] In this way, different versions of the first application can correspond to the same set of hot functions, eliminating the need to set up a separate set of hot functions for each version, reducing the time spent collecting hot functions, and simplifying the implementation.

[0271] Optionally, the fit between the first hotspot function set and version m is greater than a first threshold under at least one of the following conditions: the difference between the version number of version m and the version number of version n is less than the difference threshold; the number of hotspot functions in the first hotspot function set that fail in version m is less than the number threshold; or, the failure rate of hotspot functions in the first hotspot function set in version m is less than the failure threshold.

[0272] In one example, if the difference between the version number of version m and the version number of version n is less than the difference threshold, it can be said that the fit between the first hotspot function set and version m is greater than the first threshold.

[0273] For example, if the version number of version m is 1.1 and the version number of version n is 1.0, the difference threshold can be 0.5 or 1. If the difference threshold is less than 0.5, the difference between the version number of version m and version n is 1.1 - 1.0 = 0.1. Since 0.1 is less than 0.5, the first hotspot function set is compatible with version m.

[0274] In this way, the difference in version numbers reflects the degree of version upgrade. The larger the difference in version numbers, the higher the degree of version upgrade, and the less compatible the first hot function set is with the m-th version. The smaller the difference in version numbers, the lower the degree of version upgrade, and the more compatible the first hot function set is with the m-th version. This method is simple to implement.

[0275] In another example, if the number of hot functions in the first hot function set that fail in version m is less than the number threshold, it can be said that the fit between the first hot function set and version m is greater than the first threshold.

[0276] If the number of failed hotspot functions is greater than or equal to a threshold, it indicates that the first set of hotspot functions has a low compatibility with the m-th version. If the number of failed hotspot functions is less than the threshold, it indicates that the first set of hotspot functions has a high compatibility with the m-th version.

[0277] The quantity threshold can be positively correlated with the number of hot functions in the first hot function set. For example, if the number of hot functions in the first hot function set is 100, the quantity threshold can be 10. If the number of hot functions in the first hot function set is 500, the quantity threshold can be 30.

[0278] In this way, by counting the number of failed hot functions, the fit between the first set of hot functions and the m-th version can be reflected. Compared with the difference in version number, the fit can be fed back, which helps to improve the accuracy of calculation.

[0279] In another example, the failure rate of hot functions in the first hot function set in version m is less than the failure threshold, which indicates that the fit between the first hot function set and version m is greater than the first threshold.

[0280] If the failure rate of the hotspot functions is greater than or equal to the failure threshold, it indicates that the first set of hotspot functions has a low compatibility with the m-th version. If the failure rate of the hotspot functions is less than the failure threshold, it indicates that the first set of hotspot functions has a high compatibility with the m-th version.

[0281] In this way, reflecting the fit between the first set of hot functions and the m-th version by statistically analyzing the failure rate of hot functions is more conducive to improving the accuracy of calculation than simply counting the number of failures.

[0282] Optionally, the method further includes: at a seventh moment, the electronic device runs the first application of version m, the operating system of the electronic device is the operating system of version j, and the first application is associated with a first hotspot function set; at an eighth moment, the electronic device updates the first hotspot function set based on the running of the first application to obtain a third hotspot function set, the eighth moment being later than the seventh moment; at a ninth moment, the electronic device determines to upgrade to the operating system of version k, in the operating system of version k, the version of the first application is version m, the ninth moment being later than the eighth moment; at a tenth moment, the electronic device receives information from the operating system of version k, the information of the operating system of version k includes the first hotspot function set, the tenth moment being later than the ninth moment; at an eleventh moment, the electronic device restarts to upgrade to the operating system of version k, the eleventh moment being later than the tenth moment; at a twelfth moment, the electronic device completes the restart, merges the first hotspot function set and the third hotspot function set to obtain a fourth hotspot function set, and compiles based on the file associated with the fourth hotspot function set used to guide compilation optimization, thereby running the first application, the twelfth moment being later than the eleventh moment.

[0283] When an electronic device upgrades from operating system version j to operating system version k, it will reboot. Since the operating system upgrade does not upgrade the version of the first application (which remains version m), the third hotspot function set from before the upgrade will not become invalid. The electronic device can retain the third hotspot function set. When the electronic device upgrades to operating system version k, the information in operating system version k includes the first hotspot function set. Therefore, the electronic device can merge the first and third hotspot function sets to obtain a fourth hotspot function set and compile based on the files associated with the fourth hotspot function set that guide compilation optimization.

[0284] This method can be referred to above. Figure 5 S501 to S507 are shown, and will not be described again here.

[0285] In this way, since the first application version has not been upgraded, there are two hot function sets, namely the first hot function set and the third hot function set. Electronic devices can merge the first hot function set and the third hot function set to obtain a more comprehensive hot function set, which is beneficial to improving the performance of the application.

[0286] Optionally, the target file is obtained by compiling the file associated with the first hotspot function set to guide compilation optimization; the method also includes: the electronic device locking the target file in memory.

[0287] This method can be referred to above. Figure 5 The S509 and S510 are not discussed in detail here.

[0288] Electronic devices can lock target files using memory locking mechanisms to prevent related data from being swapped out of memory when the first application is running in the background. This helps reduce system application stuttering or frame drops and can improve application performance.

[0289] This application also provides a processing method for an application, which can be applied to a processing device. The method may include: the processing device acquiring a first file associated with a first application of version n, the first file being used to guide compilation optimization, and the first file including a first set of hot-spot functions; the processing device converting the first file into a second file, the second file being readable and not used to guide compilation optimization, the second file including the first set of hot-spot functions; when the first application upgrades from version n to version m, the processing device determining whether the compatibility between the first set of hot-spot functions and version m is greater than a first threshold; if the compatibility between the first set of hot-spot functions and version m is greater than the first threshold, the processing device converting the second file into a third file, the third file being used to guide compilation optimization, the third file including the first set of hot-spot functions; and the processing device associating version m with the third file.

[0290] The first file is used to guide compilation optimization, and the first set of hot functions is bound to version n of the first application. The processing device converts the first file into a second file, which is readable and not used to guide compilation optimization. This is equivalent to unbinding the first set of hot functions from version n of the first application, allowing the first set of hot functions to be bound to any subsequent version of the first application.

[0291] If the compatibility between the first hotspot function set and the m-th version is greater than the first threshold, the processing device can convert the second file into a third file and associate the third file with the m-th version, thus binding the first hotspot function set with the m-th version.

[0292] The processing equipment can be referenced from the above. Figure 6 For server 622, the method can refer to the steps performed on server 622 described above. It will not be repeated here.

[0293] The processing device can also be an electronic device. When the processing device is an electronic device, it can obtain the first file associated with the first application of version n from a server or other device, execute the above process, and associate version m with the third file. When the operating system is updated, it can be compiled based on the third file to upgrade the first application to version m.

[0294] In this way, the first application of different versions can correspond to the same set of hot functions, eliminating the need to collect a set of hot functions for each version, reducing the time spent collecting hot functions, and simplifying the implementation.

[0295] Optionally, the fit between the first hotspot function set and version m is greater than a first threshold under at least one of the following conditions: the difference between the version number of version m and the version number of version n is less than the difference threshold; the number of hotspot functions in the first hotspot function set that fail in version m is greater than the number threshold; or, the failure rate of hotspot functions in the first hotspot function set in version m is greater than the failure threshold.

[0296] It should be noted that the module names involved in the embodiments of this application can all be defined as other names, as long as they can achieve the function of each module, and no specific restrictions are placed on the module names.

[0297] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0298] The processing method for the application of the embodiments of this application has been described above. The apparatus for executing the above method provided in the embodiments of this application is described below. Those skilled in the art will understand that the methods and apparatus can be combined and referenced with each other, and the related apparatus provided in the embodiments of this application can execute the steps in the above list sorting method.

[0299] Figure 9 This is a schematic diagram of a chip structure provided in an embodiment of this application. Figure 9 As shown, chip 90 includes one or more processors 901, communication lines 902, communication interfaces 903, and memory 904.

[0300] In some implementations, memory 904 stores elements such as executable modules or data structures, or subsets thereof, or extended sets thereof.

[0301] The processing methods described in the embodiments of this application can be applied to or implemented by the processor 901. The processor 901 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the processing method described above can be completed by integrated logic circuits in the hardware of the processor 901 or by instructions in software form. The processor 901 described above can be a general-purpose processor (e.g., a microprocessor or conventional processor), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates, transistor logic devices, or discrete hardware components. The processor 901 can implement or execute the processing-related methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0302] The processing steps of the application disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in mature storage media in the art, such as random access memory, read-only memory, programmable read-only memory, or electrically erasable programmable read-only memory (EEPROM). This storage medium is located in memory 904, and processor 901 reads the information in memory 904 and, in conjunction with its hardware, completes the steps of the above method.

[0303] The processor 901, memory 904 and communication interface 903 can communicate with each other via communication line 902.

[0304] In the above embodiments, the instructions stored in the memory for execution by the processor can be implemented in the form of a computer program product. This computer program product can be pre-written into the memory, or it can be downloaded and installed into the memory as software.

[0305] The application processing method provided in this application embodiment can be applied to a processing device with an application installed. In one example, the processing device includes a terminal device, and the specific device form of the terminal device can be referred to the above-described related descriptions, which will not be repeated here. In another example, the processing device includes a server, and the server can be referred to the above-described... Figure 6 The server in the middle.

[0306] This application provides a processing device, which includes one or more processors and a memory; the memory is coupled to one or more processors, and the memory is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the processing device to perform the above-described method.

[0307] This application provides a chip. The chip or chip system is applied to a processing device and includes at least one or more processors. These processors invoke computer instructions to execute the technical solutions described in the above embodiments. Its implementation principle and technical effects are similar to the related embodiments described above, and will not be repeated here.

[0308] This application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program or instructions. When the computer program or instructions are executed by a processing device, they implement the methods described above. The methods described in the above embodiments can be implemented wholly or partially by software, hardware, firmware, or any combination thereof. If implemented in software, the functionality can be stored as one or more instructions or code on or transmitted over the computer-readable medium. The computer-readable medium can include computer storage media and communication media, and can also include any medium that can transfer a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0309] In one possible implementation, a computer-readable medium may include RAM, ROM, compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage or other magnetic storage devices, or any other medium targeted to carry or to store the required program code in the form of instructions or data structures, and accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disks and optical discs include optical discs, laser discs, optical discs, Digital Versatile Discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0310] This application provides a computer program product, which includes a computer program. When the computer program code is run on an electronic device, the electronic device performs the above-described method.

[0311] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0312] The above specific embodiments further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.< / pkgname>

Claims

1. A processing method for an application, characterized in that, Applied to electronic devices, including: At the first moment, the electronic device is running the nth version of the first application, the operating system of the electronic device is the ith version of the operating system, and the first application is associated with the first hotspot function set; At the second moment, the electronic device updates the first hotspot function set based on the operation of the first application to obtain the second hotspot function set, and the second moment is later than the first moment; At the third moment, the electronic device determines to upgrade to the j-th version of the operating system, in which the version of the first application is the m-th version, the m-th version is higher than the n-th version, and the third moment is later than the second moment; At the fourth moment, the electronic device receives information from the j-th version of the operating system, the information from the j-th version of the operating system including the first hotspot function set associated with the first application of the m-th version, and the fourth moment is later than the third moment; At the fifth moment, the electronic device restarts to upgrade to the j-th version of the operating system, the fifth moment being later than the fourth moment; At the sixth moment, the electronic device completes a restart. In response to the first application upgrading from version n to version m, the second hotspot function set is deleted, and compilation is performed based on the files associated with the first hotspot function set that guide compilation optimization, thereby upgrading the first application to version m. The sixth moment is later than the fifth moment.

2. The method according to claim 1, characterized in that, The first hotspot function set has a greater than a first threshold in its compatibility with the m-th version.

3. The method according to claim 2, characterized in that, The fit between the first hotspot function set and the m-th version is greater than a first threshold in at least one of the following cases: The difference between the version number of the m-th version and the version number of the n-th version is less than the difference threshold; The number of hot functions in the first set of hot functions that fail in the m-th version is less than a threshold; or, The failure rate of the hot functions in the first hot function set is less than the failure threshold in the m-th version.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: At the seventh moment, the electronic device is running the first application of the m-th version, the operating system of the electronic device is the operating system of the j-th version, and the first application is associated with the first hotspot function set; At the eighth moment, the electronic device updates the first hotspot function set based on the operation of the first application to obtain the third hotspot function set. The eighth moment is later than the seventh moment. At the ninth moment, the electronic device determines to upgrade to the k-th version of the operating system, in which the version of the first application is the m-th version, and the ninth moment is later than the eighth moment; At the tenth moment, the electronic device receives information from the k-th version of the operating system, the information from the k-th version of the operating system including the first hotspot function set, and the tenth moment is later than the ninth moment; At the eleventh moment, the electronic device restarts to upgrade to the k-th version of the operating system, the eleventh moment being later than the tenth moment; At the twelfth moment, the electronic device restarts, merges the first hotspot function set and the third hotspot function set to obtain the fourth hotspot function set, and compiles based on the files associated with the fourth hotspot function set that guide compilation optimization, thereby running the first application. The twelfth moment is later than the eleventh moment.

5. The method according to claim 4, characterized in that, The target file is obtained by compiling the file associated with the first hot function set to guide compilation optimization; The method further includes: The electronic device locks the target file in memory.

6. A processing method for an application, characterized in that, Applied to processing equipment, including: The processing device acquires a first file associated with the first application of version n, the first file being used to guide compilation optimization, the first file including a first set of hot functions; The processing device converts the first file into a second file, which is readable but not used to guide compilation optimization. The second file includes the first set of hot functions. When the first application is upgraded from version n to version m, the processing device determines whether the compatibility between the first hot function set and the version m is greater than a first threshold. If the compatibility between the first hot function set and the m-th version is greater than the first threshold, the processing device converts the second file into a third file, the third file being used to guide compilation optimization, and the third file including the first hot function set; The processing device associates the m-th version of the first application with the third file such that when upgrading to a j-th version of the operating system that includes the m-th version of the first application, the information of the j-th version of the operating system includes the first hotspot function set associated with the m-th version of the first application.

7. The method according to claim 6, characterized in that, The first hotspot function set has a greater fit with the m-th version than the first threshold in at least one of the following conditions: The difference between the version number of the m-th version and the version number of the n-th version is less than the difference threshold; The number of hot functions in the first hot function set that fail in the m-th version is greater than a threshold; or, The failure rate of the hot functions in the first hot function set is greater than the failure threshold in the m-th version.

8. A processing apparatus, characterized in that, The processing device includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, wherein the one or more processors invoke the computer instructions to cause the processing device to perform the method as claimed in any one of claims 1 to 5, or to perform the method as claimed in claim 6 or 7.

9. A chip system, characterized in that, The chip system is applied to a processing device, the chip system including one or more processors, the one or more processors being configured to invoke computer instructions to cause the processing device to perform the method as described in any one of claims 1 to 5, or to perform the method as described in claim 6 or 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions that, when executed on a processing device, cause the processing device to perform the method as claimed in any one of claims 1 to 5, or to perform the method as claimed in claim 6 or 7.

11. A computer program product, characterized in that, The computer program product includes computer program code that, when run on a processing device, causes the processing device to perform the method as claimed in any one of claims 1 to 5, or to perform the method as claimed in claim 6 or 7.

Images