Method and system for displaying multiple GUIs (Graphical User Interface) of vehicle-mounted equipment and medium

Abstract

The invention belongs to the technical field of vehicle-mounted equipment display, and particularly relates to a method for displaying a plurality of GUIs (Graphical User Interface) of vehicle-mounted equipment, which comprises the following steps: firstly, sensing an FB use application by a main GUI through a communication interface, initializing based on preset startup display configuration, and establishing an FB authority management mechanism; and then connecting the auxiliary GUI with the FB through a communication interface, interacting with the main GUI through a public interface, and performing display switching between the auxiliary GUI and the main GUI based on an event monitoring mechanism. According to the method and the device, the problem that in the prior art, an existing GUI and a third-party GUI of the vehicle-mounted equipment are difficult to reuse the FB can be solved.

Description

Technical Field

[0001] The present invention belongs to the technical field of vehicle-mounted device display, and in particular relates to a method, system and medium for displaying multiple GUIs of vehicle-mounted equipment. Background Art

[0002] In intelligent vehicle systems, vehicle-mounted video surveillance equipment, as a key embedded device, is often equipped with a display for human-computer interaction. Graphical user interface (GUI), as the core carrier of human-computer interaction, is widely used in scenarios such as real-time video output, video playback, and vehicle parameter settings. At present, vehicle-mounted devices can usually only display a set of GUIs with a predetermined drawing scheme. However, for embedded devices that can flexibly customize both software and hardware, this single drawing scheme greatly limits their ability to adapt to third-party GUIs.

[0003] The conventional display method of in-vehicle equipment is that the GUI graphics drawing layer draws each frame of graphics image, and then uses the copy function provided by the chip to copy the graphics image data to the FrameBuffer (FB), that is, the video memory. The display then reads the data in the FB and outputs it to the screen for display after rendering. Based on this conventional display solution, if a third party wants to implement a new GUI on an in-vehicle device, it can only develop it based on the existing drawing layer capabilities. However, this has many disadvantages. On the one hand, third-party developers need to spend a lot of time and energy to learn and understand the existing drawing layer technology, which has a high learning cost; on the other hand, the display effects presented by the existing drawing layer are often difficult to meet diverse needs.

[0004] When trying to adapt a third-party GUI to an in-vehicle device, there are two key issues. First, there are serious compatibility issues between the third-party GUI drawing scheme and the existing GUI drawing scheme of the in-vehicle device, which makes it difficult to smoothly integrate the third-party GUI into the in-vehicle system. Second, there are difficulties in reusing FB between the third-party GUI and the existing GUI, resulting in inefficient use of system resources and even data conflicts. These problems seriously restrict the flexibility and scalability of the in-vehicle device in terms of GUI display, and an innovative solution is urgently needed to solve them. Summary of the invention

[0005] The technical problem solved by the present invention is to provide a method, system and medium for displaying multiple GUIs of an in-vehicle device, so as to solve the problem in the prior art that it is difficult to reuse FBs between the existing GUI of the in-vehicle device and the third-party GUI.

[0006] The basic solution provided by the present invention is a method for displaying multiple GUIs of an in-vehicle device, comprising:

[0007] S1: The main GUI perceives the FB usage application through the communication interface, initializes based on the preset startup display configuration, and establishes an FB permission management mechanism;

[0008] S2: Connect the secondary GUI to the FB through the communication interface, interact with the main GUI through the common interface, and perform display switching between the secondary GUI and the main GUI based on the event listening mechanism;

[0009] The specific FB permission management mechanism is as follows: when receiving a permission application, it determines the FB occupancy status in real time. When it is not occupied, it marks the occupancy and de-initializes the FB. When it is released, it restores the FB binding and refreshes the display content;

[0010] The specific event listening mechanism is as follows: after initialization, it applies for the FB usage right. After obtaining authorization, it renders the interface in real time through loop refreshing. When a switching event is detected, it releases the permission and triggers the main GUI to resume display. When it receives an activation instruction again, it applies for the permission again.

[0011] Furthermore, the preset startup display configuration in S1 is to display the main GUI by default or allow the secondary GUI to start first.

[0012] Furthermore, S1 includes:

[0013] S1-1: After the in-vehicle device is powered on, the main GUI detects whether the startup display configuration shows the main GUI;

