Cross-system same-screen control operation method based on Android intelligent terminal

Abstract

The invention provides a cross-system same-screen control operation method based on an Android intelligent terminal, and relates to the technical field of Android system same-screen control. The method comprises the following steps: collecting screen data of the medical insurance terminal; encoding the screen data into an RGB format and transmitting the screen data to a control end, so that the control end displays a screen picture of the medical insurance terminal; an input event of the control end is monitored and converted into the medical insurance terminal, and the medical insurance terminal is remotely controlled through the control end; the input events include mouse input and keyboard input. According to the cross-system same-screen control operation method based on the Android intelligent terminal, the technical problems of poor compatibility and low data transmission efficiency of existing medical insurance terminal cross-system control are solved, and low-delay and high-compatibility remote control over the medical insurance terminal through the Internet or a local area network is achieved.

Description

Technical Field

[0001] The present invention relates to the technical field of same-screen control of Android systems, and in particular to a method for cross-system same-screen control operation based on an Android smart terminal. Background Art

[0002] With the continuous deepening of medical information construction, the medical insurance terminal, as an important carrier of medical services, has an increasingly prominent demand for cross-system collaborative operations. Traditional remote control technologies are mostly based on a single system architecture design. When realizing cross-platform interaction between Android medical insurance terminals and control terminals of different operating systems (such as Windows, iOS, etc.), there are generally problems such as poor compatibility and low data transmission efficiency.

[0003] Therefore, there is an urgent need for a remote control technology solution that can achieve low latency and high compatibility for medical insurance terminals through the Internet or local area network. Summary of the invention

[0004] The purpose of the present invention is to provide a method for cross-system same-screen control operation based on an Android smart terminal, to solve the technical problems of poor compatibility and low data transmission efficiency in the existing cross-system control of medical insurance terminals, and to realize low-latency and high-compatibility remote control of medical insurance terminals through the Internet or a local area network.

[0005] In a first aspect, the present invention provides a method for cross-system same-screen control operation based on an Android smart terminal, which is applied to a medical insurance terminal, comprising the following steps: S1. After deploying the remote control tool, the screen data of the medical insurance terminal is collected through the media projection interface; S2. After establishing a communication connection based on a communication protocol using the remote control tool and the client running on the control terminal, the screen data is encoded into RGB format and transmitted to the client through the remote control tool so that the control terminal displays the screen image of the medical insurance terminal; S3. The input events of the control terminal are monitored by the remote control tool and converted into the medical insurance terminal, so as to remotely control the medical insurance terminal through the control terminal; the input events include mouse input and keyboard input.

[0006] The method of the present invention for controlling operations on the same screen across systems based on an Android smart terminal supports functions such as screen image transmission, keyboard / mouse input, and file transfer, meets the needs of medical staff to assist patients in operations, and is conducive to improving medical treatment efficiency.

[0007] Furthermore, the specific steps in step S2 include: S21. Use Hextile encoding to compress the screen data in different regions and only transmit the screen data corresponding to the area where the picture changes.

[0008] The problem of low data transmission efficiency mentioned in the background technology is effectively solved, and a more optimized data transmission strategy is provided for realizing a remote control technical solution with low latency and high compatibility.

[0009] Furthermore, the specific steps in step S21 include: Dynamically adjust the screen data compression rate and screen data transmission frame rate of the screen change area according to the current network delay.

[0010] Through the above adjustments, when the network conditions are good, the display quality and smoothness of the screen are improved, and the user experience is improved.

[0011] Furthermore, the specific steps in step S21 include: When transmitting the screen data, the frame rate and resolution are dynamically adjusted.

[0012] The increase in frame rate and resolution improves picture quality and smoothness, providing users with a better remote control experience.

[0013] Furthermore, when dynamically adjusting the frame rate and resolution, execute: Adjust the frame rate to within the range of 15-30fps; Adjust the resolution to 720P or 1080P.

[0014] Furthermore, the specific steps in step S21 include: The screen data is compressed using a jpeg-turbo compression algorithm.

[0015] Furthermore, the specific steps in step S21 include: Receiving cache feedback information sent by the control end; the cache feedback information is generated when the control end caches historical screen data; Determine a picture change area and a non-picture change area according to the buffer feedback information; The transmission of the screen data corresponding to the non-image change area is terminated, and the screen data corresponding to the image change area is transmitted.

[0016] Furthermore, the specific steps in step S3 include: S31. When input events are generated simultaneously at the control terminal and the medical insurance terminal, the priorities of the input events at the control terminal and the medical insurance terminal are obtained and an ordered input queue is generated; S32. Execute all the input events in sequence according to the input queue.

[0017] Furthermore, the specific steps in step S31 include: S311. Real-time monitoring of the network connection status of the medical insurance terminal to obtain network quality parameters; the network quality parameters include packet loss rate and delay jitter; S312. Based on the network quality parameters, dynamically adjust the priority weight of the control terminal input event. When the packet loss rate exceeds a preset threshold or the delay jitter exceeds a preset range, reduce the priority weight of the control terminal input event; otherwise, maintain or increase the priority weight of the control terminal input event; S313. Sort the input events of the control terminal and the input events of the medical insurance terminal according to the adjusted priority weights to generate the input queue.

