Electronic device, method and non-transient computer-readable storage medium for application optimization

Abstract

An electronic device is provided in embodiments of the present disclosure. The electronic device may comprise: at least one processor including processing circuitry; and a memory including one or more storage media for storing instructions. When executed by the at least one processor, the instructions collectively or individually can instruct the electronic device to: perform a system update in response to booting of the electronic device; after the system update, identify, from the memory, a list of one or more apps on which an optimization operation is to be performed; monitor the state of the electronic device; and perform, on the basis of the result of monitoring the state of the electronic device, the optimization operation for each app according to priority information for the one or more apps. The optimization operation can include converting a byte code related to the corresponding app into an executable native code.

Description

Electronic device, method, and non-transient computer-readable storage medium for application optimization

[0001] The present disclosure relates to an electronic device, a method, and a non-transient computer-readable storage medium for application optimization.

[0002] An application can be installed on an electronic device. The code of the application, written in a programming language, can be converted to suit the platform supported by the electronic device. For example, the electronic device can perform optimization operations, including compilation, to convert bytecode into executable native code (e.g., machine code).

[0003] The information described above may be provided as related art for the purpose of aiding understanding of the present disclosure. No claim or determination is made as to whether any of the foregoing may be applied as prior art related to the present disclosure.

[0004] In embodiments of the present disclosure, an electronic device is provided. The electronic device may include at least one processor comprising a processing circuit; and a memory comprising one or more storage media for storing instructions. When executed by the at least one processor, the instructions may collectively or individually cause the electronic device to perform a system update in response to the booting of the electronic device, identify from the memory a list of one or more apps for which an optimization operation is to be performed after the system update, monitor the state of the electronic device, and, based on the result of monitoring the state of the electronic device, cause the optimization operation for each app according to priority information for the one or more apps. The optimization operation may include converting bytecode associated with the app into executable native code.

[0005] In embodiments of the present disclosure, a method is provided to be performed by an electronic device. The method may include performing a system update in response to the booting of the electronic device and, after the system update, identifying from memory a list of one or more apps for which an optimization operation is to be performed. The optimization operation may include converting bytecode associated with the app into executable native code. The method may include monitoring the state of the electronic device and, based on the result of monitoring the state of the electronic device, performing the optimization operation for each app according to priority information for the one or more apps.

[0006] In embodiments of the present disclosure, a non-transient computer-readable storage medium is provided. The non-transient computer-readable storage medium is configured to store instructions that cause an electronic device to perform functions collectively or individually when executed by at least one processor, said functions may include performing a system update in response to the booting of the electronic device, identifying from the memory a list of one or more apps for which an optimization operation is to be performed after the system update, said optimization operation including converting bytecode associated with said app into executable native code, said optimization operation including

[0007] In embodiments of the present disclosure, an electronic device is provided. The electronic device may include a communication circuit; at least one processor comprising a processing circuit; and a memory comprising one or more storage media for storing instructions. The instructions may, when executed by the at least one processor, collectively or individually, cause the electronic device to obtain information for a system update through the communication circuit, and after obtaining information for the system update, to identify the system update in response to the booting of the electronic device, to identify from the memory a list of one or more apps for which an optimization operation is to be performed in response to the system update, to monitor the state of the electronic device in response to the system update, and to perform the optimization operation for each app according to priority information for the one or more apps based on the result of monitoring the state of the electronic device. The optimization operation may include converting byte code associated with the app into executable native code.

[0008] In embodiments of the present disclosure, a method performed by an electronic device is provided. The method may include obtaining information for a system update, identifying the system update in response to booting the electronic device after obtaining the information for the system update, and identifying from memory a list of one or more apps for which an optimization operation is to be performed in response to the system update. The optimization operation may include converting bytecode associated with the app into executable native code. The method may include monitoring the state of the electronic device in response to the system update, and performing the optimization operation for each app according to priority information for the one or more apps based on the result of monitoring the state of the electronic device.

[0009] According to embodiments of the present disclosure, a non-transient computer-readable storage medium is provided. The non-transient computer-readable storage medium is configured to store instructions that cause an electronic device to perform functions collectively or individually when executed by at least one processor, said functions may include obtaining information for a system update; identifying said system update in response to booting of said electronic device after obtaining information for said system update; identifying from said memory a list of one or more apps for which an optimization operation is to be performed in response to said system update; —said optimization operation includes converting bytecode associated with said app into executable native code—; monitoring the state of said electronic device in response to said system update; and performing said optimization operation for each app according to priority information for said one or more apps based on the result of monitoring the state of said electronic device.

[0010] Figure 1 is a block diagram of an electronic device in a network environment.

[0011] Figure 2 shows an example of conversion of source code, bytecode, and native code.

[0012] Figures 3a, 3b, and 3c show examples of compilation methods.

[0013] Figure 4 shows examples of functional components of an electronic device.

[0014] Figure 5 shows an example of the operation between components of the system management process according to booting before the system update.

[0015] Figure 6 shows the operation of the components of the system management process following booting after a system update.

[0016] Figure 7 shows the operation flow of an electronic device to perform optimization operations in response to system updates according to priority.

[0017] FIG. 8 illustrates the operation flow of an electronic device for generating a list of one or more apps to which optimization operations are performed in response to a system update.

[0018] Figure 9 shows the operation flow of an electronic device for stopping or resuming optimization operations depending on the state of the electronic device.

[0019] The terms used in this disclosure are used merely to describe specific embodiments and are not intended to limit the scope of other embodiments. A singular expression may include a plural expression unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as generally understood by those skilled in the art described in this disclosure. Terms used in this disclosure that are defined in a general dictionary may be interpreted as having the same or similar meaning as they have in the context of the relevant technology, and are not to be interpreted in an ideal or overly formal sense unless explicitly defined in this disclosure. In some cases, even terms defined in this disclosure are not to be interpreted to exclude the embodiments of this disclosure.

[0020] In the various embodiments of the present disclosure described below, a hardware-based approach is described as an example. However, since the various embodiments of the present disclosure include techniques using both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0021] Terms used in the following description for the operational states of an electronic device (e.g., step, operation, procedure), terms referring to data (e.g., packet, user stream, information, bit, symbol, codeword), terms referring to units of functional components (e.g., module, process, function, operation, procedure, service), terms used to refer to usage frequency (e.g., activity frequency, number of executions, usage pattern, utilization, foreground duration, execution time, access frequency, number of accesses, access pattern, utilization), English terms for the states of an app (e.g., standby bucket, active standby bucket, workset standby bucket, exemption standby bucket), terms referring to network entities, terms referring to components of a device, terms referring to functional units within an operating system (OS) (e.g., unit, module, service, processor, receiver, listener), etc., are provided as examples for the convenience of explanation. Accordingly, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used. Additionally, terms such as '...part', '...device', '...piece', '...body' used below may refer to at least one shape structure or a unit that processes a function.

[0022] Additionally, in this disclosure, expressions of "greater than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled; however, this is merely for the purpose of expressing an example and does not exclude descriptions of "greater than" or "less than." Conditions described as "greater than" may be replaced with "greater than," conditions described as "less than" may be replaced with "less than," and conditions described as "greater than and less than" may be replaced with "greater than and less than." Furthermore, "A" to "B" below refer to at least one of elements from A (including A) to B (including B). Below, "C" and / or "D" refers to including at least one of "C" or "D," i.e., {"C", "D", "C" and "D"}.

[0023] Figure 1 is a block diagram of an electronic device in a network environment.

[0024] Referring to FIG. 1, in a network environment (100), an electronic device (101) may communicate with an electronic device (102) through a first network (198) (e.g., a short-range wireless communication network) or with at least one of an electronic device (104) or a server (108) through a second network (199) (e.g., a long-range wireless communication network). According to one embodiment, the electronic device (101) may communicate with the electronic device (104) through a server (108). According to one embodiment, the electronic device (101) may include a processor (120), memory (130), input module (150), sound output module (155), display module (160), audio module (170), sensor module (176), interface (177), connection terminal (178), haptic module (179), camera module (180), power management module (188), battery (189), communication module (190), subscriber identification module (196), or antenna module (197). In some embodiments, at least one of these components (e.g., connection terminal (178)) may be omitted from the electronic device (101), or one or more other components may be added. In some embodiments, some of these components (e.g., sensor module (176), camera module (180), or antenna module (197)) may be integrated into a single component (e.g., display module (160)).

[0025] The processor (120) can control at least one other component (e.g., hardware or software component) of the electronic device (101) connected to the processor (120) by executing software (e.g., program (140)), for example, and can perform various data processing or operations. According to one embodiment, as at least part of the data processing or operations, the processor (120) can store commands or data received from other components (e.g., sensor module (176) or communication module (190)) in volatile memory (132), process the commands or data stored in volatile memory (132), and store the resulting data in non-volatile memory (134). According to one embodiment, the processor (120) may include a main processor (121) (e.g., central processing unit or application processor) or an auxiliary processor (123) that can operate independently or together with it (e.g., graphics processing unit, neural processing unit (NPU), image signal processor, sensor hub processor, or communication processor). For example, if the electronic device (101) includes a main processor (121) and an auxiliary processor (123), the auxiliary processor (123) may be configured to use lower power than the main processor (121) or to be specialized for a designated function. The auxiliary processor (123) may be implemented separately from the main processor (121) or as part thereof.

[0026] The auxiliary processor (123) may control at least some of the functions or states associated with at least one component of the electronic device (101) (e.g., display module (160), sensor module (176), or communication module (190)) on behalf of the main processor (121) while the main processor (121) is in an inactive (e.g., sleep) state, or together with the main processor (121) while the main processor (121) is in an active (e.g., application execution) state. According to one embodiment, the auxiliary processor (123) (e.g., image signal processor or communication processor) may be implemented as part of another functionally related component (e.g., camera module (180) or communication module (190)). According to one embodiment, the auxiliary processor (123) (e.g., neural network processing unit) may include a hardware structure specialized for processing an artificial intelligence model. The artificial intelligence model may be generated through machine learning. Such learning may be performed, for example, on the electronic device (101) itself where the artificial intelligence model is executed, or through a separate server (e.g., server (108)). The learning algorithm may include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model may include a plurality of artificial neural network layers.An artificial neural network may be a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of the above, but is not limited to the examples described above. In addition to the hardware structure, the artificial intelligence model may include a software structure, either additionally or substantially.

[0027] The memory (130) can store various data used by at least one component of the electronic device (101) (e.g., processor (120) or sensor module (176)). The data may include, for example, software (e.g., program (140)) and input or output data for related commands. The memory (130) may include volatile memory (132) or non-volatile memory (134).

[0028] The program (140) may be stored as software in memory (130) and may include, for example, an operating system (142), middleware (144), or an application (146).

[0029] The input module (150) can receive commands or data to be used for a component of the electronic device (101) (e.g., processor (120)) from outside the electronic device (101) (e.g., user). The input module (150) may include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).