[0014] S1-2: If the startup display configuration is to display the main GUI, it immediately calls FB initialization and displays the main GUI interface on the in-vehicle device screen. At this time, the FB is occupied by the main GUI;

[0015] S1-3: If the startup display configuration is that the secondary GUI starts first, the main GUI does not call FB initialization, and the in-vehicle device screen is in a blank state, waiting for the secondary GUI to apply for permission.

[0016] Furthermore, S2 includes:

[0017] S2-1: Connect the secondary GUI to the FB through the communication interface and interact with the main GUI through the common interface;

[0018] S2-2: After the secondary GUI starts, it calls the common library API to detect the current environment, and then sends an FB usage right application to the main GUI;

[0019] S2-3: When the main GUI receives the FB usage right application sent by the secondary GUI and detects that the FB is not currently occupied, it marks the FB as occupied and returns an application success signal to the secondary GUI;

[0020] S2-4: After the secondary GUI obtains the FB usage permission, it calls the FB de-initialization to clear the residual display data of the primary GUI, displays the secondary GUI interface, and updates the secondary GUI interface through the loop refresh API.

[0021] Further, S2 further includes:

[0022] S2-5: The secondary GUI detects that it has received the primary GUI switching event and calls the API to release the FB usage right;

[0023] S2-6: When the primary GUI receives the FB usage right release request, it marks the FB as unoccupied;

[0024] S2-7: The primary GUI restores the FB binding and re-initializes, loads the primary GUI interface, and refreshes the in-vehicle device display window;

[0025] S2-8: When the secondary GUI switching event is detected again, S2-1 to S2-4 are repeatedly executed.

[0026] A multi-GUI display system for an in-vehicle device, which is applied to the above-mentioned multi-GUI display method for an in-vehicle device, includes a primary GUI, a secondary GUI, and an FB. The primary GUI is connected to the FB through a communication interface. The primary GUI is used to sense the FB usage application, initialize based on a preset boot display configuration, and establish an FB permission management mechanism;

[0027] The secondary GUI interacts with the primary GUI through a common interface. The secondary GUI is used to perform the display switching between the secondary GUI and the primary GUI based on an event listening mechanism;

[0028] The FB permission management mechanism is specifically: when receiving a permission application, it determines the FB occupancy status in real time. When it is not occupied, it marks it as occupied and de-initializes the FB. When it is released, it restores the FB binding and refreshes the display content;

[0029] The event listening mechanism is specifically: after initialization, it applies for the FB usage right. After obtaining authorization, it renders the interface in real time through loop refreshing. When a switching event is detected, it releases the permission and triggers the primary GUI to resume display. When it receives an activation instruction again, it applies for the permission again.

[0030] An electronic device includes a processor and a memory. Programs or instructions are stored in the processor. The processor executes the above-mentioned multi-GUI display method for an in-vehicle device by calling the programs and instructions stored in the memory.

[0031] A computer-readable storage medium stores programs or instructions, and the programs or instructions cause a computer to execute the above-mentioned multi-GUI display method for an in-vehicle device.

[0032] The principle and advantages of the present invention are as follows: A method for multi-GUI display of in-vehicle devices in this application realizes conflict-free display of multiple GUIs through the collaborative control of the main GUI, secondary GUI, and FrameBuffer (FB). Among them, the main GUI serves as the system core management unit, perceives the FB usage application of external GUIs through the communication interface, completes initialization based on the preset power-on display configuration (default to display the main GUI or allow the secondary GUI to start preferentially), and establishes an FB permission management mechanism: when receiving a permission application, it determines the FB occupancy status in real time. When it is not occupied, it marks the occupancy and de-initializes the FB. When released, it restores the FB binding and refreshes the display content to achieve exclusive scheduling of the FB. The secondary GUI interacts with the main GUI through a common interface and completes display switching based on the event listening mechanism: after initialization, it applies for the right to use the FB. After obtaining authorization, it renders the interface in real time through cyclic refreshing. When a switching event is detected, it releases the permission and triggers the main GUI to resume display. When it receives an activation instruction again, it applies for permission again.

[0033] Therefore, the technical solution of this application realizes the FB time-sharing multiplexing mechanism of "unified permission management of the main GUI + on-demand application and release of the secondary GUI", enabling the in-vehicle device to seamlessly integrate third-party applications without modifying the original GUI architecture, solving the compatibility problem between the third-party GUI and the existing GUI, realizing efficient reuse of display resources, and being applicable to embedded in-vehicle devices that require dynamic switching of multiple GUI scenarios such as monitoring, navigation, and parameter setting. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 It is a flowchart of an embodiment of the present invention;