[0018] Furthermore, the specific steps in step S313 include: All input events are sorted using a weighted quick sort algorithm to generate the input queue.

[0019] From the above, it can be seen that the method of cross-system same-screen control operation based on Android smart terminal provided by the present invention realizes low-latency, high-compatibility remote control of medical insurance terminals through the Internet or local area network, supports screen image transmission, keyboard / mouse input, file transfer and other functions, meets the needs of medical staff to assist patients in operations, and improves medical treatment efficiency.

[0020] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or be understood by implementing the embodiments of the present invention. The purpose and other advantages of the present invention can be realized and obtained by the structures particularly pointed out in the written description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A flowchart of a method for cross-system same-screen control operation based on an Android smart terminal provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0022] The technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. The components of the embodiments of the present invention generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents the selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present invention.

[0023] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings. At the same time, in the description of the present invention, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0024] Reference Figure 1 The present invention provides a method for controlling operations on the same screen across systems based on an Android smart terminal, comprising the steps of: S1. After deploying the remote control tool (VNC Server), collect the screen data of the medical insurance terminal through the media projection interface (Media ProjectionAPI); S2. After establishing a communication connection based on a communication protocol (TCP / IP) with a client (VNC Viewer) running on the control end by using a remote control tool, the screen data is encoded into RGB format and transmitted to the client through the remote control tool, so that the control end displays the screen image of the medical insurance terminal; S3. Monitor the input events of the control end through the remote control tool and convert them into the medical insurance terminal, so as to realize remote control of the medical insurance terminal through the control end; the input events include mouse input and keyboard input.

[0025] In this embodiment, in view of the technical problem of poor compatibility when the Android system medical insurance terminal performs cross-system same-screen control operations with different operating system control terminals, this application uses the media projection interface of the Android system to collect screen data on the medical insurance terminal, ensuring the compatibility of the Android system screen data collection. Further, by deploying a remote control tool on the medical insurance terminal and establishing a communication connection based on a communication protocol between the remote control tool and the client running on the control terminal, the data transmission capability across the system platform is ensured. The screen data is encoded into RGB format by the remote control tool and transmitted to the client through the network, so that the control terminal can display the real-time screen image of the medical insurance terminal, realizing the same-screen display of the screen. In addition, the remote control tool is also responsible for monitoring the mouse and keyboard input events of the control terminal, and converting these input events and transmitting them to the medical insurance terminal, thereby realizing the remote control operation of the medical insurance terminal at the control terminal. Through the collaborative work of the remote control tool, the media projection interface and the communication protocol, the technical solution realizes the cross-system compatible same-screen display and remote control functions between the Android medical insurance terminal and the control terminals of different operating systems.

[0026] Specifically, in step S1, the medical insurance terminal pre-deploys the remote control tool to provide server-side support for subsequent remote control functions. The media projection interface is called to capture the screen data of the medical insurance terminal. The API is a standard interface provided by the Android system, which ensures the compatibility and stability of screen capture. In step S2, the control end starts the client and establishes a network connection based on the communication protocol with the remote control tool of the medical insurance terminal. The communication protocol, as a general network communication protocol, ensures the reliability of data transmission between cross-system platforms. The screen data is encoded into RGB format on the remote control tool side. The RGB format is a general image display format that can be compatible with display devices of multiple operating systems. The encoded screen data is transmitted to the client through the established TCP / IP connection. After receiving the data, the client decodes and displays it, so that the user of the control end can watch the screen of the medical insurance terminal in real time. In step S3, the remote control tool continuously monitors input events from the client, which include mouse clicks, keyboard keys and other operations. When the user on the control end performs an operation, the corresponding input events are captured by the remote control tool and converted into input instructions that can be recognized by the medical insurance terminal. These instructions are passed to the operating system level of the medical insurance terminal, thereby realizing remote control of the medical insurance terminal by the control end.

[0027] In some specific embodiments, medical staff use a computer with Windows operating system as a control terminal to remotely operate the Android medical insurance terminal deployed with the method of the present application. First, install and configure the remote control tool application on the Android medical insurance terminal, and start the screen sharing service. Then, install the client software on the Windows computer, enter the IP address and port number of the medical insurance terminal, and establish a connection. After the connection is established, the screen image of the medical insurance terminal will be displayed in real time on the monitor of the Windows computer. Medical staff can operate the medical insurance terminal on the Windows computer through the mouse and keyboard, for example, click the button on the screen of the medical insurance terminal, enter medical information, etc. All operating instructions are sent to the remote control tool of the medical insurance terminal through the client, and then converted by the remote control tool into executable instructions for the medical insurance terminal, so that medical staff can smoothly remotely control the Android medical insurance terminal on the Windows computer and complete the handling of medical insurance business.

[0028] In some embodiments, the specific steps in step S2 include: S21. Use Hextile encoding to compress the screen data in different regions and only transmit the screen data corresponding to the area where the picture changes.