[0030] The sound output module (155) can output a sound signal to the outside of the electronic device (101). The sound output module (155) may include, for example, a speaker or a receiver. The speaker may be used for general purposes, such as multimedia playback or recording playback. The receiver may be used to receive incoming calls. According to one embodiment, the receiver may be implemented separately from the speaker or as part thereof.

[0031] The display module (160) can visually provide information to an external (e.g., user) of the electronic device (101). The display module (160) may include, for example, a display, a holographic device, or a projector and a control circuit for controlling said device. According to one embodiment, the display module (160) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of the force generated by said touch.

[0032] The audio module (170) can convert sound into an electrical signal or, conversely, convert an electrical signal into sound. According to one embodiment, the audio module (170) can acquire sound through the input module (150) or output sound through the sound output module (155) or an external electronic device (e.g., electronic device (102)) (e.g., speaker or headphones) connected directly or wirelessly to the electronic device (101).

[0033] The sensor module (176) can detect the operating state of the electronic device (101) (e.g., power or temperature) or the external environmental state (e.g., user state) and generate an electrical signal or data value corresponding to the detected state. According to one embodiment, the sensor module (176) may include, for example, a gesture sensor, a gyroscope sensor, a barometric pressure sensor, a magnetic sensor, an accelerometer sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biosensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0034] The interface (177) may support one or more specified protocols that can be used for the electronic device (101) to be connected directly or wirelessly to an external electronic device (e.g., electronic device (102)). According to one embodiment, the interface (177) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

[0035] The connection terminal (178) may include a connector through which the electronic device (101) can be physically connected to an external electronic device (e.g., electronic device (102)). According to one embodiment, the connection terminal (178) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0036] The haptic module (179) can convert an electrical signal into a mechanical stimulus (e.g., vibration or movement) or an electrical stimulus that can be perceived by the user through tactile or kinesthetic senses. According to one embodiment, the haptic module (179) may include, for example, a motor, a piezoelectric element, or an electric stimulation device.

[0037] The camera module (180) can capture still images and video. According to one embodiment, the camera module (180) may include one or more lenses, image sensors, image signal processors, or flashes.

[0038] The power management module (188) can manage power supplied to the electronic device (101). According to one embodiment, the power management module (188) can be implemented, for example, as at least part of a power management integrated circuit (PMIC).

[0039] The battery (189) can supply power to at least one component of the electronic device (101). According to one embodiment, the battery (189) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0040] The communication module (190) can support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between an electronic device (101) and an external electronic device (e.g., electronic device (102), electronic device (104), or server (108)), and the performance of communication through the established communication channel. The communication module (190) may include one or more communication processors that operate independently of the processor (120) (e.g., application processor) and support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module (190) may include a wireless communication module (192) (e.g., cellular communication module, short-range wireless communication module, or GNSS (global navigation satellite system) communication module) or a wired communication module (194) (e.g., LAN (local area network) communication module, or power line communication module). The corresponding communication module among these communication modules can communicate with an external electronic device (104) through a first network (198) (e.g., a short-range communication network such as Bluetooth, WiFi (wireless fidelity) direct, or IrDA (infrared data association)) or a second network (199) (e.g., a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN). These various types of communication modules may be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module (192) can identify or authenticate the electronic device (101) within a communication network such as the first network (198) or the second network (199) using subscriber information (e.g., International Mobile Subscriber Identifier (IMSI)) stored in the subscriber identification module (196).

[0041] The wireless communication module (192) can support 5G networks and next-generation communication technologies following 4G networks, for example, new radio access technology. NR access technology can support high-speed transmission of high-capacity data (enhanced mobile broadband (eMBB)), minimization of terminal power and connection of multiple terminals (massive machine type communications (mMTC)), or high reliability and low latency (ultra-reliable and low-latency communications (URLLC)). The wireless communication module (192) can support a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate, for example. The wireless communication module (192) can support various technologies for securing performance in the high-frequency band, such as beamforming, massive MIMO (multiple-input and multiple-output), full-dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large-scale antenna. The wireless communication module (192) can support various requirements specified in the electronic device (101), external electronic device (e.g., electronic device (104)), or network system (e.g., second network (199)). According to one embodiment, the wireless communication module (192) may support a Peak data rate (e.g., 20 Gbps or more) for eMBB realization, loss coverage (e.g., 164 dB or less) for mMTC realization, or U-plane latency (e.g., downlink (DL) and uplink (UL) each 0.5 ms or less, or round trip 1 ms or less) for URLLC realization.

[0042] An antenna module (197) can transmit a signal or power to or from an external source (e.g., an external electronic device). According to one embodiment, the antenna module (197) may include an antenna comprising a radiator made of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). According to one embodiment, the antenna module (197) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as a first network (198) or a second network (199), may be selected from the plurality of antennas, for example, by a communication module (190). A signal or power may be transmitted or received between the communication module (190) and an external electronic device through the selected at least one antenna. According to some embodiments, in addition to the radiator, other components (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as part of the antenna module (197).

[0043] According to various embodiments, the antenna module (197) may form a mmWave antenna module. According to one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent to a first surface (e.g., bottom surface) of the printed circuit board and capable of supporting a specified high frequency band (e.g., mmWave band), and a plurality of antennas (e.g., array antennas) disposed on or adjacent to a second surface (e.g., top surface or side surface) of the printed circuit board and capable of transmitting or receiving a signal of the specified high frequency band.

[0044] At least some of the above components can be connected to each other via a communication method between peripheral devices (e.g., bus, GPIO (general purpose input and output), SPI (serial peripheral interface), or MIPI (mobile industry processor interface)) and exchange signals (e.g., commands or data) with each other.

[0045] According to one embodiment, commands or data may be transmitted or received between the electronic device (101) and an external electronic device (104) through a server (108) connected to a second network (199). Each of the external electronic devices (102, or 104) may be the same or a different type of device as the electronic device (101). According to one embodiment, all or part of the operations performed on the electronic device (101) may be performed on one or more of the external electronic devices (102, 104, or 108). For example, if the electronic device (101) needs to perform a function or service automatically or in response to a request from a user or another device, the electronic device (101) may request one or more external electronic devices to perform at least part of the function or service instead of performing the function or service itself or additionally. One or more external electronic devices that receive the above request may execute at least part of the requested function or service, or additional function or service related to the request, and transmit the result of the execution to the electronic device (101). The electronic device (101) may provide the result as is or additionally processed as at least part of the response to the request. For this purpose, for example, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used. The electronic device (101) may provide ultra-low latency services using, for example, distributed computing or mobile edge computing. In another embodiment, the external electronic device (104) may include an Internet of Things (IoT) device. The server (108) may be an intelligent server using machine learning and / or neural networks. According to one embodiment, the external electronic device (104) or the server (108) may be included within a second network (199).The electronic device (101) can be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

[0046] Figure 2 shows an example of conversion of source code, bytecode, and native code.

[0047] Referring to FIG. 2, source code (210) represents code written by a developer in a programming language (e.g., Java, Kotlin). Source code (210) can be used to implement the functions of an application. Source code (210) can be converted into bytecode (220) by a compiler. The bytecode (220) may be in a format executable on a JVM (Java Virtual Machine), DVM (Dalvik Virtual Machine), and / or ART (Android Runtime). For example, in an Android environment, source code (210) can be converted into bytecode stored as a class (e.g., '.class') file through compilation. Subsequently, the bytecode stored as a class (e.g., '.class') file can be converted into a dex (Dalvik executable) file. A dex file represents the bytecode stored as a '.class') file that has been converted to be executable in a runtime environment. A dex file is also a type of bytecode (220) and can be referenced as bytecode in Dalvik or ART. Hereinafter, bytecode (220) represents the bytecode of a dex file.

[0048] An electronic device (101) may provide a runtime environment to execute an application. A runtime environment is one that provides resources and an environment for an application to be executed. In the runtime environment, the electronic device (101) may interpret bytecode (220) or convert it into native code (230) for execution. For example, the electronic device (101) may convert a dex file included in an APK (Android Package Kit) into native code (230) that can be executed on a CPU (e.g., processor (120)). Since the dex file is not machine code, it can be compiled. For example, the electronic device (101) may perform ahead-of-time (AOT) compilation to convert the bytecode (220) of the dex file into native code (230) in a runtime environment (e.g., ART (android runtime)). Through the AOT compilation, an optimized executable file (e.g., oat (optimized android executable) file) may be obtained. Hereinafter, through FIGS. 3a, 3b, and 3c, compilation methods, JIT (just-in-time) methods, AOT (ahead of time) methods, and / or hybrid methods are described.

[0049] Figures 3a, 3b, and 3c show examples of compilation methods.

[0050] Referring to FIG. 3a, the APK (310) may provide an executable file (e.g., a dex file (320)). Through a runtime environment (e.g., Dalvik), the dex file (320) may be converted into machine code (337). According to a just-in-time (JIT) method, the bytecode (220) of the dex file (320) may be converted into native code (230). For example, the dex file (320) may be provided to the runtime environment. The dex file (320) may be optimized through an executable file optimization process (e.g., dexopt (331)) of the runtime environment (e.g., Dalvik). The optimization may include generating an optimized dex file (333) in an execution-ready state to improve the execution speed and memory usage of the application. The odex file (333) may be a file in which the dex file (320) has been converted into a form suitable for execution on a DVM (Dalvik virtual machine) (335). After runtime, the DVM (335) may read the bytecode contained in the odex file (333) at an appropriate time and compile the parts of the bytecode that are necessary for execution into machine code (337) (e.g., native code (230)) that can be executed on a CPU (e.g., processor (120)).

[0051] The JIT method performs compilation at an appropriate time. It operates as an interpreter that converts bytecode (220) into machine code (337) for a loaded class, and when it detects repeated execution of a method of the loaded class, the JIT compiler can operate. The JIT compiler compiles the bytecode into machine code (337) and stores it, and when the class of the app is loaded next, it can read the stored file to improve execution speed. According to the JIT method, the time to execute the machine code (337) generated by compilation is relatively fast, and since memory caching is performed by default, performance can be maximized during repeated calls. Since compilation occurs during runtime, the time required for package installation may be short. However, overhead in resource usage due to JIT operation may occur during the use of the electronic device (101). Also, since re-conversion is required when repeated execution is detected after the cached memory has been released, there may be a slight delay in the application's operation and the time consumed for JIT compilation may be long.

