Keyboard position dynamic adjustment method and device based on shielding coefficient and medium

Abstract

The invention discloses a keyboard position dynamic adjustment method and device based on a shielding coefficient and a medium, and the method comprises the steps: carrying out the weighted fusion according to the historical click frequency and visual features, and generating the comprehensive weight of each control; dividing a system page into a plurality of candidate bits by taking an input box of a keyboard as a reference; for each candidate bit in the plurality of candidate bits, calculating a shielding coefficient according to the comprehensive weight in combination with a shielding area proportion between the keyboard and the control; and selecting the candidate position with the minimum shielding coefficient as a target position, and moving the keyboard to the target position. The invention provides a keyboard position dynamic adjustment method and device based on a shielding coefficient and a medium, the comprehensive weight of a control is calculated by combining historical clicks and visual features, a multi-direction candidate position is set by taking an input box as a reference, and then the optimal position is selected according to the shielding coefficient, so that the dynamic adjustment of the keyboard position is realized. The problem that when a system keyboard pops up, due to the fact that the position is fixed or an adjusting mechanism is single, key controls are shielded, and then user operation is affected can be solved.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a method, device and medium for dynamic adjustment of keyboard position based on occlusion coefficient. Background Technology

[0002] In mobile applications and cross-platform interaction scenarios, the system keyboard, as a core tool for users to complete information input, directly determines the smoothness of user operation and is deeply related to interaction efficiency and user experience. If the keyboard pops up in an appropriate position, users can clearly see key controls on the page while typing, completing a smooth process without frequently switching the focus. Conversely, if the position is unreasonable, it may cause users to perform redundant operations such as hiding the keyboard and swiping the page, or even interrupt the operation logic by obstructing the core function entry point, or even cause confusion about the interface functions. Currently, the pop-up logic of the system keyboard is still mainly based on basic design, and in most cases, it adopts a fixed display strategy. For example, on mobile devices, it is docked at the bottom center of the screen by default, and similar fixed layout logic is often followed in tablets or cross-platform scenarios.

[0003] However, in scenarios such as customer service communication and form filling, the system keyboard is fixed at the bottom center by default when it pops up, or simply avoids the input box, which often causes the page buttons to be obscured. At this time, users have to manually move the keyboard to click the button, which is cumbersome. Even worse, if the submit button is obscured, users may not be able to complete the submission because they cannot find the button, which directly interrupts the operation process and seriously reduces the usability of the software. Summary of the Invention

[0004] This invention provides a method, device, and medium for dynamic adjustment of keyboard position based on occlusion coefficient, in order to solve the problem that key controls are obscured when the system keyboard pops up due to fixed position or simple adjustment mechanism, thus affecting user operation.

[0005] To achieve the above objectives, this application provides a method for dynamically adjusting the keyboard position based on an occlusion coefficient, comprising:

[0006] Retrieve parameters of controls on the system page;

[0007] Based on the control parameters, a weighted fusion is performed according to historical click counts and visual features to generate a comprehensive weight for each control;

[0008] The system page is divided into several candidate positions based on the keyboard input box;

[0009] For each of the candidate positions, an occlusion coefficient is calculated based on the comprehensive weight and the occlusion area ratio between the keyboard and the control.

[0010] Select the candidate position with the smallest occlusion coefficient as the target position, and move the keyboard to the target position.

[0011] In this invention, historical click counts directly reflect user dependence on controls, while visual features reflect the visual salience of the page. These two metrics are weighted and fused to generate a comprehensive weight, essentially labeling controls with importance and accurately distinguishing between core and secondary controls. A circular candidate area is constructed based on the input box, breaking the limitation of a fixed keyboard position through abundant candidate positions. This design allows the keyboard to flexibly find the optimal position in multiple directions, even moving upwards or diagonally if there is insufficient space at the bottom, fundamentally reducing the risk of obscuring key controls. The calculation of the occlusion coefficient combines control weight with the actual occlusion area and depth, achieving precise quantification of the occlusion impact. When partial occlusion is unavoidable, the candidate position with the smallest occlusion coefficient is selected, ensuring both convenient input operations and maximizing the accessibility of core page functions, truly achieving effective intelligent adjustment. Compared to existing technologies, this invention calculates the comprehensive weight of controls by combining historical clicks and visual features, sets up multi-directional candidate positions based on the input box, and selects the optimal position according to the occlusion coefficient. This can avoid the keyboard affecting operation due to fixed position or adjustment of a single occluded control. Therefore, it can solve the problem that when the system keyboard pops up, key controls are occluded due to fixed position or single adjustment mechanism, which affects user operation.

[0012] As a preferred embodiment, based on the control parameters, a weighted fusion is performed according to historical click counts and visual features to generate a comprehensive weight for each control, specifically as follows:

[0013] Based on the control parameters, the interaction frequency weight is calculated by combining the historical click count of the first control and preset parameters with a logarithmic function.

[0014] The visual focus weight is calculated based on the area of ​​the first control and the area of ​​the system page.

[0015] The interaction frequency weight and the visual focus weight are weighted and summed according to a preset adjustment coefficient to obtain the comprehensive weight of the first control.

[0016] Iterate through all the controls to obtain the overall weight of each control.

[0017] In this preferred solution, historical click counts reflect users' actual operational preferences. Interaction frequency weights are calculated using a logarithmic function, leveraging the characteristic that the output growth rate slows as the input increases, thus preventing excessive weight inflation for controls with high click counts. Visual focus weights reflect the visual salience of controls. The importance of interactive behavior and visual features may vary across different scenarios. Adjustment coefficients allow developers to dynamically adjust the proportions of these two dimensions based on business goals and user group characteristics, making the weight calculation more aligned with actual needs.

[0018] As a preferred embodiment, the system page is divided into several candidate positions based on the keyboard input boxes, specifically as follows:

[0019] The inner radius is set based on the height of the keyboard and the height of the input box;

[0020] On the system page, a ring-shaped area is established with a preset point above the central axis of the keyboard as the center, based on the inner and outer radii; wherein the outer radius is a multiple of the inner radius.