[0029] In view of the problem that the transmission of all screen data may be inefficient, the technical solution of this embodiment is proposed. In this embodiment, step S21 adopts the Hextile encoding method, which divides the screen image into multiple areas and compresses the data of each area. By compressing the area by area, the amount of data transmission can be reduced. More importantly, step S21 only transmits the screen data corresponding to the area where the picture changes, which means that the system will detect the areas that have changed on the screen and only transmit the data of these changed areas, while no transmission is performed for the areas that have not changed. This method significantly reduces the amount of data that needs to be transmitted, especially when the screen image does not change much, it can greatly reduce the bandwidth occupancy and improve the data transmission efficiency, thereby reducing the delay of remote control and improving the user experience. The technical means of adopting Hextile encoding and only transmitting the area where the picture changes effectively solves the problem of low data transmission efficiency mentioned in the background technology, and provides a more optimized data transmission strategy for realizing a remote control technical solution with low delay and high compatibility.

[0030] Specifically, during the screen data transmission process, first, the screen image is divided into multiple tiles. For example, a fixed-size rectangular tile division method can be used to evenly divide the screen into tiles of 16x16 pixels or 32x32 pixels. Then, for each tile, the Hextile encoding algorithm is used for compression processing. Hextile encoding is a block image compression algorithm that is good at compressing image areas composed of repeated patterns or color blocks. The operating interface of the medical insurance terminal usually contains a large number of static or repetitive elements, such as window backgrounds, icons, and text areas. These areas are very suitable for efficient compression using Hextile encoding. Furthermore, the system will continue to monitor changes in the screen image and identify the tile areas that have changed through frame difference comparison or other image difference detection techniques. For tile areas that have not changed, there is no need to retransmit the data, and only the compressed data of the tile areas that have changed is transmitted. As a result, the amount of data transmission is greatly reduced, reducing the network bandwidth requirements. For example, when a user performs a small number of operations on the medical insurance terminal interface, such as clicking a button or scrolling a page, only part of the screen changes. At this time, the system only needs to transmit the tile data of these changed areas, rather than the complete data of the entire screen, which significantly improves data transmission efficiency.

[0031] In some specific embodiments, when the screen resolution of the medical insurance terminal is 1920x1080 pixels, the screen is divided into tiles of 32x32 pixels. When the screen image is updated, the changed area is detected, assuming that the changed area only occupies 10% of the total screen area. Hextile coding is used to compress the tiles in the changed area, and the compression rate reaches 5:1. Compared with directly transmitting uncompressed full-screen RGB data, the data transmission volume is reduced to 2% of the original. It can be seen that by adopting Hextile coding and only transmitting the technical means of the changed area of ​​the picture, the data transmission volume can be effectively reduced, and the efficiency and fluency of the cross-system same-screen control operation can be improved.

[0032] In some embodiments, the specific steps in step S21 include: Dynamically adjust the screen data compression rate and screen data transmission frame rate of the screen change area according to the current network delay.

[0033] Among them, the acquisition of network delay can be realized through network detection between the server and the control end. For example, the server periodically sends a detection packet to the control end, and records the time when the control end returns the detection packet, thereby calculating the network delay. The adjustment of the screen data compression rate can be reflected in that when the network delay is high, the compression rate is reduced, the purpose is to reduce the amount of data transmission and ensure the fluency of remote control. On the contrary, when the network delay is low, the compression rate can be increased, while ensuring the fluency of remote control, the user experience is improved. The adjustment of the screen data transmission frame rate can be reflected in that when the network delay is high, the frame rate is reduced, the purpose is to reduce the amount of data transmission per unit time, and ensure the fluency of remote control. On the contrary, when the network delay is low, the frame rate can be increased, while ensuring the fluency of remote control, the user experience is improved. Therefore, the screen data compression rate and the screen data transmission frame rate are dynamically adjusted through the network delay, so that the remote control method can adapt to the data transmission requirements under different network environments and strike a balance between data transmission efficiency and user experience.

[0034] Specifically, the medical insurance terminal monitors the current network delay in real time. When the network delay is detected to exceed the preset first threshold, such as 200ms, the system determines that the current network condition is poor. At this time, the screen data compression rate of the picture change area is reduced, such as adjusting the JPEG compression quality parameter from a high gear to a low gear, and reducing the screen data transmission frame rate, such as reducing the frame rate from 30fps to 15fps. Through the above adjustment, the amount of data to be transmitted is reduced, ensuring that the control end can still smoothly display the screen image of the medical insurance terminal and perform remote control operations in the case of poor network conditions. When the network delay is detected to be lower than the preset second threshold, such as 100ms, the system determines that the current network condition is good. At this time, the screen data compression rate of the picture change area is increased, such as adjusting the JPEG compression quality parameter from a low gear to a high gear, and increasing the screen data transmission frame rate, such as increasing the frame rate from 15fps to 30fps. Through the above adjustment, in the case of good network conditions, the display quality and smoothness of the screen image are improved, and the user experience is improved.

