Method and apparatus for identifying thread associated with UI responsiveness of application

Abstract

An electronic apparatus according to an embodiment of the present disclosure may be configured to: acquire TID information of a first thread configured to process a task related to rendering for displaying a UI; on the basis of the TID information, identify whether or not the first thread belongs to a process of an application associated with the top window from among at least one window displayed on a screen; and on the basis of identifying that the first thread belongs to the process of the application associated with the top window, include, in a thread list associated with a UI operation of the application, the first thread and a second thread that belongs to the same process as the first thread and is configured to process a task related to the UI. Threads included in the thread list associated with the UI operation may be configured to have applied thereto scheduling configurations different from at least one thread that belongs to the process and is not included in the thread list associated with the UI operation.

Description

Method and device for identifying threads associated with UI responsiveness of an application

[0001] The present disclosure relates to a method and apparatus for identifying a thread associated with UI responsiveness of an application.

[0002] As technology advances and advances, electronic devices can offer a variety of functions beyond their original functionality. For example, a television (TV) can not only display broadcast channels, but also run applications, access websites, and communicate with other electronic devices.

[0003] Electronic devices, such as TVs, can provide a multiprocess environment where multiple processes can be executed. In such devices, scheduling can be performed to efficiently allocate and manage resources. Typically, scheduling can be performed on an application-by-application basis. For example, the same scheduling policy can be applied to all threads within an application's process, and the priorities of these threads can be adjusted collectively.

[0004] However, within an application process, threads associated with UI responsiveness coexist with threads unrelated to UI responsiveness. Therefore, applying the same scheduling policy to all of them or adjusting their priorities uniformly can lead to threads associated with UI responsiveness not receiving sufficient CPU resources when CPU (central processing unit) contention occurs. This degrades UI responsiveness.

[0005] Therefore, to improve UI responsiveness, a method is needed to identify threads associated with UI responsiveness within the application's process and apply separate scheduling settings to the identified threads.

[0006] An electronic device according to one embodiment of the present disclosure comprises: a memory storing at least one program; And at least one processor electrically connected to the memory and configured to execute at least one instruction of a program stored in the memory, wherein the at least one processor includes processing circuitry, and is configured to individually and / or collectively: obtain thread ID (TID) information of a first thread configured to process a task related to rendering for displaying a user interface (UI), and identify, based on the TID information, whether the first thread belongs to a process of an application associated with a top window among at least one window displayed on a screen, and include, based on the identification that the first thread belongs to the process of the application associated with the top window, the first thread and a second thread belonging to the same process as the first thread and configured to process a task related to the UI in a thread list associated with a UI operation of the application, wherein the threads included in the thread list associated with the UI operation may be configured to have different scheduling settings applied to at least one thread belonging to the process and not included in the thread list associated with the UI operation.

[0007] According to one embodiment of the present disclosure, a method of an electronic device includes: acquiring thread ID (TID) information of a first thread set to process a task related to rendering for displaying a user interface (UI); identifying, based on the TID information, whether the first thread belongs to a process of an application associated with a top window among at least one window displayed on a screen; and including, based on the identification that the first thread belongs to the process of the application associated with the top window, the first thread and a second thread that belongs to the same process as the first thread and is set to process a task related to the UI in a thread list associated with a UI operation of the application, wherein threads included in the thread list associated with the UI operation may be set to have different scheduling settings applied to at least one thread that belongs to the process and is not included in the thread list associated with the UI operation.

[0008] FIG. 1 is a graph illustrating task processing delay caused by CPU contention according to one embodiment of the present disclosure.

[0009] FIG. 2 is a graph illustrating a context switch delay that may occur depending on a scheduling method according to one embodiment of the present disclosure.

[0010] FIG. 3 is a diagram illustrating an example of an electronic device according to one embodiment of the present disclosure.

[0011] FIG. 4A is a signal flow diagram illustrating an operation of an electronic device processing user input for an application according to one embodiment of the present disclosure.

[0012] FIGS. 4b and 4c are diagrams illustrating a screen including multi-views and a layout relationship of windows corresponding to the multi-views according to one embodiment of the present disclosure.

[0013] FIG. 5 is a system architecture diagram for CPU scheduling of an electronic device according to one embodiment of the present disclosure.

[0014] FIG. 6 shows an example of a scheduling method applied to an application according to one embodiment of the present disclosure.

[0015] FIG. 7 is a flowchart illustrating an operation of selecting a thread related to a UI operation according to one embodiment of the present disclosure.

[0016] FIG. 8 is a flowchart illustrating the operation of an application for selecting a thread related to a UI operation according to one embodiment of the present disclosure.

[0017] FIG. 9 is a flowchart illustrating the operation of a window manager for selecting a thread related to a UI operation according to one embodiment of the present disclosure.

[0018] FIG. 10 is a flowchart illustrating the operation of a booster module for selecting threads related to UI operations according to one embodiment of the present disclosure.

[0019] FIG. 11 is a signal flow diagram illustrating a procedure for selecting a thread related to a UI operation according to one embodiment of the present disclosure.

[0020] FIG. 12 is a flowchart illustrating an operation of registering a thread associated with a UI operation according to one embodiment of the present disclosure.

[0021] FIG. 13 is a flowchart illustrating an operation for requesting registration for a thread associated with a UI operation, according to one embodiment of the present disclosure.

[0022] FIG. 14 is a flowchart illustrating an operation of operating a list of threads associated with UI operations according to one embodiment of the present disclosure.

[0023] FIG. 15 is a diagram illustrating an effect of improving UI responsiveness according to one embodiment of the present disclosure.

[0024] FIG. 16 is a block diagram of an electronic device according to one embodiment of the present disclosure.

[0025] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings so that those skilled in the art can easily implement the present disclosure. However, the present disclosure may be implemented in various different forms and is not limited to the embodiments described herein. In connection with the description of the drawings, the same or similar reference numerals may be used for identical or similar components. Furthermore, in the drawings and related descriptions, descriptions of well-known functions and configurations may be omitted for clarity and conciseness.

[0026] In electronic devices, user interface (UI) responses can be delayed when the system is busy, such as during a cold boot. One of the many causes of this phenomenon is central processing unit (CPU) contention. CPU contention refers to the competition for CPU resources among multiple processes (or threads). Due to CPU contention, multiple processes may not be allocated the required amount of CPU resources. Processes or threads that are not allocated the required amount of CPU resources may have to wait until they are allocated the required amount of CPU resources. This may delay the processing of tasks associated with the processes or threads.

[0027] FIG. 1 is a graph illustrating task processing delay caused by CPU contention according to one embodiment of the present disclosure.

[0028] Referring to FIG. 1, a process (or thread) that is not allocated a resource in CPU contention may have its task processing delayed until the resource is allocated. For example, if a task associated with a process (or thread) has a processing time (or work time) (102) of 0.1 seconds and waits for 1 second until the resource is allocated in CPU contention, the processing of the task may be completed after 1.1 seconds have elapsed. In other words, the time for the task to be processed may be delayed by the delay time (104) of 1 second. The delay in processing a task may cause inconvenience to the user. For example, if the task is related to processing key inputs from a TV remote control, the user may feel inconvenience due to a delay in the response to the key inputs from the TV remote control.

[0029] To achieve more efficient CPU resource allocation, various CPU resource management methods can be utilized. For example, the Linux kernel can utilize real-time scheduling (hereinafter referred to as "Real-Time (RT) scheduling") and the Completely Fair Scheduler (CFS) scheduling method.

[0030] RT scheduling is a scheduling method for preempting CPU resources based on priorities, and can be used, for example, by the Real-Time scheduler or the O(1) scheduler. RT scheduling can be used for real-time tasks with the highest priority. RT scheduling can use a FIFO (first in first out or first come first served) policy, which allocates CPU resources to the process (or thread) that is ready first, or a round robin policy, which allows processes (or threads) to use CPU resources in order.

[0031] The CFS scheduling scheme is a scheduling scheme for fairly allocating CPU resources and can be utilized, for example, by the CFS scheduler. CFS scheduling can be utilized for tasks with lower priorities than real-time tasks. CFS scheduling can be used to allocate CPU resources to processes (or threads) within each control group (Cgroup) based on CPU resource usage determined for each control group (Cgroup). A round-robin policy can be utilized in CFS scheduling.