[0021] The annular region is divided into candidate regions covering vertical, horizontal and diagonal directions to obtain the several candidate positions.

[0022] This preferred design employs a ring-shaped design instead of a rectangular grid, providing more uniform coverage within a limited space, particularly effective distribution of candidate positions along the diagonal. It considers vertical, horizontal, and diagonal directions, covering traditional horizontal arrangements while also enabling diagonal swiping, enhancing interactive flexibility. The ratio of the outer to inner radii allows for flexible adjustment of the candidate area to accommodate different screen sizes and user preferences. Concentrating candidate positions within the visible area around the keyboard reduces user eye movement, lowers operational complexity, and improves input efficiency.

[0023] As a preferred embodiment, for each of the candidate positions, an occlusion coefficient is calculated based on the comprehensive weight and the occlusion area ratio between the keyboard and the control, specifically as follows:

[0024] For each control among the candidate positions, the occlusion ratio corresponding to the control is calculated based on the overlapping area and the area of ​​the control itself; wherein, the overlapping area is calculated based on the geometric intersection algorithm to determine the overlapping area between the control and the keyboard;

[0025] For each of the candidate positions, the occlusion ratio is weighted and summed based on the comprehensive weight of each control in that candidate position, and a comfort penalty term is introduced to calculate the occlusion coefficient.

[0026] This preferred solution combines a geometric intersection algorithm to accurately calculate the overlapping area of ​​controls and the keyboard, rather than simply determining their position, thus more accurately quantifying the degree of occlusion. Using the overlapping area and the control's own area to calculate the occlusion ratio avoids evaluation bias caused by differences in control size, making controls of different sizes comparable. An additional penalty factor is introduced, considering not only physical occlusion but also the user's subjective comfort, making the evaluation closer to the actual user experience. Through weighted calculation, the occlusion of important controls can be prioritized, preventing the occlusion of secondary controls from affecting the overall evaluation.

[0027] As a preferred embodiment, the candidate position with the smallest occlusion coefficient is selected as the target position, and the keyboard is moved to the target position, specifically as follows:

[0028] If the system page corresponds to the Android system, the keyboard can be moved to the target position by adjusting the horizontal and vertical offsets of the window or by using a window insertion controller to manage the display area.

[0029] If the system page corresponds to the iOS system, the keyboard area is located according to the keyboard layout guide provided by the system, and the keyboard is moved to the target position by adjusting the distance between the keyboard and the preset safety margin.

[0030] If the system page corresponds to a web client, the keyboard overlay position is adjusted by combining CSS transformations, and the keyboard position is corrected in real time by listening to changes in the browser viewport, moving the keyboard to the target position.

[0031] This optimized solution targets the candidate position with the lowest occlusion coefficient, ensuring minimal occlusion of controls after keyboard movement, maximizing the preservation of page operation space, and improving user operation smoothness. Platform-specific implementations are adopted for Android, iOS, and Web, fully leveraging the native features of each system to guarantee the stability and consistency of the mobile effect and avoid common cross-platform compatibility issues.

[0032] As a preferred embodiment, after selecting the candidate position with the smallest occlusion coefficient as the target position and moving the keyboard to the target position, the method further includes:

[0033] The system page is monitored. If the screen orientation of the system page changes or the page content is updated, the occlusion coefficient is recalculated and the keyboard position is readjusted.

[0034] This optimized solution addresses screen orientation changes by promptly responding to page layout rearrangements caused by device posture adjustments. It prevents imbalances in the relative positions of keyboards and page controls due to orientation changes, ensuring minimal occlusion. When page content is updated, the occlusion coefficient is recalculated to quickly adapt to the new page structure, preventing newly added controls from being obscured by the keyboard or conflicts between keyboard position and content layout.

[0035] This application also provides a keyboard position dynamic adjustment device based on occlusion coefficient, including a data module, a synthesis module, a division module, a coefficient module and an adjustment module;

[0036] The data module is used to obtain control parameters from the system page.

[0037] The integration module is used to generate a comprehensive weight for each control by performing weighted fusion based on the control parameters, historical click count, and visual features.

[0038] The division module is used to divide the system page into several candidate positions based on the keyboard input box;

[0039] The coefficient module is used to calculate the occlusion coefficient for each of the plurality of candidate positions based on the comprehensive weight and the occlusion area ratio between the keyboard and the control.

[0040] The adjustment module is used to select the candidate position with the smallest occlusion coefficient as the target position and move the keyboard to the target position.

[0041] As a preferred embodiment, the integrated module includes an interaction unit, a focus unit, a weighting unit, and an integration unit;

[0042] The interaction unit is used to calculate the interaction frequency weight based on the control parameters, according to the historical click count of the first control and preset parameters, combined with a logarithmic function.

[0043] The focus unit is used to calculate the visual focus weight based on the control area of ​​the first control and the area of ​​the system page.

[0044] The weighting unit is used to perform a weighted summation of the interaction frequency weight and the visual focus weight according to a preset adjustment coefficient to obtain the comprehensive weight of the first control.

[0045] The integration unit is used to traverse all the controls and obtain the integrated weight of each control.

[0046] As a preferred embodiment, the partitioning module includes an inner circle unit, a region unit, and a partitioning unit;

[0047] The inner ring unit is used to set the inner ring radius based on the height of the keyboard and the height of the input box;

[0048] The region unit is used to establish a ring-shaped region on the system page with a preset point above the keyboard centerline as the center, based on the inner and outer radii; wherein the outer radius is a multiple of the inner radius;

[0049] The dividing unit is used to divide the annular region into candidate regions covering vertical, horizontal and diagonal directions to obtain the plurality of candidate positions.

[0050] This application also provides a storage medium storing a computer program, which is called and executed by a computer to implement the keyboard position dynamic adjustment method based on occlusion coefficient as described above. Attached Figure Description

[0051] Figure 1 This is a flowchart illustrating a method for dynamically adjusting keyboard position based on an occlusion coefficient, as provided in an embodiment of this application.