[0035] In some specific implementations, the threshold of network delay can be adjusted according to actual application scenarios and requirements. For example, in medical scenarios with higher real-time requirements, the threshold can be set lower to ensure the real-time performance of remote control. The adjustment range of the screen data compression rate and the screen data transmission frame rate can also be adjusted according to actual conditions to achieve the best balance. For example, the compression rate can be set to multiple gears, and the frame rate can also be set to multiple levels, and fine adjustments can be made according to the specific value of the network delay.

[0036] In some embodiments, the specific steps in step S21 include: Dynamically adjust the frame rate and resolution when transmitting screen data.

[0037] Among them, the dynamic adjustment of frame rate and resolution is made based on the current network environment. When the network environment is good, the frame rate and resolution are increased to ensure the quality and smoothness of the picture. When the network environment deteriorates, the frame rate and resolution are reduced to reduce the amount of data transmission and ensure the smoothness and real-time performance of the same-screen control. As a result, the picture quality, smoothness and real-time performance can be balanced under different network conditions to optimize the effect of cross-system same-screen control operations. As a preferred embodiment, the evaluation of the network environment can be based on network parameters such as network delay and packet loss rate. Specifically, when the network delay is high or the packet loss rate is high, it can be judged that the network environment is poor, and the frame rate and resolution are reduced at this time. Conversely, when the network delay is low and the packet loss rate is low, it can be judged that the network environment is good, and the frame rate and resolution are increased at this time. The adjustment range of the frame rate can be set to 15-30fps, and the resolution adjustment can be selected as 720P or 1080P.

[0038] Specifically, in the cross-system same-screen control operation method, first, the system will continuously monitor the current network environment, such as monitoring network delay and packet loss rate. When it is detected that the network delay increases or the packet loss rate exceeds the preset threshold, the system determines that the current network environment has deteriorated. At this time, the system will dynamically reduce the frame rate and resolution of screen data transmission. For example, the frame rate is reduced from 30fps to 15fps, and the resolution is reduced from 1080P to 720P. The reduction in frame rate and resolution reduces the amount of data to be transmitted, relieves network pressure, ensures the real-time and smoothness of same-screen control, and avoids the occurrence of screen freezes. Conversely, when the system detects that the network delay is reduced and the packet loss rate is restored to below the preset threshold, the system determines that the network environment has improved. At this time, the system will dynamically increase the frame rate and resolution of screen data transmission, for example, the frame rate is restored from 15fps to 30fps, and the resolution is restored from 720P to 1080P. The increase in frame rate and resolution improves the picture quality and smoothness, providing users with a better remote control experience.

[0039] In some specific implementations, the resolution of the medical insurance terminal is initially set to 1080P, and the frame rate is initially set to 30fps. When the network monitoring module detects that the network delay exceeds 100ms, the control module adjusts the resolution to 720P and the frame rate to 15fps. If the network delay continues to exceed 150ms, the frame rate is further reduced to 10fps to ensure basic same-screen smoothness. When the network delay drops below 50ms, the control module gradually restores the frame rate and resolution to the initial values, first restoring the frame rate to 30fps, and then restoring the resolution to 1080P. Through this dynamic adjustment mechanism, the system can adaptively adjust the transmission strategy of screen data under different network environment conditions, and maximize the user experience while ensuring the basic availability of same-screen control.

[0040] In some embodiments, when dynamically adjusting the frame rate and resolution, the following is performed: Adjust the frame rate to within the range of 15-30fps; Adjust the resolution to 720P or 1080P.

[0041] In this embodiment, the frame rate adjustment range is limited to 15-30fps to ensure that the picture playback has basic smoothness. The lower limit of the frame rate is set to 15fps to avoid obvious freezes in the picture, and the upper limit of the frame rate is set to 30fps to limit the network bandwidth occupancy and prevent unnecessary waste of resources. The resolution adjustment is limited to 720P or 1080P, which takes into account the data transmission efficiency while ensuring the basic clarity of the picture. The 720P resolution is relatively low and is suitable for situations where the network conditions are poor or the device performance is low. The 1080P resolution can provide a clearer picture display effect when network conditions permit. Through the combined limitation of frame rate and resolution, the same-screen control parameters can be dynamically adjusted under different network environments and device performance, thereby achieving a balance between picture quality and smoothness.

[0042] Specifically, the technical means for dynamically adjusting the frame rate and resolution when transmitting screen data limit the specific adjustment range of the frame rate and resolution. In the specific implementation process, the current network status will be monitored first, and parameters such as network delay and packet loss rate will be collected in real time. When the network condition is good, the system will adjust the frame rate to close to 30fps and set the resolution to 1080P to provide a smooth and high-definition same-screen experience. Conversely, when the network condition is detected to be deteriorating, such as increased network delay or increased packet loss rate, the system will dynamically reduce the frame rate to 15fps and adjust the resolution to 720P. As a result, while ensuring basic fluency, the amount of data transmission is reduced and adapted to poor network environments. This dynamic adjustment mechanism ensures the stability of the same-screen control operation under different network conditions and maximizes the user experience.

[0043] In some specific embodiments, when the medical insurance terminal is in an initial state with a good network environment, when the same-screen control system is started, the frame rate is set to 30fps and the resolution is set to 1080P. As the network environment of the medical insurance terminal changes, for example, when the network delay is monitored to increase from 20ms to 100ms and the packet loss rate exceeds 5%, the same-screen control system dynamically adjusts the same-screen parameters in response to the decline in network quality. The frame rate is reduced to 15fps and the resolution is adjusted to 720P. Through this dynamic adjustment, when the network conditions deteriorate, the basic availability of the same-screen control is guaranteed, and severe freezes or even connection interruptions caused by network problems are avoided.

[0044] In some embodiments, the specific steps in step S21 include: Compress screen data using the jpeg-turbo compression algorithm.

[0045] In this embodiment, the jpeg-turbo compression algorithm is an image compression algorithm used to compress screen data. After the screen data is compressed by region using the Hextile encoding method and only the screen data corresponding to the image change region is transmitted, the jpeg-turbo compression algorithm is used to compress the screen data in the image change region. By compressing the screen data in the image change region using the jpeg-turbo compression algorithm, the amount of data to be transmitted can be further reduced.

[0046] Specifically, after the screen data of the medical insurance terminal is collected, the remote control tool will identify the area where the screen changes. For the screen data of these areas where the screen changes, the remote control tool uses the jpeg-turbo compression algorithm to compress it. The compressed screen data is transmitted to the client through the network. On the client, the received compressed screen data is decompressed and displayed, so that the screen image of the medical insurance terminal is presented on the control end. The jpeg-turbo compression algorithm is used to compress the screen data in the area where the screen changes, which reduces the amount of data transmission, so that the screen data can still be transmitted smoothly when the network bandwidth is limited, ensuring the real-time control operation of the same screen of the medical insurance terminal.

[0047] In some specific embodiments, in step S21, the screen data of the picture change area is first divided into small image blocks. These image blocks are then input into the jpeg-turbo compression algorithm for compression to generate compressed image data. The compression level can be set to adjust the compression rate and image quality under different network conditions. For example, when the network bandwidth is low, a higher compression level can be used to reduce the amount of data transmission; when the network bandwidth is high, a lower compression level can be used to obtain a better image display effect. The compressed image data is then encapsulated and sent to the control end through the network. After receiving the data, the control end uses the corresponding jpeg-turbo decompression algorithm to decompress the data, restore the screen image and display it on the control end. As a result, efficient compression and transmission of screen data using the jpeg-turbo compression algorithm is achieved.

[0048] In some embodiments, the specific steps in step S21 include: Receiving cache feedback information sent by the control end; the cache feedback information is generated when the control end has historical screen data cached; Determine the image change area and the non-image change area according to the buffer feedback information; The transmission of the screen data corresponding to the non-image change area is terminated, and the screen data corresponding to the image change area is transmitted.

[0049] In this embodiment, after receiving the cache feedback information, the medical insurance terminal analyzes the information to distinguish the screen change area and the non-screen change area on the screen. For the area that has not changed, the data transmission is terminated; for the area that has changed, the data transmission is continued. As a possible implementation method, the control end can maintain a screen data buffer area. When a new screen data frame is received and decoded, the control end compares the current frame with the previous frame in the buffer area. The comparison process can be performed pixel by pixel, or a block comparison method can be used to improve efficiency. If the control end detects that the screen content has not changed significantly since the last feedback, the cache feedback information is generated and sent to the medical insurance terminal. The cache feedback information can include a simple flag bit, such as a Boolean value, a true value indicates that the control end has cached historical screen data, and a false value is the opposite. After receiving the cache feedback information, the medical insurance terminal parses the information. If the information indicates that the control end has cached historical data, the medical insurance terminal will perform screen change detection when encoding and transmitting screen data. Screen change detection can use a frame difference method, that is, compare the pixel difference between the current frame and the previous frame. The difference degree can be set to a threshold, and the area above the threshold is determined to be a screen change area. For the image change area, the screen data is encoded and transmitted normally; for the non-image change area, the screen data transmission is terminated, thereby avoiding the transmission of unnecessary data and effectively saving network bandwidth.

[0050] Specifically, an optimization scheme based on a cache feedback mechanism is proposed for the data transmission efficiency problem of the same-screen control operation of the medical insurance terminal screen. In step S21, the control end first detects whether it has cached the historical screen data of the medical insurance terminal. If the control end is connected to the medical insurance terminal for the first time, or the cached data has been cleared, the control end does not send the cache feedback information, and the medical insurance terminal performs full screen data transmission. If the control end has cached the historical screen data, the control end generates and sends the cache feedback information to the medical insurance terminal. After receiving the cache feedback information, the medical insurance terminal enters the differentiated data transmission mode. In this mode, the screen data collected by the medical insurance terminal is first divided into multiple areas, for example, using the Hextile coding block method. Then, the medical insurance terminal compares each area of ​​the current screen frame with the corresponding area of ​​the previous frame to determine whether the pixels in the area have changed. The judgment method can be to calculate the mean or variance of the pixel difference and compare it with the preset threshold. For areas where the pixel change is less than the threshold, it is determined as a non-screen change area; otherwise, it is determined as a screen change area. For the non-image-changing area, the medical insurance terminal terminates the screen data encoding and transmission of the area; for the image-changing area, the medical insurance terminal compresses the screen data of the area using Hextile encoding and transmits it to the control end. After receiving the data, the control end decodes and updates the display screen. In this way, only the data in the area where the screen changes is transmitted, which greatly reduces the data transmission volume and improves the data transmission efficiency.