[0032] FIG. 2 is a graph illustrating context switch latency that may occur depending on a scheduling method according to one embodiment of the present disclosure.

[0033] Referring to FIG. 2, the context switch delay that may occur when the CFS scheduling method (210) is used may be longer than the context switch delay that may occur when the Real-Time (RT) scheduling method (220) is used.

[0034] Context switch latency can refer to the time delay that occurs during a process switch. For example, context switch latency can represent the time it takes for a process in a waiting state to wake up.

[0035] For example, when the CFS scheduling method (210) is used, the actual process wake-up (204) may occur 57.47 us after the required wake-up time (202). Therefore, when the CFS scheduling method (210) is used, a context switch delay of 57.47 us may occur.

[0036] For example, when the RT scheduling scheme (220) is used, the actual process wake-up (206) may occur 7.91 us after the required wake-up time (202). Therefore, when the RT scheduling scheme (220) is used, a context switch delay of 7.91 us may occur.

[0037] The CFS scheduling method (210) can prevent CPU starvation by ensuring that CPU resources are used fairly among processes (or threads). CPU starvation can refer to a state in which a specific process (or thread) cannot use CPU resources because other processes (or threads) are occupying the CPU resources. The CFS scheduling method (210) has a relatively long context switch delay and does not guarantee that CPU resources are always used, so it can be used for tasks that require long periods of time to be performed.

[0038] The RT scheduling method (220) can ensure that the context switch delay is relatively short and that CPU resources are used until the process transitions to a sleep state on its own. Therefore, the RT scheduling method (220) can be easily used for real-time tasks. Since the RT scheduling method (220) can cause a CPU starvation state in which other processes (or threads) cannot use the CPU, it can be used for tasks that require execution in a short period of time.

[0039] The CFS scheduling method (210) and the RT scheduling method (220) can be used together in a single operating system (OS). For example, by allocating resources to a process (or thread) associated with media (e.g., video or audio) playback based on the RT scheduling method (220), CPU usage can be guaranteed and interruption in media playback can be prevented. Resources can be allocated to a process (or thread) associated with an application running in the foreground based on the CFS scheduling method (210). For example, by allocating the process (or thread) to a control group that can use slightly more CPU resources than other processes (or threads), the application can be run smoothly.

[0040] FIG. 3 is a diagram illustrating an example of an electronic device according to one embodiment of the present disclosure.

[0041] Referring to FIG. 3, the electronic device (310) may be a display device such as a TV, but is not limited thereto. For example, the electronic device (310) may be a tablet PC, a mobile phone, or any other type of device capable of providing services based on various applications.

[0042] According to one embodiment, the electronic device (310) can perform wired and / or wireless communication with at least one external electronic device (320). According to one example, the electronic device (310) can perform wired communication with at least one external electronic device (320) using a cable (e.g., a high-definition multimedia interface (HDMI) cable). According to one example, the electronic device (310) can perform wireless communication with at least one external electronic device (320) based on various wireless communication technologies (e.g., wireless fidelity (Wi-Fi), Bluetooth, long term evolution (LTE), LTE-A (LTE advance), or new radio (NR) communication technologies).

[0043] According to one embodiment, at least one external electronic device (320) may be, for example, a mobile terminal such as a tablet PC or a mobile phone. The at least one external electronic device (320) is not limited to one, as illustrated in FIG. 3, and may be two or more.

[0044] According to one embodiment, the electronic device (310) may perform infrared (IR) communication or radio frequency (RF) communication with a remote controller (330). The remote control device (330) may be referred to as a remote controller or a remote control, and may include various input units (e.g., key buttons, switches, wheels, or touch screens) for controlling the electronic device (310). The remote control device (330) may transmit a control signal for controlling the electronic device (310) to the electronic device (310) based on a user input through the various input units. According to one example, the control signal may include at least one of a control signal for turning the electronic device (310) on or off, a control signal for changing a broadcast channel, a control signal for adjusting the volume, a control signal for executing or terminating an application, or a control signal for changing settings related to the electronic device (310).

[0045] According to one embodiment, the electronic device (310) may include one or more applications. For example, the electronic device (310) may include at least one application that provides multimedia content (e.g., an over-the-top (OTT) application). The electronic device (310) may display the multimedia content provided by the application on a screen. For example, the electronic device (310) may display the multimedia content provided by each application on a single screen.

[0046] FIG. 4A is a signal flow diagram illustrating an operation of an electronic device processing user input for an application according to one embodiment of the present disclosure. FIGS. 4B and 4C are diagrams illustrating a screen including multiple views and a layout relationship of windows corresponding to the multiple views according to one embodiment of the present disclosure.

[0047] In operation 4010, the electronic device (310) may receive a user input for an application (430) from an external device (e.g., the external electronic device (320) or remote control device (330) of FIG. 3) via an input interface (410) (e.g., the first communication interface (1608) of FIG. 16 or the second communication interface (1608) of FIG. 16). For example, the user input may be a touch input corresponding to the application (430) received from the external electronic device (320). For example, the user input may be a key input corresponding to the application received from the remote control device (330).

[0048] According to one embodiment, user input for the application (430) may be, for example, a user input corresponding to an event of executing (or re-executing) or selecting the application. For example, user input for the application (430) may be a user input corresponding to an event of executing or selecting the application (430) through a view corresponding to the application displayed on the screen. The electronic device (310) may provide a UI corresponding to the user input.

[0049] According to one embodiment, a view corresponding to an application (430) may be displayed on the screen. For example, multiple views corresponding to multiple applications may be displayed on a single screen. For example, as illustrated in parts (a) of FIG. 4b and (a) of FIG. 4c , a first view (View 1) corresponding to a first application, a second view (View 2) corresponding to a second application, a third view (View 3) corresponding to a third application, and / or a fourth view (View 4) corresponding to a fourth application may be displayed on a single screen. Each view may include content of the corresponding application.

[0050] According to one embodiment, a view corresponding to an application (430) may be displayed on the screen through an associated window. For example, a first view corresponding to a first application may be displayed on the screen through a first window, a second view corresponding to a second application may be displayed on the screen through a second window, a third view corresponding to a third application may be displayed on the screen through a third window, and a fourth view corresponding to a fourth application may be displayed on the screen through a fourth window.

[0051] In one embodiment, each window may have a different layer. For example, as illustrated in part (b) of FIG. 4B, a second window (401b) containing a second view may be positioned in the top layer as a top-level window, a first window (402b) containing a first view may be positioned in the layer immediately below the top-level layer, a third window (403b) containing a third view may be positioned in the layer below that, and a fourth window (403c) containing a fourth view may be positioned in the bottom layer as a top-level window. The top-level window or top-level layer may correspond to the window or layer positioned closest to the screen, and the bottom-level window or bottom-level layer may correspond to the window or layer positioned farthest from the screen. In the present disclosure, a window set as a top-level window may also be referred to as a focused window.

[0052] In one embodiment, the areas where the corresponding views are displayed in each window do not overlap each other, and the areas excluding the areas where the corresponding views are displayed can be made transparent. This allows the views displayed in each window to be displayed to the user on a single screen, even when the windows are placed on different layers.

[0053] According to one embodiment, the layer arrangement settings of a window may be changed according to a user input. When a user input corresponding to an event of executing or selecting an application (430) is received, the electronic device (310) (or the window manager (420) of the electronic device (310)) may set the window corresponding to the selected or executed application (430) as the topmost window. For example, as illustrated in part (b) of FIG. 4B, when a second application corresponding to a second view is selected or executed by a user input, a second window (401b) corresponding to the second application may be arranged as the topmost window. For example, as illustrated in part (c) of FIG. 4C, when a first application corresponding to a first view is selected by a user input while a second application corresponding to a second view is selected, the topmost window may be changed from the second window (402c) to the first window (401c). In this case, the second window (402c), which was previously the topmost window, can be placed as a lower layer of the topmost window (e.g., the immediately next lower layer).

[0054] In operations 4020 and 4030, the electronic device (310) may transmit the received user input to the application (430) through the window manager (420). When the user input is transmitted, the electronic device (310) (or the application of the electronic device (310)) may store an event corresponding to the user input in a memory (e.g., a main queue) and wait for processing of the event. According to one embodiment, the window manager (420) may be included in a platform (e.g., the platform (504) of FIG. 5). For example, a separate window manager may be included for each platform.