[0052] Figure 2 This is a block diagram of the weight calculation logic provided in the embodiments of this application;

[0053] Figure 3 This is a diagram illustrating the annular candidate region provided in an embodiment of this application;

[0054] Figure 4 This is a flowchart of the solution provided in the embodiments of this application;

[0055] Figure 5 This is a schematic diagram of a keyboard position dynamic adjustment device based on an occlusion coefficient provided in an embodiment of this application. Detailed Implementation

[0056] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0057] In the description of this application, it should be understood that the term "first" is used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "several" means two or more.

[0058] The keyboard position dynamic adjustment method based on occlusion coefficient provided in this application aims to solve a series of problems caused by the fixed position or single adjustment mechanism of traditional system keyboards: existing technologies lack dynamic adaptation capabilities based on the actual layout and interaction characteristics of the page; when the keyboard pops up, it easily occludes high-frequency operation controls, causing user operation to be interrupted; and fixed avoidance strategies are prone to failure in complex scenarios; the distance between the keyboard and the input box is too far, which increases the burden of user eye movement and causes interaction to be fragmented; it is difficult to build a unified occlusion calculation logic across platforms (Android / iOS / Web) at the same time to adapt to the differences in the underlying implementation of different platforms and ensure the consistency of multi-terminal experience.

[0059] Example 1:

[0060] Please see Figure 1 The embodiments of this application provide a method for dynamically adjusting the keyboard position based on an occlusion coefficient, including steps S1 to S5, and the specific implementation steps are as follows:

[0061] S1. Obtain the control parameters in the system page.

[0062] Step S1 in this embodiment of the application is specifically as follows:

[0063] In the target system, the position and type of all controls on the system page are identified, and historical behavior data of the controls' interactions, screen size, keyboard size, etc., are obtained to get the control parameters.

[0064] The specific methods for obtaining location-related data in different systems are as follows:

[0065] ① Android system: The view hierarchy is built based on the recursive traversal mechanism of ViewGroup, all controls are located, including interactive components such as buttons and input boxes, and the pixel coordinate parameters of each View component relative to the screen are directly obtained through the View.getLocationOnScreen() method.