[0051] In some specific implementations, the control end may periodically send cache feedback information to the medical insurance terminal, for example, once every 1 second. The cache feedback information may adopt a custom data packet format, including an information type identifier and a cache status flag. After receiving the data packet, the medical insurance terminal determines whether it is cache feedback information according to the information type identifier, and parses the cache status flag to obtain the cache status of the control end. As an example, the data packet format of the cache feedback information may be defined as: [Information type: 1 byte] [Cache status: 1 byte]. Among them, when the value of the information type field is 0x01, it indicates cache feedback information, when the value of the cache status field is 0x01, it indicates that the control end has cached historical screen data, and when the value is 0x00, it indicates that the control end has not cached historical screen data or the cache has expired. The medical insurance terminal decides whether to start the differentiated data transmission mode according to the value of the cache status field. As a result, the cache status of the control end can be fed back to the medical insurance terminal in real time, and the medical insurance terminal can dynamically adjust the data transmission strategy according to the feedback information, and reduce the data transmission amount as much as possible while ensuring the synchronization of the screen image, thereby improving the system performance.

[0052] In some embodiments, the specific steps in step S3 include: S31. When input events are generated simultaneously at the control terminal and the medical insurance terminal, the priority of the input events at the control terminal and the medical insurance terminal is obtained and an ordered input queue is generated; S32. Execute all input events in sequence according to the input queue.

[0053] For step S31, the simultaneous generation of input events can be judged by timestamps. For example, when the difference between the timestamps of the input events generated by the control end and the medical insurance terminal is less than a preset threshold, it is determined that the input events are generated simultaneously. Priority acquisition can be based on a preset priority rule. For example, the priority of the input event of the control end can be set to be higher than the priority of the local input event of the medical insurance terminal, so as to ensure the priority execution of the remote control instruction. As an implementation method, the priority can be quantified into a numerical value, and the higher the numerical value, the higher the priority. In the process of generating an ordered input queue, a data structure such as a priority queue can be adopted. The input events are inserted into the priority queue according to their priority, and the events with high priority are arranged at the front end of the queue. For step S32, all input events are executed in sequence according to the input queue, which means that the event execution engine takes out the input events one by one and executes them according to the order of arrangement of the events from the input queue generated in step S31. The event execution engine needs to be able to parse the input events and convert them into instructions that can be recognized and executed by the medical insurance terminal. Therefore, through the above steps, it can be ensured that when the input events are generated by the control end and the medical insurance terminal at the same time, the input events can be executed in a predetermined priority order to avoid input conflicts.

[0054] Specifically, in the remote control scenario of the medical insurance terminal, when the operator performs remote operation through the control terminal, the local user of the medical insurance terminal may also perform touch screen operation. In order to solve the input conflict problem that may arise from this, this embodiment is proposed to avoid the confusion of the execution order caused by the simultaneous input events without priority distinction and queue scheduling, thereby causing misoperation. Through step S31, the system first determines whether the simultaneous input of the control terminal and the medical insurance terminal occurs. If it is judged to be yes, the priority of the input events at both ends is further obtained. For example, the input operation priority of the control terminal can be preset to be higher than the local operation of the medical insurance terminal. Then, the system generates an input queue according to the priority level, and the event with high priority is arranged at the front end of the queue. Step S32 ensures that the event execution engine strictly processes the event in the order of the input queue, executes the event at the front end of the queue first, and then executes the event at the back end of the queue, so as to ensure the orderliness of the execution of the input event. In this way, even in the scenario of concurrent input, the system can reasonably coordinate and process input instructions from different sources, ensure the accuracy and reliability of remote control operations, and improve the user experience.

[0055] In some specific implementations, a time window mechanism can be used to determine whether input events are generated simultaneously. For example, a 50-millisecond time window is set. If the difference between the timestamps of the control-end input event and the medical insurance terminal input event falls within this time window, it is determined to be generated simultaneously. The priority rules can be adjusted according to the actual application scenario. For example, in some scenarios where local operations need to be prioritized, the priority of the local input events of the medical insurance terminal can be set higher than the control-end input events. The input queue can be implemented using a first-in-first-out queue (FIFO) combined with a priority sorting algorithm. When a new input event is generated, it is inserted into the appropriate position of the queue according to its priority. The event execution engine runs as an independent module, continuously monitoring the input queue. Once the queue is not empty, the head event is taken out for parsing and execution. After execution, continue to monitor the queue until the queue is empty. In this way, it is ensured that all input events entering the queue can be executed in an orderly manner.

