Patent Description:
With smartphones or other electronic devices gaining higher performance, various services are being offered on electronic devices. For example, more and more applications are coming in wide use to provide more sophisticated services, e.g., Bixby or internet-of-things (IoT), via artificial intelligence (AI) technology. An application program used on such a smart platform is called an application and, when an application is launched, computation may be conducted as resources, e.g., classes, layout, image, or library, are read by the memory. Such launching may require a wait time for the launched application to fully run on the screen. Thus, a screen indicating loading may be displayed on the screen.

Conventional methods are known from <CIT> and and <CIT>.

<CIT> discloses a method and system for delaying starting up of so-called start-up applications, such that a computer, when booted, is ready more quickly. <CIT> discloses a method and system for application prioritization teaching that when a user is interacting with a first application, other processes may be deprioritized.

Recent electronic devices deliver a better performance and thus run applications more seamlessly. However, upon running a high-resource application, it still takes time to launch the application. The launching time may be prolonged due to various computation tasks and resources necessary when the application is initially executed.

An approach to reduce the application launching time is to schedule as many processes, related to the application, as possible in a high-performance central processing unit (CPU). For example, launching target processes related to the launched application may be rendered to operate on a high-performance CPU.

However, as an electronic device is used for a longer time, background-running processes may increase regardless of the launched application. Thus, despite use of a high-performance CPU, the CPU occupancy may be allocated longer for processing the background processes than for processing the launched application-related process. Moreover, turning all the background processes to the freeze state to avoid unnecessary scheduling may cause a malfunction in the electronic device.

Accordingly, an aspect of the disclosure is to provide a method for enhancing the launching speed upon running an application.

In accordance with an aspect of the disclosure, an electronic device is provided as defined by appended claims.

In accordance with another aspect of the disclosure, a method for controlling execution of an application on an electronic device is provided as defined by the appended claims.

In accordance with another aspect of the disclosure, a storage medium storing instructions is provided as defined by the appended claims.

According to various embodiments, the operation of the processes with less dependency upon launching of the application during the application launching period may be restricted, allowing the application launching operation to be done more quickly. Thus, launching speed may be increased, and the launching time the user feels may be shortened.

According to various embodiments, since the processes to be operation-restricted are varied based on the dependency on the application whenever the application runs, operation restriction may be performed more flexibly than in the fixed operation restriction scheme. Further, the application may be executed in a more stable manner.

According to various embodiments, it is possible to increase the launching speed when the application is executed by increasing the priority for the process which is the launching target upon running the application to allow the process to be processed earlier than the other processes.

According to various embodiments, it is possible to prevent a delay in application launching due to an increase in background processes that may be caused by long-term use of the electronic device. Thus, the electronic device may remain in stable performance for a long time.

According to various embodiments, although the system is busy in a certain circumstance, e.g., application update or abnormal operation in the background, the application launching speed may remain constant as in the normal state of the system.

It is to be understood that the singular forms "a", "an", and "the" include plural referents unless the context clearly dictates otherwise.

The terms as used herein are provided merely to describe some embodiments thereof, but not to limit the scope of other embodiments of the disclosure. It is to be understood that the singular forms "a","an", and "the" include plural references unless the context clearly dictates otherwise. All terms including technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the embodiments of the disclosure belong. In some cases, the terms defined herein may be interpreted to exclude embodiments of the disclosure.

The processor <NUM> may execute, e.g., software (e.g., a program <NUM>) to control at least one other component (e.g., a hardware or software component) of the electronic device <NUM> connected with the processor <NUM> and may process or compute various data.

The auxiliary processor <NUM> may control at least some of functions or states related to at least one (e.g., the display device <NUM>, the sensor module <NUM>, or the communication module <NUM>) of the components of the electronic device <NUM>, instead of the main processor <NUM> while the main processor <NUM> is in an inactive (e.g., sleep) state or along with the main processor <NUM> while the main processor <NUM> is an active state (e.g., executing an application).

According to an embodiment, the audio module <NUM> may obtain a sound through the input device <NUM> or output a sound through the sound output device <NUM> or an external electronic device (e.g., an electronic device <NUM> (e.g., a speaker or a headphone) directly or wirelessly connected with the electronic device <NUM>.

The communication module <NUM> may support establishing a direct (e.g., wired) communication channel or wireless communication channel between the electronic device <NUM> and an external electronic device (e.g., the electronic device <NUM>, the electronic device <NUM>, or the server <NUM>) and performing communication through the established communication channel. The wireless communication module <NUM> may identify and authenticate the electronic device <NUM> in a communication network, such as the first network <NUM> or the second network <NUM>, using subscriber information (e.g., international mobile subscriber identity (IMSI)) stored in the SIM <NUM>.

According to an embodiment, the antenna module may include one antenna including a radiator formed of a conductor or conductive pattern formed on a substrate (e.g., a printed circuit board (PCB)). In this case, at least one antenna appropriate for a communication scheme used in a communication network, such as the first network <NUM> or the second network <NUM>, may be selected from the plurality of antennas by, e.g., the communication module <NUM>. According to an embodiment, other parts (e.g., radio frequency integrated circuit (RFIC)) than the radiator may be further formed as part of the antenna module <NUM>.

The first and second external electronic devices <NUM> and <NUM> each may be a device of the same or a different type from the electronic device <NUM>.

Described below in detail is a method for shortening the launching time of the running application to speed up the operation of the process required to launch the application at the system level. To reduce the launching time of an application upon running the application, largely two methods may be adopted, e.g., restricting other unnecessarily running processes than the launching application and maximizing the system operation clock.

Background processes tend to increase in proportion to the use time of the electronic device. Full restriction on the operations of the increasing background processes may cause a malfunction in the electronic device and, thus, so doing is impracticable. Thus, as the background operations increase, the background process may occupy the CPU for a longer time. If some background processes are restricted using a predefined list, the application launching time may rather prolong. For example, since various processes, such as network operation, display operation, or kernel thread, are involved as critical sections upon launching the application, it may be hard to restrict all the background processes.

However, according to an embodiment, the launching speed in execution of an application and stable execution of the application may be achieved by dynamically varying the process that is restricted whenever running the application. To that end, according to an embodiment, a restriction may be imposed on the operation of at least one process based on dependency among a plurality of processes associated with an application upon running the application. As such, the operation of the processes with less dependency upon launching of the application during the application launching period may be restricted, allowing the application launching operation to be done more quickly. Thus, launching speed may be increased, and the launching time the user feels may be shortened.

Meanwhile, the approach of maximizing the system operation clock, although shortening the application launching time, may drastically increase current consumption due to increased processing. Further, in the case where there is a sharp increase in background processes due to a long-term use, application launching may take longer even with an increased operation clock.

However, according to various embodiments, it is possible to increase the launching speed when the application is executed by increasing the priority for the process which is the launching target upon running the application to allow the process to be processed earlier than the other processes. Quick launching may be rendered possible by scheduling higher-priority processes using a high-performance CPU.

The foregoing is described below in detail with reference to <FIG>.

<FIG> is a block diagram (<NUM>) illustrating an electronic device according to an embodiment of the disclosure.

The term "module" used in connection with <FIG> denotes a unit processing at least one function or operation and be implemented in hardware, software, or a combination thereof. Although the term "module" is used in connection with <FIG>, the term may be interchangeably used with "unit," or "device.

Referring to <FIG>, an electronic device <NUM> may include a processor <NUM> and a memory <NUM>. The electronic device <NUM> may correspond to the whole or part of, e.g., the electronic device <NUM> of <FIG>. Although <FIG> illustrates an example in which a dependency determination module <NUM> and a priority determination module <NUM> are included in the processor <NUM>, the respective operations of the dependency determination module <NUM> and the priority determination module <NUM> may be performed under the control of the processor <NUM> or may be performed by the processor <NUM> alone instead of the dependency determination module <NUM> and the priority determination module <NUM>.

The memory <NUM> may store at least one application. The memory <NUM> may store data for a running application, maintaining and managing the application. For example, the application may be launched (or executed) as resources, such as classes, layout, images, or library, are read by the memory <NUM>. The launched application needs a wait time to be fully executed, and such wait time may be referred to as an application launching time.

According to an embodiment, the memory <NUM> may include a dependency DB <NUM> and a priority DB <NUM>. When an application is executed by the dependency determination module <NUM>, a plurality of processes <NUM> associated with the application may be divided into a process that corresponds to a launching target based on dependency on the application and a process that corresponds to a freezing target to be operation-restricted while launching.

The dependency DB <NUM> may include an unfreeze target group <NUM> classified as unfreeze target processes and a freeze target group <NUM> classified as freeze target processes. According to an embodiment, the unfreeze target group <NUM> and the freeze target group <NUM> may store information about processes associated with the application, rather than actual processes. For example, dependency information about each process updated while the application runs may be stored in the dependency DB <NUM>. For example, the process to be operation-restricted and launching target process, upon launching the application, may be determined based on dependency information stored per multiple processes associated with each application.

Meanwhile, the priority DB <NUM> may include a high priority group <NUM> and a low priority group <NUM>. According to an embodiment, the high priority group <NUM> may store information on the process to which a higher priority has been assigned and at least one thread in the process. The low priority group <NUM> may store information about the other threads in the launching target process than the at least one thread to which the higher priority has been assigned. The low priority group <NUM> may also store information about the process that has been operation-restricted during the application launching period.

Referring to <FIG>, although, if application A starts to run, the launching target process <NUM> related to application A needs to be executed, processes with less dependency upon application A may also run in the background. For example, the remaining background processes A, B,. , N (<NUM>, <NUM>, <NUM>) may be background processes that have increased as the electronic device <NUM> is used for a longer time, and these processes may have less dependency upon the application requested to run. Although such processes as Android BG <NUM>, DEX2OAT thread <NUM>, and just-in-time (JIT) thread <NUM>, may be processes that may run during the application launching period, such processes are not the ones that need to be executed during the launching period and may have less dependency upon the application.

Thus, according to an embodiment, restricting the execution of the other less-dependent processes, including the background processes, than the launching target process <NUM> may shorten the launching time of application A. To that end, the dependency determination module <NUM> may identify less-dependent background processes among the background processes running in the background and restrict their operation, and the dependency determination module <NUM> may previously manage the processes irrelevant to the execution of application A during the launching period as freeze targets to be frozen within the launching period.

According to various embodiments, such processes as Android BG <NUM>, DEX2OAT thread <NUM>, and just in time (JIT) thread <NUM> may be previously included in the freeze target group <NUM>. The remaining background processes A, B,. ,N(<NUM>, <NUM>, <NUM>) may be frozen during the launching period of the application requested to run. In other words, the remaining background processes A, B,. ,N(<NUM>, <NUM>, <NUM>) may be added to the freeze target group <NUM> not to be operated during the launching period.

According to an embodiment, the dependency determination module <NUM> may change a froze process back into the unfreeze state according to an event occurring during the application launching while maintaining the freeze state for the other frozen processes until the application launching is complete. For example, for a background process corresponding to the occurrence of an event among the background processes A, B,. ,N(<NUM>, <NUM>, <NUM>) which have been added to the freeze target group <NUM> for which operation restriction is applied during the launching period, the dependency determination module <NUM> may change the freeze state in which operation is restricted into the unfreeze state in which operation restriction is released.

Although, in the above description, the processes to be operation-restricted until the application launching is complete remain in the freeze state, the processes not corresponding to the event may be kept in the freeze state until the application ends.

Thereafter, upon termination of the application, the dependency determination module <NUM> may update the dependency DB including the unfreeze target group <NUM> and the freeze target group <NUM>. For example, the dependency determination module <NUM> may update the dependency DB <NUM> by adding the processes frozen until application launching is complete to the freeze target group <NUM>.

As such, rather than all the processes being frozen during application launching upon running an application on the electronic device <NUM>, at least one process is selectively changed into the freeze state, corresponding to detection of various events, such as a network event or binder call, as well as an external event, e.g., user input. Thus, launching may be accelerated, and any malfunction in the electronic device <NUM> may be prevented.

The binder call is briefly described below.

Android operating system (OS) provides components in process units and may be configured of Linux-based java. Applications running on Android OS may be operated as independent processes on Linux, and applications created by Java may be run on the java virtual machine.

Since all applications are provided in the form of processes, inter-application interactions need a requesting-responding mechanism between processes. Such a mechanism for inter-process communication is the binder. For example, functions provided by other processes in the Android OS system may be provided via the binder.

A binder driver may be used to share the program and data necessary to run an intended service upon executing an application. For example, an application may invoke a system call provided on Linux, performing communication. Thus, data exchange may be performed between different applications or between different services by the binder call.

According to an embodiment, the processor <NUM> may include a dependency determination module <NUM> and a priority determination module <NUM>. The processor <NUM> may determine at least one process to be operation-restricted during the launching period for running the application and restrict the operation of the determined process. The processor <NUM> may monitor the context of the electronic device <NUM> during the launching period and, upon detecting an event, may determine the process for which operation restriction is to be released and release the operation restriction.

As such, the operation restriction on one or more processes corresponding to detection of the event among the operation-restricted processes may be released during the launching period. However, if the launching period ends, i.e., launching is complete, all the operation-restricted processes may be released from operation restriction. For example, since the processes to be operation-restricted are varied based on the dependency on the application whenever the application runs, operation restriction may be performed more flexibly than in the fixed operation restriction scheme. Further, the application may be executed in a more stable manner. Thus, despite frequent application update and various kinds of applications, the optimized application launching may be achieved in the smartphone environment because processes to be operation-restricted may be varied based on dependency upon application. Further, since the processes to be subject to operation restriction are varied and updated whenever the application runs, launching time may be shortened by actively freezing processes with no dependency upon the application.

According to an embodiment, an electronic device <NUM> comprises at least one processor <NUM> and a memory <NUM> storing instructions executed to enable the at least one processor <NUM> to identify a plurality of processes associated with an application, identify at least one process to be operation-restricted during at least partial time of a time of running the application among the plurality of processes, restrict an operation of the at least one identified process during the at least partial time of the time of running the application, and release the operation restriction on at least some of the at least one identified process in response to meeting a preset condition.

According to an embodiment, the preset condition may include a launching time of the application, and the instructions may be configured to enable the at least one processor <NUM> to, when the application launching time elapses, release the operation restriction on the at least one identified process.

According to an embodiment, the preset condition may include detecting at least one event, and the instructions may be configured to enable the at least one processor <NUM> to release the operation restriction on a process corresponding to detection of the at least one event among the at least one identified process.

According to an embodiment, the instructions may be configured to enable the at least one processor <NUM> to identify at least one process to be operation-restricted during the at least partial time of the time of running the application among the plurality of processes based on a dependency on the application.

According to an embodiment, the instructions may be configured to enable the at least one processor <NUM> to add the at least one identified process to an operation restriction group and, in response to the operation restriction group including a process corresponding to detection of at least one event, release from the operation restriction group.

According to an embodiment, the operation restriction group may be updated so that at least some of processes included in the operation restriction group are varied whenever the application runs.

According to an embodiment, the instructions may be configured to enable the at least one processor <NUM> to determine a priority for at least one process except for the at least one identified process among the plurality of processes.

According to an embodiment, the instructions may be configured to enable the at least one processor <NUM> to increase a priority for at least one thread in the at least one process.

According to an embodiment, the instructions may be configured to enable the at least one processor <NUM> to schedule at least one thread in the at least one process higher in priority by a central processing unit (CPU) with a first operation speed and schedule a remaining thread in the at least one process by a CPU with a second operation speed. The first operation speed may be set to be higher than the second operation speed.

According to an embodiment, the instructions may be configured to enable the at least one processor <NUM> to, when the application launching time elapses, change the priority for the at least one thread in the at least one process to an original priority.

The operations of the dependency determination module <NUM> and the priority determination module <NUM> of <FIG> are described below in greater detail with reference to <FIG>.

<FIG> is a view illustrating a detailed configuration of a dependency determination module <NUM> and a priority determination module <NUM> according to an embodiment of the disclosure.

Referring to <FIG>, all the operations of the dependency determination module <NUM> and the priority determination module <NUM> may start corresponding to a user input. For example, a user input may be transferred via the touchscreen to launch (or execute) an application (e.g., application A), and thus, the dependency determination module <NUM> and priority determination module <NUM> may be driven.

According to an embodiment, the dependency and priority may be determined when the application is executed corresponding to a user request. In contrast, if an application irrelevant to the user request runs, the dependency and priority determination may not be performed. For example, if the user accidently runs the application, e.g., screen off, only the database (DB) for at least one of the dependency and priority may be updated without performing operation restriction on one or more processes upon launching. As such, operation restriction may be imposed on one or more processes only for execution of the application which the user has intended to run, i.e., the user's intended application, so that launching may be accelerated, and the launching time the user feels may be shortened. For the user's intended application, the application may occasionally auto-run even without a user input. In the application auto-run context, dependency and priority determination may be carried out, imposing operation restriction on one or more processes.

Specifically, if application A launches corresponding to a user request, the dependency determination module <NUM> may select one or more processes associated with application A and run the selected processes. The one or more processes associated with the application may be related to one or more hardware or software components of the electronic device <NUM>, and the one or more selected processes may be executed by activating the hardware or software components associated with the one or more selected processes.

For example, upon launching of an application run request from the user, an application (e.g., application A) including one or more processes may be executed corresponding to the request. Here, the process that is associated with application A and is actually executed may be called a launching target process.

According to an embodiment, one or more application-associated processes may include launching target processes that need to be executed when driving the application. Here, the processes required to necessarily run when the application is driven may include, e.g., system processes that have no dependency but involve critical system tasks, e.g., execution of application, among the one or more application-associated processes, and such necessary launching target processes may be set as an unfreeze target group.

The one or more application-associated processes may include at least one of graphic processes, network processes, media processes, log processes, or connection processes. Specifically, the graphic processes may be processes necessary for updating the screen of the user interface application, the network processes may be processes necessary for transmission/reception of data to/from the network, the media processes may be processes necessary for outputting videos and audio, the log processes may be processes for gathering log data, and the connection processes may be processes used for communication with external devices.

According to an embodiment, the dependency determination module <NUM> may identify at least one process to be operation-restricted during the execution of the application among the one or more application-associated processes. Here, the application execution period (or time) may be at least part of the time (or duration) during which the application runs.

According to an embodiment, the dependency determination module <NUM> may identify at least one process to be operation-restricted based on the dependency on the application. Thus, the dependency determination module <NUM> may freeze the at least one identified process. To determine whether there is dependency on the application, the dependency DB (e.g., the dependency DB <NUM> of <FIG>) may be referenced. Whenever the application runs, at least some of the processes included in the operation-restricted group may be varied, updating the dependency DB. Thus, the dependency determination module <NUM> may newly determine whether there is dependency whenever the application runs, by the application update or the process for which dependency is varied when the application runs.

According to an embodiment, the dependency determination module <NUM> may manage the at least one identified process, which corresponds to the freeze target, as the freeze target group to be operation-restricted. Thus, the dependency determination module <NUM> may add the at least one identified process to the freeze target group. Here, the freeze target group may also be referred to as an operation-restricted group or non-dependency group including frozen processes.

According to an embodiment, the operation of at least one process identified may be restricted from the application starts until the launching ends. For example, if application launching is complete, the dependency determination module <NUM> may release the operation restriction on the at least one identified process. The dependency determination module <NUM> may update the database while releasing the operation restriction on the at least one identified process that has been managed as the freeze target group. As such, the operation restriction on all the processes that have been operation-restricted simultaneously with the start of application launching may be released at the time of completion of the application launching.

According to an embodiment, the dependency determination module <NUM> may determine whether to release the operation restriction on the at least one process depending on whether an event occurs. The dependency determination module <NUM> may detect whether at least one event occurs during the launching period. For example, if a specific process associated with application A starts, the dependency determination module <NUM> may monitor whether such an event as a binder call by which the specific process requests another process occurs. Based on the monitoring, the dependency determination module <NUM> may identify the dependency between the processes.

Upon receiving at least one event during the launching period, the dependency determination module <NUM> may set the process <NUM> receiving the event, among the one or more application-associated processes, as an unfreeze target and designate the same as the unfreeze target group (<NUM>).

In contrast, the dependency determination module <NUM> may set the processes <NUM> failing to receive such an event as a binder call, among the one or more application-associated processes, as freeze targets <NUM> and add them to the freeze target group <NUM>. Corresponding to setting as the unfreeze target and freeze target, the dependency DB may be updated (<NUM>). In other words, whenever at least one process is designated for the unfreeze targets and freeze targets, the dependency DB may be updated.

Meanwhile, the dependency determination module <NUM> may release the operation restriction on the process corresponding to the detected event among the operation-restricted processes in the freeze target group <NUM> based on at least part of the detected event. Thus, the dependency determination module <NUM> may delete the operation restriction-released process from the freeze target group <NUM> and designate the same as the unfreeze target group.

According to an embodiment, the at least one event may be an event that occurs inside the electronic device <NUM> or is triggered by an external device or user and may include, e.g., external events, e.g., user inputs, as well as at least one of network events or binder calls.

The dependency determination module <NUM> operated as described above may separately manage a plurality of application-associated processes using the unfreeze target group <NUM> and the freeze target group <NUM> in the memory <NUM>. According to an embodiment, the dependency determination module <NUM> may divide the plurality of application-associated processes into the unfreeze target group <NUM> and the freeze target group <NUM> based on the dependency on the application.

According to an embodiment, largely two methods may be considered to shorten the launching time of application upon running the application: a dependency-based scheme of restrict other processes unnecessarily operating than the launching application and a priority-based scheme of maximizing the system operation clock for the launching target process.

According to an embodiment, the dependency-based scheme which is one of the schemes for increasing application launching speed may be a scheme that, when an application runs, turns at least one process less dependent upon the application into the freeze state while the application launches to stop unnecessary scheduling and, at the time of completion of the launching, turns the at least one frozen process back into the unfreeze state. Here, the at least one less-dependent process may be identified by referring to the database (DB) (e.g., the dependency DB <NUM> of <FIG>) for the freeze target group (or operation-restricted group) in the memory <NUM>. When the application, after downloaded, is first executed, the dependency determination module <NUM> may identify the processes to be operation-restricted among the processes associated with the downloaded application by referring to predetermined freezing target processes. According to an embodiment, examples of the predetermined freezing target processes in the freeze target group <NUM> may include, e.g., DEX2OAT <NUM>, just-in-time (JIT) <NUM>, and Android BG <NUM>.

The DEX2OAT <NUM> is a process that is run when an execution file, e.g., APK, is installed and, as the APK is compiled, huge loads may be generated within a short time. The DEX2OAT comes largely in two kinds: internal DEX2OAT and normal DEX2OAT. Since the internal DEX2OAT has a dependency on the application of the launching target, it may be excluded from the freeze targets. In contrast, the normal DEX2OAT, a process executed while the application is updated or installed, has no dependency on the application launching procedure, it may be designated as a freeze target and then be frozen during the launching period.

The JIT <NUM> is a process that previously compiles the hot code frequently used as a compiler to raise the use performance of application. The JIT (<NUM>) compiler serves to previously compile the hot code detected during the application launching with a source code in the form of JAVA bytecode. However, since such compiling is compiling the hot code which is detected during an operation after the application has been launched, rather than while the application is launching, it has no dependency on the launching. Further, since the JIT <NUM> has a large compiling load and memory usage, the dependency determination module <NUM> may previously designate the JIT <NUM> as the freeze target group <NUM> before running the application and freeze it during the launching period.

The Android background (BG) <NUM> is gathering and processing jobs that need not be immediately processed by each Android system server and has no dependency on application launching. Thus, the dependency determination module <NUM> puts the Android BG <NUM> in the freeze target group <NUM> and freezes it during the launching period.

According to an embodiment, as another scheme for increasing the application launching speed, the priority-based scheme may raise the priority of the process, as the launching target, among the plurality of processes associated with the application when the application is launching, and at least one thread in the launching target process and, at the time of completion of the application launching, change the raised priority of the process and thread in the process back into the original priority.

According to an embodiment, the processor <NUM> may process tasks using threads. For example, while each process individually takes up the memory, the plurality of threads may share the memory in the process. The plurality of threads may include a main thread, a worker thread, and a user interface (UI) thread.

The main thread may be allocated or generated per application and may be in charge of tasks recognizable by the user, such as input processing and UI update. Thus, the launching time the user feels may be shortened by setting a high priority for the main thread.

The UI thread may be responsible for the task of requesting a UI component. For example, the UI thread may process a UI update request. Thus, if a high priority is set for the UI thread, the user may see the rapidly launched application screen. As such, the launching time the user feels may be reduced.

The worker thread may deal with huge data and complicated computation. The worker thread may be generated when performing tasks, e.g., storage I/O or network I/O, that require relatively long-term processing, as compared with the tasks handled by the main thread. There may be provided a plurality of worker threads.

According to an embodiment, the priority determination module <NUM>, if application A starts to run, may lower the priorities for processes unrelated to launching among the processes associated with application A while assigning a high priority to the process directly related to the launching. For example, if application A starts to run, the priority determination module <NUM> may determine a priority for the launching target process associated with application A. The launching target process may include at least one thread. By allowing the launching target process and the main thread and UI thread in the launching target process to run quickly, the application launching time the user feels may be shortened.

To that end, according to an embodiment, corresponding to a user input for executing the application, the priority determination module <NUM> may assign a higher priority to the main thread and UI thread <NUM> in the launching target process associated with the application so that they may be executed more rapidly than the operation of the other processes. For example, the UI may be quickly displayed on the screen right after the application is executed by setting a higher priority for the main thread and UI thread upon initial execution of the application so that the launching time the user feels may be shortened. Thus, the priority determination module <NUM> may assign a higher priority to the main thread and UI thread <NUM> in the launching target process and update (<NUM>) the priority DB of application A.

As such, a top priority, e.g., real-time (RT) priority, may be assigned to raise the priority for the main thread and UI thread in the launching target process. To prevent a priority reversion that may occur when the priority for the main thread and UI thread in the launching target process goes up, the RT priority may be assigned to the process communicating with other process to be first processed. Assignment of the RT priority may reduce preemption of CPU scheduling by other tasks and thus increase CPU usage. The high priority-assigned thread may be scheduled to operate on a high-performance CPU.

Since a quick response is needed for the process corresponding to the high-priority group and at least one thread in the process, a CPU (e.g., a high-performance CPU) with a first operation speed may be used to accelerate processing and hence application launching. In contrast, the process corresponding to the low-priority group and at least one thread in the process may be processed with a CPU (e.g., a low-performance CPU) with a second operation speed. Here, the first operation speed may be higher than the second operation speed. Thereafter, when the application launching is complete or the application terminates, the main thread and UI thread in the high priority-assigned target process may go back into their original priority.

As described above, a higher priority may be set, during application launching, for the launching target process among the plurality of processes associated with the application and at least one thread in the launching target process whereas the other processes and at least one thread therein may be assigned a lower priority. For example, the freezing target process and at least one thread in the freezing target process may be assigned a lower priority than that set for the launching target process.

Further, the priority determination module <NUM> may monitor binder communication from the launching target process to the outside and may raise the priority, also, for the process <NUM> of receiving an event, e.g., binder call, thereby updating the priority DB of application A (<NUM>). For example, the process corresponding to reception of the event may be assigned the RT priority to be scheduled earlier than the other processes and, as the occupancy of high-performance CPU increases, quick processing may be possible. In contrast, for processes that lack a binder call with the launching target process, i.e., processes failing to receive the event or the other processes than the ones receiving the event, the priority may be lowered or they may be scheduled with their original priority. Such a low-priority process and at least one thread therein may be operated by a low-performance CPU.

The priority determination module <NUM> may divide at least one launching target process and at least one thread in the launching target process into a low priority group <NUM>, priority no change group <NUM>, and a high priority group <NUM>.

For example, the low priority group <NUM> may include a garbage collect (GC) <NUM>, a log daemon <NUM>, and an Android BG <NUM>. Here, the GC <NUM> may refer to a program that, when the memory is insufficient, releases the memory to be used for other purposes. The log daemon <NUM> may refer to a program that moves system-related tasks to the background.

Thereafter, upon completion of the application launching or termination of the application, the priority determination module <NUM> may update the priority DB (e.g., the DB <NUM> of <FIG>) including the high priority group <NUM> and the low priority group <NUM>. For example, the process which has been in the freeze state until before the application launching is complete and at least one thread in the freezing target process may be added to the low priority group <NUM>, so that the priority DB may be updated.

According to an embodiment, when the application is terminated, the priority determination module <NUM> may change the raised priority of the at least one process and at least one thread in the process back to the original priority. Further, the priority determination module <NUM> may temporarily raise the priority for the process corresponding to an event occurring during the application launching among the plurality of processes associated with the application and at least one thread in the process, during the application launching and, when the application launching is complete or application terminates, change back to the original priority.

<FIG> is a view (<NUM>) illustrating a process of operation restriction on one or more processes when an application runs according to an embodiment of the disclosure.

Referring to <FIG>, reference number <NUM> denotes the time axis which may be divided largely into a start time <NUM> of execution of an application, an application launching period <NUM>, and a release period <NUM> after launching is complete.

First, if the application is executed (<NUM>) corresponding to a user request, in the case of full launch (<NUM>) that poses no restriction on one or more processes based on dependency and priority, background processes and processes unrelated to application launching, as well as application-related launching target processes may be all executed during the launching period.

In contrast, at least one process to be operation-restricted among the one or more application-associated processes may be determined by the dependency and priority determination operation among the processes of the full launch (processes <NUM>). As shown in <FIG>, the processor <NUM> may identify processes <NUM> previously determined to be freeze targets among the plurality of processes <NUM> and background processes A and B <NUM> not related to the application among the background processes based on the dependency on the application. Thus, within the launching period <NUM>, the other processes <NUM> and <NUM> than the background process N <NUM> and the launching target process <NUM> related to the application may be frozen. In other words, the other processes <NUM> and <NUM> may be operation-restricted within the launching period <NUM>.

Thereafter, if the launching period <NUM> ends, i.e., if the launching time elapses, the operation-restricted processes <NUM> and <NUM> may be released from operation restriction. As set forth above, partial restriction launch <NUM> may be performed within the launching period <NUM> and, upon release after the launching period <NUM> (release period <NUM>), the operation-restricted processes <NUM> may be all unfrozen. After the launching period <NUM>, the application may be in the state of running.

<FIG> is a flowchart (<NUM>) illustrating operations of an electronic device for controlling the execution of an application according to an embodiment of the disclosure.

Referring to <FIG>, the operation method may include operations <NUM> to <NUM>. Each operation of the operation method may be performed by at least one of an electronic device (e.g., the electronic device <NUM> or <NUM> of <FIG> or <FIG>) or at least one processor (e.g., the processor <NUM> or <NUM> of <FIG> or <FIG>) of the electronic device. According to an embodiment, at least one of operations <NUM> to <NUM> may be omitted or changed in order or may add other operations.

Referring to <FIG>, the application may start to run, corresponding to a user request, e.g., the user's touch input. Thus, the electronic device <NUM> may determine whether there is an application run request from the user in operation <NUM>.

If there is an application run request, the electronic device <NUM> may identify a plurality of processes associated with the application in operation <NUM>. Then, the electronic device <NUM> may identify at least one process to be operation-restricted during at least part of the time of running the application among the plurality of processes in operation <NUM>. According to an embodiment, the at least part of the time of running the application may include the application launching time.

In operation <NUM>, the electronic device <NUM> may restrict the operation of at least one process identified during the at least part of the time of running the application. According to an embodiment, the at least one process to be operation-restricted during the application launching time may be identified based on dependency upon the application. For example, the processes receiving no event, e.g., binder call, among the plurality of processes may be determined to have no dependency on the application. Thus, the processes that lack binder communication for exchange data between processes may be operation-restricted within the launching period.

According to an embodiment, the at least one identified process may be added to the operation restriction group and may be operation-restricted.

Thereafter, the electronic device <NUM> may identify whether a preset condition is met in operation <NUM>. If the preset condition is met, the electronic device <NUM> may release the operation restriction on at least some of the at least one identified process in response to meeting the preset condition in operation <NUM>. According to an embodiment, if the operation restriction group includes a process meeting the preset condition, the electronic device <NUM> may release the process from the operation restriction group. According to an embodiment, the operation restriction group may be updated so that at least some of processes included in the operation restriction group are varied whenever the application runs.

According to an embodiment, the preset condition may include a launching time of the application, and releasing the operation restriction of the at least some of the at least one identified process may include, if the application launching time elapses, releasing the operation restriction on the at least one identified process.

According to an embodiment, the preset condition may include detecting at least one event, and releasing the operation restriction on the at least some of the at least one identified process may include releasing the operation restriction on a process corresponding to detection of the at least one event among the at least one identified process.

For example, in a case where a contact application is provided by the user, when the contact application launches, a contact DB may be fetched via a binder call from the contact provider process, in which case the contact provider process may be determined to have a dependency on the contact application and may be managed as an uplink transmission power so that it is not frozen when the contact application launches.

As set forth above, with the operation of one or more processes operation-restricted within the application launching time, the electronic device may continuously monitor whether the preset condition is met, until the application launching terminates.

An example of monitoring whether the preset condition is met is described with reference to <FIG>.

<FIG> is a flowchart (<NUM>) illustrating operations of an electronic device based on launching time of an application according to an embodiment of the disclosure.

Operation <NUM> of <FIG>, including operations <NUM> and <NUM> of <FIG>, may correspond to operations <NUM> and <NUM> of <FIG>.

Referring to <FIG>, if the preset condition indicates the application launching time, the electronic device <NUM> may determine whether the application launching time elapses in operation <NUM>. Until before the application launching time elapses, the operation restriction on the at least one identified process may be maintained as in operation <NUM> of <FIG>.

In contrast, if the application launching time elapses in operation <NUM>, the electronic device <NUM> may release the operation restriction on the at least one identified process in response to the elapse of the application launching time in operation <NUM>.

<FIG> is a signal flowchart (<NUM>) for operation restriction on a freezing target process according to an embodiment of the disclosure. <FIG> illustrates DEX2OAT as an example freezing target process.

Referring to <FIG>, if a thread is generated (<NUM>) from the DEX2OAT <NUM>, the dependency determination module <NUM> may determine whether the DEX2OAT <NUM> is the internal DEX2OAT in operation <NUM>. If the DEX2OAT <NUM> is the internal DEX2OAT in operation <NUM>, the dependency determination module <NUM> may exclude it from freeze targets in operation <NUM>. Since the internal DEX2OAT may compile in real-time, it has a dependency on the launching target application and may be excluded from the freeze targets. In contrast, since the normal DEX2OAT is performed when compiled only once upon application installation or update, it has no dependency on the application launching and may thus be added to the freeze targets as in operation <NUM>.

Although the determination on whether it is a freeze target may be performed after the application <NUM> is executed or it may be previously stored in the freeze target group regardless of whether the application <NUM> runs. Thus, if the application <NUM> runs and starts to launch in operation <NUM>, the pre-stored freeze target group may be referenced or executed and then whether it is a freeze target may be determined and, if so, the DEX2OAT <NUM> may be controlled to be frozen in operation <NUM>. Thus, the DEX2OAT <NUM> may remain in the freeze state <NUM> during the launching period <NUM>.

Thereafter, if the launching of the application <NUM> is complete in operation <NUM>, the dependency determination module <NUM> may release the operation restriction on the DEX2OAT <NUM> in operation <NUM>. Then, as the thread in the DEX2OAT <NUM> terminates in operation <NUM>, i.e., as the operation of the DEX2OAT <NUM> is ended, the DB may be updated after the DEX2OAT <NUM> is released from the freeze targets in operation <NUM>. As such, freezing may be maintained only on processes unrelated to the application <NUM> within the launching period <NUM> from the start of launching in operation <NUM> to the termination of the launching in operation <NUM>.

<FIG> is a flowchart (<NUM>) illustrating operations of an electronic device when an event occurs according to an embodiment of the disclosure.

Operations <NUM> to <NUM> of <FIG> are the same as operations <NUM> to <NUM> of <FIG>, and no detailed description thereof is repeated.

Operations <NUM> and <NUM> of <FIG> may correspond to operation <NUM> including operations <NUM> and <NUM> of <FIG>. An example of monitoring whether the preset condition is met in <FIG> is described with reference to <FIG>.

Referring to <FIG>, the electronic device <NUM> may determine whether at least one event is detected in operation <NUM>, with at least one process identified during the launching period operation-restricted. If at least one event is detected, the electronic device <NUM> may release the operation restriction on the process corresponding to detection of the at least one event among the at least one identified process in operation <NUM>. Then, the electronic device <NUM> may determine whether the application launching is terminated in operation <NUM>. If the application launching has not been terminated yet, e.g., until before the launching time elapses, the electronic device may monitor whether the launching time elapses. In contrast, if the application launching is terminated, the electronic device <NUM> may release the operation restriction on the other operation-restricted processes and update the DB in operation <NUM>.

<FIG> is a signal flowchart (<NUM>) illustrating a dependency-based process control procedure upon initially running an application according to an embodiment of the disclosure.

Referring to <FIG>, if a user touch is input (<NUM>) for running an application on the electronic device <NUM>, application launching (<NUM>) may commence. For example, if a plurality of processes associated with the application are processes A, B, C, and D, the application launching <NUM> may be started by the user touch, and dependency determination <NUM> may be performed. If the launching target process is process A <NUM>, and this process is first launched since the application has been installed, because it is before the DB is built up, the dependency determination module <NUM> may, upon initial execution, add processes B, C, and D <NUM>, <NUM>, and <NUM>, except for process A <NUM>, to the freeze target group <NUM> and update the dependency DB <NUM>. Thus, the dependency determination module <NUM> may freeze processes B, C, and D <NUM>, <NUM>, and <NUM> to restrict the operation of processes B, C, and D <NUM>, <NUM>, and <NUM> within the launching period in operation <NUM>. Processes B, C, and D <NUM>, <NUM>, and <NUM> may remain in the freeze states <NUM>, <NUM>, and <NUM> until an unfreeze instruction occurs.

Thereafter, the dependency determination module <NUM> may perform monitoring for detecting an event during the launching period. If a binder call from process A <NUM> to process B <NUM> occurs upon monitoring, the dependency determination module <NUM> may determine (<NUM>) that process B <NUM> has a dependency on process A <NUM>. Thus, the dependency determination module <NUM>, after deleting process B <NUM> from the freeze target group <NUM>, may add process B <NUM> to the unfreeze target group <NUM> and update (<NUM>) the DB. Subsequently, the dependency determination module <NUM> may unfreeze process B <NUM> to release the operation restriction on process B <NUM>, and process B <NUM> may maintain (<NUM>) the unfreeze state corresponding to the unfreeze instruction in operation <NUM>.

Thereafter, if a binder call from process A <NUM> to process C <NUM> occurs upon monitoring, the dependency determination module <NUM> may determine (<NUM>) that process C <NUM> has a dependency on process A <NUM>. Thus, the dependency determination module <NUM>, after deleting process C <NUM> from the freeze target group <NUM>, may add process C <NUM> to the unfreeze target group <NUM> and update (<NUM>) the DB. Further, the dependency determination module <NUM> may unfreeze process C <NUM> in operation <NUM>. Corresponding to this, process C <NUM> may maintain (<NUM>) the unfreeze state corresponding to the unfreeze instruction.

In contrast, if process D <NUM> exchanges no data with process A <NUM> during the launching period, the freeze state <NUM> may be maintained until before the launching ends. Thereafter, if the launching ends (<NUM>), the freeze state of process D <NUM> which used to belong to the freeze target group <NUM> may be released and unfrozen (<NUM>) via dependency determination <NUM>.

Corresponding to the initial execution of the application as described above, processes B and C <NUM> and <NUM> may be managed as included in the unfreeze target group <NUM>, and process D <NUM> may be managed as included in the freeze target group <NUM>.

<FIG> is a signal flowchart (<NUM>) illustrating a dependency-based process control procedure upon re-running an application according to an embodiment of the disclosure.

Referring to <FIG> illustrates the flow of signals when the same application as the one executed in <FIG> runs again. Referring to <FIG>, the dependency determination module <NUM>, if the application previously run re-runs, may be operated based on the dependency DB configured upon the initial execution. For example, the dependency DB configured upon the initial running may include processes B and C <NUM> and <NUM> in the unfreeze target group <NUM> and process D <NUM> in the freeze target group <NUM>.

Thus, if application starts to launch (<NUM>), dependency determination <NUM> may be performed by referring to the dependency DB. Thus, the dependency determination module <NUM> may maintain the unfreeze state for processes B and C <NUM> and <NUM> while freezing process D <NUM> and maintaining (<NUM>) the freeze state in operation <NUM>.

Thereafter, the unfreeze state may be maintained for processes B and C <NUM> and <NUM> corresponding to detection of an event, e.g., binder call, via dependency determination <NUM> and <NUM>. If there is no binder call to process D <NUM> via the dependency determination <NUM> until the time <NUM> of termination of the launching period, the freeze state <NUM> of process D <NUM> may be maintained and, at the time <NUM> of termination of the launching, be unfrozen (<NUM>).

<FIG> is a signal flowchart (<NUM>) illustrating a dependency-based process control procedure upon updating an application according to an embodiment of the disclosure.

The operations of <FIG> are similar to the operations of <FIG> and are thus not described below in detail. , Referring to <FIG> illustrates an example in which as the operation of process A is changed due to application update, the dependency DB is also updated. For example, process A <NUM> may occasionally need to exchange data with process D <NUM>. In this case, the dependency DB of <FIG> may be identical to the dependency DB of <FIG>. For example, the dependency DB may include processes B and C <NUM> and <NUM> in the unfreeze target group <NUM> and process D <NUM> in the freeze target group <NUM>.

After the launching starts (<NUM>), the dependency determination module <NUM> may perform dependency determinations <NUM> and <NUM> of continuously monitoring whether data is exchanged between process A <NUM> and processes B and C <NUM> and <NUM>. If such a circumstance occurs where process A <NUM> needs to exchange data with process D <NUM> within the launching period, e.g., when a binder call from process A <NUM> to process D <NUM> occurs via dependency determination <NUM>, the dependency determination module <NUM> may unfreeze (<NUM>) process D <NUM>, and the freeze state <NUM> of process D <NUM> may thus be released. Subsequently, the dependency determination module <NUM> may control to move process D <NUM> from the freeze target group <NUM> to the unfreeze target group <NUM> via the dependency DB <NUM>. Thus, until before the launching ends, process D <NUM> may remain in the unfreeze state <NUM>.

Thereafter, when the launching ends (<NUM>), the DB may be updated to allow the unfreeze target group <NUM> to include processes B, C, and D <NUM>, <NUM>, and <NUM>.

Thus, if the application is re-run later, the dependency determination module <NUM> may freeze processes B, C, and D <NUM>, <NUM>, and <NUM> not to be operation-restricted within the launching period based on the updated DB. Unlike this, if the non-occurrence of a binder call with process B <NUM> persists, during the launching period, until the launching terminates, the dependency determination module <NUM> may designate process B <NUM> as in the freeze target group <NUM> and update the DB. Thus, if the application runs again, the dependency determination module <NUM> may freeze process B <NUM> during the launching period based on the updated DB. As such, since the freeze target group in the dependency DB is updated so that at least some of the processes included in the freeze target group are varied whenever the application runs, even when the application is frequently updated, the process to be adaptively operation-restricted within the launching period may be identified and, thus, an application launching speed may be ensured.

<FIG> is a flowchart (<NUM>) illustrating operations of an electronic device based on priority according to an embodiment of the disclosure.

Referring to <FIG>, the electronic device <NUM> may assign a higher priority to the other processes than the at least one identified process and at least one thread in the processes in operation <NUM>. For example, if higher priorities are assigned to all of the remaining processes, priority reversion or priority conflict may occur with other processes. Thus, a higher priority may be assigned to at least one process. Since at least one process includes at least one thread, such as main thread, UI thread, or worker thread, a priority may be determined also for at least one thread in the at least one process.

For example, the electronic device <NUM> may assign the top priority, e.g., the RT priority, to the main thread and UI thread that needs to first be processed.

Then, in operation <NUM>, the electronic device <NUM> may restrict the operation of the at least one identified process while running the application and assign a lower priority. For example, the at least one identified process may be assigned a lower priority not to be operated within the launching period. Or, the electronic device <NUM> may control to schedule it with a low-performance CPU so that a specific operation in the process may be performed within the launching period although assigned a lower priority. As such, the electronic device <NUM> may control the process assigned a lower priority and at least one thread in the process to be scheduled with the low-performance CPU.

As such, according to an embodiment, the electronic device <NUM> may assign a higher priority to at least one process except for the at least one identified process among the plurality of processes associated with the application and at least one thread in the at least one process.

According to an embodiment, the electronic device <NUM> may perform scheduling at least one thread in the at least one process to which the higher priority has been assigned by a CPU with a first operation speed and scheduling a remaining thread in the at least one process by a CPU with a second operation speed. According to an embodiment, the first operation speed may be set to be higher than the second operation speed.

In operation <NUM>, the electronic device <NUM> may determine whether at least one event is detected. If at least one event is detected, the electronic device <NUM> may release the operation restriction on the process corresponding to at least part of the detected event among the at least one identified process and assign a higher priority to it in operation <NUM>. In contrast, if the at least one event is not detected, the electronic device <NUM> may go back to operation <NUM>.

Then, the electronic device <NUM> may determine whether the application launching is terminated in operation <NUM>. The above-described operations may be maintained until the application launching terminates. In contrast, if the application launching is terminated as a result of determination in operation <NUM>, the electronic device <NUM> may release the operation restriction on the operation-restricted processes and turn back to the original priority, then update the DB in operation <NUM>.

As set forth above, according to an embodiment, if the application launching time elapses, the electronic device <NUM> may turn the raised priority of the at least one process and at least one thread in the at least one process back to the original priority.

<FIG> is a view (<NUM>) illustrating a launching target process control procedure based on priority according to an embodiment of the disclosure.

Referring to <FIG>, it illustrates an example in which the application-associated launching target process (e.g., process A) <NUM> includes a main thread <NUM>, a UI thread <NUM>, and a plurality of worker threads #<NUM>, #<NUM>,. , #N (<NUM>, <NUM>, <NUM>). The main thread <NUM> and UI thread <NUM> of the launching target process (e.g., process A) <NUM> need to first be executed without falling behind other process operations.

Thus, the priority determination module <NUM> may change (<NUM>) the priority of the main thread <NUM> and UI thread <NUM> into the RT priority so as to assign a higher priority to the main thread <NUM> and UI thread <NUM> at the time of application launching along the time axis <NUM>. As such, by assigning the RT priority, longer CPU occupancy is possible, leading to quick processing. Further, the thread assigned the RT priority may be scheduled (<NUM>) with a high-performance CPU for rapid processing.

Thereafter, at the time of termination of application, the priority determination module <NUM> may restore (<NUM>) the changed priority. Here, the time of termination of the application may denote the time of completion of the application launching.

Although <FIG> illustrates an example of raising the priority for at least one thread in the launching target process, the priority for the process corresponding to detection of an event, e.g., binder call, may also be raised. For example, the priority determination module <NUM> may designate the process receiving a binder call from the launching target process as the high priority group while designating the process failing to receive a binder call as the low priority group. A normal priority may be assigned to newly generated processes and processes that do not belong to the priority DB.

<FIG> is a view (<NUM>) illustrating a process control procedure based on priority according to an embodiment of the disclosure.

Referring to <FIG>, if a user touch is input (<NUM>) for running an application on the electronic device <NUM>, application launching (<NUM>) may commence. For example, if a plurality of processes associated with the application are processes A, B, C, and D, the application launching <NUM> may be started by the user touch, and priority determination <NUM> may be performed. If the launching target process is process A <NUM>, and process A <NUM> is related to processes B and C <NUM> and <NUM>, when the application launching <NUM> begins, the priority determination module <NUM> may add processes B and C <NUM> and <NUM> to the high priority group <NUM> and process D <NUM> to the low priority group <NUM>, thereby updating (<NUM>) the DB. If there is an already built-up database including the high priority group <NUM> which includes processes B and C <NUM> and <NUM>, and the low priority group <NUM> includes process D <NUM>, the priority determination module <NUM> may assign a lower priority to process D <NUM> in operation <NUM>.

Thus, process D <NUM> may be partially operation-restricted during the launching period due to its low priority and, even within the launching period, if some specific operation needs to be performed for binder communication with process A, it may be scheduled (<NUM>) with a low-performance CPU. As such, since process D <NUM> is not related to process A <NUM>, the priority of process D <NUM> may be changed into a lower priority at the time of launching.

Thereafter, although process D <NUM> needs to be operated during the launching period, it may be assigned a low-performance CPU and scheduled (<NUM>) according to the lower priority. For example, examples of process D <NUM> assigned a lower priority may include log daemon, garbage collection (GC), and Android BG and be restricted to operate on a low-performance CPU.

In contrast, during the period where priority determination is performed, e.g., a period of monitoring an event, e.g., binder call from process A <NUM> to process B <NUM> or from process A <NUM> to process C <NUM> as in operations <NUM> and <NUM>, the priority for process B <NUM> and process C <NUM> may be changed into a higher priority, e.g., the RT priority as in operations <NUM> and <NUM>. Thus, processes B and C <NUM> and <NUM> may be assigned a high-performance CPU and be thus quickly operated.

Thereafter, if the launching is terminated in operation <NUM>, the priority for processes B and C <NUM> and <NUM> and the priority for process D <NUM> may be turned back to the original priorities in operation <NUM>. In this case, since the DB is updated whenever the priority changes, although the priorities are turned back to the original priorities, information about the change in priority for the application-associated process and at least one thread in the process may be cumulatively managed. As such, whenever the application runs, at least one process and at least one thread in the process may be classified into a high priority group and a low priority group, and the priority DB may be managed. Thus, rapid application launching based on adaptively changing priority may be ensured not only for applications that are frequently updated but also for other various kinds of applications.

For example, since binder communication from the main thread of process A <NUM> of application to the Android system and another process is directly associated with the launching time, it may be assigned an RT priority to be first processed, thus shortening the launching time.

As used herein, each of such phrases 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 include all possible combinations of the items enumerated together in a corresponding one of the phrases. As used herein, such terms as "1st" and "2nd" or "first" and "second" may be used to simply distinguish a corresponding component from another, and does not limit the components in other aspect (e.g., importance or order). It is to be understood that if an element (e.g., a first element) is referred to, with or without the term "operatively" or "communicatively", as "coupled with", "coupled to", "connected with" or "connected to" another element (e.g., a second element), it means that the element may be coupled with the other element directly (e.g., wiredly), wirelessly, or via a third element.

In such a case, according to various embodiments, the integrated component may perform one or more functions of each of the plurality of components in the same or similar manner as they are performed by a corresponding one of the plurality of components before the integration.

According to an embodiment, there is provided a storage medium storing instructions, the instructions configured to, when executed by at least one process, enable the at least one processor to perform at least one operation, the at least one operation comprising identifying a plurality of processes associated with an application, identifying at least one process to be operation-restricted during at least partial time of a time of running the application among the plurality of processes, restricting an operation of the at least one identified process during the at least partial time of the time of running the application, and releasing the operation restriction on at least some of the at least one identified process in response to meeting a preset condition.

Claim 1:
An electronic device (<NUM>, <NUM>), comprising:
at least one processor (<NUM>, <NUM>); and
memory (<NUM>, <NUM>) for storing instructions that, when executed by the at least one processor (<NUM>, <NUM>) individually or collectively, cause the electronic device (<NUM>, <NUM>) to:
in response to receiving an input for executing (<NUM>) an application, identify (<NUM>) a plurality of processes (<NUM>, <NUM>) based on dependency on the application,
based on the identified plurality of processes, identify (<NUM>) at least one process among the identified plurality of processes to be operation-restricted during at least a portion of a time of running the application (<NUM>),
restrict (<NUM>) the operation of the identified at least one process during the at least the portion of the time of running the application (<NUM>), and
release (<NUM>) the operation-restriction on at least some of the identified at least one process, when a preset condition is met.