[0035] Figure 2 It is a processing logic block diagram of an embodiment of the present invention;

[0036] Figure 3 It is a system structure block diagram of an embodiment of the present invention;

[0037] Figure 4 It is a schematic diagram of the structure of an electronic device in the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0038] The following is a further detailed description through specific embodiments:

[0039] The marks in the accompanying drawings of the specification include: electronic device 400, processor 401, memory 402, input device 403, output device 404.

[0040] The GUI of in-vehicle devices, such as the GUI of in-vehicle video surveillance devices, has functions such as parameter setting, real-time video output, and video playback. Currently, in-vehicle devices can only display the GUI of one drawing scheme. For embedded devices that can be trimmed both in software and hardware, the single drawing scheme limits the flexibility of third-party GUIs. If a third-party GUI is to be adapted to in-vehicle devices, currently, the functions of the original GUI can only be discarded, which will bring a large amount of GUI development work for the original functions.

[0041] To solve the above difficulties, this application provides the ability to multiplex the FB time-sharing. The third party and the original GUI (hereinafter, the third-party GUI is referred to as the secondary GUI, and the original GUI is referred to as the primary GUI) each complete their own initialization and startup processes. It can be configured which GUI is displayed by default at the first startup. The secondary GUI controls the display output of the monitor GUI by applying for and releasing the FB, achieving the purpose of FB time-sharing multiplexing, enabling two sets of GUIs with different drawing layer schemes to run on in-vehicle devices simultaneously. For the secondary GUI, only incremental development of new functions is required, and the functions of the primary GUI can be reused. The embodiments are basically as shown in the appendix Figure 1 and Figure 2 shown: A method for displaying multiple GUIs on an in-vehicle device, including:

[0042] S1: The primary GUI senses the FB usage application through the communication interface, initializes based on the preset startup display configuration, and establishes an FB permission management mechanism. The preset startup display configuration includes two types. One is to default to display the primary GUI, and the other is to allow the secondary GUI to start preferentially. The FB permission management mechanism is specifically as follows: when receiving a permission application, the FB occupancy status is determined in real time. When it is not occupied, it is marked as occupied and the FB is de-initialized. When released, the FB binding is restored and the display content is refreshed;

[0043] Therefore, the detailed implementation steps of S1 include:

[0044] S1-1: After the in-vehicle device is powered on, the primary GUI detects whether the startup display configuration is to display the primary GUI;

[0045] S1-2: If the startup display configuration is to display the primary GUI, the FB initialization is immediately called, and the primary GUI interface is displayed on the in-vehicle device screen. At this time, the FB is occupied by the primary GUI;

[0046] S1-3: If the startup display configuration is that the secondary GUI starts preferentially, the primary GUI does not call FB initialization, and the in-vehicle device screen is blank, waiting for the secondary GUI to apply for permission.

[0047] To better elaborate on the technical solution of the above S1 step, taking the primary monitoring GUI and the third-party secondary GUI in the in-vehicle scenario as examples, the application scenarios include:

[0048] 1. The in-vehicle device defaults to display the main GUI when powered on: After the in-vehicle device is powered on, if the main GUI detects that the default configuration is to display the monitoring main interface, it immediately calls FB for initialization and displays the real-time monitoring screen and vehicle parameters, such as vehicle speed, battery voltage, etc. on the in-vehicle device screen. At this time, FB is occupied by the main GUI and is in the "marked" state.

[0049] 2. The in-vehicle device defaults to give priority to starting the secondary GUI when powered on: When the user configures "do not display the main interface when powered on" through the main GUI, the main GUI of the in-vehicle device does not call FB for initialization after being powered on, and the screen is in the "blank" state, waiting for the secondary GUI to apply for permission. For example, in a taxi scenario, the driver sets to directly enter the order-taking software interface when powered on, and at this time, the secondary GUI is the first startup interface.

[0050] S2: Connect the secondary GUI to FB through the communication interface and interact with the main GUI through the common interface to perform the display switching between the secondary GUI and the main GUI based on the event listening mechanism. The event listening mechanism is specifically as follows: Apply for the right to use FB after initialization, and after obtaining authorization, refresh and render the real-time interface through a loop. When a switching event is detected, release the permission and trigger the main GUI to resume display. When receiving the activation instruction again, re-apply for permission. Among them, S2 includes:

[0051] S2-1: Connect the secondary GUI to FB through the communication interface and interact with the main GUI through the common interface.

[0052] S2-2: After the secondary GUI starts, call the common library API to detect the current environment, and then send an application for the right to use FB to the main GUI.

[0053] S2-3: When the main GUI receives the application for the right to use FB sent by the secondary GUI and detects that FB is not currently occupied, mark FB as the occupied state and return a successful application signal to the secondary GUI.

[0054] S2-4: After the secondary GUI obtains the right to use FB, call FB for de-initialization, clear the residual display data of the main GUI, display the secondary GUI interface, and update the secondary GUI interface through a loop to refresh the API.

[0055] In this application, after the secondary GUI starts, it detects the current environment by calling the common library API. When it finds that FB is not occupied or the main GUI has released the permission, it sends an application for the right to use FB to the main GUI.

[0056] Subsequently, when the main GUI detects that FB is not currently occupied, such as when the main GUI has not initialized FB or the user actively exits the main GUI, it marks FB as "occupied" and returns "application successful" to the secondary GUI.

[0057] After the secondary GUI obtains the permission, it calls the FB de-initialization to clear the display data remaining in the primary GUI, and draws the display content of the secondary GUI onto the FB, such as navigation maps, route planning, etc. The vehicle-mounted device interface is updated in real time through the loop refreshing API. At this time, the display screen of the vehicle-mounted device shows the interface of the secondary GUI, and the primary GUI is in the background "listening" state.

[0058] When a switching event occurs, S2 further includes:

[0059] S2-5: The secondary GUI detects that it has received the primary GUI switching event and calls the API to release the right to use the FB;

[0060] S2-6: The primary GUI receives the FB usage right release request and marks the FB as unoccupied;

[0061] S2-7: The primary GUI restores the FB binding and re-initializes, loads the primary GUI interface, and refreshes the vehicle-mounted device display window;

[0062] S2-8: When the secondary GUI switching event is detected again, S2-1 to S2-4 are repeatedly executed.

[0063] Among them, taking the actual scenario of a user using a vehicle-mounted device as an example, when the user clicks on the vehicle-mounted device display screen, such as the "back" button, or triggers a switching event through a physical button, after the secondary GUI detects the event, it calls the API to release the right to use the FB. At this time, the processing logic of the primary GUI is as follows:

[0064] 1. The primary GUI receives the release request and marks the FB as "unoccupied"; 2. Restores the FB binding and re-initializes, and loads the display screen of the primary GUI; 3. Refreshes all display windows, such as the real-time video stream is re-connected, and the vehicle-mounted parameters are updated in real time and rendered to the canvas; at this time, the vehicle-mounted device display interface shows the interface of the primary GUI, and the interface of the secondary GUI is closed.

[0065] When switching to the secondary GUI again, the secondary GUI repeats the following process:

[0066] 1. Calls the API to apply for the right to use the FB; 2. The primary GUI detects that the FB is currently unoccupied and marks it as "occupied"; 3. The secondary GUI de-initializes the FB, clears the display screen of the primary GUI, draws the secondary GUI screen onto the vehicle-mounted device display interface and refreshes it in a loop.

[0067] Therefore, based on the above implementation steps, the key technologies in this application include the following three points:

[0068] First, the secondary GUI does not need to adapt to the drawing layer of the primary GUI. By only applying / releasing the FB permission through the common library API, the display resources of the vehicle-mounted device can be reused without rewriting the underlying rendering logic of the primary GUI;

[0069] Second, the main GUI avoids resource competition of in-vehicle devices through "marking occupancy status". For example, taking the monitoring main GUI and the navigation secondary GUI as an example, when the navigation is running, the main GUI cannot forcibly occupy the FB. After the navigation exits, the main GUI automatically resumes display without restarting the in-vehicle device or re-initializing the underlying driver;

[0070] Third, for different user groups, the main GUI can be freely selected to start by default or the secondary GUI to start preferentially to meet the needs of different users; for example, taxis can choose to start the order-receiving secondary GUI interface preferentially, and private cars can choose to start the monitoring main GUI by default.

[0071] Therefore, the technology of this application realizes the FB time-sharing multiplexing mechanism of "unified permission management of the main GUI + on-demand application release of the secondary GUI", enabling the in-vehicle device to seamlessly integrate third-party applications (such as navigation and entertainment software) without modifying the original GUI architecture, solving the problems of poor compatibility and high development cost in the traditional solution, and improving the flexibility and scalability of the embedded device.

[0072] As Figure 3 shown, in another embodiment of this application, there is also a multi-GUI display system for in-vehicle devices, which is applied to the above-mentioned multi-GUI display method for in-vehicle devices, including a main GUI, a secondary GUI, and an FB. The main GUI is connected to the FB through a communication interface. The main GUI is used to sense the FB usage application, initialize based on the preset boot display configuration, and establish an FB permission management mechanism;

[0073] The secondary GUI interacts with the main GUI through a common interface. The secondary GUI is used to perform display switching between the secondary GUI and the main GUI based on an event listening mechanism;

[0074] The specific FB permission management mechanism is: when receiving a permission application, it determines the FB occupancy status in real time. When it is not occupied, it marks the occupancy and de-initializes the FB. When it is released, it restores the FB binding and refreshes the display content;

[0075] The specific event listening mechanism is: after initialization, it applies for the right to use the FB. After obtaining authorization, it renders the interface in real time by cyclic refreshing. When a switching event is detected, it releases the permission and triggers the main GUI to resume display. When it receives an activation instruction again, it applies for permission again.

[0076] As Figure 4 shown, in another embodiment of this embodiment, there is also an electronic device. The electronic device 400 includes one or more processors 401 and a memory 402.

[0077] The processor 401 may be a central processing unit (CPU) or other forms of processing units with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 400 to perform desired functions.

[0078] The memory 402 may include one or more computer program products, and the computer program products may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory, etc. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage media, and the processor 401 may run the program instructions to implement a method for displaying multiple GUIs of a vehicle-mounted device according to any embodiment of the present invention described above and / or other desired functions. Various contents such as initial extrinsic parameters, thresholds, etc. may also be stored in the computer-readable storage media.

[0079] In one example, the electronic device 400 may further include: an input device 403 and an output device 404, and these components are interconnected through a bus system and / or other forms of connection mechanisms (not shown). The input device 403 may include, for example, a keyboard, a mouse, etc. The output device 404 may output various information to the outside, including warning prompt information, braking force, etc. The output device 404 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0080] Of course, for simplicity, Figure 4 only some of the components related to the present invention in the electronic device 400 are shown, and components such as buses, input / output interfaces, etc. are omitted. In addition, according to specific application scenarios, the electronic device 400 may further include any other appropriate components.

[0081] In addition to the above methods and devices, an embodiment of the present invention may also be a computer program product, which includes computer program instructions that, when run by a processor, cause the processor to execute the steps of a method for displaying multiple GUIs of a vehicle-mounted device provided by any embodiment of the present invention.

[0082] The computer program product can be written in any combination of one or more programming languages for executing the program code of the operations of the embodiments of the present invention. The programming languages include object-oriented programming languages such as Java, C++, etc., and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, executed as an independent software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0083] In addition, an embodiment of the present invention can also be a computer-readable storage medium, on which computer program instructions are stored. When the computer program instructions are run by a processor, the processor is caused to execute the steps of a method for displaying multiple GUIs of a vehicle-mounted device provided by any embodiment of the present invention.

[0084] The above are only embodiments of the present invention. Common knowledge such as the specific structures and characteristics in the solutions is not described in detail here. Those of ordinary skill in the art know all the common technical knowledge in the technical field to which the invention belongs before the filing date or the priority date, can know all the prior arts in this field, and have the ability to apply the conventional experimental means before this date. Those of ordinary skill in the art can, under the inspiration given in this application, combine their own abilities to complete and implement this solution. Some typical well-known structures or well-known methods should not be an obstacle for those of ordinary skill in the art to implement this application. It should be noted that for those skilled in the art, without departing from the structure of the present invention, several deformations and improvements can still be made, and these should also be regarded as the protection scope of the present invention, and these will not affect the implementation effect of the present invention and the practicability of the patent. The protection scope required by this application should be based on the content of its claims, and the specific implementation manners and the like recorded in the specification can be used to explain the content of the claims.

Claims