[0056] In some embodiments, the specific steps in step S31 include: S311. Real-time monitoring of the network connection status of the medical insurance terminal and obtaining network quality parameters; network quality parameters include packet loss rate and delay jitter; S312. Based on the network quality parameters, dynamically adjust the priority weight of the control terminal input event. When the packet loss rate exceeds the preset threshold or the delay jitter exceeds the preset range, reduce the priority weight of the control terminal input event; otherwise, maintain or increase the priority weight of the control terminal input event; S313. According to the adjusted priority weights, the input events of the control terminal and the input events of the medical insurance terminal are sorted to generate an input queue.

[0057] Specifically, the network interface of the medical insurance terminal is detected periodically, for example, once every 1 second. In each detection, multiple network detection packets are sent to a preset network target address, such as the IP address of the control terminal or a specific network server. By analyzing the response of the network detection packet, network quality parameters such as packet loss rate and delay jitter are calculated. For example, the packet loss rate can be calculated by the ratio of the number of network detection packets that have not received a response to the total number of packets sent. Delay jitter can be calculated by the standard deviation of the round-trip delay of multiple consecutive network detection packets.

[0058] Furthermore, the priority weight of the control end input event is dynamically adjusted based on the network quality parameters. The preset threshold and preset range are pre-set, for example, the preset threshold of the packet loss rate is set to 10%, and the preset range of the delay jitter is set to 50 milliseconds. When the monitored packet loss rate exceeds 10% or the delay jitter exceeds 50 milliseconds, the priority weight of the control end input event is reduced. The priority weight can be reduced in a variety of ways, for example, the priority weight value of the control end input event is directly reduced by a fixed value, or a linear or nonlinear function is used to calculate the reduced priority weight value according to the specific values ​​of the packet loss rate and the delay jitter. On the contrary, when the network quality is good, that is, the packet loss rate is less than 10% and the delay jitter is less than 50 milliseconds, the priority weight of the control end input event is maintained unchanged, or when the network quality is very good, the priority weight can be increased.

[0059] Thus, the generation of the input queue sorts the input events of the control end and the medical insurance terminal based on the adjusted priority weights. When the control end and the medical insurance terminal generate input events at the same time, their respective priority weights are taken into account. Input events generated locally by the medical insurance terminal are usually given a higher initial priority weight to ensure timely response of local operations. The initial priority weight of the input events on the control end is relatively low and is dynamically adjusted according to the network quality parameters. During the sorting process, a weighted quick sorting algorithm can be used to efficiently generate input queues. Based on the traditional quick sorting, the weighted quick sorting algorithm adds priority considerations, so that input events with high priority are arranged in a front position in the queue, so that they are executed first.

[0060] Specifically, in the scenario where the medical insurance terminal and the control end perform collaborative operations, when the network condition is good, for example, the packet loss rate is less than 5% and the delay jitter is less than 20 milliseconds, the priority weight of the control end input event is maintained or slightly increased. At this time, if the control end user clicks a button on the client, and the local operator of the medical insurance terminal also slides on the screen of the medical insurance terminal at the same time, due to the good network quality, the priority weight of the control end input event is relatively high, and the click event of the control end can be transmitted to the medical insurance terminal in time and processed quickly, ensuring the response speed of remote control. On the contrary, when the network condition deteriorates, for example, the packet loss rate rises to 15% and the delay jitter increases to 80 milliseconds, the priority weight of the control end input event is significantly reduced. In this case, if the control end user and the local operator of the medical insurance terminal perform operations at the same time, the sliding operation event of the local medical insurance terminal will be processed first due to its higher priority weight, ensuring the smoothness of the local operation of the medical insurance terminal, avoiding the interference of remote control input with local operation due to network delay, and improving user experience.

[0061] In some specific implementations, the acquisition cycle of the network quality parameters is set to 1 second, the packet loss rate threshold is set to 10%, and the delay jitter range threshold is set to 50 milliseconds. The priority weight adjustment strategy is set to: when the packet loss rate exceeds 10% or the delay jitter exceeds 50 milliseconds, the priority weight of the control end input event is reduced by 20%; when the packet loss rate is less than 5% and the delay jitter is less than 20 milliseconds, the priority weight of the control end input event is increased by 10%; in other network quality conditions, the priority weight remains unchanged. In the initial state, the priority weight of the local input event of the medical insurance terminal is set to 100, and the priority weight of the control end input event is set to 80. When the network quality deteriorates, the priority weight of the control end input event may be reduced to 64 or even lower. The sorting algorithm adopts weighted quick sorting, and the input events are arranged from high to low according to the priority weight, an input queue is generated, and it is executed in sequence according to the queue order. Through the setting of the above specific parameters and strategies, the stability and user experience of the cross-system same-screen control operation in different network environments can be effectively improved.

[0062] In some embodiments, the specific steps in step S313 include: All input events are sorted using a weighted quick sort algorithm to generate an input queue.