[0052] Referring to FIG. 3b, the APK (310) may provide an executable file (e.g., a dex file (320)). Through a runtime environment (e.g., ART (android runtime)), the dex file (320) may be converted into machine code (e.g., native code (230)). According to an ahead of time (AOT) method, the bytecode (220) of the dex file may be converted into native code (230). At the time the application is installed or at the time of booting the operating system (OS), the dex file (320) may be converted into native code executable by the CPU (e.g., processor (120)) and stored. Subsequently, when the application is executed, the converted code is read. For example, the dex file (320) may be converted into an optimized executable file (e.g., an oat file (343)) through an executable file optimization process (e.g., dex2oat (341)) of the runtime environment (e.g., ART). For example, dex2oat (341) can correspond to an AOT compiler used in Android. In the above runtime environment (e.g., ART), as an executable file (e.g., dex file (320)) is converted into an optimized executable file (e.g., oat file (343)) (e.g., dex file (320) is converted into an odex file (dex transform to odex) and odex file is converted into an oat file (odex transform to oat)), the execution performance of the application can be improved. Since the code is already converted into native code (i.e., machine code) at the time of application installation, the execution speed can be improved by using the converted code immediately rather than converting the code by an interpreter at the time of the first execution of the application, thereby reducing the time required for the first execution of the application. However, a significant amount of compilation time is required when installing the application, and a considerably large amount of storage space may be required to store the compiled output.For example, when an application is executed, the ART runtime (345) may directly execute an oat file (343) corresponding to the native code (230) instead of reading the dex file (320). The oat file (343) may be obtained based on the optimization operation for the dex file (320). When an application is executed, the native code may be executed directly without JIT compilation. The JIT compilation method of FIG. 3a converts only the necessary parts into machine code at runtime. On the other hand, in the AOT compilation method of FIG. 3b, all code may be converted into machine code in advance when the application is installed.

[0053] Referring to FIG. 3c, a hybrid method combining the two compilation methods can be used to take advantage of both the JIT compilation method of FIG. 3a and the AOT compilation method of FIG. 3b. An executable file (e.g., dex file (361)) and an optimized executable file (e.g., oat file (362)) may be used. Hot code (code that is frequently executed) among the code of the executable file (e.g., dex file (361)) can be processed by the JIT compiler (381a) in the ART (371). The JIT compiler (381a) converts bytecode into native code during execution, so that performance can be optimized during subsequent repeated executions. When using the JIT compiler (381a), the optimization effect can increase as the operation of the app is repeated. The ART (371) stores the data of the JIT compiler (381a) and uses it during subsequent AOT compilation to generate more efficient native code. An optimized executable file (e.g., oat file (362)) represents a binary file compiled through an AOT compiler. When an app is installed, the optimized executable file is generated through an executable file optimization process (e.g., dex2oat) and may correspond to a native code version of an executable file (e.g., dex file (361)). The ART (372) can load and execute the optimized executable file (e.g., oat file (362)) immediately. When executing, a separate JIT compiler (381a) or interpreter (381b) is not required. If the executable file (e.g., dex file (361)) is cold code (infrequently executed code) that has not been converted through AOT compilation, the ART (371) may use an interpreter (381b). The interpreter (381b) reads and interprets the bytecode of the executable file (e.g., dex file (361)) line by line and can execute it immediately without converting it into native code. Since cold code is not executed frequently, processing it through the interpreter (381b) may not have a significant impact on performance.This allows the load of the JIT compiler (381a) or AOT conversion to be reduced.

[0054] When the app is executed, the ART (e.g., ART (371), ART (372)) can be processed differently depending on the input file (e.g., dex file (361), oat file (362)). If the oat file (362) exists, the ART can execute the oat file (362) immediately. Meanwhile, if only the dex file (361) exists, the ART can use a JIT compiler (381a) or an interpreter (381b) depending on usage frequency. The ART can maximize execution performance and process infrequently used code while saving resources. For example, depending on the pattern used when the bytecode is executed by the interpreter (381b), a profile of frequently used method information in a class of a user-based package can be stored in the memory (e.g., non-volatile memory (134)) of the electronic device (101). In order to utilize the above profile, it is required that the package be optimized to compile into machine code (e.g., native code (230)) using the stored profile at an appropriate time. The optimization may be performed by an AOT background service module (e.g., BackgroundDexOptService, bg-dexopt). The service daemon of the AOT background service module may be executed based on a job scheduler. The AOT background service module may generate an oat file (362) and / or odex file (containing the compiled code) that is compiled into native code (230) in the background. For example, the AOT background service module may generate native code based on a profile containing information about frequently used methods (e.g., functions included in classes, structures, enumerations) for all applications (e.g., packages, apks) mounted on the electronic device (101) in the background. When a compiled method is executed while the application is running, ART (372) can use the compiled code directly without an interpreter (381b).When the application is executed, the execution time can be shortened as the executable code is loaded directly from the file into memory (e.g., volatile memory (132)) for use.

[0055] A Job Scheduler can be used by developers to define background tasks and determine the timing for when these tasks will execute. Through the Job Scheduler, power consumption can be reduced because the device is activated only when necessary. The Android framework may include a Job Scheduler that controls scheduling and a Job Service that defines tasks. Information regarding the conditions under which a task should be executed can be defined in JobInfo. The content to be performed when executing a scheduled task can be defined in the JobService. When JobInfo is passed to the Job Scheduler, the Job Scheduler can execute the corresponding Job Service at the time defined in the JobInfo. When executing a scheduled task, the Job Scheduler can call the onStartJob function defined in the JobService. The Job Scheduler can call the onStopJob function if it deviates from the constraints defined in the JobInfo, that is, if the task needs to be stopped. When a scheduled task is completed or aborted, the Job Scheduler calls the JobFinished function to notify the Job Scheduler that the task has finished. As an example, if a scheduled task is aborted, the job scheduler may be rescheduled based on the reason for the abort. For example, the AOT background service module may be executed when constraints are met (e.g., idle state (e.g., maintaining a screen-off state for approximately 31 minutes without user intervention) and charging). For example, the AOT background service module may be executed periodically.

[0056] The electronic device (101) can be updated. System components of the operating system (e.g., Android) of the electronic device (101) are modularized, and at least some of the system components can be updated. At least some of the modularized system components can be updated not only through system updates of the operating system but also through external paths (e.g., App Store, Google Play (Play Store)). For example, the modularized system components of the system (e.g., mainline module) can be updated via OTA (over-the-air). However, when the modularized components are updated, it is highly likely that the BootClassPath (BCP) referenced by the application package will change. A change in the BCP prevents the electronic device (101) from using files compiled with the existing native code (230) (e.g., oat files, odex files). In other words, the output of the optimization operation may be difficult to reuse. In addition to regular system updates (system upgrade files provided by the vendor of the electronic device (101) (e.g., operating system version upgrade via OTA)), as modularized system components (e.g., mainline modules) are updated through various paths, the output of the optimization operation of the package (application) stored in the electronic device (101) may be invalidated. As a result, the user's perceived performance of the electronic device (101) may be degraded. When certain conditions (e.g., charging, idle state) are met, a method of performing optimization using an existing profile may be considered; however, depending on the user's usage pattern, if the above conditions are not met, a situation may occur where the unoptimized package is used continuously. Furthermore, the optimization operation may be interrupted or delayed due to various conditions such as battery level or heat generation. It is highly likely that the BCP will change after a system update, and the changed BCP will make it impossible to use the optimized ART output file.

[0057] An electronic device (101) according to embodiments of the present disclosure may perform optimization operations on one or more apps in a predefined list in response to system updates (e.g., manufacturer updates, updates for modularized system components (e.g., mainline modules), and OTA methods) to improve user experience. In the present disclosure, an optimization operation refers to a task performed in advance (or dynamically) to increase performance or reduce memory usage when a dex file included in an app is executed. For example, the optimization operation may include converting an executable file (e.g., a dex file (320)) into an optimized executable file (e.g., an oat file) corresponding to native code (230). For example, the optimization operation may include dynamically converting frequently used code (e.g., hot spot code, hot code) into native code (230).

[0058] FIG. 4 shows examples of functional components of an electronic device (e.g., electronic device (101)).

[0059] Referring to FIG. 4, the electronic device (101) may include a processor (120), a communication circuit (410), and a memory (130). The memory (130) may include a volatile memory (132) and a non-volatile memory (134). The processor (120), the volatile memory (132), the non-volatile memory (134), and the communication circuit (410) may be electrically and / or operably coupled with each other by an electronic component such as a communication bus. Hereinafter, the hardware being operably coupled may mean that a direct connection or an indirect connection between the hardware is established by wire or wirelessly so that a second hardware is controlled by a first hardware among the hardware. Although illustrated based on different blocks, the embodiment is not limited thereto, and some of the hardware components of FIG. 1 (e.g., processor (120), volatile memory (132), and at least some of the communication circuit (410)) may be included in a single integrated circuit, such as a system on a chip (SoC). The type and / or number of hardware components included in the electronic device (101) are not limited to those shown in FIG. 4. For example, the electronic device (101) may include only some of the hardware components shown in FIG. 4.

[0060] The processor (120) of the electronic device (101) may include a hardware component for processing data based on one or more instructions. The hardware component for processing data may include, for example, an arithmetic and logic unit (ALU), a floating point unit (FPU), a field programmable gate array (FPGA), a central processing unit (CPU), and / or an application processor (AP). The number of processors (120) may be one or more. For example, the processor (120) may have the structure of a multi-core processor such as a dual core, a quad core, or a hexa core.

[0061] Volatile memory (132) and / or non-volatile memory (134) of the electronic device (101) may include hardware components for storing data and / or instructions that are input and / or output to the processor (120). Volatile memory (132) may be referred to, for example, as random-access memory (RAM). Volatile memory (132) may include at least one of, for example, dynamic RAM (DRAM), static RAM (SRAM), cache RAM, and pseudo SRAM (PSRAM). Non-volatile memory (134) may be referred to as read-only memory (ROM). Non-volatile memory (134) may include, for example, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), flash memory, hard disk, compact disk, solid state drive (SSD), and embedded multi-media card (eMMC). Each of the volatile memory (132) and non-volatile memory (134) of FIG. 1 may include the volatile memory (132) and non-volatile memory (134) of FIG. 1.

[0062] The communication circuit (410) of the electronic device (101) may include hardware for supporting the transmission and / or reception of electrical signals between the electronic device (101) and an external electronic device. The communication circuit (410) may include, for example, at least one of a modem, an antenna, and an optic / electronic converter. The communication circuit (410) may support the transmission and / or reception of electrical signals based on various types of protocols such as Ethernet, a local area network (LAN), a wide area network (WAN), wireless fidelity (WiFi), Bluetooth, Bluetooth low energy (BLE), ZigBee, LTE (long term evolution), and 5G NR (new radio). The communication circuit (410) of FIG. 4 may include the communication module (190), the subscriber identification module (196), and / or the antenna module (197) of FIG. 1.