1. A method for displaying multiple GUIs on a vehicle-mounted device, characterized in that: including: S1: The main GUI perceives the FB usage application through the communication interface, initializes based on the preset startup display configuration, and establishes an FB permission management mechanism; S2: The secondary GUI is connected to the FB through the communication interface, interacts with the main GUI through the common interface, and performs display switching between the secondary GUI and the main GUI based on the event listening mechanism; The specific FB permission management mechanism is as follows: when receiving a permission application, it determines the FB occupancy status in real time. When not occupied, it marks the occupancy and de-initializes the FB. When released, it restores the FB binding and refreshes the display content; The specific event listening mechanism is as follows: after initialization, it applies for the FB usage right. After obtaining authorization, it refreshes and renders the interface in real time through a loop. When a switching event is detected, it releases the permission and triggers the main GUI to resume display. When receiving an activation instruction again, it applies for the permission again.

2. The method for displaying multiple GUIs of a vehicle-mounted device according to claim 1, wherein: The preset startup display configuration in S1 is to display the main GUI by default or allow the secondary GUI to start first.

3. The method for displaying multiple GUIs of an in-vehicle device according to claim 2, wherein: S1 includes: S1-1: After the in-vehicle device is powered on, the main GUI detects whether the startup display configuration shows the main GUI; S1-2: If the startup display configuration is to display the main GUI, it immediately calls FB initialization and displays the main GUI interface on the in-vehicle device screen. At this time, the FB is occupied by the main GUI; S1-3: If the startup display configuration is that the secondary GUI starts first, the main GUI does not call FB initialization, and the in-vehicle device screen is blank, waiting for the secondary GUI to apply for permission.

4. A method for displaying multiple GUIs of a vehicle-mounted device according to claim 3, characterized in that: S2 includes: S2-1: Connect the secondary GUI to the FB through the communication interface and interact with the main GUI through the common interface; S2-2: After the secondary GUI starts, it calls the common library API to detect the current environment, and then sends an FB usage right application to the main GUI; S2-3: When the main GUI receives the FB usage right application sent by the secondary GUI and detects that the FB is not currently occupied, it marks the FB as occupied and returns an application success signal to the secondary GUI; After the secondary GUI obtains the FB usage permission, it calls FB de-initialization, clears the residual display data of the main GUI, displays the secondary GUI interface, and updates the secondary GUI interface through a loop to refresh the API.

5. A method for displaying multiple GUIs of a vehicle-mounted device according to claim 4, characterized in that: S2 also includes: S2-5: The secondary GUI detects that it has received the main GUI switching event and calls the API to release the FB usage right; S2-6: The main GUI receives the FB usage right release request and marks the FB as unoccupied; S2-7: The main GUI restores the FB binding and re-initializes, loads the main GUI interface, and refreshes the in-vehicle device display window; When detecting the secondary GUI switching event again, repeat S2-1 to S2-4.

6. A multiple GUI display system for a vehicle-mounted device, which is applied to the multiple GUI display method for a vehicle-mounted device according to any one of claims 1-5 above, and is characterized in that: including the main GUI, the secondary GUI, and the FB. The main GUI is connected to the FB through the communication interface. The main GUI is used to perceive the FB usage application, initialize based on the preset startup display configuration, and establish an FB permission management mechanism; The secondary GUI interacts with the main GUI through the common interface. The secondary GUI is used to perform display switching between the secondary GUI and the main GUI based on the event listening mechanism; The specific FB permission management mechanism is as follows: when a permission application is received, the occupancy status of FB is determined in real time. When it is not occupied, it is marked as occupied and FB is de-initialized. When it is released, the FB binding is restored and the display content is refreshed. The specific event listening mechanism is as follows: after initialization, the right to use FB is applied for. After obtaining authorization, the real-time rendering interface is refreshed through a loop. When a switching event is detected, the permission is released and the main GUI is triggered to resume display. When an activation instruction is received again, the permission is applied for again.

7. An electronic device, characterized in that: It includes a processor and a memory. Programs or instructions are stored in the processor. The processor executes a method for displaying multiple GUIs of a vehicle-mounted device according to any one of claims 1-5 above by calling the programs and instructions stored in the memory.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores programs or instructions, and the programs or instructions cause the computer to execute a method for displaying multiple GUIs of a vehicle-mounted device according to any one of claims 1-5 above.

Images