[0063] Specifically, the working principle of using the weighted quick sort algorithm to generate an input queue is that when input events are generated at the control end and the medical insurance terminal at the same time, these input events are collected. Each input event is assigned a weight value according to the preset priority rules or dynamically adjusted priority weights. The weighted quick sort algorithm sorts all input events based on these weight values. During the sorting process, the algorithm quickly moves input events with higher weights to the front of the queue and input events with lower weights to the back of the queue. After the sorting is completed, an ordered input queue is generated, and the input events in the queue are arranged in order from high to low weight. The system executes input events in sequence according to the order of this queue, ensuring that high-priority control-end input events can be responded to and processed more quickly, reducing system response delays, and improving the real-time and response speed of cross-system same-screen control operations.

[0064] In some specific implementations, assume that the control end generates a mouse click event, and the medical insurance terminal itself generates a background data update event. The mouse click event is assigned a higher priority weight, such as a weight value of 10; the background data update event is assigned a lower priority weight, such as a weight value of 3. After the weighted quick sorting algorithm is started, the mouse click event is selected as the benchmark event. Since the weight value of the background data update event is less than the mouse click event, the background data update event is classified in front of the benchmark event. The quick sorting algorithm continues to recursively process the sub-queues and finally generates an input queue, in which the mouse click event is arranged before the background data update event. The system executes according to this queue, giving priority to mouse click events to ensure that the user's click operation at the control end can be responded to in a timely manner.

[0065] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0066] The above description is only an embodiment of the present invention and is not intended to limit the protection scope of the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for cross-system same-screen control operation based on an Android smart terminal, applied to a medical insurance terminal, characterized in that: Includes steps: S1. After deploying the remote control tool, the screen data of the medical insurance terminal is collected through the media projection interface; S2. After establishing a communication connection based on a communication protocol using the remote control tool and the client running on the control terminal, the screen data is encoded into RGB format and transmitted to the client through the remote control tool so that the control terminal displays the screen image of the medical insurance terminal; S3. The input events of the control terminal are monitored by the remote control tool and converted into the medical insurance terminal, so as to remotely control the medical insurance terminal through the control terminal; the input events include mouse input and keyboard input.

2. The method for controlling operations on the same screen across systems based on an Android smart terminal according to claim 1, characterized in that: The specific steps in step S2 include: S21. Use Hextile encoding to compress the screen data in different regions and only transmit the screen data corresponding to the area where the picture changes.

3. The method for controlling operations on the same screen across systems based on an Android smart terminal according to claim 2, characterized in that: The specific steps in step S21 include: Dynamically adjust the screen data compression rate and screen data transmission frame rate of the screen change area according to the current network delay.

4. The method for controlling operations on the same screen across systems based on an Android smart terminal according to claim 2, characterized in that: The specific steps in step S21 include: When transmitting the screen data, the frame rate and resolution are dynamically adjusted.

5. The method for controlling operations on the same screen across systems based on an Android smart terminal according to claim 4 is characterized in that: Execute when dynamically adjusting frame rate and resolution: Adjust the frame rate to within the range of 15-30fps; Adjust the resolution to 720P or 1080P.

6. The method for controlling operations on the same screen across systems based on an Android smart terminal according to claim 2, characterized in that: The specific steps in step S21 include: The screen data is compressed using a jpeg-turbo compression algorithm.

7. The method for controlling operations on the same screen across systems based on an Android smart terminal according to claim 2, characterized in that: The specific steps in step S21 include: Receiving cache feedback information sent by the control end; the cache feedback information is generated when the control end caches historical screen data; Determine a picture change area and a non-picture change area according to the buffer feedback information; The transmission of the screen data corresponding to the non-image change area is terminated, and the screen data corresponding to the image change area is transmitted.

8. The method for controlling operations on the same screen across systems based on an Android smart terminal according to claim 1, characterized in that: The specific steps in step S3 include: S31. When input events are generated simultaneously at the control terminal and the medical insurance terminal, the priorities of the input events at the control terminal and the medical insurance terminal are obtained and an ordered input queue is generated; S32. Execute all the input events in sequence according to the input queue.

9. The method for controlling operations on the same screen across systems based on an Android smart terminal according to claim 8, characterized in that: The specific steps in step S31 include: S311. Real-time monitoring of the network connection status of the medical insurance terminal to obtain network quality parameters; the network quality parameters include packet loss rate and delay jitter; S312. Based on the network quality parameters, dynamically adjust the priority weight of the control terminal input event. When the packet loss rate exceeds a preset threshold or the delay jitter exceeds a preset range, reduce the priority weight of the control terminal input event; otherwise, maintain or increase the priority weight of the control terminal input event; S313. Sort the input events of the control terminal and the input events of the medical insurance terminal according to the adjusted priority weights to generate the input queue.

10. The method for controlling operations on the same screen across systems based on an Android smart terminal according to claim 9, characterized in that: The specific steps in step S313 include: All input events are sorted using a weighted quick sort algorithm to generate the input queue.

Images