[0063] One or more instructions (or commands) representing operations (e.g., arithmetic operations, and / or logical operations) and / or actions (e.g., data transfer, conditional execution, and / or interrupt control) to be performed on data by the processor (120) may be stored in the volatile memory (132) and / or non-volatile memory (134). Instructions stored in the memory (e.g., memory (130) of FIG. 1) of the electronic device (101) including the volatile memory (132) and / or non-volatile memory (134) may be distinguished by whether they are readable by the processor (120). Hereinafter, the types of instructions may be classified into a first type and a second type depending on whether they are directly readable by the processor (120). For example, the first type of instructions may include instructions that are directly readable by the processor (120). For example, the first type of instruction may be referenced as native code (230). For example, the second type of instruction may include an instruction different from the first type of instruction that is directly readable by the processor (120). The second type of instruction may be referenced as bytecode (e.g., Java bytecode, bytecode (220)).

[0064] A set of one or more instructions may be stored in volatile memory (132) and / or non-volatile memory (134). The set of one or more instructions may be referred to as firmware, an operating system, a process, an instance, a daemon, a routine, a sub-routine, and / or an application. The set of instructions referred to as an application may include the first type of instructions and / or the second type of instructions. A package file (440) stored in non-volatile memory (134) may include a set of instructions corresponding to a specific application and data required for the execution of the set of instructions. The data may include an icon representing the specific application, metadata indicating the permissions of the specific application (e.g., manifest.xml), images included in the screen of the specific application, and / or videos. The package file (440) may have an extension (e.g., pkg and / or apk) designated by an operating system (e.g., the operating system (142) of FIG. 1) executed by the processor (120) of the electronic device (101). Hereinafter, the fact that an application is installed on the electronic device (101) may indicate that a package file (440) containing a set of instructions related to said application is stored in the non-volatile memory (134) of the electronic device (101).

[0065] The processor (120) of the electronic device (101) may execute a process (e.g., a system management process (420), a runtime management process (430)) for executing instructions stored in non-volatile memory (134) (e.g., instructions contained in a package file (440)). According to one embodiment, the system management process (420) (e.g., a system server) represents a process that starts at boot to manage the entire operating system and ensures that functions (e.g., apps and / or services) operate reliably. For example, the system management process (420) may include a package manager service for managing the installation, update, deletion, and metadata of app packages, and a usage stats service for recording and / or managing app and device usage data. For example, the system management process (420) may include a profile utilization service for determining at boot whether optimization of packages is necessary and for managing a list of apps to be optimized. According to one embodiment, a runtime management process (430) (e.g., ART Manager service) may be used to provide a runtime environment for running an app. For example, the runtime management process (430) may include an executable file optimization process (e.g., dexopt (331)) and / or dex2oat (e.g., dex2oat (341)) as a tool for optimization operations. Hereinafter, a process (or instance, thread) may mean a unit of one or more operations and / or tasks performed by a processor (120) of an electronic device (101). For example, an operating system executed by the processor (120) may determine or control the order of instructions executed sequentially by the processor (120) on a process-by-process basis.The operation of executing (or launching) a process may include at least one of the following: forming at least one region for executing the process within volatile memory (132); loading one or more instructions associated with the process (e.g., instructions of the first type or the second type) into the at least one region; or assigning an identifier (e.g., process ID, instance ID, and / or thread ID) to the process.

[0066] In the following, executing an application may include the operation of creating and executing an application process corresponding to a package file (440) associated with the application. In one embodiment in which the package file (440) includes first type instructions readable by the processor (120) and second type instructions different from the first type, the first type instructions and the second type instructions may be stored in volatile memory (132) based on the creation of the application process. The processor (120) may execute a runtime environment (e.g., Java Virtual Machine (JVM), Davlik, ART) to execute the second type instructions.

[0067] An electronic device (101) according to embodiments of the present disclosure may generate a list of one or more apps to be optimized in response to a system update (hereinafter, an optimized app list (450)). According to one embodiment, the optimized app list (450) may include a name and a weight value for each app. As an example not limited to, the name and weight values ​​may be stored in a data format common to clients (e.g., JSON (JavaScript Object Notation) file). The weight values ​​may be used to determine the priority of the corresponding app over other apps in the optimized app list (450). An electronic device (101) according to embodiments of the present disclosure may perform an optimization operation. The optimization operation refers to a task performed in advance (or dynamically) to increase performance or reduce memory usage when an application's executable file (e.g., dex file) is executed. For example, the optimization operation may include converting the executable file into an optimized executable file (e.g., oat file) corresponding to native code. For example, it may include dynamically converting frequently used code (e.g., hotspot code) into native code. According to one embodiment, the optimization operation may be performed in response to a system update. The electronic device (101) may compile at least one of the second type of instructions included in the package file (440). The device (101) may use a compiler to perform compilation for a second type of instruction. While the optimization operation is in progress, the processor (120) may selectively compile at least one of the second type of instructions included in the package file (440) corresponding to the package file (440).The processor (120) that executes the optimization operation may include, as the optimization operation, an executable file optimization process (e.g., 'dexopt', 'dex2oat'), and / or a system process having a name such as 'BackgroundDexOptService'. In the following, the optimization of the package file (440) may include an operation to generate an optimized file (460) based on the execution of the optimization operation, and / or an operation to save the optimized file (460).

[0068] FIG. 5 illustrates an example of the operation between components of a system management process (e.g., system management process (420)) prior to a system update during booting. An electronic device (101) according to embodiments of the present disclosure may generate a list of frequently used packages and perform optimization operations on one or more apps in the list in response to a system update (e.g., regular system updates (system upgrade files provided by the vendor (e.g., operating system version upgrades via OTA)) as well as updates to modularized system components (e.g., mainline). The electronic device (101) may monitor the state of the electronic device (101) so that the user does not perceive a performance degradation caused by the optimization operation, and may stop or resume the optimization operation based on the monitoring results. FIG. 5 illustrates the operation between components prior to a system update.

[0069] Referring to FIG. 5, the system server (510) represents a process for controlling the main functions of the device by managing various system services within the operating system of the electronic device (101) and supporting communication between services. The system server (510) can correspond to the system management process (420) of FIG. 4.

[0070] When the electronic device (101) boots up, the system server (510) may start. As the system server (510) starts, the profile utilization service (511), package manager service (512), and usage statistics service (513) may be executed. The profile utilization service (511) may include various components for optimization operations. According to one embodiment, the profile utilization service (511) may be configured to check whether an optimization operation has been initiated. According to one embodiment, the profile utilization service (511) may generate and manage a list of apps to be optimized in response to a system update. According to one embodiment, the profile utilization service (511) may monitor the status of the device. The package manager service (512) may be used to manage information about applications and packages installed on an operating system (e.g., Android). For example, the package manager service (512) may be used to manage the installation, update, deletion, and metadata of app packages. The usage statistics service (513) may be used to record and / or manage app and device usage data. For example, the usage statistics service (513) may be used to track the usage frequency, usage time, last usage time, etc. of a specific app.

[0071] The electronic device (101) may use a profile utilization service (511) to manage optimization operations. In operation (S510), the electronic device (101) may identify a boot. In operation (S520), the electronic device (101) may start the profile utilization service (511) upon booting. The electronic device (101) may determine whether optimization operations are necessary for a package. For example, the electronic device (101) may determine whether a system update has been performed. For example, the electronic device (101) may determine whether the electronic device (101) is booting for the first time, whether a system update has been performed, and / or whether updates to modularized system components (e.g., mainline) have been performed. For example, the electronic device (101) may determine whether the free space of storage space for optimization operations is above a threshold. In FIG. 5, it is assumed that there is no separate update.

[0072] In operation (S530), the electronic device (101) may register a receiver / listener. For example, the electronic device (101) may register a broadcast receiver (e.g., BroadcastReceiver) to detect a user's shutdown action. As an example, in operation (S531), the profile utilization service (511) of the electronic device (101) may subscribe to a specific action. In operation (S532), when a user request or a system API (application programming interface) is called and a shutdown action of the electronic device (101) occurs, a shutdown messaging object (e.g., 'Intent.ACTION_SHUTDOWN') may be delivered to the profile utilization service (511). When the shutdown messaging object ('Intent.ACTION_SHUTDOWN') is delivered, the profile utilization service (511) may perform operation (S540). For reference, a messaging object (e.g., an Intent in the Android OS) represents a message object used to transmit or request data or operations between components. The aforementioned Intent is used to call Activities, Services, Broadcast Receivers, etc., or to transmit data, and the Action indicates the type of operation included in the Intent.

[0073] In operation (S540), the list generator of the profile utilization service (511) can generate an optimized app list (e.g., the optimized app list (450) of FIG. 4) based on information obtained from the package manager service (512) and / or the usage statistics service (513). The optimized app list (450) may include one or more apps to be optimized in response to a system update. For example, in operation (S541), the list generator of the profile utilization service (511) can transmit a control signal requesting information. In operation (S542), the list generator of the profile utilization service (511) can obtain app information and / or status information from the package manager service (512) and / or the usage statistics service (513). The list generator of the profile utilization service (511) can generate the optimized app list (450) based on the app information and / or status information. According to one embodiment, the optimized app list (450) may include a name and a weight value for each app. As an example, but not limited to, the name and weight value may be stored in a data format common to clients (e.g., a JSON (JavaScript Object Notation) file). The weight value may be used to determine the priority of the corresponding app over other apps in the optimized app list (450).

[0074] The optimized app list (450) may include various types of apps. According to one embodiment, the optimized app list (450) may include a first set of apps that can be executed by a user. The first set of apps may be launchable packages, representing packages that can be directly executed by the user from the home screen or app drawer (launcher). For example, the launchable packages may represent packages in which ACTION_MAIN and CATEGORY_LAUNCHER intents are defined in a Manifest file.

[0075] According to one embodiment, the optimization app list (450) may include a second set of apps having profiles on which optimization has been performed. Apps in a package that already have outputs according to optimization operations prior to the system update may be included in the optimization app list (450).

[0076] According to one embodiment, the optimized app list (450) may include a third set of apps included in at least one standby bucket. Standby buckets may be used to automatically allocate and / or limit resources (particularly CPU, network, etc. related to background tasks) for the app according to how often the user uses the app (e.g., usage time (time the app is displayed on the foreground screen), interaction with the user, interaction cycle, update frequency, etc.). The electronic device (101) may place each app in one of a plurality of standby buckets. The plurality of standby buckets may include, according to priority, an active standby bucket, a working set standby bucket, a frequent standby bucket, a rare standby bucket, and a restricted standby bucket. The active standby bucket may include apps that the user is currently using or has recently used frequently (foreground execution, notification clicks, etc.). The working set standby bucket may represent apps that are used regularly, although their usage frequency is not as high as that of the 'active' bucket. For example, a working set bucket may include apps that run very frequently, even if not every day, or receive many queries from other apps. A frequent wait bucket may include apps with moderate usage frequency. A rare wait bucket may include apps that are rarely used. A restricted wait bucket may include apps that have been explicitly restricted by the user or apps that the system has determined require a significant reduction in resource usage. Meanwhile, in addition to the aforementioned multiple wait buckets, an exempted wait bucket may be used. The exempted wait bucket may include apps that are set to be exempt from restrictions so that they can freely perform background tasks or network access by the user or the system.In other words, the aforementioned exempted standby bucket may always be a bucket with high priority regardless of usage frequency. For example, the exempted standby bucket may include system apps or vendor apps, hardware drivers, and authentication services.

[0077] At least one waiting bucket corresponding to the third set of apps may include at least one of the five classes of waiting buckets and / or exempted waiting buckets described above. According to one embodiment, the at least one waiting bucket corresponding to the third set of apps may include an active waiting bucket and a working set waiting bucket. Waiting buckets other than the active waiting bucket and the working set waiting bucket may be excluded from the at least one waiting bucket. According to one embodiment, the at least one waiting bucket may include an active waiting bucket, a working set waiting bucket, and an exempted waiting bucket. Waiting buckets other than the active waiting bucket, the working set waiting bucket, and the exempted waiting bucket may be excluded from the at least one waiting bucket. According to one embodiment, the at least one waiting bucket may include an active waiting bucket, a working set waiting bucket, a frequency waiting bucket, and an exempted waiting bucket. Waiting buckets other than the active waiting bucket, the working set waiting bucket, the frequency waiting bucket, and the exempted waiting bucket may be excluded from the at least one waiting bucket.

[0078] According to one embodiment, the optimization app list (450) may include at least one of the first set of apps, the second set of apps, and / or the third set of apps. For example, the optimization app list (450) may include the first set of apps and the second set of apps. For example, the optimization app list (450) may include the second set of apps and the third set of apps. For example, the optimization app list (450) may include the first set of apps and the third set of apps. For example, the optimization app list (450) may include the first set of apps, the second set of apps, and the third set of apps.

[0079] FIG. 6 illustrates the operation of components of a system management process (e.g., system management process (420)) following booting after a system update. An electronic device (101) according to embodiments of the present disclosure may generate a list of frequently used packages (e.g., optimization app list (450)) and, in response to a system update (e.g., regular system updates as well as updates to modularized system components (e.g., mainline)), perform optimization operations on one or more apps in the list. The electronic device (101) may monitor the state of the electronic device (101) so that the user does not perceive a performance degradation caused by the optimization operation, and may stop or resume the optimization operation based on the monitoring results. FIG. 6 illustrates the operation between components in a situation where booting (i.e., rebooting) is performed after a system update.

[0080] Referring to FIG. 6, the system server (510) represents a process for controlling the main functions of the device by managing various system services within the operating system of the electronic device (101) and supporting communication between services. The system server (510) may correspond to the system management process (420) of FIG. 4. When the electronic device (101) boots up, the system server (510) may start. As the system server (510) starts, the profile utilization service (511) may be executed. The electronic device (101) may execute the runtime service (610). The runtime service (610) may modularize the functions of the runtime environment (e.g., ART) and may be configured independently of the system server (510). The runtime service (610) may correspond to the runtime management process (430) of FIG. 4. The electronic device (101) can perform optimization of an executable file (e.g., dex file (320)) (e.g., executable file optimization process (e.g., dexopt (611), dex2oat (612))), profile saving, and / or analysis of the optimized executable file (e.g., oat file) (e.g., oatdump) through the runtime service (610).

[0081] The electronic device (101) may use a profile utilization service (511) to manage optimization operations. In operation (S610), the electronic device (101) may identify a boot. In operation (S620), the electronic device (101) may start the profile utilization service (511) upon booting. The electronic device (101) may determine whether optimization operations are necessary for a package. According to one embodiment, in the profile utilization service (511), the electronic device (101) may determine whether optimization operations are necessary upon booting. For example, the electronic device (101) may identify a system update. The electronic device (101) may determine whether the free storage space of the electronic device (101) is above a threshold. If the system update is identified and the free storage space is above the threshold, the electronic device (101) may initiate an optimization operation.

[0082] In operation (S630), the electronic device (101) may register a receiver / listener. Specifically, in operation (S631), the profile utilization service (511) of the electronic device (101) may subscribe to a specific operation. In operation (S632), a messaging object (e.g., an intent in the Android OS) generated according to a user request or a system API (application programming interface) may be delivered to the profile utilization service (511). For example, the electronic device (101) may register a broadcast receiver (e.g., a BroadcastReceiver) to detect a user's termination operation. The broadcast receiver to detect a termination operation may be registered regardless of whether the system is updated.

[0083] The electronic device (101) may register an event listener. The electronic device (101) may register a receiver for a messaging object (e.g., an intent) necessary to know the state of the electronic device (101). For example, the electronic device (101) may obtain, through the receiver, a messaging object (e.g., Intent.ACTION_LOCKED_BOOT_COMPLETED) indicating that the electronic device (101) is in an optimizable state for apps after the boot process is complete, or that the electronic device (101) is in a state before the user first unlocks it after the boot process is complete. For example, the electronic device (101) may obtain, through the receiver, a messaging object (e.g., Intent.ACTION_SCREEN_ON & Intent.ACTION_USER_UNLOCKED) indicating that the screen of the electronic device (101) is on and the electronic device (101) is unlocked. Through the above messaging object, it is determined that the user is using the electronic device (101), and accordingly, the optimization operation may be stopped. For example, the electronic device (101) may obtain a messaging object (e.g., Intent.ACTION_SCREEN_OFF) indicating that the screen of the electronic device (101) is turned off through a receiver. Through the above messaging object, it may be confirmed that the user has stopped using the electronic device (101). Through this, the optimization operation may be resumed. For example, the electronic device (101) may obtain a messaging object (e.g., Intent.ACTION_BATTERY_CHANGED) indicating that the state of the battery of the electronic device (101) has changed through a receiver. Through the above messaging object, the electronic device (101) may check the battery information, and if the current remaining battery level is below a threshold, the optimization operation may be stopped or resumed.

[0084] In operation (S640), the electronic device (101) can perform device status monitoring. For the device status monitoring, a device status watcher of the profile utilization service (511) may be used. For example, in operation (S641), the device status watcher reports an update status, and in operation (S642), information about the device status may be obtained. To start the optimization operation of the app, it may be determined whether at least one condition related to the state of the electronic device (101) is satisfied. The electronic device (101) may perform an initialization operation for the optimization operation. For example, if a messaging object (e.g., Intent.ACTION_LOCKED_BOOT_COMPLETED) is obtained indicating that the apps are in an optimizable state after the completion of the boot process of the electronic device (101) or that the state is before the user first unlocks after the completion of the boot process, the electronic device (101) may start preparing for the optimization operation. Subsequently, the electronic device (101) can check whether the temperature is above a threshold through a listener of a temperature management service (e.g., ThermalManagerService). The electronic device (101) can initialize an optimization trigger module to provide optimization commands to the runtime service (610). The electronic device (101) can load an optimization app list (450).

[0085] The electronic device (101) can determine whether at least one condition related to the state of the electronic device (101) is satisfied. For example, the at least one condition may include a first condition in which the screen of the electronic device (101) is off, a second condition in which the temperature of the electronic device (101) is below a temperature threshold (e.g., about 36 degrees), and / or a third condition in which the remaining battery level of the electronic device (101) is above a battery threshold (e.g., about 25%). The electronic device (101) can determine whether the at least one condition is satisfied through an event listener. According to one embodiment, if at least one condition related to the state of the electronic device (101) is satisfied, the electronic device (101) may provide a command to the optimization trigger module to start or resume the optimization operation. According to one embodiment, if at least one condition related to the state of the electronic device (101) is not satisfied, the electronic device (101) may provide a command to the optimization trigger module to cancel or stop the optimization operation.

[0086] In operation (S650), the electronic device (101) can perform an optimization operation through the runtime service (610) via the optimization trigger module. For example, in operation (S651), the profile usage service (511) can send an optimization command to the runtime service (610). An optimization operation for the corresponding app can be performed through an executable file optimization process (e.g., dexopt (611) and / or dex2oat (612)). According to one embodiment, optimization of the package can be initiated according to the priority of the apps in the optimization app list (450). Optimization operations for each app can be performed sequentially according to the priority of the apps in the optimization app list (450). When optimization is completed, statistics related to the optimization can be collected. For example, evaluation metrics such as the number of package executions, the number of prediction executions, precision, recall, and f1-score can be stored. Meanwhile, if the user changes the state of the electronic device (101) during the optimization operation (e.g., the screen is turned on from off), the profile usage service (511) may cancel the optimization command to the runtime service (610). For example, in operation (S652), the profile usage service (511) may send a command to cancel optimization to the runtime service (610). Afterward, the optimization app list (450) may be updated. Afterward, when all optimization operations for the apps in the optimization app list (450) are performed or the optimization operation is canceled, the optimization operation may be terminated (660).

[0087] An electronic device (101) according to embodiments of the present disclosure may perform optimization operations on apps in an optimization app list (450) according to priority. In order to determine frequently used packages according to user patterns among the entire list of packages installed in the electronic device (101), packages may be classified by various conditions and priority may be assigned to each package. For example, they may be classified into a first set of apps executable by a user of the electronic device (101), a second set of apps having a profile that was optimized before a system update, and a third set of apps belonging to at least one standby bucket. According to one embodiment, priority may be assigned to each app based on the number of times the package of each app (e.g., at least one of the first set of apps, the second set of apps, and / or the third set of apps) is executed and the foreground duration (e.g., the time the app is kept in the foreground while the screen of the electronic device (101) is on). Apps may be sorted according to priority. For example, apps can be categorized into the following lists based on usage period. For the apps within each list, the table below can be referenced.

[0088] 1) Most used list: Packages used over the past 28 days (one month)

[0089] 2) Same day list: Packages used for 1 day starting from 1 week ago

[0090] 3) Same time list: Packages used for 1 hour starting from 1 week ago

[0091] 4) Recents list: list of recently used apps

[0092] #Most usedSame daySame timeRecents1App1App1App1App12App2App3App4App43App3App5App3App24App4App4App35App5

[0093] For example, the weight of an app can be calculated by adding the ranks of each list. If there is no app in the list, a penalty value may be added to the weight. The penalty value may be a fixed value or determined by adding a constant (e.g., 1) to the size of the list with the most apps. For example, the penalty value may be 6. In this way, the weight of the first app (App1) may be 4 (=1+1+1+1). The weight of the second app (App2) may be 17 (=2+6+6+3). The weight of the third app (App3) may be 12 (=3+2+3+4). The weight of the fourth app (App4) may be 12 (=4+4+2+2). The weight of the fifth app (App5) may be 20 (=5+3+6+6). Optimization operations can be performed in the order of App1, App3, App4, App3, and App5. The smaller the weight value, the higher the priority.

[0094] According to one embodiment, priority may be determined based on the type of waiting bucket as well as usage frequency. For example, the priority of an app included in an exemption waiting bucket may be higher than the priority of an app included in other waiting buckets (e.g., active waiting bucket, working set waiting bucket, frequency waiting bucket, rare waiting bucket, restricted waiting bucket). For example, the priority of an app included in an active waiting bucket may be higher than the priority of an app included in a working set waiting bucket. For example, the priority of an app included in a working set waiting bucket may be higher than the priority of an app included in a frequency waiting bucket. As an example not limited to, weight values ​​may be determined based on the waiting bucket to which the app belongs and other parameters (e.g., daily usage frequency, weekly usage frequency, monthly usage frequency). The weight values ​​may be used to determine the final priority for the order of optimization operations.

[0095] An electronic device (101) according to embodiments of the present disclosure may obtain priority information to perform optimization operations on apps in an optimization app list (450). The priority information may include a priority for each app (or a weight value for determining the priority). According to one embodiment, the priority information may be stored in the optimization app list (450). The optimization app list (450) may include the name and weight value (priority parameter) of each app. At the time the optimization app list (450) is created, the weight value may be determined based on the usage frequency for each app. For example, when the electronic device (101) detects a shutdown, it may store an optimization app list (450) containing information about the app on which the optimization operation will be performed and the weight of the corresponding app. According to another embodiment, the priority information may be stored separately from the optimization app list (450). The priority information may be used as unique data based on the usage frequency of the app. Apart from the creation of the optimization app list (450), a weight value may be determined based on the usage frequency for each app. For example, the electronic device (101) may obtain the priority information when initiating the actual optimization operation.

[0096] In the embodiments of the present disclosure, a technique is described for selecting frequently used packages (e.g., a list of optimized apps (450)) during a specific period (e.g., the last month) to improve the user experience after a system update, and for performing optimization (e.g., compilation) of the selected apps according to priority. This allows the user experience to be improved even immediately after a system update. To avoid interfering with the use of the user's electronic device (101), the optimization operation is performed when the screen is off and when the device is not overheated and the battery level is sufficient.

[0097] FIG. 7 illustrates the flow of operation of an electronic device (e.g., electronic device (101)) to perform an optimization operation in response to a system update according to priority.

[0098] Referring to FIG. 7, in operation (701), the electronic device (101) can detect the booting of the electronic device (101). For example, the booting may include a reboot following a system update of the electronic device (101) (e.g., an update of modularized system components (e.g., a mainline module)). The electronic device (101) may obtain information related to the system update and, upon performing the system update based on said information, reboot the electronic device (101). The electronic device (101) may detect the booting of the electronic device (101) through a system management process (e.g., the system management process (420) of FIG. 4, the system server (510) of FIG. 5).

[0099] In operation (703), the electronic device (101) can determine whether a system update is identified. The electronic device (101) can perform operation (705) based on identifying a system update. If the electronic device (101) does not identify a system update, for example, if the boot is a normal boot rather than a reboot due to a system update, the procedure can be terminated.

[0100] In operation (705), the electronic device (101) can identify a list of one or more apps to be optimized (e.g., a list of optimized apps (450)) in response to a system update. The list of optimized apps (450)) can be stored in the memory of the electronic device (101) (e.g., non-volatile memory (134)). For example, upon termination of the electronic device (101), the electronic device (101) can generate a list of one or more apps to be optimized (e.g., a list of optimized apps (450)). The one or more apps to be optimized can be performed in advance independently of the system update. An operation for determining one or more apps to be optimized is described in detail through FIG. 8.

[0101] In operation (707), the electronic device (101) can monitor the state of the electronic device (101). For example, the electronic device (101) can perform monitoring of the state of the electronic device (101) through a broadcast receiver and / or an event listener. The electronic device (101) can determine whether at least one condition related to the state of the electronic device (101) is satisfied in order to initiate an optimization operation. The electronic device (101) can monitor parameters and / or messaging objects necessary to determine whether at least one condition related to the state of the electronic device (101) is satisfied.

[0102] In operation (709), the electronic device (101) may perform an optimization operation for each app based on the monitoring results and priority information for one or more apps. The electronic device (101) may determine, based on the monitoring results, that at least one condition related to the state of the electronic device (101) is satisfied. For example, the electronic device (101) may determine that the screen of the electronic device (101) is off, the temperature of the electronic device (101) is below a temperature threshold (e.g., about 36 degrees), and / or the remaining battery level of the electronic device (101) is above a battery threshold (e.g., about 25%). The electronic device (101) may perform an optimization operation based on the determination that at least one condition related to the state of the electronic device (101) is satisfied. The electronic device (101) may perform an optimization operation for each app based on priority information for one or more apps. The priority information may include a weight value for each app. The weight value may be used to determine the priority of the apps in the list. The electronic device (101) can perform optimization operations in order of highest priority. As a non-limiting example, the lower the weight value, the higher the priority.

[0103] The electronic device (101) may obtain priority information for optimization operations. For example, the priority information may be generated when the optimization app list (450) is created and may be included in the optimization app list (450). Subsequently, when loading the apps of the optimization app list (450), the electronic device (101) may obtain priority information. As another example, when starting an optimization operation, the electronic device (101) may obtain priority information based on the current app status. According to one embodiment, the electronic device (101) may determine a weight value for each app based on the usage frequency of the apps. The electronic device (101) may classify apps into a list of recently used apps, a list used for one hour, a list used for one day, and a list used for one month, and then determine the weight value of the corresponding app based on whether it is included in each list. According to one embodiment, the electronic device (101) may determine the weight value based on the waiting bucket to which the app belongs. For example, the lower the weight value, the higher the priority. The electronic device (101) may assign the highest level score (e.g., 1 point) to apps belonging to the exemption waiting bucket. The electronic device (101) may assign the next highest level score (e.g., 2 points) to apps belonging to the active waiting bucket. The electronic device (101) may assign the next highest level score (e.g., 3 points) to apps belonging to the working set waiting bucket. In this way, a score is assigned to each app, and the score can be used to determine a weight value (or priority). The higher the score, the greater the weight value may be. The greater the weight value, the lower the priority may be. According to one embodiment, the electronic device (101) may determine the weight value based on the type of app. For example, the electronic device (101) may apply a weight of a fixed value (e.g., 3 points) to an app corresponding to a package defined in a manifest file as a launchable package.For example, an electronic device (101) that has already been optimized can apply a fixed value weight (e.g., 4 points) to an app.

[0104] FIG. 8 illustrates the flow of operation of an electronic device (e.g., electronic device (101)) for generating a list of one or more apps to which optimization operations are to be performed in response to a system update.

[0105] Referring to FIG. 8, in operation (801), the electronic device (101) can detect the booting of the electronic device (101).

[0106] In operation (803), the electronic device (101) may register a shutdown receiver. The electronic device (101) may register a shutdown receiver in response to booting. The shutdown receiver may be used to detect the shutdown or reboot of the electronic device (101). Not illustrated in FIG. 8, but not limited to examples, the registration of the shutdown receiver may be omitted as an optional operation to detect shutdown. Without a separate shutdown receiver, operations (e.g., operation (801), operation (803), and operation (807)) for generating a list of one or more apps on which optimization operations will be performed may be performed.

[0107] In operation (805), the electronic device (101) may detect the shutdown or reboot of the electronic device (101). For example, when a shutdown operation of the electronic device (101) occurs due to a user request or a system API (application programming interface) being called, the electronic device (101) may obtain a shutdown messaging object (e.g., 'Intent.ACTION_SHUTDOWN'). The reboot may be a reboot caused by a system update. The reboot may include the shutdown of the electronic device (101).

[0108] In operation (807), the electronic device (101) may generate a list of one or more apps on which an optimization operation is to be performed (e.g., an optimization app list (450)). The electronic device (101) may generate the optimization app list (450) based on app information and / or status information within the system management process (420) of the electronic device (101). According to one embodiment, the optimization app list (450) may include a name and a weight value for each app. As an example not limited to, the name and weight values ​​may be stored in a data format common to clients (e.g., JSON (JavaScript Object Notation) file). The weight values ​​may be used to determine the priority of the corresponding app over other apps in the optimized app list (450). According to one embodiment, the electronic device (101) may determine one or more apps to be optimized based on the frequency of use by a user within the electronic device (101). According to one embodiment, the electronic device (101) may determine at least one of a first set of apps executable by the user, a second set of apps having a profile optimized before a system update, and / or a third set of apps belonging to at least one standby bucket as one or more apps to be optimized. According to one embodiment, the electronic device (101) may calculate weights for all of the first set of apps executable by the user, the second set of apps having a profile optimized before a system update, and / or the third set of apps belonging to at least one standby bucket to determine one or more apps to be optimized. You can decide with apps.

[0109] In FIG. 8, an example is described in which the optimization app list (450) is generated upon termination, but the embodiments of the present disclosure are not limited thereto. For example, the optimization app list (450) may be generated after booting.

[0110] FIG. 9 illustrates the flow of operation of an electronic device (e.g., electronic device (101)) to stop or resume optimization operation depending on the state of the electronic device.

[0111] Referring to FIG. 9, in operation (901), the electronic device (101) may perform device status monitoring. For example, the device status monitoring may include determining whether the temperature of the electronic device (101) is above a threshold value. The device status monitoring may be performed in advance to initiate an optimization operation. For example, the device status monitoring may include determining whether the remaining battery level of the electronic device (101) is above a threshold value. For example, the device status monitoring may include determining whether the screen of the electronic device (101) is on or off.

[0112] In operation (903), the electronic device (101) can determine whether an app for optimization is identified. The electronic device (101) can perform optimization operations sequentially according to the priority of each app. When an optimization operation is performed for one app among the apps in the optimization app list (450), said app may be excluded from the optimization target. In this way, when the optimization operation for all apps in the optimization app list (450) is completed, the electronic device (101) can terminate the procedure. The electronic device (101) can perform operation (905) based on the determination that an app for optimization is identified. When an app for optimization is identified, optimization for said app may be initiated or the optimization for said app may be suspended. The electronic device (101) can terminate the procedure for optimization operations based on the determination that an app for optimization is not identified.

[0113] In operation (905), the electronic device (101) can determine whether a usage event is detected. The electronic device (101) can perform operation (907) based on the determination that a usage event is detected. The electronic device (101) can perform operation (909) based on the determination that a usage event is not detected.

[0114] In operation (907), the electronic device (101) can stop the ongoing optimization operation. The electronic device (101) can stop the optimization operation so that the user of the electronic device (101) does not feel any inconvenience due to the optimization operation while using the electronic device (101). The profile utilization service (511) of the electronic device (101) can send an optimization stop command to the runtime service (610) via the optimization trigger module.