[0066] ② iOS system: Use the frame property (position and size in the parent view's coordinate system) or bounds property (size in its own coordinate system) of UIView to obtain the view's position information, and recursively traverse the view hierarchy through the subviews property to locate the controls and extract their position coordinates simultaneously.

[0067] ③ Web front-end: Recursively traverse the DOM tree structure to locate all interactive elements, including buttons, input boxes, etc.; obtain the size and position of the element relative to the viewport through the Element.getBoundingClientRect() method, which returns a DOMRect object containing top, right, bottom, left, width, and height properties.

[0068] It should be noted that the "controls" in this embodiment refer to various elements on the system page that users can interact with, such as buttons, input boxes, tabs, drop-down menus, checkboxes, radio buttons, function icons, etc.

[0069] S2. Based on control parameters, weighted fusion is performed according to historical click counts and visual features to generate a comprehensive weight for each control.

[0070] Step S2 in this embodiment of the application is specifically as follows:

[0071] In the target system, the click frequency of each control is counted based on the historical behavior data in the control parameters, thereby identifying the target control and summarizing its historical click count in a preset time period; the historical behavior data includes event tracking records, etc.

[0072] The interaction frequency weight W is calculated based on the historical click count of the first control and preset parameters, combined with a logarithmic function. freq ;

[0073] The visual focus weight W is calculated based on the area of ​​the first control and the area of ​​the system page. visual ;

[0074] The interaction frequency weight W is adjusted according to a preset adjustment coefficient. freq and visual focus weight W visual Perform a weighted summation to obtain the overall weight W of the first control;

[0075] Iterate through all controls to obtain the overall weight of each control.

[0076] The interaction frequency weight is:

[0077] W freq = log(historical click count + 1)

[0078] The visual focus weight is:

[0079] W visual = (control area / screen area) × 2

[0080] The overall weight is:

[0081] W = αW freq +βWvisual

[0082] Where α and β are adjustment coefficients, with the default values ​​being α = 0.7 and β = 0.3.

[0083] For examples of this application, please refer to [link / reference]. Figure 2 , Figure 2 This is a block diagram of the weight calculation logic provided in the embodiments of this application, which shows the calculation process of interaction frequency weight, visual focus weight and comprehensive weight;

[0084] Wherein, "W_freq" refers to the interaction frequency weight W. freq "W_visual" refers to the visual focus weight W. visual The input data consists of two parts: firstly, the historical interaction data of the control (the number of clicks based on user tracking data); and secondly, the control type (recorded in a pre-built list of control attributes). It also includes page layout information (control dimensions width and height, and the control's x-axis and y-axis coordinates relative to the screen). Calculations show that the theoretical range for visual focus weight (visual weight value) is 0.1–1.8; and the theoretical range for interaction frequency weight (frequency weight value) is 0.0–2.5. The weight allocation results are indirectly reflected through keyboard position optimization; developers can obtain specific values ​​through the debugging interface to assist in verification.

[0085] Furthermore, the calculation method for "Submit button W=1.6, Close icon W=0.4" is as follows:

[0086] ① The submit button has a value of W = 1.6. The calculation process is as follows:

[0087] Assuming the submit button has been clicked 100 times, the button area is 8000 pixels, and the screen area is 1920,000 pixels (e.g., a 1080×1920 screen), then:

[0088] W freq =log(100+1)≈log(101)≈2.00;

[0089] W visual = (8000 / 1,920,000)×2≈0.0083×2≈0.0166

[0090] By introducing a centering bonus into the visual weights (e.g., if a button is located at the bottom center of the screen, an additional 0.2 weight is added), the final weights are:

[0091] W = 0.7 × W_{freq} + 0.3 × (W_{visual} + positional bonus)

[0092] Substituting the parameters, we get:

[0093] W=0.7×2.00+0.3×(0.0166+0.2)≈1.4+0.065≈1.6

[0094] ② The icon is off. W = 0.4. The calculation process is as follows:

[0095] Assuming the close icon is clicked 5 times, the icon area is 500 pixels, and the screen area is the same, then:

[0096] W freq =log(5+1)≈log(6)≈0.78;

[0097] W visual = (500 / 1,920,000)×2≈0.00026×2≈0.00052

[0098] Introducing a control type attenuation coefficient (e.g., icon weight defaults to ×0.5), the final weight is:

[0099] W=0.5×(0.7×0.78+0.3×0.00052)≈0.4

[0100] In this embodiment S2, the historical click count reflects the user's actual operational preferences. The interaction frequency weight is calculated using a logarithmic function. By utilizing the characteristic that the output growth rate slows down as the logarithmic input increases, the excessive expansion of the weight of controls with high click counts can be avoided. The visual focus weight reflects the visual salience of the control. The importance of interactive behavior and visual features may vary in different scenarios. The adjustment coefficient allows developers to dynamically adjust the proportion of the two dimensions according to business goals and user group characteristics, making the weight calculation more in line with actual needs.

[0101] S3. Divide the system page into several candidate positions based on the keyboard input box.

[0102] Step S3 in this embodiment of the application is specifically as follows:

[0103] The inner radius is set based on the keyboard height, the input box height, and the safety spacing.

[0104] On the system page, a ring-shaped area is created with the preset point above the keyboard centerline as the center, based on the inner and outer radii; the outer radius is 1.5 times the inner radius.

[0105] The annular region is divided into candidate areas covering vertical, horizontal, and diagonal directions at 45° intervals, resulting in several candidate positions.

[0106] For examples of this application, please refer to [link / reference]. Figure 3 , Figure 3This is a circular candidate region illustration provided in an embodiment of this application, showing several candidate positions after division, specifically including 8 candidate regions.

[0107] This embodiment S3 employs a ring-shaped design instead of a rectangular grid, providing more uniform coverage within a limited space, especially effectively distributing candidate positions along the diagonal direction. It considers vertical, horizontal, and diagonal directions, covering both traditional horizontal arrangements and enabling diagonal swiping, thus enhancing interactive flexibility. By adjusting the ratio of the outer to inner radii, the candidate area can be flexibly adjusted to suit different screen sizes and user preferences. Concentrating candidate positions within the visible area around the keyboard reduces the user's eye movement distance, lowers operational complexity, and improves input efficiency.

[0108] S4. For each candidate position among several candidate positions, calculate the occlusion coefficient based on the comprehensive weight and the occlusion area ratio between the keyboard and the control.

[0109] Step S4 in this embodiment of the application is specifically as follows:

[0110] For each control among several candidate positions, based on the overlapping area A overlap The occlusion ratio R of the control is calculated by combining the area of ​​the control itself; where the overlapping area A is the occlusion ratio R of the control itself. overlap It is obtained by calculating the overlapping area of ​​the controls and the keyboard based on a geometric intersection algorithm;

[0111] For each candidate position among several candidate positions, the occlusion ratio R is weighted and summed based on the comprehensive weight W of each control in that candidate position, and a comfort penalty term is introduced to calculate the occlusion coefficient.

[0112] The occlusion coefficient is:

[0113] Occlusion coefficient = Σ(W) i ×R i ) + γ × (distance between keyboard and input box center / screen height)

[0114] Among them, W i and R i These represent the overall weight and occlusion ratio of control i, respectively; γ is the distance penalty coefficient, with a default value of 0.2.

[0115] In this embodiment, S4 combines a geometric intersection algorithm to accurately calculate the area of ​​the overlapping region between the control and the keyboard, rather than simply determining the position, thus more accurately quantifying the degree of occlusion. Using the overlapping area and the control's own area to calculate the occlusion ratio avoids evaluation bias caused by differences in control size, making controls of different sizes comparable. An additional penalty term is introduced, considering not only physical occlusion but also the user's subjective comfort, making the evaluation closer to the actual user experience. Through weighted calculation, the occlusion of important controls can be prioritized, preventing the occlusion of secondary controls from affecting the overall evaluation.

[0116] S5. Select the candidate position with the smallest occlusion coefficient as the target position and move the keyboard to the target position.

[0117] Step S5 in this embodiment includes S5.1 to S5.2, specifically as follows:

[0118] S5.1 If the system page corresponds to the Android system, the keyboard can be moved to the target position by adjusting the horizontal and vertical offsets of the window or by using the window insets controller to manage the display area. Specifically, the screen offset of the keyboard window can be adjusted using the x / yOffset property of WindowManager.LayoutParams, or the content display area can be dynamically managed through the WindowInsetsController interface to achieve accurate positioning and adaptation of the input area when the keyboard pops up.

[0119] If the system page corresponds to the iOS system, the keyboard area is located according to the keyboard layout guidelines provided by the system, and the keyboard is moved to the target position by adjusting the distance between the keyboard and the preset safety margin. Specifically, based on the linkage mechanism between the UIKeyboardLayoutGuide layout guide and the NSLayoutConstraint automatic layout constraints, the layout relationship between the keyboard and the system safety area is dynamically adjusted to ensure that the input controls are always within the visible range when the keyboard is floating;

[0120] If the system page corresponds to a web interface, the keyboard overlay position is adjusted using CSS transformations, and the keyboard position is corrected in real time by monitoring changes in the browser viewport, moving the keyboard to the target position. Specifically, the keyboard container is repositioned using the CSS "transform:translate()" property, while the Visual Viewport API is used to monitor changes in the browser viewport size and dynamically correct the relative coordinates between the keyboard and the input area to ensure smooth input interaction.

[0121] In this embodiment, S5.1 targets the candidate position with the smallest occlusion coefficient, ensuring minimal occlusion of controls after keyboard movement, maximizing the preservation of page operation space, and improving user operation smoothness. Platform-specific implementations are used for Android, iOS, and Web, fully utilizing the native features of each system to ensure the stability and consistency of the movement effect and avoid common cross-platform compatibility issues.

[0122] S5.2 Monitor the system page; if the screen orientation of the system page changes or the page content is updated, recalculate the occlusion coefficient and readjust the keyboard position. Specifically:

[0123] ① Listen for screen rotation events. When the device screen orientation changes, such as switching between portrait and landscape modes, recalculate the occlusion coefficient and readjust the keyboard position. Adjust the layout, size, or interactive area of ​​page elements to adapt to the new screen ratio.

[0124] ②Web platform: Use MutationObserver to monitor changes in the DOM tree, such as adding / deleting nodes or modifying attributes. Android system: Use ViewTreeObserver to monitor changes in the view hierarchy, such as layout completion or changes in view size.

[0125] When the content of the system page is updated asynchronously via AJAX requests, dynamic rendering, or other methods, the occlusion coefficient is recalculated and the keyboard position is readjusted.

[0126] For examples of this application, please refer to [link / reference]. Figure 4 , Figure 4 This is a flowchart of the solution provided in this application embodiment, showing the overall process of adjusting the keyboard position in this embodiment one.

[0127] In this embodiment, S5.2 can promptly respond to changes in screen orientation and page layout rearrangement caused by device posture adjustments, avoiding imbalances in the relative relationship between keyboard positions and page controls due to orientation changes, and ensuring that occlusion is always kept to a minimum. When page content is updated, the occlusion coefficient is recalculated to quickly adapt to the new page structure, preventing newly added controls from being obscured by the keyboard or conflicts between keyboard positions and content layout.

[0128] Furthermore, by monitoring screen rotation, DOM updates, and dynamic form changes in real time, it can automatically recalculate and adjust the keyboard position. Even in complex scenarios such as customer service conversations and long forms, it maintains a reasonable distance between the input field and the keyboard, reducing eye movement.

[0129] Overall, this embodiment has the following beneficial effects:

[0130] In this application, historical click counts directly reflect user dependence on controls, while visual features reflect the visual salience of the page. These two metrics are weighted and fused to generate a comprehensive weight, essentially labeling controls with importance and accurately distinguishing between core and secondary controls. A circular candidate area is constructed based on the input box, breaking the limitation of a fixed keyboard position through abundant candidate positions. This design allows the keyboard to flexibly find the optimal position in multiple directions, even moving upwards or diagonally if there is insufficient space at the bottom, fundamentally reducing the risk of obscuring key controls. The calculation of the occlusion coefficient combines control weight with the actual occlusion area and depth, achieving precise quantification of the occlusion impact. When partial occlusion is unavoidable, the candidate position with the smallest occlusion coefficient is selected, ensuring both convenient input operations and maximizing the accessibility of core page functions, truly achieving effective intelligent adjustment.

[0131] In summary, this application dynamically analyzes the weight of all controls on the page, prioritizing the avoidance of frequently used controls. Simultaneously, by combining the occlusion area ratio with an ergonomic distance penalty mechanism, it precisely selects the optimal keyboard position, ensuring both the visibility of key operation buttons and smooth input, thereby effectively reducing the user's operational burden and improving interaction fluency. Furthermore, this application provides a universal occlusion coefficient calculation algorithm that is adaptable to the underlying APIs of different platforms. Developers only need to call a unified interface, eliminating the need for repeated development for different platforms, significantly improving development efficiency.

[0132] Example 2:

[0133] Please see Figure 5 The embodiments of this application provide a keyboard position dynamic adjustment device based on occlusion coefficient, including a data module 10, a comprehensive module 20, a division module 30, a coefficient module 40 and an adjustment module 50;

[0134] Among them, data module 10 is used to obtain control parameters in the system page;

[0135] The comprehensive module 20 is used to generate a comprehensive weight for each control by weighting and fusing based on control parameters, historical click counts, and visual features.

[0136] The partitioning module 30 is used to divide the system page into several candidate positions based on the keyboard input boxes;

[0137] The coefficient module 40 is used to calculate the occlusion coefficient for each candidate position among several candidate positions, based on the comprehensive weight and the occlusion area ratio between the keyboard and the control.

[0138] Adjustment module 50 is used to select the candidate position with the smallest occlusion coefficient as the target position and move the keyboard to the target position.

[0139] In one embodiment, data module 10 specifically comprises:

[0140] In the target system, the position and type of all controls on the system page are identified, and historical behavior data of the controls' interactions, screen size, keyboard size, etc., are obtained to get the control parameters.

[0141] The specific methods for obtaining location-related data in different systems are as follows:

[0142] ① Android system: The view hierarchy is built based on the recursive traversal mechanism of ViewGroup, all controls are located, including interactive components such as buttons and input boxes, and the pixel coordinate parameters of each View component relative to the screen are directly obtained through the View.getLocationOnScreen() method.

[0143] ② iOS system: Use the frame property (position and size in the parent view's coordinate system) or bounds property (size in its own coordinate system) of UIView to obtain the view's position information, and recursively traverse the view hierarchy through the subviews property to locate the controls and extract their position coordinates simultaneously.

[0144] ③ Web front-end: Recursively traverse the DOM tree structure to locate all interactive elements, including buttons, input boxes, etc.; obtain the size and position of the element relative to the viewport through the Element.getBoundingClientRect() method, which returns a DOMRect object containing top, right, bottom, left, width, and height properties.

[0145] It should be noted that the "controls" in this second embodiment refer to various elements on the system page that users can interact with, such as buttons, input boxes, tabs, drop-down menus, checkboxes, radio buttons, function icons, etc.

[0146] In one embodiment, the integration module 20 includes an interaction unit, a focus unit, a weighting unit, and an integration unit;

[0147] The interaction unit is used to count the click frequency of each control in the target system corresponding to the system page based on the historical behavior data in the control parameters, thereby identifying the target control and summarizing its historical click count in a preset time period; the historical behavior data includes event tracking records, etc.

[0148] The interaction unit is also used to calculate the interaction frequency weight W based on the historical click count of the first control and preset parameters, combined with a logarithmic function. freq ;

[0149] The focus unit is used to calculate the visual focus weight W based on the area of ​​the first control and the area of ​​the system page. visual ;

[0150] The weighting unit is used to weight the interaction frequency W according to a preset adjustment coefficient. freq and visual focus weight W visual Perform a weighted summation to obtain the overall weight W of the first control;

[0151] The comprehensive unit is used to traverse all controls and obtain the comprehensive weight of each control.

[0152] The interaction frequency weight is:

[0153] W freq = log(historical click count + 1)

[0154] The visual focus weight is:

[0155] W visual = (control area / screen area) × 2

[0156] The overall weight is:

[0157] W = αW freq +βW visual

[0158] Where α and β are adjustment coefficients, with the default values ​​being α = 0.7 and β = 0.3.

[0159] For examples of this application, please refer to [link / reference]. Figure 2 , Figure 2 This is a block diagram of the weight calculation logic provided in the embodiments of this application, which shows the calculation process of interaction frequency weight, visual focus weight and comprehensive weight;

[0160] Wherein, "W_freq" refers to the interaction frequency weight W. freq "W_visual" refers to the visual focus weight W. visual The input data consists of two parts: firstly, the historical interaction data of the control (the number of clicks based on user tracking data); and secondly, the control type (recorded in a pre-built list of control attributes). It also includes page layout information (control dimensions width and height, and the control's x-axis and y-axis coordinates relative to the screen). Calculations show that the theoretical range for visual focus weight (visual weight value) is 0.1–1.8; and the theoretical range for interaction frequency weight (frequency weight value) is 0.0–2.5. The weight allocation results are indirectly reflected through keyboard position optimization; developers can obtain specific values ​​through the debugging interface to assist in verification.

[0161] Furthermore, the calculation method for "Submit button W=1.6, Close icon W=0.4" is as follows:

[0162] ① The submit button has a value of W = 1.6. The calculation process is as follows:

[0163] Assuming the submit button has been clicked 100 times, the button area is 8000 pixels, and the screen area is 1920,000 pixels (e.g., a 1080×1920 screen), then:

[0164] W freq =log(100+1)≈log(101)≈2.00;

[0165] W visual = (8000 / 1,920,000)×2≈0.0083×2≈0.0166

[0166] By introducing a centering bonus into the visual weights (e.g., if a button is located at the bottom center of the screen, an additional 0.2 weight is added), the final weights are:

[0167] W = 0.7 × W_{freq} + 0.3 × (W_{visual} + positional bonus)

[0168] Substituting the parameters, we get:

[0169] W=0.7×2.00+0.3×(0.0166+0.2)≈1.4+0.065≈1.6

[0170] ② The icon is off. W = 0.4. The calculation process is as follows:

[0171] Assuming the close icon is clicked 5 times, the icon area is 500 pixels, and the screen area is the same, then:

[0172] W freq =log(5+1)≈log(6)≈0.78;

[0173] W visual = (500 / 1,920,000)×2≈0.00026×2≈0.00052

[0174] Introducing a control type attenuation coefficient (e.g., icon weight defaults to ×0.5), the final weight is:

[0175] W=0.5×(0.7×0.78+0.3×0.00052)≈0.4

[0176] In the integrated module 20 of this embodiment, historical click counts reflect users' actual operational preferences. The interaction frequency weight is calculated using a logarithmic function, leveraging the characteristic that the output growth rate slows down as the logarithmic input increases, thus preventing excessive expansion of the weight of controls with high click counts. The visual focus weight reflects the visual salience of the control. The importance of interactive behavior and visual features may differ in different scenarios. The adjustment coefficient allows developers to dynamically adjust the proportion of the two dimensions according to business goals and user group characteristics, making the weight calculation more aligned with actual needs.

[0177] In one embodiment, the partitioning module 30 includes an inner circle unit, a region unit, and a partitioning unit;

[0178] The inner circle unit is used to set the inner circle radius based on the keyboard height, the input box height, and the safety spacing.

[0179] A region unit is used to create a ring-shaped area on the system page, centered on a preset point above the keyboard's central axis, based on the inner and outer radii; wherein the outer radius is 1.5 times the inner radius.

[0180] The dividing unit is used to divide the annular area into candidate regions covering the vertical, horizontal and diagonal directions at 45° intervals, thus obtaining several candidate positions.

[0181] For examples of this application, please refer to [link / reference]. Figure 3 , Figure 3 This is a circular candidate region illustration provided in an embodiment of this application, showing several candidate positions after division, specifically including 8 candidate regions.

[0182] In this embodiment, the partitioning module 30 adopts a ring design instead of a rectangular grid, which can provide a more uniform coverage area within a limited space, especially effectively distributing candidate positions along the diagonal direction. It considers vertical, horizontal, and diagonal directions simultaneously, covering both traditional horizontal arrangements and enabling diagonal sliding operations, thus enhancing interactive flexibility. By using the ratio between the outer and inner radii, the range of the candidate area can be flexibly adjusted to adapt to different screen sizes and user preferences. Concentrating candidate positions within the visible area around the keyboard reduces the distance the user's eye travels, lowers operational complexity, and improves input efficiency.

[0183] In one embodiment, coefficient module 40 specifically comprises:

[0184] For each control among several candidate positions, based on the overlapping area A overlap The occlusion ratio R of the control is calculated by combining the area of ​​the control itself; where the overlapping area A is the occlusion ratio R of the control itself. overlap It is obtained by calculating the overlapping area of ​​the controls and the keyboard based on a geometric intersection algorithm;

[0185] For each candidate position among several candidate positions, the occlusion ratio R is weighted and summed based on the comprehensive weight W of each control in that candidate position, and a comfort penalty term is introduced to calculate the occlusion coefficient.

[0186] The occlusion coefficient is:

[0187] Occlusion coefficient = Σ(W) i ×R i ) + γ × (distance between keyboard and input box center / screen height)

[0188] Among them, W i and R i These represent the overall weight and occlusion ratio of control i, respectively; γ is the distance penalty coefficient, with a default value of 0.2.

[0189] In this embodiment, the coefficient module 40 combines a geometric intersection algorithm to accurately calculate the area of ​​the overlapping region between the control and the keyboard, rather than simply determining the position, thus more accurately quantifying the degree of occlusion. Using the overlapping area and the control's own area to calculate the occlusion ratio avoids evaluation bias caused by differences in control size, making controls of different sizes comparable. An additional penalty term is introduced, considering not only physical occlusion but also the user's subjective comfort, making the evaluation closer to the actual user experience. Through weighted calculation, the occlusion of important controls can be prioritized, preventing the occlusion of secondary controls from affecting the overall evaluation.

[0190] In one embodiment, the adjustment module 50 includes an adjustment unit and a monitoring unit, specifically:

[0191] The adjustment unit is used to move the keyboard to the target position if the system page corresponds to the Android system by adjusting the horizontal and vertical offsets of the window or by using the window insets controller to manage the display area. Specifically, it uses the x / yOffset property of WindowManager.LayoutParams to adjust the screen offset of the keyboard window, or uses the WindowInsetsController interface to dynamically manage the content display area, so as to achieve accurate positioning and adaptation of the input area when the keyboard pops up.

[0192] The adjustment unit is also used to locate the keyboard area according to the keyboard layout guide provided by the system if the system page corresponds to the iOS system, and move the keyboard to the target position by adjusting the distance between the keyboard and the preset safety margin. Specifically, based on the linkage mechanism of UIKeyboardLayoutGuide layout guide and NSLayoutConstraint automatic layout constraints, the layout relationship between the keyboard and the system safety area is dynamically adjusted to ensure that the input controls are always within the visible range when the keyboard floats;

[0193] The adjustment unit is also used to adjust the keyboard overlay position in conjunction with CSS transformations if the system page corresponds to a web interface. It also monitors browser viewport changes and corrects the keyboard position in real time, moving the keyboard to the target location. Specifically, it uses the CSS "transform:translate()" property to adjust the keyboard container's displacement, while simultaneously using the Visual Viewport API to monitor browser viewport size changes in real time and dynamically correct the relative coordinates between the keyboard and the input area, ensuring smooth input interaction.

[0194] This embodiment adjusts the candidate position with the lowest occlusion coefficient, ensuring minimal occlusion of controls after keyboard movement, maximizing the preservation of page operation space, and improving user operation smoothness. Platform-specific implementations are used for Android, iOS, and Web, fully utilizing the native features of each system to guarantee the stability and consistency of the movement effect and avoid common cross-platform compatibility issues.

[0195] The monitoring unit listens to the system page; if the screen orientation changes or the page content is updated, it recalculates the occlusion coefficient and readjusts the keyboard position. Specifically:

[0196] ① Listen for screen rotation events. When the device screen orientation changes, such as switching between portrait and landscape modes, recalculate the occlusion coefficient and readjust the keyboard position. Adjust the layout, size, or interactive area of ​​page elements to adapt to the new screen ratio.

[0197] ②Web platform: Use MutationObserver to monitor changes in the DOM tree, such as adding / deleting nodes or modifying attributes. Android system: Use ViewTreeObserver to monitor changes in the view hierarchy, such as layout completion or changes in view size.

[0198] When the content of the system page is updated asynchronously via AJAX requests, dynamic rendering, or other methods, the occlusion coefficient is recalculated and the keyboard position is readjusted.

[0199] For examples of this application, please refer to [link / reference]. Figure 4 , Figure 4 This is a flowchart of the solution provided in this application embodiment, showing the overall process of keyboard position adjustment in this second embodiment.

[0200] In this embodiment, the monitoring unit can promptly respond to changes in screen orientation, resulting in page layout rearrangement due to device posture adjustments. This avoids imbalances in the relative positions of keyboards and page controls caused by orientation changes, ensuring that occlusion is always kept to a minimum. When page content is updated, the occlusion coefficient is recalculated to quickly adapt to the new page structure, preventing newly added controls from being obscured by the keyboard or conflicts between keyboard position and content layout.

[0201] Furthermore, by monitoring screen rotation, DOM updates, and dynamic form changes in real time, it can automatically recalculate and adjust the keyboard position. Even in complex scenarios such as customer service conversations and long forms, it maintains a reasonable distance between the input field and the keyboard, reducing eye movement.

[0202] Overall, this embodiment has the following beneficial effects:

[0203] In this application, historical click counts directly reflect user dependence on controls, while visual features reflect the visual salience of the page. These two metrics are weighted and fused to generate a comprehensive weight, essentially labeling controls with importance and accurately distinguishing between core and secondary controls. A circular candidate area is constructed based on the input box, breaking the limitation of a fixed keyboard position through abundant candidate positions. This design allows the keyboard to flexibly find the optimal position in multiple directions, even moving upwards or diagonally if there is insufficient space at the bottom, fundamentally reducing the risk of obscuring key controls. The calculation of the occlusion coefficient combines control weight with the actual occlusion area and depth, achieving precise quantification of the occlusion impact. When partial occlusion is unavoidable, the candidate position with the smallest occlusion coefficient is selected, ensuring both convenient input operations and maximizing the accessibility of core page functions, truly achieving effective intelligent adjustment.

[0204] In summary, this application dynamically analyzes the weight of all controls on the page, prioritizing the avoidance of frequently used controls. Simultaneously, by combining the occlusion area ratio with an ergonomic distance penalty mechanism, it precisely selects the optimal keyboard position, ensuring both the visibility of key operation buttons and smooth input, thereby effectively reducing the user's operational burden and improving interaction fluency. Furthermore, this application provides a universal occlusion coefficient calculation algorithm that is adaptable to the underlying APIs of different platforms. Developers only need to call a unified interface, eliminating the need for repeated development for different platforms, significantly improving development efficiency.

[0205] Example 3:

[0206] This application provides a computer-readable storage medium, which includes a stored computer program, wherein the computer program controls the device where the computer-readable storage medium is located to execute the aforementioned method for dynamic adjustment of keyboard position based on occlusion coefficient when it is executed.

[0207] The keyboard position dynamic adjustment method based on occlusion coefficient, when implemented as a software functional unit and used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0208] The above are preferred embodiments of the present invention. It should be noted that, for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for dynamically adjusting keyboard position based on an occlusion coefficient, characterized in that, include: Retrieve control parameters from the system page; Based on the control parameters, a weighted fusion is performed according to historical click counts and visual features to generate a comprehensive weight for each control; The system page is divided into several candidate positions based on the keyboard input box; For each of the candidate positions, an occlusion coefficient is calculated based on the comprehensive weight and the occlusion area ratio between the keyboard and the control. Select the candidate position with the smallest occlusion coefficient as the target position, and move the keyboard to the target position.

2. The method for dynamic adjustment of keyboard position based on occlusion coefficient as described in claim 1, characterized in that, Based on the control parameters, a weighted fusion is performed according to historical click counts and visual features to generate a comprehensive weight for each control, specifically: Based on the control parameters, the interaction frequency weight is calculated by combining the historical click count of the first control and preset parameters with a logarithmic function. The visual focus weight is calculated based on the area of ​​the first control and the area of ​​the system page. The interaction frequency weight and the visual focus weight are weighted and summed according to a preset adjustment coefficient to obtain the comprehensive weight of the first control. Iterate through all the controls to obtain the overall weight of each control.

3. The method for dynamic adjustment of keyboard position based on occlusion coefficient as described in claim 1, characterized in that, The system page is divided into several candidate positions based on the keyboard input boxes, specifically as follows: The inner radius is set based on the height of the keyboard and the height of the input box; On the system page, a ring-shaped area is established with a preset point above the central axis of the keyboard as the center, based on the inner and outer radii; wherein the outer radius is a multiple of the inner radius. The annular region is divided into candidate regions covering vertical, horizontal and diagonal directions to obtain the several candidate positions.

4. The method for dynamic adjustment of keyboard position based on occlusion coefficient as described in claim 1, characterized in that, For each of the candidate positions, an occlusion coefficient is calculated based on the comprehensive weight and the occlusion area ratio between the keyboard and the control, specifically as follows: For each control among the candidate positions, the occlusion ratio corresponding to the control is calculated based on the overlapping area and the area of ​​the control itself; wherein, the overlapping area is calculated based on the geometric intersection algorithm to determine the overlapping area between the control and the keyboard; For each of the candidate positions, the occlusion ratio is weighted and summed based on the comprehensive weight of each control in the candidate position, and a comfort penalty term is introduced to calculate the occlusion coefficient.

5. The method for dynamic adjustment of keyboard position based on occlusion coefficient as described in claim 1, characterized in that, Select the candidate position with the smallest occlusion coefficient as the target position, and move the keyboard to the target position, specifically as follows: If the system page corresponds to the Android system, the keyboard can be moved to the target position by adjusting the horizontal and vertical offsets of the window or by using a window insertion controller to manage the display area. If the system page corresponds to the iOS system, the keyboard area is located according to the keyboard layout guide provided by the system, and the keyboard is moved to the target position by adjusting the distance between the keyboard and the preset safety margin. If the system page corresponds to a web client, the keyboard overlay position is adjusted by combining CSS transformations, and the keyboard position is corrected in real time by listening to changes in the browser viewport, moving the keyboard to the target position.

6. The method for dynamic adjustment of keyboard position based on occlusion coefficient as described in claim 1, characterized in that, After selecting the candidate position with the smallest occlusion coefficient as the target position and moving the keyboard to the target position, the method further includes: The system page is monitored. If the screen orientation of the system page changes or the page content is updated, the occlusion coefficient is recalculated and the keyboard position is readjusted.

7. A keyboard position dynamic adjustment device based on an occlusion coefficient, characterized in that, It includes a data module, a synthesis module, a partitioning module, a coefficient module, and an adjustment module; The data module is used to obtain control parameters from the system page. The integration module is used to generate a comprehensive weight for each control by performing weighted fusion based on the control parameters, historical click count, and visual features. The division module is used to divide the system page into several candidate positions based on the keyboard input box; The coefficient module is used to calculate the occlusion coefficient for each of the plurality of candidate positions based on the comprehensive weight and the occlusion area ratio between the keyboard and the control. The adjustment module is used to select the candidate position with the smallest occlusion coefficient as the target position and move the keyboard to the target position.

8. The keyboard position dynamic adjustment device based on occlusion coefficient as described in claim 7, characterized in that, The integrated module includes an interaction unit, a focus unit, a weighting unit, and an integration unit; The interaction unit is used to calculate the interaction frequency weight based on the control parameters, according to the historical click count of the first control and preset parameters, combined with a logarithmic function. The focus unit is used to calculate the visual focus weight based on the control area of ​​the first control and the area of ​​the system page. The weighting unit is used to perform a weighted summation of the interaction frequency weight and the visual focus weight according to a preset adjustment coefficient to obtain the comprehensive weight of the first control. The integration unit is used to traverse all the controls and obtain the integrated weight of each control.

9. The keyboard position dynamic adjustment device based on occlusion coefficient as described in claim 7, characterized in that, The partitioning module includes inner circle units, region units, and partitioning units; The inner ring unit is used to set the inner ring radius based on the height of the keyboard and the height of the input box; The region unit is used to establish a ring-shaped region on the system page with a preset point above the keyboard centerline as the center, based on the inner and outer radii; wherein the outer radius is a multiple of the inner radius; The dividing unit is used to divide the annular region into candidate regions covering vertical, horizontal and diagonal directions to obtain the plurality of candidate positions.

10. A storage medium, characterized in that, The storage medium stores a computer program, which is called and executed by a computer to implement a method for dynamic adjustment of keyboard position based on an occlusion coefficient as described in any one of claims 1 to 6.

Images