CN113051047B - Method and device for identifying android system drawing threads, mobile terminal and storage medium - Google Patents

Method and device for identifying android system drawing threads, mobile terminal and storage medium Download PDF

Info

Publication number
CN113051047B
CN113051047B CN202110239090.XA CN202110239090A CN113051047B CN 113051047 B CN113051047 B CN 113051047B CN 202110239090 A CN202110239090 A CN 202110239090A CN 113051047 B CN113051047 B CN 113051047B
Authority
CN
China
Prior art keywords
thread
state
current running
identifying
threads
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110239090.XA
Other languages
Chinese (zh)
Other versions
CN113051047A (en
Inventor
丁唐
王斌宏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Yuxin Zhixing Technology Ningbo Co ltd
Original Assignee
Yuxin Zhixing Technology Ningbo Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Yuxin Zhixing Technology Ningbo Co ltd filed Critical Yuxin Zhixing Technology Ningbo Co ltd
Priority to CN202110239090.XA priority Critical patent/CN113051047B/en
Publication of CN113051047A publication Critical patent/CN113051047A/en
Priority to EP22762325.3A priority patent/EP4303725A1/en
Priority to PCT/CN2022/072611 priority patent/WO2022183856A1/en
Priority to US18/548,904 priority patent/US20240143395A1/en
Application granted granted Critical
Publication of CN113051047B publication Critical patent/CN113051047B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/526—Mutual exclusion algorithms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/545—Gui
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/548—Queue
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Image Generation (AREA)

Abstract

The invention discloses a method, a device, a mobile terminal and a storage medium for identifying android program drawing threads, wherein the method comprises the following steps: creating a plurality of threads, wherein the threads comprise one or more threads of a main thread of an application process, a hardware rendering thread of an android system and a custom thread; performing cross-process communication through threads, applying for a graphic buffer area, calling a queue buffer function of a buffer queue, and submitting graphic contents drawn by a client to a system graphic buffer area; identifying a thread task according to the state when the process state is switched, identifying a current running thread, marking the current task_struct of the thread as ui_thread, and obtaining the state of the drawing thread; and identifying a thread task according to the state when the process state is switched, and resetting the state of the drawing thread if the thread task is not the current running thread. The invention can identify the relevant process drawn on the mobile terminal and give the maximum resource utilization, and can improve the utilization rate of the mobile system.

Description

Method and device for identifying android system drawing threads, mobile terminal and storage medium
Technical Field
The invention relates to the technical field of Android operating system terminals, in particular to a method and device for identifying Android system drawing threads, a mobile terminal and a storage medium.
Background
With the continuous development of computer technology, more and more software is installed on mobile terminals such as mobile phones, tablet computers and desktop computers, and then the software contends for resources on the mobile terminals more and more, such as a Central Processing Unit (CPU), a Memory, an input/output (IO) and the like. Processor manufacturers are limited by power consumption and temperature, while computer technology has evolved toward multi-core computer architectures in order to keep high performance operations continually growing. In order to fully utilize the multi-core architecture, an application program is split into a plurality of threads which can independently run on a single CPU, so that the design program can be executed in parallel to improve the overall running efficiency. Currently, when software runs on a mobile terminal, there may be a plurality of auxiliary processes of software residues on the mobile terminal, a process for collecting data to formulate a user policy, a process for popup windows, and the like. Because these residual processes occupy the resources of the mobile terminal, the mobile terminal often has the phenomena of stuck or slower running, etc.
Threads are the smallest unit of program execution flow, are one entity in a process, and are the basic units independently scheduled and dispatched by the system. The thread includes three basic states of ready, stuck, and running. The ready state refers to all conditions that the thread has to run, can logically run, and waits for a processor; the running state refers to that the thread occupies the processor to run; a stuck state refers to a thread being logically non-executable while waiting for an event (e.g., a semaphore). The thread in a stuck state will directly affect the running effect of the whole program. Therefore, how to identify the threads related to drawing on the mobile terminal and give maximum resource utilization becomes a technical problem to be solved.
Accordingly, there is a need for a method, mobile terminal and storage medium for identifying android system rendering threads to solve the above-mentioned problems.
Disclosure of Invention
The invention aims to solve the technical problems that when software runs on a mobile terminal, a plurality of software residual auxiliary processes, a process for collecting data to formulate a user strategy, a process for popup window and the like possibly exist on the mobile terminal, the residual processes occupy the resources of the mobile terminal, so that the mobile terminal is frequently blocked or runs slowly and the like, and the thread in the blocked state directly influences the running effect of the whole program, so the invention provides a method for identifying the android system drawing thread, the mobile terminal and a storage medium for solving the problems.
The technical scheme adopted for solving the technical problems is as follows:
in a first aspect, the present invention provides a method for identifying android system rendering threads, which is used for a client based on an android operating system, and includes the following steps:
creating a plurality of threads, wherein the threads comprise one or more threads of a main thread of an application process, a hardware rendering thread of an android system and a custom thread;
performing cross-process communication through threads, applying for a graphic buffer area, calling a queue buffer function of a buffer queue, and submitting graphic contents drawn by a client to a system graphic buffer area;
identifying a thread task according to the state when the process state is switched, identifying a current running thread, marking the current task_struct of the thread as ui_thread, and obtaining the state of the drawing thread;
and identifying a thread task according to the state when the process state is switched, and resetting the state of the drawing thread if the thread task is not the current running thread.
In the above technical solution, preferably, the step of identifying the thread task according to the state when the process state is switched includes:
when the current running thread is a main thread, setting the state of the drawing thread according to whether the current running thread is a foreground state, if so, marking the current running thread as the drawing thread and entering a drawing process, otherwise, resetting the state of the drawing thread or entering the process by adopting a default priority;
when the current running thread is a hardware rendering thread, setting a drawing state for the drawing thread when initializing, setting the drawing state into a thread table maintained by a kernel, entering a drawing process when recognizing that a drawing mark is set, and otherwise, entering the process by adopting a default priority;
when the current running thread is a self-defined thread, the current running thread is identified in a drawing interface queue buffer and the state of the drawing thread is set, when a client fills a graphic cache through the interface, the mark calling end is the drawing thread, when the current running thread is identified as the self-defined thread, the drawing thread enters a drawing process, and otherwise, the drawing process enters the process by adopting a default priority.
In the above technical solution, preferably, the step of identifying the thread task according to the state when the process state is switched includes: when the current running thread is a main thread, the main thread is identified by updating the process state, and then whether the current running thread is a foreground state or not is judged to set the drawing thread state.
In the above technical solution, preferably, in the step of performing cross-process communication by a thread and applying for a graphics cache region, the thread is configured to: the graphics buffer area is a graphics buffer.
In the above technical solution, preferably, the method step of identifying the android system drawing thread further includes: and the current running thread sends a drawing request, and calls an interface control ioctl function, wherein the ioctl function analyzes the service request.
In the above technical solution, preferably, the method step of identifying the android system drawing thread further includes: the current process calls a server and draws an application, and the drawing application synthesizes and draws a control window through a surface eFlinger.
In the above technical solution, preferably, in the drawing application, the synthesizing of the surface eflinger control window is performed, and in the drawing step, the surface eflinger is connected with the hw composer, and the synthesized frame buffer area is sent to the hw composer, so that the synthesized frame buffer area is used as the target buffer area.
In a third aspect, an embodiment of the present invention further provides an apparatus for identifying an android system rendering thread, where the apparatus is configured to be based on a client of an android operating system, and the apparatus includes:
the thread creation module is used for creating a plurality of threads, wherein the threads comprise one or more threads of a main thread of an application process, a hardware rendering thread of an android system and a custom thread;
the cache acquisition module is used for carrying out cross-process communication through threads and applying for a graphic cache area, calling a QueueBuffer function of the BufferQueue and submitting graphic contents drawn by the client to the system graphic cache area;
the thread drawing module is used for identifying a thread task according to the state when the process state is switched, identifying a current running thread, marking the current task_struct of the thread as ui_thread, and obtaining the state of the drawing thread;
and the thread drawing control module is used for identifying a thread task according to the state when the process state is switched, and resetting the state of the drawing thread if the thread task is not the current running thread.
In a third aspect, the present invention provides a mobile terminal comprising a memory, a processor and an identified android system rendering thread program stored on the memory and executable on the processor, the processor being adapted to perform the method as described above when executing the identified android system rendering thread program.
In a fourth aspect, the present invention provides a storage medium storing a computer program for electronic data exchange, wherein the computer program causes a computer to perform the method as described above.
The beneficial effects are that: the method for identifying the android system drawing thread provided by the invention identifies the current running thread by identifying the thread task according to the state when the process state is switched, particularly marks the main thread, the hardware rendering thread and the custom thread in different modes, specifically identifies whether the main thread is in a foreground state so as to determine whether to enter a drawing process, identifies whether the hardware rendering state is set in an initialization state so as to determine whether to enter the drawing process, and identifies whether the custom thread is set in a drawing interface queue buffer so as to determine whether to enter the drawing process; further, the process related to drawing on the mobile terminal can be identified, the maximum resource utilization is provided, and the utilization rate of the mobile system can be improved.
Drawings
FIG. 1 is a flow chart of steps of a method for identifying android system rendering threads provided by the invention;
FIG. 2 is a block diagram of a rendering thread data stream provided by the present invention;
FIG. 3 is a specific flow chart of drawing thread identification provided by the present invention;
fig. 4 is a schematic block diagram of an apparatus for identifying a drawing thread of an android system provided by the invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention clearer and more specific, the present invention will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
As used herein, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless expressly stated otherwise, as understood by those skilled in the art. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may also be present. Further, "connected" or "coupled" as used herein may include wirelessly connected or wirelessly coupled. The term "and/or" as used herein includes all or any element and all combination of one or more of the associated listed items.
It will be understood by those skilled in the art that all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs unless defined otherwise. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the prior art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
The methods discussed below (some of which are illustrated by flowcharts) may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine or computer readable medium such as a storage medium. The processor(s) may perform the necessary tasks.
Specific structural and functional details disclosed herein are merely representative and are for purposes of describing example embodiments of the present application. This application may be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein.
Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although a flowchart depicts operations as a sequential process, many of the operations can be performed in parallel, concurrently, or at the same time. Furthermore, the order of the operations may be rearranged. The process may be terminated when its operations are completed, but may have additional steps not included in the figures. The processes may correspond to methods, functions, procedures, subroutines, and the like.
Referring to fig. 1 to fig. 3, fig. 1 is a flowchart illustrating steps of a method for identifying a rendering thread of an android system according to the present invention, fig. 2 is a frame diagram of a rendering thread data flow according to the present invention, and fig. 3 is a specific flowchart illustrating a rendering thread identification according to the present invention.
According to the step flow chart provided in fig. 1, the invention provides a method for identifying android system rendering threads, which is used for a client based on an android operating system, and comprises the following steps:
s01, creating a plurality of threads, wherein the threads comprise one or more threads of a main thread of an application process, a hardware rendering thread of an android system and a custom thread;
s02, performing cross-process communication through threads, applying for a graphic buffer area, calling a QueueBuffer function of the BufferQueue, and submitting graphic contents drawn by a client to the system graphic buffer area;
s03, identifying a thread task according to the state when the process state is switched, identifying a current running thread, marking the current task_struct of the thread as ui_thread, and obtaining the state of the drawing thread;
s04, identifying a thread task according to the state when the process state is switched, and resetting the state of the drawing thread if the thread task is not the current running thread.
S05, calling a server by the current running process and drawing an application, and synthesizing and drawing a window through a SurfaceFlinger control in the drawing application.
In particular, the present invention provides an embodiment for elaborating the above steps.
The Android system provides a graph drawing system, an application program can call through a certain interface, and transfer a drawing instruction of the application program to a surface eFlinger for drawing and displaying through the given interface, wherein the specific steps and principles of the method for identifying the drawing thread of the Android system are as follows:
s01, creating a plurality of threads, wherein the threads comprise one or more of a main thread of an application process, a hardware rendering thread of an android system and a custom thread.
Threads are the smallest unit of program execution flow, are one entity in a process, and are the basic units independently scheduled and dispatched by the system. An Android program has only one Process (Process) by default, and multiple threads (threads) can be set under one Process. A thread is an execution scenario in one process, which can launch multiple threads. The thread includes three basic states of ready, stuck, and running. The ready state refers to all conditions that the thread has to run, can logically run, and waits for a processor; the running state refers to that the thread occupies the processor to run; a stuck state refers to a thread being logically non-executable while waiting for an event (e.g., a semaphore). The method provided by the invention is used for identifying the running state of the thread.
Threads in Android are mainly divided into two categories: UITMread, a main thread, also known as a UI thread; another type is WorkerThread, a custom thread, or a so-called worker thread. UITMREAD is the primary thread of application execution and is where most application code is run. All application components are created in this thread, including activities, services, content providers, broadCastReceivers, etc., and any system calls to the application components are performed in this thread. After an Android process is running, jvm (Java virtual machine) automatically starts a thread, i.e. the main thread, in which any legal operation can be performed in principle. Accessing the network is generally time-consuming, and accessing the network in the main thread may cause program to get stuck or even dead. Any time consuming operation should not be performed in the main thread. Thus, if there are long time consuming operations in the application, then a new thread must be started. Thus, a UITMread thread and one or more WorkerThread threads may exist together in a program. In addition, the Android system defaults to a hardware rendering thread HardwareRenderer, hardwareRenderer being the portal for the whole hardware accelerated rendering, the implementation is a threadedrender object, threadedrender should be in close relation to a Render thread, and threadedrender is created in the UI thread, which is mainly responsible for communicating with the rendering thread.
S02, performing cross-process communication through a drawing thread, applying for a graphic buffer area, calling a dequeue buffer function of the buffer queue, and delivering the graphic content drawn by the client to the system graphic buffer area. In particular, the graphics buffer is a graphics buffer.
Specifically, the graphics buffer area is a graphics buffer. According to the drawing principle of the Android system graphics system, whether the system is a built-in application or a three-party application, a piece of graphics cache is required to be applied from the buffer queue for preparing the content of the drawing application. Based on the image data displayed by the current application thread application, applying for a corresponding GraphicBuffer to a SurfaceFlinger in a display system of a local operating system; then, drawing the image data applied and displayed by the current application process to a GraphicBuffer; and synthesizing final image content by using the GraphiBuffer after drawing the image data through the SurfaceFlinger, and displaying the final image content as current screen information.
In addition, the allocation of the drawing memory is similar whether software drawing or hardware acceleration, namely, the request of the SurfaceFlinger service to allocate a piece of memory is needed, except that the hardware acceleration can directly allocate the memory from a frame buffer area, the drawing of the two is at the application program end, and the SurfaceFlinger is also needed to be informed to synthesize after the drawing is completed.
S03, identifying the current running thread according to the state identification task when the process state is switched, marking the current task_struct of the thread as ui_thread, and obtaining the state of the drawing thread.
When the current running thread is thread a (main thread), the thread a updates the process state (updateProcessState) and then sets the state of the drawing thread according to whether the current running thread is the foreground state. If the thread A is judged to be in the foreground state, the current task_struct of the thread A is marked as ui_thread, the state of the drawing thread is obtained, and the IOCTL function is called through the system. Where IOCTL is a function of the device driver that manages the I/O channels of the device. The I/O channel management is to control some characteristics of the device, such as the transmission baud rate of the serial port, the rotation speed of the motor, etc. In this embodiment, the drawing request sent by the current running thread is parsed.
When the current running thread is thread B (hardware rendering thread HardwareRender), setting a drawing state for thread B when initializing, and setting the drawing state into a thread table maintained by a kernel. When the thread B is identified to be in a drawing state, marking the current task_struct of the thread as ui_thread to obtain the drawing thread state, and calling an IOCTL function through a system.
When the current running thread is a thread N (unknown user-defined thread), identifying in a drawing interface QueueBuffer, setting the state of the drawing thread, and when a client performs graphic cache filling through the drawing interface QueueBuffer, marking the current task_struct of a calling end thread as ui_thread to obtain the state of the drawing thread. And when the thread N is identified to be in the set drawing state, entering a drawing flow, and calling an IOCTL function through a system.
S04, identifying tasks according to the state when the process state is switched, and if the tasks are not the current running thread, resetting the state of the drawing thread and entering the process by adopting the default priority.
When the current running thread is thread a (main thread), the thread a updates the process state (updateProcessState) and then sets the state of the drawing thread according to whether the current running thread is the foreground state. If the thread A is judged not to be in the foreground state, the drawing thread state is reset, and the IOCTL function is called through the system.
When the current running thread is thread B (hardware rendering thread HardwareRender), setting a drawing state for thread B when initializing, and setting the drawing state into a thread table maintained by a kernel. And when the thread B is identified to be in the non-set drawing state, adopting the default priority to enter a process.
When the current running thread is a thread N (unknown user-defined thread), identifying in a drawing interface QueueBuffer, setting the state of the drawing thread, and when the thread N is identified as not being in the drawing state, entering a process by adopting a default priority.
S05, calling a server by the current running process and drawing an application, and synthesizing and drawing a window through a SurfaceFlinger control in the drawing application. Preferably, the SurfaceFlinger is connected with the HWComposer, and the synthesized frame buffer is sent to the HWComposer, so that the synthesized frame buffer is used as a target buffer.
To facilitate the explanation of the data flow principle of the drawing thread of the android system, we can know from the framework chart of the drawing thread data flow provided in fig. 2:
each application App includes multiple threads (threads), and it is not certain which Thread the application App may create multiple sub-threads Thread, specifically by which Thread to perform the drawing task. When the sub-thread needs to execute the drawing task, a piece of graphic cache is applied from the buffer queue for preparing the content of the drawing application, and finally the content is transferred to the buffer queue in a queue buffer mode and then is transferred to a surface eFlinger for drawing.
In Android, a window is described by a Surface. Multiple windows need to be displayed simultaneously, and then multiple windows need to be combined. This requires the composition of the service surfacefringer control window in the display system, combining multiple windows into one, and sending to the LCD. Among them, surfacefelder adopts the concept of a Layer, i.e., layer. The surface eFlinger synthesis is based on the implementation of Display HAL, combining multiple layers. The Surface eFlink synthesizes the contents in multiple surfaces, and finally submits the synthesized contents to a rear buffer area of the screen, waits for the arrival of the next vertical synchronous signal of the screen, and then displays the synthesized contents on the screen.
A plurality of Buffer areas exist in the Surface to form a Buffer queue, graphics are transferred through the Buffer as a carrier, and the Surface is used for further packaging the Buffer, namely, the Surface is internally provided with a plurality of Buffer upper layers.
In the Android system, the graphic buffer area allocated in the system frame buffer area is used in the SurfaceFlinger service, and the graphic buffer area allocated in the memory can be used in the SurfaceFlinger service or other application programs. When other applications need to use the graphics cache, they will request that the SurfaceFlinger service allocate them, so for other applications they need only map the graphics cache returned by the SurfaceFlinger service to their own process address space for use.
The SurfaceFinger is a management core of the whole Android display system, controls superposition of all windows, and calls a GPU or a 2D accelerator for synthesis. In the interface, firstly, a dequeue buffer function of the BufferQueue is called to obtain a piece of frame buffer, then the GPU is started to synthesize the content of each window onto the piece of frame buffer, and then the queue buffer function of the BufferQueue is called. The BufferQueue will call the fbPost function of the hw composer and give the synthesized frame buffer to the hw composer as the target buffer of the 2D accelerator. Finally, the surfeflinger calls the commit function of the hw compound, and the hw compound calls the interface fb_post of the frame buffer_device_t to deliver the target buffer to the frame buffer_device_t to be sent to the screen display.
Specifically, from the specific flowchart of drawing thread identification provided in fig. 3, further we can learn:
thread a represents the main program of an application program, and each application program will default to create a main thread for lifecycle management when created. Thread A updates the progress state (updatProcessState) and then sets the rendering thread state by whether it is the foreground state. If the thread A is judged to be in a foreground state, marking the current task_struct of the thread as ui_thread, obtaining a drawing thread state, and calling an IOCTL function through a system; if the thread A is judged not to be in the foreground state, the drawing thread state is reset, and the IOCTL function is called through the system.
Thread B is a hardware rendering thread HardwareRender which defaults to the android system, and when the thread B is initialized, a drawing state is set and is set in a thread table maintained by a kernel. When the thread B is identified to be in a drawing state, marking the current task_struct of the thread as ui_thread to obtain the drawing thread state, and calling an IOCTL function through a system. And when the thread B is identified to be in the non-set drawing state, entering a process by adopting a default priority.
Thread N is an unspecified thread, and no specific marking bit can be identified, so that the identification is performed through a QueueBuffer formed by a plurality of cache areas in the Surface. Specifically, when the client performs graphics cache filling through the drawing interface QueueBuffer, the current task_struct of the calling thread is marked as ui_thread, and the drawing thread state is obtained. The subsequent identification step is consistent with the thread B, when the thread N is identified to be in a set drawing state, the current task_struct of the thread is marked as ui_thread, the drawing thread state is obtained, and an IOCTL function is called through a system. And when the thread N is identified to be in the unset drawing state, entering a process B by adopting a default priority.
In one embodiment, a mobile terminal is provided that includes a processor and a memory, the memory storing a program, the processor configured to:
creating a plurality of threads, wherein the threads comprise one or more threads of a main thread of an application process, a hardware rendering thread of an android system and a custom thread;
performing cross-process communication through threads, applying for a graphic buffer area, calling a queue buffer function of a buffer queue, and submitting graphic contents drawn by a client to a system graphic buffer area;
identifying a thread task according to the state when the process state is switched, identifying a current running thread, marking the current task_struct of the thread as ui_thread, and obtaining the state of the drawing thread;
identifying a thread task according to the state when the process state is switched, and resetting the state of the drawing thread if the thread task is not the current running thread;
the current running process calls the server and draws the application, and the drawing application synthesizes and draws the window through the SurfaceFlinger control.
Wherein the processor of the mobile terminal is configured to provide computing and control capabilities. The memory of the mobile terminal comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface of the mobile terminal is used for communicating with an external terminal through network connection. The computer program, when executed by a processor, implements a method of identifying android system rendering threads.
In other implementations, as shown in fig. 3, an embodiment of the present invention further provides an apparatus for identifying an android system rendering thread, where the apparatus is configured to be based on a client of an android operating system, and the apparatus includes:
a thread creation module 10, configured to create a plurality of threads, where the threads include one or more threads of a main thread of an application process, a hardware rendering thread of an android system, and a custom thread;
the cache obtaining module 20 is configured to perform cross-process communication through a thread and apply for a graphics buffer area, call a queue buffer function of a BufferQueue, and submit graphics content drawn by a client to a system graphics buffer area;
the thread drawing module 30 is configured to identify a thread task according to a state when the process state is switched, identify a current running thread, and mark a current task_struct of the thread as ui_thread to obtain a drawn thread state;
the thread drawing control module 40 is configured to identify a thread task according to a state when the process state is switched, and if the thread task is not a current running thread, reset the state of the drawing thread.
In a further embodiment, the invention provides a storage medium storing a computer program for electronic data exchange, wherein the computer program causes a computer to perform the method as described above.
Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), memory bus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.
In summary, the method for identifying the android system drawing thread identifies the current running thread by identifying the thread task according to the state when the process state is switched, particularly marks the main thread, the hardware rendering thread and the custom thread in different modes, specifically identifies whether the main thread is in a foreground state to determine whether to enter a drawing process, identifies whether the hardware rendering state is set in an initialization state to determine whether to enter the drawing process, and identifies whether the custom thread is set in a drawing interface queue buffer to determine whether to enter the drawing process; further, the process related to drawing on the mobile terminal can be identified, the maximum resource utilization is provided, and the utilization rate of the mobile system can be improved.
Furthermore, portions of the present application may be implemented as a computer program product, such as computer program instructions, which when executed by a computer, may invoke or provide methods and/or techniques in accordance with the present application by way of operation of the computer. Program instructions for invoking the methods of the present application may be stored in fixed or removable recording media and/or transmitted via a data stream in a broadcast or other signal bearing medium and/or stored within a working memory of a computer device operating according to the program instructions. An embodiment according to the present application comprises an apparatus comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein the computer program instructions, when executed by the processor, trigger the apparatus to operate a method and/or a solution according to the embodiments of the present application as described above.
Finally, it should be noted that: it will be evident to those skilled in the art that the present application is not limited to the details of the foregoing illustrative embodiments, and that the present application may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned. Furthermore, it is evident that the word "comprising" does not exclude other elements or steps, and that the singular does not exclude a plurality. A plurality of units or means recited in the system claims can also be implemented by means of software or hardware by means of one unit or means. The terms first, second, etc. are used to denote a name, but not any particular order. The application of the present invention is not limited to the above examples, and the technical solutions described in the foregoing embodiments may be modified, or some technical features thereof may be replaced by equivalent ones; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims (7)