[0115] In operation (909), the electronic device (101) can determine whether the device state is checked. In operation (909), the device state can be used to determine the resumption of a suspended process. According to one embodiment, the electronic device (101) can check whether the screen of the electronic device (101) is turned off. For example, a messaging object (e.g., Intent.ACTION_SCREEN_OFF) indicating that the screen of the electronic device (101) is turned off can be obtained. Through the messaging object, it can be confirmed that the user has stopped using the electronic device (101). According to one embodiment, the electronic device (101) can check whether the remaining amount of the battery of the electronic device (101) is below a threshold value. For example, a messaging object (e.g., Intent.ACTION_BATTERY_CHANGED) indicating that the state of the battery of the electronic device (101) has changed can be obtained. Through the above messaging object, the electronic device (101) can determine whether the current remaining battery level is below a threshold by checking battery information. The electronic device (101) can perform an operation (911) based on the determination that the device status is confirmed. The electronic device (101) can perform an operation (901) again based on the determination that the device status is not confirmed.

[0116] In operation (911), the electronic device (101) can resume the interrupted optimization operation. The electronic device (101) can perform the optimization operation again because the user is not using the electronic device (101). The profile utilization service (511) of the electronic device (101) can send an optimization resume command to the runtime service (610) via the optimization trigger module.

[0117] The implementation of the present disclosure can be verified by checking the compilation status of the application immediately after a system update of the electronic device (101) (including updates to modularized system components (e.g., mainline module). For example, the compilation status of each app can be checked through ADB (Android Debug Bridge) commands (e.g., adb shell pm art dump, adb shell dumpsys package dexopt). The compilation status may be a verified status (e.g., 'verify status') or a profile status (e.g., 'speed-profile status'). The verified status may indicate a state in which a verification file (e.g., vdex (verified dex) file) is generated by extracting the executable file (e.g., dex file) of the APK after installation, so a separate verification procedure for the executable file is omitted when the app is executed. The profile status may indicate a state in which an optimization file (e.g., odex file) is generated as AOT optimization is completed, as a profile related to frequently executed code is collected due to the continuous use of the app. Since the system is in a verified state (e.g., 'verify status') before optimization, if applications that were frequently used before the update have a profile state (e.g., 'speed-profile status') immediately after the system update, it can be confirmed that the optimization operation according to the embodiments of the present disclosure has been performed.

[0118] In the embodiments of the present disclosure, a technique is described for selecting frequently used packages (e.g., an optimized app list (450)) during a specific period (e.g., the last month) to improve the user experience after a system update, and for performing optimization (e.g., compilation) of the selected apps according to priority. Through this, the user experience can be improved even immediately after a system update. Additionally, user convenience can be improved as the optimization operation proceeds when the screen is off, when it is not overheated, and when the battery level is sufficient, so as not to interfere with the use of the electronic device (101).

[0119] The effects obtainable from the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure belongs from the description below.

[0120] In embodiments of the present disclosure, an electronic device (101) is provided. The electronic device (101) may include at least one processor comprising a processing circuit; and a memory (134) comprising one or more storage media for storing instructions. The instructions, when executed by the at least one processor, may collectively or individually cause the electronic device (101) to perform a system update in response to the booting of the electronic device (101), identify from the memory (134) a list (450) of one or more apps for which an optimization operation is to be performed after the system update, monitor the state of the electronic device (101), and, based on the result of monitoring the state of the electronic device (101), cause the optimization operation for each app according to priority information for the one or more apps. The optimization operation may include converting the byte code associated with the app into executable native code.

[0121] In embodiments of the present disclosure, an electronic device (101) is provided. The electronic device (101) may include a communication circuit (410); at least one processor including a processing circuit; and a memory (134) including one or more storage media for storing instructions. The instructions may, when executed by the at least one processor, collectively or individually, cause the electronic device (101) to obtain information for a system update through the communication circuit (410), and after obtaining information for the system update, to identify the system update in response to the booting of the electronic device (101), to identify a list (450) of one or more apps to be optimized in response to the system update from the memory (134), to monitor the state of the electronic device (101) in response to the system update, and to perform the optimization operation for each app according to priority information for the one or more apps based on the result of monitoring the state of the electronic device (101). The above optimization operation may include converting bytecode associated with the app into executable native code.

[0122] For example, the number of one or more apps in the list (450) may be smaller than the total number of apps of the electronic device (101). Priority information for the one or more apps may be determined for each app based on the number of times the app's package is executed and the time the app remains in the foreground while the screen of the electronic device (101) is turned on.

[0123] For example, the number of one or more apps in the list (450) may be smaller than the total number of apps of the electronic device (101). The one or more apps in the list (450) may include a first set of apps executable by a user of the electronic device (101), a second set of apps having a profile optimized prior to the system update, and a third set of apps belonging to at least one standby bucket. The at least one standby bucket may include an active standby bucket containing apps currently in use or recently used, and a working set standby bucket containing apps used more than a certain frequency.

[0124] For example, the number of one or more apps in the list (450) may be smaller than the total number of apps of the electronic device (101). The one or more apps in the list (450) may include at least one of a first set of apps executable by a user of the electronic device (101), a second set of apps having a profile optimized prior to the system update, and a third set of apps belonging to at least one standby bucket. The at least one standby bucket may include an active standby bucket containing apps currently in use or recently used apps, and a working set standby bucket containing apps used more than a certain frequency.

[0125] For example, priority information for the one or more apps may be obtained based on the list (450) of the one or more apps being identified from the memory (134). The priority of an app in the active waiting bucket may be higher than the priority of an app in the working set waiting bucket.

[0126] For example, priority information for the one or more apps may be obtained based on the list (450) of the one or more apps being identified from the memory (134). The priority of the third set of apps may be higher than the priority of the second set of apps. The priority of the second set of apps may be higher than the priority of the first set.

[0127] For example, priority information for the one or more apps may be obtained based on the identification of a list (450) of the one or more apps from the memory (134). The one or more apps in the list (450) may include at least one app belonging to an exempted waiting bucket. The at least one app in the exempted waiting bucket may be pre-configured to have a higher priority than other apps within the list (450).

[0128] For example, the system update may include a standard system update provided by the vendor of the electronic device (101) or an update of modularized system components. The system update may cause a change in the boot class path (BCP) within the electronic device (101). One or more classes associated with the BCP may be compiled into native code through at least part of the optimization operation.

[0129] For example, when the above instructions are executed collectively or individually by the at least one processor, in order to perform the optimization operation, the electronic device (101) may determine whether at least one condition related to the state of the electronic device (101) is satisfied based on the result of monitoring the state of the electronic device (101), and upon the determination that at least one condition related to the state of the electronic device (101) is satisfied, cause the optimization operation to be initiated, the optimization operation in progress to be maintained, or the optimization operation in interruption to be resumed, and upon the determination that at least one condition related to the state of the electronic device (101) is not satisfied, cause the optimization operation in progress to be interrupted or the optimization operation to be canceled.

[0130] For example, the above at least one condition may include a first condition in which the screen of the electronic device (101) is off, a second condition in which the temperature of the electronic device (101) is below a temperature threshold, and a third condition in which the remaining amount of the battery of the electronic device (101) is above a battery threshold.

[0131] For example, when the above instructions are executed collectively or individually by the at least one processor, the electronic device (101) may be caused to register a shutdown receiver in response to the booting of the electronic device (101), identify one or more apps to which the optimization operation is to be performed in response to the detection of the shutdown or reboot of the electronic device (101) through the shutdown receiver, determine a weight value for each of the one or more apps based on the usage frequency of each app, generate a list (450) of the one or more apps including identification information of each app and the weight value, and store the list (450) of the one or more apps in the memory (134).

[0132] For example, when the above instructions are executed collectively or individually by the at least one processor, the electronic device (101) may identify one or more apps on which the optimization operation is to be performed, determine a weight value for each of the one or more apps based on the usage frequency of each app, generate a list (450) of the one or more apps including identification information of each app and the weight value, and store the list (450) of the one or more apps in the memory (134).

[0133] In embodiments of the present disclosure, a method is provided to be performed by an electronic device (101). The method may include performing the system update in response to the booting of the electronic device (101) and, after the system update, identifying from the memory (134) a list (450) of one or more apps for which an optimization operation is to be performed. The optimization operation may include converting byte code associated with the app into executable native code. The method may include monitoring the state of the electronic device (101) and, based on the result of monitoring the state of the electronic device (101), performing the optimization operation for each app according to priority information for the one or more apps.

[0134] In embodiments of the present disclosure, a method performed by an electronic device (101) is provided. The method may include obtaining information for a system update, identifying the system update in response to booting of the electronic device (101) after obtaining the information for the system update, and identifying from the memory (134) a list (450) of one or more apps for which an optimization operation is to be performed in response to the system update. The optimization operation may include converting byte code associated with the app into executable native code. The method may include monitoring the state of the electronic device (101) in response to the system update, and performing the optimization operation for each app according to priority information for the one or more apps based on the result of monitoring the state of the electronic device (101).

[0135] For example, the number of one or more apps in the list (450) may be smaller than the total number of apps of the electronic device (101). Priority information for the one or more apps may be determined for each app based on the number of times the app's package is executed and the time the app remains in the foreground while the screen of the electronic device (101) is turned on.

[0136] For example, the number of one or more apps in the list (450) may be smaller than the total number of apps of the electronic device (101). The one or more apps in the list (450) may include a first set of apps executable by a user of the electronic device (101), a second set of apps having a profile optimized prior to the system update, and a third set of apps belonging to at least one standby bucket. The at least one standby bucket may include an active standby bucket containing apps currently in use or recently used apps, and a working set standby bucket containing apps used more than a certain frequency.

[0137] For example, the number of one or more apps in the list (450) may be smaller than the total number of apps of the electronic device (101). The one or more apps in the list (450) may include at least one of a first set of apps executable by a user of the electronic device (101), a second set of apps having a profile optimized prior to the system update, and a third set of apps belonging to at least one standby bucket. The at least one standby bucket may include an active standby bucket containing apps currently in use or recently used apps, and a working set standby bucket containing apps used more than a certain frequency.

[0138] For example, priority information for the one or more apps may be obtained based on the list (450) of the one or more apps being identified from the memory (134). The priority of an app in the active waiting bucket may be higher than the priority of an app in the working set waiting bucket.

[0139] For example, priority information for the one or more apps may be obtained based on the list (450) of the one or more apps being identified from the memory (134). The priority of the third set of apps may be higher than the priority of the second set of apps. The priority of the second set of apps may be higher than the priority of the first set.

[0140] For example, priority information for the one or more apps may be obtained based on the identification of a list (450) of the one or more apps from the memory (134). The one or more apps in the list (450) may include at least one app belonging to an exempted waiting bucket. The at least one app in the exempted waiting bucket may be pre-configured to have a higher priority than other apps within the list (450).

[0141] For example, the system update may include a standard system update provided by the vendor of the electronic device (101) or an update of modularized system components. The system update may cause a change in the boot class path (BCP) within the electronic device (101). One or more classes associated with the BCP may be compiled into native code through the optimization.

[0142] For example, performing the optimization operation may include determining whether at least one condition related to the state of the electronic device (101) is satisfied based on the result of monitoring the state of the electronic device (101); initiating the optimization operation, maintaining the ongoing optimization operation, or resuming the interrupted optimization operation based on the determination that at least one condition related to the state of the electronic device (101) is satisfied; and interrupting the ongoing optimization operation or canceling the optimization operation based on the determination that at least one condition related to the state of the electronic device (101) is not satisfied. The at least one condition may include a first condition in which the screen of the electronic device (101) is off, a second condition in which the temperature of the electronic device (101) is below a temperature threshold, and a third condition in which the remaining amount of the battery of the electronic device (101) is above a battery threshold.

[0143] For example, the above method may include registering a shutdown receiver in response to the booting of the electronic device (101), identifying one or more apps on which the optimization operation is to be performed in response to detecting the shutdown or reboot of the electronic device (101) through the shutdown receiver, determining a weight value for each of the one or more apps based on the usage frequency of each app, generating a list (450) of the one or more apps including identification information of each app and the weight value, and storing the list (450) of the one or more apps in the memory (134).

[0144] According to embodiments of the present disclosure, a non-transient computer-readable storage medium is provided. The non-transient computer-readable storage medium is configured to store instructions that cause an electronic device (101) to perform functions collectively or individually when executed by at least one processor, said functions may include performing a system update in response to the booting of the electronic device (101), identifying from the memory (134) a list (450) of one or more apps for which an optimization operation is to be performed after the system update, said optimization operation including converting byte code associated with said app into executable native code, said optimization operation including monitoring the state of the electronic device (101), and performing the optimization operation for each app according to priority information for said one or more apps based on the result of monitoring the state of the electronic device (101).

[0145] According to embodiments of the present disclosure, a non-transient computer-readable storage medium is provided. The non-transient computer-readable storage medium is configured to store instructions that cause an electronic device (101) to perform functions collectively or individually when executed by at least one processor, said functions may include obtaining information for a system update, and after obtaining information for the system update, identifying the system update in response to the booting of the electronic device (101), identifying from the memory (134) a list (450) of one or more apps for which an optimization operation is to be performed in response to the system update, - said optimization operation includes converting byte code associated with the app into executable native code, and - said optimization operation, monitoring the state of the electronic device (101) in response to the system update, and performing the optimization operation for each app according to priority information for the one or more apps based on the result of monitoring the state of the electronic device (101).

[0146] For one or more embodiments, at least one of the components described in one or more of the prior art drawings may be configured to perform one or more operations, techniques, processes and / or methods as described in the present disclosure. For example, a processor (e.g., a baseband processor) described in the present disclosure in relation to one or more of the prior art drawings may be configured to operate according to one or more examples described in the present disclosure. As another example, circuits associated with user equipment (UE), a base station, a network element, etc., as described above in relation to one or more of the prior art drawings may be configured to operate according to one or more examples described herein.

[0147] Any of the embodiments described above may be combined with any other embodiment (or combination of embodiments) unless otherwise explicitly stated. The foregoing description of one or more embodiments is for illustrative and explanatory purposes only, and is not intended to limit or exhaust the scope of the embodiments in the exact form disclosed. Modifications and variations are possible in light of the foregoing teachings or may be obtained from the practice of various embodiments.

[0148] The electronic devices according to the various embodiments disclosed in this document may be of various forms. The electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, electronic devices, or consumer electronics. The electronic devices according to the embodiments of this document are not limited to the devices described above.

[0149] The various embodiments of this document and the terms used therein are not intended to limit the technical features described in this document to specific embodiments, and should be understood to include various modifications, equivalents, or substitutions of said embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of said items unless the relevant context clearly indicates otherwise. In this document, phrases such as "A or B," "at least one of A and B," "at least one of A or B," "A, B or C," "at least one of A, B and C," and "at least one of A, B, or C" may each include any one of the items listed together in the corresponding phrase, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used simply to distinguish said components from other said components and do not limit said components in any other aspect (e.g., importance or order). Where any (e.g., 1st) component is referred to as "coupled" or "connected" to another (e.g., 2nd) component, with or without the terms "functionally" or "communicationly," it means that said any component may be connected to said other component directly (e.g., via a wire), wirelessly, or through a third component.

[0150] The term “module” as used in the various embodiments of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit, for example. A module may be a component formed integrally, or a minimum unit of said component or a part thereof that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0151] Various embodiments of the present document may be implemented as software (e.g., program (140)) comprising one or more instructions stored in a storage medium (e.g., internal memory (136) or external memory (138)) readable by a machine (e.g., electronic device (101)). For example, a processor (e.g., processor (120)) of the machine (e.g., electronic device (101)) may call at least one of the one or more instructions stored in the storage medium and execute it. This enables the machine to be operated to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code that can be executed by an interpreter. The storage medium readable by the machine may be provided in the form of a non-transitory storage medium. Here, 'non-temporary' simply means that the storage medium is a tangible device and does not contain a signal (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently and cases where it is stored temporarily.

[0152] According to one embodiment, the method according to the various embodiments disclosed herein may be provided by being included in a computer program product. The computer program product may be traded between a seller and a buyer as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or distributed online (e.g., download or upload) through an application store (e.g., Play Store™) or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created on a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

[0153] According to various embodiments, each component (e.g., module or program) of the components described above may include a singular or multiple entities, and some of the multiple entities may be separated and placed in other components. According to various embodiments, one or more of the components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Generally or additionally, multiple components (e.g., module or program) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the multiple components in the same or similar manner as those performed by the corresponding component among the multiple components prior to integration. According to various embodiments, operations performed by the module, program, or other components may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

Claims

1. In an electronic device; At least one processor including a processing circuit; and The memory includes one or more storage media for storing instructions, and When the above instructions are executed by the at least one processor, collectively or individually, the electronic device: Performing a system update in response to the booting of the above electronic device, Identifying a list of one or more apps from the memory on which optimization operations are to be performed after the above system update, and the optimization operation includes converting byte code associated with the app into executable native code. Monitoring the status of the above electronic device, and Causing to perform the optimization operation for each app according to priority information for the one or more apps based on the result of monitoring the state of the electronic device, Electronic device.

2. In Claim 1, The number of one or more apps in the above list is smaller than the total number of apps of the electronic device, and Priority information for one or more of the above apps is determined for each app based on the number of times the app's package is executed and the time the app remains in the foreground while the electronic device's screen is on. Electronic device.

3. In Claim 1, The number of one or more apps in the above list is smaller than the total number of apps of the electronic device, and The above list of one or more apps includes at least one of a first set of apps executable by a user of the electronic device, a second set of apps having a profile optimized prior to the system update, and a third set of apps belonging to at least one standby bucket. The above at least one standby bucket includes an active standby bucket containing an app currently in use or a recently used app, and a working set standby bucket containing an app used more than a certain frequency. Electronic device.

4. In Claim 3, Priority information for the above one or more apps is obtained based on the list of the above one or more apps being identified from the memory, and The priority of the apps in the above active standby bucket is higher than the priority of the apps in the above working set standby bucket, Electronic device.

5. In Claim 3, Priority information for the above one or more apps is obtained based on the list of the above one or more apps being identified from the memory, and The priority of the apps in the third set above is higher than the priority of the apps in the second set above, and The priority of the apps in the second set above is higher than the priority of the first set above, Electronic device.

6. In Claim 1, Priority information for the above one or more apps is obtained based on the list of the above one or more apps being identified from the memory, and The above one or more apps in the above list include at least one app belonging to an exempted waiting bucket, and At least one app in the above exemption waiting bucket is pre-configured to have a higher priority than other apps in the above list, Electronic device.

7. In Claim 1, The above system update includes regular system updates or updates of modular system components provided by the vendor of the electronic device, and The above system update causes a change in the boot class path (BCP) within the electronic device, and One or more classes related to the above BCP are compiled into native code through at least part of the above optimization operation, Electronic device.

8. In Claim 1, When the above instructions are executed collectively or individually by the at least one processor, the electronic device to perform the optimization operation: Based on the monitoring result of the state of the electronic device, it is determined whether at least one condition related to the state of the electronic device is satisfied, and Based on the determination that at least one condition related to the state of the electronic device is satisfied, an optimization operation is initiated, an optimization operation in progress is maintained, or an optimization operation that is interrupted is resumed, and Causing to stop or cancel an ongoing optimization operation based on a determination that at least one condition related to the state of the electronic device is not satisfied, Electronic device.

9. In Claim 8, The above at least one condition includes a first condition in which the screen of the electronic device is off, a second condition in which the temperature of the electronic device is below a temperature threshold, and a third condition in which the remaining amount of the battery of the electronic device is above a battery threshold. Electronic device.

10. In Claim 1, When the above instructions are executed collectively or individually by the at least one processor, the electronic device: Identify one or more apps on which the above optimization operation will be performed, and Based on the usage frequency of each app, a weight value for each of the above one or more apps is determined, and Generating a list of one or more apps including identification information of each app and the weight value, and Causing a list of the above one or more apps to be stored in the memory, Electronic device.

11. In a method performed by an electronic device; Performing a system update in response to the booting of the above electronic device, and After the above system update, identifying a list of one or more apps from the memory on which an optimization operation is to be performed, and the optimization operation includes converting bytecode associated with the app into executable native code, and Monitoring the status of the above electronic device, and Based on the result of monitoring the state of the electronic device, the method includes performing the optimization operation for each app according to priority information for the one or more apps. method.

12. In Claim 11, The number of one or more apps in the above list is smaller than the total number of apps of the electronic device, and Priority information for one or more of the above apps is determined for each app based on the number of times the app's package is executed and the time the app remains in the foreground while the electronic device's screen is on. method.

13. In Claim 11, The number of one or more apps in the above list is smaller than the total number of apps of the electronic device, and The above list of one or more apps includes at least one of a first set of apps executable by a user of the electronic device, a second set of apps having a profile optimized prior to the system update, and a third set of apps belonging to at least one standby bucket. The above at least one standby bucket includes an active standby bucket containing an app currently in use or a recently used app, and a working set standby bucket containing an app used more than a certain frequency. method.

14. In Claim 13, Priority information for the above one or more apps is obtained based on the list of the above one or more apps being identified from the memory, and The priority of the apps in the above active standby bucket is higher than the priority of the apps in the above working set standby bucket, method.

15. In a non-transient computer-readable storage medium, the non-transient computer-readable storage medium is configured to store instructions that cause an electronic device to perform functions, collectively or individually, when executed by at least one processor, and said functions are: Obtaining information for system updates, and After obtaining information for the above system update, identifying the system update in response to the booting of the electronic device, and Identifying from memory a list of one or more apps for which an optimization operation is to be performed in response to the above system update, and the optimization operation includes converting bytecode associated with the app into executable native code. In response to the above system update, monitoring the status of the electronic device, and Based on the result of monitoring the state of the electronic device, the method includes performing the optimization operation for each app according to priority information for the one or more apps. Non-transient computer-readable storage media.

Images