[0055] According to one embodiment, the window manager (420) can manage the window(s) displayed on the screen (e.g., the current screen). For example, the window manager (420) can manage a window stack including data of the window(s) displayed on the current screen. The window data may include, for example, information about the process of the application corresponding to the window (e.g., PID information of the process) and / or information about the view displayed on the window. The window stack can sequentially store data of the topmost window to the bottommost window. For example, data of the topmost window may be stored at the topmost position on the window stack, and data of the bottommost window may be stored at the bottommost position on the window stack, but is not limited thereto. For example, the opposite may also be possible, and various methods are possible.

[0056] Meanwhile, the settings of the above-described windows and the views displayed in the windows can be controlled by the window manager (420). The window manager (420) can provide various types of window and view settings, not limited to the examples described above, based on application requests, user input, and / or system settings. For example, multiple windows corresponding to multiple applications can be arranged in the same layer. For example, multiple windows can be assigned to a single application, or a single window can be assigned to multiple applications.

[0057] In operation 4040, the electronic device (310) (or the application (430) of the electronic device (310)) may obtain an event corresponding to a user input from memory (e.g., a main queue). For example, if CPU resources are allocated to a thread (e.g., a UI thread or a main thread) that initiates processing of an event corresponding to a user input, the electronic device (310) may obtain the corresponding event from the main queue.

[0058] In one example, the electronic device (310) (or UI thread) may trigger a UI display / rendering request (or UI draw request) for processing an event corresponding to user input.

[0059] In operation 4050, the electronic device (310) (or the application (430) of the electronic device (310)) may perform processing to display a user interface (UI) corresponding to the event on the screen. For example, if CPU resources are allocated to a thread (e.g., a renderer thread) that performs rendering processing of the event, the electronic device (310) may perform rendering processing to display a UI corresponding to the event on the screen.

[0060] For example, when an event for selecting a second application is identified, as illustrated in part (a) of FIG. 4b, the electronic device (310) (or renderer thread) may perform rendering processing to display a user interface (440b) (e.g., a button for increasing or decreasing the sound) for increasing or decreasing the sound of the content of the second application on the second view of the second window (401b). As illustrated in part (b) of FIG. 4b, the second window (401b) corresponding to the currently selected or executed application (430) may be set as the topmost window before or after the rendering processing.

[0061] For example, when an event for selecting a first application is identified, as illustrated in part (a) of FIG. 4c, the electronic device (310) (or renderer thread) may perform rendering processing to display a user interface (440c) (e.g., a play button, a forward button, a backward button) for controlling a playback operation of the content of the first application on the first view of the first window (401c). As illustrated in part (b) of FIG. 4c, the first window (401c) corresponding to the currently selected or executed application (430) may be set as the topmost window before or after the rendering processing.

[0062] FIG. 5 is a system architecture diagram for CPU scheduling of an electronic device according to one embodiment of the present disclosure.

[0063] Referring to FIG. 5, a system for CPU scheduling of an electronic device (310) may include an application (502) (e.g., application (430) of FIG. 4A), a platform (504), and a kernel (506).

[0064] The application (502) may be referred to as an APP or may be associated with a service. The application (502) may include a software program that is executed by a user's selection. In one example, the application (502) may be executed by a user's selection using at least one external device (320) or a remote control device (330). In one example, the application (502) is executed based on the OS and may or may not be displayed on the screen of the electronic device (310). The application (502) may provide various services such as media playback. In one example, the application (502) may include a home application (512) that is displayed on the screen of the electronic device (310) after a cold boot. In one example, the home application (512) may be an application that provides a UI for at least one of application selection, website search, broadcast channel selection, or external device connection.

[0065] The platform (504) may be associated with an operating system (OS) and may provide an environment for executing applications (502). The platform (504) may access hardware through the kernel (506) and perform control group assignment, control group change or movement, CPU resource assignment, or process management operations associated with services. In one example, the platform (504) may include a web application service (WAS) (522), an application management daemon (AMD) (524), a boost daemon (or booster module) (526), ​​and a service process (or process) (528). In one example, the platform (504) may include a window manager (e.g., window manager (420) of FIG. 4A).

[0066] WAS (522) can perform operations to provide web-based application services. AMD (524) can manage the execution of the application (502) and the life cycle of the application (502) (e.g., app creation (create), app execution / resume (resume), app pause (pause), app termination (terminate). When an event corresponding to the life cycle of the application (502) occurs, AMD (524) can provide information about the process of the application (502) to the boost daemon (526).

[0067] The Boost Daemon (526) may perform CPU scheduling and / or CPU resource management. In one example, the Boost Daemon (526) may include an App Status Listener (530), a Service Booster (532), a Netlink Handler (534), and a Booster Manager (536).

[0068] The app status listener (530) can receive events related to the life cycle of the application (502). The service booster (532) can manage the CPU resource allocation of the service process (528). The netlink handler (534) can receive events related to the life cycle of the process. The booster manager (536) can set CPU policies (or CPU scheduling methods), allocate control groups, determine resource allocation ratios, or set CPU resource allocation priorities.

[0069] A service process (528) may provide functions necessary for the operation of a service (or application). There may be one or more service processes (528).

[0070] The kernel (506) can manage hardware and provide services required for the platform (504). The kernel (506) can include a Netlink (542), a Cgroup (544), and a RealTime Scheduling (RTS) unit (546).

[0071] Netlink (542) can provide events related to the life cycle of a process of an application (502), such as a process fork event, a process execute event, or a process exit event. Cgroup (544) can provide a CPU resource distribution function. The real-time scheduling unit (546) can perform real-time scheduling to preempt CPU resources.

[0072] The operations related to CPU scheduling of the application (502) can be performed as follows through the boost daemon (526) and kernel (506) of FIG. 5.

[0073] When the process of the application (502) is forked, the netlink (542) of the kernel (506) may provide a process fork event to the boost daemon (526). The boost daemon (526) may receive a process fork event (or application creation event) through the netlink handler (534). In one example, the process fork event may be an event associated with the creation of a process of the application (502). For example, the process fork event may be an event indicating that the application (502) is created, a process identifier (PID) of the process of the application (502) is assigned, and a main thread (or main task) is created. In one example, the process execution event (or application execution / re-execution event) that may be provided by the netlink (542) may be an event indicating the execution of the process of the application (502) (or the execution / re-execution of the application) that may occur after the process fork event. As an example, a process termination event may be an event that indicates termination of a process of an application (502) that may occur after a process execution event.

[0074] The netlink handler (534) can receive a process fork event and provide information about the received process fork event to the service booster (532). The service booster (532) can receive information about the process fork event from the netlink handler (534) and forward the received information to the booster manager (536) for CPU resource allocation to the process of the application (502).

[0075] The boost manager (536) can set CPU policies for the processes of the application (502) and allocate CPU resources. The processes of the application (502) can perform initialization based on the allocated CPU resources. In one example, the initialization may include preparatory operations (or pre-operations) that must be performed to execute the application (502). When the initialization of the process of the application (502) is completed, the process of the application (502) can call the boost library (libboost) (or the resource allocation boosting release API (application programming interface)) to request the boost daemon (526) to release the boosting.

[0076] The app status listener (530) can receive an app launch / relaunch event. In one example, the app launch / relaunch event can be an event requesting an application (502). The application (502) associated with the app launch / relaunch event can be, for example, an application (e.g., an OTT application) that provides other services that do not require communication with at least one external device (320). In one example, the app launch event can be received based on a control signal transmitted from a remote control device (330). The control signal transmitted from the remote control device (330) can be, for example, a control signal based on a user's key input on the remote control device (330).

[0077] The app status listener (530) can provide information indicating that an app launch / relaunch event has been received to the booster manager (536). Based on the received information, the booster manager (536) can determine that the application (502) associated with the app launch / relaunch event will be launched / relaunched. If the application (502) is launched / relaunched, the booster manager (536) can recognize the application (502) as a foreground app.

[0078] FIG. 6 shows an example of applying various scheduling methods to an application according to one embodiment of the present disclosure.

[0079] Referring to FIG. 6, a CFS scheduling method (e.g., the CFS scheduling method (210) of FIG. 2) (e.g., a Cgroups policy) may be applied to an application (foreground app) running in the foreground (or a process of the foreground app).

[0080] When a Cgroups policy is applied to a foreground app, UI responsiveness may be reduced due to at least one thread belonging to the foreground app's process that may interfere with UI operations. For example, as illustrated in Figure 6, the foreground app's process may include at least one thread that processes tasks related to UI operations (e.g., the UI thread, the renderer thread), as well as at least one thread that processes tasks that may interfere with UI operations. Therefore, simply applying a Cgroups policy to the foreground app itself may not sufficiently ensure the CPU usage required for at least one thread related to UI operations. This is because, since the Cgroups policy is applied to all threads of the foreground app, if threads other than the thread related to the UI operation within the app occupy CPU usage, the processing of the thread related to the UI operation will be delayed. This results in reduced UI responsiveness.

[0081] When a Cgroups policy is applied to a foreground app, UI responsiveness may be reduced due to processes outside the foreground app. For example, as illustrated in Figure 6, a service that plays a CPU-intensive media source, such as an Advanced Television Systems Committee (ATSC) 3.0 service, may be provided along with the foreground app. In this case, the service's process may be subject to, for example, a Real-Time scheduling scheme (220). This results in excessive CPU contention, making it difficult for the Cgroups policy alone to sufficiently guarantee the CPU usage required for UI responsiveness for the foreground app. This phenomenon can also occur when the system is busy due to incomplete OS initialization at the beginning of a cold boot.

[0082] Additionally, when a Cgroups policy is applied to multiple foreground apps, different priorities may be applied to each app. In this case, other apps with higher priorities may consume significant CPU usage, preventing sufficient CPU resources from being allocated to the primary threads associated with the desired app's UI operations (e.g., the primary thread associated with the UI operations of the app corresponding to the currently focused window).

[0083] Therefore, a method is needed to identify threads involved in the UI operations of a user-selected application (e.g., an application selected or launched by user input) and apply a separate CPU scheduling scheme to these threads. This method can ensure that the UI of the desired application is presented smoothly to the user without compromising UI responsiveness while maintaining fast cold boot performance.

[0084] FIG. 7 is a flowchart illustrating an operation of selecting a thread related to a UI operation according to one embodiment of the present disclosure.

[0085] In the embodiment of FIG. 7, an operation of selecting threads related to a UI operation (a UI operation related thread selection operation) may be performed by the electronic device (310) (e.g., a booster module (526) of the electronic device (310)). For example, the booster module (526) of the electronic device (310) may perform the UI operation related thread selection operation in cooperation with an application (e.g., an application (430)) and a window manager (e.g., a window manager (420)) of the electronic device (310). The operation of the electronic device (310) described below may be understood as an operation of the booster module (526) controlled by the electronic device (310) or a processor of the electronic device (310).

[0086] Referring to FIG. 7, in operation 7010, the electronic device (310) can obtain thread ID (TID) information of a first thread that is requested to render for displaying a UI for an application (hereinafter, referred to as UI rendering).

[0087] According to one embodiment, the first thread may be configured to process tasks related to rendering for displaying a UI. For example, the first thread may be a thread that receives a request for UI rendering (hereinafter referred to as a UI rendering request or UI draw request) from a second thread configured to process tasks related to the UI for an application, and processes tasks related to rendering based on the UI rendering request. The UI rendering request may include at least one piece of information necessary for UI rendering.

[0088] In one embodiment, the second thread may be a thread that triggers a UI rendering request (or UI drawing request) for the application. The second thread may, for example, transmit the UI rendering request for the application to the first thread based on user input. For example, the second thread may transmit the UI rendering request for the application to the first thread when a user input that selects or executes the application (or an event associated with UI rendering corresponding to the user input) is identified.

[0089] In one embodiment, the first thread and the second thread may belong to the same application process. In one embodiment, the application may be an application running in the foreground (a foreground app).

[0090] In the present disclosure, the first thread may be referred to as a render thread, a renderer thread, or a UI rendering request thread. In the present disclosure, the second thread may be referred to as a UI thread.

[0091] According to one embodiment, the electronic device (310) may receive information about a first thread from an application and obtain TID information of the first thread from the information about the first thread. The information about the first thread may include TID information of the first thread and / or at least one additional piece of information associated with the first thread. The TID information of the first thread may indicate the TID of the first thread.

[0092] In one embodiment, the application may identify an event associated with UI rendering based on user input. For example, when the application receives user input (e.g., a remote control key press or touch input of operation 4010 of FIG. 4A ) to select or execute an application, the application may identify an event associated with UI rendering corresponding to the user input.

[0093] According to one embodiment, the application may transmit information about a first thread, including TID information of the first thread, to the booster module (526) of the electronic device (310) based on the identification of an event associated with UI rendering. For example, in response to the identification of an event associated with UI rendering, the application may request UI rendering by calling a rendering API, and transmit information about the first thread, including TID information of the first thread, to the booster module (526) of the electronic device (310). The rendering API may be an API provided by a window manager.

[0094] In operation 7020, the electronic device (310) can identify, based on the TID information of the first thread, whether the first thread belongs to a process of an application associated with a top-level window among at least one window displayed on the screen.

[0095] According to one embodiment, a top-level window may be a window in which a UI (e.g., UI (440b) of FIG. 4b or UI (440c) of FIG. 4c) corresponding to a user input is displayed on a screen (e.g., a current screen (e.g., screen (400b) of FIG. 4b or screen (400c) of FIG. 4c)). The data of the top-level window may be stored, for example, at the topmost position on a window stack.

[0096] According to one embodiment, the topmost window may be a window corresponding to an application of interest to the user among at least one window displayed on the screen (e.g., the current screen).

[0097] According to one embodiment, the topmost window (or focused window) may be a window positioned frontmost (e.g., closest to the screen) among at least one window (e.g., the first to fourth windows of FIGS. 4b / c) displayed on the screen (e.g., the current screen). For example, the topmost window may be the second window (401b) illustrated in part (b) of FIG. 4b or the first window (401c) illustrated in part (b) of FIG. 4c. For a description of the topmost window, refer to the description of FIGS. 4a to 4c.

[0098] According to one embodiment, the electronic device (310) may place a window at the frontmost position based on an identification of a request to bring the window to the front (hereinafter, referred to as a focus request). The focus request may be based on a user input selecting or executing an application corresponding to the window.

[0099] According to one embodiment, the electronic device (310) can obtain information about the process of an application associated with a top-level window. For example, the booster module (526) of the electronic device (310) can receive information about the process of the application associated with the top-level window from a window manager. The information about the process of the application associated with the top-level window can include, for example, PID information indicating the process ID (PID) of the process.

[0100] According to one embodiment, information about the process of an application associated with a top-level window may be transmitted based on, for example, an identification of a change in the top-level window by a window manager. For example, in response to an identification of a change in the top-level window, the window manager may transmit information about the process of the application associated with the top-level window to the booster module (526) of the electronic device (310). For example, whenever a change in the top-level window is identified, the window manager may transmit information about the process of the application associated with the top-level window to the booster module (526) of the electronic device (310). For example, whenever a change in the window(s) displayed on the screen (or a change in the window stack) is identified, the window manager may transmit information about the process of the application associated with the window(s) (or window stack change information) to the booster module (526) of the electronic device (310). The window stack change information may include, for example, information about the process of the application associated with the window(s) that have been changed on the window stack.

[0101] According to one embodiment, the electronic device (310) may identify whether the first thread belongs to the process of the application associated with the top-level window by comparing the TID(s) of the thread(s) belonging to the process of the application associated with the identified top-level window based on the PID information transmitted from the window manager with the TID of the first thread identified by the TID information transmitted from the application. For example, if one of the TID(s) of the thread(s) belonging to the process of the application associated with the top-level window is the same as the TID of the first thread, the electronic device (310) may identify that the first thread belongs to the process of the application associated with the top-level window. For example, if one of the TID(s) of the thread(s) belonging to the process of the application associated with the top-level window does not match the TID of the first thread, the electronic device (310) may identify that the first thread does not belong to the process of the application associated with the top-level window.

[0102] According to one embodiment, the booster module (526) of the electronic device (310) may obtain a thread list including TID(s) of thread(s) belonging to the process of the application from AMD (524) when the application is executed or re-executed.

[0103] In operation 7030, the electronic device (310) may include the first thread and a second thread that belongs to the same process as the first thread and is set to process UI-related tasks in a list of threads associated with UI operations of the application (hereinafter referred to as a UI thread list) based on the identification that the first thread belongs to the process of the application associated with the top-level window.

[0104] According to one embodiment, threads included in the UI thread list may belong to the same process and may have different scheduling settings applied to at least one thread not included in the UI thread list. According to one embodiment, threads included in the UI thread list may belong to the same process and may have different priority adjustments applied to at least one thread not included in the UI thread list. This can improve the responsiveness of UI operations processed by threads included in the UI thread list.

[0105] For example, threads included in the UI thread list may have a different scheduling method (or scheduling policy) applied to them than at least one thread that belongs to the same process and is not included in the UI thread list. For example, threads included in the UI thread list may have the RT scheduling method (RT policy) applied to them, and other threads of the process that are not included in the UI thread list may have the CFS scheduling method (e.g., Cgroups policy) applied to them.

[0106] For example, threads included in the UI thread list can be set to have a higher priority than at least one thread that belongs to the same process and is not included in the UI thread list. For example, although the CFS scheduling method (e.g., Cgroups policy) is applied to both threads included in the UI thread list and other threads of the process that are not included in the UI thread list, the threads included in the UI thread list can be set to have a higher priority than other threads of the process that are not included in the UI thread list.

[0107] According to one embodiment, in response to identifying the first thread as belonging to a process of an application associated with a top-level window, the electronic device (310) may include the first thread in a list of UI threads of the application. Thereafter, the electronic device (310) may identify the process to which the first thread belongs, identify a second thread among the thread(s) belonging to the process that is configured to process UI-related tasks, and include the second thread in the list of UI threads of the application. In this way, the first thread and the second thread that affect UI responsiveness may be included together in the list of UI threads.

[0108] According to one embodiment, the electronic device (310) can identify, among the threads included in the process to which the first thread belongs, a thread having a TID identical to the process ID (PID) of the process as the second thread. This method can be applied when the first thread (UI thread) corresponds to the main thread of the application. This is because the main thread is the first thread created when the process is created and is set to have an ID identical to the process ID.

[0109] According to one embodiment, the electronic device (310) can identify, among the threads included in the process to which the first thread belongs, a thread with the same name as the process name as the second thread. This method can be applied when the first thread (UI thread) corresponds to the main thread of the application. This is because the main thread is the first thread created when the process is created and is set to have the same name as the process name.

[0110] According to one embodiment, the electronic device (310) can identify a thread having a thread ID registered as the first thread (UI thread) among the threads included in the process to which the first thread belongs, as the first thread. This method can be applied when the first thread (UI thread) does not correspond to the main thread of the application. For example, a registration API that can register a thread (e.g., the first thread) in the application can be provided, and the application (or the main thread of the application) can call the registration API to register the thread (e.g., the first thread). Information about the thread registered through the registration API can be the TID of the corresponding thread (e.g., the first thread). Registration of a thread is exemplarily described below with reference to FIGS. 12 and 13.

[0111] As described above, the thread selection operation of the present disclosure includes only threads associated with UI operations belonging to the process of the application associated with the top-level window (or the focused window) in the UI thread list, rather than including all threads associated with UI operations in the UI thread list, thereby enabling only threads that actually affect UI responsiveness to be selected and managed separately.

[0112] Meanwhile, depending on the implementation structure of the application, in addition to the first thread (renderer thread) and the second thread (UI thread) described above, there may be threads that have a dependency relationship with the renderer thread and / or the UI thread. A thread having a dependency relationship (or dependency) with another thread may include cases where the processing of another thread cannot be completed unless the processing of one thread is completed.

[0113] For example, in the case of certain applications (e.g., OTT apps), the UI thread waits for the completion of processing by a worker thread created by the application, so the worker thread and the UI thread have a dependency relationship (e.g., the processing of the UI thread depends on the processing of the worker thread). In this case, the priority of the worker thread must also be adjusted along with the UI thread to improve UI responsiveness.

[0114] For example, in the case of a specific application (e.g., the Home app), if a thread associated with a garbage collection operation generated by the application (e.g., the stdout thread) does not finish processing, the entire process may stop, so the thread and the UI thread have a dependency relationship (e.g., the processing of the UI thread depends on the processing of the thread). In this case, the priority of the thread should also be adjusted together with the UI thread to improve UI responsiveness.

[0115] According to one embodiment, the electronic device (310) may provide a registration API for registering a thread (e.g., a worker thread) that is dependent on UI rendering in an application process (or a UI thread list of the application) when the thread is created. In this case, the electronic device (310) (or the main thread of the electronic device (310)) may register the thread by calling the registration API with the TID of the thread as a parameter when the thread that is dependent on UI rendering is created. The thread registered in this way may be identified together when the renderer thread is identified (e.g., the renderer thread to be included in the thread list is identified by operation 7020). The registration of the thread will be exemplarily described below with reference to FIGS. 12 and 13.

[0116] According to one embodiment, the electronic device (310) may include a third thread having a dependency relationship with the first thread and / or the second thread (renderer thread) in a list of threads associated with the UI operation of the application, together with the first thread and the second thread, based on the first thread (UI thread) being identified as belonging to the process of the application associated with the top-level window.

[0117] FIG. 8 is a flowchart illustrating the operation of an application for selecting a thread related to a UI operation according to one embodiment of the present disclosure.

[0118] The description of operations 8010 and 8020 of FIG. 8 may refer to the description of operation 7010 of FIG. 7. Therefore, any duplicate description is omitted.

[0119] Referring to FIG. 8, at operation 8010, an application (e.g., application (430)) may request rendering for displaying a UI (UI rendering). The rendering request API may be, for example, an API provided by a window manager (e.g., window manager (420)).

[0120] In one embodiment, an application may request UI rendering by calling a rendering request API. For example, when a user input for selecting or executing the application is identified, the application may request UI rendering by calling the rendering request API. For example, when a user input for selecting or executing the application is identified, a second thread (UI thread) of the application may request UI rendering from a first thread (renderer thread) by calling the rendering request API. In response to the application's call, the rendering request API may transmit TID information of the first thread (renderer thread) that received the UI rendering request to the application or a booster module (e.g., booster module (561)).

[0121] In operation 8020, the application (or rendering request API) may transmit the TID information of the first thread (renderer thread) that received the UI rendering request to the booster module (561).

[0122] FIG. 9 is a flowchart illustrating the operation of a window manager for selecting a thread related to a UI operation according to one embodiment of the present disclosure.

[0123] The description of operations 9010 and 9020 of FIG. 9 may refer to the description of operation 7020 of FIG. 7. Therefore, any duplicate description is omitted.

[0124] Referring to FIG. 9, at operation 9010, a window manager (e.g., window manager (420)) can identify whether a change in the top-level window has occurred.

[0125] According to one embodiment, a change in the topmost window may occur based on a user input for selecting an application (e.g., application (430)). For example, as illustrated in part (b) of FIG. 4b, when a second window (401b) corresponding to a second application is set as the topmost window, and a user input for selecting a first application is selected as illustrated in part (b) of FIG. 4c, the topmost window may change from the second window (401b) to the first window (401c). A UI corresponding to the user input may be drawn on the topmost window. A change in the topmost window may cause a change in the window stack.

[0126] In operation 9020, if the window manager identifies that a change in the top-level window has occurred, the window manager may transmit information about the process of the application associated with the top-level window to a booster module (e.g., booster module (561)). The information about the process of the application associated with the top-level window may include, for example, PID information indicating the process ID of the process of the application associated with the top-level window.

[0127] According to one embodiment, the window manager may transmit window stack change information, which includes information about the process of the application associated with the top-level window, to the booster module (561).

[0128] According to one embodiment, the window stack change information may include information about the process of the application associated with the top-level window, along with information about the process of the windows included in the window stack (e.g., PID information).

[0129] FIG. 10 is a flowchart illustrating the operation of a booster module for selecting threads related to UI operations according to one embodiment of the present disclosure.

[0130] The description of operations 10010 to 10030 of FIG. 10 may refer to the description of operations 7010 to 7030 of FIG. 7. Therefore, any duplicate description is omitted.

[0131] In operation 10010, the booster module (e.g., booster module (561)) may receive TID information of the first thread (renderer thread) that has received a rendering request. The description of operation 10010 of FIG. 10 may refer to the description of operation 7010 of FIG. 7. Therefore, any duplicate description will be omitted.

[0132] According to one embodiment, the booster module (561) may receive TID information of a first thread that has been requested to render from an application (e.g., application (430)).

[0133] According to one embodiment, the booster module (561) may receive PID information of a process of an application associated with a top-level window from a window manager (e.g., window manager (420)). For example, after the TID information of the first thread is received or before the TID information of the first thread is received, the booster module (561) may receive PID information of a process of an application associated with a top-level window from the window manager.

[0134] In operation 10020, the booster module (561) can identify whether the first thread belongs to the process of the application associated with the top-level window. The description of operation 10020 of FIG. 10 may refer to the description of operation 7020 of FIG. 7. Therefore, any duplicate description will be omitted.

[0135] According to one embodiment, the booster module (561) can identify whether the first thread belongs to a process of an application associated with the top-level window based on the received TID information and PID information.

[0136] In operation 10030, if the first thread is identified as belonging to the process of the application associated with the top-level window, the booster module (561) may include the first thread and the second thread (UI thread) belonging to the same process as the first thread and processing UI-related tasks in the list of threads associated with the UI operation (UI thread list). The description of operation 10030 of FIG. 10 may refer to the description of operation 7030 of FIG. 7. Therefore, any duplicate description will be omitted.

[0137] Meanwhile, if the first thread is not identified as belonging to the process of the application associated with the top-level window, the booster module (561) does not include the first thread and the second thread (UI thread) in the UI thread list. That is, the first thread and the second thread are not set as threads whose priorities are adjusted separately from other threads within the process. This is because the application of the process to which the first thread and the second thread belong does not correspond to an application that the user is currently interested in (e.g., an application associated with UI response).

[0138] FIG. 11 is a signal flow diagram illustrating a procedure for selecting a thread related to a UI operation according to one embodiment of the present disclosure.

[0139] In operation 11010, an application (e.g., application (430)) may transmit TID information of a rendering request thread (first thread) to a booster module (e.g., booster module (561)). The description of operation 11010 may refer to the description of operation 7010 of FIG. 7, operations 8010 / 8020 of FIG. 8, and operation 10010 of FIG. 10. Therefore, any duplicate description will be omitted.

[0140] In operation 11020, a window manager (e.g., window manager (420)) may transmit information about the process of an application associated with the top-level window to the booster module. Operation 11020 may be performed before operation 11010, or may be performed in parallel with operation 11010. The description of operation 11020 may refer to the description of operations 9010 / 9020 of FIG. 9. Therefore, any duplicate description will be omitted.

[0141] At operation 11030, the booster module can determine whether the first thread belongs to the process of the application associated with the top-level window. Operation 11030 may refer to the description of operation 7020 of FIG. 7 or operation 10020 of FIG. 10 . Duplicate descriptions are omitted.

[0142] In operation 11040, if it is identified that the first thread belongs to the process of the application associated with the top-level window, the booster module may include the first thread and / or a second thread that belongs to the same process as the first thread and handles UI-related tasks in the list of threads associated with the UI operations of the application (UI thread list). Operation 11040 may refer to the description of operation 7030 of FIG. 7 or operation 10030 of FIG. 10. Therefore, any duplicate description will be omitted.

[0143] FIG. 12 is a flowchart illustrating an operation of registering a thread associated with a UI operation according to one embodiment of the present disclosure.

[0144] In the embodiment of FIG. 12, the operation of registering a thread associated with a UI operation (the operation of registering a UI-associated thread) may be performed, for example, by the electronic device (310) (e.g., the booster module (526) of the electronic device (310). The operation of the electronic device (310) described below may be understood as the operation of the booster module (526) controlled by the electronic device (310) or the processor of the electronic device (310).

[0145] Referring to FIG. 12, in operation 12010, the electronic device (310) may receive a registration request for a thread associated with a UI operation (UI-associated thread). The thread associated with the UI operation may be a first thread (renderer thread), a second thread (UI thread), or a thread dependent on the first thread or the second thread (UI thread).

[0146] According to one embodiment, the electronic device (310) may receive a registration request for a thread associated with a UI operation from an application (e.g., application (430)). For example, the main thread (e.g., UI thread) of the application may transmit a registration request for the UI-associated thread, including TID information of the UI-associated thread, to the booster module (526) by calling a UI registration request API for the UI-associated thread.

[0147] At operation 12020, the electronic device (310) can identify whether a UI associated thread is running.

[0148] According to one embodiment, the electronic device (310) can identify whether a UI-associated thread having a TID included in the registration request is running.

[0149] If the UI-associated thread is identified as not running, the electronic device (310) does not perform any additional procedures for registering the UI-associated thread. This is because, if the UI-associated thread is not running (or the application of the UI-associated thread has been terminated), there is no need to set the thread as a thread whose priority is adjusted separately.

[0150] In operation 12030, if a UI-associated thread is identified as running, the electronic device (310) can identify whether a TID of the UI-associated thread exists.

[0151] According to one embodiment, the electronic device (310) can identify whether a TID of a UI-associated thread exists within a system (e.g., a system for CPU scheduling of FIG. 5).

[0152] If it is determined that the TID of the UI-associated thread does not exist, the electronic device (310) does not perform any additional procedures for registering the UI-associated thread. This is because, if the TID of the UI-associated thread does not exist in the system, the application of the process to which the thread belongs is not running (or re-running), and therefore there is no need to set it as a thread whose priority is adjusted separately.

[0153] In operation 12040, if it is identified that a TID of a UI-associated thread exists, the electronic device (310) may include the UI-associated thread in a list of threads (UI thread list) associated with UI operations of the application. According to one embodiment, the electronic device (310) may register the TID of the UI-associated thread in the UI thread list. Through this, the UI-associated thread may be set as a thread whose priority is adjusted separately, and thereafter, its priority may be adjusted together with the first thread (renderer thread) and the second thread (UI thread).

[0154] According to one embodiment, threads included in the UI thread list may belong to the same process and may have different scheduling settings applied to at least one thread not included in the UI thread list. According to one embodiment, threads included in the UI thread list may belong to the same process and may have different priority adjustments applied to at least one thread not included in the UI thread list. This can improve the responsiveness of UI operations processed by threads included in the UI thread list.

[0155] For example, threads included in the UI thread list may have a different scheduling method (or scheduling policy) applied to them than at least one thread that belongs to the same process and is not included in the UI thread list. For example, threads included in the UI thread list may have the RT scheduling method (RT policy) applied to them, and other threads of the process that are not included in the UI thread list may have the CFS scheduling method (e.g., Cgroups policy) applied to them.

[0156] For example, threads included in the UI thread list can be set to have a higher priority than at least one thread that belongs to the same process and is not included in the UI thread list. For example, although the CFS scheduling method (e.g., Cgroups policy) is applied to both threads included in the UI thread list and other threads of the process that are not included in the UI thread list, the threads included in the UI thread list can be set to have a higher priority than other threads of the process that are not included in the UI thread list.

[0157] FIG. 13 is a flowchart illustrating an operation for requesting registration for a thread associated with a UI operation, according to one embodiment of the present disclosure.

[0158] In the embodiment of FIG. 13, an operation requesting registration for a thread associated with a UI operation (a UI-associated thread registration request operation) may be performed, for example, by an electronic device (310) (e.g., an application of the electronic device (310)). The operation of the electronic device (310) described below may be understood as an operation of an application controlled by the electronic device (310) or a processor of the electronic device (310).

[0159] In operation 13010, the electronic device (310) may create a thread belonging to a process of the application.

[0160] According to one embodiment, the electronic device (310) can identify whether the corresponding thread is a thread associated with a UI operation. For example, as in operation 13020, the electronic device (310) can identify whether the corresponding thread is a thread for a Garbage Collect operation (Garbage Collect operation thread). The Garbage Collect operation thread may be, for example, a thread that periodically checks the memory space allocated by the application and performs a function of releasing memory that is no longer in use. Since the entire process may stop if the processing of the Garbage Collect operation thread is not completed, the Garbage Collect operation thread may be a thread that is dependent on the UI thread (second thread).

[0161] According to one embodiment, the electronic device (310) may request registration (UI-associated thread registration) for a thread associated with a UI operation if the thread is identified as a thread associated with a UI operation. For example, as in operation 13030, the electronic device (310) may request registration of a UI-associated thread for the thread if the thread is identified as a Garbage Collect operation thread. For example, the electronic device (310) may request registration of a UI-associated thread for the thread by calling a registration API.

[0162] According to one embodiment, when a registration request for a thread associated with a UI operation (UI-associated thread registration request) is received, the electronic device (310) may perform, for example, the UI-associated thread registration operation of FIG. 12 to include (or register) the corresponding thread in the UI thread list. For a description of the UI-associated thread registration operation for the corresponding thread, reference may be made to the description of FIG. 12. Therefore, any duplicate description will be omitted.

[0163] FIG. 14 is a flowchart illustrating an operation of operating a list of threads associated with UI operations according to one embodiment of the present disclosure.

[0164] In the embodiment of FIG. 14, an operation of operating a thread list associated with a UI operation (UI thread list operating operation) may be performed, for example, by an electronic device (310) (e.g., a booster module (526) of the electronic device (310). The operation of the electronic device (310) described below may be understood as an operation of the booster module (526) controlled by the electronic device (310) or a processor of the electronic device (310).

[0165] In operation 14010, the electronic device (310) may receive a UI rendering request for an application. In one embodiment, the booster module (526) of the electronic device (310) may receive the UI rendering request from the application (or the UI thread of the application). The UI rendering request may be generated based on a user input selecting or executing the application.

[0166] In operation 14020, the electronic device (310) can identify whether there is a list of threads (UI thread list) associated with UI operations for the application.

[0167] In operation 14030, if it is identified that a UI thread list exists for the corresponding application, the electronic device (310) may adjust priorities for threads included in the UI thread list. The threads included in the UI thread list may include, for example, a first thread (renderer thread), a second thread (UI thread), and / or at least one thread having a dependent relationship with the first thread or the second thread.

[0168] According to one embodiment, the electronic device (310) may identify whether the window corresponding to the application is a top-level window before or after operation 14020 is performed. If it is identified that the window corresponding to the application is a top-level window and that a UI thread list for the application exists, the electronic device (310) may adjust the priorities of the threads included in the UI thread list.

[0169] According to one embodiment, threads included in the UI thread list may belong to the same process and may have different scheduling settings applied to at least one thread not included in the UI thread list. According to one embodiment, threads included in the UI thread list may belong to the same process and may have different priority adjustments applied to at least one thread not included in the UI thread list. This can improve the responsiveness of UI operations processed by threads included in the UI thread list.

[0170] For example, threads included in the UI thread list may have a different scheduling method (or scheduling policy) applied to them than at least one thread that belongs to the same process and is not included in the UI thread list. For example, threads included in the UI thread list may have the RT scheduling method (RT policy) applied to them, and other threads of the process that are not included in the UI thread list may have the CFS scheduling method (e.g., Cgroups policy) applied to them.

[0171] For example, threads included in the UI thread list can be set to have a higher priority than at least one thread that belongs to the same process and is not included in the UI thread list. For example, although the CFS scheduling method (e.g., Cgroups policy) is applied to both threads included in the UI thread list and other threads of the process that are not included in the UI thread list, the threads included in the UI thread list can be set to have a higher priority than other threads of the process that are not included in the UI thread list.

[0172] According to one embodiment, the electronic device (310) can perform UI operations using allocated CPU resources based on adjusted priorities. This can improve UI responsiveness.

[0173] FIG. 15 is a diagram illustrating an effect of improving UI responsiveness according to one embodiment of the present disclosure.

[0174] The thin solid line in Figure 15 illustrates the first result of measuring UI responsiveness (e.g., FPS performance) when the procedure for selecting threads related to UI operations of the present disclosure is not performed. Referring to the first result, it can be confirmed that the UI thread does not receive sufficient CPU usage due to CPU contention, resulting in an average FPS drop to 33 FPS.

[0175] The bold solid line in Fig. 15 illustrates a second result of measuring UI responsiveness (e.g., FPS performance) when a procedure for selecting threads related to the UI operation of the present disclosure is performed. For example, the second result may be a result of measuring UI responsiveness in a state where the render thread (renderer thread) is included in the UI thread list together with the UI thread and its priority is adjusted / boosted. Referring to the second result, it can be confirmed that the UI thread is sufficiently guaranteed CPU usage, and the average FPS is improved to 51 FPS.

[0176] FIG. 16 is a block diagram of an electronic device according to one embodiment of the present disclosure.

[0177] Referring to FIG. 16, the electronic device (310) may include a processor (1602), a memory (1604), a display (1606), a first communication interface (1608), and a second communication interface (1610). In one example, the electronic device (310) may include additional components (e.g., an audio output unit) in addition to the illustrated components, or may omit at least one of the illustrated components.

[0178] According to one example, the memory (1604) can store various information or data associated with the operation of the electronic device (310) and can store at least one program.

[0179] In one example, the display (1606) can perform various display operations depending on the function of the electronic device (310). For example, the display (1606) can display at least one of various service information, media information, text information, or broadcast information according to the execution of an application. In one example, the display (1606) can display a UI corresponding to a user input.

[0180] In one example, the first communication interface (1608) can perform wired or wireless communication with at least one external device (320). For example, the first communication interface (1608) can perform wired communication with at least one external device (320) via a cable, or wireless communication based on Wi-Fi, Bluetooth, or other wireless communication technologies.

[0181] In one example, the second communication interface (1610) can communicate with a remote control device. For example, it can communicate with at least one external device (320) via IR or RF communication.

[0182] According to one example, the processor (1602) is electrically connected to the memory (1604), the display (1606), the first communication interface (1608), and the second communication interface (1610), respectively, and can execute at least one instruction of a program stored in the memory (1604). There may be one or more processors (1602) and they can perform the operations of the electronic device (310) described above. For example, at least one processor (1602) includes a processing circuit and can individually and / or commonly perform at least one of the following operations:

[0183] According to one embodiment, at least one processor (1602) may obtain thread ID (TID) information of a first thread configured to process a task related to rendering for displaying a user interface (UI).

[0184] According to one embodiment, at least one processor (1602) can identify, based on the TID information, whether the first thread belongs to a process of an application associated with a top window among at least one window displayed on the screen.

[0185] According to one embodiment, at least one processor (1602) may include the first thread and a second thread that belongs to the same process as the first thread and is set to process work related to the UI in a list of threads associated with UI operations of the application, based on the first thread being identified as belonging to a process of the application associated with the top-level window.

[0186] According to one embodiment, threads included in the list of threads associated with the UI action may be configured to have different scheduling settings applied to at least one thread that belongs to the process and is not included in the list of threads associated with the UI action.

[0187] According to one embodiment, in order to obtain the TID information of the first thread, at least one processor (1602) may receive, from the application, the TID information of the first thread for which rendering for displaying the UI has been requested. The application may request rendering for displaying the UI based on a user input for selecting or executing the application.

[0188] According to one embodiment, at least one processor (1602) may, in response to identifying that a change in the top-level window has occurred, receive, from a window manager, process information about a process of the application associated with the top-level window. The process information may include process identifier (PID) information indicating a process ID (PID) of the process.

[0189] According to one embodiment, at least one processor (1602) can compare the TIDs of threads belonging to a process identified by the PID information with the TID of the first thread identified by the TID information to identify whether the first thread belongs to a process of an application associated with the top-level window.

[0190] According to one embodiment, at least one processor (1602) can identify, among the threads included in the process, a thread having a TID identical to the PID of the process as the second thread.

[0191] According to one embodiment, at least one processor (1602) can identify, among the threads included in the process, a thread having the same name as the name of the process as the second thread.

[0192] According to one embodiment, to include the first thread and the second thread in the list of threads associated with the UI operation, the at least one processor (1602) may: in response to identifying the first thread as belonging to a process of the application associated with the top-level window, include the first thread in the list of threads associated with the UI operation, identify the process to which the first thread belongs, identify the second thread among threads included in the process, and include the second thread in the list of threads associated with the UI operation.

[0193] According to one embodiment, the at least one processor (1602) may be configured to: identify at least one third thread having a dependency on at least one of the first thread or the second thread, and include the third thread in a list of threads associated with the UI operation.

[0194] According to one embodiment, threads included in the thread list associated with the UI operation may be subject to a real-time (RT) scheduling method, and at least one thread not included in the thread list associated with the UI operation may be subject to a completely fair scheduler (CFS) scheduling method.

[0195] According to one embodiment, threads included in the list of threads associated with the UI action may be set to a higher priority than at least one thread not included in the list of threads associated with the UI action.

[0196] According to one embodiment, a method of an electronic device may include obtaining thread ID (TID) information of a first thread configured to process a task related to rendering for displaying a user interface (UI).

[0197] According to one embodiment, the method of the electronic device may include an operation of identifying, based on the TID information, whether the first thread belongs to a process of an application associated with a top window among at least one window displayed on the screen.

[0198] According to one embodiment, the method of the electronic device may include an operation of including the first thread and a second thread belonging to the same process as the first thread and set to process a task related to the UI in a list of threads associated with a UI operation of the application, based on the first thread being identified as belonging to a process of the application associated with the top-level window.

[0199] According to one embodiment, threads included in the list of threads associated with the UI action may have different scheduling settings applied to at least one thread that belongs to the process and is not included in the list of threads associated with the UI action.

[0200] According to one embodiment, the operation of obtaining the TID information of the first thread may include: receiving, from the application, the TID information of the first thread for which rendering for displaying the UI has been requested. The application may request rendering for displaying the UI based on a user input for selecting or executing the application.

[0201] According to one embodiment, a method of an electronic device includes: in response to identifying that a change in the top-level window has occurred, receiving, from a window manager, process information about a process of the application associated with the top-level window, wherein the process information may include PID information indicating a process ID (PID) of the process.

[0202] According to one embodiment, the operation of identifying whether the first thread belongs to the process of the application associated with the top window may include: comparing the TID of the first thread identified by the TID information with the TIDs of the threads belonging to the process identified by the PID information, thereby identifying whether the first thread belongs to the process of the application associated with the top window.

[0203] According to one embodiment, at least one method may include: identifying, among the threads included in the process, a thread having a TID that is the same as a PID of the process as the second thread.

[0204] According to one embodiment, at least one method may include: identifying, among the threads included in the process, a thread having a name identical to the name of the process as the second thread.

[0205] According to one embodiment, the act of including the first thread and the second thread in the list of threads associated with the UI action may include: in response to identifying the first thread as belonging to a process of the application associated with the top-level window, including the first thread in the list of threads associated with the UI action; identifying the process to which the first thread belongs; identifying the second thread among threads included in the process; and including the second thread in the list of threads associated with the UI action.

[0206] According to one embodiment, at least one method may include: identifying at least one third thread having a dependency with at least one of the first thread or the second thread; and including the third thread in a list of threads associated with the UI operation.

[0207] According to one embodiment, threads included in the thread list associated with the UI operation may be subject to a real-time (RT) scheduling method, and at least one thread not included in the thread list associated with the UI operation may be subject to a completely fair scheduler (CFS) scheduling method.

[0208] According to one embodiment, threads included in the list of threads associated with the UI action may be given a higher priority than at least one thread not included in the list of threads associated with the UI action.

[0209] The electronic device (310) according to various embodiments disclosed in this document may be a variety of devices. The electronic device (310) may include, for example, a portable communication device (e.g., a smartphone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance device. The electronic device (310) according to the embodiments of this document is not limited to the aforementioned devices.

[0210] The various embodiments of this document and the terminology used therein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various modifications, equivalents, or substitutes of the 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 the items, unless the context clearly indicates otherwise. In this document, each of the phrases "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" can include any one of the items listed together in the corresponding phrase among those phrases, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as "coupled" or "connected" to another (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

[0211] The term "module" used in 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. A module may be an integral component, or a minimum unit or part of such a component 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).

[0212] According to various embodiments, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and placed in other components. According to various embodiments, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to various embodiments, the operations performed by a module, program, or other component 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 electronic devices, memory for storing at least one program; and At least one processor electrically connected to said memory and configured to execute at least one instruction of a program stored in said memory; At least one processor of the above: Obtain the thread ID (TID) information of the first thread set to process tasks related to rendering for displaying the user interface (UI), Based on the above TID information, identify whether the first thread belongs to a process of an application associated with at least one top window displayed on the screen, Based on the identification that the first thread belongs to the process of the application associated with the top-level window, the first thread and a second thread that belongs to the same process as the first thread and is set to process work related to the UI are configured to be included in the list of threads associated with the UI operation of the application. An electronic device, wherein threads included in the list of threads associated with the UI operation are set to have different scheduling settings applied to at least one thread that belongs to the process and is not included in the list of threads associated with the UI operation.

2. In the first paragraph, in order to obtain the TID information of the first thread, the at least one processor: configured to receive the TID information of the first thread from which rendering for displaying the UI is requested from the above application, An electronic device, wherein the application requests rendering for display of the UI based on user input for selecting or executing the application.

3. In claim 1 or 2, at least one processor: An electronic device, in response to identifying that a change in the top-level window has occurred, receiving, from a window manager, process information about a process of the application associated with the top-level window, the process information including PID information indicating a process ID (PID) of the process.

4. In the third paragraph, the at least one processor: An electronic device that compares the TIDs of threads belonging to a process identified by the PID information with the TID of the first thread identified by the TID information to identify whether the first thread belongs to a process of an application associated with the top-level window.

5. In claim 3 or 4, at least one processor: An electronic device configured to identify, among the threads included in the above process, a thread having a TID identical to the PID of the above process as the second thread.

6. In claim 3 or 4, at least one processor: An electronic device configured to identify, among the threads included in the above process, a thread having the same name as the name of the above process as the second thread.

7. In the first paragraph, to include the first thread and the second thread in the list of threads associated with the UI operation, the at least one processor: In response to identifying said first thread as belonging to the process of said application associated with said top-level window, including said first thread in a list of threads associated with said UI operation; Identify the process to which the first thread belongs, Identifying the second thread among the threads included in the above process, An electronic device, which includes the second thread in a list of threads associated with the UI operation.

8. In paragraph 1, At least one processor of the above: Identify at least one third thread that has a dependency on at least one of the first thread or the second thread, An electronic device configured to include the third thread in a list of threads associated with the UI operation.

9. In paragraph 1, An electronic device, wherein threads included in the thread list associated with the UI operation are subject to a real-time (RT) scheduling method, and at least one thread not included in the thread list associated with the UI operation is subject to a completely fair scheduler (CFS) scheduling method.

10. In paragraph 1, An electronic device, wherein threads included in the list of threads associated with the UI operation are set to a higher priority than at least one thread not included in the list of threads associated with the UI operation.

11. In the method of an electronic device, An action to obtain thread ID (TID) information of a first thread set to process tasks related to rendering for displaying a user interface (UI); An operation for identifying whether the first thread belongs to a process of an application associated with at least one top window among windows displayed on the screen based on the TID information; and An operation of including the first thread and a second thread, which belongs to the same process as the first thread and is set to process work related to the UI, in a list of threads associated with UI operations of the application, based on the identification that the first thread belongs to the process of the application associated with the top-level window, A method wherein threads included in the list of threads associated with the UI operation are set to have different scheduling settings applied to at least one thread that belongs to the process and is not included in the list of threads associated with the UI operation.

12. In paragraph 11, the operation of obtaining the TID information of the first thread is: An operation for receiving the TID information of the first thread from which rendering for displaying the UI is requested from the application, A method wherein the application requests rendering for display of the UI based on user input for selecting or executing the application.

13. In clause 11 or 12, the method: A method comprising: in response to identifying that a change in said top-level window has occurred, receiving from a window manager process information about a process of said application associated with said top-level window, said process information including PID information indicating a process ID (PID) of said process.

14. In the 13th paragraph, the operation of identifying whether the first thread belongs to the process of the application associated with the top-level window is: A method comprising an operation of comparing the TIDs of threads belonging to a process identified by the PID information and the TID of the first thread identified by the TID information to identify whether the first thread belongs to a process of an application associated with the top window.

15. In clause 13 or 14, the method: A method comprising an action of identifying, among the threads included in the above process, a thread having a TID identical to the PID of the above process as the second thread.

Images