1. A method for identifying android system rendering threads for a client based on an android operating system, comprising the steps of:
creating a plurality of threads, wherein the threads comprise one or more threads of a main thread of an application process, a hardware rendering thread of an android system and a custom thread;
performing cross-process communication through threads, applying for a graphic buffer area, calling a queue buffer function of a buffer queue, and submitting graphic contents drawn by a client to a system graphic buffer area;
identifying a thread task according to the state when the process state is switched, identifying a current running thread, marking the current task_struct of the thread as ui_thread, and obtaining the state of the drawing thread;
identifying a thread task according to the state when the process state is switched, and resetting the state of the drawing thread if the thread task is not the current running thread;
the current running process calls a server and draws an application, and the drawing application synthesizes and draws through a SurfaceFlinger control window;
the SurfaceFlinger is connected with the HW compound, and the synthesized frame buffer area is sent to the HW compound to be used as a target buffer area;
the step of identifying the thread task according to the state when the process state is switched comprises the following steps:
when the current running thread is a main thread, setting the state of the drawing thread according to whether the current running thread is a foreground state, if so, marking the current running thread as the drawing thread and entering a drawing process, otherwise, resetting the state of the drawing thread and entering the process by adopting a default priority;
when the current running thread is a hardware rendering thread, setting a drawing state for the drawing thread when the current running thread is initialized, setting the drawing state into a thread table maintained by a kernel, entering a drawing process when the current running thread is identified as a drawing mark setting state, and otherwise, entering the process by adopting a default priority;
when the current running thread is a custom thread, identifying in a drawing interface queue buffer and setting the state of the drawing thread, when a client performs graphic cache filling through the drawing interface queue buffer, marking a calling end as the drawing thread, and when the current running thread is identified as the custom thread, entering a drawing process, otherwise, entering the process by adopting a default priority; and identifying a thread task according to the state when the process state is switched, and resetting the state of the drawing thread if the thread task is not the current running thread.
2. The method for identifying a rendering thread of an android system as recited in claim 1, wherein the step of identifying a thread task based on a state at a process state switch comprises:
when the current running thread is a main thread, the main thread is identified by updating the process state, and then whether the current running thread is a foreground state or not is judged to set the drawing thread state.
3. The method for identifying an android system rendering thread as recited in claim 1, wherein said step of cross-process communication and application of a graphics cache region by the thread comprises:
the graphics buffer area is a graphics buffer.
4. The method for identifying an android system rendering thread of claim 1, wherein said method step of identifying an android system rendering thread further comprises:
and the current running thread sends a drawing request, and calls an interface control ioctl function, wherein the ioctl function analyzes the drawing request.
5. An apparatus for identifying android system rendering threads for use with a client based on an android operating system, the apparatus comprising:
the thread creation module is used for creating a plurality of threads, wherein the threads comprise one or more threads of a main thread of an application process, a hardware rendering thread of an android system and a custom thread;
the cache acquisition module is used for carrying out cross-process communication through threads and applying for a graphic cache area, calling a QueueBuffer function of the BufferQueue and submitting graphic contents drawn by the client to the system graphic cache area;
the thread drawing module is used for identifying a thread task according to the state when the process state is switched, identifying a current running thread, marking the current task_struct of the thread as ui_thread, and obtaining the state of the drawing thread;
the thread drawing control module is used for identifying a thread task according to the state when the process state is switched, and resetting the state of a drawing thread if the thread task is not the current running thread;
the current running process calls a server and draws an application, and the drawing application synthesizes and draws through a SurfaceFlinger control window;
the SurfaceFlinger is connected with the HW compound, and the synthesized frame buffer area is sent to the HW compound to be used as a target buffer area;
the step of identifying the thread task according to the state when the process state is switched comprises the following steps:
when the current running thread is a main thread, setting the state of the drawing thread according to whether the current running thread is a foreground state, if so, marking the current running thread as the drawing thread and entering a drawing process, otherwise, resetting the state of the drawing thread and entering the process by adopting a default priority;
when the current running thread is a hardware rendering thread, setting a drawing state for the drawing thread when the current running thread is initialized, setting the drawing state into a thread table maintained by a kernel, entering a drawing process when the current running thread is identified as a drawing mark setting state, and otherwise, entering the process by adopting a default priority;
when the current running thread is a custom thread, identifying in a drawing interface queue buffer and setting the state of the drawing thread, when a client performs graphic cache filling through the drawing interface queue buffer, marking a calling end as the drawing thread, and when the current running thread is identified as the custom thread, entering a drawing process, otherwise, entering the process by adopting a default priority; and identifying a thread task according to the state when the process state is switched, and resetting the state of the drawing thread if the thread task is not the current running thread.
6. A mobile terminal comprising a memory, a processor and an identified android system rendering thread program stored on the memory and executable on the processor, the processor implementing the method of any one of claims 1-4 when executing the identified android system rendering thread program.
7. A storage medium storing a computer program for electronic data exchange, wherein the computer program causes a computer to perform the method of any one of claims 1-4.
CN202110239090.XA 2021-03-03 2021-03-03 Method and device for identifying android system drawing threads, mobile terminal and storage medium Active CN113051047B (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202110239090.XA CN113051047B (en) 2021-03-03 2021-03-03 Method and device for identifying android system drawing threads, mobile terminal and storage medium
EP22762325.3A EP4303725A1 (en) 2021-03-03 2022-01-18 Method and device for identifying android system drawing thread, and mobile terminal and storage medium
PCT/CN2022/072611 WO2022183856A1 (en) 2021-03-03 2022-01-18 Method and device for identifying android system drawing thread, and mobile terminal and storage medium
US18/548,904 US20240143395A1 (en) 2021-03-03 2022-01-18 Method and device for identifying android system drawing thread, and mobile terminal and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110239090.XA CN113051047B (en) 2021-03-03 2021-03-03 Method and device for identifying android system drawing threads, mobile terminal and storage medium

Publications (2)

Publication Number Publication Date
CN113051047A CN113051047A (en) 2021-06-29
CN113051047B true CN113051047B (en) 2023-06-27

Family

ID=76510086

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110239090.XA Active CN113051047B (en) 2021-03-03 2021-03-03 Method and device for identifying android system drawing threads, mobile terminal and storage medium

Country Status (4)

Country Link
US (1) US20240143395A1 (en)
EP (1) EP4303725A1 (en)
CN (1) CN113051047B (en)
WO (1) WO2022183856A1 (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113051047B (en) * 2021-03-03 2023-06-27 驭新智行科技(宁波)有限公司 Method and device for identifying android system drawing threads, mobile terminal and storage medium
CN113918249B (en) * 2021-09-14 2023-11-21 北京房江湖科技有限公司 Method and device for realizing background fuzzy control
CN117130774B (en) * 2023-04-28 2024-07-12 荣耀终端有限公司 Thread acceleration processing method and device
CN117687771B (en) * 2023-07-24 2024-09-06 荣耀终端有限公司 Buffer allocation device, electronic equipment and storage medium

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110109528A (en) * 2019-03-29 2019-08-09 努比亚技术有限公司 Management-control method, mobile terminal and the computer readable storage medium of application program

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8629878B2 (en) * 2009-08-26 2014-01-14 Red Hat, Inc. Extension to a hypervisor that utilizes graphics hardware on a host
CN108509260B (en) * 2018-01-31 2021-08-13 深圳市万普拉斯科技有限公司 Thread identification processing method and device, computer equipment and storage medium
CN110489228B (en) * 2019-07-16 2022-05-17 华为技术有限公司 Resource scheduling method and electronic equipment
CN111367741B (en) * 2020-02-28 2022-07-08 Oppo广东移动通信有限公司 User interface card pause detection method and device and electronic equipment
CN111831462A (en) * 2020-07-01 2020-10-27 Oppo广东移动通信有限公司 IO request processing method and device, storage medium and electronic equipment
CN113051047B (en) * 2021-03-03 2023-06-27 驭新智行科技(宁波)有限公司 Method and device for identifying android system drawing threads, mobile terminal and storage medium

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110109528A (en) * 2019-03-29 2019-08-09 努比亚技术有限公司 Management-control method, mobile terminal and the computer readable storage medium of application program

Also Published As

Publication number Publication date
WO2022183856A1 (en) 2022-09-09
US20240143395A1 (en) 2024-05-02
EP4303725A1 (en) 2024-01-10
CN113051047A (en) 2021-06-29

Similar Documents

Publication Publication Date Title
CN113051047B (en) Method and device for identifying android system drawing threads, mobile terminal and storage medium
US11164280B2 (en) Graphics layer processing in a multiple operating systems framework
US10127628B2 (en) Method and system to virtualize graphic processing services
CN113110910B (en) Method, system and equipment for realizing security Zhuo Rongqi
US10074206B1 (en) Network-optimized graphics library for virtualized graphics processing
US9734546B2 (en) Split driver to control multiple graphics processors in a computer system
CN107292807B (en) Graph synthesis method, window setting method and system
CN112269603A (en) Graphic display method and device for compatibly running Android application on Linux
US20150193904A1 (en) Graphics acceleration for applications executing on mobile devices with multi-operating system environment
US20190080017A1 (en) Method, system, and device that invokes a web engine
US20210049730A1 (en) Systems and methods for using egl with an opengl api and a vulkan graphics driver
US20220292628A1 (en) Image processing method and apparatus
WO2023087778A1 (en) Window information processing method and apparatus, electronic device, and storage medium
CN106683035B (en) GPU acceleration method and device
WO2018120992A1 (en) Window rendering method and terminal
US20140059114A1 (en) Application service providing system and method and server apparatus and client apparatus for application service
US9041719B2 (en) Method and system for transparently directing graphics processing to a graphical processing unit (GPU) of a multi-GPU system
CN114116227A (en) Display method, device and equipment based on Wayland protocol without GPU support
CN111414150B (en) Game engine rendering method and device, electronic equipment and computer storage medium
WO2023221822A1 (en) Data processing method, electronic device, and readable storage medium
WO2015154226A1 (en) Method, device and processor for data communication in virtualized environment
WO2023138020A1 (en) Image generation method and apparatus, electronic device, and storage medium
CN117992189A (en) Window realization method under multiple systems and electronic equipment
US9754560B2 (en) Pooling and tiling data images from memory to draw windows on a display device
WO2019079940A1 (en) Graphics processing method, and related apparatus and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right

Effective date of registration: 20230511

Address after: Z0042, 1st Floor, Building 4, No. 88 Meishan Qixing Road, Beilun District, Ningbo City, Zhejiang Province, 315800

Applicant after: Yuxin Zhixing Technology (Ningbo) Co.,Ltd.

Address before: 516003 No.86, hechangqi Road West, Zhongkai high tech Zone, Huizhou City, Guangdong Province

Applicant before: HUIZHOU TCL MOBILE COMMUNICATION Co.,Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant